D-Link Routers: One Hack to Own Them All
January 9th, 2010
We’ve been on hiatus over the past few months working on other projects, but last week we re-focused on D-Link routers. While we previously found a flaw in D-Link’s CAPTCHA implementation, this time around we’ve found a way to view and edit D-Link router settings without any administrative credentials.
The short story is that D-Link routers have a second administrative interface, which uses the Home Network Administration Protocol. While HNAP does require basic authentication, the mere existence of HNAP on D-Link routers allows attackers and malware to bypass CAPTCHA “security”. Further, HNAP authentication is not properly implemented, allowing anyone to view and edit administrative settings on the router.
HNAP appears to have been implemented in D-Link routers since 2006, and cannot be disabled. We have verified that vulnerabilities exist in the HNAP implementations of the DI-524, DIR-628 and DIR-655 routers, and suspect that most, if not all, D-Link routers since 2006 are vulnerable.
You can read our full write-up here, and download our POC tool, HNAP0wn, here.
- 62 Comments »
- Posted in Code, Papers, Vulnerabilities
January 9th, 2010 at 9:25 pm
Social comments and analytics for this post…
This post was mentioned on Twitter by dragosr: d-link APs, secret mgmt interface, sigh. DI-524, DIR-628 and DIR-655 + others http://bit.ly/7UrgT6...
January 10th, 2010 at 9:25 am
[...] die Seite SourceSec Security Research angibt, besteht bei den meisten, wenn nicht allen D-Link Routern, welche seit 2006 angeboten [...]
January 10th, 2010 at 12:25 pm
[...] “…HNAP appears to have been implemented in D-Link routers since 2006, and cannot be disabled. We have verified that vulnerabilities exist in the HNAP implementations of the DI-524, DIR-628 and DIR-655 routers, and suspect that most, if not all, D-Link routers since 2006 are vulnerable…” (sourcesc.com) [...]
January 11th, 2010 at 4:39 am
[...] http://www.sourcesec.com/2010/01/09/d-link-routers-one-hack-to-own-them-all/ [...]
January 11th, 2010 at 5:00 am
[...] Security Research berichtet über eine Sicherheitslücke auf D-Link Routern. Im Home Network Administration Protocol sei demnach Authentifizierung fehlerhaft implementiert. So [...]
January 11th, 2010 at 10:05 am
[...] [...]
January 11th, 2010 at 7:28 pm
[...] January, 2010, 2:28 am Prema postu na SourceSec Security Research web stranicama, mnogi – potencijalno D-Link router modeli [...]
January 12th, 2010 at 12:11 am
[...] it appears that D-Link routers implement a protocol which allows router reconfiguration via SOAP and don’t authenticate it properly. Mix in a little DNS rebinding and this likely results in [...]
January 12th, 2010 at 7:49 am
Confirmed working on my DIR-655 hardware version A3 firmware 1.21EU. Had to specify port 8099 to get it to work.
January 12th, 2010 at 2:46 pm
Are you aware of the fact that the 3 routers mentioned all use UBICOM boards, CPU’s with UBICOM32™ instruction-set and UBICOM’s
“own linux” as OS ? The firmware is made with the UBICOM SDK :
Basically it’s like lego-bricks, each function or subset of functions has it’s own module, the OEM’s then just need to select the modules that give the desired feature-set . The SDK can even auto-generate a UI .
So, Isn’t it quite possible this affects ALL routers with UBICOM-CPU’s ??
January 12th, 2010 at 3:03 pm
Of course the OEM’s can also code their own modules
so it could be just a D-Link issue ..
January 12th, 2010 at 5:59 pm
@Thomas:
Thanks for the confirmation! We’ve updated the hnap0wn script so that you shouldn’t have to specify the port anymore.
@Peter:
I was aware that they use UBICOMs, but wasn’t aware of the UBICOM SDK. If HNAP is indeed part of the UBICOM SDK, then I would suspect that all UBICOM-based routers would be vulnerable.
The only other routers that I’m aware of that support HNAP are Linksys, and they are not vulnerable to this particular attack. ZyXel supposedly also uses HNAP, so they may be another vendor to take a look at (though I don’t know if they use UBICOM or not).
January 12th, 2010 at 7:40 pm
I think you have found a pretty nasty issue with
UBICOMS implementation of HNAP, it has been part of the SDK since 2006 :
Release notes for SDK 7.0 July 15-2006
——————————————————————————-
Ubicom SDK 7.0 is the first SDK release supporting the IP5000 line
of microprocessors. The goal of this release is to provide ease-
of-development features, both from software innovation, and new
hardware functions. In addition, this release continues to expand
on the strengths of ipOS, delivering low-latency network traffic with
a high quality, small executable footprint. This release supports the
802.11n (draft) radio from Atheros.
This release focusses on the Home Router reference platform, this
is the only sample project included. Other sample projects will
be provided in future releases.
——————————————————————————-
Release features
o Server Side Includes (SSI)
o Reflection
o Draft 11n radio support
o IP5000 hardware features (new to ip5000)
o Wireless Intelligent Stream Handling (WISH)
o WiFi Simple Config
o Link Layer Topology Discovery (LLTD)
o Home Network Administration Protocol (HNAP)
o String Internationalization (i18n)
o Advanced XML handling
o Simplified HTTP serving
o Secure Sockets (TLS 1.0)
——————————————————————————-
http://developer.ubicom.com/wiki/index.php/IpOS
January 12th, 2010 at 10:47 pm
Ah, that would make sense since it looks like D-Link started adding HNAP support in late 2006. Very awesome, thanks for the info!
I did a quick look around, and the only routers that I was able to find that were reported to be using UBICOMs were D-Links; do you know of any other vendors that use them?
January 13th, 2010 at 12:58 am
[...] D-Link Routers: One Hack to Own Them All – sourcesec.com A flaw in D-Link’s CAPTCHA can prove to be a backdoor into the admin settings interface. [...]
January 13th, 2010 at 7:35 am
I just received this e-mail from
UBICOMS Robert Wessels :
“Peter,
Thank you for the report. I have forwarded the report to our engineering team who will diligently address the issue.
With regards to donating an SDK, we are working closely with the OpenWrt team and support for the UBICOM32 architecture will be available in the OpenWrt SDK soon.
Thanks again,
Robert Wessels ”
As for other router-brands using UBICOM :
Yes, there are other brands using it but I don’t remember the exact model-names right now, but I do have a small list somewhere. I’ll get back with some info when time allows me to.
Basically, if the back of the router looks anything like a DIR 655 and has a USB-port there is a good chance it’s a
UBICOM-board.
January 13th, 2010 at 7:47 am
Hi, I’ve tested on some D-link routers and must admit that this is working pretty well except on WBR-2310 that only administrator can play with the HNAP Protocol.
The test was made on:
WBR-2310
Hardware Version: A1
Firmware Version: 1.05
Thanks for the info tought we are addind this vuln to our pentest strategy.
January 13th, 2010 at 1:03 pm
hey whats am i doing wrong when i run this i get back
Default Creds Failed! Sorry
can someone tell me whats going on?
January 13th, 2010 at 4:42 pm
I have tried hnap0wn on a DI-524 with firmware “V2.04, Fri, Apr 28 2006″ without success. Even tried supplying my admin credentials to the script, but still no luck. It would seem that HNAP is not implemented or at least it is not present at the location the script is looking at.
January 13th, 2010 at 4:45 pm
By the way i think cross-domain restrictions on XMLHttpRequest in the browser would make it hard if not impossible to use exploit remotely. What are ur thoughts?
January 13th, 2010 at 8:19 pm
@Peter:
Awesome, thanks for the update. I found a list of at least a few UBICOM based routers here: http://www.dd-wrt.com/wiki/index.php/Known_incompatible_devices. Looks like D-Link routers are the most prevalent, but there might be some UBICOM-based Linksys routers vulnerable to this attack as well.
@Julien:
Thanks for letting us know about the WBR-2310; I’ll have to look and see if that model is uses a UBICOM chip set like the others. Based on the information Peter has given, I would suspect that it doesn’t, and that’s why it’s not vulnerable.
@awesomedonald:
If you get that message, then the SOAPAction header exploit failed, as did attempting to use the default user credentials. This could mean one of several things:
1) Your router isn’t vulnerable.
2) Your router doesn’t support HNAP.
3) Your changed the password of the router’s user account.
To check and see if HNAP is supported, see if you can browse to http:///HNAP1/. If it exists, then HNAP is supported and you should get an XML file returned; if not, then HNAP is not supported.
@ossipoff:
I believe that the firmware release v3.23 for the DI-524 was one of the first to support HNAP, so your firmware version almost definitely does not support HNAP. If you upgrade to version 3.23, the exploit should work.
Also, you are correct that the same-domain policy will prevent XMLHttpRequests from querying the router, which is why in the paper we mentioned that an attacker would have to use a DNS re-binding attack in order to exploit the HNAP vulnerability via the browser (see the reference links in the paper if you are unfamiliar with DNS re-binding).
It is also possible that an attacker could use GNUCitizen’s flash attack as well, but I don’t think that attack works with flash version 10 and later. You can read more about it here: http://www.gnucitizen.org/blog/hacking-the-interwebs/.
January 14th, 2010 at 11:21 am
DIR-625 isn’t vulnerable.
Firmware version 1.09 hardware version A1.
January 14th, 2010 at 11:59 am
These also use UBICOM :
D-Link Wireless 108G Gaming Router
SMC Barricade SMCWGBR14-N
Netgear WNDR3700
ZyXEL’s MIMO-N line
January 14th, 2010 at 1:49 pm
D-Link dir-655 f/w 1.30 ww not have password, when we use HNPA.
January 14th, 2010 at 3:18 pm
I can’t seem to find any detailed info about which models and FW versions are actually affected. All you find are dangerous half-truths… Are you planning on ivestigating this issue any further and releasing reliable info on the above question?
Cheers,
TheBloke
January 14th, 2010 at 5:59 pm
@Peter:
Again, thanks for all the info you’ve provided. We’ll see if we can get our hands on some other UBICOM routers to test their HNAP implementations.
@TheBloke:
I’m not sure what question you are referring to; I don’t see one in your post, nor any others that have not already been answered here.
I’m also not sure what “dangerous half-truths” you are talking about. We have been very clear as to exactly what this vulnerability is, and which routers we know are affected. We have confirmed that the DIR-655, DIR-628 and DI-524 are vulnerable to this attack. Other commenters here have informed us that the DIR-625 and WBR-2310 routers are not vulnerable, but I cannot personally vouch for them. Unfortunately, we do not have the time or money to buy every potentially vulnerable router and test it, so we can only speculate as to which other devices may likely be vulnerable.
We do plan on investigating this issue further with other D-Link devices, as well as routers from other vendors as time (and money!) permit. We will keep our blog updated with any additional findings.
January 14th, 2010 at 6:16 pm
@Craig:
Sorry for having been unspecific. I sincerely hope you didn’t take any offence. I greatly appreciate your work!
What I was referring to is that if I search for further info on the web re which other D-Link routers than those you have tested may be affected, I cannot find any authoritative answer. D-Link doesn’t seem to have released any official statement.
Regards,
TheBloke
January 14th, 2010 at 7:41 pm
No offense taken at all! I just wanted to make sure everything was clear and that you didn’t think that we were hiding any of our research here.
You are correct, it does not appear that anyone else has done any research into this vulnerability, or at least they have not publicized it. I can’t say I’m surprised – HNAP itself isn’t a very widely publicized protocol. In fact, the only way we could find any documentation on it was by locating the patent application that PureNetworks filed for it, which luckily had lots of details regarding the protocol and it’s supported SOAP actions.
I do know that Linksys products support HNAP (PureNetworks was acquired by Cisco), but they do not appear vulnerable. According to the information that Peter has provided, it looks like this may be an issue that affects all (or most) UBICOM-based devices, though D-Link appears to be the biggest UBICOM vendor that I’ve found so far.
January 15th, 2010 at 12:41 pm
D-Link claims these have already been patched 6 months ago take a look…
http://forums.dlink.com/index.php?topic=10330.0
January 15th, 2010 at 1:48 pm
@EndlessDreams:
The posts on the D-Link forum seem to differ in opinion. D-Link claims that this was patched 6 months ago, but PCWorld posted article today that seems to contradict this (http://www.pcworld.com/businesscenter/article/186996/dlink_issues_fixes_for_router_vulnerabilities.html).
To address the issue of the age of the firmware versions that we tested: Yes, the DI-524 is certainly an old router. The firmware version we used for the DIR-655 is also a bit out of date, but we were unable to upgrade the firmware for it, or even change any settings (this is a known bug in some of the DIR-655’s, not much we could do about that).
However, the DIR-628, which D-Link did not mention at all in their PCWorld quotations, was tested against the latest firmware available, version 1.22NA, which was released five months ago on 8/13/2009. If they knew about this bug and had in fact fixed it six months ago, I would have expected the fix to be present in this firmware release.
Even if we assume that this is an old vulnerability, it is certainly one that was not publicized, and it appears that D-Link may not even be aware of all the models that are affected.
Very few people upgrade their firmware. Just saying, “oh, it’s not the latest firmware, so it’s no big deal” doesn’t cut it. You need to let your customers know of the problem and urge them to upgrade or else it just won’t happen, and they will remain vulnerable. Though D-Link might not like the fact that we publicized this issue, we felt it was necessary to let everyone know about it in order to keep users informed of potential vulnerabilities in their networks. Ignorance is not security.
January 15th, 2010 at 1:58 pm
One other thing regarding the PCWorld post is that D-Link mentioned several routers that are affected by this vulnerability. As I stated in my last post, their list does not include the DIR-628 which we have confirmed is also vulnerable, so I would not consider this a comprehensive list, but it is a start:
“D-Link said the models affected are the DIR-855 (version A2), DIR-655 (versions A1 to A4) and DIR-635 (version B). Three discontinued models — DIR-615 (versions B1, B2 and B3), DIR-635 (version A) and DI-634M (version B1) — are also affected.”
http://www.pcworld.com/businesscenter/article/186996/dlink_issues_fixes_for_router_vulnerabilities.html
January 18th, 2010 at 10:20 pm
[...] SourceSac claim that all D-Link routers sold since 2006 were affected.” SourceSec apparently made their research available, including an exploitation tool, without ever contacting [...]
January 18th, 2010 at 10:39 pm
Pretty irresponsible of SourceSec to publish this without at contacting D-Link first. Professionals or just a bunch of script kiddies with a website?
January 18th, 2010 at 11:36 pm
Call us what you like jim (although I think we don’t technically qualify as “script kiddies” since we wrote our own script…
). I’ll preface this by saying that we’ve never worked directly with D-Link, however I’d like to make two points:
1) I guarantee that this issue has been addressed faster and been made known to more users who need to know about it (i.e., those who need to upgrade) than it ever would have been if we had contacted D-Link and waited for them to fix it.
2) Everyone loves to shoot the messenger. We’re “irresponsible” for having told D-Link customers of a vulnerability in their product that has been around for years and for all we know is already being exploited by those who have not made their discoveries public. What does that make the vendor who created and sold the product with the vulnerability in the first place?
January 18th, 2010 at 11:59 pm
Maybe not “script kiddiez” but definitely unprofessional to not notify the vendor *first* and give them a reasonable amount of time to provide a solution before releasing your exploit code and detailed information. This has been a vulnerability for what…3 years? what’s another 3-6 months for D-Link to fix this and publicize the issue themselves (giving SourceSec credit, of course)?
January 19th, 2010 at 12:15 am
To me 3-6 months isn’t a big deal. But the guy who is getting hacked and doesn’t know it because the vendor is taking a few months to fix a problem that can obviously be fixed in a few days might have a different perspective.
January 19th, 2010 at 3:42 am
Sorry Craig, but you guys are wrong on this. You’ve basically provided a hacking tool for an obscure exploit, opening this up to way more people than otherwise would have known how to handle this.
So, rather than a few people potentially getting hacked over the next 3-6 months while D-Link releases an update (if they need to), you’ve made it so that it’s extraordinarily likely that someone actually WILL get hacked even if the window until D-Link’s patch is less than a week.
I don’t believe security by obscurity is a valid form of bulletproofing, but it sure does keep out a lot of people that are malicious yet too stupid to figure it out.
With that said, I think you guys did a great job finding this hole, and you certainly deserve kudos for figuring it out.
January 19th, 2010 at 9:29 am
Jordan,
I agree that the threat is much higher now that everyone knows about the vulnerability, but I don’t think that the situation is quite so dire. The implication I presume is that now any script-kiddie can now use our tool to exploit the vulnerability. In reality, our POC code can only really be used against people who likely already have very lax security.
There are only a few scenarios where an attacker can exploit this remotely, which includes DNS re-binding, for which, AFAIK, there are no public tools available for performing, so they’d have to write their own which is non-trivial. It could potentially be exploited using a flash-based attack, but again, the attacker would have to code this themselves.
A local client can use our tool to exploit this bug, but they would have to be running Linux (or probably a Mac, but we didn’t test it on Macs). Most people run Windows, so even if some evil hacker gets a backdoor or other malware onto an internal user’s machine, that machine is almost always going to be a Windows box, so they’d have to write their own tool to implement the attack.
Now, that pretty much leaves two scenarios where script-kiddie attackers can use our tool successfully:
1) By gaining access to an un-secured (or poorly secured) access point, in which case the router is probably still using default credentials anyway and no security bypass exploit is required.
2) By exploiting some other open WiFi network, like hot-spots. The routers used in hot-spots are likely secured, so this could provide an attacker with access to the router. But users of open hot-spots really shouldn’t be expecting any type of security to begin with, so this presents an increased threat to them, but they shouldn’t really be surprised.
Now, script-kiddies aside, I agree with you: someone probably will get hacked. Talented attackers can certainly write their own attacks based on this vulnerability, and probably will. They are the real threat, and always have been. I’ll concede your point that this is now a much larger threat due to the growing number of people who are now aware of it.
I still think that making D-Link release a fix sooner rather than later is a good thing, and the only way to do this that I’m aware of is to disclose the vulnerability publicly. I’m still not sure why vendors never seem to take private disclosures seriously; disclose something publicly and it takes them 5 days to fix it. Disclose it to them in private and it takes them 5 months, on top of which they release very little information regarding the bug or which products are affected.
Thanks for the kudos – you’re right that this was a pretty obscure bug, and in fact HNAP itself is relatively unknown, so it was certainly an interesting find.
January 19th, 2010 at 10:47 am
“guarantee that this issue has been addressed faster and been made known to more users who need to know about it (i.e., those who need to upgrade) than it ever would have been if we had contacted D-Link and waited for them to fix it.”
Yeah, all the wrong people.
“I agree that the threat is much higher now that everyone knows about the vulnerability” -due to your unprofessional actions.
“but I don’t think that the situation is quite so dire” -then why not go through the proper channels?? Your last post sounds like you’re just trying to cover up the fact that you know was you did was unprofessional and irresponsible.
“you’re right that this was a pretty obscure bug” -but not any longer, thanks to you… You don’t know that it would have taken D-link 3+ months to release an update firmware. Of course, now they have no choice but to rush one out with minimal testing, possibly creating other problems.
January 19th, 2010 at 11:11 am
rocky,
“Yeah, all the wrong people.”
Normal users don’t watch for firmware updates. They don’t look at change logs. But hackers do. You say that all the wrong people now know about the bug, and that’s true. But so do all the right people, aka, end users. vendors can’t update their firmware for them, they have to be informed of the issue, and vendors don’t like making a big deal of security flaws in their products.
“due to your unprofessional actions.”
Well *obviously* it’s due to our actions…never said it wasn’t…
“then why not go through the proper channels?? Your last post sounds like you’re just trying to cover up the fact that you know was you did was unprofessional and irresponsible.”
Please don’t quote out of context. I don’t think that the situation is as dire as *Jordan* implied that it was. Our reasoning is, and always has been, that the threat is from the more advanced and/or privy attacker who had already discovered and begun exploiting this flaw that no one else knew about. I believe that if you read it, my previous post supports that position.
“You don’t know that it would have taken D-link 3+ months to release an update firmware. Of course, now they have no choice but to rush one out with minimal testing, possibly creating other problems.”
Nope, I sure don’t, but in my (and others) experience that’s about the right time frame. I don’t think that you’d find anyone that would expect them to get it out in a few days like they did unless the vulnerability was public.
As far as minimal testing goes, that appears to be what caused the issue in the first place. All we did to find this bug was change the default password on the router, then run the router setup utility that came with the router. All of the HNAP requests generated by the setup utility returned 401 unauthorized messages except for the GetDeviceSettings request. That process takes what, 5 minutes at the most? The majority of our time was spent investigating what HNAP was and how it worked, but D-Link should already know all of that since they built it into their routers. I believe that Cisco even has an HNAP-specific utility that will run through these types of tests automatically and report problems such as this one.
January 19th, 2010 at 11:32 am
This sounds more like “OMG we suck, what can we do to push our site up in Google rankings”. I found a server exploit in the code of one of your webpages. Maybe someone will give you the link after I post it to the rest of the internet.
January 19th, 2010 at 11:49 am
considering they haven’t had any news on their site in 7 months, and the news that they posted wasn’t even their news, I have to agree with jofu.
They may not be script kiddies, but they use the same tactics.
January 19th, 2010 at 1:07 pm
@jofu:
If you did, kudos to you – we run Wordpress, so that’s a huge vulnerability.
Also I’d like to point out that we didn’t notify PCWorld, ZDNet, ComputerWorld, Slashdot, etc about our findings. We posted them to the usual vulnerability disclosure places (Full Disclosure, Bugtraq, PacketStromSecurity, etc). The news sites picked up the story all on their own. Not that we mind the attention of course, but we didn’t whore the story out to them.
@1212:
Believe it or not, we have other projects to work on that do not pertain to security research, and thus do not belong on this site. We don’t post things just to take up space on the site – we wait until we have something interesting.
Could you please point out the news that we posted that wasn’t ours? Are you talking about the D-Link Captcha bypass? No wait, that was us. Are you referring to the work we did on WPS? No, that’s us too. Please be more specific.
Also, if I understand your post correctly, are you saying that script kiddies do SEO work? Because you know that’s not the definition of a script kiddie, right?
January 19th, 2010 at 1:21 pm
You were wrong. Admit it. How hard would it have been to post your findings to one more place: D-Link… Even Tiger Woods was man enough to admit that he was wrong.
As far as script kiddies go, I wouldn’t rate them as low as your organization. Trying to raise your popularity at someone else’s expense is never cool.
January 19th, 2010 at 1:36 pm
Thanks for finding this vulnerability. I confirmed that the vulnerability exists on a D-Link DIR-655 hardware version A3 running firmware version 1.21.
As Thomas noted previously, the exploit worked using port 8099, but not default HTTP port 80. You may wish to modify the hnap0wn bash script or its description to explicitly specify port 8099, i.e., rather than just . The same goes for the “Proof of Concept” example in dlink_hnap_captcha.pdf.
January 19th, 2010 at 1:55 pm
David,
Thanks for confirming!
Yes, newer D-Link routers run HNAP on port 8099, while the older ones seem to use port 80. The bash script uses wget, which should follow the redirect (the router should redirect the port 80 request to port 8099). Was this not the case?
January 19th, 2010 at 6:33 pm
craig,
I believe it was not the case under FW 1.21.
I have overwritten my DIR-655’s previous firmware version 1.21 with current North American firmware version 1.32NA for testing, so the following information is from my recollection of earlier today. I am using WGet 1.11.4 to test the exploit on the DIR-655.
When I issued a POST with an HNAP GetDeviceSettings header to the DIR-655 HW A3 FW 1.21 via the “http://[DIR-655 IP address]/HNAP1/” (default HTTP port 80) URL, the DIR-655 replied with GetDeviceSettings results no matter what the contents of the in the POSTed XML file were. I.e., the DIR-655 respected the HNAP GetDeviceSettings header and the exploit did not work. The DIR-655’s web server did not redirect WGet to new HNAP port 8099.
But when I did the same via “http://[DIR-655 IP address]:8099/HNAP1/” (new HNAP port 8099), the DIR-655 replied to the contents of the in the POSTed XML file. I.e., the DIR-655 ignored the HNAP GetDeviceSettings header and the exploit worked.
It sounds like Thomas found a similar result last week using DIR-655 FW 1.21EU.
January 19th, 2010 at 6:42 pm
Gah. I keep stupidly trying to enter angle brackets in comments, and they get vaporized along with their enclosed text.
My first comment should read: … i.e., (IP address:8099) rather than just (IP address).
My second comment should read: … no matter what the contents of the soap:Body in the POSTed XML file were.
and: … the DIR-655 replied to the contents of the soap:Body in the POSTed XML file.
Apologies for making a mess of this helpful thread.
January 19th, 2010 at 8:31 pm
Oops. I was wrong. A different problem crops up here.
The DIR-655 FW 1.32NA redirects (and probably redirected under FW 1.21, contrary to my earlier post’s claim) “http://[DIR-655 IP address]/HNAP1/” (default HTTP port 80) to HNAP port 8099. It does so by returning a 307 Temporary Redirect HTTP status code. WGet, arguably incorrectly, then turns the original HTTP POST to port 80 into an HTTP GET to port 8099, discarding the original POST’s XML file data. So you wind up with the result of a GET of “http://[DIR-655 IP address]:8099/HNAP1/” instead of the intended POST. That GET’s result is a GetDeviceSettingsResponse, which caused my earlier confusion.
Given WGet’s behavior, the hnap0wn bash script shouldn’t rely on the DIR-655’s redirect from port 80 to port 8099. Doing so has the effect of causing WGet to reduce the POST to a GET.
January 19th, 2010 at 9:16 pm
The HNAP vulnerability exists in D-Link DIR-655’s latest North American firmware, version 1.32NA, using port 8099.
January 19th, 2010 at 10:02 pm
David,
Thanks for all the updates. Maybe different firmware versions use different redirect messages? The redirection did work fine on the devices we tested. Of course, our version of wget might handle things differently too – different Linux distros like to change functionality like that some times.
In either case, thanks for posting the info here. We’ve updated the documentation and the script usage to include using port 8099.
January 20th, 2010 at 11:04 am
I don’t doubt it.
If you remove the ‘q’ option from the WGet command line, i.e., change “-qO” to “-O”, WGet will display the HTTP result returned from the server for the initial POST and the subsequent redirected request.
January 20th, 2010 at 7:29 pm
Thanks again for posting your results here David. Due to a faulty DIR-655, we were unable to test other firmware versions for that router, and there had been some debate as to whether or not the latest firmware was vulnerable. Now we know!
January 21st, 2010 at 9:38 am
You did absolutely right in publishing the POC-code .
It allows people to test if their router is affected,
script-kiddies hardly know what to do with it anyway and
real hackers don’t screw around with ordinary peoples systems .
The cyber-criminal crackers on the other hand DO mess with ordinary peoples systems and many of them also have the skills to make their own exploit and they wont publish it anywhere outside their own little circle .. And that’s GUARANTEED !
By publishing the code UBICOM and D-Link have been forced to
take the issue seriously from day 1 and my e-mail correspondence
with both show that they did just that. At no point did they deny the problem or try to downplay the seriousness of the issue
or drag their feet around instead of addressing it immediately as
you often see other companies do .
The publication of the code also makes it a lot easier for everybody to check if the fix actually works !
Apparently it doesn’t so maybe the problem is HNAP itself and not the implementation ?
January 21st, 2010 at 8:24 pm
Peter,
Are you saying that the new beta firmware that D-Link published to address the HNAP vulnerability did not fix the vulnerability? We have not yet tested the beta firmware as our DIR-655 is a lemon (won’t let us upgrade the firmware), and D-Link has not acknowledged that the vulnerability exists in the DIR-628, so we don’t expect a fix for that router unless they change their story.
The problem here should not be with HNAP. Per the protocol specifications, one MUST properly authenticate in order to perform administrative actions through HNAP. This seems to be just an implementation flaw, as other HNAP-enabled routers (Linksys) do not appear to be vulnerable.
January 21st, 2010 at 9:49 pm
[...] and edit D-Link router settings without any administrative credentials. You can read the rest here. __________________ Taking each day as it comes Grow, learn and OVERCLOCK. Need help?? Ask me. [...]
January 23rd, 2010 at 9:10 pm
Do you know if US firmware version 1.21 is effected?
Thanks
Eck
January 24th, 2010 at 9:16 am
Eck,
David made an earlier post stating that he tested the DIR-655 firmware 1.21 and found that it was vulnerable; I believe that it was the North American firmware release.
January 24th, 2010 at 1:12 pm
I must have missed it earlier. Great info I was watching HNN, and Dlink supposedly has a patch for the problem. However, it isn’t posted on their site. Might have to give Dlink a call after I play with this a little more.
Thanks
Eck
February 4th, 2010 at 7:29 pm
Here is the latest of WW version, i have tested it and seems it fixed the issue : http://support.dlink.co.id/firmware/DIR655A4_FW131WWB01.rar
February 24th, 2010 at 9:41 pm
I just read about this issue and came here. I have tested my US DIR-655 on firmware 1.11 (while I’m a professional programmer, I must admit I’ve rarely bothered to update my routers unless to fix a specific issue that got in my way). Interestingly enough, v1.11 doesn’t seem to have the vulnerability.
Using your hnap0wn script I get back a 401 Authorization Required for the GetDeviceSettings.xml post (and the others). So unless I’m overlooking something, it might be that D-Link originally had everything secure and opened it up accidently during a firmware update. I’m probably not going to try updating my firmware at this time
I also have an old D-Link DI-624 Rev C firmware 2.76 (the last firmware update, as this product is no longer supported), and it does have the user exploit (e.g. if user password is still default of blank, then I can update the admin password).
February 27th, 2010 at 8:45 pm
BobW,
Thanks for the update, and yes, if you got a 401 unauthorized then your firmware version isn’t vulnerable. The latest firmware for the DIR-655 should also have this bug fixed, but it’s funny that not keeping your firmware up to date kept you secure.
Thanks for the info on the DIR-624; like you said, it is old, but you see those old routers around all the time and I don’t think I’ve ever seen anyone change the user account logins for them.