Introduction to exploitation

Slides:



Advertisements
Similar presentations
Smashing the Stack for Fun and Profit
Advertisements

Defenses. Preventing hijacking attacks 1. Fix bugs: – Audit software Automated tools: Coverity, Prefast/Prefix. – Rewrite software in a type safe languange.
David Brumley Carnegie Mellon University Credit: Some slides from Ed Schwartz.
Introduction to Information Security ROP – Recitation 5 nirkrako at post.tau.ac.il itamarg at post.tau.ac.il.
CSc 352 Programming Hygiene Saumya Debray Dept. of Computer Science The University of Arizona, Tucson
Computer Security: Principles and Practice EECS710: Information Security Professor Hossein Saiedian Fall 2014 Chapter 10: Buffer Overflow.
CMSC 414 Computer and Network Security Lecture 22 Jonathan Katz.
Review: Software Security David Brumley Carnegie Mellon University.
Foundations of Network and Computer Security J J ohn Black Lecture #30 Nov 26 th 2007 CSCI 6268/TLEN 5831, Fall 2007.
Intro to Exploitation Stack Overflows James McFadyen UTD Computer Security Group 10/20/2011.
1 CHAPTER 8 BUFFER OVERFLOW. 2 Introduction One of the more advanced attack techniques is the buffer overflow attack Buffer Overflows occurs when software.
Assembly תרגול 8 פונקציות והתקפת buffer.. Procedures (Functions) A procedure call involves passing both data and control from one part of the code to.
Netprog: Buffer Overflow1 Buffer Overflow Exploits Taken shamelessly from: netprog/overflow.ppt.
Andrea Bittau, Adam Belay, Ali Mashtizadeh, David Maziéres, Dan Boneh
CMSC 414 Computer and Network Security Lecture 20 Jonathan Katz.
University of Washington CSE 351 : The Hardware/Software Interface Section 5 Structs as parameters, buffer overflows, and lab 3.
Security Exploiting Overflows. Introduction r See the following link for more info: operating-systems-and-applications-in-
Buffer overflows.
Introduction to InfoSec – Recitation 2 Nir Krakowski (nirkrako at post.tau.ac.il) Itamar Gilad (itamargi at post.tau.ac.il)
CAP6135: Malware and Software Vulnerability Analysis Buffer Overflow : Example of Using GDB to Check Stack Memory Cliff Zou Spring 2011.
Assembly, Stacks, and Registers Kevin C. Su 9/26/2011.
Exploiting Buffer Overflows on AIX/PowerPC HP-UX/PA-RISC Solaris/SPARC.
Buffer Overflows : An In-depth Analysis. Introduction Buffer overflows were understood as early as 1972 The legendary Morris Worm made use of a Buffer.
Introduction: Exploiting Linux. Basic Concepts Vulnerability A flaw in a system that allows an attacker to do something the designer did not intend,
Mitigation of Buffer Overflow Attacks
CNIT 127: Exploit Development Ch 4: Introduction to Format String Bugs.
Buffer Overflow CS461/ECE422 Spring Reading Material Based on Chapter 11 of the text.
Introduction to InfoSec – Recitation 2 Nir Krakowski (nirkrako at post.tau.ac.il) Itamar Gilad (itamargi at post.tau.ac.il)
Buffer Overflow Attack-proofing by Transforming Code Binary Gopal Gupta Parag Doshi, R. Reghuramalingam The University of Texas at Dallas 11/15/2004.
Overflow Examples 01/13/2012. ACKNOWLEDGEMENTS These slides where compiled from the Malware and Software Vulnerabilities class taught by Dr Cliff Zou.
Exploitation possibilities of memory related vulnerabilities
Buffer Overflow Proofing of Code Binaries By Ramya Reguramalingam Graduate Student, Computer Science Advisor: Dr. Gopal Gupta.
Buffer Overflow Attack Proofing of Code Binary Gopal Gupta, Parag Doshi, R. Reghuramalingam, Doug Harris The University of Texas at Dallas.
Lecture 9: Buffer Ovefflows and ROP EEN 312: Processors: Hardware, Software, and Interfacing Department of Electrical and Computer Engineering Spring 2014,
Introduction to Information Security ROP – Recitation 5.
Lecture 13 Page 1 CS 236 Online Major Problem Areas for Secure Programming Certain areas of programming have proven to be particularly prone to problems.
Reminder Bomb lab is due tomorrow! Attack lab is released tomorrow!!
SEH overwrite and its exploitability Shuichiro Suzuki Fourteenforty Research Institute Inc. Research Engineer.
Information Security - 2. A Stack Frame. Pushed to stack on function CALL The return address is copied to the CPU Instruction Pointer when the function.
Foundations of Network and Computer Security J J ohn Black CSCI 6268/TLEN 5550, Spring 2013.
Security Attacks Tanenbaum & Bo, Modern Operating Systems:4th ed., (c) 2013 Prentice-Hall, Inc. All rights reserved.
Slides by Kent Seamons and Tim van der Horst Last Updated: Nov 11, 2011.
VM: Chapter 7 Buffer Overflows. csci5233 computer security & integrity (VM: Ch. 7) 2 Outline Impact of buffer overflows What is a buffer overflow? Types.
ROP Exploit. ROP Return Oriented Programming (ROP): is a hacking exploit technique where you exploit buffer overflow to inject a chain of gadgets. Each.
CAP6135: Malware and Software Vulnerability Analysis Buffer Overflow : Example of Using GDB to Check Stack Memory Cliff Zou Spring 2014.
Introduction to Information Security
Overflows Mark Shtern.
Mitigation against Buffer Overflow Attacks
Introduction to Information Security
Protecting Memory What is there to protect in memory?
Introduction to Information Security
CSC 495/583 Topics of Software Security Stack Overflows (2)
CSC 495/583 Topics of Software Security Return-oriented programming
Recitation: Attack Lab
CMSC 414 Computer and Network Security Lecture 21
Summary by - Bo Zhang and Shuang Guo [Date: 03/31/2014]
CS 465 Buffer Overflow Slides by Kent Seamons and Tim van der Horst
Software Security Lesson Introduction
CSC 495/583 Topics of Software Security Format String Bug (2) & Heap
Dr. Si Chen Class15 CSC 495/583 Topics of Software Security Bypassing ASLR/NX with GOT Overwrite Dr. Si Chen
CAP6135: Malware and Software Vulnerability Analysis Buffer Overflow : Example of Using GDB to Check Stack Memory Cliff Zou Spring 2015.
Week 2: Buffer Overflow Part 1.
CTF Class 2018 By: Shawn Stone
Week 2: Buffer Overflow Part 2.
CAP6135: Malware and Software Vulnerability Analysis Buffer Overflow : Example of Using GDB to Check Stack Memory Cliff Zou Spring 2016.
Understanding and Preventing Buffer Overflow Attacks in Unix
CAP6135: Malware and Software Vulnerability Analysis Buffer Overflow : Example of Using GDB to Check Stack Memory Cliff Zou Spring 2013.
Return-to-libc Attacks
Presentation transcript:

Introduction to exploitation James McFadyen

About Me Information Security Engineer and Director of Customer Support at HAWK Network Defense, Inc. Student at UTD Active in local security community 2600 UTDCSG DC214 Experience with penetration testing, big data security, security software development, reverse engineering, exploit development, web application exploitation and development

Introduction to Exploitation Introduce different types of vulnerabilities Introduce some assembly and low level concepts Show vulnerable functions and code, along with fixes Main focus will be stack overflow exploit development and mitigation bypass techniques

Outline What is an exploit? Helpful tools Vulnerabilities Overview Stack Overflows Stack Overflow Exploit Development Protection mechanisms and how to bypass them

What is an exploit? “An exploit (from the verb to exploit, in the meaning of using something to one’s own advantage) is a piece of software, a chunk of data, or sequence of commands that takes advantage of a bug,glitch or vulnerability in order to cause unintended or unanticipated behaviour to occur on computer software, hardware, or something electronic (usually computerised). Such behavior frequently includes such things as gaining control of a computer system or allowing privilege escalation or a denial-of-service attack.” - Wikipedia

Why Should We Care? Exploitation can allow an attacker to gain complete control of a system or a network Can expose sensitive information, such as sensitive customer data, source code, company emails, etc… Vulnerable software can hurt reputation.. Adobe.. Interruption of business continuity

Helpful Tools Linux Windows GDB, gcc, vi, perl/python/ruby, readelf, objdump, ltrace, strace, ropeme, valgrind, metasploit Windows WinDBG, OllyDBG, ImmunityDBG, IDA, Python, Mona (ImmunityDBG plugin)

Vulnerabilities Some vulnerabilities include: Stack Overflow Format String Integer Overflow Sign Extension Heap Overflow Use After Free Null Pointer Dereference

Stack Overflow Overview Local variables, function parameters.. Grows downward General case: Give the program too much input and hijack the instruction pointer (EIP / RIP) Control instruction pointer Remotely or locally execute arbitrary code Don’t necessarily need to control instruction pointer – other registers can be abused

Format String Overview User supplied variable for printf(), or other output function that uses format flags. int printf(const char *format, ...); int fprintf(FILE *stream, const char *format, ...); int sprintf(char *str, const char *format, ...); int snprintf(char *str, size_t size, const char *format, ...); printf(“Hello, %s”, name); // This is ok printf(name); // BAD The user can specify the format flags!

Integer Overflow Overview “An integer overflow condition exists when an integer, which has not been properly sanity checked, is used in the determination of an offset or size for memory allocation, copying, concatenation, or similarly. If the integer in question is incremented past the maximum possible value, it may wrap to become a very small, or negative number, therefore providing a very incorrect value.” – owasp.org Not isolated to “integers”, can be any primitive data type

Integer Overflow If we have an unsigned 8-bit integer, the max value is 255 111111112 = 25510 unsigned char z; z = 255; z++; Wraps to 0. Useful for bypassing certain conditions, allocating too much / too little memory, etc…

Registers Register Description EIP – Instruction Pointer * Next instruction to be executed ESP – extended stack pointer Top of stack EBP – extended base pointer Bottom of stack EAX Accumulator register EBX Base register ECX Counter register EDX Data register ESI Source index EDI Destination Index Note: these are x86 32-bit registers

Stack Overflow strcpy() doesn't check size Vulnerable: char buf[128]; strcpy(buf, userSuppliedString);

Stack Overflow char *strncpy(char *dest, const char *src, size_t n); We have a size, but what if.. strncpy(somebuffer, str, strlen(str)); or.. strncpy(somebuffer, str, sizeof(somebuffer)); Where str is supplied by user Common bug, proper fix: strncpy(somebuffer, str, sizeof(somebuffer)-1);

Stack Overflow char *strncat(char *dest, const char *src, size_t n); Ex: void vulnerable(char *str1, char *str2) { char buf[256]; strncpy(buf, str1, 100); strncat(buf, str2, sizeof(buf)-1); } Fix: strncat(buf, str2, sizeof(buf) - strlen(buf) -1);

Stack Overflow local variables ... arguments... previous stack frame The stack: Low memory addresses ESP local variables ... EBP - x EBP EBP RET EBP + x arguments... previous stack frame High memory addresses

Stack Overflow char buf[100] argc *argv[] 4 bytes EBP RET ESP 100 byte buffer EBP EBP 4 bytes 4 bytes RET 4 bytes argc *argv[]

Stack Overflow Assume user passes input to buf as an argument Example input: $ ./program $(python -c 'print "A" * 108 ')

Stack Overflow char buf[100] argc *argv[] 4 bytes EBP RET ESP RET overwritten 108 bytes ( 0x41 * 108) char buf[100] 100 byte buffer EBP EBP 4 bytes 4 bytes RET 4 bytes argc *argv[]

Stack Overflow In previous slide, ret is overwritten. When this value is popped off the stack, EIP will point to 0x41414141, which is not a valid instruction. Now, to control EIP, subtract 4 and put a new memory address. Example Input: : $ ./program $(python -c 'print "A" * 104 + “\xef\xbe\xad\xde”') The above memory address is fake

Stack Overflow char buf[100] argc *argv[] 4 bytes EBP RET ESP 0xdeadbeef 108 bytes ( 0x41 * 108) char buf[100] 100 byte buffer EBP EBP 4 bytes 4 bytes RET 4 bytes argc *argv[]

Stack Overflow We have 104 bytes for a payload $ ./program $(python -c 'print "A" * 104 + “\xef\xbe\xad\xde” ') We have 104 bytes for a payload Payload can be anything, but for our purpose we would spawn a shell The payload will be fixed size, so when we insert it, we must reduce the # of A's by the size of the payload

Stack Overflow $ ./program $(python -c 'print "A" * 104 + “\xef\xbe\xad\xde” ') If we had a 32 byte payload .. (real payload will not be a bunch of \xff) $ ./program $(python -c 'print "A" * 72 + “\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff” + “\xef\xbe\xad\xde” ') We have adjusted the buffer so the payload will fit We will then have to point EIP (\xef\xbe\xad\xde) to our payload on the stack

Stack Overflow $ ./program $(python -c 'print "A" * 72 + “\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff” + “\xef\xbe\xad\xde” ') “\xef\xbe\xad\xde” would be replaced with the address of our payload EIP will now point to the address of our payload, which will spawn a shell Not very effective... why?

Protection Mechanisms (Windows) DEP – Data execution Prevention Can't execute on the stack /GS Flag – cookie / canary detects if stack has been altered SafeSEH – Structured Exception Handler Try / except, catches exceptions ASLR - Address Space Layout Randomization Randomizes addresses in memory

Protection Mechanisms (Linux) NX – Stack Execute Invalidation Processor feature Like DEP, can't execute on the stack Stack Smashing Protection – cookie / canary Generally enabled by default ASLR - Address Space Layout Randomization Many other compiler protections...

ret2libc (Linux) Return to library If we point EIP to a function in libc, such as system(), we can pass it our own arguments EIP will point to address of system(), next 4 bytes return address, next 4 bytes will be arguments Example: Overwrite EIP with address of system. Call this offset “x” At offset x+4, (right after EIP), we have a return address At x+8, we have the arguments. “/bin/sh” would make great arguments.. ./program $(python -c 'print "A" * 104 + address_of_system + return_address + payload ') Above assumes ‘program’ to be vulnerable, and the necessary offset is 104 system(“bin/sh”) would spawn a shell

Return Chaining This is very useful, can use it in conjunction with the ret2libc methodology to bypass more protection mechanisms, such as ASCII Armoring If we try the ret2libc technique on a binary with ASCII Armor, we see that there are null bytes in the address. Ex: 0x00167100 To evade this protection, we must repeatedly return into the PLT, in a “chain” of instructions

Return Chaining The PLT (Procedure Linkage Table) and the GOT (Global Offset Table) are two important sections When a program calls a function, it calls a function “stub” in the PLT, which then jumps to an address listed in the GOT. On first call to the GOT from PLT, the address for the wanted function will be resolved by dynamic linker and patched into the GOT. Next time the PLT entry jumps to the GOT, it will jump to the actual address.

Return Chaining If we have a libc function that has null bytes, we can take advantage of the PLT and GOT to achieve the same goal as ret2libc char *strcpy(char *dest, const char *src); *dest will be address of GOT for a function *src will be the bytes We have to do this byte at a time… How do we do this?

Return Chaining Repeatedly call strcpy, write a single byte into GOT for a function that gets called in the program Example: replace printf() with system() Since there are null bytes in system, we write one byte at a time of the 4 byte address , null bytes included This changes printf() to system(), so when we call printf() in the program, it actually calls system (since system() probably won’t already exist in the binary) So what does that look like?

Return Chaining Basic example: pseudo-payload to overwrite GOT of printf() with system(): strcpy() + pop pop ret + printf@GOT[0] + 1st byte of system() address strcpy() + pop pop ret + printf@GOT[1] + 2nd byte of system() address strcpy() + pop pop ret + printf@GOT[2] + 3rd byte of system() address strcpy() + pop pop ret + printf@GOT[3] + 4th byte of system() address Once this is accomplished, carry out ret2libc like normal, but instead of executing system(), we point to printf(), since it is overwritten

Return Chaining pop pop ret is an important gadget (Explained later) In an actual payload, it will be a memory address pointing to those instructions The next 4 bytes after strcpy() are the return address Since the return address has pop pop ret, it will execute those instructions, moving past the arguments to strcpy(): dst and src.

ROP Basics Return Oriented Programming This is not an introduction to x86 assembly Uses code that is already in the program’s address space No injection of a payload necessary Evades DEP / NX Many techniques exist to bypass even more protection mechanisms Based on return to library attacks, such as ret2libc

ROP Basics Evolution: Ret2libc, “Borrowed Code Chunks”, ROP Extends beyond scope of ret2lib techniques by allowing the use of “gadgets” Allows loops and conditional branching Take control of stack Especially interested in $esp / $rsp We will rely on the stack pointer rather than instruction pointer for ROP Take sequences of instructions that already exist in the code to control the program

ROP Basics Usefool tools (Linux): Scripting language of choice gdb objdump readelf ROPGadget http://shell-storm.org/project/ROPgadget/ ROPEme

ESP vs. EIP (RSP vs. RIP) EIP points to the current instruction to execute Processor automatically increments EIP upon execution ESP does not get incremented by the processor “ret” increments ESP Note: not limited to ret for stack traversal

Gadgets We will only introduce very basic and limited gadgets, since they are beyond the scope of this presentation. Different instruction sequences ending in “ret” They perform specific tasks, such as moving the stack pointer or writing a value Ex: pop eax; ret Load address at stack pointer into eax Ex: pop eax; pop ebx; ret Load two consecutive words into eax and ebx. Also good for “stepping over” instructions and incrementing the stack pointer Need to understand assembly, these can get very complicated when dealing with logic and control flow

Gadgets We can use gadgets to pivot the stack into an area that we control Ex: mov esp, ebx; ret Strings of these gadgets form chains of instructions Gadgets placed in specific orders can execute specific tasks Only requirement is a sequence of useable bytes somewhere in executable memory region

red – executable Orange - writeable

Gadgets “readelf –s binary” – displays section headers for binary Areas such as .bss are writeable - this allows us to throw payloads here, create custom stacks, etc… .got is also an important place to write, since we can manipulate a program by changing the functions Ex: replace a printf() with exec() in a binary that does not contain exec()

Gadgets Sample objdump output from a Linux binary

Gadgets Orange: memory location Green: opcodes Red: instructions You can see the gadgets can be obtained from within the same binary But do we really want to dig through objdump output?

Gadgets Example: Assume we control the stack, and we need to place a value from our stack into EBX.. If we execute memory address 0x080483b2, it will pop our value from the stack pointer, store it in EBX, which increments the stack pointer, pop the next value into EBP, which increment thes stack pointer, and return, which increments the stack pointer.

References “Source Code Auditing” - Jared Demott “Smashing the stack in 2010” - Andrea Cugliari + Mariano Graziano A Gentle Introduction to Return-Oriented Programming by Tim Kornau - http://blog.zynamics.com/2010/03/12/a-gentle-introduction-to-return-oriented-programming/ PLT and GOT – The key to code sharing and dynamic libraries - http://www.technovelty.org/linux/pltgot.html “Return-oriented Programming: Exploits Without Code Injection” Erik Buchanan, Ryan Roemer… http://cseweb.ucsd.edu/~hovav/talks/blackhat08.html

References “Payload Already Inside: Data Reuse for ROP Exploits” Blackhat 2010, longld @ vnsecurity.net - http://media.blackhat.com/bh-us-10/whitepapers/Le/BlackHat-USA-2010-Le-Paper-Payload-already-inside-data-reuse-for-ROP-exploits-wp.pdf “Practical Return-Oriented Programming” Dino A. Dai Zovi - http://trailofbits.files.wordpress.com/2010/04/practical-rop.pdf “ Linux exploit development part 4 – ASCII armor bypass + return-to-plt” – sickn3ss