Skip to content

GHSA-x7g2-wrrp-r6h3 CVE-2021-27913

Use of a Broken or Risky Cryptographic Algorithm

Low Packagist
Severity
3.5 / 10
Low · CVSS 3.1
Exploit chance (EPSS)
0.46%
Chance of exploitation in the next 30 days. Higher than 39.75% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-327 Use of a Broken or Risky Cryptographic Algorithm
Fix
3.3.4
Upgrade mautic/core to this version or later

Description

✍️ 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_seedroot$ ./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.

📝 References

Affected versions

Packagist

PackageVulnerableFixed in
mautic/core
< 3.3.4
3.3.4
mautic/core
>= 4.0.0-alpha1, < 4.0.0
4.0.0

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

mautic/core Packagist → 3.3.4

composer
composer require mautic/core:^3.3.4

Severity breakdown

CVSS 3.1 3.5

CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:L

Attack vector
Network
Attack complexity
Low
Privileges required
Low
User interaction
Required
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
Low

Weakness

CWE-327: Use of a Broken or Risky Cryptographic Algorithm

The product uses a broken or risky cryptographic algorithm or protocol.

How to prevent it
  • Architecture and Design: When there is a need to store or transmit sensitive data, use strong, up-to-date cryptographic algorithms to encrypt that data. Select a well-vetted algorithm that is currently considered to be strong by experts in the field, and use well-tested implementations. As with all cryptographic mechanisms, the source code should be available for analysis. For example, US government systems require FIPS 140-2 certification [REF-1192]. Do not develop custom or private cryptographic algorithms. They will likely be exposed to attacks that are well-understood by cryptographers. Reverse engineering techniques are mature. If the algorithm can be compromised if attackers find out how it works, then it is especially weak. Periodically ensure that the cryptography has not become obsolete. Some older algorithms, once thought to require a billion years of computing time, can now be broken in days or hours. This includes MD4, MD5, SHA1, DES, and other algorithms that were once regarded as strong. [REF-267]
  • Architecture and Design: Ensure that the design allows one cryptographic algorithm to be replaced with another in the next generation or version. Where possible, use wrappers to make the interfaces uniform. This will make it easier to upgrade to stronger algorithms. With hardware, design the product at the Intellectual Property (IP) level so that one cryptographic algorithm can be replaced with another in the next generation of the hardware product.
  • Architecture and Design: Carefully manage and protect cryptographic keys (see CWE-320). If the keys can be guessed or stolen, then the strength of the cryptography itself is irrelevant.
  • Architecture and Design: Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482]. Industry-standard implementations will save development time and may be more likely to avoid errors that can occur during implementation of cryptographic algorithms. Consider the ESAPI Encryption feature.
  • Implementation, Architecture and Design: When using industry-approved techniques, use them correctly. Don't cut corners by skipping resource-intensive steps (CWE-325). These steps are often essential for preventing common attacks.

References

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-5hvg-w58j-545m
Mautic has Stored Cross-Site Scripting (XSS) in Project Option Selector
Medium Also affects mautic/core
GHSA-7h65-whp7-rgqf
Mautic has Stored Cross-Site Scripting (XSS) in Projects Component
High Also affects mautic/core
GHSA-2jrw-c95w-h43g
Mautic has an Authorization Bypass in API v2 Endpoints
High Also affects mautic/core
GHSA-6r9h-4h75-7q4x
Mautic vulnerable to Path Traversal via Campaign Import
Critical Also affects mautic/core
GHSA-9fx4-7cmj-47vg
Mautic has Server-Side Template Injection (SSTI) in Theme Templates
Critical Also affects mautic/core
GHSA-jmv8-8j9j-rcpc
Mautic Focus component Vulnerable to SSRF
Medium Also affects mautic/core
GHSA-fcmw-wx57-9p75
Mautic has SQL Injection in API Contact Filtering
High Also affects mautic/core
GHSA-r5j5-q42h-fc93
Mautic is Vulnerable to SQL Injection through Contact Activity API Sorting
High Also affects mautic/core
Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor