In part 2 of this series we found a SQL injection vulnerability using static analysis. However, it is often advantageous to debug a target application, a capability that we’ll need when working with more complex exploits later on.
In this segment we won’t be discovering any new vulnerabilities, but instead we will focus on configuring and using our debugging environment. For this we will be using Qemu and the IDA Pro debugger. If you don’t have IDA you can use insight/ddd/gdb instead, but in my experience IDA is far superior when it comes to embedded debugging.
In part 1 we used the TEW-654TR’s TFTP service to retrieve the administrative credentials to our target system.
But what if we didn’t have access to the TFTP service? Many embedded devices don’t have a TFTP service, or there may be a firewall between us and the target that blocks traffic to UDP port 69. In this case, we’ll have to take a closer look at the web application running on the target.
So far our tutorials have focused on extracting file systems, kernels and code from firmware images. Once we have a firmware image dissected into something we can work with, the next step is to analyze it for vulnerabilities.
Our target is going to be the Trendnet TEW-654TR. We’ll be examining many different security holes in this device, but for part 1 we will focus on gaining initial access given only a login page and nothing more. We will assume that we do not have physical access to the target device, nor to any other device for testing or analysis.
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.
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.