Critical RCE vulnerability on OpenSSH: Detecting and mitigating CVE-2024-6387 “regreSSHion"
On July 1, the Qualys Threat Research Unit issued an advisory for a vulnerability, CVE-2024-6387, that may affect glibc-based Linux systems by enabling unauthenticated remote code execution (RCE) as root. According to Hacker News, the vulnerability, codenamed “regreSSHion, is a regression of the previously patched CVE-2006-5051 from almost 2 decades ago, with the problem reinstated in October 2020 as part of OpenSSH version 8.5p1.
While this can be challenging to exploit, it can have high impact consequences when successfully exploited. It’s been confirmed in lab environments that it requires approximately 10,000 attempts which can take 6-8 hours of continuous connections against a 32-bit host. While far more prevalent, exploitation against 64-bit hosts is theoretically possible (but yet to be proven publicly).
What’s the impact?
This vulnerability potentially allows attackers to run with full privileges if a client does not authenticate within 120 seconds (600 seconds for old OpenSSH versions). Exploiting regeSSHion could allow attackers to:
- Fully compromise a vulnerable host
- Access sensitive data
- Pivot/move laterally to internal hosts
- Ransom critical data
Vulnerable versions
- OpenSSH versions prior to 4.4p1
- OpenSSH versions between 8.5p1 and 9.7p1
Previous patches for CVE-2006-5051 and CVE-2008-4109 have addressed the flaw, and OpenBSD systems are unaffected. In addition the OpenSSH versions shipped with Red Hat Enterprise Linux 6, 7 and 8 are not vulnerable as the regression in the upstream was introduced in OpenSSH 8.5p1, which is newer than the aforementioned Red Hat Enterprise Linux versions.
Steps to mitigate
- Upgrade versions of OpenSSH as soon as patches become available
- Set LoginGraceTime to 0
- Note that this adds a risk of denial of service if simultaneous connections exceed the value of MaxStartups
- Limit SSH access to internet exposed hosts, and implement network segmentation to restrict lateral movement.
How Lacework monitors zero-day exploits and prioritizes patching
The disclosure of a high-severity vulnerability such as regreSSHion, with its potentially damaging consequences across the internet and cloud computing, is something that makes our hearts sink.
While no one can fully defend against zero-day vulnerabilities, Lacework continuously monitors and detects any anomalous activities and events that may be associated with an attacker actively exploiting a zero-day. Our patented threat detection and behavioral analysis technology automatically learns the characteristics of your cloud workloads, and how those activities and behaviors evolve. From this baseline, Lacework raises an alert on any unexpected changes, providing the historical and runtime context to aid in investigations.
Because Lacework uses machine learning to build a unique, detailed behavior model for each individual cloud environment, identifying unexpected activity is relatively easy, based on what has been seen before. For example, detecting anomalous SSH connections in concert with other relevant indicators might signal that an attacker is actively exploiting regreSSHion to gain persistence, move laterally or access sensitive data. By automatically uncovering this activity, your security and incident response teams can find previously unknown exploits and take action faster.
Once a fix is available, it will be important to be able to prioritize which vulnerable instances pose the greatest risk to your cloud and your business. It can also be daunting to figure out what implications updates may have on the rest of your environment — will it break anything or impact customers or operations? Having more context around the discovered vulnerabilities is important, especially when you need to decide which ones to patch first. After all, if you have a long list of things to remediate, you want to start with the most critical ones versus randomly choosing which ones to do first.
Lacework provides active vulnerability detection to help prioritize active vulnerable packages, versus those installed but inactive, and therefore less of an immediate concern. By combining dynamic runtime insights with static CVE data, teams clearly understand the impact and exploitability of each vulnerability within their specific cloud environments, and can prioritize those that matter most.
Not a Lacework customer? Learn how to detect anomalous behavior and active cloud threats without writing and maintaining rules: Lacework Anomaly Detection
Categories
Suggested for you