Best approach for targeting weak email pws

[net123]

May be too delicate for open discussion (please pm me) but we'd love to know if any of you found solutions to weak email passwords? We spend way to much time tracking down and changing pws after the fact. At the same time I really don't want to force new pws on every single box and every single user - I'm not sure that wouldn't be worse for us and our resellers, but maybe it's the only way.

Thx - Dave

 

[net123]

Just curious... new here, perhaps that's why there are no responses yet? I would have thought this would be a very hot topic for every cpanel user. Perhaps I am late to the discussion or... early? I have searched these forums for clues on this topic - I started with 2 factor verification hoping we could implement that as Google has with gmail (which I use but I'm not sure that our clients would warm up to it).
Anyway, any tips on the state of this topic or feedback, always appreciated.

Dave

 

[Infopro]

At the same time I really don't want to force new pws on every single box and every single user - I'm not sure that wouldn't be worse for us and our resellers, but maybe it's the only way.

Starting off with a good plan is the best way to go, I think.
Password Strength Configuration - cPanel Documentation

But, thats not always possible. In those cases, force new passwords on just those you have concerns about. You don't have to select all users, AFAIK.
Force Password Change - cPanel Documentation

As far as Two Factor Authentication, please review this Feature Request located here:
Two-factor Authentication - cPanel Feature Requests

Hope that helps.

 

[net123]

Thanks, we appreciate your response - we have seen those tips btw and read the docs, and they look promising but they inspire plenty of questions as well, like:

Would invoking stronger passwords be only for new pws - new ones created going forward? Or would it cause current weak ones to have to be updated, specifically weak email pws?

For the amount of time we spend chasing after spammers because of users who have "bob123" as an email pw we would seriously consider mandating ALL email and cpanel access pws be changed. But we obviously want to do it in the most user friendly way possible (it's a pretty unfriendly thing to begin with but not doing it is even less friendly). So if we could mandate new passwords for email, how would that work? Would clients get a warning screen or some other "you must first update your password..." notice?
My understanding is that when cpanel pws are mandated a user can log in to a limited cpanel and MUST then update their pw to a better one before getting access to the entire feature set. Does email work in a similar way?

Yes! I did vote for the 2-factor auth new feature. My only change to Google's implementation would be to have it last for longer than 30 days.

Again, appreciate your suggestions. This feels like the most urgent of all issues we face as a host, especially since it effects every client we have.

 

[net123]

Thanks for the reply Infopro! Yes, we have seen and reviewed those docs - we also voted for the 2 Factor Auth feature, we're definitely ready.

A while ago we upped our password strength as recommended, but that does not address the 90% of our client base, current clients with weak passwords. When we request all users update their pws, typically it's the users with weak passwords that don't follow our suggestion!

We spend so much time tracking hacked email accounts now because of weak pws, that we are in fact considering changing all email and cpanel pws. My question about that is: what does it look like from the client side? I know that requiring an update to a cpanel pw, the client can log in with the old one and only get a limited access to the cpanel and they are directed to update their pw first before getting complete access. IF email worked the same way we'd jump at that - if a user was somehow prompted to change their email in order to get their mail and not just getting a pw error, that would be amazing. But I don't think it works that way, correct?

 

[Infopro]

If you don't have one already, create a test account for testing and force that user to update their password. Some testing on your part will go a long way in understanding the limits of what you can and cannot do, and how things work.

 

[net123]

Thanks for the tip, certainly, we'll do testing, just thought this was something everyone had need for so some kind of standardization was already in place.

 

[net123]

I also noticed that none of these options change any of the client email passwords (not talking webmail), or am I missing something? Is there an option for force changing those?

 

[mtindor]

We spend so much time tracking hacked email accounts now because of weak pws, that we are in fact considering changing all email and cpanel pws.

Although I agree that weak passwords should not be used/tolerated, and that it is extremely difficult to get those who use weak passwords to change them, I think everyone should keep in mind that all email hijackings aren't due to weak passwords.

I know that in the past month or so there has been some sort of client-side vulnerability being exploited that then installs a trojan/malware that either sniffs the email credentials or logs keystrokes and obtains email login credentials. I've seen this across mail platforms (cPanel / Smartermail / Mdaemon / Imail). I've seen quite a few breached accounts, and in quite a few of the cases the new secure passwords were obtained within two hours of them being changed on the server. That tells me that the passwords are being discovered on the client side. And, in many cases the original passwords were not weak to begin with. After having seen enough of these instances, I insisted that the clients run AV scans of their system using multiple scanners and some sort of malware scanner like MalwareBytes, and in every case they notified me that one or more trojans had been found on the infected systems. In particular, these were the Canadian pharma spammers.

Typically one IP address would connect to the server to verify that the credentials were valid. That IP would never actually relay spam. Within an hour or so, IPs from all over the world would start connecting and relaying spam [at low volumes per IP usually], indicating that it was also botnet controlled.

Granted, this is a specific type of spam I'm referring to -- Canadian pharma spam via hijacked email smtp auth credentials and using an otherwise legitimate mailserver for relay.

So I at this point I would always suggest/insist that the customer run a full virus scan with one or more reputatable AV packages, after having turned off System Restore and booted to Safe Mode [windows, obviously] and to also run MalwareBytes or some other effective malware scanner.

At least that has been my experience.

Keep in mind, that a lot of server admins use something like CSF to block too many failed auth attempts. If you are restrictive [only allow a low number of failed auth attempts] before temporarily blocking POP3/smtp auth brute forcing, it is highly unlikely that somebody is going to brute force any but the weakest and most common of passwords. Granted, there are a lot of people out there using assisine weak passwords. But there are many more email accounts hijacked that aren't weak and weren't brute forced, leaving a client-side infection as the likely culprit of the email credential leakage.

M

 

[net123]

mtindor - thank you so much for the reply and info. I am both encouraged and discouraged by your answer - it seems that there's nothing to it other than to keep shoveling as fast as we can. But - best not to inconvenience any/all clients with an unnecessary change to their service and hours of work on our end if it's not the fix we need.
I wish someone would come up with a way so that only the client can send email from their boxes, like an ip verification - I suppose that could be cracked too though.

Thanks again,
Dave

 

[mtindor]

mtindor - thank you so much for the reply and info. I am both encouraged and discouraged by your answer - it seems that there's nothing to it other than to keep shoveling as fast as we can. But - best not to inconvenience any/all clients with an unnecessary change to their service and hours of work on our end if it's not the fix we need.
I wish someone would come up with a way so that only the client can send email from their boxes, like an ip verification - I suppose that could be cracked too though.

Thanks again,
Dave

Dave,

I'm not sure which is worse -- (a) weak password brute forced and used to auth/relay spam or (b) customer machine infected with trojan that in one way or another steals auth which is then used to relay spam.

If it's a weak password, in my mind it's so simple to at that point change the password and make sure the customer no longer has the opportunity to use weak passwords. If it's a compromised machine, you only know that if the customer tells you. If you have a "vibe" that the customer machine is infected, it's not an easy task to convince them. In my experience, customers are very put off when I even remotely suggest that their may a virus/trojan/malware on their computer. Fortunately, recently I've had some sucess in getting them to properly scan their systems and most have them have discovered infections.

Do keep in mind that you can impose a stronger password strength from here foreword without forcing all existing customers to change their password. Then, if they need to change their password on their own, they are suddenly forced to meet a minimum security. Or if their account gets hijacked and you change the password, you can just explain to them then that they need to use strong passwords.

When the option to set a password strength for email (via WHM) became available, I simply set the password strength high. It didn't stop current weak passwords from logging in. It simply stops anyone from setting a new password that is weak. So your existing clients with weak [but non hijacked] passwords continue on without skipping a beat.

So I'd suggest that you set the password strength for email to something significantly higher, and then don't even tell your customers. If they try to change their password, they'll learn quickly enough that it must meet a certain minimum strength requirement. If they currently have a weak password and their account gets breached, you can simply explain to them at that time that the system automatically enforces a requirement for a strong password.

I wish I had an idea for some alternate method of providing additional authentication for SMTP authentication, but in general I think we're all stuck (on any mailserver) with the method we have now.

Mike

 

[alphawolf50]

Here's some info I put together regarding finding and strengthening the passwords on your system:

Finding Weak Passwords (The Easiest Method):

Log in to SSH as root and run this:

find /home/ -type f -wholename '*pwcache/*' -exec grep -Hi strength {} \; | awk -F ':' '{print $NF,$0}' | sort -n

That will show you the strength of many (but not necessarily all) email passwords on the system, sorted by by the strength as determined by cPanel. The output will look something like this:

60 /home/user1/etc/[I]example.com[/I]/@pwcache/[I]info[/I]:strength:60
82 /home/user2/etc/[I]example.com[/I]/@pwcache/[I]postmaster[/I]:strength:82
82 /home/user3/etc/[I]example.com[/I]/@pwcache/[I]postmaster[/I]:strength:82
86 /home/user4/etc/[I]example.com[/I]/@pwcache/[I]orders[/I]:strength:86

The first (and last) numbers are the strength of the password. Near the end, you'll find the local part of the email address (i.e. [email protected]), and somewhere near the middle you'll see the domain. Users with very weak passwords should be forced to change their password. Before you force anyone to change their passwords, make sure you've read the section at the bottom titled "Upgrade Your Hashing Algorithm".

Testing Account Passwords:

If you really want to find the weak passwords, round up all the shadow files and run them through "John the Ripper" with the rockyou.txt wordlist. That's Script Kiddie 101, so anything that fails here is dangerously weak. I won't go through how to use "john" (there are plenty of guides), but to collect the contents of all shadow files in one go, use:

find /home/ /etc/ -type f -name 'shadow' -exec grep '\$' {} \; | sort | uniq > allshadow.txt

Everything will now be in the file "allshadow.txt". Run john on that file, and any accounts that are cracked should be asked to change their passwords. There are many password lists to test against, (rockyou.txt possibly being the most comprehensive), so try a few. It would be a good idea to cross-reference the output obtained from "The easiest method" above, and see what strength of passwords you are able to crack. Set your minimum password strength above this number. Before you force anyone to change their passwords, read the next section...

"Upgrade" Your Hashing Algorithm:

This section perhaps should have come first, but since it would have slowed down the password cracking in "Testing Account Passwords", I saved it for last. Slowing down password cracking is of course the reason you want to do this

If you're running CentOS/RHEL 5, chances are your passwords are hashed with md5. As of cPanel 11.34, cPanel supports sha512 for password hashes. Once you've increased the minimum password strength to prevent new bad passwords, it would be a good idea to "upgrade" the password hashing algorithm to sha512. First, check which algorithm you're using by running this as root in SSH:

authconfig --test | grep hash

If it says you're using md5, run the following to switch to sha512:

authconfig --passalgo=sha512 --update

Now, all new passwords will be hashed with sha512. Users with weak passwords should now be asked to change their passwords.

I hope this helps!

 

[net123]

Mike - Thx again. We did impose the stronger password requirements for just the scenario you described - once a client tries to update or change their current pw they will have to comply with the new restrictions. We also sent out a "Best Practices" newsletter - again - and so I'm hopeful that we are making progress.

- - - Updated - - -


Thanks a ton Alpha - great read. I wonder - is there any concern if we switch to sha512 that it could be over written by future cpanel upgrades?

 

[alphawolf50]

Hi Dave,

I don't think there is any risk of cPanel changing the hash algorithm back to something weaker in the future. As of 11.34, it just uses whatever algorithm you've configured for the whole system (which is what the "authconfig" command did). Source:

http://forums.cpanel.net/f185/does-...2-password-encryption-301642.html#post1254151

 

[bhd]

....tracking down and changing pws after the fact. ...

I got really tired of it too! so I wrote my own script:

1. it checks* all cPanel password
2. All mail passwords
3. all FTP passwords
4. (still need to add some other stuff when I figure out how

* "Checks" means challenge against a password list. Presently it can do MD5 hash, SHA512 and old school "Crypt".

For those who don't know, cPanel (Linux actually) "salts" all password these days so rainbow tables or anything like that won't work: one needs to take the salt and then attack the hash (using the salt) with a plain-text list of passwords; this is what we've done. It's slow and runs for hours (with a password list of say 10,000) and it uses 100% of one CPU core.....

If you have a 4 core CPU with threading, it's perfectly safe to use. DO NOT attempt to run this perl script on a single or dual core machine that does not have threading!!

I'll subscribe to this thread, and if anyone is interested, I'll give you the link to to the code. (Please note, I'll NOT give the code to a new member of cPanel forums with 3 posts as this code can be used for really bad things!).

On our own servers, I have it in crontab on our servers and it runs starting on Saturday (and ends sometime Sunday) and sends an email summary of weak passwords it found. The first time I ran it (especially on old accounts with Crypt and MD5 hashes, I nearly passed out! Half of then were "password" or "blessing" or "Access" ... really scary!!).

Every week, I upload a different plain-text password list, "just to see"; and every week, I'm shocked by what I find!

It's a single perl file (so far) that you put into /etc/wpwd/wpwd + a file called passwords.DAT (which is a plain-text list of passwords)

If there is interest, let me know

 

[cPanelMichael]

You can set a password age for cPanel, webmail, and WHM users. However, this will only force a user to change their password upon accessing those interfaces. It does not actually disable the login, so an email account would still function via an email client. There are currently no native options that will disable access until an email account user changes their password. You are welcome to submit a feature request for this at:

Submit A Feature Request

Thank you.