So far, the vulnerabilities found in the DSP-W215 have only been practically exploitable from the LAN, unless someone was foolish enough to make their smart plug remotely accessible on the Internet.
The typical way for external attackers to target internal web servers, such as the one running on the DSP-W215, is through CSRF. The problem is that any web browser used for a CSRF attack will URL encode binary values, such as our return addresses, but thus far the vulnerabilities we’ve exploited don’t URL decode our data (note that the replace_special_char function exploited in the last vulnerability only URL decodes a small range of ASCII values).
The my_cgi.cgi binary, which has been our primary target for exploitation, contains a decode function which is responsible for URL decoding POST data. This function accepts only two arguments, which are a pointer to the encoded data and a pointer to a destination buffer to store the decoded data:
void decode(char *encode_buf, char *decode_buf);
The decode function simply loops through all of the bytes in encode_buf, decoding/copying them blindly into decode_buf:
The decode while loop
Here we go again…again.
In the last DSP-W215 exploit, I mentioned that the exploit’s POST parameter name had to be “storage_path” in order to prevent the get_input_entries function from crashing prematurely. That’s because there is another stack overflow, this time in the replace_special_char function, which is called by get_input_entries if the POST parameter name is neither “storage_path” nor “path”:
Checking the POST parameter name against “storage_path” and “path”
The replace_special_char function is passed a single argument which is a pointer to the current POST value being processed:
The replace_special_char function is responsible for URL decoding a small set of common ASCII characters:
List of ASCII characters to be URL decoded, if necessary
D-Link recently released firmware v1.02 for the DSP-W215 to address the HNAP buffer overflow bug in my_cgi.cgi. Although they were quick to remove the download link for the new firmware (you must “Use mobile application to upgrade device”), I grabbed a copy of it before my trip to Munich this week, and the 8 hour flight provided plenty of quality reversing time to analyze the new firmware more closely.
Unfortunately, the HNAP bug was just the beginning of the smart plug’s problems.
The D-Link DSP-W215 Smart Plug is a wireless home automation device for monitoring and controlling electrical outlets. It isn’t readily available from Amazon or Best Buy yet, but the firmware is up on D-Link’s web site.
The D-Link DSP-W215
TL;DR, the DSP-W215 contains an unauthenticated stack overflow that can be exploited to take complete control of the device, and anything connected to its AC outlet.
Here are the slides from my short talk on getting started using JTAG. Thanks to everyone who came out!
Just got back from the EELive conference in San Jose – great talks, great people, and way better weather than we had back here on the east coast.
For those interested, the slides for my talk, “Finding and Reverse Engineering Backdoors in Consumer Firmware” can be found here. If you get a chance to go next year, I highly recommend it!
Since starting our in-seat Embedded Device Exploitation class, we’ve been getting queries about offering the class online.
Well, good news: it’s coming! But, we need to gauge interest before deciding to go all-in, so if you want to see EDE offered online, go to www.edetraining.com and submit your email address. We’ll notify you as soon as online registration is available!
In honor of all the good fun we’ve had at Linksys’ expense, students can use the promotional code LINKSYS to get a 30% discount off our Embedded Device Exploitation course on March 10th!
Our next Embedded Device Exploitation class will be held March 10-14th, 2014 in Columbia, MD. Registration is now open!
With a good firmware disassembly and JTAG debug access to the WRT120N, it’s time to start examining the code for more interesting bugs.
As we’ve seen previously, the WRT120N runs a Real Time Operating System. For security, the RTOS’s administrative web interface employs HTTP Basic authentication:
Most of the web pages require authentication, but there are a handful of URLs that are explicitly allowed to bypass authentication:
bypass_file_list(“/cgi-bin/login /images/ /login…”);
Full list of bypass files
Any request whose URL starts with one of these strings will be allowed without authentication, so they’re a good place to start hunting for bugs.