Date: Fri, 4 Apr 2014 17:25:02 -0400
From: Craig Young <vuln-report@...ur3.us>
To: Palula Brasil <palulabrasil@...il.com>
Cc: Full Disclosure <fulldisclosure@...lists.org>
Subject: Re: [FD] Remote Command Execution within the ASUS RT-AC68U Managing
 Web Interface

Hi Paula,
SOHO router security is quite bad.  This is far from an isolated ping
injection as most home routers don't bother to sanitize input going to
ping functionality.  It is common enough that I have begun just
referring to it as ping injection.

FYI - For tracking purposes, the CVE I had assigned when I alerted
Asus to this about 6 months ago is CVE-2013-5948.

More information on my SOHO router research with Tripwire VERT is
available here:
http://www.tripwire.com/register/soho-wireless-router-insecurity/

Thanks for sharing,
Craig
@CraigTweets

On Fri, Apr 4, 2014 at 2:08 PM, Palula Brasil <palulabrasil@...il.com> wrote:
> =====[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/

_______________________________________________
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