Loving this worlds technology is something we have embraced with open arms, but implying security is a necessary measure which is just as important as embracing it. Many of us want to make our network safe or even make our devices highly protected. We can achieve it by making it secure by using OpenSSH's server (sshd) as a secure door for our devices. But still, one of the most believed server - OpenSSH's server can also have vulnerability - CVE-2024-6387.
You may also like to read: SploitScan: Find Latest CVE Documentation and Exploitation With All Details
Background and Nature of the vulnerability
CVE-2024-6387 is referred as 'regression' because it has reoccurred in the mean time. A vulnerability CVE-2006-5051 was first discovered in 2006 in OpenSSH version 4.4p1. In October 2020, during a revision of the logging infrastructure in OpenSSH 8.5p1, the vulnerability was inadvertently reintroduced. And this regression remained unidentified until its discovery in 2024.
The vulnerability is basically a timing problem (race condition) in OpenSSH's server. It happens when a user comes across authentication failure, within 120 seconds, a background process (SIGALRM handler) runs unsafe functions. This can mess up memory (heap corruption), giving an opportunity to hackers to exploit the system.
Affected Versions
This vulnerability affects OpenSSH versions 8.5p1 to 9.7p1 on Linux systems but not on OpenBSD. It mainly targets 32-bit computers (x86), but 64-bit systems (amd64) could also be at risk in theory. Since OpenSSH is widely used for remote server access, this flaw could allow attackers to take full control of vulnerable systems, making it a serious security threat.
How Hackers hack using this vulnerability
Hacking CVE-2024-6387 isn’t easy—it requires advanced skills. As OpenSSH's server (sshd) is so secure, even exploiting this vulnerability is no easy task. Attackers must repeatedly trigger the timing flaw (race condition) many times over a long period to successfully take control of a system. The code needs to be exploited need highly skilled attackers as there is no ready-made attack tools available publicly.
Steps to Secure OpenSSH
- Update OpenSSH: If a vulnerability has been addressed in your your current OpenSSH version, upgrade to the next version.
- Modify SSH Configuration: Reduce LoginGraceTime - lower the LoginGraceTime parameter in the sshd_config file to minimize the window for potential exploitation. Setting it to 30 seconds is advisable. Disable Root Login - If not necessary, set PermitRootLogin to no to prevent direct root access via SSH.
- Monitor and Audit: Taking caution and regularly monitoring SSH access logs for unusual authentication attempts is a must. To get notified about suspicious activities, we implement intrusion detection systems.
Conclusion
CVE-2024-6387 is a reminder that old security flaws can return when code changes over time. OpenSSH infrastructure has always aimed to protect everyone’s privacy and security, yet vulnerabilities can still emerge, even in the most secure systems. This highlights the importance of regular security checks and timely updates. To stay protected, admins must prioritize security by promptly assessing their systems, applying patches, and following best practices to prevent potential attacks.
