Exploitation techniques and fuzzing

Exploitation Techniques and
Fuzzing

Index
• Vulnerability
• Classification of Vulnerabilities
• What is fuzzing?
• What data can be fuzzed?
• What does fuzzed data look like?
• When (not) to fuzz?
• Two approaches and a basic methodology
• Advanced techniques
• Unsolved challenges

Vulnerability
• ISO 27005 defines vulnerability as:
• A weakness of an asset or group of assets that can be exploited by one or more
threats.
• where an asset is anything that has value to the organization, its business
operations and their continuity, including information resources that support
the organization's mission.
• IETF RFC 2828 define vulnerability as:
• A flaw or weakness in a system's design, implementation, or operation and
management that could be exploited to violate the system's security policy.

Vulnerability
• A vulnerability is a weakness which can be exploited by a Threat Actor, such as
an attacker, to perform unauthorized actions within a computer system.
• To exploit a vulnerability, an attacker must have at least one applicable tool or
technique that can connect to a system weakness.
• A security risk is often incorrectly classified as a vulnerability.
• The risk is the potential of a significant impact resulting from the exploit of a
vulnerability.
• Then there are vulnerabilities without risk: for example when the
affected asset has no value.

Vulnerability
• A vulnerability with one or more known instances of working and fully
implemented attacks is classified as an exploitable vulnerability—a vulnerability
for which an exploit exists.
• The window of vulnerability is the time from when the security hole was
introduced or manifested in deployed software, to when access was removed, a
security fix was available/deployed, or the attacker was disabled—Example:-
zero-day attack.

Classification of Vulnerability
• Vulnerabilities are classified according to the asset class they are related to:
• Hardware
• susceptibility to humidity
• susceptibility to dust
• susceptibility to soiling
• susceptibility to unprotected storage
• Software
• insufficient testing
• lack of audit trail
• design flaw

Classification of Vulnerability
• Network
• unprotected communication lines
• insecure network architecture
• Personnel
• inadequate recruiting process
• inadequate security awareness
• Physical site
• area subject to flood
• unreliable power source

Privilege Escalation Vulnerability
• Privilege escalation is the act of exploiting a bug, design flaw or configuration
oversight in an operating system or software application to gain elevated access
to resources that are normally protected from an application or user.
• The result is that an application with more privileges than intended by
the application developer or system administrator can
perform unauthorized actions.
• Privilege escalation occurs in two forms:
• Vertical privilege escalation
• Horizontal privilege escalation

Vertical Privilege Escalation
• It is also known as privilege elevation.
• Where a lower privilege user or application accesses functions or content reserved
for higher privilege users or applications (e.g. Internet Banking users can access
site administrative functions or the password for a smartphone can be bypassed.)
• This type of privilege escalation occurs when the user or process is able to obtain
a higher level of access than an administrator or system developer intended,
possibly by performing kernel-level operations.
• Examples
• some cases, a high-privilege application assumes that it would only be provided
with input matching its interface specification, thus doesn't validate this input.
Then, an attacker may be able to exploit this assumption, in order to run
unauthorized code with the application's privileges:

• Examples
• Some Windows services are configured to run under the Local System user
account. A vulnerability such as a buffer overflow may be used to execute
arbitrary code with privilege elevated to Local System. Alternatively, a system
service that is impersonating a lesser user can elevate that user's privileges if
errors are not handled correctly while the user is being impersonated (e.g. if
the user has introduced a malicious error handler)
• Under some legacy versions of the Microsoft Windows operating system, the
All Users screensaver runs under the Local System account – any account that
can replace the current screensaver binary in the file system or Registry can
therefore elevate privileges.

Horizontal privilege escalation
• Where a normal user accesses functions or content reserved for other normal users
(e.g. Internet Banking User A accesses the Internet bank account of User B).
• The result is that the application performs actions with the same but different
security context than intended by the application developer or system
administrator; this is effectively a limited form of privilege escalation
(specifically, the unauthorized assumption of the capability of impersonating other
users).

• Examples:
• This problem often occurs in web applications. Consider the following
example:
• User A has access to their own bank account in an Internet Banking
application.
• User B has access to their own bank account in the same Internet Banking
application.
• The vulnerability occurs when User A is able to access User B's bank account
by performing some sort of malicious activity.
• Potential web application vulnerabilities or situations that may lead to this
condition include:
• Session fixation
• Cross-site Scripting
• Easily guessable passwords
• Theft or hijacking of session cookies
• Keystroke logging

Win32k Elevation of Privilege Vulnerability (CVE-2015-0057)
• This vulnerability involving a flaw in a GUI component of Windows 10—
namely the scrollbar element—allows a threat actor to gain complete control
of a Windows machine through privilege escalation.
• win32k.sys in the kernel-mode drivers in Microsoft Windows Server 2003
SP2, Windows Vista SP2, Windows Server 2008 SP2 and R2 SP1, Windows 7
SP1, Windows 8, Windows 8.1, Windows Server 2012 Gold and R2, and
Windows RT Gold and 8.1.

Buffer overflow
• A buffer overflow, or buffer overrun, is an anomaly where a program, while
writing data to a buffer, overruns the buffer's boundary and overwrites
adjacent memory locations.
• Buffers are areas of memory set aside to hold data, often while moving it from one
section of a program to another, or between programs.
• Exploiting the behaviour of a buffer overflow is a well-known security exploit.
• The famed Morris worm in 1988 used this as one of its attack techniques.

What are buffer overflows?
• Suppose a web server contains a function:
void func(char *str) {
char buf[128];
strcpy(buf, str);
do-something(buf);
}
• When the function is invoked the stack looks like:
• What if *str is 136 bytes long? After strcpy:
strret-addrsfpbuf
top
of
stack
str
top
of
stack
*str ret

Many unsafe C lib functions
strcpy (char *dest, const char *src)
strcat (char *dest, const char *src)
gets (char *s)
scanf ( const char *format, … )
• “Safe” versions strncpy(), strncat() are misleading
• strncpy() may leave buffer unterminated.
• strncpy(), strncat() encourage off by 1 bugs.

Buffer Overflow Exploitation
• Stack-based exploitation
• Heap-based exploitation
• Barriers to exploitation
• Practicalities of exploitation
• NOP sled technique
• The jump to address stored in a register technique

Dangling pointer
• Dangling pointers arise during object destruction, when an object that has an
incoming reference is deleted or deallocated, without modifying the value of the
pointer, so that the pointer still points to the memory location of the deallocated
memory.
• The system may reallocate the previously freed memory, and if the program
then dereferences the (now) dangling pointer, unpredictable behaviour may result,
as the memory may now contain completely different data.

• Wild pointers arise when a pointer is used prior to initialization to some known
state, which is possible in some programming languages.
• They show the same erratic behaviour as dangling pointers, though they are less
likely to stay undetected because many compilers will raise a warning at compile
time if declared variables are accessed before being initialized.

Code injection
• Code injection is the exploitation of a computer bug that is caused by processing
invalid data. Injection is used by an attacker to introduce (or "inject") code into a
vulnerable computer program and change the course of execution.
• The result of successful code injection can be disastrous, for example by
allowing computer worms to propagate.
• Code injection vulnerabilities (injection flaws) occur when an application sends
untrusted data to an interpreter.

• Injection flaws are most often found in SQL, LDAP, XPath, or NoSQL queries;
OS commands; XML parsers, SMTP headers, program arguments, etc. Injection
flaws tend to be easier to discover when examining source code than via testing.
• Injection can result in data loss or corruption, lack of accountability, or denial of
access. Injection can sometimes lead to complete host takeover.
• Code injection techniques are popular in system hacking or cracking to gain
information, privilege escalation or unauthorized access to a system.

Examples:
• SQL Injection
• HTML script injection
• Dynamic evaluation vulnerabilities
• Object injection
• Remote file injection
• Format Specifier Injection
• Shell injection

What is fuzzing ?
• Feed target automatically generated malformed data designed to trigger
implementation flaws
• A fuzzer is the programmatic construct to do this
• A fuzzing framework typically includes library code to:
• Generate fuzzed data
• Deliver test cases
• Monitor the target

• Publicly available fuzzing frameworks:
• Spike, Peach Fuzz, Sulley, Schemer
• Requirement of Microsoft’s Secure Development Lifecycle program
• Still a long way to go - many vendors do no fuzzing!

What data can be fuzzed?
• Virtually anything!
• Basic types: bit, byte, word, dword, qword
• Common language specific types: strings, structs, arrays
• High level data representations: text, xml

Where can data be fuzzed?
• Across any security boundary, e.g.:
• An RPC interface on a remote/local machine
• HTTP responses & HTML content served to a browser
• Any file format, e.g. Office document
• Data in a shared section
• Parameters to a system call between user and kernel mode
• HTTP requests sent to a web server
• File system metadata
• ActiveX methods
• Arguments to SUID binaries

What does fuzzed data consist of?
• Fuzzing at the type level:
• Long strings, strings containing special characters, format strings
• Boundary case byte, word, dword, qword values
• Random fuzzing of data buffers
• Fuzzing at the sequence level
• Fuzzing types within sequences
• Nesting sequences a large number of times
• Adding and removing sequences
• Random combinations
• Always record the random seed!!

When to fuzz?
• Fuzzing typically finds implementation flaws, e.g.:
• Memory corruption in native code
• Stack and heap buffer overflows
• Un-validated pointer arithmetic (attacker controlled offset)
• Integer overflows
• Resource exhaustion (disk, CPU, memory)
• Unhandled exceptions in managed code
• Format exceptions (e.g. parsing unexpected types)
• Memory exceptions
• Null reference exceptions
• Injection in web applications
• SQL injection against backend database
• LDAP injection
• HTML injection (Cross-site scripting)
• Code injection

When not to fuzz
• Fuzzing typically does not find logic flaws
• Malformed data likely to lead to crashes, not logic flaws
• e.g. Missing authentication / authorization checks
• Fuzzing does not find design/repurposing flaws
• e.g. A sitelocked ActiveX control with a method named “RunCmd”.
• However transitions in a state machine can be fuzzed...
• Send well-formed requests out of order
• But how to know when you’ve found a bug?

Two approaches
“Dumb” “Smart”
• Fuzzer lacks contextual informational
about data it is manipulating
• May produce totally invalid test cases
• Up and running fast
• Find simple issues in poor quality
code bases
• Fuzzer is context-aware
• Can handle relations between
entities, e.g. block header lengths,
CRCs
• Produces partially well-formed test
cases
• Time consuming to create
• What if protocol is proprietary?
• Can find complex issues

Pseudo-code for dumb fuzzer
for each {byte|word|dword|qword} aligned location in file
for each bad_value in bad_valueset
{
file[location] := bad_value
deliver_test_case()
}

...
o_jpeg = fz3AddObjectToList( NULL, TYPE_BYTE, PTR(0xff), 1 ); // new header
fz3AddObjectToList( o_jpeg, TYPE_BYTE, PTR(0xd8), 1 ); // unknown type
(start of file?)
fz3AddObjectToList( o_jpeg, TYPE_BYTE, PTR(0xff), 1 ); // new header
fz3AddObjectToList( o_jpeg, TYPE_BYTE, PTR(0xe0), 1 ); // extension app0
marker segment
o_jfif_len = fz3AddObjectToList( o_jpeg, TYPE_WORD, BE_W(0x10), 2 ); // length
o_jfif = fz3AddObjectToList( o_jpeg, TYPE_COLLECTION, NULL, 0 );
o_jfif_dat = fz3AddObjectToList( NULL, TYPE_COLLECTION, NULL, 0 );
fz3AddObjectToList( o_jfif_dat, TYPE_STATIC, "JFIF", 5 ); // APP0 marker
fz3AddObjectToList( o_jfif_dat, TYPE_WORD, BE_W(0x0102), 2 ); // version
fz3AddObjectToList( o_jfif_dat, TYPE_BYTE, PTR(0), 1 ); // units
fz3AddObjectToList( o_jfif_dat, TYPE_WORD, BE_W(0x64), 2 ); // x density
fz3AddObjectToList( o_jfif_dat, TYPE_WORD, BE_W(0x64), 2 ); // y density
fz3AddObjectToList( o_jfif_dat, TYPE_BYTE, PTR(0), 1 ); // x thumbnail
fz3AddObjectToList( o_jfif_dat, TYPE_BYTE, PTR(0), 1 ); // y thumbnail
…
fz3AddAdditionalDataToObject( o_jfif, TYPE_COLLECTION, (BYTE *)o_jfif_dat, sizeof(object *) );
…
fz3SetObjectCallback( o_jfif_len, JPEG_set_length, o_jfif );
…
Sample config for smart fuzzer (1)

Sample config for smart fuzzer (2)

Two approaches cont.
• Which approach is better?
• Depends on:
• Time: how long to develop and run fuzzer
• [Security] Code quality of target
• Amount of validation performed by target
• Can patch out CRC check to allow dumb fuzzing
• Complexity of relations between entities in data format
• Don’t rule out either!
• My personal approach: get a dumb fuzzer working first
• Run it while you work on a smart fuzzer

Fuzzing in practice: the basic steps
Monitor Target
Generate next test case
Deliver test case
Target
crashed? Save crash dump
Any more
test cases?
Finish
Start

Monitoring the target
1. Attach a debugger
• Leverage existing functionality
• Scripting, logging, crash dumps etc.

2. Write your own debugger
• Actually easy to do
• Lightweight, fast, full control
C++
BOOL WINAPI WaitForDebugEvent(
__out LPDEBUG_EVENT lpDebugEvent,
__in DWORD dwMilliseconds
);
typedef struct _DEBUG_EVENT { /* de */
DWORD dwDebugEventCode;
DWORD dwProcessId;
DWORD dwThreadId;
union { EXCEPTION_DEBUG_INFO Exception;
CREATE_THREAD_DEBUG_INFO CreateThread;
CREATE_PROCESS_DEBUG_INFO CreateProcess;
EXIT_THREAD_DEBUG_INFO ExitThread;
EXIT_PROCESS_DEBUG_INFO ExitProcess;
LOAD_DLL_DEBUG_INFO LoadDll;
UNLOAD_DLL_DEBUG_INFO UnloadDll;
OUTPUT_DEBUG_STRING_INFO DebugString; }
u; } DEBUG_EVENT, *LPDEBUG_EVENT;

3. Monitor resources:
• File, registry, memory, CPU, logs

Deliver the test case
1. Standalone test harness
• E.g. to launch to client application and have it load fuzzed file format
2. Instrumented client
• Inject function hooking code into target client
• Intercept data and substitute with fuzzed data
• Useful if:
• State machine is complex
• Data is encoded in a non-standard format
• Data is signed or encrypted

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.
• 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…’)

• 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?

• Recent advances – Microsoft !Exploitable
• WinDbg extension to determine exploitability
• Does lightweight taint analysis
• Uses meta-instructions (STACK_PUSH, DATA_MOVE etc.)
• Demoed at CanSec West conference, March 2009

A quick diversion
• These days you can get paid for finding vulnerabilities:
• iDefense, Tipping Point, Pwn2Own
• Write a fuzzer, find bugs.
• Here’s how to get started:
• Download FileFuzz (iDefense)
• Pick a media application and find some samples
• Fuzz! You will find bugs…

A quick diversion
• Code execution in Internet Explorer via 3rd party ActiveX control

A quick diversion
• Vulnerability in widely used enterprise-level software

A quick diversion
• Remotely exploitability vulnerability in critical infrastructure/the core OS

A quick diversion
• Why isn’t everyone in the security community rich…
• The best (= $$$) targets are the most secure
• Few remote vulnerabilities in Vista
• Even less in IIS or Apache
• Clued up vendors are fuzzing:
• Windows Vista file fuzzing effort in numbers:
• 350M iterations total
• 250+ file parsers fuzzed
• 300+ issues fixed

Advanced fuzzing
• Problems with our basic model:
• Fuzzer and target are not in sync
• Fuzzer has no feedback mechanism
• We have no visibility into fuzzer’s effectiveness
• Revised model:
• Send good requests at regular intervals to check health of target
• Fuzzer is able to control target debugger
• Use a code coverage build if possible

Advanced fuzzing
• Fuzzer issues debugger commands
• Can restart target
• Can handle resource exhaustion bugs, e.g. 100% CPU
• Can save callstack, crash dump etc.
• Fuzzing isolated states in a state machine
• Save and restore “state” of process
• See Hoglund, McGraw “Exploiting Software”
• Constrain execution to a single state with breakpoints
• Substitute real data for fuzzed data
• But how to handle handles?

Example
• Microsoft Exchange Remote Code Execution
• Critical Microsoft hotfix, MS06-003 (Heasman & Litchfield)
• Run code on a mail server with a single email!
• Bonus: same bug affected Outlook 2003!
• We found this by fuzzing email…
• Rich text email often has a “winmail.dat” attachment
• This is a binary Transport Neutral Encapsulation Format
• Lets fuzz it!

Example
• TNEF is a Tag Length Value (TLV) format
• Our bug: triggered by tag length of 0xFFFFFFFF for certain properties
• Any ideas what was going on?
• Integer overflow!
• Small memory allocation followed by a large memcpy
• We trash the heap, overwriting heap control structures
• End up with arbitrary DWORD overwrite which we use to get code execution
0xFFFFFFFF + 1 = 0

Example
• Interesting asides: 5 years earlier…
• Bugtraq Security Mailing List - August 2000
• "As a side note it would be an interesting excercise to see if Outlook is
susceptible to a message with a malformed winmail.dat attached. One could
theoretically use winmail.dat to hit on holes in either Outlook itself, or the
Outlook RTF engine"
• February 2009 - MS09-003 “Vulnerabilities in Microsoft Exchange Could Allow
Remote Code Execution”
• TNEF again!

Existing challenges
• Fuzzing likely to trigger same bug repeatedly
• Automatically remove duplicate bugs
• Compare call stacks, register values, memory locations
• What if they are trashed?
• Or slightly different?
• Seems like this problem would benefit from a fuzzy approach
• How to implement code coverage on a binary?
• Without degrading performance
• How to effectively use code coverage to direct fuzzing ?

Existing challenges
• How to measure effectiveness of a fuzzer?
• Number of test cases?
• Number of bugs?
• Severity of bugs?
• % Code coverage?
• How many test cases to run?
• How to balance complexity vs. time
constraints?

Exploitation techniques and fuzzing

More Related Content

What's hot

Similar to Exploitation techniques and fuzzing

More from Prachi Gulihar

Recently uploaded

Exploitation techniques and fuzzing

Editor's Notes