{"id":675,"date":"2017-08-20T21:14:20","date_gmt":"2017-08-21T05:14:20","guid":{"rendered":"https:\/\/www.pnfsoftware.com\/blog\/?p=675"},"modified":"2017-08-21T12:57:20","modified_gmt":"2017-08-21T20:57:20","slug":"firmware-exploitation-with-jeb-part-1","status":"publish","type":"post","link":"https:\/\/www.pnfsoftware.com\/blog\/firmware-exploitation-with-jeb-part-1\/","title":{"rendered":"Firmware Exploitation with JEB: Part 1"},"content":{"rendered":"

In this series of blog posts I will show how JEB\u2019s <\/span>MIPS decompiler<\/span><\/a>\u00a01<\/a><\/sup> can help you find and exploit software vulnerabilities in embedded devices. To do so, we will use Praetorian\u2019s <\/span>Damn Vulnerable Router\u00a0<\/span><\/a>Firmware <\/a> (DVRF) written by <\/span>b1ack0wl<\/span><\/a>.<\/span><\/p>\n

DVRF is a custom firmware made to run on a <\/span>Linksys E1550 router containing a bunch of memory corruption vulnerabilities. The goal of the DVRF is to serve as a playground to learn exploitation on the MIPS architecture. As far as I know, there are no write-ups of the challenges on the Internet.<\/span><\/p>\n

For the readers interested in testing the challenges by themselves, I suggest to follow the DVRF tutorial, and getting a <\/span>complete MIPSEL Debian QEMU image<\/span><\/a> as it allows the usual exploit development workflow on Linux, without any limits on the available tools.<\/span><\/p>\n

Recon<\/span><\/h1>\n

First things first, I extracted the binaries from the firmware with <\/span>binwalk<\/span><\/a>. Let\u2019s then do some recognition on the first challenge file:<\/span><\/p>\n

\r\n\r\nfile stack_bof_01\r\n\r\nstack_bof_01: ELF 32-bit LSB executable, MIPS, MIPS32 version 1 (SYSV), dynamically linked, interpreter \/lib\/ld-uClibc.so.0, not stripped\r\n\r\n<\/pre>\n
After loading it in JEB we can see several interesting functions:<\/span><\/p>\n
\"\"<\/a><\/p>\n
Among some classic libc interesting routines (system<\/em>, strcpy<\/em>\u2026), I noticed the aptly named \u201cdat_shell<\/em>\u201d function.<\/span><\/p>\n
\"\"<\/a><\/p>\n
As we see here, this function congratulates you for solving the challenge then spawns a shell with the call to system<\/em>. We now know that we want to redirect the execution flow to the dat_shell<\/em> function.<\/span><\/p>\n
Next, we see that the binary calls \u201cstrcpy<\/em>\u201d and that may just be a textbook case of buffer overflow. So let\u2019s check the main function, where strcpy<\/em> is called.<\/span><\/p>\n
\"\"<\/a><\/p>\n
First, it checks if we provided a command-line argument, and welcomes us. Second, it copies user input in a local variable and prints what we entered. Finally, it tells us to \u201cTry Again\u201d and then returns. Fortunately, strcpy<\/em>\u00a0does not check its input size, which results in a stack buffer overflow as the challenge\u2019s name indicates. <\/span><\/p>\n
Building the Exploit…<\/span><\/h1>\n
As you would do in a similar situation on a x86 binary, let\u2019s first run the binary inside a debugger with a large parameter to verify the overflow. <\/span><\/p>\n
To do this, I started a gdbserver on my QEMU VM and attached to it with JEB\u2019s debugger interface (see the <\/span>debugging manual<\/span><\/a> for more info). In MIPS ISA, the return address from a routine call is stored in a specific register called $ra,<\/em> which is also filled from the stack as you normally see on x86. It then jumps to that saved <\/span>return address.<\/span><\/p>\n
\"\"<\/a><\/p>\n
In our binary, we confirm that the return address is user-controlled by providing a large parameter — a series of 0x4F bytes –, and displaying the registers state after the strcpy<\/em> call:<\/span><\/p>\n
\"\"<\/a><\/p>\n
Let’s check the stackframe that I reconstructed to calculated the appropriate padding. You can access that view with the Ctrl+Alt+k shortcut in the function of your choice. I changed the type of the variable buf<\/em> to a char array of all the available size between the start of the variable and the next one. This gave me 200 bytes.<\/span><\/p>\n
\"\"<\/a><\/p>\n
The variables var04 and var08 are in fact the saved return address and the saved frame pointer of the main function. The result is that this offset is at 204 bytes because we fill the buffer with 200 bytes and overwrite the save frame pointer with four more. Let\u2019s try the following exploit:<\/span><\/p>\n
\r\n\r\n#!\/usr\/bin\/python\r\n\r\npadding = "O"* 204\r\n\r\ndat_shell_addr = "\\x50\\x09\\x40" # Partial overwrite with little-endian arch\r\n\r\npayload = padding + dat_shell_addr\r\n\r\nwith open("input", "wb") as f:\r\n\r\nf.write(payload)\r\n\r\n<\/pre>\n
\u2026Is Not So Easy<\/span><\/h1>\n
Surprisingly, our dummy exploit makes the program segfaults at the address 0x400970<\/em> — within the dat_shell<\/em> routine. Let\u2019s take a look at this address in JEB native view:<\/span><\/p>\n
\"\"<\/a><\/p>\n
We can see here a memory access to the address computed by adding the offset 0x801C<\/em> to the global pointer register $gp<\/em>. The problem here is that $gp<\/em> was initially set at the beginning of the routine from the $t9<\/em> register (see 0x4000958<\/em> above). <\/span><\/p>\n
So, where does the value in $t9<\/em> comes from? The answer lies in the way routines are usually called on MIPS (the calling convention): the $t9<\/em> register is first set to the address of the target routine, and is then branched to, for example with a jalr $t9<\/em> instruction (see MIPS ISA\u00a0<\/span>p.50<\/span><\/a>). The global pointer $gp<\/em>\u00a0is then initialized with $t9<\/em> and serves to compute various offsets, in particular to other functions that will be called, hence the fact that it absolutely needs to be correct.<\/span><\/p>\n
In other words, if the value of $t9<\/em> is not the address of dat_shell<\/em> when executing this routine, there is a good chance an invalid memory access will happen during the routine execution. To build a successful exploit, we need to load an arbitrary value from the stack into $t9<\/em> and then branch to it, as it was a real function call. <\/span><\/p>\n
To do so, we need a \u201cgadget\u201d, that is a series of instructions implementing the previously described behavior that we can jump to. In the search of this gadget, let\u2019s first check what dynamic libraries are loaded with the \u201clibs\u201d debugger command.<\/span><\/p>\n
\"\"<\/a><\/p>\n
Luckily, we have three libraries loaded at fixed memory addresses: libc.so.0<\/em>, libgcc_s.so.0<\/em> and ld-uClibc.so.0<\/em>. <\/span><\/p>\n
Interlude: ROP Gadget Finder Plugin for JEB<\/span><\/h1>\n
Using gadgets is a common need to build Return-Oriented-Programming (ROP) exploits, so I decided to develop a gadget finder plugin 2<\/a><\/sup>. Also, rather than searching gadgets from native instructions I decided to use JEB Intermediate Representation<\/strong> (IR), such that I could find gadgets on all architectures handled by JEB transparently.<\/span><\/p>\n
The end result is that when loading the three previously mentioned libraries in JEB, the plugin creates a view with all the gadgets:<\/span><\/p>\n
\"\"<\/a><\/p>\n
The output is free of duplicated gadgets and alphabetically ordered to ease the process of finding interesting gadgets. <\/span><\/p>\n
So, how does it work exactly? Using JEB\u2019s API, the plugin converts the native code to the IR used in the first stage of our decompilation pipeline. At this stage, all the side-effects of the native instructions are exposed and no optimizations have been made yet. <\/span><\/p>\n
To find gadgets — a series of instructions ending with a branch –, we simply search for the assignments on the program counter register and iterate backwards until another assignment on that register is made. The last step is to filter out relative jumps — which can not really be controlled during an exploit — and we got ourselves a good list of ROP gadgets. <\/span><\/p>\n
Again, this method works on all architectures as it is using only the IR.\u00a0<\/span>As an example, here is the same code running on an ARMv7 binary:<\/span><\/p>\n
\"\"<\/a><\/h1>\n
The published code can be found here<\/a>:<\/p>\n
Interlude End<\/span><\/h1>\n
Back to our challenge, using our plugin on the libc library, I found the following gadget at offset 0x6b20<\/em>:<\/span><\/p>\n
\"\"<\/a><\/p>\n
It copies a value from the top of the stack into the $t9<\/em> register, and branches to the $t9<\/em> register\u2026 perfect! <\/span><\/p>\n
The plan is therefore to use the vulnerable strcpy<\/em> to execute this gadget first, such that dat_shell<\/em> address will be called as a normal routine call would do. After deactivating Address Space Layout Randomization (ASLR) on our test machine, we can use the previously found libc base address for the exploit. The final exploit looks like this:<\/span><\/p>\n
\r\n#!\/usr\/bin\/python\r\n\r\nimport struct\r\n\r\n# LW $t9, 0($sp); JALR $t9;\r\n\r\ngadget_offset = 0x6b20\r\n\r\nlibc_base = 0x77eea000\r\n\r\ngadget_addr = struct.pack("<I", libc_base + gadget_offset)\r\n\r\npayload = ""\r\n\r\npayload += "A"*204 # padding\r\n\r\npayload += gadget_addr\r\n\r\npayload += "\\x50\\x09\\x40"\r\n\r\nwith open("input", "wb") as f:\r\n    f.write(payload)\r\n<\/pre>\n
And here we go!<\/p>\n

\n\"\"<\/a><\/p>\n
Special thanks to @b1ack0wl<\/a>\u00a0for the challenges and help and to @yrp604<\/a>\u00a0for the review. This post was also co-authored with our own @joancalvet<\/a>.<\/p>\n
Stay tuned for more MIPS exploitation blog posts!<\/span><\/h3>\n
\n
<\/div>\n
    \n
  1.  In this blog, we use JEB 2.3.3, which will roll out the week of Aug 21-25. ↩<\/a><\/span><\/li>\n
  2.  The gadget finder plugin will be published on GitHub later this week. ↩<\/a><\/span><\/li>\n<\/ol>\n<\/div>\n","protected":false},"excerpt":{"rendered":"
    In this series of blog posts I will show how JEB\u2019s MIPS decompiler\u00a01 can help you find and exploit software vulnerabilities in embedded devices. To do so, we will use Praetorian\u2019s Damn Vulnerable Router\u00a0Firmware (DVRF) written by b1ack0wl. DVRF is a custom firmware made to run on a Linksys E1550 router containing a bunch of … Continue reading Firmware Exploitation with JEB: Part 1<\/span><\/a><\/p>\n","protected":false},"author":4,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[8,13],"tags":[],"class_list":["post-675","post","type-post","status-publish","format-standard","hentry","category-jeb2","category-native-code"],"_links":{"self":[{"href":"https:\/\/www.pnfsoftware.com\/blog\/wp-json\/wp\/v2\/posts\/675","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.pnfsoftware.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.pnfsoftware.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.pnfsoftware.com\/blog\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/www.pnfsoftware.com\/blog\/wp-json\/wp\/v2\/comments?post=675"}],"version-history":[{"count":0,"href":"https:\/\/www.pnfsoftware.com\/blog\/wp-json\/wp\/v2\/posts\/675\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.pnfsoftware.com\/blog\/wp-json\/wp\/v2\/media?parent=675"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.pnfsoftware.com\/blog\/wp-json\/wp\/v2\/categories?post=675"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.pnfsoftware.com\/blog\/wp-json\/wp\/v2\/tags?post=675"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}