tl;dr

Auth bypass, partial admin password leak, weak crypto and DoS, in the first firmware of the Netgear SX10 switch

Summary

After my “work” on the nested backdoors of the Netgear WNDR4000 router, Netgear sent me some nice gifts, among which a brand new SX10 switch, so I decided to audit it. This “work” was done in April 2018, and I discovered a few vulnerabilities and a few oddities.

Disclosure timeline

I sent an advisory to Netgear on May 4, 2018 (Star Wars fan: this was not on purpose!).
I received a response within 4 days, in which I was told that the vulnerabilities had been assigned PSVs, and that the oddities were being looked into.
As I did not hear back from Netgear for more than 2 months, I asked for some news on Jul 24, 2018.
I received an answer the next day, in which I was given a link to the advisory for the 2nd vulnerability, and that all other vulns should be fixed by the end of September.
I never got any more news after that. At the time of writing, only 3 out of 4 advisories have been published, but I will publish my findings anyway (5.5 months should be more than enough to fix everything…).

Links to PSVs

Vuln 1, PSV-2018-0219: Security Advisory for Authentication Bypass on Some Switches
Vuln 2, PSV-2018-0220: Security Advisory for Sensitive Information Disclosure on GS810EMX
Vuln 3, PSV-2018-0221: not published at time of writing
Vuln 4, PSV-2018-0222: Security Advisory for Denial of Service on Some Switches

Notes

I am lazy to write much about my findings, so I’ll just paste the advisory below (with slight modifications). I hope you’ll still have some fun reading about the vulnerabilities, especially vulnerability 1, point c) 😄
Almost everything on this switch is done by an executable called iss.exe. Don’t be fooled by the name, this switch is running Linux (on ARM Cortex A9, Marvell Armada-38x). The firmware is available from netgear’s support, and is easily extracted with binwalk.
On the hardware side, I managed to get console (CLI) access to the switch via its serial port (UART), and hence a root shell. I managed to upload files via UART to the switch, such as a gdbserver. However, I could not make the switch communicate with the “outside world” via the network, from the shell, which hindered my attempts to perform a dynamical analysis of iss.exe and thus to audit the switch in more depth. This was somehow a frustrating first hardware hacking experience!
The exploit for the DoS (vuln 4) is here.

Advisory


############################################################################

Advisory: 1- unauthenticated access (leak of the admin cookie)
          2- leak of the beginning of the admin password
          3- weak cryptography of the admin password (stored in the admin
             cookie), hard-coded xoring key
          4- Denial of Service

Product: Nighthawk SX10 Gaming 10-Gigabit/Multi-Gigabit Switch / GS810EMX

Firmware Version: 1.0.0.1

Author: DuSu

############################################################################

I recently started auditing the Netgear Nighthawk SX10 switch that Netgear
sent me and I found a few vulnerabilities that are reported below. I will
also report a few oddities I found, even though I could not exploit them
yet (some oddities are not really security issues). Finally, I mention the
access to the hidden debugging options.

For all that follows, the IP address of the switch will be assumed to
be 192.168.1.15, and the admin password has been changed from the default
"password" to "LEAKMEADMINPASSWORD".
I will also use the notation @ 0xADDR to refer to content, in the binary
/root/iss.exe (which does all the job), at address 0xADDR.

############################################################################

Vulnerability 1: unauthenticated access (leak of the admin cookie)

When the admin is logged in, there are various ways to leak the admin
cookie (so called Gambit in iss.exe):

a) Any attacker can perform the following request
`curl http://192.168.1.15/iss/file/get/foo`
This results in an error message "File does not exist"
But inspecting the answer more closely, one sees the following two lines
<form> <input type=hidden
  name=Gambit
  value="pftjgajesiikhjojngugbcohfbigocnebdomnoddukngcptrbohjjmlkllbf">
</form>
(where the Gambit value is of course not always what is shown here).

b) This leak can also be achieved by attempting to log in, with a
password with a length > 0x5ff2, which results in a different error, namely
"413 Content Length is Too Big".

c) The most problematic way, from a security point of view, is that any
attacker can simply do the following (with a web browser):
- request http://192.168.1.15/homepage.html
  although this redirects to the login page http://192.168.1.15/wmi/login
  so that everything looks secure, it is not secure, since inspecting the
  answer from the switch shows that it sets the cookie to the admin cookie
- request http://192.168.1.15/homepage.html a second time, and have access
  to the admin panel, meaning the switch is under the attacker's control.

This can all be seen from the command line, by requesting
`curl -v -c cookies -b cookies http://192.168.1.15/homepage.html` twice.

I do not know  whether the Gambit cookie is leaked from yet other requests.

----------------------------------------------------------------------------

Vulnerability 2: leak of the beginning of the admin password

When the admin has just logged out, performing the same operations as a) or
b) in Vulnerability 1 leaks the beginning of the password. For example, I
got an answer from the way a) (`curl http://192.168.1.15/iss/file/get/foo`)
containing the two lines
<form><input type=hidden name=Gambit value="1:58:admin:LEAKMEA">
</form>

----------------------------------------------------------------------------

Vulnerability 3: weak cryptography of the admin password (stored in the
admin cookie), hard-coded xoring key

It is clear from Vulnerability 2 that the password set by the admin is
stored in plain text (it is not hashed), which is a big security concern.
Furthermore, one can wonder why the beginning of it can be leaked.
It seems (I could not figure out all details) that the cookie is an
encrypted version of the text LOG:TIME:USER:PASSWORD, where
- LOG is the number of successful logins since last switch reboot
- TIME is the number of seconds since last switch reboot at the moment of
  loggin in
- USER is the admin username (admin)
- PASSWORD is the admin password (LEAKMEADMINPASSWORD here)
In the example of Vulnerability 2, the admin logged in once, 58 seconds
after reboot.

The encryption is performed by the function @ 0xec170, while the decryption
is performed by the function @ 0xec290. These both use a buffer @ 0x73c3f8
in BSS to store their data (the encrypted Gambit, or its plain text
version). Both these operations use a custom algorithm (that I did not try
to understand in detail), using a hard-coded xoring key:
KEY: ne@t~e$7ge#2At*q (found @ 0x40d676)

I do not know why the full password is not leaked in Vulnerability 2,
because as already mentionned, I did not try to understand all details of
the encryption and decryption.
It is however a security weakness to have the password stored somewhere in
plain text, and an even bigger weakness to have this password stored in the
cookie, even if encrypted, since the decryption and encryption routines
are found in iss.exe. All the data (LOG, TIME, admin username, admin
password) should be hidden from the user, and should not appear in the
Gambit cookie (even encrypted).
Furthermore, it would be a good practice to zero out the memory used to
store sensitive information, once it is no longer used.

----------------------------------------------------------------------------

Vulnerability 4: Denial of Service

The iss.exe binary makes use, at various places, of buffers of size 0x6000,
used to store and manipulate user data. This should prevent buffer
overflows, since the Content-Length of http requests is also checked to be
smaller than 0x6000.
However, it turns out that the Content-Length check is performed by a signed
comparison (I did not try to figure out where this happens in iss.exe, I
only triggered the vulnerability). Hence, creating a raw http request with
a fake size of 0x80000000 will result in the check to pass, when it should
fail, since this size is wrongly interpreted as -0x80000000. This allows to
send more data than 0x6000 bytes. As 0x80000000 is too much to be sent, one
can send less and perform a shutdown('write') on the socket from the client
side.
This results in a BSS overflow, that can eventually lead to a segmentation
fault (and thus a reboot of the switch, see the /etc/init.d/S55iss script),
and thus a DoS attack if this is repeated over and over again.
I triggered such a reboot by sending a password of minimum length 0x29ffa
(see the attached DoS_sx10.py file), which overwrites part of the word
(4 bytes) located @ 0x79c90c in BSS.
I did not manage to convert this overflow into code execution, and do not
know if it is even possible.

############################################################################

Oddities:

* One can set a too long password (more than 20 characters) in the admin
  interface. This password is accepted, but using it to log in fails.
  Successful login can only be achieved by using the first 20 characters of
  the password that has been set.

* Some functions (e.g. @ 0xc59c or @ 0xe8a04) perform operations that are
  basically: strncpy(dest, src, strlen(src)), which is nothing else than:
  strcpy(dest, src), so this will not prevent buffer overflows, even though
  strncpy is used.

* The string "system_backdoor" is found in the iss.exe binary. I did not
  manage to find my way in this backdoor, and do not know whether it is even
  possible to do so, but the mere presence of this string is worrisome.

* Strings "iss123" and "admin123" that look like hard-coded passwords are
  present in iss.exe. Again, I could not figure out what they are used for.

############################################################################

Debugging:

Up to now, my only debugging means are to enable the debugging, via
/debug.html, which redirects to /loginhidden.html, and then using the
hard-coded user name "Admin1NtgrDebugUser" and the admin password. I did not
list this as a vulnerability, because the admin password could not be leaked
completely in Vulnerability 2. But if the admin password has very few
characters, it could be fully leaked, and if it is weak, knowing the
beginning of it should allow to brute force the end of it.
In such an eventuality, the attacker would have access to core dumps,
packet dumps or configuration dumps.