Hacking the D-Link DIR-890L

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:

D-Link's $300 DIR-890L router

D-Link’s $300 DIR-890L router

I think the most “insane” thing about this router is that it’s running the same buggy firmware that D-Link has been cramming in their routers for years…and the hits just keep on coming.

Continue reading

Reversing Belkin’s WPS Pin Algorithm

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:

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             Obfuscated Arcadyan firmware, signature bytes: 0x12010920, see https://github.com/devttys0/wrt120n/deobfuscator
666624        0xA2C00         LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 454656 bytes

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.

Continue reading

Reversing D-Link’s WPS Pin Algorithm

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

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.

Continue reading

A Code Signature Plugin for IDA

When reversing embedded code, it is often the case that completely different devices are built around a common code base, either due to code re-use by the vendor, or through the use of third-party software; this is especially true of devices running the same Real Time Operating System.

For example, I have two different routers, manufactured by two different vendors, and released about four years apart. Both devices run VxWorks, but the firmware for the older device included a symbol table, making it trivial to identify most of the original function names:

VxWorks Symbol Table

VxWorks Symbol Table

The older device with the symbol table is running VxWorks 5.5, while the newer device (with no symbol table) runs VxWorks 5.5.1, so they are pretty close in terms of their OS version. However, even simple functions contain a very different sequence of instructions when compared between the two firmwares:

strcpy from the VxWorks 5.5 firmware

strcpy from the VxWorks 5.5 firmware

strcpy from the VxWorks 5.5.1 firmware

strcpy from the VxWorks 5.5.1 firmware

Of course, binary variations can be the result of any number of things, including differences in the compiler version and changes to the build options.

Despite this, it would still be quite useful to take the known symbol names from the older device, particularly those of standard and common subroutines, and apply them to the newer device in order to facilitate the reversing of higher level functionality.

Continue reading

Hacking the DSP-W215, Again, Again, Again

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

The decode while loop

Continue reading

Hacking the DSP-W215, Again, Again

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"

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:

replace_special_char(entries[i]->value);

replace_special_char(entries[i]->value);

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

List of ASCII characters to be URL decoded, if necessary

Continue reading

Hacking the DSP-W215, Again

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.

Continue reading

Hacking the D-Link DSP-W215 Smart Plug

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

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.

Continue reading

WRT120N fprintf Stack Overflow

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:

401 Unauthorized

401 Unauthorized

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...");

bypass_file_list(“/cgi-bin/login /images/ /login…”);

Full list of bypass files

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.

Continue reading

Cracking Linksys “Encryption”

Perusing the release notes for the latest Linksys WRT120N firmware, one of the more interesting comments reads:

Firmware 1.0.07 (Build 01)
– Encrypts the configuration file.

Having previously reversed their firmware obfuscation and patched their code to re-enable JTAG debugging, I thought that surely I would be able to use this access to reverse the new encryption algorithm used to secure their backup configuration files.

Boy was I giving them way too much credit.

Here’s a diff of two backup configuration files from the WRT120N. The only change made between backups was that the administrator password was changed from “admin” in backup_config_1.bin to “aa” in backup_config_2.bin:

OFFSET        backup_config_1.bin              backup_config_2.bin
----------------------------------------------------------------------------------------
0x00001468    9E 9B 92 96 91 FF FF FF |........| / 9E 9E FF FF FF FF FF FF |........|

Two things to note here:

  • The first letter of each password (“a”) is encrypted to the same value (0x9E)
  • The same letter (“a”) is encrypted to the same value (0x9E), regardless of its position in the password

I immediately suspected some sort of simple single-byte XOR encryption. If true, then XORing the known plain text (“a”, aka, 0x61) with the known cipher text (0x9E) should produce the XOR key:

0x61 ^ 0x9E = 0xFF

Applying the XOR key of 0xFF to the other characters in the password gives us:

0x9E ^ 0xFF = a
0x9B ^ 0xFF = d
0x92 ^ 0xFF = m
0x96 ^ 0xFF = i
0x91 ^ 0xFF = n

And XORing every byte in the config file with 0xFF gives us a decrypted config file:

00000000  33 34 35 36 00 01 df 60  00 00 46 ec 76 31 2e 30  |3456...`..F.v1.0|
00000010  2e 30 37 00 00 00 00 00  00 00 00 00 00 00 00 00  |.07.............|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 57 52 54 31  |............WRT1|
00000030  32 30 4e 00 00 00 00 00  00 00 00 00 00 00 00 00  |20N.............|
00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000080  61 64 6d 69 6e 00 00 00  00 00 00 00 00 00 00 00  |admin...........|
00000090  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000a0  00 00 00 00 00 00 00 00  61 64 6d 69 6e 00 00 00  |........admin...|
000000b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000100  00 00 00 00 00 00 00 00  30 2e 30 2e 30 2e 30 00  |........0.0.0.0.|
00000110  00 00 00 00 00 00 00 00  01 01 01 00 00 00 00 01  |................|
00000120  00 00 00 01 00 00 00 00  00 00 00 08 32 39 34 38  |............2948|
00000130  33 31 30 35 00 01 00 00  00 31 39 32 2e 31 36 38  |3105.....192.168|
00000140  2e 31 2e 31 00 00 00 00  00 32 35 35 2e 32 35 35  |.1.1.....255.255|
00000150  2e 32 35 35 2e 30 00 00  00 00 00 00 04 00 02 00  |.255.0..........|
00000160  01 00 00 00 00 00 00 00  00 00 00 00 00 00 4c 4f  |..............LO|
00000170  4f 50 42 41 43 4b 00 00  00 00 31 32 37 2e 30 2e  |OPBACK....127.0.|
00000180  30 2e 31 00 00 00 00 00  00 00 32 35 35 2e 32 35  |0.1.......255.25|
00000190  35 2e 32 35 35 2e 32 35  35 00 00 00 00 00 00 00  |5.255.255.......|
000001a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001b0  00 00 00 00 49 52 51 3d  30 20 50 4f 52 54 3d 30  |....IRQ=0 PORT=0|
000001c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
...

This is truly atrocious. Given that “encrypting” the backup configuration files is done presumably to protect end users, expecting this to thwart any attacker and touting it as a product feature is unforgivable.

OK, I don’t really care that much. I’m just disappointed that it took longer to write this blog post than it did to break their “crypto”.