27 August 2024
James McGoldrick, DFIR / CSIRT Manager, Systal
Last month, Qualys researchers released a blog post detailing a remote code execution flaw named “RegreSSHion” in the SSH server (SSHD) implementation in glibc-linux installations. The vulnerability gave remote, unauthenticated attackers root-level access to execute code on compromised devices.
The vulnerability meant that internet-exposed SSH servers became susceptible to remote takeover by anyone with the technical skills to exploit the vulnerability or anyone who could utilise and re-use any proof-of-concept code available online.
Considering that SSH stands for ‘Secure Shell’ and is designed to offer secure remote access for system administrators and other remote users, it’s unsurprising that a significant number of systems on the internet are now exposed to this powerful new vulnerability.
The dangers
There are two key problems facing organisations in today’s digital world:
1. Security by design is challenging
Examining the history of security updates linked to OpenSSH reveals a similar Common Vulnerability and Exposure (CVE) from 2006, which also reported the same race condition flaw. This issue was resolved back then, leading to widespread patching and the issue being considered resolved. However, the incident naturally raises the question – what went wrong this time?
Maintaining highly secure and complex technologies like SSH is a challenging task, and in this instance, it seems that a recent update to the code base inadvertently reintroduced the security vulnerability that had been previously patched.
This highlights the challenges of achieving flawless security in complex protocols and technologies that are constantly evolving to provide more functionality and connectivity. In this case, the vulnerability stems from a complex interaction between various operating system components beyond the SSHD protocol itself, requiring a deep understanding of system architecture to detect and exploit it effectively.
2. Security often comes at the cost of convenience
Companies are always looking to minimise friction, maximise efficiency and develop solutions that are both easy to manage and cost-effective – and understandably so. However, securing systems against exploitation often requires implementing barriers that can conflict with these goals.
The RegreSSHion vulnerability is a perfect example of this dilemma. OpenSSH by its very design is a service which should be reachable remotely, but errors in its implementation can lead to severe consequences for exposed systems. The best way to mitigate this risk is by safeguarding access to the device’s wire firewalls and VPN technology. However, this adds complexity to the network, increases costs and introduces another element – the VPN gateway – that also needs to be monitored and managed for security.
Steps to securing systems against the RegreSSHion vulnerability
The first step in securing your system is to ensure it isn’t running an affected version of SSHD on devices which can be publicly accessed. Cybercriminals actively scan for exposed servers and it won’t be long before we see attempts to exploit machines using vulnerable versions of OpenSSH.
Any SSHD version before 4.4p1 is susceptible to the original race condition vulnerability, though it’s highly unlikely that any system still in operation is using this version of SSHD.
Versions from 4.4p1 to 8.5p1 are not affected by this vulnerability. However, versions between 8.5p1 and 9.8p1 are vulnerable because a previously included function that patched the earlier vulnerability has been removed.
If immediate patching of affected systems isn’t possible, it’s advisable to limit access to SSH services through a firewall. Ideally, you should configure the firewall to only allow trusted IPs that need to access these services over the internet. For added security, companies could restrict access to SSH ports to internal networks and only permit authenticated access to those internal interfaces via VPN connections with appropriate Role Based Access control to those servers.
In certain situations, applying the above changes immediately might not be feasible and could lead to unacceptable service disruptions. But, there are alternative measures to reduce the impact of this vulnerability that could be considered until a proper fix can be applied. One option is to set the LoginGraceTime parameter in your sshd_conf file on any vulnerable servers to a value of 0. This adjustment will prevent login attempts from timing out and could allow server resources to be saturated and lead to a DoS condition for SSH connections, if not the server itself. This should not be considered as a long-term solution.
Consider implementing the 'Fail2Ban' open-source project, which provides dynamic blocking of malicious IPs based on repeated local connection attempts to SSH on the servers it is installed on. This will automatically blacklist any IPs attempting to exploit the vulnerability, significantly reducing the chances of a successful attack.
For many businesses, keeping an up-to-date record of their exposed assets, software versions and associated configurations is a daunting task. Thankfully, there are various services and tools available that are designed to efficiently and affordably identify and safeguard critical assets, without increasing the burden on your daily business operations.
