Use of a Broken or Risky Cryptographic Algorithm in mautic/mautic

Valid

Reported on

Jul 10th 2021


✍️ Description

The function mt_rand is used to generate session tokens, this function is cryptographically flawed due to its nature being one pseudorandomness, an attacker can take advantage of the cryptographically insecure nature of this function to enumerate session tokens for accounts that are not under his/her control

🕵️‍♂️ 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+)

Hey, that's your seed!

💥 Impact

An attacker could takeover accounts at random by enumerating and using access tokens.

Ziding Zhang
5 months ago

Admin


Hey Michael, great job with the disclosures lately. Let's hope the maintainers of these packages respond swiftly.

I've just emailed the mautic maintainers as per their security policy - waiting to hear back.

We have contacted a member of the mautic team and are waiting to hear back 5 months ago
mautic/mautic maintainer
5 months ago

Hi folks, thanks for letting us know. I will raise this with the Mautic Security Team per our documented processes and we will look into it.

Ruth Cheesley (Mautic Project Lead)

mautic/mautic maintainer
5 months ago

Internal reference: MST-18

Michael Rowley
4 months ago

Researcher


Thanks Ziding, I'm hoping that things will get looked into soon.

Is there any way to get notified when someone comments/replies to a post (@admin) as I've been thinking that unresolved posts are ones where maintainers just haven't replied but in a few cases they have replied without verifying the vulnerability so it would be cool to be able to see when a maintainer comments on one of my reports without being pinged.

Jamie Slome
4 months ago

Admin


@Michael - thanks for the suggestion.

Please could you create a ticket against our public repository? It will help us track your feature request there.

https://github.com/418sec/huntr

mautic/mautic maintainer
4 months ago

Hi folks! The team have confirmed that this is possible but unlikely to be exploited. We are going to look into some options for addressing this in a future release and will keep you updated with progress. Thanks again for reporting the issue.

mautic/mautic maintainer validated this vulnerability 4 months ago
Michael Rowley has been awarded the disclosure bounty
The fix bounty is now up for grabs
Michael Rowley
4 months ago

Researcher


Thanks @Jamie I'll create a ticket there now.

Thank you for the update @mautic/mautic - I'm looking forward to seeing this get patched, I've been told that Mautic is a CNA itself so I'll need to go directly through you guys to get a CVE assigned to this vulnerability, would it be possible to do this or would I need to email you guys seperately via security@?

mautic/mautic maintainer
4 months ago

Yes we are indeed a CNA and will assign an ID once we have dug into it in more detail and have all the info that we require, We will keep you updated here if that works for you :)

Michael Rowley
4 months ago

Researcher


That sounds good!

Michael Rowley submitted a
4 months ago
Michael Rowley
4 months ago

Researcher


Hey, I've submitted a patch for this vulnerability where I switched out the entire SHA1 implementation for a more suitable 'random_bytes()' one that provides an output string of the same length as the typical SHA1 ciphertext (20 bytes/characters) therefore providing a similar computational complexity when it comes to bruteforcing the sessionId if an attacker were to try - in the future, this could be adjusted to make it even harder for brute-force attacks but I doubt that this will be a product in the near future.

Let me know if it breaks anything else or isn't suitable for Session-IDs!

Ruth Cheesley confirmed that a fix has been merged on 95fecf 3 months ago
The fix bounty has been dropped