Wednesday, February 12, 2025
HomeCVE/vulnerabilityCritical OpenSSL Vulnerability Let Attackers Launch Man-in-the-Middle Attacks

Critical OpenSSL Vulnerability Let Attackers Launch Man-in-the-Middle Attacks

Published on

SIEM as a Service

Follow Us on Google News

A high-severity security vulnerability (CVE-2024-12797) has been identified in OpenSSL, one of the most widely used cryptographic libraries.

The flaw allows attackers to exploit a loophole in TLS and DTLS handshakes, potentially enabling man-in-the-middle (MITM) attacks on vulnerable connections.

OpenSSL has issued a security advisory urging affected users to upgrade immediately to mitigate the risk.

Flawed Server Authentication (CVE-2024-12797)

The issue lies in the handling of RFC7250 Raw Public Keys (RPKs), an optional mechanism in TLS/DTLS connections.

When a client enables RPK use for authenticating a server, it might fail to terminate the handshake if the server’s public key does not match the expected values—despite SSL_VERIFY_PEER verification mode being set.

This omission leaves the connection open to interception by a malicious actor.

RPKs are disabled by default across OpenSSL implementations, but when explicitly enabled in both the client and server configurations, this vulnerability could allow attackers to impersonate the server.

By exploiting this flaw, they could intercept, read, or modify communication between a client and server.

Impact and Affected Versions

The vulnerability affects OpenSSL versions 3.4, 3.3, and 3.2. Earlier versions (3.1, 3.0, 1.1.1, and 1.0.2) and OpenSSL’s FIPS modules are unaffected.

Clients relying solely on the handshake process to validate server authentication are at the most risk. However, those implementing additional checks using SSL_get_verify_result() remain unaffected.

OpenSSL has released patches to address the issue. Users are advised to upgrade their OpenSSL libraries to the following versions immediately:

  • OpenSSL 3.4 users: Upgrade to OpenSSL 3.4.1
  • OpenSSL 3.3 users: Upgrade to OpenSSL 3.3.2
  • OpenSSL 3.2 users: Upgrade to OpenSSL 3.2.4

Viktor Dukhovni implemented the fix following a report from Apple Inc. in December 2024.

System administrators and developers using OpenSSL in their environments should review their implementations to determine if RPKs are explicitly enabled. If so, upgrading to the patched versions is critical to mitigate potential security risks.

For those not actively using RPKs, the vulnerability poses no immediate threat, as RPKs are disabled by default. OpenSSL advises users to regularly monitor their security advisory page for any additional updates or technical details.

This latest vulnerability underscores the importance of proactive patching and rigorous security practices, particularly for foundational libraries like OpenSSL.

Organizations relying on OpenSSL are urged to act promptly to secure their systems and prevent malicious exploitation of this flaw.

Investigate Real-World Malicious Links & Phishing Attacks With Threat Intelligence Lookup - Try for Free

Divya
Divya
Divya is a Senior Journalist at GBhackers covering Cyber Attacks, Threats, Breaches, Vulnerabilities and other happenings in the cyber world.

Latest articles

Ratatouille Malware Bypass UAC Control & Exploits I2P Network to Launch Cyber Attacks

A newly discovered malware, dubbed "Ratatouille" (or I2PRAT), is raising alarms in the cybersecurity...

Sandworm APT Hackers Weaponize Microsoft KMS Activation Tools To Compromise Windows

In a sophisticated cyber-espionage operation, the Russian state-sponsored hacking group Sandworm (APT44), linked to...

Hackers Can Exploit “Wormable” Windows LDAP RCE Vulnerability for Remote Attacks

A critical new vulnerability in Microsoft’s Windows Lightweight Directory Access Protocol (LDAP), tagged as...

Google Chrome’s Safe Browsing Now Protects 1 Billion Users Worldwide

Google's Safe Browsing technology now ensures enhanced protection for over 1 billion Chrome users...

Supply Chain Attack Prevention

Free Webinar - Supply Chain Attack Prevention

Recent attacks like Polyfill[.]io show how compromised third-party components become backdoors for hackers. PCI DSS 4.0’s Requirement 6.4.3 mandates stricter browser script controls, while Requirement 12.8 focuses on securing third-party providers.

Join Vivekanand Gopalan (VP of Products – Indusface) and Phani Deepak Akella (VP of Marketing – Indusface) as they break down these compliance requirements and share strategies to protect your applications from supply chain attacks.

Discussion points

Meeting PCI DSS 4.0 mandates.
Blocking malicious components and unauthorized JavaScript execution.
PIdentifying attack surfaces from third-party dependencies.
Preventing man-in-the-browser attacks with proactive monitoring.

More like this

Ratatouille Malware Bypass UAC Control & Exploits I2P Network to Launch Cyber Attacks

A newly discovered malware, dubbed "Ratatouille" (or I2PRAT), is raising alarms in the cybersecurity...

Sandworm APT Hackers Weaponize Microsoft KMS Activation Tools To Compromise Windows

In a sophisticated cyber-espionage operation, the Russian state-sponsored hacking group Sandworm (APT44), linked to...

Hackers Can Exploit “Wormable” Windows LDAP RCE Vulnerability for Remote Attacks

A critical new vulnerability in Microsoft’s Windows Lightweight Directory Access Protocol (LDAP), tagged as...