On June 30, 2024, Qualys, a US security firm, has discovered a critical vulnerability in OpenSSH Server - the de facto standard tool used to access and manage cloud servers.[1]
The vulnerability allows an attacker to bypass the authentication process and remotely execute code with root-level access on the system, potentially leading to data theft or system compromise. At risk are OpenSSH versions 8.5p1 (2020) to 9.7p1 (2024) or below 4.4p1 (2006).
The "Remote Code Execution" (RCE) vulnerability has been assigned CVE-2024-6387 and dubbed "regreSSHion" - This is pun to this being a regression bug because it has been reported and fixed in 2006 (CVE-2006-5051) and reintroduced in 2020.
Luckily the vulnerability is (still) challenging to exploit, requiring multiple attempts and timing for a succesful attack - but any serious organization would want to mitigate this risk immediately.
For the real Geeks among us - A basic proof of concept exploit has been published on GitHub. [2]
80% of Companies with Cloud using OpenSSH
OpenSSH has become the de facto standard for remote access to servers. It is used by DevOps, SysAdmins, Engineers, and Security teams to manage (cloud) infrastructure, and is often the first tool to be installed on a new server.
WIZ, a cloud security company, estimates that 80% of organizations with cloud environments have at least one vulnerable instance of OpenSSH running, putting them at risk. [3]
Qualys has run internet scans and identified 14 million potentially vulnerable OpenSSH servers, which are accessible from the internet(!). [1]
Mitigation 1: Update OpenSSH - or Change Config and Risk DOS
Quickly apply patches and update OpenSSH to version 9.8p1, released on July 1st 2024. [4]
If you are unable to update, you can mitigate this vulnerability by changing sshd setting "LoginGraceTime" to "0" in the configuration file. This will eliminate the risk of remote code excution through this vulnerability, but it can make the server susceptible to Denial of Service (DOS) attacks - which is probably a lesser evil than the risk of a remote code execution.
Nasreddine Bencherchali, a Security Researcher on X explaining how to mitigate the RCE risk, and instead be susceptiple to DOS attacks. [5]
Mitigation 2: Use Fail2Ban to Mitigate Both CVE-2024-6387 and DOS Attacks
In order to mitigate against both risks - the RCE and DOS - you can use Fail2Ban, an open-source intrusion prevention software that comes with a default config file for sshd and can automatically alter firewall configuration to ban IPs after a certain number of unsuccessful login attempts. [6][6]
Florian Roth, a Security Researcher on X explaining how to mitigate both RCE and DOS risk using Fail2Ban. [7]
Mitigation 3: Use VPN to Prevent Access to SSH Port 22 from the Internet
Use a VPN such as WireGuard or the open-source Netbird in front of the SSH service. This will prevent attackers from accessing the SSH port 22 from the internet, reducing the risk of remote exploitation. [6][8]
How to Identify Exploitation Attempts and Systems at Risk
To reveal exploitation attempts, set up your monitoring systems to detect multiple occurences of "Timeout before authentication" in the sshd server logfiles. [1]
To identify systems at risk, scan your environment for installations of vulnerable versions of the OpenSSH servers.
References
- https://blog.qualys.com/vulnerabilities-threat-research/2024/07/01/regresshion-remote-unauthenticated-code-execution-vulnerability-in-openssh-server
- https://github.com/zgzhang/cve-2024-6387-poc
- https://www.wiz.io/blog/cve-2024-6387-critical-rce-openssh
- https://www.openssh.com/releasenotes.html
- https://x.com/nas_bench/status/1807821951433416877
- https://www.digitalocean.com/community/tutorials/how-to-protect-ssh-with-fail2ban-on-ubuntu-20-04
- https://x.com/cyb3rops/status/1808089314707784167?s=48&t=tyFllwqVrpzw2rL-cc8b5w
- https://netbird.io/knowledge-hub/using-ssh-to-secure-remote-access