Security Summer School

User Tools

Site Tools

session:extra:stateless-fuzzing

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision 		Previous revision
session:extra:stateless-fuzzing [2014/07/14 10:39]
drcomaneci [Sulley Data Model] 		session:extra:stateless-fuzzing [2020/07/19 12:49] (current)
Line 1: Line 1:
-= Session 07 +====== 0x07. Stateless Fuzzing ======
-====== Stateless Fuzzing ======+
  
-== Slides+===== Slides =====
  
-<note warning> +The slides can be found {{:session:sess-07.pdf|here}}.
-TODO +
-</note>+
  
-== Tutorials  +===== Tutorials  =====
- +
-<note warning> +
-Under Development +
-</note>+
  
 //"To fuzz or not to fuzz ?"// //"To fuzz or not to fuzz ?"//
Line 40: Line 33:
   * Generation-based fuzzers where you contruct the data from the ground up based on its specific structure   * Generation-based fuzzers where you contruct the data from the ground up based on its specific structure
  
-<note> +When generating fuzzing data, we're trying to pick interesting values for the fields being fuzzed. Eg.  
-TODO: Patterns when generating data + * Integers  
-</note>+   * Negative numbers (0xFFFFFFFF, 0x80000000, etc.) 
 +   * Large numbers (0x7FFFFFFF, 0x20000000, etc.) 
 +   * Small values such as 0-10 
 +   * Header values identifying the length of header/data segments 
 + * ASCII 
 +   * Large strings / empty strings 
 +   * Strings with "inaccurate" length tags 
 +     * Long string, short tag 
 +     * Short string, long tag 
 +   * Strings with "accurate" but long length tags 
 +   * Strings with format specifiers
  
 Following this, the generated fuzz data is **executed against the target application** and we **monitor succesively for exceptions**. After each fuzz test, the application is killed and restored to its initial state. Following this, the generated fuzz data is **executed against the target application** and we **monitor succesively for exceptions**. After each fuzz test, the application is killed and restored to its initial state.
 Once a crash/hang has been found, we proceed to **determine whether the vulnerability is exploitable**.   Once a crash/hang has been found, we proceed to **determine whether the vulnerability is exploitable**.  
  
-=== Stateless vs. Stateful Fuzzing+==== Stateless vs. Stateful Fuzzing ====
 We've hinted a bit in the preceding section about restoring the application to its initial state after each fuzz test is run. This can be as simple as just restarting the application in the case of **stateless fuzzing** where we have a fixed state from which we're trying to fuzz to performing the necessary operations to get the application into a specific state before performing the fuzz test in the case of **stateful fuzzing**.  We've hinted a bit in the preceding section about restoring the application to its initial state after each fuzz test is run. This can be as simple as just restarting the application in the case of **stateless fuzzing** where we have a fixed state from which we're trying to fuzz to performing the necessary operations to get the application into a specific state before performing the fuzz test in the case of **stateful fuzzing**. 
 In this session we'll be covering only stateless fuzzing but we will also go into stateful fuzzing in the next session which will build on the knowledge gained in this one.  In this session we'll be covering only stateless fuzzing but we will also go into stateful fuzzing in the next session which will build on the knowledge gained in this one. 
-=== Fuzzing Frameworks+==== Fuzzing Frameworks ====
 A fuzzing framework is mostly concerned with generating the fuzzing data, but it can also serve the following aditional functions: A fuzzing framework is mostly concerned with generating the fuzzing data, but it can also serve the following aditional functions:
  * Orchestrate running the program against the generated test data and see whether it crashed  * Orchestrate running the program against the generated test data and see whether it crashed
Line 58: Line 61:
  
 Most fuzzing frameworks are designed only for the data generation stage, leaving the test execution to the user. For this particular lab we will be using the Sulley Fuzzing Framework which, as we'll see, covers all of the above functionality.  Most fuzzing frameworks are designed only for the data generation stage, leaving the test execution to the user. For this particular lab we will be using the Sulley Fuzzing Framework which, as we'll see, covers all of the above functionality. 
-=== The Sulley Fuzzing Framework+==== The Sulley Fuzzing Framework ====
 {{ https://camo.githubusercontent.com/09d3c5c19cbe0d8e1b5048afef31e2fe46fc4941/687474703a2f2f692e696d6775722e636f6d2f41487542752e6a7067?&.jpg?500 |}} {{ https://camo.githubusercontent.com/09d3c5c19cbe0d8e1b5048afef31e2fe46fc4941/687474703a2f2f692e696d6775722e636f6d2f41487542752e6a7067?&.jpg?500 |}}
  
Line 67: Line 70:
  * Session: Link your developed requests together to form a session, attach the various available Sulley monitoring agents (network, debugger, etc...) and commence fuzzing.  * Session: Link your developed requests together to form a session, attach the various available Sulley monitoring agents (network, debugger, etc...) and commence fuzzing.
  * Post Mortem: Review the generated data and monitored results. Replay individual test cases.  * Post Mortem: Review the generated data and monitored results. Replay individual test cases.
-=== Setting up Sulley+==== Setting up Sulley ====
 The first step in installing Sulley is to clone the Github repository for it:  The first step in installing Sulley is to clone the Github repository for it: 
 <code bash> <code bash>
Line 112: Line 115:
     [-l|--log_level LEVEL]       log level (default 1), increase for more verbosity     [-l|--log_level LEVEL]       log level (default 1), increase for more verbosity
 </code> </code>
-=== Running a fuzz scenario with Sulley+==== Running a fuzz scenario with Sulley ====
 Without going into all the details in the [[http://www.fuzzing.org/wp-content/SulleyManual.pdf|user manual]], there are some basics that we need to know. When fuzzing with Sulley, we need to write a python script that defines all required objects that Sulley needs in order to fuzz specific target. Those objects are: Without going into all the details in the [[http://www.fuzzing.org/wp-content/SulleyManual.pdf|user manual]], there are some basics that we need to know. When fuzzing with Sulley, we need to write a python script that defines all required objects that Sulley needs in order to fuzz specific target. Those objects are:
  
Line 121: Line 124:
   - **Monitoring Interface**: monitoring interface allows us to easily see the result of fuzzing process, how many of the test cases were already sent, how many of them caused a crash, etc.   - **Monitoring Interface**: monitoring interface allows us to easily see the result of fuzzing process, how many of the test cases were already sent, how many of them caused a crash, etc.
  
-==== Concrete Example+=== Concrete Example ===
 Let's start by considering a concrete fuzzing example. Consider we have a network service listening on port 9999 and it supports the following commands : Let's start by considering a concrete fuzzing example. Consider we have a network service listening on port 9999 and it supports the following commands :
 <code bash> <code bash>
Line 148: Line 151:
 </code> </code>
  
-==== Protocol Fuzzer +=== Protocol Fuzzer  ===
 The fuzzer for it would look as follows (sulley/vulnserver.py): The fuzzer for it would look as follows (sulley/vulnserver.py):
 <code python> <code python>
Line 256: Line 259:
 s.fuzz() s.fuzz()
 </code> </code>
-==== Starting the Network and Process Monitor+=== Starting the Network and Process Monitor ===
 <code bash> <code bash>
 mkdir auditsvulnserver mkdir auditsvulnserver
Line 265: Line 268:
 In case you have any issues with the network_monitor.py script exiting while trying to capture the first fuzz test, please modify the call to pcapy.open_live so that it takes 4096 and True as the second and third parameters.  In case you have any issues with the network_monitor.py script exiting while trying to capture the first fuzz test, please modify the call to pcapy.open_live so that it takes 4096 and True as the second and third parameters. 
 </note> </note>
-==== Starting the fuzzing process+=== Starting the fuzzing process ===
 <code bash> <code bash>
 python vulnserver.py python vulnserver.py
 </code> </code>
 <note> <note>
-The **examples** folder contains a few other relevant Sulley scripts that demo de framework's functionality. +The **examples** folder contains a few other relevant Sulley scripts that demo the framework functionality. 
 </note> </note>
  
-=== Sulley Data Model+==== Sulley Data Model ====
 Now that we've had our first taste of how a fuzzer can be defined using Sulley, let's take a closer look at the options available for defining the data model and what they can do.  Now that we've had our first taste of how a fuzzer can be defined using Sulley, let's take a closer look at the options available for defining the data model and what they can do. 
  
-==== Defining a new request+=== Defining a new request ===
 <code python> <code python>
 s_initialize("new request") s_initialize("new request")
 </code> </code>
-==== Static and Random Primitives+=== Static and Random Primitives ===
 Static primitives are never mutated.  Static primitives are never mutated. 
 <code python> <code python>
Line 298: Line 301:
 s_random(min_length, max_length, num_mutations, fuzzable, name) s_random(min_length, max_length, num_mutations, fuzzable, name)
 </code> </code>
-==== Integers+=== Integers ===
  * 1 byte: s_byte(), s_char()  * 1 byte: s_byte(), s_char()
  * 2 bytes: s_word(), s_short()  * 2 bytes: s_word(), s_short()
Line 304: Line 307:
  * 8 bytes: s_qword(), s_double()  * 8 bytes: s_qword(), s_double()
  
-==== Strings and Delimiters+=== Strings and Delimiters ===
 <code python> <code python>
 # fuzzes the string: <BODY bgcolor="black"> # fuzzes the string: <BODY bgcolor="black">
Line 318: Line 321:
 </code> </code>
  
-==== Blocks & Groups+=== Blocks & Groups ===
  
 <code python> <code python>
Line 347: Line 350:
 </code> </code>
  
-==== Dependencies+=== Dependencies ===
 <code python> <code python>
 s_short("opcode", full_range=True) s_short("opcode", full_range=True)
Line 374: Line 377:
 </code> </code>
  
-==== Block Helpers+=== Block Helpers ===
 <code python> <code python>
 # table entry: [type][len][string][checksum] # table entry: [type][len][string][checksum]
Line 399: Line 402:
 You can find more information about these primitives in the [[http://www.fuzzing.org/wp-content/SulleyManual.pdf|Sulley Manual]] You can find more information about these primitives in the [[http://www.fuzzing.org/wp-content/SulleyManual.pdf|Sulley Manual]]
 </note> </note>
-== File Format Fuzzing+===== File Format Fuzzing =====
 A File format is quite similar to a protocol meaning that it can be treated as a standardized means of communication. As such, applications should be able to deal with anomalies in the files they are parsing by implementing: A File format is quite similar to a protocol meaning that it can be treated as a standardized means of communication. As such, applications should be able to deal with anomalies in the files they are parsing by implementing:
  * input validation controls  * input validation controls
Line 412: Line 415:
  
 As always, we can have the same two approaches when generating files for fuzzing, meaning mutation-based fuzzers (notSPIKEfile) and generation-based fuzzers (SPIKEfile). As always, we can have the same two approaches when generating files for fuzzing, meaning mutation-based fuzzers (notSPIKEfile) and generation-based fuzzers (SPIKEfile).
-=== SPIKEfile+==== SPIKEfile ====
 SPIKEfile is a Linux generation-based file fuzzer based on SPIKE. Fuzzers may be defined for it with the same SPIKE script block based notation as we've seen with Sulley.  SPIKEfile is a Linux generation-based file fuzzer based on SPIKE. Fuzzers may be defined for it with the same SPIKE script block based notation as we've seen with Sulley. 
-==== Installing SPIKEfile+=== Installing SPIKEfile ===
 <code bash> <code bash>
 wget http://www.fuzzing.org/wp-content/SPIKEfile.tgz wget http://www.fuzzing.org/wp-content/SPIKEfile.tgz
Line 423: Line 426:
 <note> <note>
 In case you run into any problems with compiling SPIKEfile, please use the following {{:session:spike_makefile.tgz|Makefile}} instead of the default one it comes with. Also, you may encounter the same problem with libdisasm as described below with notSPIKEfile.  In case you run into any problems with compiling SPIKEfile, please use the following {{:session:spike_makefile.tgz|Makefile}} instead of the default one it comes with. Also, you may encounter the same problem with libdisasm as described below with notSPIKEfile. 
 +Aslo, modify the FLAGS option:
 +<code>FLAGS   = $(INCLUDE) -m32  -O3 -ggdb </code>
 +
 +Modify the SPIKEfile Makefile:
 +<code>
 +CFLAGS=-L$(LIBDISASM) -L. -m32
 +$(LD) -shared -melf_i386 -soname libdlrpc.so -o libdlrpc.so $(OBJ)
 +</code>
 +
 </note> </note>
  
-==== Running SPIKEfile+=== Running SPIKEfile ===
 <code bash> <code bash>
 export LD_LIBRARY_PATH=path/to/libdisasm:path/to/libdlrpc export LD_LIBRARY_PATH=path/to/libdisasm:path/to/libdlrpc
Line 449: Line 461:
  ./SPIKEfile -t 3 -f fuzz.gif gif89a.spk 0 0 "/usr/X11R6/bin/display -debug %FILENAME%"  ./SPIKEfile -t 3 -f fuzz.gif gif89a.spk 0 0 "/usr/X11R6/bin/display -debug %FILENAME%"
 </code> </code>
-==== Example SPIKEfile .spk script+=== Example SPIKEfile .spk script ===
 <code> <code>
 s_blocksize_string("fileformat", 4); s_blocksize_string("fileformat", 4);
Line 460: Line 472:
 Other SPK script options may be found by inspecting the **spike.c** source file. You'll have to use the source Luke for this one.  Other SPK script options may be found by inspecting the **spike.c** source file. You'll have to use the source Luke for this one. 
 </note> </note>
-=== notSPIKEfile+==== notSPIKEfile ====
 notSPIKEfile is a Linux based file format fuzzing tool. It was designed to automate the execution and launching of applications and detection of exceptions caused by fuzzed file formats. It's a mutation based fuzzing tool meaning that starting from a valid input file it will attempt and modify the file byte by byte (or some other pattern) in order to produce test cases.  notSPIKEfile is a Linux based file format fuzzing tool. It was designed to automate the execution and launching of applications and detection of exceptions caused by fuzzed file formats. It's a mutation based fuzzing tool meaning that starting from a valid input file it will attempt and modify the file byte by byte (or some other pattern) in order to produce test cases. 
-==== Installing and Compiling notSPIKEfile+=== Installing and Compiling notSPIKEfile ===
 <code bash> <code bash>
 wget http://www.fuzzing.org/wp-content/notSPIKEfile.tgz wget http://www.fuzzing.org/wp-content/notSPIKEfile.tgz
Line 471: Line 483:
 <note> <note>
 In case you run into any trouble with compiling libdisasm, please modify libdisasm/src/arch/i386/libdisasm/Makefile and change the order in which the -L. -ldisasm parameters are passed when compiling the quikdis and testdis targets.  In case you run into any trouble with compiling libdisasm, please modify libdisasm/src/arch/i386/libdisasm/Makefile and change the order in which the -L. -ldisasm parameters are passed when compiling the quikdis and testdis targets. 
 +Also, modify the following lines in the Makefile:
 +<code>
 +FLAGS   = $(INCLUDE) -m32  -O3 -ggdb
 +</code>
 +and remove quickdis from compiling.
 +
 +In the Makefile from noSPIKEfile also change the following: 
 +<code>
 +CFLAGS=-m32
 +</code>
 +and
 +<code>
 +all $(OBJ):
 +    $(CC) $(OBJ) $(CFLAGS) -o $(EXE) $(LIBS)
 +</code>
 +
 </note> </note>
-==== Running notSPIKEfile+=== Running notSPIKEfile ===
 <code bash> <code bash>
 export LD_LIBRARY_PATH=path/to/libdisasm/shared/library export LD_LIBRARY_PATH=path/to/libdisasm/shared/library
Line 511: Line 539:
  
 </code> </code>
-== Tasks+===== Tasks =====
  
-=== Manual Fuzzing+==== Manual Fuzzing ====
  
 Download the following archive containing a linux binary {{:session:server.tgz|}}. Unpack it and run the program to see what it does. Try to discover at least one vulnerability by sending manual input to it through the network socket it's listening on.  Download the following archive containing a linux binary {{:session:server.tgz|}}. Unpack it and run the program to see what it does. Try to discover at least one vulnerability by sending manual input to it through the network socket it's listening on. 
  
 <note tip> <note tip>
-Please bare in mind that when a new connection is made to the service, a new thread is spawned. Also, GDB knows how to intercept signals ;)+Please bare in mind that when a new connection is made to the service, a new process is forked. Also, GDB knows how to intercept signals ;)
 </note> </note>
  
-Once you've discovered something, go ahead and analyze the vulnerability with GDB to see if it's indeed exploitable.  +<note> 
-=== Automated Fuzzing +The goal of this task is to trigger a crash of the program. 
-Download the following binary <TODO> that listens for commands on port 8888 and attempt to fuzz it using Sulley. +</note>
  
-=== File Format Fuzzing+Once you've discovered something, go ahead and analyze the vulnerability with GDB to see if it's indeed exploitable. You don't need to create an exploit, just get an idea of how you could exploit it. 
 +==== Automated Fuzzing ==== 
 +Sync the following github repository: 
 +<code bash> 
 +git clone https://github.com/madmaze/HTCPCP.git 
 +</code> 
 +Compile the code by executing  
 +<code bash> 
 +./make.em 
 +</code>  
 + 
 +Explore the structure of the Hyper Text Cofee Pot Control Protocol (HTCPCP) in [[http://www.ietf.org/rfc/rfc2324.txt|RFC2324]] or in the source code provided. Create a Sulley fuzzer for the HTCPCP server implementation and commence fuzzing.  
 +<note tip> 
 +The HTCPCP server forks a new process initially upon starting. You may have to modify Sulley's process_monitor_unix.py script in order to take that into consideration.  
 +</note> 
 + 
 +==== File Format Fuzzing ==== 
 + 
 +Sync the following github repository: 
 +<code bash> 
 +git clone https://github.com/ejohnst/exiftags.git 
 +</code> 
 + 
 +and compile it: 
 + 
 +<code bash> 
 +make 
 +</code>
  
-Download the following binary <TO DO>. Try to understand what types of files it reads and writes and how they are structured. Fuzz it using notSPIKEfile in order to discover vulnerabilities.+The application reads in and parses JPEG exif tags from different camera vendors. The EXIF tag format is discussed [[http://www.media.mit.edu/pia/Research/deepview/exif.html|here]]. An example JPEG file containing EXIF tags can be found here: {{:session:dsc_0441.jpg?linkonly|}} 
 +Fuzz it using notSPIKEfile in order to discover vulnerabilities and, afterwards using SPIKEfile. Compare and contrast the two approaches and findings. 
  
-== References+===== References =====
  * [[https://github.com/OpenRCE/sulley|Sulley Github Repository]]  * [[https://github.com/OpenRCE/sulley|Sulley Github Repository]]
  * [[http://www.fuzzing.org/wp-content/SulleyManual.pdf| Sulley User Manual]]  * [[http://www.fuzzing.org/wp-content/SulleyManual.pdf| Sulley User Manual]]
  * [[http://www.fuzzing.org/| Fuzzing.org]]  * [[http://www.fuzzing.org/| Fuzzing.org]]
 + * [[http://sulley.readthedocs.org/en/latest/genindex.html| Sulley API Docs]]
session/extra/stateless-fuzzing.1405323571.txt.gz · Last modified: 2014/07/14 10:39 by drcomaneci

Page Tools

Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
CC Attribution-Share Alike 4.0 International Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki