The Story of regreSSHion: A Resurfaced sshd Vulnerability

What Is regreSSHion?

The regreSSHion (CVE-2024-6387) vulnerability is an unauthenticated remote code execution flaw found in OpenSSH servers (sshd) on glibc-based Linux systems. If exploited, it allows full root access to the targeted machine without user interaction. This vulnerability is classified as High severity (CVSS 8.1).

The Ghost of the Past

• 2006 OpenSSH faced a similar regression vulnerability (CVE-2006-5051), which was patched.

• In this context, a regression means that a flaw, once fixed, has reappeared in a subsequent software release, typically due to changes or updates that inadvertently reintroduce the issue.

• Fast forward to 2020: OpenSSH 8.5p1 introduced a transformative patch that resolved the issue.

• But fate had other plans—regreSSHion resurfaced due to the accidental removal of a critical component in versions between 8.5p1 and 9.8p1.

Affected Versions

The Vulnerable Range

• Versions earlier than 4.4p1 are vulnerable unless patched for CVE-2006-5051 and CVE-2008-4109.

• Versions from 4.4p1 up to (but not including) 8.5p1 are safe due to the transformative patch.

• The danger zone: Versions from 8.5p1 up to (but not including) 9.8p1.

Vulnerability Technical Details

On July 1, 2024, OpenSSH released version 9.8/9.8p1, which addresses the critical race condition vulnerability (CVE-2024-6387). The release note further discusses the details of this vulnerability. Below are the details shared as of July 3, 2024:

Exploitation Details

• Demonstrated Exploitation: Successful exploitation has been shown on 32-bit Linux systems using glibc with Address Space Layout Randomization (ASLR) enabled. Under controlled lab conditions, the attack requires 6-8 hours of continuous connection attempts, up to the server's maximum allowed connections.

• Potential for 64-bit Systems: Although exploitation on 64-bit systems has not been demonstrated, it is considered possible and likely to be improved upon by attackers.

• Non-glibc Systems: While exploitation of non-glibc systems is conceivable, it has not been examined.

• ASLR Considerations: Systems without ASLR or downstream Linux distributions that have turned off per-connection ASLR re-randomization may be more susceptible to more effortless exploitation.

Attack Vectors

• Continuous Connections: The attack requires continuous connections over an extended period, taking advantage of the race condition in the sshd(8) process.

• ASLR Bypass: The exploitation demonstrated relies on ASLR to increase the chances of success. Systems lacking ASLR may be more vulnerable.

Detection with Logpoint

We have specially produced a playbook to identify whether your environment's Linux systems are vulnerable to CVE-2024-6387.

The following SQL query is executed through Osquery on each machine, and the results are reflected in Logpoint.

This query evaluates the vulnerability status of OpenSSH packages installed on a system by looking at packages maintained by DEB and RPM package managers. It discovers OpenSSH packages, obtains their version numbers, and determines if they are susceptible, not vulnerable, or potentially vulnerable based on their version. The output of both package managers is aggregated into a table containing the package manager type, package name, version, and vulnerability status.
The information that was returned can be visualized from Logpoint Case Management.

For better aggregation and visualization of the data, you can also use a Logpoint Search Query, as this information is also indexed in Logpoint SIEM. You can copy the query from the Case Management Window and start your aggregation.

This query provides a list of agents with the openssh-server installed with their respective versions. If the version falls into a vulnerable range, the corresponding vulnerability status is displayed in the vulnerability_status column.

If you wish only to see the vulnerable machines, you can use the query below:

If the above options are not feasible, you can use the provided bash script to check for vulnerability locally.

Suppose you suspect your device has been hacked. In that case, you may mitigate the risk by isolating it or blocking the suspicious IP address through AgentX.

Mitigation Strategies

The most efficient mitigation strategy is to recognize all vulnerable devices and patch them to the latest version, OpenSSH 9.8/9.8p1. If this is not possible, several other mitigation strategies can be implemented, which are detailed below.

Immediate Actions

1. Apply Patches and Updates:

   • To mitigate the issue, immediately install any available patches or updates from your SSH vendor or operating system.

   • According to Qualys, if updating or recompiling sshd is not an option, set LoginGraceTime to 0 in the configuration file. While this setting may lead to a denial-of-service attack by exhausting all MaxStartups connections, it mitigates remote code execution risk.

2. Disable SSH Temporarily:

   • To avoid exploitation, deactivate SSH access until the vulnerability is addressed.

3. Restrict IP Access:

   • Use firewall rules or security groups to limit SSH access to only trusted IP addresses.

4. Disable Root Login:

   • Edit your SSH configuration (/etc/ssh/sshd_config) and set PermitRootLogin no.

5. Use Strong Authentication Methods:

   • Disable password-based authentication and instead utilize key-based authentication. Make sure the PasswordAuthentication number is set in your SSH settings.

6. Implement Multi-Factor Authentication (MFA):

   • Use multi-factor authentication for additional security layers so that even if the vulnerability is exploited, it is inaccessible without the MFA key.

Long-term Hardening

1. Change Default SSH Port:

   • Modify the default SSH port(22) to a nonstandard port to minimize automated attacks.

2. Use SSH Key Management:

   • Regularly rotate SSH keys and ensure they have strong passphrases.

   • Use tools like ssh-agent and ssh-add to manage your keys securely.

3. Enable SSH Logging and Monitoring:

   • Enable verbose logging for SSH (LogLevel VERBOSE in sshd_config).

   • Regularly monitor logs for suspicious activities using tools like fail2ban or SIEM systems like Logpoint SIEM.

4. Implement Intrusion Detection Systems (IDS):

   • Deploy an IDS such as Snort or OSSEC to detect and respond to real-time suspicious activities.

5. Limit User Access and Use AllowUsers or AllowGroups:

   • Use AllowUsers or AllowGroups directives in sshd_config to limit which users or groups can access SSH.

6. Use a Bastion Host:

   • Set up a bastion host to act as a gateway for SSH access, reducing the attack surface and centralizing logging and monitoring.

7. Implement Network Segmentation:

   • Create segmentation on your network to minimize the impact of a compromised SSH server.

8. Regular Security Audits and Penetration Testing:

   • Regular security audits and penetration testing are necessary to identify and mitigate vulnerabilities.

9. Harden SSH Client Configurations:

   • Ensure your SSH clients are also configured securely, using strong ciphers and algorithms (Ciphers, MACs, and KexAlgorithms in ssh_config).