Recent DDoS cases and the release of the Mirai botnet source code made clear, if needed at all, that insecure IoT devices can be a threat not only for their owners, but for the whole connected ecosystem.
Many security researchers were already aware of these potential threats, even before the “IoT wave” of the latest years.
The “wave” brought a name change from “network-connected embedded devices” to “IoT devices” and a constantly increasing frequency of “IoT threats” mentions. To the point that they have become a sort of a “mantra” in the security community and marketing departments.
The talks I gave in 2010 on Access Points exploitation already explored, in the context of APs, some of the advantages an attacker might gain when in control of such devices. With the proliferation of IoT devices now, those considerations are even more relevant and certainly not limited to APs only.
I realized that, although that research from 2010 is now outdated and fixes have been provided, those presentations might still be interesting for a glance into embedded exploitation and provide some insights which might still be useful today.
Unfortunately, they are not easily found on conference sites anymore. So, I decided to fill the gap and make them available here.
This posting also comes with an inner smile in seeing how and how much I personally evolved since those times.
Six years are definitely a significant amount of time.
…but I guess this happens to anybody peeking a bit back into his own past. 🙂
The talk at SyScan 2010 encompassed the same topics, but demonstrated how remote exploitation of an internal LAN device could be performed by pivoting on a smartphone. URL shortening services and Social Networks perfectly fitted in the picture for such an attack scenario.
The slides of SyScan 2010 can be found here: Syscan_10_Taipei_- _Too _much_Access_Points_-_Exploitation_Roundup
..and if you are still curious on these topics, you can dive in the posts of this blog, which provide further technical details.
The IS-2010-005 advisory describes a vulnerability in the D-Link DAP-1160, that allows for authentication bypass and complete device reconfiguration.
Authentication can be bypassed by accessing the URL:
http://IP_ADDR/tools_firmw.htm
within 40 seconds of the web server start, and consequently after the reboot, and taking care that the request for the specified URL is the first HTTP request the web server receives.
This vulnerability has been verified on the firmware versions 1.20, 1.30 and 1.31, that are all the binary firmware versions I made test with, but it might be present also in older firmware versions and/or other D-Link devices.
Source code for DAP-1160 seems to be available only for version 1.20b06, and can be downloaded from here:
Unfortunately no source code is available for the httpd server, just object files that can be found at DAP-1160_v120b06_src/AP/httpd inside the compressed archive.
The binary code that is relevant for the vulnerability discussion can be seen in the picture below, where some code blocks have been aggregated and colored for better description.
The code path in the picture is executed at each HTTP request.
It first checks if a timeout has occurred by checking a counter in auth_sys_time structure, that is updated every 20 seconds circa.
If the counter is less than 2 (less than 40 seconds have passed since process start), it then checks if the requested URL path matches the string “tools_firmw.htm”.
If it does, then all the data pertaining to a successful authentication are updated and the result is equivalent to a successful authentication.
It is important that the path “tools_firmw.htm” is accessed as a first HTTP request, otherwise authentication structures and variables are updated in a different manner and authentication bypass becames not possible until next process execution.
So, in order to successfully exploit this vulnerability, an attacker should either be able to track a rebooting device and perform his actions in the short time window or be able to reboot the device and then exploit the vulnerability.
While the first possibility may be unpractical from an attacker point of view, the second option may be more feasible in case the attacker has physical access to the device.
In facts, it may also seem that physical interaction is required for a reboot, but for DAP-1160… unfortunately… this is not the case
One of the vunerabilities published in the the IS-2010-004 advisory, allow for unauthenticated remote reboot of the device.
The dccd daemon, listening on port UDP 2003, allows for unauthenticated remote configuration of a DAP-1160 via properly formatted UDP messages; security relevant information can be set and queried and possibly interesting operations can be performed.
Again, the dccd daemon comes distributed in binary format and no source code is available, and it can be found insde the source code archive at the same path above specified.
Received, and valid, UDP messsages are processed by using different handlers that are triggered depending on the requested action; these handlers are shown in the picture below, where the handlers have been assigned meaningful names according to their function.
So reboot is one of the functionalities supported by the dccd daemon, and it is performed by killing init (see picture):
…without checking for authentication!
As described in the advisory, this functionality can be triggered with the following code snippet:
An attacker that is able to send UDP datagrams to the device is able to reboot it at will, exploit the authentication bypass vulnerability and access the web administration interface.
So, leveraging the IS-2010-004 vulnerability an attacker is able to perform remote exploitation of the IS-2010-005 vulnerability, that, otherwise, would have been not so easily exploitable and might have been relevant, probably, only in case the attacker had physical access to the device.
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.
Conclusion
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.
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:
If you are reading this post, you may possibly be interested in the stack overflow vulnerability on the Netgear WG6024, published here.
The vulnerability can be triggered by logging into the device and changing his admin password to something a bit longer than 128 characters.
This can be done by sending a proper POST request to the web server: either via some purposely written code or bypassing client side checks on the dedicated web page on the management interface
In both ways an overly long password will be saved in flash memory and will be used during authentication, overflowing a buffer on the stack and allowing for remote code execution.
In any case password will be “permanently” changed, web server will crash at each authentication attempt and reverting to a sane situation may require resetting the whole device, losing the whole configuration.
Reset can be performed by pressing the little button on the rear side of the device for more than 20 seconds, but, another solution is possible by using the serial interface present on the access point’s board, shown in the picture below along with its pinout.
That is a 3.3V TTL serial interface that can be used by means of proper a TTL-USB converter.
Please note that the connector is originally unpopulated in the stock AP, so I needed to solder some pins on the board, in order to connect to the serial interface with my TTL-USB converter and start a normal session over the serial interface.
Once connected, password can be restored by using the nvram command and restarting the AP in the following way:
nvram set http_passwd=password && nvram commit &&/sbin/reboot
nvram set http_passwd=password && nvram commit && /sbin/reboot
The password will be changed to “password” and will not overflow the buffer anymore; the web server will not crash during authentication and the web management interface can then be accessed in the usual way.
The whole AP configuration will remain untouched and will not force the victim (you? ;)) to go through the annoying re-configuration process.
