Although D-Link’s CAPTCHA login feature has a history of implementation flaws and has been proven to not protect against the threat it was intended to thwart, they continue to keep this feature in their products. Today we’ll be looking at the CAPTCHA implementation in the D-Link DIR-605L, which is a big-endian MIPS system running Linux 2.4.
A pre-authentication vulnerability exists in the DIR-605L’s processing of the user-supplied CAPTCHA data from the Web-based login page. The formLogin function in the Boa Web server is responsible for handling the login data, and obtains the value of the FILECODE POST variable using the websGetVar function. The FILECODE value contains a unique string identifying the CAPTCHA image displayed on the login page, and is saved to the $s1 register:
$s1 = FILECODE
If the CAPTCHA feature is enabled, this value is later passed as the second argument to the getAuthCode function:
FILECODE value being passed to getAuthCode
The getAuthCode function saves the FILECODE value back to the $s1 register:
$s1 = $a1
Which in turn is passed as the third argument to sprintf, (note the ‘%s’ in the sprintf format string):
sprintf’s are bad, mmmk?
The result of the sprintf is saved to the address contained in $s0, which is the address of the stack variable var_80:
$a0 = var_80
This is a classic stack based buffer overflow, and overflowing var_80 allows us to control all of the register values saved onto the stack by getAuthCode’s function prologue, including the saved return address and the saved values of the $s0 – $s3 registers:
The decision has been made to open source the Reaver command line tool. The commercial version will contain the all the features the open source command-line tool has along with a web based client, support, and service options.
This means that the open source version of Reaver will have much requested features, such as identification of WPS enabled networks and pause/resume functionality.
This also means that Reaver will have the ability to specify specific options for a given model inside a database. In other words, if it is known that certain options are required or helpful when attacking XYZ router, you can put them in the database and they will be automatically applied whenever you target that model router. How often the FOSS database will be updated remains to be seen, obviously those paying for the support plan will take priority.
The latest Reaver release (1.3) now also implements the short DH key optimizations described in the original vulnerability release paper, which reduces computation time on the target AP and increases the attack speed.
The WiFi Protected Setup protocol is vulnerable to a brute force attack that allows an attacker to recover an access point’s WPS pin, and subsequently the WPA/WPA2 passphrase, in just a matter of hours.
This is something that I’ve been testing and using for a while now, but Stefan over at .braindump beat me to publication. Such is life.
Stefan’s code isn’t quite ready for release yet, so I’ve open-sourced Reaver, my WPS attack tool. Reaver is stable and has been tested against a variety of access points and WPS implementations.
Usage is simple; just specify the target BSSID and the monitor mode interface to use:
# reaver -i mon0 -b 00:01:02:03:04:05
For those interested, there is also a commercial version available with more features and speed improvements.
So far in this series we’ve found that we can log in to our target TEW-654TR router by either retrieving the plain text administrator credentials via TFTP, or through SQL injection in the login page. But the administrative web interface is just too limited – we want a root shell!
We’ll be doing a lot of disassembly and debugging, so having IDA Pro Advanced is recommended. But for those of you who don’t have access to IDA, I’ve included lots of screenshots and an HTML disassembly listing courtesy of IDAnchor.
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.
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.