Meta

References

Getting Started with Network Fuzzers

SPIKE

Notes about SPIKE

SPIKE is notoriously hard to compile and get working, so if you had to change something to make it work on your computer, post your instructions to the mailing list so everyone else can benefit.

Instructions for OSX

  • In the makefile, remove:
    • ld -share -soname libdlrpc.so -o libdlrpc.o -lc dlrpc.o dlargs.o $(SPIKE_OBS)
  • In the makefile, add:
    • ld -dynamic -flat_namespace -bundle -undefined suppress -o libdlrpc.so -lc -ldl dlrpc.o dlargs.o $(SPIKE_OBS)
  • Change LD_LIBRARY_PATH to DYLD_LIBRARY_PATH
  • Comment out -ldlrpc

Cygwin

Don't even try using SPIKE on Cygwin. If you somehow get it working, it's because you made considerable patches to SPIKE source files/build scripts which you should submit to me for extra credit.

If you insist using Windows/Cygwin, try Peach or Sulley as they are both written in Python and better supported on Windows.

Reading Material

Sulley

Archive

Note that fuzzing is no longer taught as part of this class. This topic has been moved to an application security class instead. The rationale is that fuzzing is better at identifying mass quantities of vulnerabilities rather than the one vulnerability that you want to exploit.

Fall 2010

The homework was to download a copy of AxMan and answer the following questions about it. Don't get lost in the binary portion of AxMan. This is a simple helper library that is not core to the fuzzer. The majority of the fuzzer is implemented in the other files delivered with the tool.

  1. Specifically, what is the target of the fuzzer?
  2. What input vectors are being tested? Are there any other input vectors that AxMan may have missed? Why or why not?
  3. How is fuzzing data generated? Are there boundary conditions that are being tested for? What are they and why were they chosen?
  4. How is fuzz data delivered to the target?
  5. What is the process for monitoring for exceptions?
  6. How would you determine the exploitability of the fuzz test results from AxMan?
  7. Find at least one example of a vulnerability that was previously identified with AxMan. 

Fall 2009

The assignment for the Fuzzing 101 section was the following:

  1. Locate a stack overflow in an ActiveX control by fuzzing it.
    Choose your target machine carefully. If you run a clean and patched Windows box, you might have a harder time finding something exploitable. See if you can run your tools on someone else's machine - preferably a machine with a lot of garbage software installed on it. COMRaider will more easily find the low-hanging fruit - the basic stack smash - and you should probably run this tool first. If you find nothing, run other fuzzers like Dranzer, AxRub, or AxMan.
  2. Determine the exploitability of the overflow by investigating the stack with a debugger.
    COMraider will show you debugger output in its own GUI. Double clicking on the exceptions will show a stack dump. AxMan will require use of an external debugger of your choosing. You get extra points if you use WinDBG and run the !exploitable plugin.
  3. Reproduce the successful fuzz in a "Proof of Concept" that overwrites EIP with all A's.
    Even though COMraider might show EIP over written, we still want to see a stand-alone script that demonstrates the vulnerability in a web browser. Additionally, you should identify the vulnerable DLL on the machine and grab a copy of it. This will be important if you are not testing on your own machine - you will want to take the DLL with you for further testing. For more information on registering DLLs on a Windows box, check out the Regsvr32 documentation.

What to hand in: One DLL, a PoC that crashes the DLL, a screenshot of the crash in a debugger.

If you want a simple walkthrough before starting the assignment or if you've tried the assignment and can't find a vulnerable ActiveX, you can register the ActiveX included in this zip file which I guarantee is loaded with exploitable vulnerabilities. To make things simple, just register it and then point COMRaider directly at it. The vulnerable function is foobar() and pretty much anything it accepts will generate a stack overflow. If you don't see "ACCESS VIOLATION", you're doing something wrong. If you see error messages saying "Cannot Create Object", you have not registered the DLL correctly.

If you're still having problems finding an ActiveX to fuzz, try some of these:

Reading material about ActiveX:

The assignment for the Fuzzing 102 section was the following:

This week you will be writing your own fuzz module for any one of three general-purpose network fuzzers (SPIKE, Sulley installer or SVN, or Peach) to identify vulnerabilities in a custom network service. The network service requires a Java runtime (Java 6 tested) and starts a listener on a specified port. If the service appears to halt, try pressing CTRL+C in its command window to get it going again. It's a bit unstable, sorry about that!

Protocol Spec:

Authentication

  • USER <username>\r\n

Commands

  • ls\r\n (no arguments)
  • whoami (no arguments)
  • cat <filename>\r\n

What to hand in: a fuzz module for the network service written using either SPIKE, Sulley, or Peach and documentation of any of the vulnerabilities you uncovered.

HINT: There are only 3 distinct vulnerabilities in the network service. I will grade this assignment more on whether it looks like you learned something and less on the completeness of your assessment of the vulnerabilities, IMHO it's very hard to find all 3.

Fall 2008