Skip to main content

Spammers Hijacking Email Accounts

Comments

31 comments

  • robb3369
    We've definitely noticed a distinct uptick in the number of failed smtp auth attempts across several of our managed servers including cpanel...
    0
  • dalem
    this is not new but there has been a definite upswing in the amount of disturbed attacks the last couple of weeks
    0
  • kernow
    [quote="dolphyn, post: 1579261"> The spammers have consistently used "mycomputer" as the HELO or EHLO name,.
    Yep, been seeing that also :(
    0
  • cPanelMichael
    [quote="dolphyn, post: 1579261">The spammers have consistently used "mycomputer" as the HELO or EHLO name, so currently it's pretty easy to see if you've been affected.
    The following options under "ACL Options" in "WHM Home " Service Configuration " Exim Configuration Manager" might help to block those emails: "Require RFC-compliant HELO" Thank you.
    0
  • kernow
    The default for that option is already "on"
    0
  • talk2prakash
    Check whether smtp restriction is on in your whm. Also check the emails in the queue to determine the source of the spam. Whether the spam is sent from the website script or from outlook express etc using email headers...
    0
  • acenetgeorge
    We're seeing the same thing, and they are direct email logins. So somehow the email passwords were compromised. Maybe a Distributed brute force of the passwords. We see those every once in a while. We are using the following command to pull out the compromised email addresses, and are randomizing the passwords. We then notify the client to login to cPanel and reset the passwords, but use more secure (and unique) passwords. grep mycomputer /var/log/exim* | grep 'A=courier_' | awk -F'courier_' '{print $2}' | awk '{print $1 " " $3}' | awk -F':' '{print $2}'
    Not the prettiest code, but it works.
    0
  • chrisbuk
    Anyone spoke to CPanel support about this?
    0
  • nxds
    Seeing this too on 3 different cPanel servers. It's quite alarming how many accounts have been compromised. Any ideas how they've done this? This code will get a list of compromised addresses: sed -n 's/^.*H=(mycomputer).*P=esmtpa A=courier_plain:\(.*\) S=.*$/\1/p' /var/log/exim_mainlog | sort | uniq
    And this will get a list of IP addresses that you can append to csf.deny (e.g. by adding >> /etc/csf/csf.deny to the end of this command): sed -n 's/^.*(mycomputer) \[\(.*\)\].*P=esmtpa.*$/\1 # do not delete/p' /var/log/exim_mainlog | sort | uniq
    0
  • serichards
    Most likely is weak and guessable passwords or using non encrypted means to send login credentials. An SSL vulnerability has been published recently that is in macosx and ios. Latter has been patched. [url=http://www.theregister.co.uk/2014/02/23/apple_mac_os_x_10_9_ssl_fix/]Apple Safari, Mail and more hit by SSL spying bug on OS X, fix 'soon' This would allow decrypting of SSL data so passwords could be stolen if the person were using public wifi.
    0
  • mtindor
    That subject line is misleading. There is no cPanel exploit causing this to happen. This is happening across all mail platforms. Passwords are being stolen either via brute force (weak passwords), viruses on client computers (more often than you think) or by data leakage. For the latter, think about this -- a person re-uses their email password as the password for logging into various websites [ex: Adobe]. Email credentials are leaked via a website breach and people attempt to use those passwords against your other accounts, which is successful if you re-use your passwords all over the place. Add to that the ability to leverage a botnet to slowly [sometimes] and methodically brute force POP3 / SMTP Auth and then send out low-volume spam from each hijacked account in an attempt to stay under the radar. Rarely do I see a single email account get hijacked and then a single IP used to send a massive amount of spam anymore. Instead, I see multiple email accounts breached [ahead of time] and then a botnet of random remote IP addresses authenticating with those credentials and relaying low-volume, non-constant spam. One spammer sending 6,000 spam from one account gets noticed pretty quickly. One spammer, sending 30-60 emails from 100 hijacked accounts is much more successful. These incidents don't usually happenly constantly throughout the year. You'll notice lulls in this activity. The people doing it are busy collecting SMTP auth credentials from hijacked accounts. When they have enough stored up, then they pull the trigger and let loose. Then, suddenly out of nowhere, everyone starts reporting that email accounts are hijacked on their cPanel / Smartermail / Mailenable / Imail / Merak / Mdaemon / etc servers and think it's an exploit against the server. I firmly believe [as has been the case for at least the 1+ years that we've seen this activity] that it's simply a case where clients (your customers and my customers) can't manage to (a) use secure passwords, (b) not get viruses, (c) not re-use passwords across accounts. Your / my clients are directly responsible for the vast majority of this. M
    0
  • sparek-3
    [quote="mtindor, post: 1581401">I firmly believe [as has been the case for at least the 1+ years that we've seen this activity] that it's simply a case where clients (your customers and my customers) can't manage to (a) use secure passwords, (b) not get viruses, (c) not re-use passwords across accounts. Your / my clients are directly responsible for the vast majority of this.
    Well said. I initially thought this might be some kind of server-side exploit because I was seeing a larger than normal number of hijacked accounts. But I also wasn't seeing the number of hijacked accounts that I would expect if it was a server-level exploit. I suppose the SSL vulnerability that was referenced earlier in this thread could be partly to blame. And that would put the blame more on the developers and vendors of that software than on the end-user. But there is also just a very, very vast misunderstanding by end-users when it comes to security. End-users are way too casual with their passwords and overall security. Until this is solved (and I don't know what the solution is) you're going to continue to see "exploits" like this happening.
    0
  • vanessa
    [quote="sparek-3, post: 1581641">I suppose the SSL vulnerability that was referenced earlier in this thread could be partly to blame. And that would put the blame more on the developers and vendors of that software than on the end-user. But there is also just a very, very vast misunderstanding by end-users when it comes to security. End-users are way too casual with their passwords and overall security. Until this is solved (and I don't know what the solution is) you're going to continue to see "exploits" like this happening.
    I disagree with this. There really isn't a cure for stupidity. cPanel/Apache/whateverdevelopersyourereferringto can continue to make their products more and more secure, but when you expose these items to end users that do dumb things, you can't put the responsibility back on the vendors. cPanel does let you set password security thresholds on passwords your users choose, so perhaps consider that a step forward. This has happened on our servers countless times, and we by now have scripts that mass-change the affected email accounts and notify the customers. While this doesn't prevent what already happened, it at least helps ensure that those users are less likely have have the same problem again. You can also consider looking at outbound spam protection (also a feature you can enable through WHM) and creating custom SA rules to help minimize the impact the outgoing spam has on your entire server when these compromises occur.
    0
  • Infopro
    Thread title updated to be a bit more relevant.
    0
  • jols
    I've just made out a cpanel.net ticket for this one. There is definitely something usual going on with this. Here's what we have observed so far: The pattern has been consistent. 1-- The exim log always includes "(mycomputer)" 2-- The hosted email account apparent relaying the messages only contain "A=dovecot_plain:user@domain.com" rather than what we normally see, for example: "A=dovecot_login:user@domain.com" Note: "dovecot_plain" vs. "dovecot_login" 3-- The number of email addresses relayed in each burst, is usually about the same, 10 to 20 addresses (BCCed I believe). 4-- The originating IP addresses are nearly always from countries like Korea, Africa, Argentina, Ukraine, and so on, i.e. never from anywhere close to where the hosted customer does businesses. Right now I am looking for a way to drop any connection attempt to Exim, if "mycomputer" is in the incoming header. Anyone?
    0
  • jols
    As it turns out, the "dovecot_plain" aspect signify plain text logins. The upshot is, the email accounts in question, have simply had their passwords exploited. Now, thanks to a pointer I received just now I am attempting to implement the following in the Advanced Exim Configuration, in custom_begin_smtp_helo, but when I did this, the server started rejecting all email as invalid helo: deny condition = ${if match {$sender_helo_name}{mycomputer}} message = "Your server is spamming!" log_message = "Attempted spam message" Anyone know how this could be improved?
    0
  • jols
    Hmmm, so far I've tried all of these in custom_begin_smtp_helo, and we still get all email rejected for invalid HELO as a result: deny condition = ${if match {$sender_helo_name}{mycomputer}} drop condition = ${if eq{[mycomputer]}{$sender_helo_name}} drop message = Spam HELO: $sender_helo_name is suspicious log_message = Spam HELO: $sender_helo_name condition = ${if match{$sender_helo_name}\ {mycomputer}} Anyone have a clue as to how to make this work? TIA.
    0
  • serichards
    Why do you allow plaintext logins? First thing I blocked... There are a few settings to only allow secure logins so anyone using basic scripts would hopefully be stopped. It also reduces ability to sniff passwords. I also wonder whether only having smtp on a non standard port would also help?
    0
  • SageBrian
    So glad to see mtindor and sparek-3 state what I thought was obvious. Users are the weakest link. I've been getting these 'hacks', which are nothing but bots using known credentials. No guessing, no brute-force. Simple login and send. I've been catching them quickly, but the problem is all on the users. Even when they are told/taught/educated to update their passwords, and not use the same login info for every website, they continue to ignore. I've also been seeing direct access into cpanel. Just this weekend, I first got a spam from a webmaster of a client's website. It came from their account, so I just figured another victim of weak passwords. Then, later that day, the client's cpanel is accessed and a couple of sub-domains added. Next, phishing pages were created. I cannot be sure as I have no way of tracking, but my quess is that bots got the webmasters login for their email. Then, it might have quickly scanned their mail (Yahoo account, but it could be any mail service with stored messages). Looking for any messages that might have login info in it. The client's cpanel password was a random generated, 12 digit secure pw. That Adobe breach in September was HUGE, with a wealth of info for figuring out logins. And how many people do you think bothered to change their passwords even when told to?
    0
  • serichards
    [quote="jols, post: 1581951">Hmmm, so far I've tried all of these in custom_begin_smtp_helo, and we still get all email rejected for invalid HELO as a result: deny condition = ${if match {$sender_helo_name}{mycomputer}} drop condition = ${if eq{[mycomputer]}{$sender_helo_name}} drop message = Spam HELO: $sender_helo_name is suspicious log_message = Spam HELO: $sender_helo_name condition = ${if match{$sender_helo_name}\ {mycomputer}} Anyone have a clue as to how to make this work? TIA.
    There seems to be an issue with any condition put into the ACL within WHM. I had the same issue with it dropping all mail instead of just mail from certain addresses. It should work. It's not being evaluated properly. If you run exim with the -v option it should tell you what it is doing. I have a feeling one of the other settings you can enable achieves the same thing - the RFC compliant helo setting.
    0
  • alinford
    One thing that would help is if cPanel would add the option to force new password on next login for an email account, and also block all previously used passwords.
    0
  • vanessa
    [quote="alinford, post: 1583932">One thing that would help is if cPanel would add the option to force new password on next login for an email account, and also block all previously used passwords.
    On next login...to what? How many of your clients' mail users access cPanel or webmail on a regular basis to where such an effort would make a difference?
    0
  • alinford
    [quote="vanessa, post: 1583951">On next login...to what? How many of your clients' mail users access cPanel or webmail on a regular basis to where such an effort would make a difference?
    So, when we see an issue like this, we change the password to stop the exploit, and then contact the client. Problem is that the client may not be available when we contact them. Forcing a password update, and not allowing the use of previous passwords makes it so that the client does not go right back to using the same email password.
    0
  • Infopro
    [quote="alinford, post: 1583932">One thing that would help is if cPanel would add the option to force new password on next login for an email account, and also block all previously used passwords.
    You might be interested in signing on to this Feature Request: Email Security Policy - Force email password changes | cPanel Feature Requests
    0
  • alinford
    [quote="Infopro, post: 1584032">You might be interested in signing on to this Feature Request: Email Security Policy - Force email password changes | cPanel Feature Requests
    Mine is the first response in that thread.
    0
  • serichards
    Blocking people from their email when they need it seems like a good way of cheesing off clients to me. Just changing them and leaving the rest of the system insecure is hopeless as you'll annoy people with password changes and they'll still have their email account compromised. To me a two factor authentication method of some kind would be a better solution. When you login in from a new location or a new device, you may want different policies for pcs vs smartphones, it is blocked until you enter a particular passcode that is sent to their mobile. Then that means only that location can use it with that passcode. Anywhere else will prompt a passcode to be generated so you'd then know where someone is trying to hack it. Forcing password changes and locking people out of their email when they could need it will just annoy people unnecessarily.
    0
  • jols
    I agree with that emotion, that is, with the two factor auth. It has been employed for the on-line billing system we use, and I believe that ultimately this is the way to go. For now, we have applied the same exim log analysis scripts to "dovecot_plain" as we did for spotting "dovecot_login". This at least gives us some sort of a early warning system in this regard. Also, as for our customers keeping their accounts secure, they generally do an okay job. When they don't, we change their email account password, and then send them a report with a bunch of advice. A key component of that advice is to install an anti-key logger tool, i.e. the one that can be downloaded for free from qfxsoftware.com. IMHO, everyone with a Windows machine should have this one installed. As for forcing members to use SSL logins. Yeah, well, I'm not sure why but iPhones almost never work in my experience when using SSL/TLS. Also, correct me if I'm wrong, but the only place SSL offers any protection at all is when using a public WiFi connection. In all other cases for mobile devices using carriers such as Verizon, AT&T, etc. the connections, and the entire transmission uses spread spectrum technology that truly encrypts everything from A to Z, that is, unless someone has escalated privileges within the interior one of Verizon's NOCs (of course.) And even if you are using SSL/TLS with your iPad at the airport, and someone spoofs the connection point with their laptop for example, then, while they can't get your password, they can certainly sang the body copy and most of the rest of the header, right? My understanding is that SSL/TLS only encrypts a small part of the header that contains the log in credentials, and that's it. For complete end-to-end email encryption, both the sender and the receiver would need to use a PGP/GPG key pair. Right? So, you help someone reset their account password, then send it to them via email. And they (somewhat stupidly) reply with a "thanks," leaving the credentials in the email body.... then bang-o! There goes the password, even if they are using SSL/TLS.
    0
  • serichards
    I use SSL with ios. It does work but needs a kick in the pants to make it work. There seems to be some issue with certain imap settings, imap server types. It dislikes courier. I could never make it work with that. Switched to dovecot and it behaved. I'd have hoped man in the middle attacks would be prevented. It's depressing if email client and email server writers can't manage that. Those attacks are old as anything. I don't know exactly which bits are encrypted. I should investigate. Complete pgp encryption sounds good. Would stop all kinds of snoopers as well as your normal hackers. I wouldn't send new passwords out via email either for that very reason unless you can make the message self destruct ;)
    0
  • jols
    PGP encryption requires that both parties, the sender and the receiver, have the same matched pair of encryption keys installed within each respective email client. This is of course highly impracticable for regular email use.
    0
  • serichards
    [quote="jols, post: 1584211">PGP encryption requires that both parties, the sender and the receiver, have the same matched pair of encryption keys installed within each respective email client. This is of course highly impracticable for regular email use.
    Maybe not such a good idea then!
    0

Please sign in to leave a comment.