[+] Humhub insecure password validation and reset design [+] Discovered by: Jos Wetzels [+] Affects: Humhub <= 0.10.0-rc.1 Humhub [1] versions 0.10.0-rc.1 and prior suffer from several design flaws, which have now been resolved in cooperation with the vendor [2], in the implementation of its password reset and validation functionality. 1. Insecure password validation The validatePassword() function located in '/protected/modules_core/user/models/UserPassword.php' is vulnerable to a so-called a so-called 'type juggeling' attack [3,4,5]: if ($this->password == $this->hashPassword($password)) Here a hash of the user-supplied password gets compared to the stored hash in an insecure manner, since PHP's loose type comparison operators compare only data values but not their associated types, deriving variable types from context. PHP's string conversion rules [6] specify strings (when evaluated in a numeric context) with leading decimal, hexadecimal, infinity, NAN or radix (a '.') data optionally followed by an exponent are evaluated as floats. What this means is that a string like 00e13242 is cast to 0 and as such, to PHP 0e94323 == 00e19384. When given two different passwords, with different hashes, such as: $a = md5('240610708'); // = 0e462097431906509019562988736854 $b = md5('QNKCDZO'); // = 0e830400451993494058024219903391 They are considered identical when compared in the following manner: var_dump($a == $b); This allows an attacker to easily build a dictionary of passwords whose hashes result in float type conversions to greatly reduce their bruteforce keyspace against stored hashed passwords of the format 0+[eE]\d+. In addition, Humhub versions 0.10.0-rc.1 and prior allow users to directly reset the password of any account without any verification (see 2.). An attacker can thus send a large number of password reset requests for any account until the resulting, randomly generated, hashed password is of the format 0+[eE]\d+ and is thus covered by the dictionary. 2. Insecure password reset design The setRandomPassword() function located in '/protected/modules_core/user/models/UserPassword.php' suffers from the following flaws: - Password reset functionality is unauthorized allowing anyone to reset the password of any humhub user, provided they know their e-mail address. - Generated passwords are limited to a lowercase alphanumeric plus $-sign charset and passwords have a static length of 7. - PRNG seed entropy (and thus the possible reset password keyspace) is limited to at most 9^6 since the 8-digit precision microseconds in microtime are limited to 9 characters and multiplication by 1000000 results in a 6-digit number. - Passwords are generated using a non-cryptographically secure PRNG seeded in an insecure manner, making it vulnerable to a so-called Adversarial Time Synchronization (ATS) attack [7]. Since reset passwords are generated using PHP's rand() PRNG, seeded by the microtime() function, an attacker can send reset request pairs until the Date field in the server's HTTP response between both requests differs by 1, indicating a second has passed between the first and the second request. This means the clock microseconds have been zeroed between both requests and the value returned by microtime() (from which the reset password is derived) is below an upper limit determined by the average RTT of the reset request, thus greatly reducing the reset password keyspace and making quick bruteforce attacks feasible. Using the Snowflake framework by Argyros et al. [8], a more accurate attack could potentially be developed. [*] References: 1. http://humhub.org 2. https://github.com/humhub/humhub/releases/tag/v0.10.0 3. http://phpsadness.com/sad/47 4. http://turbochaos.blogspot.nl/2013/08/exploiting-exotic-bugs-php-type-juggling.html 5. http://en.securitylab.ru/lab/PT-2012-29 6. http://php.net/manual/en/language.types.string.php#language.types.string.conversion 7. http://crypto.di.uoa.gr/CRYPTO.SEC/Randomness_Attacks_files/paper.pdf 8. https://github.com/GeorgeArgyros/Snowflake