Wednesday, October 19, 2016

HENkaku - Exploit teardown - Stage 2

HENkaku - Stage 2

 

Stage 2's payload is composed by another ROP chain and data.
It creates two userland threads (each one with it's own ROP chain), that take care of leaking kernel pointers (by issuing devctl commands to "sdstor0:") and breaking the userland sandbox (by exploiting sceNet functions).
  
Stage 2 leverages a bug in sceIoDevctl in order to leak 2 distinct kernel pointers. These 2 pointers refer, respectively, to SceSysmem module's base address and SceIoFilemgr(?) thread's stack address:
  •     // Store leaked kernel pointer 1
        // Comes from devctl_outbuf + 0x3D4
        scesysmem_base = 0x00(x_stack + 0x00007308) + 0xFFFFA8B9
        // Store leaked kernel pointer 2
        // Comes from devctl_outbuf + 0x3C4
        sceiofilemgr_stack_base = 0x00(x_stack + 0x000072F8) + 0xFFFFF544
When preparing to write the kernel ROP chain, we can see a few pointers being set. These translate to:
  •     // Kernel ROP inside sceiofilemgr
        // This is where our ROP chain gets copied to inside the SceIoFilemgr module
        kern_rop = sceiofilemgr_stack_base + 0x000006F8
        // Encrypted kernel code
        kern_code = kern_rop + 0x300
Now we write down our kernel ROP chain in the stack, but we can see that some values only get written afterwards.
This is because these values are directly related to the decryption of the next kernel level stage! Team molecule likely only writes them into the ROP chain later so they can easily update the encrypted stage without having to change the kernel ROP chain directly.
So:
  •     // Overwrite specific NULLs in the ROP chain
        0x00(x_stack + 0x00008C04) = 0x00(x_stack + 0x00008EAC)     // kern_code
        0x00(x_stack + 0x00008B48) = 0x00000090
        0x00(x_stack + 0x00008CC0) = 0x00000240
        0x00(x_stack + 0x00008D58) = 0x00000200
        0x00(x_stack + 0x00008D14) = 0x00008FC0                     // kern_next_payload
And our final ROP chain should look like this:
Now we copy the chain from the stack into the buffer that's being sent through sceIoDevctl:
  •     // Copy kernel ROP chain
        memcpy(x_stack + 0x00007448, x_stack + 0x00008A8C, 0x300);
        // Copy the first 0x400 bytes of "obfuscated" data
        // and append them at the bottom of the ROP chain
        memcpy(x_stack + 0x00007744, x_stack + 0x00008EB8, 0x400);
And so, the final input buffer will look like this:
  •     // SceSysmem address
        // Unknown pointer written right on top of the input buffer
        0x00(x_stack + 0x00007444) = scesysmem_base + 0x0001E460
        // Kernel ROP chain
        0x00(x_stack + 0x00007448) = 0xXXXXXXXX;
        ...
        0x00(x_stack + 0x00007734) = 0xXXXXXXXX;
        // A few NULLs for padding
        0x00(x_stack + 0x00007738) = 0x00000000;
        0x00(x_stack + 0x0000773C) = 0x00000000;
        0x00(x_stack + 0x00007740) = 0x00000000;
        // Encrypted kernel code
        // Only the first 0x100 bytes will fit in the buffer
        0x00(x_stack + 0x00007744) = 0xXXXXXXXX;
        ...
        0x00(x_stack + 0x00007B44) = 0xXXXXXXXX;
Finally, we must craft a buffer that will have our ROP chain's SP and PC. This is the buffer we feed the SceNet exploit with:
  •     // Set kernel thread SP, PC, UNK
        0x00(x_stack + 0x0000884C) = sceiofilemgr_stack_base + 0x000006F8 + 0x00000004      // SP
        0x00(x_stack + 0x00008850) = scesysmem_base + 0x00000347                            // PC
        0x00(x_stack + 0x00008858) = sceiofilemgr_stack_base + 0x000006DC                   // UNK
When the SceNet exploit finishes, we should have hijacked a kernel thread inside the SceNetPs module and overwritten it's stack contents with our own.
This results in the kernel jumping to scesysmem_base + 0x00000347 (which is very likely a POP {PC} gadget) and executing our ROP chain at sceiofilemgr_stack_base + 0x000006F8 + 0x00000004 (which translates to kern_rop + 0x04).
  
To further reverse the exploit, one must dump the target kernel modules, rebuild the kernel ROP and deobfuscate/decrypt the rest of HENkaku's code.


Next up, stage 3!

No comments:

Post a Comment