Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG) in star7th/showdoc
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.
Occurrences
Hey Michael, I've just emailed the maintainers of this repo. Great job!
I don't know if I can reply when I'm not logged in. Thanks
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.
@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?
@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.
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.
Okay, I've opened an issue on Github to see if the process of submitting patches could be adjusted slightly.
Great, thanks for this! We will get some comments on this ASAP.