As expected from yesterday’s announcement article, the exploit code for the freshly-discovered OpenSSH “regreSSHion” vulnerability (CVE-2024-6387) has already surfaced on GitHub. This critical flaw in one of the internet’s most ubiquitous secure communication tools threatens to turn millions of systems into potential targets for malicious actors.
First reported by Qualys’ Threat Research Unit on July 1, 2024, the vulnerability affects a wide swath of Portable OpenSSH versions, from 8.5p1 to 9.7p1. At its core, it’s a nasty little race condition in the OpenSSH server (sshd) on glibc-based Linux systems that could allow unauthenticated attackers to execute arbitrary code with root privileges. In other words, it’s a hacker’s dream come true, even if it takes all night (~8 hours or ~10,000 attempts).
Qualys’ recon of affected systems showed that over 14 million OpenSSH server instances exposed to the internet could be vulnerable. Their analysis suggests that about 700,000 external internet-facing instances within their global customer base are at risk – that’s a whopping 31% of all internet-facing instances with OpenSSH.
As I said yesterday, the fact that Qualys published a detailed technical breakdown of how the vulnerability was found, it would be only a matter of time before exploits start popping up, and that is precisely the case today. A GitHub user known as “7etsuo” has published a proof-of-concept exploit for the regreSSHion vulnerability. The code, aptly titled “7etsuo-regreSSHion.c,” details step-by-step how an attacker could potentially leverage this flaw.
* Exploit Title : SSH Exploit for CVE-2024-6387 (regreSSHion)
* Author : 7etsuo
* Date : 2024-07-01
*
* Description:
* Targets a signal handler race condition in OpenSSH's
* server (sshd) on glibc-based Linux systems. It exploits a vulnerability
* where the SIGALRM handler calls async-signal-unsafe functions, leading
* to rce as root.
*
* Notes:
* 1. Shellcode : Replace placeholder with actual payload.
* 2. GLIBC_BASES : Needs adjustment for specific target systems.
* 3. Timing parameters: Fine-tune based on target system responsiveness.
* 4. Heap layout : Requires tweaking for different OpenSSH versions.
* 5. File structure offsets: Verify for the specific glibc version.The exploit attempts to bypass ASLR (Address Space Layout Randomization) by trying multiple possible glibc base addresses. It then hammers the target server with repeated SSH connections, trying to hit the spot where the race condition can be triggered.
The exploit code implements a few key techniques:
- Precise timing mechanisms to hit the vulnerable window just before the SIGALRM signal is triggered.
- Heap preparation to create a favorable memory layout for exploitation.
- Creation of fake FILE structures to manipulate memory and control execution flow.
- A placeholder for shellcode, ready for an attacker to insert their own payload for arbitrary code execution.
While this particular code appears to be more of a proof-of-concept than a fully weaponized exploit, it significantly lowers the barrier for potential attackers, and you can bet your bottom dollar that more refined and efficient versions of this exploit are already being cooked up in the darker corners of the internet.
The publication of this exploit code turns what was already a race against time for organizations to patch their vulnerable OpenSSH installations into a full-blown sprint.
Alexander Hagenah, xaitax on GitHub, published a Python script that can mass-scan target systems that might be vulnerable to CVE-2024-6387. In his own words, “This script facilitates rapid scanning of multiple IP addresses, domain names, and CIDR network ranges to detect potential vulnerabilities and ensure your infrastructure is secure.”
Stack Diary has also seen instances of malicious actors who are attempting to capitalize on this security issue by offering working exploits for sale:
For organizations still dragging their feet on this one, the message is clear: patch now, or prepare for a world of hurt. Here’s your to-do list:
- Update to OpenSSH 9.8 or apply vendor-specific patches issued by your distribution.
- Lock down SSH access with network-based access controls.
- Get those intrusion detection systems up and running to spot exploitation attempts.
- Audit the hell out of any systems that might have been exposed to this vulnerability.
As this situation unfolds, you can bet that cybersecurity pros worldwide will be burning the midnight oil, watching for any signs of active exploitation in the wild.
