Embed Size (px)
Citation preview
Introduction
¡ This presentation is an overview ofthe lab process used by HBGary™to locate and exploit software bugs
¡ The value is reduced timeinvestment and formalizing a ‘blackart’
The Deconstructionist
¡ Taking a system apart is aboutuncovering mysteries
¡ Having secret knowledge attractsthe human psyche at the deepestlevel
¡ There is an age old battle betweenthose that create systems and thosewho take them apartl i.e, crytoanalysis
Why Exploit Software?
¡ Exploits are worth moneyl A vulnerability can be worth over $100K
¡ The vendor costs are huge for a publicvulnerability
l An exploit costs less than physical ‘bugs’
¡ Exploits are worth livesl An exploit is safer than physical penetration
¡ Exploits are strategicl Disable or control the information systems of
your enemies decision cycle
Survivability
¡ Exploits have a lifetime¡ Every use of an exploit has the
potential to compromise the asset¡ Exploits depend on bugs and your
enemy may also find the same bug¡ The public may find the same bug¡ Once public, many exploits can be
protected against or detected via anIDS
In order to maintain a battleadvantage, your offensive
information capability must includea lab process for finding andexploiting new software bugs
Chapter One
The Bugs!
The Bugs
1. Buffer Overflowsa. Lack of bounds checkingb. Arithmetic errors
2. Parsing Problemsa. Input filters and normalization
3. General State Corruption4. Race Conditions
Buffer Overflows
¡ Old News, but still most commontodayl Because of speed, most server
software is still developed in c/c++
¡ Will remain common until oldcompiler technologies areabandonedl Strongly typed languages, such as C#,
eliminate simple string overflows
Parsing Problems
¡ Not solved by better compilers¡ Solved only by good algorithms¡ To eliminate parsing problems
requires standardized algorithmsl Similar to peer review on crypto
systems
¡ This will never happenl Parsing problems here to stay
General State Exploits
¡ States control decisions¡ Users can cause state transitions¡ Some states are insecure by nature¡ State exploits are found by sending
commands in the exact order andcontext to arrive at the insecurestate
¡ Only solved by provably correctsystemsl Humans are never going to build
provably correct systems
Race Conditions
¡ State problems are going to bedifficult to measure and control
¡ When state is managed over manynodes, the problem becomes evenharderl When state must be synchronized
among nodes, we have race conditionsl The problem is compounded greatlyl This is the ‘buffer overflow’ of the
future
Chapter Two
What is the‘GreyBox’ process?
GreyBox:Combining both static analysisand runtime fault injection tomaximize coverage of asoftware programs’ state-space. Typically used todetect and isolate fault statesin a software system.
White Box
¡ In theory, operating with full knowledgeabout the inner workings of the systeml At best, we only have an approximate
understanding of the builder’s intent
¡ White box analysis involves “deadlistings”static disassemblies of the binaryl Source code is an added advantage, like
having really good documentation for thedeadlisting
¡ The software is not being executed
First Pass
¡ When confronted with a new binary, theHBGary team fires the binary throughBugScan™
¡ We obtain a report within minutes toassess whether the programmers usesecure coding practicesl Typically they do not
¡ We use the BugScan report to prioritizewhich binaries will be analyzed firstl Binaries with bad reports are hit first
Manage the Deadlisting
¡ IDA-Pro allows you to manage andcomment a large deadlisting
Is it actually exploitable?
¡ Depends on many variables in theenvironment
¡ All automatic analysis tools havethis problem
¡ It almost always takes an expertreverse engineer to determine if acondition is exploitable
Does it matter?
¡ Even if a vulnerability cannot bereached today – what can you sayabout tommorow?
¡ What if interface changes?¡ What if code gets used from other
locations?¡ Is the original author going to be
maintaining this code in 10 years?
Automatic Bug Detection
¡ The bug must have a definedpattern, it must be schematic innature
¡ Effective when certain conditionsexistl Availability of type informationl Separation of data and codel All instructions can be recoveredl Data that drives control flow can be
mapped
Branching Decisions
¡ Many branches are made based onvalues that are calculated atruntime
¡ The static analyzer must emulateexecution to determine these values
¡ At some point, the emulationbecomes computationally equivalentto running the program in the firstplace. How much emulation isenough?
Backtraces reach dead ends
¡ We backtrace up to 64 steps from avulnerable functionl Every branch is exercised
¡ Back traced cross references can beused to connect input with a codelocationl For example, does a previous function
take input from the network?
¡ Many times a static backtrace dead-endsl Windows message handler
Black Box
¡ All we see are the outputs from thesoftware – no inner workings
¡ Requires deep protocol knowledge
¡ ‘Fuzzers’:l Hailstorm and Spike
Black Box is not stand alone
¡ Black box testers take FOREVER tocomplete their input sequences.
¡ If the program is slow, thiscompounds the problem
¡ Amounts to ‘brute forcing’¡ Finding bugs with pure brute force
is mostly luck
Blackbox State
¡ Typical network software is highlystateful
¡ A client must be able to maintain acomplex state in order tocommunicate effectively with thetarget
¡ Modeling highly stateful clients fromscratch is very time consuming andprone to error
Instrumented Clients
¡ Using a real client programeliminates most of the state issues
¡ You don’t need to rebuild the wheel¡ Fault injection is inserted in-transit
by modifying the code within theclient program
¡ The client program becomes ahostile mutant
Fault Injection Clients
¡ If the protocol is proprietary youhave two choicesl Modify in the middle the packets
¡ Only works is protocol is not overlycomplex and not encrypted – beware ofauthentication/encryption
l Instrument proprietary client¡ Requires difficult call-hooking, time
consuming
Hooking clients
¡ Find location where pointer is held inregister
¡ Put breakpoint on this location and modifythe given string in memory l Cannot BO string w/o corruption
¡ Or, replace the pointer with anotherpointerl May cause state problems in some clients
¡ Using ‘debugger’ technology makes thiswhole process easier – no EXE patchingrequired
GreyBox
¡ Combine black-box injection withcode analysis
¡ If you use a program debugger,your performing grey-box analysis
¡ Performed at runtime so softwarecan be observed
¡ All instructions which are executedcan be obtained. All data involvedat these points can be tracked
Interactive
¡ Grey-box testing is an interactiveprocess between a skilled engineerand the target program
¡ Tools used include SoftIce, OllyDbg,Aegir, Fenris, GDB, Tempest, andthe MS-Visual C debugger*
*IDA-Pro has an integrated debugger, but the currentversion is not evolved enough for industrial levelwork
Fenris www.bindview.com
Chapter Three
How to useBug Scan™
Easy Stuff – Introducing BugScan!
¡ BugScan is extremely simple touse
¡ Submit binary and get report¡ Report cannot verify is conditions
are actually exploitablel But it takes 30 seconds, not 30 hoursl Defensive stance – don’t wait for
someone to attack before you protectyourself
Submit a File
View the Report
Latest BugScan Reports from the Field
TO BE REVEALED AT CONFERENCE
FREE BUGSCAN for BLACKHAT
¡ Use this logon to scan any binary,free for blackhat attendees for thenext 60 days
l HTTP://www.hbgary.com/freeblackhat
Chapter Four
HowHBGaryUses GreyBox
Hard Stuff
¡ Designed for expertsl Not a product!
¡ Requires reverse engineering skillsnot limited to:l Runtime debuggingl Assembly codel Protocolsl Technical knowledge of programming
bugs
Introducing TEMPEST
Free technology available for
download from
www.hbgary.com
TEMPEST
¡ Connect the inputs with the bugs¡ Verify the exploit¡ Build a working exploit¡ Offensive stance – find working
injection vectors¡ Defines a WORKFLOW
Static backtrace from suspect locations
sprintf call
Blocks of code thatlead to sprintf
‘Self Learning Coverage’
¡ We start with user-supplied data¡ We can detect when decisions are
calculated from user input¡ We can freeze and restore the
program at any point and test newvalues
¡ Thus, we can map how user-controlled values influence statetransitions
Location Coverage
¡ As program is used, if a code blockis visited it will be highlighted‘grey’*
Code
Block
Breakpoint
Process Snapshots
0x00000000
0xFFFFFFFF
VirtualQueryEx
MEM_COMMIT&&NOT PAGE_READONLY&&NOT PAGE_EXECUTE_READ&&NOT PAGE_GUARD&&NOT PAGE_NOACCESS
Fly-By’s & Drill Downs
¡ If we hit code blocks ‘above’ asuspect location we are alerted topotential operations that will causethe target to be exercised
¡ Coverage helps us tune our inputdata to drill down to a targetlocationl This is the fundamental advantage
Tracing
SelectedCode Block
The code blockexits to all thesepoints
Trillian IRC DLL
Signed/Unsignedmismatch insubroutineat 0x1000FE40
Boron Tagging
¡ Traces from known points¡ Breakpoints on suspect calls¡ Can be used as a strategy to skip
large sections of the graphl These become ‘clusters’l We cannot create a spanning tree
graph unless everything is connected
Leap Frogging
recv( … )Change page protectionin order to track access
mov edx, [esi]
lea edx,[esi]
mov [ecx], eax
Leapfrog with Boron
¡ Read memory to find all boronstrings
¡ Set memory breakpoints on allthese locations
¡ Locations are typically re-used¡ Doesn’t always work because
memory is cleared after use
Data Flow Analysis
EAXEDI
HEAP
STACK
HEAP
STACK
Registers
Heap orstack
Write
Read
Graphing Problems
¡ Graph complexity increases with thenumber of back traces
¡ Using tempest on more than a fewtarget points at a time results in ahuge, unwieldy graph
Advanced Graphing
¡ Different graphing algorithms canbe used
¡ Hyperbolic graphs serve better forbrowsing a large number of nodes
All code paths leading to sprintf call in commercial FTP server,information obtained statically
WALRUS
www.caida.org
Filtering the set
¡ Don’t worry about sprintf if theformat string doesn’t contain %s
¡ Don’t worry about off by ones if thesize parameter is less than thestack correction
¡ Don’t worry about anything if thesource data is not obtained fromoutside the function
ID locationsusing static
analysis
Backtrace frompotentially vulnerableAPI call or location
Static traces
ID locationsusing static
analysis Static traces
FUZZ
Locations whichare visited aretagged grey
This is a HIT
- This causesa work item tobe exercised.
Is user-supplied data used in the suspect call?
ID locationsusing static
analysis Static traces
FUZZ
Faults?
Faults?
UnresolvedBranches?
Use Data FlowAnalysis todetermine if
branch iscalculated fromuser-controlled
data
Incompletebranchcoverage
Modify inputfuzzer to
compensate
This location is the nearest fly-by. Tosolve the problem we must visit thislocation and determine what data is beingused to make the branching decision.
In most cases, the value is not directlycontrolled by the fuzzer. This means thatwe must trace back further to determine ifthe value is calculated from user input.This is both tedious and time consuming.
wsprintf that uses%s **
** this graph generated from commercial proxy server (vendor not revealed)
Conclusion
¡ There exists a process to connectuser-input to potentialvulnerabilities
¡ By tracing data and control flow atruntime, a fuzzer can be tuned totarget a location
¡ Only a certain percentage of thosebugs identified statically will beexploitable
Closing Remarks
BugScan is a commercial productthat can be obtained from
www.hbgary.com
Spike is free and can be obtainedfrom
www.immunitysec.com
Closing Remarks
¡ The Tempest debugging system isused internally by HBGary and isnot a commerical product
¡ Many components of the tempestsystem are open source and can beobtained for study
www.hbgary.com
