Security Summer School

User Tools

Site Tools

session:extra:stateful-fuzzing

Differences

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

Link to this comparison view

Next revision 		Previous revision
session:extra:stateful-fuzzing [2016/06/30 20:35]
Razvan Deaconescu created 		session:extra:stateful-fuzzing [2020/07/19 12:49] (current)
Line 1: Line 1:
-= 0x07b. Stateful Fuzzing+====== 0x07b. Stateful Fuzzing ======
  
-== Slides+===== Slides =====
  
 The slides ca be found over {{:session:sess-08.pdf|here}} The slides ca be found over {{:session:sess-08.pdf|here}}
-== Tutorials  +===== Tutorials  ===== 
-=== Stateful Fuzzing +==== Stateful Fuzzing  ====
 When doing stateful fuzzing, our protocol message requests aren't independent any more from one another and must be sent in a specific order so as to carry out the fuzzing process. This type of ordering leads to a natural representation of the state machine as a graph with message requests being represented as nodes and sequencing between messages as edges.  When doing stateful fuzzing, our protocol message requests aren't independent any more from one another and must be sent in a specific order so as to carry out the fuzzing process. This type of ordering leads to a natural representation of the state machine as a graph with message requests being represented as nodes and sequencing between messages as edges. 
 The fuzzer, in this case, will walk all the paths in the graph, incrementally sending the correct messages to reach a certain node. The fuzzing process is complete when all paths have been explored.  The fuzzer, in this case, will walk all the paths in the graph, incrementally sending the correct messages to reach a certain node. The fuzzing process is complete when all paths have been explored. 
-=== Sulley Recap & Review +==== Sulley Recap & Review  ====
 {{ :session:sulley-architecture.png?direct&800 |}} {{ :session:sulley-architecture.png?direct&800 |}}
 Let's recap a bit what we've learned about the Sulley Fuzzing Framework. A general overview of its architecture is given in the figure above.  Let's recap a bit what we've learned about the Sulley Fuzzing Framework. A general overview of its architecture is given in the figure above. 
Line 25: Line 25:
 In our previous lab we've been mainly focused on the data generation step and stateless fuzzing and left Sulley session management and the other components for this one.  In our previous lab we've been mainly focused on the data generation step and stateless fuzzing and left Sulley session management and the other components for this one. 
  
-=== Sulley Sessions+==== Sulley Sessions ====
 The major benefit of Sulley is the fact that is allows "deep" fuzzing within a protocol. This is accomplished by linking requests together in a graph (or session in Sulley parlance) as shown in the following figure depicting such a graph for SMTP.  The major benefit of Sulley is the fact that is allows "deep" fuzzing within a protocol. This is accomplished by linking requests together in a graph (or session in Sulley parlance) as shown in the following figure depicting such a graph for SMTP. 
  
Line 98: Line 98:
 {{ :session:sulley-callbacks.png?direct&700 |}} {{ :session:sulley-callbacks.png?direct&700 |}}
  
-=== Sulley Debugging Tips  +==== Sulley Debugging Tips  ==== 
-==== Sulley Process Monitor+=== Sulley Process Monitor ===
 In previous session on stateless fuzzing, we had problems with Sulley not restarting the process properly after it crashed.  In previous session on stateless fuzzing, we had problems with Sulley not restarting the process properly after it crashed. 
  
Line 105: Line 105:
 Also, the **stop_target** function must return **True** as well. By default it returns None which corresponds to False when used in an if statement.   Also, the **stop_target** function must return **True** as well. By default it returns None which corresponds to False when used in an if statement.  
  
-=== Parallel Fuzzing+==== Parallel Fuzzing ====
 Sulley is designed (but not fully implemented yet) to support parallel fuzzing by adding more targets. When more than one target is present, the fuzz tests are divided between all targets and are run in parallel. For each target, you will need a separate process monitor and network monitor to be instantiated. These can either be on the same machine (different ports) or on different machines.  Sulley is designed (but not fully implemented yet) to support parallel fuzzing by adding more targets. When more than one target is present, the fuzz tests are divided between all targets and are run in parallel. For each target, you will need a separate process monitor and network monitor to be instantiated. These can either be on the same machine (different ports) or on different machines. 
-== Tasks +===== Tasks ===== 
-=== DNS Server Fuzzing+==== DNS Server Fuzzing ====
 During the previous Stateless Fuzzing session we've fuzzed only text based protocols but Sulley can also be used for binary ones so this time we can have a go at DNS. You may start your fuzzing from the **examples/mdns.py** fuzzer found in Sulley. During the previous Stateless Fuzzing session we've fuzzed only text based protocols but Sulley can also be used for binary ones so this time we can have a go at DNS. You may start your fuzzing from the **examples/mdns.py** fuzzer found in Sulley.
  
Line 125: Line 125:
  
 MaraDNS is a tough nut to crack so, don't be disappointed if you won't find any crashes. The main challenge for this exercise is to orchestrate and automate the fuzzing for this real application.  MaraDNS is a tough nut to crack so, don't be disappointed if you won't find any crashes. The main challenge for this exercise is to orchestrate and automate the fuzzing for this real application. 
-=== FTP Server Fuzzing +==== FTP Server Fuzzing  ====
 Please sync the following Github repository which contains a simple FTP Server written in C, compile it, look over how it's configured and attempt to develop a stateful Sulley FTP fuzzer for it. A reference for the FTP state machine can be found in [[http://tools.ietf.org/html/rfc959|RFC959]] int the **6. STATE DIAGRAMS** section.  Please sync the following Github repository which contains a simple FTP Server written in C, compile it, look over how it's configured and attempt to develop a stateful Sulley FTP fuzzer for it. A reference for the FTP state machine can be found in [[http://tools.ietf.org/html/rfc959|RFC959]] int the **6. STATE DIAGRAMS** section. 
 <code bash> <code bash>
Line 138: Line 138:
 git clone https://github.com/jedisct1/pure-ftpd git clone https://github.com/jedisct1/pure-ftpd
 </code> </code>
-=== Fuzz your own application+==== Fuzz your own application ====
  
 This is a free-form exercise. You can select any application you want to fuzz and go build a fuzzer for it.  This is a free-form exercise. You can select any application you want to fuzz and go build a fuzzer for it. 
Line 163: Line 163:
    * etc...    * etc...
  
-== Resources+===== Resources =====
  * [[http://www.informatik.uni-bremen.de/uDrawGraph/en/download/download.html | uDraw]]  * [[http://www.informatik.uni-bremen.de/uDrawGraph/en/download/download.html | uDraw]]
  * [[https://github.com/OpenRCE/sulley|Sulley Github Repository]]  * [[https://github.com/OpenRCE/sulley|Sulley Github Repository]]
session/extra/stateful-fuzzing.1467308156.txt.gz · Last modified: 2016/06/30 20:35 by Razvan Deaconescu

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