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 security advisories, and thus were clearly aware of all these attack vectors.
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.
Today we’ll be jailbreaking the Netgear NTV300 set top box…with a TV remote.
The Netgear NeoTV 300
Negear’s NeoTV set top boxes are designed to compete with the popular Roku, and can stream video from all the usual sources (Netflix, HuluPlus, Youtube, etc). The NTV300 is one of the least expensive NeoTV models, and while a GPL release is available, it contains only copies of the various standard open source utilities used by the NTV300. All the interesting bits – such as Netflix streaming, or the ability to build a custom firmware image – are not included.
Inside the NTV300 we find a Mediatek ARM SoC, a 128MB NAND flash chip and 256MB of RAM:
Inside the NTV300
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:
getAuthCode stack layout
I have an old DTV converter sitting around gathering dust, so I thought it would be interesting to take a look inside:
Inside the DTV Converter
As you can see, there’s not much there: a Thomson TV tuner, an IR receiver, 32MB of RAM and a 2MB flash chip (on the underside of the board). What really makes this interesting though is the LGDT1111 SoC; this is a DTV chip manufactured by LG, so it’s a little different than the Broadcom/Atheros/Ralink/etc SoCs found in a lot of other consumer devices. It is very popular with many DTV converters though, so determining its CPU architecture and reversing the underlying firmware could be interesting.
Digging around on the Internet turned up a nice block diagram of the LGDT1111 (courtesy of MVPtek):
LGDT1111 Block Diagram
The MVPtek web site states that the SoC uses an “AMR926EJ-STM” controller…could they mean an ARM926EJ-STM? Hmmm…
Today we’re going to take a look at an interesting little device, the Linksys WMB54G wireless music bridge.
This is a pretty specialized device, so it’s likely a fairly minimalistic system. Even the administrative interface is small and simple:
WMB54G Administrative Interface
The Linksys support page doesn’t have any firmware updates available, so let’s take a peek at the hardware.
Opening the case reveals an expectedly limited system, with just 2MB of flash, 8MB of RAM and a small processor covered up by a heat sink:
There are two connectors on the right hand side of the board, labelled J5 and J9. J5 appears to be a JTAG connector, while J9 shows promise of being a serial port:
J5 and J9 Connectors