Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG) in star7th/showdoc

Valid

Reported on

Aug 2nd 2021


✍️ Description

The referenced code block computes a MD5 hash based on a string ("rgrsfsrfsrf"), the current time, and a random number. The string used is static and does not appear to change, therefore I'm not sure why it is there in the first place as it does not provide any additional security (maybe this could be considered security-by-obscurity but this is an open source project, in fact, if it was an attempt at security-by-obscurity which is already a bad idea; it would have been better if the string that should provide the obscurity was not a 11-character string consisting of 4 unique ones!). The time used is the machine's current time which is unlikely to add additional security as the value returned by time() is an integer that records the seconds since epoch (1970 iirc) meaning that an attacker would either need to know when you generated the MD5 hash or be able to brute-force it to break the hash so far (both of which are easily possible as there 31,104,000 seconds in a year and approximately 2,600,000 in a month, effectively nothing to a modern computer). The final value that is used for the hash generation is the output of a call to rand( ) which is considered cryptographically insecure even by its PHP documentation.

🕵️‍♂️ Proof of Concept

The issue with time( ):

As I've already stated, there are 31,104,000 seconds in a year - meaning that an attacker could quite easily predict a user's time( ) value as long as they know the time-window that it was called in, making 31,000,000 calls isn't an unrealistic expectation either.

The issue with rand( ):

Numerous attack vectors have been shown in this paper.

💥 Impact

This vulnerability is capable of allowing attackers to divulge extremely sensitive information without authorization.

Z-Old
a year ago

Admin


Hey Michael, I've just emailed the maintainers of this repo. Great job!

Michael Rowley
a year ago

Researcher


Great, I'm looking forward to a reply!

We have contacted a member of the star7th/showdoc team and are waiting to hear back a year ago
star7th/showdoc maintainer confirmed that a fix has been merged on 4b962c a year ago
The fix bounty has been dropped
star7th/showdoc maintainer
a year ago

I don't know if I can reply when I'm not logged in. Thanks

Michael Rowley
a year ago

Researcher


This reply is showing on the report so it seems to have worked, your fix doesn't account for the insecure nature of rand( ) as it seems to just increase the max value of rand to an absurdly large one (which still leaves it in an insecure state) - I've submitted my fix that just replaces your MD5 implementation with the hex representation of 16 bytes derived from a CSRNG.

Michael Rowley
a year ago

Researcher


@admin I'm unable to use the 'submit patch' button as the maintainer of this repository marked his own as the fix but it isn't a valid fix - due to this; I've submitted my fix here (1438) is there any way I could collect the fix bounty for this when it is merged?

Jamie Slome
a year ago

Admin


@maintainer, can you just confirm that this is the case?

If so, I will update the data for this advisory and the CVE for publishing.

Jamie Slome
a year ago

Admin


Unfortunately, we cannot reward for fix bounties unless they have been submitted through the platform.

BTW, the CVE is in the process of being reviewed and should be published shortly.

Michael Rowley
a year ago

Researcher


Okay, I've opened an issue on Github to see if the process of submitting patches could be adjusted slightly.

Jamie Slome
a year ago

Admin


Great, thanks for this! We will get some comments on this ASAP.

to join this conversation