CVE-2018-11013 D-Link DIR-816 OOB BoF
Well, it is time to practice my poor English by writing internationalized post, not in the future. I would appreciate it if you could point me out the inappropriate usage of English. Return to the rop, CVE-2018-11013 is a stack based BoF in D-Link DIR-816 router, the author has exploited it in an interesting way, which is so abstract that I explored as fllows.
- Firmware: DIR-816A2_v1.10CNB03_D77137.img
- Operating System: Kali with correct binwalk
- Debugger: pwndbg, gdb-multiarch
As the original blog said, it is convenient to debug http service with internal
telnetd in low version firmware. We can find the differences by binwalking them:
Although the telnetd isn’t started by default, we can still turn it on by accessing d_telnet.asp, just looks like a kind of backdoor, isn’t it?
What we should do is to upload gdbserver.mipsle using its tftp binary and debug it whenever you want.
The vulnerability in websRedirect function is the OOB write, the loop storing byte to stack doesn’t stop until it meets byte ‘:’ or ‘\n’:
At this time, $a1 is the loop counter, $a0 is the source HTTP_HOST in HTTP request header, and $s2 is the var_E0.When the host header is larger than (0xE0-0x40-0x4) bytes, the $ra register will be overwrited.
After sending out your AAAA stuff, you will figure out that the stack in high address is still accessed in later instruction:
Therefore, the corresponding positions of var_30 and var_2C should be an accessable address.
With the accurate offset, the final step is to construct rop or shellcode. It is also the time to checksec goahead binary:
The binary is naked and the heap is also executable.The ASLR on the system is 1, and the heap address is not changeable:
Witout information leak, we can’t use the gadget in libuClibc, the mipsle architecture and host ‘\x00’ block make us use only once ret2somewhere. The author’s solution is to generate a request larger than 64k, the http data will be malloced to the unchangeable heap, the final jump will be much easy too. What a good idea!
The reason why the limit is 64k is obvious in goahead’s source code, which I search for a long time:
The WEBS_DEFAULT_MEM is just the limit 64k. Thanks to msfvenom, the shellcode won’t be a challenge:
We can exploit it now:
For fresh water comes from the source, it is a good idea and chance to learn the exploitation in the IoT world.