Linksys WAP54Gv3 Remote Debug Root Shell

2010.06.08

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.

http://downloads.linksysbycisco.com/downloads/gplcode/1224638867116/wap54gv3_v3.04.03.tgz

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.

6 comments

  1. Nice find. They took a month to send you contact information, then sat on the information since October 2009? At Cisco, customers come first!

    Kelvin, 11/06/2010
  2. Thanks.

    Not really, dates in the advisory are in dd/mm/yy format, so it took them just one day to answer my contact request.
    I have to say that, excluding the “no update received” period, they have been really responsive.

    But thanks for bringing this to my attention, I did something similar regarding the “Received clarification…” and “Additional detail..” date.
    That should have been 12/11/2009 in dd/mm/yy format, meaning Nov 12th, 2009.
    I’ll update the advisory and I will include also date format in the next ones.
    Thanks.

    pulsoid, 11/06/2010
  3. Advisory (and related links) now updated.

    pulsoid, 11/06/2010
  4. Hello,

    Very neat finding and nice summary :) Keep up the great work.

    Regards

    Marc

    Marc Ruef, 15/06/2010
  5. Awesome..could you guide me in the direction on how te retrieve admin password through the debug window? cheers

    harry, 19/06/2011
  6. Comprehensive configuration information can be viewed by issuing the following command through the debug page:
    cat /tmp/var/tmp/nvram

    Look for nvram_http_passwd
    and also notice nvram_wl_wpa_psk

    Jeroen, 13/09/2014

Leave a comment