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 [2015/07/06 19:10]
Razvan Deaconescu [Manual Fuzzing] 		session:extra:stateless-fuzzing [2020/07/19 12:49] (current)
Line 1: Line 1:
-= Session 07 +====== 0x07. Stateless Fuzzing ======
-====== Stateless Fuzzing ======+
  
-== Slides+===== Slides =====
  
 The slides can be found {{:session:sess-07.pdf|here}}. The slides can be found {{:session:sess-07.pdf|here}}.
  
-== Tutorials +===== Tutorials  =====
  
 //"To fuzz or not to fuzz ?"// //"To fuzz or not to fuzz ?"//
Line 51: Line 50:
 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 62: 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 71: 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 116: 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 125: 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 152: 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 260: 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 269: 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
Line 277: Line 276:
 </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 302: 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 308: 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 322: Line 321:
 </code> </code>
  
-==== Blocks & Groups+=== Blocks & Groups ===
  
 <code python> <code python>
Line 351: Line 350:
 </code> </code>
  
-==== Dependencies+=== Dependencies ===
 <code python> <code python>
 s_short("opcode", full_range=True) s_short("opcode", full_range=True)
Line 378: 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 403: 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 416: 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 427: 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 453: 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 464: 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 475: 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 515: 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. 
Line 530: Line 554:
  
 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. 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+==== Automated Fuzzing ====
 Sync the following github repository: Sync the following github repository:
 <code bash> <code bash>
Line 545: Line 569:
 </note> </note>
  
-=== File Format Fuzzing+==== File Format Fuzzing ====
  
 Sync the following github repository: Sync the following github repository:
Line 561: Line 585:
 Fuzz it using notSPIKEfile in order to discover vulnerabilities and, afterwards using SPIKEfile. Compare and contrast the two approaches and findings.  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]]  * [[http://sulley.readthedocs.org/en/latest/genindex.html| Sulley API Docs]]
session/extra/stateless-fuzzing.1436199010.txt.gz · Last modified: 2015/07/06 19:10 (external edit)

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