A walk through of the hardware design is given in the video below; if you’re interested in how the collected infrared data can be used to identify and track your phone, be sure to check out their talk at the wireless village!
As mentioned in an update to my post on the HNAP bug in the DIR-890L, the same bug was reported earlier this year in the DIR-645, and a patch was released. D-Link has now released a patch for the DIR-890L as well.
The patches for both the DIR-645 and DIR-890L are identical, so I’ll only examine the DIR-890L here.
Although I focused on command injection in my previous post, this patch addresses multiple security bugs, all of which stem from the use of strstr to validate the HNAP SOAPAction header:
Use of unauthenticated user data in a call to system (command injection)
Use of unauthenticated user data in a call to sprintf (stack overflow)
Unauthenticated users can execute privileged HNAP actions (such as changing the admin password)
Remember, D-Link has acknowledged all of the above in their securityadvisories, and thus were clearly aware of all these attack vectors.
The past 6 months have been incredibly busy, and I haven’t been keeping up with D-Link’s latest shenanigans. In need of some entertainment, I went to their web page today and was greeted by this atrocity:
After finding D-Link’s WPS algorithm, I was curious to see which vendors might have similar algorithms, so I grabbed some Belkin firmware and started dissecting it. This particular firmware uses the SuperTask! RTOS, and in fact uses the same firmware obfuscation as seen previously on the Linksys WRT120N:
Being a known obfuscation method, binwalk was able to de-obfuscate and extract the compressed firmware image. The next step was to figure out the code’s load address in order to get a proper disassembly in IDA; if the code is disassembled with the wrong load address, absolute memory references won’t be properly resolved.
While perusing the latest firmware for D-Link’s DIR-810L 80211ac router, I found an interesting bit of code in sbin/ncc, a binary which provides back-end services used by many other processes on the device, including the HTTP and UPnP servers:
Call to sub_4D56F8 from getWPSPinCode
I first began examining this particular piece of code with the hopes of controlling part of the format string that is passed to __system. However, this data proved not to be user controllable, as the value placed in the format string is the default WPS pin for the router.
So far, thevulnerabilitiesfound 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:
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.