Microsoft finds new NETGEAR firmware vulnerabilities that could lead to identity theft and full system compromise

The continuous improvement of security solutions has forced attackers to explore alternative ways to compromise systems. The rising number of firmware attacks and ransomware attacks via VPN devices and other internet-facing systems are examples of attacks initiated outside and below the operating system layer. As these types of attacks become more common, users must look to secure even the single-purpose software that run their hardware—like routers. We have recently discovered vulnerabilities in NETGEAR DGN-2200v1 series routers that can compromise a network’s security—opening the gates for attackers to roam untethered through an entire organization.

We discovered the vulnerabilities while researching device fingerprinting in the new device discovery capabilities in Microsoft Defender for Endpoint. We noticed a very odd behavior: a device owned by a non-IT personnel was trying to access a NETGEAR DGN-2200v1 router’s management port. The communication was flagged as anomalous by machine learning models, but the communication itself was TLS-encrypted and private to protect customer privacy, so we decided to focus on the router and investigate whether it exhibited security weaknesses that can be exploited in a possible attack scenario.

In our research, we unpacked the router firmware and found three vulnerabilities that can be reliably exploited. We shared our findings with NETGEAR through coordinated vulnerability disclosure via Microsoft Security Vulnerability Research (MSVR), and worked closely with NETGEAR security and engineering teams to provide advice on mitigating these issues while maintaining backward compatibility. The critical security issues (those with CVSS Score: 7.1 – 9.4) have been fixed by NETGEAR. See NETGEAR’s Security Advisory for Multiple HTTPd Authentication Vulnerabilities on DGN2200v1.

We are sharing details from our research with the broader community to emphasize the importance of securing the full range of platforms and devices, including IoT, and how cross-domain visibility continues to help us uncover new and unknown threats to continually improve security.

Obtaining and unpacking the firmware

The firmware was available from the vendor’s website, making it easier for us to obtain a copy for examination. It is a simple .zip file containing release notes (.html) and the firmware image itself (.chk file). Running binwalk on the .chk file ended up extracting the filesystem (squash-fs).

Figure 1. Extracting the filesystem from the firmware

The filesystem itself is a standard Linux root filesystem, with some minor additions. The relevant ones for our research are:

1. /www – contains html pages and .gif pictures
2. /usr/sbin – contains various custom binaries by NETGEAR, including HTTPd, FTPC, and others

Since we saw the anomalous communication use the standard port that HTTPd serves, we focused on HTTPd. The HTTPd itself is a 32-bit big-endian MIPS ELF, compiled against uClibc (the standard libc for embedded devices), stripped. It seems the entire server-side logic (CGI) was compiled into the HTTPd.

Figure 2. HTTPd information with some symbols

Exploration

When exploring an embedded web service, the first few questions that come to mind are:

1. Does the web service present some pages without authentication? If so, how are they governed?
2. How does the web service perform authentication?
3. Does the web service handle requests correctly (that is, with no memory corruption bugs)?
4. Does the web service implement certain security measurements, such as (anti-) cross-site request forgery tokens or Content Security Policy?

To answer these questions, we performed a static analysis of the HTTPd binary, along with some dynamic analysis by running QEMU, an open-source emulator, and hooking the specialized invocations (for example, NVRAM getters and setters).

Vulnerabilities in DGN-2200v1 routers

Accessing router management pages using authentication bypass

While examining how HTTPd dictates which pages should be served without authentication, we found the following pseudo code:

Figure 3. Pseudo code in HTTPd

This code is the first page handling code inside HTTPd, and it automatically approved certain pages such as form.css or func.js. While there is no harm in approving those pages, one thing that stood out was the fact that NETGEAR decided to use strstr to check if a page has “.jpg”, “.gif” or “ess_” substrings, trying to match the entire URL.

We can therefore access any page on the device, including those that require authentication, by appending a GET variable with the relevant substring (like “?.gif”). For example: hxxps://10[.]0[.]138/WAN_wan.htm?pic.gif. This is a complete and fully reliable authentication bypass.

Deriving saved router credentials via a cryptographic side-channel

At this stage, we already had complete control over the router, but we continued investigating how the authentication itself was implemented.

If a page had to be authenticated, HTTPd would require HTTP basic authentication. The username and password would be encoded as a base64 string (delimited by a colon), sent in the HTTP header, and finally verified against the saved username and password in the router’s memory. The router stores this information (along with the majority of its configuration) in NVRAM, that is, outside the filesystem that we had extracted.

However, when we examined the authentication itself, we discovered a side-channel attack that can let an attacker get the right credentials:

Figure 4. Authentication process

Note that the username and the password are compared using strcmp. The libc implementation of strcmp works by comparing character-by-character until a NUL terminator is observed or until a mismatch happens.

An attacker could take advantage of the latter by measuring the time it takes to get a failure. For example, when measuring the times of the first character, we get the following graph:

Figure 5. Time of reply per character attempt

This indicates that the first character is “n”. An attacker could repeat this process (“na”, “nb”, “nc” and so on) to get the second character, until the entire username and password is revealed.

We recommended to NETGEAR that they can avoid such attacks by performing XOR-based memory comparison, as such:

Figure 6. XOR-based memory comparison

This function continues even upon a byte mismatch. Similar approaches can be seen in cryptography secure libraries, such as OpenSSL’s CRYPTO_memcmp.

Retrieving secrets stored in the device

After using the first authentication bypass vulnerability, we still wanted to see if we could recover the username and the password used by the router using other existing weaknesses. To that end, we decided to use the router’s configuration backup\restore feature. We can abuse the authentication bypass mentioned earlier to simply get the file: hxxp://router_addr:8080/NETGEAR_DGN2200[.]cfg?pic[.]gif.

The file itself has high entropy, which suggests it was either compressed or encrypted so we couldn’t read it directly. Additionally, binwalk did not produce any meaningful results:

Figure 7. High-entropy configuration file

Our suspicion became real when we reverse-engineered the backup\restore functionality:

Figure 8. Constant password used for DES encryption

After some preparatory steps, the contents are DES-encrypted with a constant key “NtgrBak”. This allows an attacker to get the plaintext password (which is stored in the encrypted NVRAM) remotely. The user name, which can very well be variations of ‘admin’, can be retrieved the same way.

Enhancing router security through CVD and threat intelligence-sharing

As modern operating system security continues to advance, attackers are forced to look for alternative ways to compromise networks, and network devices such as routers are a prime candidate. This makes an endpoint discovery solution a critical asset to any security operations.

The new endpoint and network device discovery capability in Microsoft Defender for Endpoint locates unmanaged devices to ensure organizations have comprehensive visibility into their environment. This lets security operators detect anomalous network activity, in this case, the attacker’s anomalous connection to the router’s management port.

Figure 9. Device inventory in Microsoft 365 Defender

In addition, with ReFirm Labs recently joining Microsoft, we continue to enrich our firmware analysis and security capabilities across devices. ReFirm’s firmware analysis technology will enhance existing capabilities to detect firmware vulnerabilities and help secure IoT and OT devices via Azure Defender for IoT.

With this research, we have shown how a simple anomalous connection to a router, found through the endpoint discovery service, drove us to find several vulnerabilities on a popular router.

Routers are integral to networking, so it is important to secure the programs supporting its functions. Collaboration between vulnerability researchers, software vendors and other players is crucial to helping secure the overall user experience. This includes disclosing vulnerabilities to vendors under the guiding principles of Coordinated Vulnerability Disclosure (CVD). We would like to thank the NETGEAR security and engineering teams for their cooperation.

Learn how Microsoft Defender for Endpoint delivers a complete endpoint security solution that covers preventative protection, post-breach detection, automated investigation, and response.

 

Jonathan Bar Or

Microsoft 365 Defender Research Team