Student ID: SLAE-1250
Assignment Five: Analysis of Shellcode Part Three - linux/x86/exec
This blog post has been created for completing the requirements of the SecurityTube Linux Assembly Expert Certification:
http://www.securitytube-training.com/online-courses/securitytube-linux-assembly-expert/index.html
All code can be found in: https://github.com/securitychops/security-tube-slae32
All work was tested on a 32bit version of Ubuntu 12.10
TLDR; - JMP short Final_Breakdown
Part three of assignment five of the SLAE has us performing the final analysis of the Linux/x86 shellcode payload from msfvenom: linux/x86/exec
Just like in part one and part two we must first generate our shellcode to perform our analysis on!
As with the previous blog entires in the SLAE series, we start off by generating our shellcode and immediately converting it to base64 for easy transport between computers.
The msfvenom command used was as follows:
msfvenom -p linux/x86/exec CMD=id | base64
Which produced the following output:
agtYmVJmaC1jiedoL3NoAGgvYmluieNS6AMAAABpZABXU4nhzYA=
after moving the base64 encoded contents into a file on the x86 Ubuntu VM I converted it back to raw with:
cat linux-x86-exec.b64 | base64 -d > linux-x86-exec
followed by the following command to start to analysis via ndisasm:
cat linux-x86-exec | ndisasm -u -
“-u” specifies x86 and “-“ specifies to use the contents piped into it from the cat operation
which produced the following disassembled output:
00000000 6A0B push byte +0xb
00000002 58 pop eax
00000003 99 cdq
00000004 52 push edx
00000005 66682D63 push word 0x632d
00000009 89E7 mov edi,esp
0000000B 682F736800 push dword 0x68732f
00000010 682F62696E push dword 0x6e69622f
00000015 89E3 mov ebx,esp
00000017 52 push edx
00000018 E803000000 call dword 0x20
0000001D 696400575389E1CD imul esp,[eax+eax+0x57],dword 0xcde18953
00000025 80 db 0x80
Given how small this block of code is we are going to try something different this time and just work through each line at a time to see if we can’t get a handle on what this shellcode is doing!
ASM Code Block One
00000000 6A0B push byte +0xb
00000002 58 pop eax
These two lines should look pretty familiar at this point as this is the value of the function to call being popped into the eax register, which is 0xB (decimal 11).
If we investigate what this value represents by referencing /usr/include/i386-linux-gnu/asm/unistd_32.h we will see that it is making a call to the execve function
__NR_execve
which has a C function signature of:
int execve(const char *filename, char *const argv[], char *const envp[]);
There are several things we need to revisit about making a call to execve. The first is that the first parameter, filename, just needs to point to a memory address containing the value for the command to execute (/bin/sh). The second parameter is where the real magic is happening as we will need to point to a memory address that contains the following values: [/bin/sh, -c, id]. The third parameter in our case can simply be null since we won’t have any environment specific information to pass into the function.
Lets start by diving into the code and figure out how to make all of this happen!
The very next instruction we encounter is:
00000003 99 cdq
This instruction is a fairly interesting one in that it takes advantage of the sign bit that is already present in the eax register (0000 0000 0000 0000). cdq will take whatever the value of the sign bit is in the eax register and copy that bit into every single bit in the edx register, so really this is just a different way of performing a xor operation on edx!
The value stored in the edx register will end up being incredibly useful to us throughout the code block since this parameter will end up being null as we have no environmental settings to pass to the function, or the equivalent of an ‘\0’ that we can use over and over to push to the end of any string (char array) we need to null terminate…
00000004 52 push edx
Speak of the devil, the very next instruction has us pushing edx (‘\0’) onto the stack in order to null terminate the instruction that comes after it (since this is x86 / little endian)!
00000005 66682D63 push word 0x632d
This will push c- to the stack (or logically it will be -c) and since we have already pushed a null terminator what we really end up having is -c\0
00000009 89E7 mov edi,esp
The previous instruction may seem a little weird at first, but as we will eventually need to store the values currently in esp in ecx we are going to need to offload it to another register that we can later move to ecx since we are about to need to use the stack again for a bit…
0000000B 682F736800 push dword 0x68732f
00000010 682F62696E push dword 0x6e69622f
Now that we have offloaded the previous value of the stack to edi we can now freely push “h/sh “ and “nib/” to the stack which will actually end up logically translating to: /bin/sh since we are dealing with x86 / little endian.
After this we see the following commands:
00000015 89E3 mov ebx,esp
00000017 52 push edx
This instruction will move esp (or the address pointing to /bin/sh) to the register ebx, which in our C code is parameter const char *filename!
After which it immediately pushes a null onto the stack in order to null terminate the string!
At this point in our code we have now accounted for both ebx and edx and our function call looks like the following:
int execve("/bin/bash\0", char *const argv[], "\0");
Another thing to keep in mind as we keep moving forward is that the value of the register edi is also currently (logically) set to: -c\0”
Having said all of that it is at this point we again face several instructions that look a little suspect:
00000018 E803000000 call dword 0x20
0000001D 696400575389E1CD imul esp,[eax+eax+0x57],dword 0xcde18953
00000025 80 db 0x80
If you were thinking these just didn’t look like they could be the correct instructions then you would be spot on, as we once again have some mangled instructions due to a string being in the middle of these commands. Our original command to execute was id which just so happens to translate to the hexadecimal characters 0x69, 0x64 and 0x00!
If we run the following command:
echo 696400 | xxd -r -p
it will indeed output:
id
This is particularly useful since the value of id was accessed via a call to the address of id which will cause the address of id to end up being stored on the stack!
After accounting for the hex values of 0x69, 0x64 and 0x00 we are left with the following hexadecimal values to re-translate into assembly code for analysis: 575389E1CD80
Feeding those values back into ndisasm with the following command:
echo -ne "\x57\x53\x89\xe1\xcd\x80" | ndisasm -u -
we get the following output:
00000000 57 push edi
00000001 53 push ebx
00000002 89E1 mov ecx,esp
00000004 CD80 int 0x80
These set of codes definitely look much better!
At this point we push edi, but why, what is in edi? Well, edi currently contains -c and by pushing it we are logically causing the stack to currently look like [-c, id] which is just one element away from being done!
After pushing edi we unsurprisingly push ebx which has the value /bin/bash.
Next up we move the address of the stack (esp) into ecx which means we now have [/bin/bash, -c, id] stored in ecx!
After the mov ecx,esp our function call now looks like:
int execve("/bin/bash\0", "{/bin/bash, -c, id}", "\0");
At this point we are ready to make the call to execve, which is rather convenient since the very next instruction is int 0x80, which is the interrupt command which will indeed fire execve and execute the id command!
Final_Breakdown:
The linux/x86/exec shellcode from msfvenom performs the following steps:
- Executes execve with the following function signature:
int execve("/bin/bash\0", "{/bin/bash, -c, id}", "\0");
Just for completeness I have also included the final disassembled assembly code after accounting for id throwing off the disassembly:
push byte +0xb
pop eax
cdq
push edx
push word 0x632d
mov edi,esp
push dword 0x68732f
push dword 0x6e69622f
mov ebx,esp
push edx
call dword 0x20
push edi
push ebx
mov ecx,esp
int 0x80
