zero-day-vulnerabilities-ZyXEL

Hacking

Incorrectly patched ZyXEL vulnerability becomes zero-day again

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 incomplete patching.

New vulnerabilities and attack vectors emerge almost daily. Defense teams have a higher chance of fending off attacks when there is less time between hackers’ active exploitation and detection. 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 payloads we collected in a separate honeypot project over the last year, which we will cover 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 [1].

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.

In depth analysis of CVE-2020-9054 exploitation

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. Smaller and medium-sized enterprises around the world are increasingly deploying the devices, often lacking 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 [2].

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 [3]. 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. The patch only addresses the vulnerability via HTTP port, not the actual vulnerable PAM module accessible through other ports.

‍

Different port, same exploit

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 reported the issue to ZyXEL, who deemed it a separate matter with different attack vectors. We requested a CVE ID (no response) and expect a new patch soon.A quick Shodan search yields around 2-3k vulnerable devices.

Other evidence of poorly patched vulnerabilities

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. During our research, we discovered multiple vulnerabilities publicly reported due to 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. After disclosing this vulnerability, a patch was released to add checks for the rendered template and prevent the exploitation of CVE-2019-16759.

Approximately a year later, the vulnerability reappeared as CVE-2020-17496, along with an exploit that circumvented the previous fix [4]. Similar to ZyXEL’s case, the patch for the initial issue aimed to prevent the exploit’s attack path rather than resolving the underlying vulnerability.

Conclusion

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. Understand reasons for incomplete patches, then implement steps regarding training, resource allocation, incentives, partnerships, and processes. Effectively defending against zero-days must focus on addressing new issues, not having to revisit old ones.

Research by: Alberto del Rio, Genco Altan Demir, Julian-Ferdinand Vögele