Linksys WAP54Gv3: Remote blind attack demo


The IS-2010-002 vulnerability, regarding the undocumented debug interface on the Linksys WAP54gV3, has received CVE number (CVE-2010-1573) and Cisco has published a detailed security advisory on the issue (credits report misspelled name).
It seems also that a separate CVE number(CVE-2010-2261) has been assigned just for the command injection vulnerability, present in the data2 and data3 POST variables.
The vulnerability has been reported also on several other websites, but not always with the utmost accuracy, so I here try to clarify a few things.

Affected devices and firmware
In some cases it has been reported that only European devices are affected while devices sold in the US are safe.
Unfortunately that is not correct, in facts, firmware version v3.05.03 is installed on European devices, while, at the best of my knowledge, v3.04.03 is the current firmware version for US devices.
Both firmware versions v3.05.03 and v3.04.03 are vulnerable, so, if these are the only available firmware versions, this lead to the conclusion that all the WAP54Gv3 that are currently available suffer of the reported security issue, without any country based distinction.

Vulnerability attack “range”
Some websites reported that, in order to exploit the vulnerability, attacker should/may/must have access to the local network, either wired or wireless, and, be able to access the web interface.
I have the feeling that this kind of formulation, or similar, does not completely capture and describe all the possible attack scenarios related to this vulnerability.

It seems clear that the debug interface has to be accessed by a resource that is able to reach the the device (eg: is able to “ping” port TCP/80 of the device), but this does not necessarily imply that the resource is the attacker himself, or that the attacker has access to the local network.
At a logical level, by “decoupling” the attacker functions from the resource, a “Remote Blind” attack scenario is possible, where an attacker can exploit a device that is not even “IP-reachable”.

This concept is not new at all, it has been known for years and discussed in details in the security community:
the resource (eg: a Web browser) act as a “reflector”, sending commands on behalf of the attacker, that could be very well located outside of the local network and could not even be able to reach the device.

Look at the following video for a demonstration of the attack, where a vulnerable Linksys WAP54Gv3 uploads sensitive information on an attacker controlled website.

if there is, at least, an user that is able to access a vulnerable access point, all that is required to an attacker to exploit the “unreachable” vulnerable device is to entice the user in accessing a malicious web page.

One possible countermeasure would be to deny connections from the Access Point to the Internet, or apply some similar policy on the firewall at the network edge, this would prevent the AP to upload information in this scenario.

Anyway this should provide proper warning to readers that might underestimate the advisory, thinking that “access to local network” may be related only to plugging cables and inserting Wi-Fi passphrases.
Your own browser could be very well the key to unlock your “local network” doors.

*** Update *** (23/06/2010)
If an attacker exploits the XSS detailed in IS-2010-003, the browser itself may upload credentials to the attacker website.
In this case the countermeasure of denying connections to the Internet that are originated by the AP wil not be effective in preventing the attack detailed in this post.

Categories : Advisory  Security

Linksys WAP54Gv3 Remote Debug Root Shell


The IS-2010-002 vulnerability affects the WAP54Gv3, a 802.11g access point from Linksys and allows a remote attacker to take complete control of the device, independently of how strong the administration password has been chosen.
This vulnerability has been verified for firmware currently available for devices with hardware version v3.x, but may be present also in firmware for different hardware versions or for different models.
The firmware version currently available for WAP54Gv3 US devices is ver.3.04.03, while ver.3.05.03 is available for European customers.

The httpd daemon, listening on device’s 80/TCP port, relies on a structure named mime_handlers[] for storing information needed to handle an incoming request, including function pointers to the routines used for authentication initialization.
The picture below shows the mime_handlers[] structure present in the httpd daemon included in binary firmware ver.3.05.03.

The handler used for almost all the incoming request is the init_user_auth() function (green oval), that retrieves username and password stored in flash (“NVRAM” region) and copies them in RAM, in order to use them during the authentication check.
But, in two cases the handler init_GTK_auth() (red ovals) is used: that happens when the requested path (blue rectangles) is “Debug_command_page.asp” or “debug.cgi” (the latter can be followed by any sequence of chars).

The way the init_GTK_auth() handler initializes the authentication material can be appreciated in the following, pretty self-explanatory, picture.

The credentials stored in flash, used for authenticating the access to any other URL path, are not used in this case: authentication material is initialized with strings stored in the .rodata section of the httpd binary.
So, the only valid credentials for accessing the two “debug” paths mentioned above are:

user: Gemtek
password: gemtekswd

The handler init_GTK_auth() is not used for other URL paths, so the above credentials cannot be used for authenticating to any web page on the device other than the two “debug” paths.

These debug credentials are not stored in the device configuration that resides in the NVRAM region, so they cannot be accessed and modified via the nvram command.
Consequently, there is no way to remove or change them via the administration web interface, because it relies on the nvram command for modifying the device configuration settings.

But what is available at those two URLs?
The same content on both: a simple web page with a form that allows debugging of the device (see picture below).

By inserting shell commands and pressing the Debug button, they will be executed on the system with the privileges of the httpd daemon: root.

Then, an attacker can execute root commands on the target device, without even knowing the very strong admin password that every security conscious user has already configured on its device (you haven’t? :)).
And this also means that, whichever WI-FI SSID or passphrase, or administration password you have set, they can be remotely retrieved (and modified!).
Additionally, malicious binaries can be downloaded and executed on the system: sniffer, rootkits, botnet related binaries…
Finally, a “remote blind” attack scenario can be set up by crafting malicious web page that, when visited, will have the visitor’s browser acting as a “reflector” and executing commands on the device on attacker’s behalf.
Therefore it would be possible to target a device located in a local network, with private addressing, that would be otherwise unreachable from a malicious party located over the Internet.
And this without the need to bypass any authentication, so no need for social engineering attempts, CSRF, bruteforce…

But, what makes these scenarios even worse is that, again, these credentials cannot be modified or deleted in any way by the user, not even if you have a shell on the device.
The only action effective in fixing the vulnerability would be to upload a fixed firmware: officially released or created by patching the httpd binary inside the current binary firmware, or, alternatively, by applying a fix in source code and rebuilding it from scratch.

Wait.. do we have source code?
Probably yes.
The Linksys GPL center currently hosts the source code of firmware ver.3.04.03 for WAP54G, that is the version currently available for non-European customers, that can be retrieved here.

On the other hand, no source code seems to be available for ver.3.05.03, that is downloadable in binary format only for European customers.

I’m not aware of the differences between the two versions above, but comparing the httpd source code of the former with the httpd binary of the latter, they seem to be very similar, at least in respect to the vulnerability discussion.

Inspecting the ver.3.04.03 source code confirms all the elements reported above, suggesting that the issue is likely present in all the firmware versions currently available for WAP54Gv3.
The httpd code source code is located at: /wap54gv3_v3.04.03/release/src/router/httpd
while the mime_handlers[] structure is defined inside file broadcom.c located at: /wap54gv3_v3.04.03/release/src/router/shared.

The following entries are present into the mime_handlers structure:

struct mime_handler mime_handlers[] =
    { "Debug_command_page.asp", "text/html", no_cache, NULL, do_ej, do_debug_auth },
    { "debug.cgi*", "text/html", no_cache, do_debug_post, do_debug_cgi, do_debug_auth },

where the function do_debug_auth is the function referred above as init_GTK_auth, and is defined the following code:

static void do_debug_auth(char *userid, char *passwd, char *realm)
    strncpy(userid, "Gemtek", AUTH_MAX);
    strncpy(passwd, "gemtekswd", AUTH_MAX);

providing confirmation that version 3.04.03 is also affected by IS-2010-002 vulnerability.

Categories : Advisory  Security