Use of a Broken or Risky Cryptographic Algorithm in serghey-rodin/vesta
Reported on
Jul 24th 2021
✍️ Description
uniqid does not generate cryptographically secure strings, even if it did, supplying it with mt_rand would render it insecure as an attacker would be able to gain access to a victim's account by simply knowing when they logged in, this could be used as a mass-account-takeover vector given how an attacker could automate checking tokens and generate them after deducing the server's randomization seed.
🕵️♂️ Proof of Concept
Numerous examples and attack implementations can be found in this paper .
If you're looking for a practical tool that can crack your mt_rand implementation's seed value, see this project and run the following commands in a console with php5 and OpenWall's tool installed:
root$ php -r 'mt_srand(13333337); echo mt_rand( ), "\n";'
After that, copy the output (1863134308) and execute the following commands:
root$ gcc php_mt_seed.c -o php_mt_seed
root$ ./php_mt_seed 1863134308
After waiting ~1 minute you should have a few possible seeds corresponding to their PHP versions, next to your installed PHP version you should see something akin to:
seed = 0x00cb7359 = 13333337 (PHP 7.1.0+)
💥 Impact
This vulnerability is capable of allowing an unauthenticated attacker to generate session tokens of users at random and at mass by deducing the backend server's randomization seed or by taking advantage of the fact that uniqid isn't cryptographically secure.
Occurrences
Hey Michael, I've just contacted the vesta team. Waiting to hear back, good job!
it's hardly exploitable because sessions are linked to IP address from which they are created, so attacker (even if he guess session_id) also must has the same IP address as victim. However, this will be easily fixed, soon.
Thank you for your response! If it's not a hassle, kindly consider marking this report as valid or invalid to settle this advisory.
Well, since I'm not main maintainer of VestaCP, I think I don't have a right to mark it as valid, even I think it's valid (under very hard conditions, for example, because of IP address). I will let Serghey Rodin to mark it as he thinks it should be marked.
I will paste here link to commit when we fix it (in next few days)
Thanks for the additional insight into the session fixation although I don't believe that unique IP addresses should be considered a barrier for attacks as this would not mean that the vulnerability is useless, rather that it requires an attacker and victim to be using the same IP address which is relatively common in public practice as people that use VPNs and other shared wide-scale networks (Tor & public networks, for example) would be unable to prevent accounts from being taken over as an attacker could connect to their network and abuse the above issue without concering themselves with session-fixation via IP address issues (if I have understood what you're saying correctly, that is).
Totally agree. I just said that it's the factor that will make it harder to exploit it.
I will tell to Serghey to come here and mark the issue.
Fix - https://github.com/myvesta/vesta/commit/df11eaf33f5ca48a5fda16be2fb1e266421087bd