New vulnerabilities and attack vectors emerge almost daily. The less time between the active exploitation by hackers and the detection through defense teams, the higher the chance that attacks can be fended off. While SRLabs conducts research on both vulnerabilities (e.g., reverse engineering, black box testing) and exploitations (e.g., honeypots, network monitoring), this blog post shares interesting results from our research on zero-day vulnerabilities.
We analyzed the most commonly captured payloads we had gathered in a separate honeypot project throughout the last year, which will be covered in future blog posts. Most of the roughly 100 unique payloads were related to known vulnerabilities for which patches existed. However, the question arose whether these patches were complete (i.e., correct and comprehensive) since recent research had shown that some patches merely paper over specific attack vector instead of tackling the root cause of the vulnerability.
With this in mind, we dug deeper into the vulnerability and patch for CVE-2020-9054, a pre-auth command injection in ZyXEL NAS devices. We found that the patched vulnerability was still exploit-able due to this type of incomplete patching.
CVE-2020-9054 affects ZyXEL NAS devices. These network attached storage devices allow authorized users to store and access data at a central location. NAS devices are attractive target for hackers since they are likely to hold sensitive data. The devices are increasingly deployed in smaller and medium-sized enterprises around the world, which often lack attack detection and mitigation resources compared to larger enterprises.
The vulnerability covered in CVE-2020-9054 is a pre-authentication command injection that may allow a remote unauthenticated attacker to execute arbitrary code on a vulnerable device. If the username parameter contains certain characters, it can allow command injection with the privileges of the web server that runs on the ZyXEL device. Although the web server does not run as the root user, ZyXEL devices include a setuid utility that can be leveraged to run any command with root privileges.
Figure 1 shows an exploitation attempt with CVE-2020-9054 against our honeypot:
After observing the vulnerability being exploited in the wild, we investigated the patch that should address the issue. The patch was released by ZyXEL in early 2020. What stood out was that the actual vulnerability was not located in the code section that the CVE suggested, but in a custom PAM module used by it. Diving deeper, we found that the patch only prevents the vulnerability from being exploited through the device’s HTTP port (e.g., Port 80) by applying a regex to a code section that was, in fact, not actually vulnerable. The vulnerability itself, which is located in the PAM module (Figure 2), could still be reached through other open ports.
Aside from the port exploited by the original exploit, the ZyXEL NAS also exposes a second interface: Port 21 for FTP services. The FTP uses the PAM module for authentication and hence affected by the same issue in that PAM module. We managed to inject a slightly different payload via the username field of FTP (Figure 3). This allowed us to exploit the underlying vulnerability in supposedly patched systems and inject arbitrary commands as root. This demonstrates that malicious actors could have fully compromised affected hosts and run arbitrary code at the highest level of privilege (Figure 4). While we did not find any evidence for active exploitation in our data, exploitation cannot be ruled it out.
SRLabs has reported the issue to ZyXEL, who replied that it should be considered a separate issue because the attack vectors are different. We requested a CVE ID for the slight variation of CVE-2020-9054 (no response at the time of publishing this blogpost) and a new patch should be released shortly. A quick Shodan search yields around 2-3k vulnerable devices.
This is not the first time that a patch issued by a vendor does not solve the underlying problem. In such cases, attackers often just need to tweak their exploits slightly to use them again successfully [1].
Examples of superficial fixes are routine. Through our research we have found multiple vulnerabilities that were publicly reported to be a consequence of incomplete or inadequate patches of older issues. This shows how developers and security engineers tend to resolve security issues by focusing on a given attack vector instead of tackling the underlying vulnerability that often remains present after patching. Time pressure may be one reason for that.
For instance, another example of a vulnerability that could be exploited again after a patch was released is CVE-2019-16759. This issue affects vBulletin, a popular software for managing online forums, and it is the template rendering engine allowing an attacker to execute PHP code by sending a malicious request. Through disclosure of this vulnerability a patch was released implementing additional checks for the template that was rendered and preventing CVE-2019-16759 from being exploited.
Approximately a year later, the vulnerability reappeared as CVE-2020-17496, along with an exploit that circumvented the previous fix. Just like in the case of ZyXEL, the patch for the initial issue was based on preventing the exploit’s attack path from being used instead of resolving the underlying vulnerability.
The rapidly paced arms race between attackers and security researchers is a constant challenge. While patching is a key component in defending an organization from potential attacks, research regularly demonstrates that patches sometimes miss fixing the actual root cause of vulnerabilities. In such cases, slightly modified versions of the original exploits may easily circumvent the patches.
While other security researchers have started looking into this as well, the topic of incomplete patching requires a great deal more attention and investigation. It is important to get an accurate picture of how widespread it is. Equally important is to understand why incomplete patches are released. Once the reasons are identified, concrete steps regarding better training, resource allocation, incentive structures, partnerships, and organizational processes can be implemented. Effectively defending against zero-days must focus on addressing new issues, not having to revisit old ones.
