regreSSHion gap: New SSH feature offers protection, proof of concept is none
A Qualys researcher explained the severity of the problem in an interview with heise security. A major new OpenSSH function additionally secures the service.
There are often indications of attempted attacks in the SSH access logs.
(Image: Paolo De Gasperis/shutterstock.com)
A security problem called "regreSSHion" in OpenSSH can lead to the execution of arbitrary (malicious) code, but is difficult to exploit. Nevertheless, the first "proof-of-concept" alleged exploits appeared on the web a few days after release, and a vulnerability scanner is also in circulation. Meanwhile, the OpenSSH development team has not only fixed the programming error in the current version, but has also built in blocks against future attacks.
Fake exploits on GitHub
A few days have passed since the publication of a remote code execution vulnerability in OpenSSH and exploit code is already in circulation. A search for the CVE ID CVE-2024-6387 on GitHub reveals several alleged PoCs (Proof of Concept), mostly copies of a program by a security researcher with the pseudonym "7etsuo". Caution is advised when using such PoC exploits: Unwanted side effects and backdoors introduced by free riders can cause a lot of trouble for the curious.
According to the discoverers of the vulnerability, the 7etsuo exploit is not real: "It looks great, but does nothing. A working proof of concept for this vulnerability would be much more extensive and complex and will require much more development time than this one," is the assessment of the Qualys researchers on the oss-security mailing list.
The Linux distributions Ubuntu and Debian have now reacted and made updated OpenSSH packages available – However, users of Red Hat 9 will have to be patient. They should use one of the workarounds (see section"Workaround for patch mufflers").
If IT administrators want to quickly test their server zoo for vulnerability, they can use a handy tool from Alexander "xaitax" Hagenah: The script, written in Python, can check entire network areas for regreSSHion-prone SSH services. To do this, it compares the version identifier transmitted when the connection is established à la SSH-2.0-OpenSSH_9.6p1 Ubuntu-3ubuntu13.3 with a list of vulnerable versions.
Every sixth SSH server worldwide vulnerable
The Shadowserver project has now also included the CVE-2024-6387 vulnerability in its statistics. Of around 24 million SSH servers accessible via the Internet worldwide, 4 million are vulnerable, i.e. one in six. Most vulnerable SSH servers are located in the United States, with Germany in second place with just under 700,000 servers. This figure is likely to fall significantly over the next few weeks once patches have been applied.
(Image: The Shadowserver Project)
Over 1000 working hours until the exploit
The project manager responsible for "regreSSHion" at Qualys, Saeed Abbasi, explained some details of his team's work in an interview with heise security. First of all, he somewhat limited the severity of the bug – contrary to the editorial team's initial assumption, the CVSS score is only 8.1 and the bug is therefore not critical, but only a high priority. Nevertheless, unpatched servers can be successfully attacked within a few hours, according to Saeed: In tests carried out by his teams, 98-99 parallel connections were easily established. In the standard configuration, the SSH server randomly starts to reject further connections after 10 parallel connection attempts in order to avoid an overload attack(MaxStartups 10:30:100).
From the discovery of the vulnerability to the coordinated publication of the detailed article on regreSSHion, over a thousand hours of work went into the project, Abbasi continues. Although a large part of the work was carried out by a small core team, the entire team from the Vulnerability Research department contributed their mite.
OpenSSH 9.8 with built-in brute force protection
In addition to the bug fix for regreSSHion, the current version 9.8 of the OpenSSH server contains new configuration directives to penalize improper clients. Frequent false logins or even server crashes serve as an indication to the server of attempted attacks and result in log-in blocks. This helps against exploits such as regreSSHion, but also against the usual password guessing games that occur in their thousands on every server connected to the Internet.
Administrators can control very precisely in which situations the SSH server distributes which penalties. heise security has taken a look at the new setting options. First of all: A freshly installed OpenSSH server in version 9.8(p1) comes with sensible-looking default settings, which we list below after a colon. The new blocking functions are also activated by default and therefore do not need to be entered separately in the configuration.
However, if the system administrator wishes to make changes to the settings, various options are available, which are appended to the PerSourcePenalties directive separated by spaces:
The OpenSSH server can include not only the conspicuous IP address, but also others from the same network block in the block in order to block attacks from compromised networks. With the configuration directive"PerSourceNetBlockSize", the system administrator controls which CIDR netmask is used for IPv4 and IPv6 addresses. In the default setting 32:128, individual IP addresses are considered, a setting such as 24:48 would include the respective /24 or /48 subnet.
Admins can also define a whitelist called "PerSourcePenaltyExemptList" so that their own management networks are not inadvertently excluded. This contains a comma-separated list of IP addresses in CIDR notation, i.e. with the netmask. The configuration line PerSourcePenaltyExemptList 192.168.178.0/24 is therefore sufficient to add the typical Fritz!Box subnet to the positive list.
Notbehelf for patch grouches
However, apart from Slackware, none of the better-known Linux distributions currently offer OpenSSH 9.8 as a package –, so it will probably be a while before every administrator can enjoy the new configuration options. Until then, it is better to use other measures if you cannot or do not want to install an update directly.
Admins can eliminate the "race condition" on which the attack is based by giving SSH clients an unlimited amount of time to successfully log in using"LoginGraceTime 0" in the SSH configuration file (usually /etc/ssh/sshd_config). However, the risk of this setting is that attackers can use all available SSH connection options on the server, which are then never released again due to the lack of a time limit. Legitimate users would thus be locked out.
System administrators can also get to grips with the regreSSHion exploit using tools such as fail2ban. As attack attempts look similar to normal brute forcing, a fail2ban configured for SSH monitoring (as described in this guide, for example) should already offer some protection.
However, admins should be aware of all blocking measures: By using botnets or "residential proxies", criminals can access hundreds of thousands of different IP addresses to launch their intrusion attempts. Only an update of the OpenSSH server offers one hundred percent protection against regreSSHion.
(cku)
