We already saw how to bypass the authentication so in this post I want to focus in the compromise of the underlying system. In order to do this we have to understend how the router works internally and the management of the administration interface.

Checking the filesystem we got in the previous post I found that everything is handled by just one cgi called setup.cgi:

One of the most common vulnerabilities we can see on SOHO routers are command injection through bad implemented functions, so my priority is to find where a command is executed to against the system and that allows me to control the input. For this I opened setup.cgi in IDA and search for keywords, in this case '/bin':

The ping command caught my attention as it meets both conditions. In this case the webpage that handles this is diag.htm which allows the user to perform different tests to validate the internet connectivity.

By opening diag.htm and reading the source code we find the first interesting thing. Input data is validated client side, so just changing return ping_ck() by return true or modifying the POST request we can send our crafted data.

As you can see above we tried to inject a command appending ';' to the IP address but the command never reaches the server. It's filtering it server side, so let's take a look at the cgi:

As you can see, it searches for a semicolon in the request and if exists the command is never executed...but..what happens here? It only filters the semicolon so if we replace it with '&&' we bypass the check and the command is successfuly executed...or it should...

If we run the command against the system we receive a 403 error but I noticed that setup.cgi gets a GET numeric parameter as follows...setup.cgi?id=0000000
So let's move again to IDA and search for 'id=' string:

First main() search for POST parameters and environment variables, if not found seek for GET parameters. In case it finds 'id' runs strtol() and if succeed extract the content of /tmp/SessionFile and compares against the id parameter where if doesn't match returns the 403 error.

Finally we know that we need to sign the request with this parameter in order to run the command, so we use the auth bypass vulnerability from the previous post to access the web interface, scrap the source code to extract a valid sessionid before it changes, craft the injection and returns the response.

Here is a script to do this:

And finally we got the expected result in the response after running a 'pwd' command:

Unlike the previous vulnerability this only affects to two models JWNR2000v5 and JWNR2010v5.

It has been a long time since my last update so today I want to show you two vulnerabilities found while reversing the firmware from a NETGEAR router. The exploitation of these two vulnerabilities provides the attacker full remote unauthenticated root access to the device if it has WAN administration enabled.

First things first, the content you are about to read is intended as educative content, do not hack random thing out there, don't be stupid.
Ok, let's start with this. In this case I analyzed the firmware 1.1.0.31 published on 05/11/2015 for the Netgear JWNR2010v5.

I use to run a script that test every file in the webserver and returns the error code, so I did, and from this preliminary file access analysis I found that an unauthenticated user can access every static file located in the webroot which is interesting but not very useful, anyway reviewing the results of this test I found the tip of the iceberg.
Every time I ran the script and reached one file the following files were available without authentication (Error 501 == 200):

And even worse...when I ran the script again every file returned a 501 error, so by doing this I disabled the authentication for the router somehow and with this we reached the "IDA Time!".
By analyzing the router behaviour we can see that the authentication is handled by the webserver binary, so we import it to IDA and search for our reference string ( BRS_netgear_success.html ) which returns an intermediate function between 'main' and other function that we called 'auth_req_check' because of a .htpasswd reference.

This intermediate function will be called 'url_handle' as we can see a clasic staircase pattern comparing the reveived URL with hardcoded strings using strstr() function and executing different actions.
Now we identified and isolated the authentication and url handler functions, lets move to our suspicious string. As you can see in the following image if the url contains the string ( BRS_netgear_success.html ) it moves to an interesting piece of code which sets two variables in the nvram to 0 (need_not_login and start_in_blankstate)

With this in mind it's easy to understand what is this doing, wen we access BRS_netgear_success.html the router redirects to NETGEAR webpage just to check whether we have internet access or not, and allows the user to access the router without credentials just for change the administrative password...but...this should be only allowed the first time the router is connected which is not the case...
Finally lets confirm our assumptions checking where the bypass is done. For this, we have to move to the 'auth_req_check' function that we named previously ( offset 00403858 if you want to check) and read from the beginning where the function checks the existence of the .httpasswd file. If yes, we find a reference to start_in_blankstate where it's compared to be different to 1 and if yes the login is bypassed:

With the we confirmed that if start_in_blanckstate is 0 the .htpasswd is disabled and we have free access to the admin panel of the router.

So in short, if we hit this URL http://[IP_ROUTER]:[PORT]/BRS_netgear_success.html the login for every page in the router is temporary disabled.

I could confirm that the following models are vulnerable to this:
NETGEAR_JNR1010v2, NETGEAR_JNR3000, NETGEAR_JWNR2000v5, NETGEAR_JWNR2010v5, NETGEAR_N300, NETGEAR_R3250, NETGEAR_WNR2020, NETGEAR_WNR614, NETGEAR_WNR618

But this is only the beginning and we want to get unauthenticated root access to the router.

In the following post I explain a vulnerability that affects just these two models (JWNR2010v5 and JWNR2000v5) that allows us to fully compromise the router and also you can find a PoC to test with your own router.