lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date: Tue, 22 Apr 2014 12:39:07 +0200
From: Tim Rots <>
Subject: [FD] Parallels Plesk Panel 12.x & 11.x /etc/psa/private/secret_key

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:

 31 if ($failureRedirectUrl = get_gpc('failure_redirect_url')) {
 36     hspc_setopt('failure_redirect_url', $failureRedirectUrl);
>37     hspc_setopt('failure_redirect_url_sign', md5($failureRedirectUrl .
 38 }

363     final public static function getCryptKey() {
369             if (Os::UNIX) {
370                 self::$_cryptKey = @file_get_contents(ENCRYPT_KEY_FILE);
380         return self::$_cryptKey;
381     }

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
- script sets two cookies which contains the following values:
failure_redirect_url = $failureRedirectUrl (supplied in URL)
failure_redirect_url_sign = md5($failureRedirectUrl + contents

[+] Annoying redirect loop if localhost is specified as url to to redirect
to when login fails until cookies are cleared.

root@...ian7:~# #see /usr/local/psa/admin/sbin/encrypt_keygen for details
on key generation routine
root@...ian7:~# dd if=/dev/urandom of=/etc/psa/private/secret_key bs=16
1+0 records in
1+0 records out
16 bytes (16 B) copied, 0.000183366 s, 87.3 kB/s

root@...ian7:~# hexdump -C /etc/psa/private/secret_key
00000000  99 51 17 9a c6 8c 6e bd  4a 75 98 73 e2 64 fa e4

$ curl -k -i -s "
'/fail/ {print $2}'

root@...ian7:~# ./
#! /usr/bin/env python

import hashlib
import binascii

with open('/etc/psa/private/secret_key') as f:
whoops = hashlib.md5("w00t" +
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
I'm glad nobody owns the amount of computing power which is required to
abuse this bug nowadays anyhow .. :']


Tim Rots

The Netherlands

Sent through the Full Disclosure mailing list
Web Archives & RSS:

Powered by blists - more mailing lists