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 PageHERE


 

📧 SUBSCRIBE TO OUR NEWSLETTER 🔔


    🔒 Join Inner Circle

    Get an alert every time something gets added to this specific article!


    Want to follow specific category? 📧 Subscribe

    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.

      By clicking SEND you accept this Privacy Policy
      Question will be added on Q&A forum. You will receive an email from us when someone replies to it.
      🔒Private Fast Track Message (1-24Hours)

      TRY CHAT Terms and Conditions
      If you like this service, please consider supporting us. We use affiliate links on the blog allowing NAScompares information and advice service to be free of charge to you.Anything you purchase on the day you click on our links will generate a small commission which isused to run the website. Here is a link for Amazon and B&H.You can also get me a ☕ Ko-fi or old school Paypal. Thanks!To find out more about how to support this advice service check HEREIf you need to fix or configure a NAS, check Fiver Have you thought about helping others with your knowledge? Find Instructions Here  
       
      Or support us by using our affiliate links on Amazon UK and Amazon US
          
       
      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 ☕

       

      locked content ko-fi subscribe
      Private 🔒 Inner Circle content in last few days :
      (Early Access) PLEX PASS - Price Increases Coming?
      (Early Access) How to Install UnRAID/TrueNAS on a UGREEN NAS - A Quick Install Guide
      (Early Access) The UnRAID 7 Beta - The Highlights (with Ed ‪@SpaceinvaderOne‬ )
      Why Is This 1TB USB SSD $149? And Is It Safe?
      (Early Access) Best User Friendy NAS OS for Your DiY/BYO NAS Build
      (Early Access) CLOUD Prices vs NAS Prices - HOW MUCH??????
      (Early Access) How to Use a Phone as a PLEX MEDIA SERVER - Complete Tutorial
      (Early Access) UGREEN NAS Software Review - 3 Months Later!
      (Early Access) Synology - Becoming TOO Enterprise?
      (Early Access) What Is Cloud Data Egress - And Why it SUCKS!
      (Early Access) QNAP vs UGREEN NAS - The Whole Package?
      (Early Access) The PROs and CONs of UniFi Networking
      Access content via Patreon or KO-FI

      DISCUSS with others your opinion about this subject.
      ASK questions to NAS community
      SHARE more details what you have found on this subject
      CONTRIBUTE with your own article or review. Click HERE
      IMPROVE this niche ecosystem, let us know what to change/fix on this site
      EARN KO-FI Share your knowledge with others and get paid for it! Click HERE

      ASK YOUR QUESTIONS HERE!

      81 thoughts on “The OpenSSH regreSSHion Vulnerability – TURN OFF SSH RIGHT NOW ON YOUR NAS

      1. Update on this;
        At the moment, while there are reports of a public POC, there are no known actual exploits in the wild against this vulnerability.
        And some security vendors also have stated that they can’t get the public POC to work.
        Also how this exploits works, it will requires, due to the racing condition, a lot of luck and well over 100K attempts to even get close – so “real world” exploitation at this point against systems that have basic protection against DDOS or other repeated attack attempts may help to thwart some of this.
        Such as the previous outlined “block IP after repeated failed login attempts”.
        And it is general security hygiene to turn off features, protocols etc if they are not used, so turning SSH off is the best practice.
        REPLY ON YOUTUBE

      2. Once again, I’m grateful my public-facing server is running OpenBSD, which, according to an article in The Register, has been immune to this exploit since 2001.
        REPLY ON YOUTUBE

      3. SSH literally has been well known not to be truly secure. I’ve had it off for years and only when i need it for a short time limit for a valid specific reason.
        REPLY ON YOUTUBE

      4. @nascompres TrueNAS Core update available here: https://forums.truenas.com/t/truenas-core-13-0-u6-2-is-now-available/7909

      5. Why would you open ssh on a NAS? It’s not really a normal use on a NAS unit. Of course if you build your own NAS system ssh is a good tool. But this vulnerability is patched, which means a quick system update will fix the issue. Not sure how long off the shelf NAS systems take to update their software.
        REPLY ON YOUTUBE

      6. It always made sense to me to keep SSH/FTP/Telnet and that type of stuff off. Just turn it on if you need to use it, and shut it down again. Also my router doesn’t port forward to it.
        REPLY ON YOUTUBE

      7. Never port map your SSH port and never use port 22 if you have to port mapping .
        If someone is in your network and can get to SSH without port mapping their is nothing you can do .
        REPLY ON YOUTUBE

      8. Duly noted. Turns out my Synology did have it enabled, though I do know it is not available to the outside world. Still, wasn’t aware it was even listening, so I’ve turned that off. Thanks for the heads up.
        REPLY ON YOUTUBE

      9. Is there a special port to block on my modem or router as I have no idea if anything at home has ssh and I do have NASs but only turned on when I need it?. I know nothing about security, I rely on my virus checker/internet security software.
        REPLY ON YOUTUBE

      10. If your NAS isn’t exposed to the internet, there is no reason to turn it off. That means you are behind a NAT. No one can get to it but you. Disappointed in the scare video. Just wait for the patch.
        REPLY ON YOUTUBE

      11. Why this panic sounding video “RIGHT NOW” … for the CVE-2024-6387 vulnerability that was widely announced back in May 2024, over a month ago ?

        The energetic encouragement to act may be appropriate, but the “click bait” title and presentation, as if some NEW, like right now, this day (or at least this week), is inappropriate, in my view at least.
        REPLY ON YOUTUBE

      12. 0:54 I disagree. The majority should have ssh enabled, as it is one of the simplest ways to manage any machine over the network.
        Your security should be mainly in front of your devices (firewalls), not on them (disabling services).
        REPLY ON YOUTUBE

      13. Nope. I use SSH extensively. I’ve changed ports years ago and am behind a firewall. As best I can tell QNAP is not impacted. The statement that SSH is not secure is factually false. You still need to authenticate to the system. Yes the vulnerability is a problem. But under normal circumstances its fine.
        REPLY ON YOUTUBE

      14. Did you actually read that write-up? It’s an extremely theoretical attack that is currently unfeasable to pull off on 64 bit operating systems. So almost all Nas systems from the past 10 years are NOT vulnerable, even if it has an affected version of ssh. On 32 bit it could take weeks.
        REPLY ON YOUTUBE

      15. It’s far from massive. This is just spreading FUD.
        Yes, an attack is possible – but on 32bit systems it takes thousands of hours to set up.
        On 64bit it hasn’t been executed at all so far.
        So because this is fairly expensive to perform, don’t worry about your private porn collection.
        REPLY ON YOUTUBE

      16. Your SSH should be behind wireguard. Wireguard doesn’t respond to port knocking or anything. You should have to connect to wireguard before being able to connect to SSH. Rookies.
        REPLY ON YOUTUBE

      17. If you had left SSH (any implementation) with an open port on anyt public-facing IP, you do not deserve to have any NAS anyway… it’s giving away the stick to get beaten
        REPLY ON YOUTUBE

      18. Somebody please correct me if I’m wrong, but as long as your device isn’t open to the internet (either because it is in the DMZ, or because you’re forwarding port 22 to your device), then you shouldn’t have much to worry about.

        I have a lot of device with ssh accessible, but none of them are accessible by the internet.
        REPLY ON YOUTUBE

      19. I use debian for my plex server, ssh version is in the range, I use “sudo systemctl stop ssh” and “sudo systemctl disable ssh” to turn it off and deactivate it. Thanks for the useful video !
        REPLY ON YOUTUBE

      20. All the people wanking now because they ran an outdated version – with open vulns that they just never even found out about 😉

        for the record: FreeBSD had the fixes yesterday, and on i.e. Alpine you can switch to dropbear SSH for the moment, many other embedded systems have dropbear too.
        REPLY ON YOUTUBE

      21. Its not SSH which is the problem. Its XZ Util andover SSH it allows you to execute code on the targeted system. There are actually a lot of requirements you need to fullfil that someone can actually do it.
        REPLY ON YOUTUBE

      22. @NASCompares – FreeBSD and OpenBSD are not the same thing. TrueNAS Core is based on FreeBSD 13.0, which does not have the safer syslog call, and is also using a vulnerable version of OpenSSH.
        REPLY ON YOUTUBE

      23. Hi. Can you please make a video how to install Nextcloud on the Ugreen NAS? With remote access via domain? Would be awesome just like your plex video.
        REPLY ON YOUTUBE

      24. Unless you’re forwarding the SSH port or reverse proxying SSH, I don’t see how this is a problem. Especially if you only allow authentication by key authentication like you should.
        REPLY ON YOUTUBE

      25. SSH (and Telnet) should normally be turned-off by default. And only be turned-on an a need-to-do-so basis, for the shortest time possible whilst monitoring all the time.
        Some NAS systems, such as QNAP also have IP Access Protection, a relatively effective method for blocking those IP’s who fail to login too many times.
        And of course, QuFirewall should be installed and be turned-on, at least at the Basic level.
        And while you at it for security, I would also strongly recommend looking into which version SMB you are using and supporting (from your client-side) and also the TLS version. Setting these to higher security-levels is one I would also recommend.
        REPLY ON YOUTUBE

      26. *UPDATE* – If your OpenSSH version is between 8.5p1 and 9.7p1 – IT CONTAINS THE AFFECTED VERSION OF OpenSSH. I will add versions affected to this pinned comment (as they are shared). Hoping to stay on top of this as much as possible until OpenSSH (and in turn, the main NAS brands) roll out fully appropriate patch as needed. Additionally, you can use the article here to find out more – https://nascompares.com/2024/07/02/the-openssh-regresshion-vulnerability-turn-off-ssh-right-now/

        TrueNAS Scale Dragonfish-24.04.1.1. – 9.2p1 version ( @leonidiakovlev )
        REPLY ON YOUTUBE

      27. I found that ssh was turned on on one of my QNAP’s. I normally have it turned off everywhere so I have to wonder if this was turned on with an update. So, even if you are convinced that your ssh is turned off, check it anyways.
        REPLY ON YOUTUBE