Apache Struts Distraction Continues While Over 600 Additional Vulnerabilities Have Been Released

While everyone has been heavily focused on, or we could say distracted by, the recent Apache Struts vulnerability, the steady flow of additional vulnerabilities being disclosed continues. As we recently pointed out, the flood of vulnerabilities is not letting up this year. They range from the fairly mundane that likely affects few people, to ones that are not as severe but likely impact every major organization, to the truly bad ones like the Struts vulnerability. We figured this would be a good time to give some attention to one of the medium severity issues that may escape notice by organizations frantically patching Struts.

On July 30, 2018, Dariusz Tytko (securitum.pl) and Michał Sajdak contributed a commit to the OpenSSH package maintained by OpenBSD that had a fairly innocuous commit message: “delay bailout for invalid authenticating user until after the packet containing the request has been fully parsed.” This commit went largely unnoticed despite its security impact. On August 15, security firm Qualys posted a message to the OSS-sec mail list pointing out this commit, its security impact, and noting that it deserved a CVE assignment. A day later, a working exploit was posted to PacketStorm. The following day, CVE assigned an ID for the issue (CVE-2018-15473)

This in turn led Bleeping Computer to cover the vulnerability on August 22nd, where they also pointed out that it affects all versions of OpenSSH released in the past two decades. A day later, Sophos’ Naked Security blog wrote about the vulnerability as well, saying: “no the sky isn’t falling.

As with the Apache Struts vulnerability, which has increasingly gotten more attention in news articles and mentions on social media, this OpenSSH enumeration vulnerability is also getting some attention. This is one of the factors that goes into the VulnDB Social Risk Score, which we assign to vulnerabilities to better highlight issues that may fly under the radar due to a low CVSS score or perception that the issue is not serious.

OpenSSH Delay Bailout Packet Parsing Remote Username Enumeration Weakness

Looking at VulnDB, we see that this vulnerability has a 5.0 CVSSv2 base score, but it can be triggered remotely, has a publicly available exploit, and as mentioned the Social Risk Score is high. As we have seen, there are some organizations that prioritize solely on CVSS scores and may potentially ignore this issue.

One of the reasons that this issue may be more serious than it initially appears on the surface is that it affects just about every Linux distribution out there, as OpenSSH is enabled by default. Versions between 5.9, released on September 6, 2011, and version 7.8, released on August 24, 2018, are impacted. This means that a high percentage of Unix-flavored systems are impacted by this vulnerability.

Enumeration vulnerabilities, which allow a remote attacker to slowly and systematically determine information about a system, have long been debated in the Information Security community. Some argue that due to the time and effort required, they are not serious, and that other mitigations make them even less severe. For example, do organizations care that an enumeration attack carried out over ten days might reveal dozens of valid usernames on a system when a strong password policy implemented would make guessing a password almost impossible? While that is a great point, others argue that a dedicated attacker might just be able to do that or use the information on a mismanaged system that doesn’t have a policy properly enforced. Worse, if they are using a public repository of credentials collected from prior data breaches such as tracked in Cyber Risk Analytics, the chances of them knowing a password without having to conduct a brute-force attack go up significantly.

Another point to remember is that enumeration attacks, like remote path disclosures, may not be serious unto themselves but may be one of the first steps in a longer exploit chain. That username may carry over to a web application that doesn’t enforce as strong of a password policy as the underlying Unix system. That username may be an avenue to enumerate additional information via a web-based user directory, giving access to files that were not meant to be public. While most professionals will say that “security through obscurity is no security at all”, obscurity definitely has a place in a defense-in-depth approach. Even if it is not intentional, obscurity often works as additional security for organizations (even if only slightly).

Regardless of where your beliefs sit on the enumeration severity spectrum, it is important to note that organizations relying on vulnerability intelligence from CVE/NVD are still in the dark. Like hundreds of other vulnerabilities, both critical and minor, NVD has not assigned a CVSS score or CPE details to this issue.

While details and news coverage continues coming out on the OpenSSH enumeration issue, it was revealed that Dropbear SSH, a popular replacement for OpenSSH, also has a similar remote enumeration issue. The exploit for OpenSSH works equally well against Dropbear SSH. To top it all off, a second OpenSSH remote enumeration issue was disclosed on August 27th (CVE-2018-15919), and like the first one, you guessed it, it is still awaiting analysis by NVD.

Looking at the bigger picture, VulnDB has over 500 remote enumeration vulnerabilities in which an attacker can potentially determine multiple pieces of information about a system (e.g. valid usernames, file existence, user groups, password policy, etc.). Almost 300 of those are cases where an attacker can enumerate valid account names. Sixteen of those are in SSH services. Nine of those SSH-based enumeration vulnerabilities are in OpenSSH, meaning that while this may not be considered as serious a vulnerability by some, the issue keeps coming back.

Each organization, of course, needs to prioritize patching and remediation based on their own networks, assets, and exposures. However, as always, we want to remind organizations that a CVSS score should not be the only factor to consider. Given the attention that this vulnerability is getting, this issue is something that we recommend each organization quickly evaluate, and if deemed an exposure, work on prioritizing the fix.