[+] 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