This vulnerability is a Buffer Overflow vulnerability in the WAVLINK WN530H4 router.

There was a buffer overflow vulnerability in /cgi-bin/makeRequest.cgi. The overflow occured in the main function, where it read the CONTENT_LENGTH environmental variable that came from a POST request in the browser. There was an fgets call at 0x406888 that read an arbitrarily long string of size CONTENT_LENGTH into a fixed buffer on the stack of size 512.

The bug was replicated in gdb for testing purposes. As seen below, the instruction pointer on the stack was overwritten with a series of "A" characters (ASCII 0x41) and the CPU attempted to jump to this address after popping it off the stack:

[ Picture coming soon ]

Because Address Space Layout Randomization (ASLR) is enabled for libraries and for the stack, I used Return Oriented Programming (ROP) to jump to the payload. Data Execution Prevention (DEP) was not enabled, making the stack executable.

ROP is a technique in which addresses in the program’s instruction memory are utilized to perform an attack. This is useful for when ASLR only randomizes stack space and not instruction space, like in this case. ROP is generally more useful with larger binaries, which was the case for the /cgi-bin/makeRequest.cgi binary.

In this case, I used ROP to jump to the stack. To do this, I found special sections of code, called "gadgets", that perform useful tasks, including causing the CPU to jump to a particular stack location. Specifically, I found gadgets that incremented the stack pointer, and then jumped to a location on the stack that I control through user input.

To craft this attack, I placed addresses on the stack in specific locations. This was trivial because I had insight into what the stack looked like. By reversing the binary, I knew that 564 characters can overflow the buffer before the first return pointer was overwritten. Additionally, I knew that the stack pointer would point to the first four bytes after the return address is overwritten. Essentially, I crafted an attack (which can certainly be improved) that followed the format below:

As noted in the table, there were two ROP gadgets. The first was at address 0x4050d8 and the second was at 0x40214c

First gadget at 0x4050d8:

lw      $ra, 0x94($sp)
lw      $s2, 0x90($sp)
lw      $s1, 0x8C($sp)
lw      $s0, 0x88($sp)
jr      $ra
addiu   $sp, $sp, 0x98

Second gadget at 0x40214c:

lw      $ra, 0x38($sp)
lw      $s3, 0x34($sp)
lw      $s2, 0x30($sp)
lw      $s1, 0x2C($sp)
lw      $s0, 0x28($sp)
jr      $ra
addiu   $sp, $sp, 0x40

Next, I created a payload that jumped to a bigger area on the stack:

addiu   $ra,$ra,-752
jr      $ra

At this point, the CPU jumped to the location of the real payload. The attack payload simply wrote 7 bytes, hacked\a, to standard out (fd 1). It additionally allowed for up to 1000 bytes to be written to standard out, which increased the payload size. The code for this attack is seen below:

addiu   $sp, $ra, 0x11A
li      $v0, 4004
li      $a0, 1
move    $a1, $sp
li      $a2, 1000
syscall                 ; write(1, $sp, 1000)
nop
nop
li      $v0, 4001
xor     $a0, $a0, $a0
syscall                 ; exit(0)
nop
nop

After compiling the payload, I submitted it as data to the web-server under the /cgi-bin/makeRequest.cgi endpoint. Unfortunately, the code did not execute with certainty 100% of the time. I believe this is due to the stack address that the program attempted to jump to; it may not be completely deterministic. However, I encapsulated the payload in a script to run it multiple times.

The attack is demonstrated in the figure below:

[ Picture coming soon ]

The final script is located on my GitHub.