The OpenSSH regreSSHion Vulnerability – TURN OFF SSH RIGHT NOW ON YOUR NAS

New OpenSSH Vulnerability Could Impact NAS Users: What You Need to Know

(Updated 3rd July 2023 with QNAP Advisory and TrueNAS implementation of the OpenSSH official Patch)

A critical vulnerability in OpenSSH, dubbed “regreSSHion” and assigned CVE-2024-6387, has been discovered by researchers at Qualys. This flaw, which allows for unauthenticated remote code execution (RCE) with root privileges on glibc-based Linux systems, poses a significant threat to various network-attached storage (NAS) systems widely used for secure remote login and file management. The vulnerability stems from a signal handler race condition in the OpenSSH server (sshd) and has been found to impact versions from 8.5p1 up to, but not including, 9.8p1. This discovery has significant implications, especially for environments where secure remote management and access are paramount.

Below is the link to the original Qualys Blog Post that covered this CVE

How is this New OpenSSH Vulnerability Exploited?

The vulnerability, initially identified in May 2024, reintroduces an issue previously patched in 2006, known as CVE-2006-5051. If a client does not authenticate within the default LoginGraceTime of 120 seconds, sshd’s SIGALRM handler is called asynchronously and executes various functions that are not async-signal-safe. This opens the door for remote attackers to exploit the race condition, potentially leading to full system compromise. This regression highlights the importance of thorough regression testing in software development to prevent reintroducing previously resolved vulnerabilities.

“We discovered a vulnerability (a signal handler race condition) in OpenSSH’s server (sshd): if a client does not authenticate within LoginGraceTime seconds (120 by default, 600 in old OpenSSH versions), then sshd’s SIGALRM handler is called asynchronously, but this signal handler calls various functions that are not async-signal-safe (for example, syslog()). This race condition affects sshd in its default configuration. On investigation, we realized that this vulnerability is in fact a regression of CVE-2006-5051 (“Signal handler race condition in OpenSSH before 4.4 allows remote attackers to cause a denial of service (crash), and possibly execute arbitrary code”), which was reported in 2006 by Mark Dowd.

This vulnerability is exploitable remotely on glibc-based Linux systems, where syslog() itself calls async-signal-unsafe functions (for example, malloc() and free()): an unauthenticated remote code execution as root, because it affects sshd’s privileged code, which is not sandboxed and runs with full privileges. We have not investigated any other libc or operating system; but OpenBSD is notably not vulnerable, because its SIGALRM handler calls syslog_r(), an async-signal-safer version of syslog() that was invented by OpenBSD in 2001.” – Qualys Security Advisory, July 1st 2024

For NAS users, the implications are severe, even if the actions required to utilize this exploit are quote long and require a specific system network setup to be at risk. Synology, QNAP, Asustor, TerraMaster, and TrueNAS all rely on secure remote access capabilities, which could be undermined by this vulnerability. While Synology has confirmed that their products are not affected as they utilize OpenSSH versions not susceptible to this flaw, other NAS vendors have yet to release official statements regarding their status. Users of QNAP and Asustor, in particular, should be vigilant and ensure their systems are updated to the latest firmware versions to mitigate any potential risks. Regular checks for vendor updates and security patches are essential to maintain the integrity of these systems.

In terms of mitigation, the immediate recommendation is to apply any available security updates for OpenSSH. As Qualys detailed in their advisory, the latest OpenSSH version 9.8p1 includes fixes for this vulnerability. Additionally, users are advised to restrict SSH access through network-based controls such as firewalls and to implement network segmentation to prevent lateral movement within the network. Implementing these measures can significantly reduce the potential attack surface and enhance the overall security posture of NAS environments.

For those who cannot update their systems immediately, setting the `LoginGraceTime` parameter to 0 in the sshd configuration file can temporarily mitigate the risk, although this may expose the server to denial-of-service attacks. This approach effectively disables the vulnerable signal handler by preventing unauthenticated connections from lingering beyond the initial handshake period. It is a stopgap measure that can be utilized while waiting for a more permanent fix through updates or patches. Despite the complexity of the exploit, which requires multiple attempts and the overcoming of Address Space Layout Randomization (ASLR), the potential use of AI tools to increase the success rate of exploitation adds to the urgency. The Qualys Threat Research Unit (TRU) has noted that AI-assisted attacks could overcome practical difficulties, making the vulnerability a more significant concern. This evolving threat landscape underscores the necessity for continuous monitoring and adaptation of security strategies.

(Example of 3rd party AI expliots to overwork an attack vulnerability – AKA ‘AI as a Service’ models)

It’s important to note that FreeBSD-based TrueNAS Core is unaffected by this vulnerability. This is due to the secure mechanism introduced in 2001 that prevents the signal handler race condition from being exploited on OpenBSD systems, which FreeBSD inherits. This security feature provides a significant advantage, ensuring that TrueNAS Core users remain protected against this specific threat without needing immediate updates or configuration changes. UPDATE – However a TrueNAS Scale user named @Cameronfrye5514 (system running Dragonfish-24.04.1.1) states that his system is running 9.2.p1 – so the linux version of TrueNAS definitely features affected OpenSSH version in at least some of it’s own respective firmware revisions:

Additionally, YouTube user @roehlaguila7930 highlighted that the latest Stable version of UnRAID uses OpenSSH OpenSSH_9.3p2.

Update 3rd July – QNAP has also now issued an entry into their Security Advisory for the OpenSSH vulnerability, related to their QTS and QuTS 5.2 Release Candidate, as it uses an impacted component version of OpenSSH. They also highlight that QTS 5.1.x, QTS 4.5.x, QuTS hero h5.1.x, h4.5.x, and QuTScloud c5.x are not affected. 

For users of QTS 5.2.0 RC and QuTS hero h5.2.0 RC, QNAP recommends keeping the SSH service disabled by default or not exposing the OpenSSH service to the internet. If you really need to use the OpenSSH service, they strongly recommend the following mitigations, Go to Control Panel -> Security -> IP Access Protection, and enable SSH. Avoid using port 22 (the default port number for SSH) before updating to the official releases of QTS or QuTS hero. Instead, configure SSH to use a different port number.

Update 3 – It appears TruenNAS Core and Scale were both in the affected update margin, and application of the OpenSSH patch can be monitored in this ticket – https://ixsystems.atlassian.net/browse/NAS-129828/ alongside a duplicate entry here – https://ixsystems.atlassian.net/browse/NAS-129829/

As always, staying informed and proactive is crucial. Users should regularly check for updates from their NAS manufacturers and follow best practices for network security. With over 14 million internet-exposed OpenSSH servers identified by Censys and Shodan, and 700,000 confirmed vulnerable instances based on Qualys CSAM 3.0 data, the scale of potential impact underscores the need for prompt action.

How to Secure Your NAS From The OpenSSH Vulnerability?

Regular vulnerability checks and revisiting security advisories are vital steps in maintaining a secure network environment. NAS users should consider implementing the following recommendations to enhance their security posture:

1. Apply Security Updates: Regularly check for and install the latest firmware updates from your NAS vendor. If the brand has not already implemented a change to OpenSSH that can be applied in the short term, they WILL apply a path for OpenSSH for affected versions as soon as it is issued by the creators

2. Restrict SSH Access: Use firewalls to limit SSH access to trusted IP addresses. This reduces the attack surface by only allowing connections from known sources, thereby minimizing the risk of unauthorized access attempts. If you do not have the skill set for this, DISABLE SSH settings on your NAS. Typically SSH should only be ‘on’ when it’s in use anyway. Again, if in double about your running version of OpenSSH on your NAS software, disable.

3. Implement Network Segmentation: Separate critical systems from other parts of the network. This limits the ability of an attacker to move laterally within your network if they compromise one system, providing an additional layer of defense. Exploitation of the vulnerability is only possible with admin/super user powers, so limit that power! This removes the attack vector and significantly reduces the risk, making your system less susceptible to remote exploitation attempts.

4. Monitor Network Traffic: Use intrusion detection systems (IDS) and intrusion prevention systems (IPS) to monitor and analyze network traffic for suspicious activity. Set up alerts for unusual login attempts or other potentially malicious actions to enable quick response to threats. This vulnerability needs a lot of time to hit the system (6-8 hours was suggested by Qualys

5. Use Strong Authentication Methods: More of a top layer suggestioned, but useful nonetheless to add hurdles and barriers to unauth access – Implement multi-factor authentication (MFA) for SSH access. This adds an additional layer of security by requiring more than just a password for access, thereby reducing the likelihood of unauthorized access.

6. Regularly Review Access Logs: Periodically review SSH access logs for any unauthorized attempts or unusual patterns. Early detection of suspicious activity can help prevent successful exploitation by allowing timely intervention and mitigation. As mentioned earlier, this exploit requires ALOT of repeated access – so numerous failed attempts will be a dead giveaway that this vulnerability is attempting to be exploited. Also, enabling auto-block settings is HIGHLY recommended!

Is Your NAS OS Running a compromised version of OpenSSH? Here is how to check

To determine if your NAS system is affected by the regreSSHion vulnerability, you need to check the version of OpenSSH running on your device. This can be done easily using an SSH client like PuTTY.

Once you have logged into your NAS via SSH, you can check the OpenSSH version by entering the following command:

ssh -V

This command will display the version of OpenSSH installed on your system. If the version falls within the affected range (8.5p1 to 9.7p1), you should take immediate action to update to the latest version. Keeping your OpenSSH version up-to-date is crucial in protecting your system from known vulnerabilities and exploits.

How Much Should NAS Users Be Concerned About the OpenSSH Vulnerability?

The risk posed to NAS users by the regreSSHion vulnerability is debatable, due to several mitigating factors that make exploitation highly impractical. Firstly, the NAS system would need to be running an operating system that includes the specific affected versions of OpenSSH (8.5p1 to 9.7p1). Additionally, the system must be internet-facing with SSH access enabled, making it accessible to remote attackers. Even under these conditions, the exploit requires an extended period of sustained access attempts, typically over many hours, to achieve the necessary memory corruption to successfully exploit the race condition. During this time, a vigilant system administrator monitoring access logs would likely detect the suspicious activity and take corrective action, further reducing the likelihood of a successful attack.

Moreover, many NAS configurations are behind firewalls and utilize network segmentation, limiting the exposure of SSH services to the wider internet. Implementing strong authentication methods, such as multi-factor authentication (MFA), further protects against unauthorized access attempts. Regularly updating the NAS firmware and the OpenSSH version also mitigates the risk by ensuring that known vulnerabilities are patched. In practical terms, an attacker would need to sustain a continuous and sophisticated attack vector without interruption, which is highly unlikely in well-managed network environments. These layers of defense, combined with vigilant monitoring and best security practices, make the successful exploitation of regreSSHion on NAS systems a remote possibility. Users are advised to follow recommended security measures to ensure their systems remain secure against such threats.

Be Regularly Updated on Security Concerns with Synology & QNAP NAS

Recently there has been a spotlight on some NAS brands and their security and protection from attacks by hackers and online intruders. In some cases, this has been down to holes being found in the system software or system protocol over time that, if left unpatched can lead to Ransomware like the QNAP QLocker of 2021, the Synology Synolocker of 2014. Typically, these can stem from many methods but ultimately revolve around hackers boarding the latest firmware and finding loopholes/backdoors within the system software each time it has an official update. This is not unusual and practically ALL the computer software-related services and hardware in your home/business environment go through this – most updates to the firmware in everything from your phone to your TV, router, console and more are specifically designed to close these newly found chinks in the armour. It is a constant game of cat and mouse, however, in almost all cases the vulnerability in software (that led to your system being penetrated) will be down to the fact your device has not been updated in firmware/software in a considerable length of time.

The NASCompares NAS Vulnerability Alerts and Updates Page – HERE

---

 

📧 SUBSCRIBE TO OUR NEWSLETTER 🔔

🔒 Join Inner Circle

This description contains links to Amazon. These links will take you to some of the products mentioned in today's content. As an Amazon Associate, I earn from qualifying purchases. Visit the NASCompares Deal Finder to find the best place to buy this device in your region, based on Service, Support and Reputation - Just Search for your NAS Drive in the Box Below

Need Advice on Data Storage from an Expert?

Finally, for free advice about your setup, just leave a message in the comments below here at NASCompares.com and we will get back to you. Need Help? Where possible (and where appropriate) please provide as much information about your requirements, as then I can arrange the best answer and solution to your needs. Do not worry about your e-mail address being required, it will NOT be used in a mailing list and will NOT be used in any way other than to respond to your enquiry. TRY CHAT Terms and Conditions   Alternatively, why not ask me on the ASK NASCompares forum, by clicking the button below. This is a community hub that serves as a place that I can answer your question, chew the fat, share new release information and even get corrections posted. I will always get around to answering ALL queries, but as a one-man operation, I cannot promise speed! So by sharing your query in the ASK NASCompares section below, you can get a better range of solutions and suggestions, alongside my own.

☕ WE LOVE COFFEE ☕