Date: Fri, 4 Apr 2014 15:08:30 -0300
From: Palula Brasil <palulabrasil@...il.com>
To: Full Disclosure <fulldisclosure@...lists.org>
Subject: [FD] Remote Command Execution within the ASUS RT-AC68U Managing Web
	Interface

=====[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

_______________________________________________
Sent through the Full Disclosure mailing list
http://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists