[Case 108473] change in password creates .my.cnf in home directory
Curious thing.
running CENTOS 6.5 x86_64 kvm " storm2 WHM 11.44.1 (build 15)
I host a number of domains.
When setting the password for the domain in cPanel (List --> "+" --> "Change Password"
I find that a file .my.cnf is created in the home directory. This file contains the domain username and password:
and ....
Is this Standard Operating Procedure? Interesting that it is not encrypted.
[meuser@storm2 ~]# ls -l /home/liliana/.my.cnf
-rw------- 1 liliana liliana 39 Aug 18 08:40 /home/liliana/.my.cnf
and ....
[meuser@storm2 ~]#cat /home/domainuser/.my.cnf
[client]
password=m
user=domainuser
Is this Standard Operating Procedure? Interesting that it is not encrypted.
-
Yes, that is normal behavior. The MySQL credentials in the .my.cnf file are used to log into phpMyAdmin and to install and uninstall Site Software, and the password is stored in plain text in that file. 0 -
Thanks. Nice to know. Now to sleep. 0 -
Is this a new behavior? I did not have any user level .my.cnf files on my server, and I change passwords relatively frequently. I never had any problems accessing phpmyadmin without the .my.cnf file there. I notice now if I change one through list accounts that a .my.cnf is indeed created. While the permissions being 600 certainly helps keep it restricted to that user, I still would like to know why this default behavior changed. This could lead to simple LFI attacks disclosing a plain text cPanel password. 0 -
The change you notice likely stems from internal case number 96117 that was introduced in cPanel version 11.44: Fixed case 96117: Update users .my.cnf when Synchronize MySQL password is selected. The issue was brought up with our developers in internal case number 108473, but it was determined to be by design. Thus, a feature request would be necessary to see a change in this behavior: Submit A Feature Request Thank you. 0 -
I'll be calling someone on the security team then. It's pretty unacceptable to store the CP PW in plain text; anyone with an addon domain or ftp docroot in public_html has access to the password. If nothing else, it should be default to create a different mysql password (one that is not the cPanel password) if the MySQL PW must be stored in plain text now. I don't see why it even needs to be in the first place though. 0 -
[quote="quizknows, post: 1711722">I'll be calling someone on the security team then. It's pretty unacceptable to store the CP PW in plain text; anyone with an addon domain or ftp docroot in public_html has access to the password.
It's important to note that this file is stored in the account's home directory (/home/$username) and not in the public_html directory. That does not make much of a difference regarding your concerns, but I wanted to point that out to other users who may see this thread. Please let us know if you the security team provides you with a case number and we can update this thread with the outcome. Thank you.0 -
Agreed, quizknows. This may be by design, but the design needs redesigned. Clearly. 0 -
I see the title has had the case number added to it, this is the same case number provided to me in my correspondence with the security team. I look forward to a resolution, thank you. 0 -
I just want to add my support for changing this. Storing the cpanel login details - or the mysql login details in a plain text file anywhere in the account is just not acceptable. 0 -
I also want it to be changed because 'Storing the cpanel login details - or the mysql login details in a plain text file anywhere in the account is just not acceptable' 0 -
Yeah that is absolutely insane. Although not as blatant as if one would put their cPanel password in /home//public_html/this_is_my_cpanel_password.txt, it's pretty close. Any vulnerable script on the account can be immediately used to garner the password [plaintext in a known location on every cPanel server] and then account login. If the account has SSH available, somebody can jump right in via SSH and pick away until they find something else exploitable. Let's face it, 99 times out of 100 a user who changes their password likely syncs it with MySQL. Reminds me of Filezilla and their stance for the longest time [and maybe still] that it's perfectly okay by default to store FTP login credentials in a plaintext file on your machine, so that when your machine gets infected the infecting program knows exactly where to go to look for FTP login credentials. This is disappointing. Somebody at cPanel should be yelling "what were you thinking!" Mike 0 -
I think you guys are looking at this all wrong. It's not a bug, it's a feature! Now, when the customer complains that they can't remember their password, just go look in .my.cnf! Problem solved! No messy password resets needed! Even better -- put up a KB article and explain how they can look for themselves. Think of the time savings! I hope we can replicate this design to email accounts, so I have an easy way of seeing everyone's email passwords, too. Maybe they can be stored in plain text in the user's root at /.my.email.passwords (better yet, use /.my.3mai1.pa$$w0rds for security). I'll get the feature request submitted. You're welcome. - Scott 0 -
[quote="sneader, post: 1730711"> I hope we can replicate this design to email accounts, so I have an easy way of seeing everyone's email passwords, too. Maybe they can be stored in plain text in the user's root at /.my.email.passwords (better yet, use /.my.3mai1.pa$$w0rds for security). I'll get the feature request submitted. You're welcome. - Scott
Thanks Scott! That certainly would make my life easier. Damned customers are always forgetting their email passwords. This would free up that support time for more important things, like suspending breached acccounts! M0 -
While I can usually appreciate sarcasm, this is a serious issue. I do thank everyone for their support (and the laughs). I've been assured this is being addressed, but I have not been supplied with a timeline. I'd mention another current event that increases the severity of this significantly, but the hackers haven't figured it out yet, so I'm in no hurry to post it publicly. 0 -
[quote="quizknows, post: 1731082">While I can usually appreciate sarcasm, this is a serious issue. I do thank everyone for their support (and the laughs).
Indeed it is a serious issue -- and serious issues often call for a little levity. For those of us who are on call 24/7/365 in this forsaken business, you have to have something to laugh about. I'm glad to hear cPanel has assured you that this is being addressed. Hopefully the other 'current event' you are referring to is also being addressed by the parties responsible for doing so. I appreciate the fact that sjwrick posted about it so that we could all be aware. Take it easy. M0 -
storing passwords, especially main account passwords, in plain text is a security issue - anyone who has had the experience of an account compromise knows this, so I am very surprised that cpanel has allowed this through, and those who favour convenience have probably never suffered from the tragedy that can strike. csx scans specifically highlight files where the cpanel password is stored, for attention/action as a security risk for now, I am deleting the ones I find so - the question now becomes, "what will not work if this file does not exist"? 0 -
[quote="ianmarie, post: 1733502">storing passwords, especially main account passwords, in plain text is a security issue - anyone who has had the experience of an account compromise knows this, so I am very surprised that cpanel has allowed this through, and those who favour convenience have probably never suffered from the tragedy that can strike. csx scans specifically highlight files where the cpanel password is stored, for attention/action as a security risk for now, I am deleting the ones I find so - the question now becomes, "what will not work if this file does not exist"?
Nothing. It doesn't need to be there. PHPmyAdmin does not need that file, it can use the cPanel session data and does so with priority over a .my.cnf file. The only need for a .my.cnf file IMO is so you can call mysql from the bash command line without needing your password. This needs to be fixed yesterday. BTW, the people calling it a convenience are being sarcastic ;)0 -
[quote="sneader, post: 1730711"> I hope we can replicate this design to email accounts, so I have an easy way of seeing everyone's email passwords, too. Maybe they can be stored in plain text in the user's root at /.my.email.passwords (better yet, use /.my.3mai1.pa$$w0rds for security). I'll get the feature request submitted. You're welcome. - Scott
Why waste the developers time making this a feature request - its already a feature ( sic) The information available is already all that is required to access the email accounts, change passwords or indeed just use the default email account straight out of the tin.0 -
I'm deleting the my.cnf files every day via cron - but that's obviously not an adequate resolution. In the last ten years of using cPanel, I've not seen such a glaringly stupid oversight as this. What an embarrassing mistake. It makes them look like amateurs. Seemingly no idea about security whatsoever. I'm also astounded that they haven't fixed it yet. I'm honestly looking at alternatives to cpanel now. If this doesn't get resolved soon - cpanel will lose a long standing customer. Very disappointed. 0 -
[quote="4u123, post: 1787612">I'm deleting the my.cnf files every day via cron - but that's obviously not an adequate resolution. In the last ten years of using cPanel, I've not seen such a glaringly stupid oversight as this. What an embarrassing mistake. It makes them look like amateurs. Seemingly no idea about security whatsoever. I'm also astounded that they haven't fixed it yet. I'm honestly looking at alternatives to cpanel now. If this doesn't get resolved soon - cpanel will lose a long standing customer. Very disappointed.
This was fixed in 11.46; the .my.cnf files are no longer created. Also, upgrading to 11.46 will remove the files if the users have not put custom options in them. I agree this was a serious issue, I'm just glad that I never saw any script kiddies try to LFI it. Things could have gotten really bad.0 -
[quote="quizknows, post: 1787622">This was fixed in 11.46; the .my.cnf files are no longer created. Also, upgrading to 11.46 will remove the files if the users have not put custom options in them. I agree this was a serious issue, I'm just glad that I never saw any script kiddies try to LFI it. Things could have gotten really bad.
Good news, thanks for letting me know. This has really made me lose confidence in cpanel. If they don't understand the implications of doing something like this - and not one person in their company flags it up as a security flaw before it is implemented, it shows an astounding ignorance of security that could put my customers at serious risk again in the future. On top of this, cpanel make the mistake of being nonchalant about it. To think I'd be required to submit a feature request to prompt them to address an obvious security issue just makes it worse.0
Please sign in to leave a comment.
Comments
21 comments