Re: The OAuth2 Complete plugin for WordPress uses a pseudorandom number generator which is non-cryptographically secure (WordPress plugin)

[Scott Arciszewski <scott () arciszewski me>]

On Wed, Aug 12, 2015 at 9:48 AM, dxw Security <security () dxw com> wrote:
> Details
> ================
> Software: OAuth2 Complete For WordPress
> Version: 3.1.3
> Homepage: http://wordpress.org/plugins/oauth2-provider/
> Advisory report: 
> https://security.dxw.com/advisories/the-oauth2-complete-plugin-for-wordpress-uses-a-pseudorandom-number-generator-which-is-non-cryptographically-secure/
> CVE: Awaiting assignment
> CVSS: 10 (High; AV:N/AC:L/Au:N/C:C/I:C/A:C)
>
> Description
> ================
> The OAuth2 Complete plugin for WordPress uses a pseudorandom number generator which is non-cryptographically secure
>
> Vulnerability
> ================
> The following refer to the generateAccessToken() function in library/OAuth2/ResponseType/AccessToken.php, and the 
> generateAuthorizationCode() function in library/OAuth2/ResponseType/AuthorizationCode.php.
>
> These functions attempt to generate secure auth tokens, but do not use the WordPress random number generator. Instead 
> they use a series of fallback calculations depending on which PHP version is being used. Some of these calculations 
> are not crypographically secure:
> The first is mcrypt_create_iv(100, MCRYPT_DEV_URANDOM). MCRYPT_DEV_URANDOM is expected to change to a different 
> random value whenever it is called, but on Windows, on older versions of php it is known to be a constant value
> if no other functions (e.g. /dev/urandom) are available then the access token is generated solely using mt_rand(), 
> microtime(), and uniqid().
> mt_rand() (Mersenne twister) is not a cryptographically secure pseudorandom number generator.
> According to the documentation mt_rand() is also biassed towards even return values in some circumstances.
> According to the documentation uniqid() is as secure a PRNG as microtime().
>
>
> Proof of concept
> ================
> See the documentation:
> http://www.php.net/manual/en/function.uniqid.php
> http://www.php.net/manual/en/function.mt-rand.php
>
> Mitigations
> ================
> Upgrade to version 3.1.5 or later.
> If this is not possible then ensure that you are using a recent version of php (at least 5.3), or disable the plugin.
>
> Disclosure policy
> ================
> dxw believes in responsible disclosure. Your attention is drawn to our disclosure policy: 
> https://security.dxw.com/disclosure/
>
> Please contact us on security () dxw com to acknowledge this report if you received it via a third party (for 
> example, plugins () wordpress org) as they generally cannot communicate with us on your behalf.
>
> This vulnerability will be published if we do not receive a response to this report with 14 days.
>
> Timeline
> ================
>
> 2014-04-16: Discovered
> 2015-07-21: Reported to vendor by email
> 2015-07-21: Requested CVE
> 2015-08-10: Vendor responded
> 2015-08-11: Vendor confirmed fixed in version 3.1.5
> 2015-08-12: Published
>
>
>
> Discovered by dxw:
> ================
> Tom Adams
> Please visit security.dxw.com for more information.
>
>
>
> _______________________________________________
> Sent through the Full Disclosure mailing list
> https://nmap.org/mailman/listinfo/fulldisclosure
> Web Archives & RSS: http://seclists.org/fulldisclosure/

Hi Tom, FD readers,

> The first is mcrypt_create_iv(100, MCRYPT_DEV_URANDOM). MCRYPT_DEV_URANDOM is expected to change to a different 
> random value whenever it is called, but on Windows, on older versions of php it is known to be a constant value

The bug you are referring to was fixed in PHP 5.3.7; this can be
solved by checking the PHP version and/or by not supporting older and
insecure versions of PHP.

See random_compat for how this should be done:

https://github.com/paragonie/random_compat/blob/master/lib/random.php#L53

> if no other functions (e.g. /dev/urandom) are available then the access token is generated solely using mt_rand(), 
> microtime(), and uniqid().
> mt_rand() (Mersenne twister) is not a cryptographically secure pseudorandom number generator.
> According to the documentation mt_rand() is also biassed towards even return values in some circumstances.
> According to the documentation uniqid() is as secure a PRNG as microtime().

Let's quantify these numbers:

* mt_rand()
    * Predictable, only up to 31 bits of entropy in the possible seed values
    * http://www.openwall.com/php_mt_seed/
* microtime()
    * Given the UNIX timestamp of the server is generally knowable, we
can ballpark this at a maximum of 10^6 (or about 20 bits) due to
microsecond resolution.
* uniqid()
    * 10 bits of entropy by default
    * 29 bits of entropy with more_entropy
    * http://securitymaverick.com/php-uniqid-entropy-analysis-and-potentially-vulnerable-apps

So if you're using WordPress on an ancient version of PHP on Windows
or have open_basedir restrictions on Linux, and disabled ext/mcrypt,
you can squeeze 60 to 80 bits out of this, assuming all of the seeds
are unrelated.

That's not as terrible as some of what I've seen (You want me to put
this str_shuffle() password generator in production? Dream on!) but
still not great. Ideally, you want at least 100 bits of entropy (from
urandom or equivalent).

BTW, unless you're using the latest patches for 5.4, 5.5, or 5.6,
openssl_random_pseudo_bytes() can silently fail and become weak too.
:(

The lesson to learn here is that you should be running a supported
version of PHP where these bugs are fixed, rather than continuing to
run 5.2.x in 2015.

_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/