User Tools
session:extra:fuzzing
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
session:extra:fuzzing [2017/07/20 12:11] Lucian Mogosanu [Intro] |
session:extra:fuzzing [2020/07/19 12:49] (current) |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== 0x0C. Fuzzing ====== | ====== 0x0C. Fuzzing ====== | ||
| - | == Slides | + | ===== Slides |
| - | Slides are available {{:session:session_12.pdf|here}}. | + | Slides are available {{:session:s12-slides-fuzzing.pdf|here}}. |
| - | == Tutorials | + | ===== Tutorials |
| - | === Introduction | + | ==== Introduction |
| Fuzzing is a technique for testing certain kinds of software by feeding the target with thousands of random generated inputs. From now on, **the target** is the software program that we test using the fuzzer. Fuzzing is used by companies to test their internal developed software, or by security companies to analyze interesting pieces of software(delivered as binaries). | Fuzzing is a technique for testing certain kinds of software by feeding the target with thousands of random generated inputs. From now on, **the target** is the software program that we test using the fuzzer. Fuzzing is used by companies to test their internal developed software, or by security companies to analyze interesting pieces of software(delivered as binaries). | ||
| Line 12: | Line 12: | ||
| Fuzzers are divided into two main categories based on the target form as **source code** or **binary file**. Fuzzers that work with “source code”, can use compiler features to instrument the binary code with coverage handlers and sanitizers, thus the fuzzer can use information from the target itself. The second class of fuzzers, that work with binary files, must run each instruction in an environment that allows the fuzzer to collect execution feedback data. In the following tutorial, we will consider only the latter class. | Fuzzers are divided into two main categories based on the target form as **source code** or **binary file**. Fuzzers that work with “source code”, can use compiler features to instrument the binary code with coverage handlers and sanitizers, thus the fuzzer can use information from the target itself. The second class of fuzzers, that work with binary files, must run each instruction in an environment that allows the fuzzer to collect execution feedback data. In the following tutorial, we will consider only the latter class. | ||
| - | === Basic Blocks | + | ==== Basic Blocks |
| In order to understand what fuzzers try to achieve, we must understand the flow graph of a program. The **flow graph** is the target program layout representing all the paths that can be traversed during program execution. Its representation corresponds to a graph where the nodes correspond to basic blocks. The direct edge between two basic blocks represent that there is a jump instruction after the first block that directs the execution to the second basic block. The first basic block, called also the **entry block** is the first block to be executed. | In order to understand what fuzzers try to achieve, we must understand the flow graph of a program. The **flow graph** is the target program layout representing all the paths that can be traversed during program execution. Its representation corresponds to a graph where the nodes correspond to basic blocks. The direct edge between two basic blocks represent that there is a jump instruction after the first block that directs the execution to the second basic block. The first basic block, called also the **entry block** is the first block to be executed. | ||
| Line 68: | Line 68: | ||
| * syscall/ | * syscall/ | ||
| - | === How do fuzzers work | + | ==== How do fuzzers work ==== |
| Briefly, a fuzzer is a program the generates input randomly and feeds the input to the target program. The target program is a x86/x86_64 binary. Now we will understand how the input is generated, how does the target program receive the input and most important, what is execution feedback and how the fuzzer makes use of it. | Briefly, a fuzzer is a program the generates input randomly and feeds the input to the target program. The target program is a x86/x86_64 binary. Now we will understand how the input is generated, how does the target program receive the input and most important, what is execution feedback and how the fuzzer makes use of it. | ||
| Line 131: | Line 131: | ||
| An input is **interesting** if the execution of target program with the aforementioned input will **exercise** one or more basic blocks that were not previously exercised by any other input. **Coverage-based fuzzers** rely more on increasing the number of basic blocks discovered, than on discovering a certain issue in an isolated area of the code. | An input is **interesting** if the execution of target program with the aforementioned input will **exercise** one or more basic blocks that were not previously exercised by any other input. **Coverage-based fuzzers** rely more on increasing the number of basic blocks discovered, than on discovering a certain issue in an isolated area of the code. | ||
| - | === Fuzzing with a view | + | ==== Fuzzing with a view ==== |
| {{: | {{: | ||
| Line 149: | Line 149: | ||
| </ | </ | ||
| - | === Driller - augmenting fuzzing with symbolic execution | + | ==== Driller - augmenting fuzzing with symbolic execution |
| Driller is a software verification system for detecting vulnerabilities in small binaries. Driller is built on top of [[http:// | Driller is a software verification system for detecting vulnerabilities in small binaries. Driller is built on top of [[http:// | ||
| Line 178: | Line 178: | ||
| angr is the concolic execution engine integrated in driller. Now that we have an idea about how it works, let’s see some blood. | angr is the concolic execution engine integrated in driller. Now that we have an idea about how it works, let’s see some blood. | ||
| - | === Installing Driller | + | ==== Installing Driller |
| + | |||
| + | <note important> | ||
| + | You can skip this part of the tutorial if you're using the [[https:// | ||
| + | </ | ||
| Driller is a pretty complex framework comprising a bunch of components: a fuzzer (AFL), a symbolic execution engine (angr) and some scaffolding to use the two together. If you're running the lab VMs, they will most likely come with Driller preinstalled. Otherwise, follow the steps here to (hopefully) get it up and running. | Driller is a pretty complex framework comprising a bunch of components: a fuzzer (AFL), a symbolic execution engine (angr) and some scaffolding to use the two together. If you're running the lab VMs, they will most likely come with Driller preinstalled. Otherwise, follow the steps here to (hopefully) get it up and running. | ||
| Line 243: | Line 247: | ||
| Now we should be all done! If the first task works for you, then you should be all set. | Now we should be all done! If the first task works for you, then you should be all set. | ||
| - | == Tasks | + | ===== Tasks ===== |
| - | === Intro | + | The archive can be downloaded from {{: |
| + | |||
| + | <note important> | ||
| + | To run Driller scripts in the Ubuntu 64bit VM, make sure that you're in the '' | ||
| + | |||
| + | < | ||
| + | $ workon driller | ||
| + | (driller) $ | ||
| + | </ | ||
| + | </ | ||
| + | ==== Task 1: Intro ==== | ||
| The first task can be found in '' | The first task can be found in '' | ||
| <code bash> | <code bash> | ||
| Line 263: | Line 277: | ||
| </ | </ | ||
| - | The first parameter passed to driller is the **binary path**. The second parameter is a reference input (it should be long enough to crash the program). The third parameter is the bitmap with no discovered transitions. | + | The first parameter passed to driller is the **binary path**. The second parameter is a **reference input** (it should be long enough to crash the program). The third parameter is the fuzzer |
| Run the above code. The result contains a set of inputs discovered by driller. We can see that all inputs start with " | Run the above code. The result contains a set of inputs discovered by driller. We can see that all inputs start with " | ||
| < | < | ||
| Line 272: | Line 286: | ||
| | | ||
| </ | </ | ||
| - | At address '' | + | At address '' |
| - | === Objdump or Driller? Which one is better? | + | <note important> |
| + | Now feed the driller input to '' | ||
| + | <code bash> | ||
| + | cat input | ./fst | ||
| + | </ | ||
| + | </ | ||
| + | |||
| + | ==== Task 2: Objdump or Driller? Which one is better? | ||
| The second task executable can be found in '' | The second task executable can be found in '' | ||
| Line 284: | Line 305: | ||
| - | === Codegate - postbox | + | ==== Task 3: Codegate - postbox |
| The executable can be found in '' | The executable can be found in '' | ||
| Line 294: | Line 315: | ||
| </ | </ | ||
| - | Analyze the binary using '' | + | Analyze the binary using '' |
| Open script file '' | Open script file '' | ||
| Line 303: | Line 324: | ||
| $ dmesg | tail | $ dmesg | tail | ||
| </ | </ | ||
| + | |||
| + | |||
session/extra/fuzzing.1500541907.txt.gz · Last modified: 2017/07/20 12:11 by Lucian Mogosanu
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
