auditing binaries for security vulnerabilities

8/14/2019 Auditing Binaries for Security Vulnerabilities

1/49

2001 Halvar Flake

Auditing binaries for security

vulnerabilities

Speech outline (I)

Legal considerations concerning reverse

engineering

Introduction to the topic: The different

approaches to auditing binaries Review of C/C++ programming mistakes

Spotting these mistakes in the binary Demonstration of finding a vulnerability

--- Break ---


2/49

2001 Halvar Flake

Auditing binaries for security

vulnerabilities

Speech outline (II)

Patching the problem away Dealing with Run-time-encrypted binaries

Automated scanning for suspicious constructs Automating the process of reconstructing

structures

Extending structure reconstruction toautomate OOP class reconstruction

Free time to answer questions and discuss

the topic


3/49

2001 Halvar Flake

Legal considerations

Technically, the reverse engineer breaks the licenseagreement between him and the software vendor, as

he is forced to accept upon installation that he will not

reverse engineer the program.

The vendor could theoretically sue the reverse engineer

and revoke the license.

Depending on your local law, there are different waysto defend your situation:


4/49

2001 Halvar Flake

Legal considerations (EU)

EU Law:1991 EC Directive on the Legal Protection of

Computer Programs

Section 6grants the right to decompilation forinteroperability purposes

Section 5.3 grants the right to decompilation for

error correction purposes

Under EU Law, these rights cannot be contracted away


5/49

2001 Halvar Flake

Legal considerations (USA)

US Law:Final form of DMCA includes exceptions to

copyright for:

Reverse engineering for interoperability Encryption research Security testing

One should ask his lawyer if these rights can becontracted away.


6/49

2001 Halvar Flake

Approach A: Stress testingOverly long (or malformed) strings are automatically

generated and supplied to the program

Pros: The process is largely automatic

No specially skilled personnel is needed The stress-testing tool is re-usable

Cons: The protocol has to be known

Complex conditions will be missed


7/49

2001 Halvar Flake

Approach B: Tracing InputA reverse engineer reads the program from the

point where it receives input on and analyzes thecode to find possible weaknesses

Pros:

Even very complex conditions are found

Cons:

Auditor needs to be highly skilled Nearly infeasible for large applications Very time consuming since one will be

reading a lot of irrelevant `tentacles


8/49

2001 Halvar Flake

Approach C: Finding suspicious

constructs and reading backwards

Certain constructs which appear suspicious aredetected, and a reverse engineer then manually

analyzes the threat they pose

Pros:

A lot less time consuming than approach B The process of detecting suspicious

constructs can be automated Fairly complex conditions can be found

Cons: Some vulnerabilities will be missed Needs highly specialized auditor


9/49

2001 Halvar Flake

Blackhatvs Whitehatauditing

Blackhat: Wants the fastest way to find an unknown

vulnerability Doesnt care if he misses some problems

Only needs to repeat the process if thevulnerability was fixed

Whitehat: Wants security, so he needs to read all code

Has to repeat the process with every upgrade Has to continue after he has found something

The Blackhat is at an advantage here


10/49

2001 Halvar Flake

Tools the auditor needsIDA Pro by Ilfak Guilfanov

www.datarescue.com

Can disassemble x86, SPARC, IA64, MIPS and much more ... Includes a powerful scripting language Can recognize statically linked library calls Features a powerful plug-in interface

Features CPU Module SDK for self-developed CPU modules Automatically reconstructs arguments to standard calls via

type libraries, allows parsing of C-headers for adding new

standard calls & types Great technical support

... much more ...


11/49

2001 Halvar Flake

strcpy() and strcat()

Old news:

strcpy() andstrcat() copying dynamic data

into any kind of fixed-size buffer are inherently

suspicious

C/C++ auditing recap


12/49

2001 Halvar Flake

sprintf() and vsprintf()

Old news:

Sincesprintf() can expand an arbitrary string

using the `%s` format character, any call to

sprintf()/vsprintf() which expands dynamic data

into a fixed-size buffer has to be consideredsuspicious.



13/49

2001 Halvar Flake

The *scanf() function family

As *scanf() parses data of dynamic origininto fixed buffers by using the %s` format

character, any *scanf() call which targets a fixed-

size buffer with a `%s` format character is

suspicious



14/49

2001 Halvar Flake

The strncpy()-pitfall (I)

While strncpy supports size checking, it does not

guarantee NUL-termination of the destination buffer.So in cases where the code includes something like

strncpy(destbuff, srcbuff, sizeof(destbuff));

problems will arise.



15/49

2001 Halvar Flake

The strncpy()-pitfall (II)


Source string \x0 data

After copying the source into a smaller buffer, the

destination string is not properly terminated any more.

Destination string data with a \x0 somewhere

Any subsequent operations which expect the string to

be terminated will work on the data behind our original

string as well.


16/49

2001 Halvar Flake

The strncat()-pitfall (I)


As withstrncpy(),strncat() supports size checking,

but guarantees the proper termination of the string

after the last byte has been written.

If the buffer that is targeted is the first one which

was declared in the offending function, it is possible

to overwrite theframe pointerand gaining control

one function layer outwards.


17/49

2001 Halvar Flake

The strncat()-pitfall (II)


Buffer to which

we append

saved_EBP

saved_EIP

saved_EBPs lowest byte is set to 0x00

Function epilogue: mov esp, ebp


18/49

2001 Halvar Flake

The strncat()-pitfall (III)


saved_EBP

saved_EIP

Function epilogue: pop ebp


19/49

2001 Halvar Flake

The strncat()-pitfall (IV)


saved_EIP Function epilogue: ret

The value in EBP (theframe pointer) is now our modified value !


20/49

2001 Halvar Flake

The strncat()-pitfall (V)


User-supplied data

saved_EBP

saved_EIP

Next function epilogue: mov esp, ebp

ESP slides upwards (as its lowest order byte was

overwritten) into the user-supplied data. We cannow supply a new return address to gain control

ESP should be here ...

.. but it lands lands here ...


21/49

2001 Halvar Flake

The strncat()-pitfall (VI)


Furthermore, the fact thatstrncat() has to deal with

dynamic values for the len parameter increases the

danger of signedness misconceptions:

strncpy(buff, userdata, sizeof(buff));

strncat(buff, userdata2, sizeof(buff)-strlen(buff)-1);

Fills buff so thatstrlen(buff) = sizeof(buff)

len is pushed to 1 which is 0xFFFFFFF


22/49

2001 Halvar Flake

Cast screwups (I)


void func(char *dnslabel)

{

char buffer[256];

char *indx = dnslabel;

int count;

count = *indx;

buffer[0] = '\x00';

while (count != 0 && (count + strlen (buffer)) < sizeof (buffer) - 1)

{strncat (buffer, indx, count);

indx += count;

count = *indx;

}

}

First byte at *dnslabel is 0x80 = -128

Gets expanded to 0xFFFFF80

signed comparison passes

arbitrary length string is appended


23/49

2001 Halvar Flake

Format string vulnerabilities


Any call that passes user-supplied input directly to a

*printf()-family function is dangerous. These calls can

Also be identified by their argument deficiency.

Consider this code:

printf(%s, userdata);

printf(userdata); Argument deficiency


24/49

2001 Halvar Flake

-- x86 assembly recap --

void *memcpy(void *dest, void *src, size_t n);

Assembly representation:

push 4

mov eax, unkn_40D278

push eax

lea eax, [ebp+var_458]

push eaxcall _memcpy


25/49

2001 Halvar Flake

Disassembly:strcpy()/strcat()

This call targets a stack buffer

The source is variable, not a static string


26/49

2001 Halvar Flake

Disassembly:sprintf()/vsprintf()

Target buffer is a stack buffer

Expanded strings are not static and not fixed in length

Format string containing %s

Disassembly: The * f()


27/49

2001 Halvar Flake

Disassembly: The *scanf()

function family

Format string contains %s

Data is parsed into stack buffers

Disassembly: The


28/49

2001 Halvar Flake

Disassembly: The

strncpy()/strncat() pitfall (I)

If the source is larger than n (4000 bytes),

no NULL will be appended

Copying data into a stack buffer again ...

Disassembly: The


29/49

2001 Halvar Flake

Disassembly: The

strncpy()/strncat() pitfall (II)

The target buffer is only n bytes long

Disassembly: The strncat()


30/49

2001 Halvar Flake

Disassembly: Thestrncat()

pitfall

Dangerous handling oflen parameter


31/49

2001 Halvar Flake

Disassembly: Cast screwups

Does the function accepts asize_tparameter forcopying data into a buffer ? (e.g.strncpy(), strncat(),

fgets()) Is thesize_tparameter a dynamic value and not

hardcoded ? Is thesize_tparameter at any point loaded using a

movsx instruction (move with sign extend) ? Is anything substracted from the size_t parameter

before it gets passed to the function ?

Disassembly: Format String


32/49

2001 Halvar Flake


vulnerabilities

Argument deficiency

Format string is a dynamic variable



33/49

2001 Halvar Flake


vulnerabilities

Argument deficiency

Format string is a dynamic variable


34/49

2001 Halvar Flake

Demonstration of finding

vulnerabilities by manuallyauditing binaries


35/49

2001 Halvar Flake

-- BREAK --


36/49

2001 Halvar Flake

Patching the problem away (I)

PE File Header

.textsection

containing code

other sections

containing data

...

Zero-padded tothefile alignment

(usually 0x200)so-called `Cave`

so-called Cave


37/49

2001 Halvar Flake

Patching the problem away (II)

.textsectioncontaining code

`Cave` where we have

put our new code

jmping into our code

passing control back

D li ith ti


38/49

2001 Halvar Flake

Dealing with runtime

encryption (I)PE File Header

.textsection

containing code

.rsrc section

containing code

.data section

containing data

descrambling code

Entry point

1. The de-scrambling code is added

to the end of the executable

2. The entry point is moved to the

descrambler

3. The contents of the file are

scrambled

Entry point

D li ith ti


39/49

2001 Halvar Flake

Dealing with runtime

encryption (II)Steps to undertake:

Trace through the descrambler until it passes control

back to the application

Repair the damage done to the executable structure bythe scrambler/descrambler/executable loader

Dump the memory to disk

Very time consuming !

Automated tools exist to do this for many scramblers

(e.g. IceDump)

A i h i f


40/49

2001 Halvar Flake

Automating the scanning for

suspicioussprintf()-calls

Criteria for suspicioussprintf() calls:

Does the call expand data using a `%s`format

character without size checking ? Does the call expand a non-static string

through the %s? Does the call suffer from an argument

deficiency ? If so, is the format string dynamic or static ?

Demonstration script: sprintf.idc

A i h i f


41/49

2001 Halvar Flake


suspiciousstrncpy()-calls

Criteria for suspiciousstrncpy() calls:

Is thesize_tparameter smaller or equal to thesize of the target buffer ?

Does the call copy dynamic data into a stack

buffer ?

Demonstration script: strncpy.idc

A i h i f


42/49

2001 Halvar Flake


format string vulnerabilities (I)

As we will frequently encounter wrapper functions that

implementprintf() like functionality using either

vsprintf() orvsnprintf(), it is desirable to have a script that

can be used for all functions. The data it needs to get fromthe auditor is:

1. The address of the function that gets analyzed

2. The proper minimum stack correction of that function

3. The argument number of the format string

A i h i f


43/49

2001 Halvar Flake


format string vulnerabilities (II)

The criteria the script should then apply are:

Is the stack correction smaller than our suppliedminimum value ?

Is the format string dynamic or static ?

Demonstration script: format.idc

R h d t


44/49

2001 Halvar Flake

Reasons why we need to

reconstruct structures

Many applications store data in large structures which are

passed around between functions. The information about

the layout of these structures is lost during the compilation.

This is bad for the reverse engineer for a variety of reasons:

Without knowing how large target/source buffers are,

it becomes very hard to evaluate the danger posed by a

suspicious construct

Many overflows happen within structures. Withoutknowing what were overwriting, it becomes hard to see

if a condition is exploitable at all

D t ti f l


45/49

2001 Halvar Flake

Demonstration of manual

structure reconstruction

While the manual reconstruction of structures using IDAs

built-in capabilities is great for `real` reverse engineering,

it takes too much time when only looking for suspicious

constructs.

Automated ways to at least reconstruct the structure

member sizes is desirable.

A t t d t t


46/49

2001 Halvar Flake

Automated structure

reconstructionFrequently, we have a pointer to a structure as a local variable

in a function. What we want the script to do is:

Trace through the entire function and find all places

where this pointer is loaded into a register Each time the pointer is loaded, trace the code until the

register is overwritten. Each time anything is referenced

relative to the register, retrieve that value

Use the retrieved values to add members to a structure,thus reconstructing accesses to it

Demonstration script: bas_objrec.idc

Wh i thi i t ti h


47/49

2001 Halvar Flake

Why is this interesting when

auditing IIS ?Because it consists mostly of OOP code, and OOP code is

notoriously annoying to read in the disassembly.

Now, automated structure reconstruction can be of great

interest when auditing OOP code:

The more functions we can analyze which access the

same structure, the more exact our reconstruction of that

structure will be

A class is nothing but a collection of functions which allwork with the same structure

C id ti i


48/49

2001 Halvar Flake

Considerations concerning

class reconstruction

Method1(...)

Method2(...)

Method3(...)

Method4(...)

Method5(...)

vTable

Every vTable entry points to

a function which accesses thesame structure via the this

pointer. The vTable therefore

gives us a list of functions

we can use to reconstruct the

class data layout.


49/49

Any Questions ?

auditing binaries for security vulnerabilities

Documents