D-Link Router Input Validation Flaw in DHCP HOSTNAME Lets Remote Users Inject Scripting
SecurityTracker Alert ID: 1010562|
SecurityTracker URL: http://securitytracker.com/id/1010562
(Links to External Site)
Date: Jun 22 2004
Disclosure of authentication information, Disclosure of user information, Execution of arbitrary code via network, Modification of user information|
Exploit Included: Yes |
Version(s): Model DI-614+; Firmware version 2.30|
A vulnerability was reported in the D-Link DI-614+ router. A remote user can inject scripting code to be executed by a target administrator.|
Gregory Duchemin reported that the software does not properly validate user-supplied input in DHCP messages in the HOSTNAME field before displaying the information in the DHCP administrative pages and the log pages. A remote user can send a specially crafted DHCP message. Then, when a target administrator views one of the affected pages, arbitrary scripting code will be executed by the target administrator's browser. The code will originate from the router's administrative interface and will run in the security context of that interface. As a result, the code will be able to access the target administrator's cookies (including authentication cookies), if any, associated with the device, access data recently submitted by the target user via web form to the device, or take actions on the device acting as the target user.
The HOSTNAME field is truncated to 20 characters but is not otherwise filtered, the report said.
The vendor was reportedly notified on May 24, 2004 without response.
A remote user can access the target administrator's cookies (including authentication cookies), if any, associated with the device, access data recently submitted by the target administrator via web form to the device, or take actions on the device acting as the target administrator.|
No solution was available at the time of this entry.|
The author of the report indicates that, as a workaround, you can use static leasing or you can disable the D-Link DHCP feature and use a separate DHCP daemon instead.
Vendor URL: www.dlink.com/ (Links to External Site)
Input validation error|
Source Message Contents
Subject: DLINK 614+, script injection vulnerability|
-----BEGIN PGP SIGNED MESSAGE-----
TITLE: Security flaw in DLINK 614+ - SOHO routers (http://www.dlink.com)
TYPE: Script injection over DHCP
QUOTE from DLINK:
The AirPlus DI-614+ combines the latest advancements in 802.11b
design from Texas Instruments, utilizing their patented Digital Signal
ProcessingTM technology, and D-Link?s own robust firewall security
A simple yet intelligent, web-based setup wizard makes the DI-614+
easy for any
user to quickly and securely connect computers to share a high-speed
connection, files, resources, games or just to communicate. An
switch allows direct connection of up to four computers. Several wireless
clients can also securely connect to the network using 64, 128, or
The D-Link AirPlus DI-614+ is the ideal networking solution for small
home offices, schools, coffee shops and other small businesses that
cater to the
The DI-614+ SOHO router (latest firmware rev 2.30) suffers a "script
injection over dhcp" vulnerability.
Using DHCP as a vector, arbitrary and malicious scripting can be
injected into the DHCP administrative and logs pages (if enabled)
Scripting sent in such a way will be executed on behalf of the unaware
administrator when he consult the web based management interface and
lead to the complete compromising of the
firewall/router giving full access to the administrative account.
The DI-614+ does not filter user supplied data passed through the DHCP
Basically, it first truncates the string to 20 characters and displays
it AS IS in the DHCP and log pages
opening a large hole that can easily be exploited for instance:
to change the administrator password (doesn't require his current
password), to reboot the box, to reset the box's factory settings.
Because the DLINK 614+ is used, among others, by coffee shops, a
successful exploitation may have very serious impact.
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'>
where a call to restore.cgi indeed restore the box factory defaults.
the DI-614+ will truncate this code into:
<iframe height=0 wid ** CGI ADDED STUFF **
20 characters is obviously not enough to do something useful here.
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.
<iframe height=0 wid** CGI ADDED STUFF **
th=0 src='restore.cgi'** CGI ADDED STUFF **
| ** CGI ADDED STUFF **
the result is still bogus from a browser perspective, because of the
other tags (noted above as CGI ADDED STUFF) inserted between
each new entry.
However a dirty trick allows to circumvent this problem by finishing
each fragment with an id option and doing so, quoting the ** CGI added
like this (this time in four packets):
<iframe id='**CGI ADDED STUFF**
' height=0 id='**CGI ADDED STUFF**
' width=0 id='**CGI ADDED STUFF**
Result is quite awful for a human but also readable for most browsers,
afterwhat, next time the site administrator opens the DHCP page,
he will automaticaly, and without notice, restores the box default
password (blank), disable wireless encryption, etc...
Finally X has to connect to 192.168.0.1 (default address), and voila !
he is administrator.
This vulnerability can be exploited from both wire and wireless networks.
The solution is simply to filter the HOSTNAME DHCP option supplied by
users by escaping html meta-characters
DLINK's support staff has been contacted by May 24th but didn't reply
to my questions
No idea if a new firmware will be made available soon and even if they
are currently working on it
It looks like they just don't care too much about security.
Use static leasing only (it fixes the hostname) otherwise just use a
real dhcpd daemon (and disable DLINK dhcpd)
firmware up to rev 2.30 (latest)
AUTHOR: Gregory Duchemin (c3rb3r at sympatico.ca)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
Go to the Top of This SecurityTracker Archive Page