DLink-614+ Script Injection Through DHCP HOSTNAME Option
22 Jun. 2004
Summary
"The DI-614+ is ideal for those creating their first wireless network, as well as for more advanced users looking for additional management settings and policy-based content filtering. Filters can be set based on MAC address, IP address, URL and/or Domain Name."
It is possible to inject malicious script through the DHCP HOSTNAME option thereby executing a script on behalf of the administrator when accessing the device. A variety of attacks are then possible, including setting an administrative password (without the need for the old one), resetting the device, and more.
Credit:
The information has been provided by c3rb3r.
Vulnerable Systems:
* DLink DI-614+ software revision 2.30, prior version possibly affected as well
Using DHCP as a method of attack, arbitrary and malicious scripting can be injected into the DHCP administrative and logs pages (if enabled). When the web administration toold is accessed, the code injection will execute with administrative privileges, which could lead to a complete compromise of the system.
The problem stems from improper filtering of the input received through the DHCP HOSTNAME option. What actually happens is that the HOSTNAME option is truncated to a mere 20 bytes if longer and it is displayed unaltered in the DHCP and log pages. The security hole can be used for example to set a new administrative password. Other operations are possible as well.
Eploitation Example
As an example, one can inject a script designed to force the administrator into restoring the box default settings using this nasty little script: <iframe height=0 width=0 src='restore.cgi'>
A call to the restore.cgi script will indeed restore the box to the default factory settings but there are a few problems:
* The length of the HOSTNAME option is truncated to 20 characters, as stated above. Thus, 20 characters are not enough to perform something useful using only one request. Splitting this script into 3 parts, sending each of them in a different DHCPREQUEST along with a different CLIENTID option or Mac address will create 3 new differents entries in the DHCP admin page, which could look like: <iframe height=0 wid** CGI ADDED STUFF **
th=0 src='restore.cgi'** CGI ADDED STUFF **
< ** CGI ADDED STUFF **
* The result is still not parseable by a browser because tags are inserted in the middle of the combined input (notice the example). However a dirty trick allows to circumvent this problem by finishing each fragment with an id option and doing so, quoting the ** CGI added stuff **. It can be done with four packets in the following manner: <iframe id='**CGI ADDED STUFF**
' height=0 id='**CGI ADDED STUFF**
' width=0 id='**CGI ADDED STUFF**
' src='restore.cgi'>
The result will be parseable by a browser, hence invoking the combined script that was injected. The result of the above example is that when the administrator opens the DHCP page the next time, the box's defaults will be restored, which means the password will become blank, wireless encryption will be disabled and others as well. If the attacker then has a way to log into the router, it is trivial to log in as the new administrator.
The vulnerability can be exploited from both normal and wireless networks.
Workaround
Since there is no fix and no response yet from the vendor, use static leasing only (it fixes the HOSTNAME option), otherwise just use a real dhcpd daemon (and disable DLINK's dhcpd).
