eMail Short Name Security Hole in Plesk 8.6

[robharris]

There is a security hole in Plesk 8.4 and 8.6, which allows email accounts to be highjacked by spammers.

Our servers are maintained by RackSpace. The RackSpace engineers have been working on this for weeks in an attempt to identify the source of spam and phishing messages, which are sent through highjacked email accounts. At first they said that the source domain of the spam could not be identified due to a bug in Plesk 8.4 server logs so we updated to 8.6. (As usual there was an issue with security certificates, which had to be fixed manually at root level, but the update bugs are another issue, which I am sure you are tired of hearing about:-(

After updating to 8.6, the trouble still occured and we still could not identify the source domain. From time to time a spammer gains access and sends thousands of phishing messages. Eventually the server mail queue fills up with undeliverables and the mail server slows down or stops working until the mail queue is emptied manually. Left unchecked, the server becomes blacklisted and then legitimate email is blocked.

RackSpace spent many hours searching for a solution. They reported back to us that Plesk was no help to them. I am not surprised at all considering how many complaints you receive on a regular basis and how many bugs seem to be ignored for long periods of time. Finally we found that we are not the only ones having this trouble and we have confirmed that this is a security bug in Plesk. I could not find a thread for this bug in the Plesk forum, however it appears that someone else has already reported this bug and nothing has been done about it yet. Here is the site where the bug is reported. http://seclists.org/bugtraq/2008/Sep/0001.html

A quick fix for this bug is to change Plesk settings to require long email usernames. If Plesk support does not address this issue soon, we will change the setting and ask our hundreds of hosted clients to change all of their usernames from short to long. I am hoping to avoid this major inconvenience for our hosted clients.

Please respond asap to let us know if you are working on this bug and how long it might take to fix it!

Rob Harris
http://ashopwebhosting.com

 

[ehabheikal]

me too

I have this same problem. I debugged it myself extensively before seeing this thread. This is terrible, has it been fixed in updates?

 

[Ragefast]

As far as I know, that (null) bug in qmail log was fixed in 8.6 yes (It fixed for me).

If you still get those null messages, you could try reinstalling psa-qmail rpm with the --force option. (I don't know the equivalent for debian).

If after that you 'still' get the null sender in smtp_auth lines, then I'd suggest you installing spamdyke, which will be able to tell you which local users are sending messages thru the server.

 

[ashopandreas]

Ragefast, this is not the same bug. The null user name problem does appear to have been fixed but this is something completely different. When short names are allowed in Plesk a hacker only needs to guess a valid password (such as "password" which too many stupid clients seem to use unfortunately) to login as any user of his choice (he can make one up) and send spam. Please read the thread before replying.

 

[Ragefast]

@ashopandreas

Sorry. Maybe I really misunderstood his problem.

@robharris

Really, now I think I get it. your problem is that some spammer is sending messages thru your server using an authenticated account, where because Plesk is using short name, you can't identify from which domain that account is part, is that right?

Well, that is in no way Plesk's fault, much less a security hole, but your customer's fault for using such weak passwords. Plesk even does offer you an alternative (long mailnames) which obviously is (almost) impossible to use once you have your big user database up and running. And don't forget you also have dictionary-based check for passwords as yet another alternative.

Is the spammer using TLS for sending the messages? If not, you can easily find out which account he is using with help of a tool like ngrep:

ngrep host <ip_spammer> port 25

And then base64 decoding the user and password.

If he is using TLS, you can install spamdyke as a middleman, which will do the TLS talk with the spammer, while logging the account. In any case, you get the (short) account name.

Now to find which domain that account is part of. Here is a good thread with nice sql scripts for searching Plesk's database for that exploited user:
http://forum.swsoft.com/showthread.php?t=55143

I hope this time I am able to help you.

 

[ashopandreas]

No, the problem is NOT that the spammer is using an authenticated account and that we can't identify which one it is. The problem is that the spammer can invent his own username, as long as he can guess one password on the server. In other words: the username can't be identified at all since it simply doesn't exist on the server. A weak password is obviously much weaker if you only need to know the password itself, not the username it belongs to. In any case, this should clearly not be possible and is certainly a security issue.

 

[Ragefast]

ashopandreas, I'm sorry, but theres *NO* password without a valid user. The spammer may fake the sender's address, but thats as far as it goes, the smtp authentication still *MUST* be made with a valid user.

And even if that really IS what happens in your case, that would be an isolate problem in your box, not a security flaw in Plesk's authentication system (at least until someone is able to reproduce it).

Please try what I described above.

 

[ashopandreas]

Well, there is the vulnerability report: http://seclists.org/bugtraq/2008/Sep/0001.html, which you should have read btw, that even tells you how to reproduce the problem and then there is one other person, besides us, in this thread with the same trouble. Three different sources reporting the same issue, one even showing how to reproduce it, how can you call this an "isolate problem"? Please stay out of this thread and let someone with a solution to this problem answer instead. What is the point in arguing against this? Do you want Parallels to ignore this trouble?

 

[Ragefast]

No, the point where I'm discussing this is because I took my time to try and help you, even installing a fresh Plesk 8.6.0 to test that (because obviously, I also have various production Plesk servers, and if that were true, I'm also in the same boat), but all the steps I've taken to try and reproduce it failed miserably, showing me Plesk 8.6 is working the way it should be, on all my production and testing servers.

And as a matter of fact, we still don't know what kind os tests you have done already, since you haven't provided much information aside the issue itself, and rejected any attempt for me to clarify that.

But enough, do as you please.

 

[ehabheikal]

I have spamdyke installed, how do I know through it which users sent the emails?

 

[ehabheikal]

As far as I can tell the issue is MUCH worse than just sending emails by knowing any password. Such an authentication can also pull random emails if it uses pop3.

 

[Ragefast]

I have spamdyke installed, how do I know through it which users sent the emails?

In you maillog (usually /usr/local/psa/var/log/maillog) you'll see lines like this:

(if the client is using full name)
Sep 18 06:28:02 server spamdyke[23191]: ALLOWED from: [email protected] to: [email protected] origin_ip: 123.456.789.123 origin_rdns: 123-456.clientip.com auth: [email protected]

(if the client is using short name)
Sep 18 06:28:02 server spamdyke[23191]: ALLOWED from: [email protected] to: [email protected] origin_ip: 123.456.789.123 origin_rdns: 123-456.clientip.com auth: sender

 

[faris]

I've tried to reproduce this on one of our machines but have failed. It is a very old machine that's been upgraded many times so it has lots of things that could have got munged on the way. It has also used shortnames right from the start (we are about to rectify this!).

No matter what I do, though, I've not been able to reproduce the problem.

This is not to say it isn't a real problem. Could it be down to a particular combination of past Plesk upgrades or something like that? Or the version of Plesk for a particular OS?


Faris.

 

[atomicturtle]

I haven't been able to reproduce this on 8.6 either (CentOS 4 and CentOS5) has anyone else?

 

[Felix Buenemann]

I have reported the bug on bugtraq and doing some quick testing it seems to be indeed dependant on the host OS.
Both hosts on which I were able to reproduce the bug were running openSUSE 10.3 x86_64. I just tested the bug on a Debian Etch 4.0 system and it was not vulnerable.

Note that my main server that was affected is currently running patched plesk authentication modules for QMail (SMTP) and Courier-IMAP (POP3/IMAP) that were provided to me by a plesk developer. Using those patched auth modules the server is no longer vulnerable.

If your server is affected you might get fixed binaries for smtp_auth (qmail) and authpsa (courier-imap) by filing a support request with parallels and specifying your exact OS name, release and platform (eg. openSUSE 10.3 x86_64 or Debian Etch 4.0 x86) aswell as the version of Plesk you are running and a link to the bugtraq issue.

 

[phaetons]

I had the same issue on Plesk 8.6. and SuSE-OS.
Deactivating short names stops the spam.

best regards

 

[chileno]

what is the final solution? i have centos 4.7 / plesk 8.6 = too many spam

 

[nandar]

We had the same problem recently (with plesk 8.6.5) and it fixed after we changed Plesk settings to require long email username.