Mama Always Told Me Not to Trust Strangers without Certificates
Introduction
This blog post details a vulnerability, the exploitation of which results in Remote Code Execution (RCE) as root, that impacts many modern Netgear Small Offices/Home Offices (SOHO) devices. The vulnerability isn’t your typical router vulnerability, in that the source of the vulnerability is located within a third-party component included in the firmware of many Netgear devices. This code is part of Circle, which adds parental control features to these devices. However, since this code is run as root on the affected routers, exploiting it to obtain RCE is just as damaging as a RCE vulnerability found in the core Netgear firmware.
This particular vulnerability once again demonstrates the importance of attack surface reduction. The Circle update daemon that contains the vulnerability is enabled to run by default, even if you haven’t configured your router to use the parental control features. While it doesn’t fix the underlying issue, simply disabling the vulnerable code when Circle is not in use would have prevented exploitation on most devices.
This blog post also demonstrates the growing concern that corporate security teams should have for SOHO device vulnerabilities. As a result of Covid-19 precautions, the number of people working remotely has increased significantly. While companies have taken steps to facilitate remote work, employees are usually responsible for managing their own internet connections. In most cases, this takes the form of purchasing or renting a SOHO router or modem. These devices typically aren’t on the radar of corporate security teams, unlike their enterprise-grade brethren. However, the last year and a half has seen a significant increase in the number of SOHO devices being used to connect to corporate networks. As a result, the threat to corporate networks posed by SOHO devices (particularly routers and modems) continues to grow.
As of the release of this blog post, patches should be available to download for all affected devices from Netgear. Additional information is available via Netgear's security advisory.
Bug identification
Circle Parental Control Service insecure update process
Vulnerability Type: RCE
Location:
/bin/circleddaemonAffected Devices and Versions: The below devices and versions have been determined to be vulnerable to this issue. Additionally, GRIMM analyzed the first firmware image for the R7000 with Circle support, version 1.0.9.10 released in 2017, and found that it also contains this vulnerability. As such, older versions of the below devices are also likely vulnerable.
R6400v2 - 1.0.4.106
R6700 - 1.0.2.16
R6700v3 - 1.0.4.106
R6900 - 1.0.2.16
R6900P - 1.3.2.134
R7000 - 1.0.11.123
R7000P - 1.3.2.134
R7850 - 1.0.5.68
R7900 - 1.0.4.38
R8000 - 1.0.4.68
RS400 - 1.5.0.68
Impact: RCE as root on the device
CVE Number: CVE-2021-40847
The update process of the Circle Parental Control Service on various Netgear routers allows remote attackers with network access to gain RCE as root via a Man-in-the-Middle (MitM) attack. While the parental controls themselves are not enabled by default on the routers, the Circle update daemon, circled, is enabled by default. This daemon connects to Circle and Netgear to obtain version information and updates to the circled daemon and its filtering database. However, database updates from Netgear are unsigned and downloaded via Hypertext Transfer Protocol (HTTP). As such, an attacker with the ability to perform a MitM attack on the device can respond to circled update requests with a specially-crafted, compressed database file, the extraction of which gives the attacker the ability to overwrite executable files with attacker-controlled code.
Technical analysis
The RCE vulnerability exists in the circled update daemon and can be exploited by a remote attacker that is able to sniff and send network traffic to and from the router. The circled daemon polls http://http.updates1.netgear.com/sw-apps/parental-control/circle/r7000/circleinfo.txt to obtain version information for Circle. This file contains versions, checksums, and sizes for the firmware, database, and platform components:
firmware_ver 2.3.0.1
database_ver 3.2.1
platforms_ver 2.15.2
db_checksum db06d2cb17ce67e7081fd3951b55c5cf
firmware_size 1982549
database_size 8648492Next, circled compares the current firmware, database, and platform versions to the ones mentioned in the downloaded circleinfo.txt. If the component is out of date, circled requests the update from:
database -
http://http.updates1.netgear.com/sw-apps/parental-control/circle/r7000/database.tar.gzfirmware -
http://http.updates1.netgear.com/sw-apps/parental-control/circle/r7000/firmware.binplatform -
http://http.updates1.netgear.com/sw-apps/parental-control/circle/r7000/platforms.bin
Unlike the firmware and platform binaries, which are encrypted and signed blobs, the database is simply a tarball. Presumably, the database updates were not protected in a similar manner, as they do not contain executables, only the Circle filtering database. However, as explained in the next section, a malicious database update can lead to arbitrary code execution.
After downloading the updates to the /tmp directory, circled unpacks them:
## database - The database update is extracted with the command:
cd /mnt/ && tar xzf /tmp/database.tar.gz
## firmware - First firmware.bin is decrypted, signature validated, and copied
## to /tmp/sdfiles.tar.gz. Then it's extracted with:
cd /mnt/ && tar zxf /tmp/sdfiles.tar.gz
## platform - First platforms.bin is decrypted, signature validated, and copied
## to /tmp/platforms.tgz. Then it's extracted with:
cd /tmp/ && tar zxf /tmp/platforms.tgz
[ -s /tmp/platforms/circle-customized.txt ]
mv -f /tmp/platforms/circle-customized.txt /mnt/shares/usr/bin/
[ -s /tmp/platforms/platforms.xml ]
mv -f /tmp/platforms/platforms.xml /tmp/platforms/platforms.ver /mnt/shares/usr/bin/Once the files are extracted, the circled daemon will restart Circle if it is enabled and currently running. This restart is done via the stopcircle and startcircle scripts from the /mnt/shares/usr/bin/ directory. Since the database updates are extracted to the same folder as the firmware binaries, , they can overwrite the startcircle and stopcircle scripts with arbitrary code. Additionally, the ping_circle.sh and check_update.sh scripts within the same directory are run once an hour to ping the Circle servers and determine whether enough time has elapsed between the last update check. These scripts are executed regardless of whether Circle is enabled, and thus can be used to obtain code execution regardless of Circle’s status on the device.
Exploit
This vulnerability can be exploited by serving a malicious database update to circled. This process is demonstrated in the included Proof of Concept (PoC). For reference, the PoC was developed for and tested against the Netgear R7000. A fake Domain Name System (DNS) server is run and configured to respond to requests from the router with the IP address of a MitM server. If the router receives the malicious DNS response before the legitimate one, the router will connect to the MitM server instead of Netgear’s update server. While the PoC uses a DNS spoofing attack, any type of MitM attack could also exploit this vulnerability.
The first step is to craft the database update that is used to trigger remote code execution. To generate a functional database update, GRIMM downloaded and modified a legitimate Netgear database update. For the PoC, the database file was modified to overwrite the executable scripts with code to start telnet on the device on ports 5500-5003 (see Figure 1). The included create.sh can be used to automate this process.
 |
| Figure 1: Creating the Malicious Circle Database |
The MitM server can be started by executing the included upgrade_attack.py script. This script will listen for DNS requests for http.updates1.netgear.com and respond with the local computer’s IP address. Additionally, it will host an HTTP server that will respond to the device’s requests for the database tarball and circleinfo.txt file. During the next circle update, the PoC will serve the malicious update. The router will then extract the update, which will overwrite ping_circle.sh with code to start telnet on port 5502 on the router. After an hour, ping_circle.sh will be run as root, executing the injected code which creates the telnet connections necessary for establishing a bi-directional remote shell. If the router has Circle enabled, then either stopcircle or startcircle could be overwritten instead of ping_circle.sh, which would result in the injected code being run immediately.
Old Tar
As an aside, the R7000’s tar utility is from busybox version 1.7.2, originally released in September 2007. One of the issues with old versions of tar is that they do not safely account for files included in tarballs with absolute paths. For instance, if a tarball includes a file with a path of /tmp/test, older versions of tar will extract the file to /tmp/, regardless of the current directory. More modern versions will strip the leading / from the path unless the -P option is specified. As a result, the Circle database updates can write a file to any directory, not just those under the /mnt/ directory. Thus, even if the database update extraction was restricted to a directory separate from the Circle executables, it could still compromise the device.
Figure 2 demonstrates this issue by creating a tarball with an absolute path on a computer with a modern version of tar, copying it to the R7000, and then extracting the tarball from within the /mnt/ directory.
 |
| Figure 2: Creating a tarball with an absolute path |
Testing
A shell script, create.sh, has been provided to create a malicious database tarball and the associated circleinfo.txt file for the R7000. Once generated, these files will need to be served via a MitM attack on the device. The easiest way to test the MitM attack is via DNS spoofing. From a computer on the WAN side of the device, run the include upgrade_attack.py script. You will need to provide the IP address of the host (as visible to the device) and the name of the interface between the host and the device. Once the script is running, the next Circle update occurs, the script will spoof the response for http.updates1.netgear.com to return the local computer’s IP address. It will then serve the malicious database tarball and circleinfo.txt files created by create.sh. Afterwards, the device will start a telnet instance on ports 5500-5503 immediately if Circle is enabled, or within the hour if it’s disabled. Figure 3 illustrates this process.
 |
| Figure 3: The PoC exploiting the Circle update on the R7000 |
Affected Devices
The Netgear devices listed below (followed by the most recent version of of the firmware available when this research was conducted) have been verified to contain the vulnerable update code.
R6400v2 - 1.0.4.106
R6700 - 1.0.2.16
R6700v3 - 1.0.4.106
R6900 - 1.0.2.16
R6900P - 1.3.2.134
R7000 - 1.0.11.123
R7000P - 1.3.2.134
R7850 - 1.0.5.68
R7900 - 1.0.4.38
R8000 - 1.0.4.68
RS400 - 1.5.0.68
Impact
The impact of the vulnerability described above is that attackers on the same network as any of the vulnerable routers or otherwise able to redirect the router’s traffic can launch a MitM attack, the result of which, can provide RCE as root on the targeted router. The vulnerability itself exists in the Circle Parental Control Service update daemon, which is enabled by default. Thus, even Netgear devices that have not been configured to use the Circle parental control feature are still vulnerable to this exploit.
To exploit the vulnerability, the attacker must be must be able to intercept and modify the router’s network traffic. For the specific DNS-based MITM attack used above, the attacker must race DNS queries from the Circle update daemon. If the attacker wins one of these races, which can be done reliably with the PoC exploit written by GRIMM, code execution is trivial to obtain. Other MitM attacks that do not rely on DNS manipulation will also allow an attacker to exploit this vulnerability.
Since the executable files that can be overwritten by this vulnerability are run as root, the highest privileged user in Linux environments, the code executed on behalf of the attacker will be run as root as well. With root access on a router, an attacker can read and modify all traffic that is passed through the router. For example, if an employee connects to a corporate network via a compromised router, the router could MitM the connection and read any unencrypted data sent between the user’s device and devices on the corporate network.
Additionally, a compromised router could be used as part of a larger chain to infiltrate more secure environments. For instance, one possible attack chain that uses this vulnerability to compromise a corporation is:
The attacker performs some initial reconnaissance to determine the ISP that employees of the target corporation use.
The attacker compromises this ISP via some other mean (phishing, exploit, etc).
From within the ISP, the attacker will be able to compromise any routers vulnerable to the Circle Parental Control Service vulnerability.
From the compromised routers, the attacker can directly communicate with any corporate computers that are connected to the router. Then, using an exploit for a separate vulnerability, such as the recent PrintNightmare vulnerability,1 the attackers can compromise these computers.
Once the attackers have compromised the corporate computers, they can pivot to the corporate network and exfiltrate corporate data or launch further attacks on the corporation.
While this attack chain requires separate exploits, which may be blocked or detected, it does provide an alternative to directly attacking the corporate network which is much harder and more likely to be detected.
Conclusions
This report detailed a vulnerability in the Circle Parental Control Service included in many SOHO Netgear routers. Exploitation of this vulnerability allows attackers on the same network as one of these devices or otherwise able to intercept the router’s network traffic to obtain RCE as root on the router. The exact list of devices affected by this vulnerability is included in the technical analysis section.
For many organizations, SOHO devices typically fly under the radar when it comes to cybersecurity risk management. However, the significant increase in employees remotely connecting to corporate networks (e.g. due to updated work-from-home policies brought into practice as a result of Covid-19) has similarly increased the risk to corporate networks from vulnerabilities in SOHO devices.
To mitigate the risks to corporate environments posed by vulnerable SOHO routers, GRIMM recommends the provisioning and use of Virtual Private Network (VPN) clients. These clients should be configured to handle all traffic to ensure that an attacker cannot read or modify network traffic in a way that cannot be detected by the VPN endpoints.
Timeline
07/23/2021 - First attempt to notify vendor
07/29/2021 - Second attempt to notify vendor
07/30/2021 - Third attempt to notify vendor
08/09/2021 - Notified CISA
08/18/2021 - Met with vendor's product security team
08/18/2021 - Granted two-week extension to release deadline
09/09/2021 - Assigned CVE-2021-40847
09/20/2021 - Security advisory released by vendor
09/21/2021 - Patches made available by vendor
09/21/2021 - NotQuite0DayFriday release
09/21/2021 - Blog post release
GRIMM’s Private Vulnerability Disclosure (PVD) program
GRIMM’s Private Vulnerability Disclosure (PVD) program is a subscription-based vulnerability intelligence feed. This high-impact feed serves as a direct pipeline from GRIMM’s vulnerability researchers to its subscribers, facilitating the delivery of actionable intelligence on 0-day threats as they are discovered by GRIMM. We created the PVD program to allow defenders to get ahead of the curve, rather than always having to react to events outside of their control.
The goal of this program is to provide value to subscribers in the following forms:
Advanced notice (at least two weeks) of 0-days prior to public disclosure. This affords subscribers time to get mitigations in place before the information is publicly available.
In-depth, technical documentation of each vulnerability.
PoC vulnerability exploitation code for:
Verifying specific configurations are vulnerable
Testing defenses to determine their effectiveness in practice
Training
Blue teams on writing robust mitigations and detections
Red teams on the art of exploitation
A list of any indicators of compromise
A list of actionable mitigations that can be put in place to reduce the risk associated with each vulnerability.
The research is done entirely by GRIMM, and the software and hardware selected by us is based on extensive threat modeling and our team’s deep background in reverse engineering and vulnerability research. Requests to look into specific software or hardware are welcome, however we can not guarantee the priority of such requests. In addition to publishing our research to subscribers, GRIMM also privately discloses each vulnerability to its corresponding vendor(s) in an effort to help patch the underlying issues.
If interested in getting more information about the PVD program, reach out to us.
Working with GRIMM
Want to join us and perform more analyses like this? We’re hiring. Need help finding or analyzing your bugs? Feel free to contact us.
