FUZZING FOR BEGINNERS (KUGG teaches STÖK American fuzzy lop)

Summary

In this video, Stick teams up with Christopher, aka Cook, to delve into the basics of fuzzing using AFL (American Fuzzy Lop). Christopher explains the process of using AFL to find bugs in binary programs through automated testing. They discuss the importance of compiling programs with instrumentation, setting up the environment, and running AFL on an HTTP server. The video demonstrates how to identify and analyze crashes, offering insights into bug hunting and reporting. Additionally, they highlight the value of fuzzing for various parsers and the potential for exploiting vulnerabilities.

Takeaways

• 😀 Introduction to Fuzzing: The script introduces fuzzing as a method to find bugs in binary programs by sending numerous requests into a system.
• 🔧 AFL Tool Overview: AFL (American Fuzzy Lop) is highlighted as a fast testing tool used for fuzzing, which can automate the process of finding bugs.
• 🛠️ Compilation with AFL: The script explains how to compile a program using AFL by replacing the GCC with AFL-GCC and setting the CC environment variable.
• 🔬 Instrumentation: AFL's instrumentation feature allows for tracking the internal state of a program during execution, which is useful for identifying when specific code paths are reached.
• 🔄 Synchronization in Multi-core Systems: AFL can synchronize output across multiple cores or machines, which is beneficial for large-scale fuzzing operations.
• 📁 Output Directory Importance: The output directory in AFL is crucial for syncing results, storing crashes, and managing the fuzzing queue.
• 🚫 SSD Fuzzing Caution: The script advises against running fuzzing on SSDs due to the high volume of writes, suggesting the use of RAM-based storage like tmpfs instead.
• 🔄 Fuzzing Automation: AFL automatically mutates input data to discover new paths within the program, learning from each iteration.
• 🛑 Handling Crashes: The script discusses how to handle crashes found during fuzzing, using tools like gdb to analyze and understand the cause of the crash.
• 🔑 Security Implications: Fuzzing can reveal serious security vulnerabilities, such as privilege escalation and denial of service, which can be critical in systems running as root.
• 🔍 Debugging and Exploitation: The process of using gdb to debug a program post-crash is outlined, which is essential for creating proof-of-concept exploits.
• 🌐 Community and Resources: The script mentions the availability of web casts and the F-Secure Lab channel on YouTube as community resources for learning more about fuzzing.

Q & A

What is AFL and what does it stand for?

AFL stands for American Fuzzy Lop, but in the context of this script, it refers to a fast testing tool used for finding bugs in binary programs by sending a lot of requests into something.

How does fuzzing work in the context of AFL?

Fuzzing involves sending a lot of random inputs into a program to see how it behaves. AFL takes an original input and transforms it in each iteration, running thousands of iterations every second to test the program's response to various inputs.

What is the role of GCC in AFL?

GCC is a compiler used in Linux for compiling software. In AFL, you replace GCC with AF-GCC, which compiles the program with built-in instrumentation, allowing AFL to understand what's happening inside the program during execution.

What is instrumentation in the context of AFL?

Instrumentation in AFL refers to the process of modifying the code being built so that every time the program reaches a certain state, it is registered by the instrumentation. This helps AFL understand the program's internal workings and behavior.

Why is it recommended to not run AFL on SSD drives?

SSD drives are not always ready to handle the high volume of writes that AFL generates, which can be harmful and wear them out quickly. Instead, using tmpfs, which is a temporary file storage in RAM, is recommended for the output directory to avoid excessive writes to SSD.

What does the output directory in AFL contain?

The output directory in AFL contains the results of the fuzzing process, including crashes, hangs, bitmaps, statistics, and other data. It is also used for synchronization between multiple machines or cores running AFL.

What is the purpose of the queue data in AFL?

The queue data in AFL shows the original file in the queue where it started and its current position. It helps AFL learn from each iteration and adjust its approach, flipping bits and learning what type of data the program wants or doesn't want.

How does AFL handle synchronization in a multi-core or multi-machine setup?

AFL uses the output directory to synchronize multiple slaves in a multi-core or multi-machine setup. The master process gives the slaves a queue of tasks to do, ensuring they always have work to do until the master updates the queue.

What is the significance of finding crashes during fuzzing?

Finding crashes during fuzzing is significant because it indicates potential vulnerabilities in the program. These crashes can be the starting point for further analysis and exploitation, leading to the discovery of serious bugs or security issues.

How can the crashes found by AFL be used for further analysis?

The crashes found by AFL can be analyzed using tools like gdb to understand the program's behavior at the time of the crash. This can help in identifying the cause of the crash, such as a segmentation fault or memory corruption, and potentially lead to the creation of a proof-of-concept exploit.

What is the role of gdb in analyzing crashes found by AFL?

Gdb (GNU Debugger) is a tool used for debugging programs. It can be used to analyze crashes found by AFL by running the program with the problematic input and observing the behavior, stack trace, and register states at the time of the crash, which can help in understanding and exploiting the vulnerability.

Outlines

00:00

😀 Introduction to AFL Fuzzing

In this introductory segment, Stick and Christopher (also known as Cook) discuss the basics of fuzzing and AFL (American Fuzzy Lop). Cook explains that AFL is a fast testing tool designed to find bugs in binary programs by sending numerous requests into a system. The process involves taking an original input and transforming it through thousands of iterations per second. Cook demonstrates how to set up AFL by replacing the GCC compiler with AF-GCC and setting the CC environment variable. This enables the compilation of programs with built-in instrumentation, which allows AFL to monitor the program's state and detect when it reaches points of interest, such as breakpoints.

05:02

🔍 Fuzzing an HTTP Server Configuration File

The second paragraph delves into the specifics of fuzzing an HTTP server's configuration file. Cook discusses the importance of fuzzing the configuration file parser, especially when an attacker might have arbitrary write access. The goal is to potentially crash the process and exploit the memory overwrite. The input for AFL in this case is the configuration file, and the output is a directory where AFL syncs its findings. Cook also mentions the importance of not running AFL on SSD drives due to the high number of write operations, which can wear out SSDs. Instead, using tmpfs (temporary file storage in RAM) is recommended. The discussion also touches on the ability to synchronize fuzzing efforts across multiple machines or a cluster.

10:02

🚀 AFL Fuzzing in Action and Finding Crashes

In this segment, the focus is on running AFL to fuzz an HTTP server and observing the results. Cook demonstrates how AFL quickly identifies crashes, which are the starting point for further analysis. The discussion includes the scalability of AFL, which can be run on multiple cores to increase the number of attempts per second, potentially leading to the discovery of more bugs. Cook also explains that AFL can be run in the cloud or on multiple cores to speed up the process. The output directory is highlighted as a crucial component, containing information about crashes, hangs, and the queue of inputs being tested. The segment ends with a look at the crashes directory, which contains the configuration files that caused the crashes.

15:04

🐛 Analyzing Crashes and Using GDB

This paragraph discusses the analysis of crashes found during fuzzing. Cook explains that the output directory contains a 'crashes' directory with files that caused the crashes, as well as a README file that provides information on how the bug was found. The discussion moves to using GDB (GNU Debugger) to further investigate the crashes. GDB is highlighted as a valuable tool for security research and CTF competitions. Cook demonstrates how to run GDB on the HTTP server and analyze the crash by setting breakpoints and examining the program's behavior. The goal is to understand why the program crashes and potentially exploit the vulnerability.

20:08

🔎 Exploring the Impact of Fuzzing and Reporting Bugs

In this segment, Cook and Stick discuss the implications of fuzzing and the process of reporting bugs. They mention that fuzzing can lead to the discovery of denial of service vulnerabilities and privilege escalation issues. Cook shares his experience of reporting a bug to an HTTP server vendor, providing details on how the bug was found and the stack trace obtained using GDB. The conversation also touches on the potential for fuzzing to uncover bugs in various file formats and parsers, which can be exploited for different purposes. The importance of responsible disclosure in bug bounties and penetration testing is emphasized.

25:10

🌐 Community and Resources for Fuzzing

The final paragraph wraps up the discussion by highlighting the community aspect of fuzzing. Cook mentions setting up webcasts to help people get started with fuzzing and provide a platform for live interaction and support. The F-Secure Lab channel on YouTube is introduced as a resource for those interested in fuzzing. The conversation concludes with an appreciation for the learning experience and an invitation for viewers to join the fuzzing community and explore the potential of AFL and fuzzing techniques.

Keywords

💡Fuzzing

Fuzzing is an automated software testing technique that involves providing random, invalid, or unexpected data to a program in order to observe how it handles the input. In the context of the video, fuzzing is used to find bugs in binary programs by sending numerous requests to test the program's robustness and uncover potential vulnerabilities. The script discusses the use of AFL (American Fuzzy Lop), a fuzzing tool, to perform this testing.

💡AFL (American Fuzzy Lop)

AFL is an open-source fuzzing tool designed to discover bugs in binary programs by automatically generating input data and observing the program's behavior. It is central to the video's theme, as the tutorial focuses on using AFL to fuzz an HTTP server and find potential crashes or vulnerabilities. The script mentions using AFL with GCC (GNU Compiler Collection) to compile programs with instrumentation for fuzzing.

💡Instrumentation

In the context of fuzzing, instrumentation refers to the process of modifying a program's code to collect runtime information about its execution. This allows the fuzzer to understand the internal state of the program and identify paths taken during execution. The video script explains that AFL compiles programs with built-in instrumentation to track the program's behavior during fuzzing.

💡GCC (GNU Compiler Collection)

GCC is a collection of compilers for various programming languages, including C and C++. In the script, it is mentioned that AFL replaces GCC with 'AFL-GCC' to compile programs with instrumentation, which is a crucial step in preparing a program for fuzzing with AFL.

💡Configuration File Parser

A configuration file parser is a component of a program that reads and interprets configuration files. In the video, the focus is on fuzzing the parser of an HTTP server's configuration file, assuming an attacker has write access to this file. The goal is to find input that causes the parser to crash or behave unexpectedly.

💡Crashes

In the context of the video, crashes refer to the instances where the fuzzed program encounters an error and terminates unexpectedly. The script describes finding crashes as a significant outcome of fuzzing, as they indicate potential vulnerabilities that can be further investigated and exploited.

💡SSD (Solid-State Drive)

SSDs are storage devices that use flash memory to store data. The script mentions that running fuzzing, which involves a high number of writes, on an SSD can be harmful due to the limited write cycles of flash memory. It suggests using 'tmpfs', a temporary filesystem stored in RAM, to mitigate this issue.

💡tmpfs

tmpfs is a temporary filesystem in Unix-like operating systems that resides in volatile memory (RAM). The script recommends using tmpfs for the output directory of fuzzing tools like AFL to avoid the wear and tear on SSDs caused by the high volume of writes during fuzzing.

💡GDB (GNU Debugger)

GDB is a debugger tool used to analyze and debug programs written in C, C++, and other languages. In the script, GDB is used to analyze crashes found by AFL, allowing the user to understand the cause of the crash and potentially develop an exploit. The video mentions using GDB to investigate a segmentation fault in the fuzzed HTTP server.

💡Segmentation Fault

A segmentation fault is a specific kind of error caused by accessing memory that the program is not allowed to access. In the video, a segmentation fault is identified as a result of fuzzing the HTTP server, indicating a serious vulnerability that could potentially be exploited for privilege escalation.

💡Privilege Escalation

Privilege escalation refers to the act of exploiting a bug or vulnerability to gain higher levels of access or permissions in a system. The script discusses the potential for a segmentation fault caused by fuzzing to lead to privilege escalation, allowing an unprivileged user to gain root access.

Highlights

Introduction to using AFL (American Fuzzy Lop) for beginners as a fast testing tool to find bugs in binary programs.

Fuzzing is the process of sending numerous requests into a system to find vulnerabilities.

AFL works by taking an original input and transforming it through thousands of iterations per second.

The importance of automation in fuzzing to ensure efficiency.

Setting up AFL involves using a compiler like GCC with an environment variable CC.

Compiling with AFL involves instrumenting the code to track program states.

Instrumentation allows AFL to understand and learn from the program's behavior during execution.

AFL can be run on multiple CPUs with tuning options for performance.

The discovery of a vulnerability in an HTTP server during fuzzing sessions.

Explanation of how fuzzing an HTTP server's configuration file can lead to crashes.

The use of an output directory for AFL to synchronize findings across multiple processes or machines.

Avoiding SSD drives for the AFL output directory due to high write operations that can wear out SSDs.

AFL's ability to mutate input data to discover what type of data a program wants or rejects.

AFL's use of a queue system to manage input data and mutations.

Finding crashes with AFL and the significance of these crashes for vulnerability discovery.

Using GDB (GNU Debugger) to analyze crashes and understand the underlying code issues.

The process of reporting a discovered vulnerability responsibly to the affected vendor.

AFL's continuous learning and mutation process until it exhausts the search space.

The potential for fuzzing to be applied to various file formats and parsers in security research.

The value of fuzzing in bug bounty programs and penetration testing.

Upcoming webcasts on fuzzing to help beginners get started and troubleshoot issues.

F-Secure Lab's initiative to create a community around fuzzing to increase its adoption.

Transcripts

hi I'm stick and today I'm gonna learn

something new and for this reason I

brought on Christopher yeah also known

as cook to help me understand the

beginner's guide to fussing or a mean

audience in a beginner's guide but it's

gonna be an introduction to using AFL

thank you so far

hi I'm cook hi cook cook instead show

yeah so we you and I outside of this

camera

situation has had been has been playing

around a little bit with fussing and I

kind convince you to get on here and

teach me and others how this actually

works and talk a little bit about

fussing so without any further ado

please take it away

all right so today we're gonna play with

AFL AFL is fast testing tool and it's a

method to find bugs in binary programs

fussing is sending a lot of like

requests into something right is that

the idea yeah so you have an original

input in a dictionary of possible inputs

and then it's taking that original thing

and transforming it every time it runs a

new iteration and it runs thousands of

iterations every second so this is

automation yeah definitely you have to

automate it otherwise it won't work okay

show us how you did it okay so

essentially when you want to do this

when you want to run AFL you have to use

a compiler so compiling software you do

it with in Linux you do it with GCC

normally and GCC is by the compiler

program called make or make file sis is

define an environment variable called CC

so CC equals GCC is an environment

variable that's automatically assumed

every

you do a compilation and compiling

programs means to take all that C code

and turn it into turn it into a binary

program cool with AFL you're going to

replace GCC with with your thing so our

thing is AF - GCC and setting that

environment variable we can now compile

the program with something called

instrumentation built-in and that means

that it's changing the code that you're

building so that every time it comes the

program turns into a certain state then

that's registered by something called

the instrumentation instrument or the

instrumentation state oh cool right so

having instrumentation means that you

can know what's going on inside of the

program when you run it and this is a

really nice feature with a FL that other

Foster's aren't that good at and that

means that if al can understand when you

have reached into a point that you're

interested in reaching say you want to

you want to break a certain point in a

certain place than a FL will know if you

are there so it's some kind of break

points so taking its just measuring all

the time like where are you in the code

and if something breaks breaks it's

gonna know instantly yeah yeah it's

definitely like a break point I think

this is more more what you could call a

function hook where you take a regular

function you put yourself in a place of

it and and that's something that it can

put into some kind of a live

documentation that it's understanding

and learning from that so it's a sort of

a self learning program cool so once you

have compiled your program you can start

it using the AFL foster that looks a bit

like this AFL fuss is name of the

program you want to run efl by the way

is a program that you can download using

apt-get install AFL that's it

so it's it's super easy to set up just

get started and yeah now you're up and

running on different CPUs you have some

different tuning options that you want

to set and those tuning options is

something that AFL will tell you what to

do with so you can adapt to multiple

cores and you can do different things

but it depends on your architecture

we've already done this but if I will

tell you exactly what you need to do for

your CPU cool so the - I argument it

gives you the inputs to the program and

we're gonna take a look at the input to

this program because we are today

fussing HTTP server no I got cool and

the HTTP server we are fussing we did

one more take with this last week and we

are ready to publish it when we realize

that we have found this here today and

we had to report it and that meant that

we couldn't really publish it at that

time right so this is the second

recording for that obviously yeah when

you financier days do during your

fussing sessions it's a good thing to

report those yeah so we're gonna show

you how we found that Saturday but we're

not going to show you what program it's

in but it's a HTTP server we'll give you

that much so if you look it into the

input directory I have a default

configuration file that sort of looks a

bit this is this a fake configuration

folder I wrote it's this similar to the

default file where the domain domain

name is f-secure comm which is my my

employer the the configuration file is

pretty straightforward we are today

going to fuss the configuration file

parser and the reason why we want to

fastest parser is because we are

assuming that an attacker has arbitrary

write access but once the escalator

privileges to root or get access to

whatever that server is is doing and

since you have write access if you write

to that configuration file something

arbitrary and bad

then maybe you can make the process

crash and if the process crashes then

you can overwrite this memory and that's

what we're gonna try to do or already

used wait for it let's say that we had a

malicious conferral that we created and

uh well we would use do is to either use

crash the daemon itself right or or just

wait for it to reboot and then hopefully

you know nobody's noticing what's going

on in wala suddenly we have root axes

yeah exactly

and in this case the input to a FL is

that configuration file so the default

the default configuration file is pretty

much what we need as an input as an

output output in this case is a

directory where a FL is syncing whatever

it's doing with other processes so if

you run this with multiple course you

can synchronize that output using the

output directory and this is something

that you can synchronize between

multiple machines even so if you're

having a cluster running it and you want

all these machines to know what's going

on

that's good things just meant can you

map this over network or is that not

recommended yeah you can so what what

the master process does is it

synchronizes multiple slaves using the

output directory and then it gives the

slaves a queue of things to do so if

there is a certain lag between the

machines that queue will sort of work

itself out so as long as the lag is not

longer than the queue then the slaves

will have something to do to do until

the master realizes that this is where

we want to go with with the fussing so

all the directory is pretty important it

also contains wherever our like crashes

and things that we found out during the

this attempt is going to end up in the

output directory

oh cool I got a question though and I

know last time we talked a little bit

about it we and it didn't really strike

me self out for me but you've mentioned

that it would be a good idea to not run

this on SSD drives right so the output

directory is some directory that is

written to a lot of times so it's

written for every single instance in my

case is writing 2000 times every second

and that means a lot of Rights and for

an SSD that can be a bit harmful SSDs

are are not always ready to handle that

much data and it can wear them out

quickly and therefore there is something

called tmpfs which is like what do you

have in /tmp in your machine where you

can write as many times as you like

because it's on the RAM and it's all

very quick so so we have the input which

is the config file actually we can have

a directory full of inputs so if we had

a bunch of other bunch of other config

files there that would be fine and that

gives a file inspiration to how to

destroy things oh okay so it's fetching

all this other stuff as well and yes

thinks about maybe this you can put

random data in there and you can put

legitimate data in there eventually AFL

will figure out what type of data this

program wants

so it's or doesn't want so the next

argument for AFL is to type in hd-dvd

and that's the name of the server that

we are fussing and there C is the

arguments for a config file and then we

type in at-at-at that is the variable

where EFL will input the forcing

mechanism so this is where it will go

and attack so if we run this it's going

to initiate by trying to find basic

paths into the program and just try to

understand the program and now it's

started and even like in the first

second here we found a crash and when

this turns red and it says one unique

crash then we have essentially we have

the beginning of a CRT

because this is yeah and that's not the

time it takes to sometimes there's the

second one

and so now we're running in two thousand

attempts a second you can I mean you can

scale this as much as you want to if you

have more course you can scale this much

much faster and if you do that then you

can find more bugs basically and if you

are pressed with time let's say that

you're a developer and you want to test

your own software then maybe you want to

do this in the cloud or you run it on

multiple cores and you get it up to

maybe thirty thousand twice a second

because that's gonna take the tax base

or make it much shorter absolutely it's

like if you can run this like not just

one time faster like ten or twenty times

faster yeah horse you're gonna save like

a lot of time where it yeah isn't it

gonna be like very CPU intensive and

very expensive that if you let's say

you're putting it in a cloud storage

somewhere yeah I mean it uses only CPU

so if you have a story solution where

where CPU is cheap and the rest is

expensive then that's fine

but but it's using a lot of CPU and

somewhat a bit of network if you have it

networked but but it's only using as

much as you allow it to use so you can

make it make it crash and hang in

different different ways

damn it that means that I'm gonna have

to buy back all my old rack servers now

again yeah yeah so CPU cost nothing if

you own the server if you have your own

servers and this is what they're for

right used abuse for cracking and CPUs

for fussing yeah oh man oh man so right

now we're running on 12% of the CPU that

means in this case that we're running on

bond core only which is enough for our

example and in another caste we can show

maybe how to increase that number

because if you use more than or up to a

hundred percent of the CPU that means

all course then you can then you can

make a lot of damage

hey let's do that that would be exciting

but and it's this ever going to stop

though or or it doesn't ever feel like

I'm done now this this never exhausts

because it actually has ways of muting

the output and coming up with new ideas

until forever so I think this can pretty

much go on forever in this case but you

can exhaust the search space for a given

input so imagine you have you know that

a program only takes true or false as an

argument then that search space will be

exhausted pretty quickly and the program

will just run on hot fuse basically cool

so we we currently have two crashes what

does that really mean like what do one

simply do with the crashes yeah so now I

interrupted the program typing control-c

and it says we're done have a nice day

thanks and I'm done too right so now we

have the output directory let's take a

look at that so in the output directory

you can see the crashes directory the

first bitmap that gives an information

about where in RAM are we at this point

statistics hangs that's an option to

crashes so the hang is when a program

doesn't finish in a given certain time

so you put a timeout on a program you

can assume that it's not supposed to

hang until this or that or it's supposed

to finish before that's the particular

time and and every input that exceeds

that ends up in hang block data don't

know the queue is where the next input

is queued let's look at the queue yet

for now because this is pretty pretty

interesting so looking at what it's

doing it shows the original file in the

queue where it started and then it shows

where it's at so right now this queue

data here is on position 25 and it's

flipping one bit and

we can look at what that looks like it

pretty much looks like a shorter version

of the previous file it's flip flip flip

they stopped what it did previously and

every time it does this it learns that

parsing the config file at this point

gave that output and config parsing the

config file it and another point Kay

gave something else in terms of of we're

in the matheletes ending up let's move

into the crashes directory because

that's what you wanted to see right

whoopsie yep

so there is a readme file and this

readme file is pretty good the readme

file shows what you actually ran to find

this bug and that's something that you

can give to a to a organization that the

dust is testing so that they can

actually know what's going on I mean if

they want to reproduce this bug then

then it's good to have that command line

saved so this entire directory is

relevant for anyone who wants to

reproduce it cool inside of here we have

the config file that caused the crash so

this is a config file that has a

character called 8a in it and that's

like a non ASCII character maybe that's

the reason white crashed maybe there is

another reason it says that the log

access file is called hard bracket that

looks kind of weird as well and the doc

index has bracket as well maybe that's

not it we don't know exactly but we can

find out eventually we can look at the

other file for now so this is two files

representing two different crashes

all right so this is a weird one and

weird is good the weirder the better

yeah so now it's actually advantage to

produce this kind of a string here where

it says TMM Vernis whatever that means

yeah and that's yes the the machine

talking and in other cases woman when I

did fussing with with pictures before I

started with basically an empty file and

it actually managed to produce in a few

days it managed to produce a valid JPEG

header by us looking at the reaction

from the programs like if I want to get

a step further I have to type in this in

this position oh cool so here it's

actually created the image for you yeah

yeah and that's built it up yeah that's

the definition of mutation right cool so

this is a configuration file that also

causes a crash and there's also non

ASCII characters in a comment on the

last line maybe that has something to do

with it I'm not exactly sure yet so I'm

gonna back out to this directory where

the HTTP server was yeah and now I'm

gonna run gdb and gdb sounds for annuity

bugger it's if you are into CTF or any

type of security research gdb is a good

tool to know it's older than me and it

has a lot of good plugins for its that

can enable you to write exploits later

cool so we're gonna run gdb on httpd

which is the name of the server and

right now I didn't compile it with the

bug symbol so it's not super easy to

find out what I what's going on but if I

have debug symbols on it's going to tell

me on what line in the code the bug

exists which is pretty nice sorry I'm

gonna set up an argument which is - see

this is the configuration I do for the

programs I typeset args - C and then

output crashes and then I paste in the

name of that file the second file that

cost a problem for us

so this is now the configuration file of

the program at this point I can set up a

breakpoint myself if I happen to know

what I'm going for if there's something

in particular I'm interested in but yet

right now I don't know so now I can run

some people put the breakpoint on main

for instance which is usually a function

that starts initially in the pro in the

program in this case I know there is no

main function so it's not gonna work the

main function doesn't work necessarily

the way I wanted to but you can put the

breakpoint on either and offset into the

file or into a function that you think

caused the crash this is much easier to

do if you have debug symbols on so if I

type on run right now then you'll see

that there is a segmentation fault and

this is not supposed to happen normally

like a program is not supposed to seg

fault every time it reads the cosmic

file then you have a serious

vulnerability in this case this is a

vulnerability where we are running as an

unprivileged user writing to a config

file right and the service is reading

that config file and it's corrupting

memory causing a seg fault somehow yes

and it's doing it as root because root

is needed to start this service and bind

port 80 and this is running as root

initially and then when it's running

it's it's crashing and I have Minkoff

all of the memory so that's a privilege

escalation on the kind of suite and and

here we can do a back trace

oops sorry a back trace where it shows

the states of of the program and you can

look into the info about the registers

that you're dealing with right now

no idea

I'm sorry about that there are more

tutorials that can go into depth and

show how to do this the exploitation and

proof of concept state because what we

have right now is a crash right we have

a denial of service vulnerability that's

local by the way but it's still

something after this point in time we

start figuring out why is the return

winter here at this point why is it

there what happened how did it secure if

we do that using gdb we can start

figuring out writing a proof-of-concept

exploit have you done osip by the way

the buffer overflow part is very much

like this right so this is exactly

that's that you have to do at this point

you can you can input a certain pattern

into the program see if that pattern

reoccurs and if you do that you can see

where this is a memory and what you were

able to overwrite using the original

config file that we looked at and this

is pretty much how you say a file that's

amazing so the whole idea with AFL is

for us to by automation and a little bit

of and I wouldn't called ai but at least

a little bit of learning that it learns

what's going on in the process and then

when it crashes its try to replicate it

and see what happens again again again

again until you know whatever kind of

break it then this happens and it

outputs that file and that's where the

exploitation creation begins right yeah

we're we're people this is where when

people write exploits this is what they

do

yeah and this is how you this is how you

find a bug and and this is something

that I already in this point

reported to the vendors I told the HTTP

server vendor what the bug was about how

it was found what the stack looked like

by using gdb and gave the core dump file

to them so they could reproduce that bug

in their local environment and see that

this is a problem that's very

responsible of you I'm I'm very proud in

bug bounty do you think this is useful

for you maybe it's not this situation

because in bug bounties you don't if you

get this far you report it and get out

right you can touch just a part of it

this that's that's game over you've done

your work you don't privilege escalate

further on you might just be doing it in

pen testing my buddy bounties you don't

do it but I see other areas where this

can be very interesting like there's

file formats there's

different other servers parsers and

things that are being used by our

industry that if you can find an exploit

or something that breaks that that could

turn into I don't know a DOS or some

kind of other this configuration

happening maybe I don't know maybe even

a little bit of memory leak if you're

lucky right so I mean if you have an

input like a sip file or a JavaScript

parser or something where you can upload

maybe a HTML document that's key

getting parsed or CSS getting parsed or

maybe maybe a video file or something

mm-hmm there's there's all these parsers

out there that that's gonna have to deal

with and I know you and I have been

goons and reaches research on this and

eventually yeah I would recommend anyone

to to you at least started to doing a

little bit of fussing I think it's super

super fun and and so rewarding when you

see that crashes sign coming up you're

like yeah so I mean it's it's so easy to

get started with and the types of bugs

you find you can use them on the large

scale for much longer time because this

low-level level programs are reused

identically on multiple platforms I mean

so imagine that you we were playing with

a media transformation for Matt I found

the bug the other week and that's

something you can reproduce forever you

know like it's reported and all and they

don't seem to want to fix it because

it's just a hang and not a crash I was

like okay fine so then you can use that

to identify this media transformer tool

well all this is super interesting but

could you've been you've been doing this

for a while and I know you got some aces

up your sleeve can you tell us a little

bit more about that so we're setting up

we're setting up in web casts where you

can follow along and live answer and ask

questions how to get a get started with

fussing and if you have getting got

stuck recently with it you can get help

there in the web cast and it's on a

secure Labs where me my colleagues

publish lots of talks of

we're doing basically that's amazing so

so it's going to be a community-based

thing that if security is doing to get

more people into fussing yes so this is

the f-secure lab channel on youtube and

it's it's available to anyone who wants

to wash it that's amazing

god damn it I learned something new

today as well and and I'm gonna be a

huge fan of the channel of course I'm

gonna glue myself to that so thank you

very much for taking your time and

learning me or teach me about AFL thanks

for for joining in guys so this is it's

really fun to teach and thank you stuck

for having me appreciate it

awesome a my bike

[Music]

[Music]