Managing the RegreSSHion vulnerability

James McGoldrick at Systal explains how to address the severe remote code execution RegreSSHion vulnerability

 

On 1st July 2024, researchers from Qualys published a blog post outlining a remote code execution vulnerability within the SSH server (SSHD) implementation in glibc-linux installations: “RegreSSHion”. This vulnerability allowed a remote, unauthenticated attacker to remotely execute code on affected devices with root privileges.  

 

This meant that SSH servers exposed to the internet could be vulnerable to remote takeover by anyone who had the technical ability to leverage the condition – or anyone who could harness and re-use any proof-of-concept code found on the internet.  

 

Given that SSH stands for ‘Secure Shell’ and the purpose of the protocol is to provide secure remote access for system admins and other remote users, it will be no surprise that there are a huge number of systems on the internet which are exposed to this new potent vulnerability.  

 

The risks

This highlights two key problems facing companies in an ever more connected world:  

 

1. Security by design is hard

If we look at the history of security-related updates associated with OpenSSH, we find another CVE from 2006 which essentially reports the same race condition flaw. This of course was addressed at the time and the world patched and moved on. That raises the question, however - what happened? 

 

As it turns out, maintaining highly secure and complex technologies like SSH is difficult and on this occasion, it appears as if a recent change in the code base has re-introduced the previously patched security vulnerability. 

 

This demonstrates how difficult it can be to maintain perfect security in complex protocols and technologies which are always being pushed to offer more functionality and connectivity. The vulnerability, in this case, arises due to a complex inter-relationship between several operating system components out with the SSHD protocol itself and requires a deep understanding of system architecture to identify it and craft a successful exploit.

 

2. Security is the enemy of convenience

Businesses constantly strive to reduce friction, maximise efficiency and create solutions that are easy and affordable to manage and use - and quite rightly so. The need to secure systems against exploitation however can often mean barriers have to be put in place which run contrary to these objectives. 

 

The RegreSSHion vulnerability is an example of this paradox. OpenSSH by its very design is a service which should be reachable remotely but mistakes in the implementation of the software can have devastating consequences for the systems which are exposed.

 

The only way to reduce this risk is to protect access to the devices via firewalls and access through VPN technology. This introduces complexity to the network environment and additional costs - not to mention another technology (the VPN gateway) which also has to be monitored and managed for security. 

 

The response

About the RegreSSHion vulnerability specifically, making sure you are not running an affected version of SSHD on publicly routable devices is of paramount importance. Malicious scanning for exposed servers is already underway and it likely will not take long at all before we see attempts to compromise machines using affected versions of OpenSSH. 

 

Any version of SSHD earlier than 4.4p1 is vulnerable to the original race condition vulnerability – it should be very unlikely that any system still online is running this old version of SSHD.

 

Versions between 4.4p1 and 8.5p1 are safe from this vulnerability. But versions between 8.5p1 and 9.8p1 are vulnerable due to the removal of a previous function component which patched the earlier vulnerability. 

 

If you cannot patch affected systems in the short term, you should consider restricting access to SSH services using a firewall. Ideally, you should whitelist trusted IPs that have a legitimate need to access these services over the internet.

 

Taking this one step further, companies could restrict the access to SSH ports to internal networks only and permit authenticated access to those internal interfaces via VPN connections with appropriate Role Based Access control to those servers. 

 

In some cases, implementing the above changes might not be practical in the short term and may result in service outages that cannot be tolerated. There are some options to mitigate the impact of this vulnerability that could be considered until the fix can be applied. 

 

You could consider changing the LoginGraceTime parameter within your sshd_conf file on any vulnerable servers to a value of 0. This will however mean that login attempts to your server will never time 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.  

 

The use of the ’Fail2Ban’ open-source project should also be considered. This utility allows for 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 take advantage of this vulnerability well before the attacker is likely to succeed. 

 

For many companies maintaining an accurate image of their exposed assets, software versions and associated configurations is a significant challenge in and of itself. There are fortunately several services and resources available that can help identify your critical assets and protect them in a cost-effective and easy-to-manage way without increasing the burden on your daily business operations.

 

---

 

James McGoldrick is DFIR / CSIRT Manager at Systal

 

Main image courtesy of iStockPhoto.com and Vertigo3d