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: ftp://ftp.dlink.it/Products/DAP/DAP-1160/GPL/DAP-1160_v120b06_GPL.tar.gz 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...
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: ftp://ftp.dlink.it/Products/DAP/DAP-1160/GPL/DAP-1160_v120b06_GPL.tar.gz 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: `python -c 'print "\x05" + "\x00" * 7' | nc -u <IP_ADDR> 2003` 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.
