I’ve always envied CSI’s amazing IP address geolocation capabilities. Not only can they get your exact physical address based solely off your IP (right down to your hotel room number!), it even works on IP addresses that don’t exist!
While that level of IP address tracking is beyond the grasp of us mere mortals, MAC address geolocation provided by Google Location Services and Skyhook is pretty close. Just feed them the MAC address of your wireless router and they will tell you, with scary precision, where you are.
But what if you wanted to find the wireless MAC address of someone else’s router – remotely? Thanks to an information disclosure vulnerability in DD-WRT, you can.
If you are running DD-WRT and have set the ‘info page’ configuration to either ‘enabled’ (the default) or ‘disabled’, an unauthenticated remote attacker can get your:
Router’s LAN/WAN/WLAN MAC addresses
Router’s internal IP address
Internal client’s IP addresses and host names
All they have to do is make a GET request for the ‘/Info.live.htm’ page.
Now, I know what you’re thinking: “Surely this only affects DD-WRT routers that have remote administration enabled!” No, it doesn’t. And don’t call me Shirley.
This is exploitable even with remote administration disabled because DD-WRT is also vulnerable to a public IP DNS rebinding attack. That means that when a user inside your network browses to any Web site, that site can proxy requests through the user’s browser and pull this information from the router’s internal Web interface – no authentication or remote administration required. And, thanks to Rebind, pulling off this type of rebinding attack is pretty simple.
You can read a more detailed write-up on the vulnerability here, or watch the below video demonstrating the use of Rebind and Google Location Services to obtain the location of a DD-WRT router.
The D-Link WBR-1310 contains an authentication bypass vulnerability that allows remote attackers to change administrative settings without authentication. This can be used to enable remote management and change the administrative password.
Note that even if remote administration is not enabled, this vulnerability can be easily exploited via CSRF.
When examining embedded devices, it is not uncommon to find that two or more of them share common code, and even common hardware. This probably comes as no surprise, as re-using code and hardware designs helps lower production costs. What might be a little more surprising is when you find two devices from two different vendors that share the same code or hardware.
It’s important to be able to identify devices that use the same code or design. If you find a bug or vulnerability in one device, it’s likely that it affects other devices as well. Likewise, if you are having trouble reversing or analyzing a particular device, work that others have done on similar products can help put you on the right track.
No, this is not some new SSL vulnerability. In fact, it’s a really old vulnerability, as old as cryptography itself: keep your secret keys secret.
A lot of embedded devices provide HTTPS support so that administrators can administer the devices securely over untrusted networks. Some devices, such as SSL VPNs, center their entire functionality around SSL encryption. OK, well SSL isn’t perfect, but it’s still the de facto standard for Web-based encryption. So far, so good.
Here’s where it gets fun: many of these devices use hard-coded SSL keys that are baked into the firmware. That means that if Alice and Bob are both using the same router with the same firmware version, then both of their routers have the same SSL keys. All Eve needs to do in order to decrypt their traffic is to download the firmware from the vendor’s Web site and extract the SSL private key from the firmware image.
We’ve just released a new version of Binwalk, our open source firmware analysis tool. This release features new firmware signatures and a huge speed increase; scan times for large firmware images went from ~12 hours to less than a minute!
The UK firmware (version 4.11) for the D-Link DIR-615 revision D router contains a privilege escalation vulnerability in its HNAP service.
Using the unprivileged ‘user’ account on the device, local users can edit administrative settings, including the administrator password. Since the ‘user’ account is often ignored (default password is blank), this exploit is likely to work against any DIR-615 revision D router running the 4.11 firmware.
This vulnerability can be exploited using the hnap0wn tool. See our vulnerability report for more details.
We have discovered* an authentication bypass vulnerability that affects multiple D-Link routers, specifically those that use PHP based Web interfaces. So far we have confirmed that the following devices are affected:
It appears that the same PHP code was re-used among these routers, so it is likely that other routers are affected as well.
It should be noted that this vulnerability does not only affect those devices that have remote administration enabled. Even with remote administration disabled, this vulnerability can be exploited using a simple hidden image tag in a malicious Web page; as soon as someone behind one of these routers browses to the malicious page, their browser can be used to re-configure the device.
See our vulnerability report for more detailed information.
* It looks like Karol Celin from Safe Computing found this bug in some of the same routers we did and beat us to the punch! Good to see that others are looking at these devices too! See his BugTraq disclosure here. Our disclosure report further confirms that the DIR-320 and DIR-615 revD devices are also vulnerable.