Offensive Software

Exploitation
SEC-300-01/CSI-301-02

Ali Hadi
@binaryz0ne
 Bug Hunting…

a quick road to bug hunting …

• INFOSEC 101 …. 

ashemery.com 3
 Bug Hunting
• Bug hunting is the process of finding bugs in software or
hardware “cited [1]”

• Security bugs (aka software security vulnerabilities and

ashemery.com 4
 4 Fun & Profit
• Finding security bugs was done for fun and to get media
attention
• Today, organizations are paying for security researchers to
identify bugs
– Bounty programs (Google, FaceBook, Twitter, RedHat, etc)
– Zero Day Initiative (ZDI)
– iDefense
– Tipping Point
– Pwn2Own
– Others? Please add

ashemery.com 5
 Taking Advantages of Bugs
• Software that take the advantages of a software vulnerability
are called “exploits”
• Exploiting a widely used application, os, protocol, etc … will
grab huge media coverage and attention
– Road to become a Hacking Star 

ashemery.com 6
 Exploits Language
• No specific language for writing exploits
• Exploits can be written using any programming language
• C, C++, Perl, JavaScript, Assembly, and PYTHON !
• I prefer Python for it’s simplicity and for the huge range of
libraries that could be used for creating a PoC or working
exploit

ashemery.com 7
 Bug Hunting Formal Process
• Writing software is a human art, and two different coders may
code the same function with the same requirements
differently!
• For that reason IMO, Bug Hunting is a human art too!
• No formal process to finding bugs in SW, but there are a
couple of techniques that can be used for bug discovery

ashemery.com 8
 Common Techniques
• Static Analysis
– Static Code Analysis
– Reverse Engineering
• Dynamic Analysis
– Debugging
– Fuzzing

• Each technique has it’s pros and cons

ashemery.com 9
 General Bug Hunting Methodology
Understand the Application
• Read specs / documentation
– understand purpose or business logic
• Examine attack surface
– inputs, configuration
• Identify target components an attacker would hit
– think like an attacker to defend better:
• try to hit the Database for SQLi?
• try to upload a file?
• try to spawn a shell?

ashemery.com 10
 What Leads to Bugs?
• Miscalculations
• Failure to validate input
• Programmer failure to understand an API
• Failure to validate results: operations, functions, etc
• Application state failures
• Complex protocols
• Complex file formats
• Complex encoding / decoding / expansion
• etc

ashemery.com 11
Debugging…
 Debugger
• A computer program that lets you run your program, line by
line and examine the values of variables or look at values
passed into functions and let you figure out why it isn't
running the way you expected it to.

ashemery.com 13
 Why use Debuggers
• Debuggers offer sophisticated functions such as:
– Running a program step by step (single-stepping mode),
– Stopping (breaking) (pausing the program to examine the current state) at
some event or specified instruction by means of a breakpoint,
– Tracking the values of variables,
– Tracking the values of CPU registers,
– Attach to a process,
– View the process’s Memory map,
– Load memory dump (post-mortem debugging),
– Disassemble program instructions,
– Change values at runtime,
– Continue execution at a different location in the program to bypass a crash
or logical error.

ashemery.com 14
 Common Debuggers
• GNU Debugger (GDB)
• Microsoft Windows Debugger (Windbg)
• OllyDbg
• Immunity Debugger
– Based on Ollydbg
• Microsoft Visual Studio Debugger
• Interactive DisAssembler (IDA Pro)

ashemery.com 15
Immunity Debugger

ashemery.com 16
 ?
• Can we modify executables using a debugger?
• Write an example showing howto modify a Windows EXE file.
– For example bypass a whole check routine or set of instructions!!!

ashemery.com 17
 Determining Exploitability
• This process requires experience of debugging security issues,
but some steps can be taken to gain a good idea of how
exploitable an issue is...
• Look for any cases where data is written to a controllable
address – this is key to controlling code execution and the
majority of such conditions will be exploitable
• Verify whether any registers have been overwritten, if they do
not contain part data sent from the fuzzer, step back in the
disassembly to try and find where the data came from

ashemery.com 18
 Determining Exploitability – Cont.
• If the register data is controllable, point the register which
caused the crash to a page of memory which is empty, fill that
page with data (e.g., ‘aaaaa...’)
• Repeat and step through each operation, until another crash
occurs, reviewing all branch conditions which are controlled
by data at the location of the (modified) register to ensure
that they are executed

ashemery.com 19
 Determining Exploitability – Cont.
• Are saved return address/stack variables overwritten?
• Is the crash in a heap management function?
• Are the processor registers derived from data sent by the
fuzzer (e.g. 0x61616161)?
• Is the crash triggered by a read operation?
• Can we craft a test case to avoid this?
• Is the crash triggered by a write operation?
• Do we have full or partial control of the faulting address?
• Do we have full or partial control of the written value?

ashemery.com 20
 Language To Use
• Don’t listen to others
• Just choose one, whatever you like
• But if you still need a recommendation? Python is my answer
• Many hack libraries are written in python
• If you use C for fuzzing because you just want to feel you’re
l33t, you’re wrong!
• Realize what is your goal

ashemery.com 21
 SUMMARY
• Described what bug hunting means, and who's hunting nowadays
• What we mean by taking advantages of bugs
• What language to use to write an exploit
• Why there isn't a bug hunting formal process for vulnerability discovery
• Common Techniques for bug hunting
• What and why do we need a debugger and the most popular debuggers

ashemery.com 22
 References
• A Bug Hunter’s Diary, Tobias Klein, No Starch Press
• Fuzz Testing, http://en.wikipedia.org/wiki/Fuzz_testing
• Fuzzing: Brute Force Vulnerability Discovery, Michael Sutton, et al, Addison-Wesely
• University of Wisconsin Fuzz Testing (the original fuzz project)
• Fuzzing 101, NYU/Poly.edu, Mike Zusman, http://pentest.cryptocity.net/fuzzing/
• Fuzzing for Security Flaws, John Heasman, Stanford University
• EVERYONE HAS HIS OR HER OWN FUZZER, BEIST (BEISTLAB/GRAYHASH), www.codeengn.com
• An Introduction to SPIKE, the Fuzzer Creation Kit, Dave Aitel, http://www.docstoc.com/docs/2687423/An-
Introduction-to-SPIKE-the-Fuzzer-Creation-Kit---PowerPoint
• Common Vulnerablities and Exposures, http://cve.mitre.org/
• Common Weakness Enumeration, http://cwe.mitre.org/
• Seven kingdoms of weaknesses Taxonomy,
http://cwe.mitre.org/documents/sources/SevenPerniciousKingdomsTaxonomyGraphic.pdf
• Common Configuration Enumeration, http://cce.mitre.org/
• National Vulnerability Database, http://nvd.nist.gov/home.cfm
• Exploit Database, http://exploit-db,com
• http://www.security-database.com/toolswatch/+-Fuzzers-+.html
• http://caca.zoy.org/wiki/zzuf
• https://code.google.com/p/ouspg/wiki/Radamsa

ashemery.com 23