2009
12.27

The Sulley Framework -Basic-

Ref.: Gray Hat Python

The framework is coded entirely from Python and is open source.

Developed by Pedram Amini and Aaron Portmoy from Tipping Point, Sulley is a fuzzer packed with interesting capabilities. Such as packet-capturing, crash reporting and VMware automation. It also has the capability to restart the target application in the event of a crash. Then continues on with the fuzzing process.

For data generation, Sulley uses a block-based fuzzing, the same method used as Dave Aitel’s SPIKE. So if you’re familiar with SPIKE, you shouldn’t have much trouble with this fuzzer. In block based fuzzing, you build up a general skeleton for the protocol or file you are fuzzing. There’s going to be an example later in this post.

One great feature this fuzzer has over others, is the ability to show the CPU’s registers at the moment of the crash. Sulley comes with PyDBG, and once the framework installed it uses this to monitor the process you are fuzzing. Another one is Sulley’s ability to monitor the network (using pcapy), capturing every “fuzz” sent to the target. Creating one pcap file for each attempt. This way you can follow your progress, or review your fuzzing session. Lastly, you can even see the fuzzing progress via an HTML page. The page shows you which variable it’s currently fuzzing and it’s progress.

Sulley Primitives

Strings
Sulley uses the s_strings() directive to denote that the data contained is a fuzzable string. So we wantd to fuzz an email address, we’d declare it like this in our skeleton:
s_string(“fuzzing@sulley.com”)
This tells Sulley it’s a valid value, so it will fuzz that string and exhaust all reasonable possibilities. Once it’s finished, it will revert to it’s original value and continue fuzzing the rest of the declared values down the file.

Delemiters
This is just a small string that helps break up larger ones. If we take our email example from above, the delimiter would be the “@” sign. This is how we’d passe this primitive on to Sulley:
s_string(“fuzzing”)
s_delim(“@”)
s_string(“sulley”)
s_delim(“.”)
s_string(“com”).
Like the s_string() primitive, the delimiter is also fuzzed. In this example, odds are the “.” is a value we really don’t need to so we can tell Sulley to not fuzz it like so:
s_delim(“.”, fuzzable=false)

Static
The values passed to a static string, remind unchanged (or un-fuzzed I suppose).
s_static(“\r\n”)

So let’s take a look at a complete, yet small and simple, skeleton file. In this example, we’ll look at the FTP protocol.

# import all of Sulley’s functionality
# We’ll call this file ftp_ability.py
from sulley import *

s_initialize(“user”)
s_static(“USER”)
s_delim(” “)
s_string(“ftp”)
s_static(“\r\n”)

s_initialize(“pass”)
s_static(“PASS”)
s_delim(” “)
s_string(“ftp”)
s_static(“\r\n”)

s_initialize(“stor”)
s_static(“STOR”)
s_delim(” “)
s_string(“AAAA”)
s_static(“\r\n”)

You can see, it’s pretty simple. This file basically feeds Sulley with starting values and it takes it from there. Fuzzing the fields you denoted as fuzzable. In this case; the username, password and STOR command. Depending on the target FTP server, you’ll add and/or remove commands. Not every FTP server will have “STOR”, and not all of them have “LIST” … So this is where you’d supply a valid list of commands.

Now that we’ve seen our blocks, lets take a look at the session file. The file that starts the whole fuzzable process.

from sulley import * # import everything from Sulley
from requests import ftp_ability # this is our ftp_ability.py file from requests folder

def receive_ftp_banner(sock):

sock.recv(1024)

sess = sessions.session(session_filename=”audits/ability.session”)
#Target IP xxx.xxx.xxx.xxx
target = sessions.target(“xxx.xxx.xxx.xxx”, 21)
target.netmon = pedrpc.client(“xxx.xxx.xxx.xxx”, 26001)
target.procmon = pedrpc.client(“xxx.xxx.xxx.xxx”, 26002)
target.procmon_options = { “proc_name” : “Ability Server.exe” }

sess.pre_send = receive_ftp_banner #grab the banner
sess.add_target(target)

sess.connect(s_get(“user”)) # Notice our commands from the previous file
sess.connect(s_get(“user”),s_get(“pass”))

# This tells Sulley user must be authenticated to use this command

sess.connect(s_get(“pass”),s_get(“stor”))

sess.fuzz()

Because most FTP servers send a banner, we tell Sulley to wait for it before fuzzing any data.
The next thing, is the session file which keeps track of our overall session. This allows us to stop and restart our fuzzing where we had previously left off.
After that we define our target with the appropriate IP and port number. In this case, a FTP server.
After defining the target, we tell our network sniffer to set itself up on the same host and listening on 26001.
Last we tell our debugger is listening on the same host and that is listening on 26002.
We chain in the authentication commands and tell Sulley to start fuzzing.

To start the fuzzing process, we need to have Sulley installed on 2 machines (I find it less confusing this way). The attacking and victim machines.
From the target machine
1: start the process we want to fuzz (this case Ability Server)
2: attach the process monitor to our server.
C:\sulley>python process_monitor.py -c c:\ability.crash -p “Ability Server.exe”
3: attach the network monitor to our network card and have it sniff for specific traffic. The -P parameter is to store your pcaps file. You must create this folder first. You can use a mapped drive too.
C:\sulley>python network_monitor.py -d 1 -f “src or dst port 21″ -P z:\

From our attacking machine
1: execute the session file from Sulley’s root directory
C:\sulley>python ftp_session_ability.py

Once the process has started, you can point your browser to the attacking machine’s IP on port 26000 to get a progress report. You need to manually refresh the page. Once the application crashes, you’ll be able to see the crash report on the page. Enabling you to see what/where was overwritten in the CPU’s registry.

You can get the install executable here
And the PDF here
Here’s a video on kioptix.com demonstrating all of this. Using the same files and vulnerable application mentioned above. Thanks to dookie for pointing out a few mistakes of mine while I was setting up Sulley for the first time. Also the Gray Hat Python book that gave me a good push with this.

Next week, fuzzing the wife to get.. wait wrong blog.

2009
12.19

General purpose CPU register

I just needed to type this somewhere so I don’t forget. Maybe by putting it here, it will be of some use to others.

A CPU uses 8 general purpose registers: EAX, EDX, ECX, ESI, EDI, EBP, ESP and EBX.
Each register is design for a particular purpose, and each performs a function that enables the CPU to efficiently process information.

The EAX register, is used to perform calculations as well as storing return values from function calls. Basic operations ilke add, subtract, and compare are optimized to use the EAX register. More specialized operations like multiplication and dvision can occur only within the EAX register.

The EDX is the data register. It’s basically an extension of EAX to assist it in storing extra data for complex operations. It can also be used for general purpose data storage.

The ECX, also called the count register, is used for looping operations. The repeated operations could be storing a string or counting numbers.

The ESI and EDI relied upon by loops that process data. The ESI register is the source index for data operation and holds the location of the input data stream. The EDI points to the location where the result of data operation is stored, or the destination index.

ESP is the stack pointer, and EBP is the base pointer. These registers are used for managing function calls and stack operations. When a function is called, the function’s arguments are pushed on the stack and are followed by a return address. The ESP register points to the very top of the stack, so it will point to the return address. EBP is used to point to the bottom of the call stack.

EBX is the only register that was not designed for anything specific. It can be used for extra storage.

EIP is the register that points to the current instruction being executed. As the CPU moves through the binary executing code, EIP is updated to reflect the location where the execution is occuring.

2009
12.11

Looking at EggHunters…

Buffer overflows can be a daunting part of exploitation, almost esoteric in nature if you don’t have an idea of what’s going on in the back ground. A little while ago I posted an exercise for Easy Chat Server with a proof of concept. If you successfully accomplished the task, you may like this little entry: Egghunters.

An egghunter is a bit of code that, once executed, will search the memory for a specific string called “the egg”. Once it’s found the egg, your shellcode is then executed. Well so far it doesn’t seem to complicated does it?

So why would you want this solution to exploit a buffer overflow vulnerability? Well, once you’ve overwritten EIP and jump to your buffer where the shellcode would go. What would happen if you only had about 50 bytes of usable space? This would be a nice example of when an egghunter would be used.

The egghunter itself is about 32 bytes, the egg is 4 bytes (times 2) and then you have your shellcode. When you send your “evil buffer”, the egghunter is placed in the part of memory you overwrite. The shellcode is stuffed somewhere else, its location unknown to us. Once EIP is pointed to your buffer space, the hunter is executed and then searches the memory for your shellcode. To put it roughly, it would look like this: offset + egghunter + egg + shellcode.
As long as the egghunter fits the buffer space EIP is sending you, you’re in business.

Here’s a nice example of code using the egghunter method. It was coded by Dr_IDE (an OSCP graduate) and dookie2000ca (star quarter-back for the Edmonton Roughriders back in ’86). It’s well coded and very easy to read.
Eureka Mail BoF SEH

So let’s try and break down the above exploit shall we?
First we have the egghunter. Notice the commented part “This is the egg: w00t”
egghunter = (“\x66\x81\xCA\xFF\x0F\x42\x52\x6A\x02\x58\xCD\x2E\x3C\x05\x5A\x74\xEF\xB8″
“\x77\x30\x30\x74″ # this is the egg: w00t
“\x8B\xFA\xAF\x75\xEA\xAF\x75\xE7\xFF\xE7″)

The hunter is setup to look for the string “w00t” in memory. It loops though and compares the value to “\x77\x30\x30\x74″. It will loop until it finds the egg, break out of the loop and execute the shellcode found directly after it.

The next few parts of the file is pretty standard stuff. Return address, short jumps and nop slide… Won’t go into that, but let me direct your attention to the last part. Where the buffer is built:
sploit = (“-ERR ” + buff + retn + egghunter + nops + junk + “w00tw00t” + bindshell);
As you can see, we have our egg there. The hunter will look for 2 instances of the string “w00t” in a row, and execute the code following it.

There is one down side to using the egghunter method. It’s CPU intensive. Once the egghunter is execute it will go through the roof, and reach 100%. On the other hand, you’ll be able to send almost any sized payload.
Here’s a very interesting video showing an egghunter. It’s from Offensive-Security’s video vault.
HP NNM from Bug to 0day

I’ll try and post a video on kioptix.com showing the egghunter in action. The above video is very clear in explaining, but the video quality can be lacking at times (but not very).

EDIT:
skape’s original paper on egghunters
Link to a video of an Egghunter in action here

2009
12.08

HackUS 2010 CTF Event

HackUS First Edition, is a capture the flag event being held in Sherbrooke Quebec in April of 2010. The event will last a full 48 hours which is guaranteed to keep you from actually doing any sleep.
More details can be found on there website: HackUS

Also, here are a few of the prizes made available thanks to Offensive-Security’s generosity:
PWB w/ 60 day lab access
CTP w/ 60 day lab access
Now that’s what I called an incentive to participate.
Registration is only 110$ CAD and includes meals and accommodations, with transportation from the hotel to the event site. It’s 50$ CAD if you don’t want a hotel room (or plan on not sleeping).


I had the pleasure of e-mailing one of the organizers. Must say, very nice and he’s obviously
into Information Security. The Sherbrooke team came in second place at the
Hackfest.ca CTF event this past November. Just one point shy of the UQAM team. I’m sure you guys will get your revenge in April.

So if any of you are near the Quebec boarder, I highly recommend this. Check out their site and hope to see you there.

I’ll be participating, but will only send in my registration fees after Christmas… bills bills bills

2009
12.05

OSCP vs PTF

I recently completed 2 security related certifications. The first is Offensive-security’s “OSCP” (Pentesting With Backtrack) and the other is Heorot’s PTF (Pentesting Fundamentals).

Here is where you can find more information on both certifications:
Pentesting Fundamentals: Heorot
OSCP : Offsec

The point of this blog is not to “bash” or “flame” one certification. Both are challenging and interesting in their own way. It’s just that, depending on how you look at it, one is more advanced then the other. Seeing that difficulty is very relative to each individual person, if I refer one as being more “difficult” keep in mind it’s my opinion.

Let’s start off by describing each training course, let’s talk about Heorot’s PTF.
Once a student starts the course, he receives an e-mail with links and access codes to the online training material. This is comprised of videos, slides and documents. Also, 2 live CD images are needed for the course. The first CD is the first De-ICE live CD used during the course itself. The second is the vulnerable system which is your target to complete the course. You get to run a mock pentest on this system following the methodology (based on the ISSAF) learned in the course. Once you’ve finished, you write up your report as explained in the ISSAF and send it on it’s way for review/grading.

Offensive-Security’s PWB takes a different approach. Once the course starts (classes start on a saturday), the student gets an e-mail with access to the course material (video and PDF) and access to an online lab. Through out the course, the student gets to follow the teacher and practice on live hosts (in secure and legal environment). Students get the chance to run scans, exploits and other techniques on various operating systems. Once all the exercises completed, an exam is scheduled. Upon completion of the exam, the fail or pass e-mail is sent within 72 hours.

So in a nutshell, they are both courses that teach you about penetration testing. One is more documentation/methodology driven, and the other has a more “hands on” approach.
So which is better ?
Which one should you take ?
Which one should you take first ?
Which one is harder/easier ?
Which one is worth it ?

Well.. The answer to all those questions really depend on one’s personal skill level and experience. When I started OSCP, I had no prior experience with exploits/metasploit and other info-sec related activities. I did however have a pretty good knowledge of the Linux operating system, networking and programming. Even with all that, I found the course extremely challenging if not out of my league at times. Still with some effort and research, I still managed to pass the 24 hour exam and receive my certification.

After doing all that, I waited a few months and tried my hand with Heorot’s fundamentals course. Being a fundamentals course, and documentation/methodology driven, the penetration and exploitation of the target system was easy in comparison to OSCP. The goal in PTF is not to see if you can “pop a box”, but properly produce a penetration report following certain guidelines.

As you can see, depending on what you already know (or don’t know) both certifications can have a strong learning curve. For me, well PTF was a bit of a disappointment seeing the cost and time it’s taking to grade my report.
[as of today it’s been over a week and still no news]

So for the cost, in my opinion, if you already have experience with vulnerability scanners, frameworks such as Metasploit / w3af etc, go for OSCP. Once you’ve done that, nothing stops you from downloading the ISSAF methodology documentation free from their website. If you don’t have any prior experience, then PTF would be a good place to start. You get to learn the basic tools, such as nmap & hydra, and properly conduct a pentest from A to Z.

The answers to all my previous questions above all comes down to this:
It depends on you….

Thanks for reading.