1 of 37

Binary Exploitation

By. Daniel

​

2 of 37

About Me

  • vulnerability researcher (embedded systems and exploit/fuzzer dev)
  • hobbyist kernel dev (device drivers, memory management, IPC)
  • passionate student who just wants to understand how things work

Slides will be posted immediately after talk in #hackucf channel on slack.

​

DM me if any questions or find me @ the cyberlab/around campus

3 of 37

4 of 37

5 of 37

Ran an executable within the GUEST user space that was able to execute code to spawn a calculator on the HOST! This is a complete sandbox escape with code exec!

https://twitter.com/KiraCxy/status/1080488308478803968?s=20

​

6 of 37

HOW DOES THAT WORK?!?!

7 of 37

What is a binary exploitation?

  • Software is filled with bugs/vulnerabilities !
  • Binary exploitation is the harnessing of those bugs/vulnerabilities to cause unintended or undefined behavior
  • It is a VERY fun and creative process !

In our context a binary is a compiled executable that can be reverse engineered to discover functionality and bugs

8 of 37

Basic reverse engineering

  • Process of learning about a systems operation
  • Software RE
    • lack of source code
    • Involves disassembling the binary and interpreting the assembly
    • Deduce software functionality and control flow
    • Discover vulnerabilities

9 of 37

Reverse engineering is a skill on it own and really deserves its own talk

​

​

​

​

​

​

https://www.youtube.com/watch?v=75gBFiFtAb8

10 of 37

Knowledge for talk

  • Memory: volatile storage; place to store program’s data
  • Memory Address: number that represents a place, or address, in memory
  • OP codes: special numbers that your processor understands as operations
  • Assembly: low level programming language, can be derived from opcodes
  • Pointer: value that points to a location in memory, AN ADDRESS!
  • Stack: Abstract data structure to represent function data in memory

Memory Addresses

OP Codes

Assembly Instructions

11 of 37

Vulnerability 0x01 - Buffer Overflow

Its the overflow of a limited allocated space of memory. Essentially a user controlled input that can exceed the limited of the variable its being stored in

Consequences:

    • User can write to what should be inaccessible regions of memory
    • Crash program
    • Arbitrary redirect flow of execution
    • Execute your own code (code exec)

12 of 37

STACK based buffer overflows

  • The overflow of a local stack variable (variable within a function)
  • What makes them so special?
    • The structure of the stack guarantees an overflow can hit important pointers
    • This can make exploitation easy and reliable

​

13 of 37

The x86 stack

  • The top of the stack is represented by CPU register ESP and base with EBP
  • The stack grows downward in memory address
  • When a function is called
    • Arguments for function are pushed onto the stack
    • Special pointer called the return address is pushed onto the stack
    • EBP is pushed on stack and space is allocated for function variables by setting esp to the value of ebp and subtracting necessary space

int b = 10

int a = 0

EBP

Return address

int result

ESP

Stack for sum(10, 0)

14 of 37

The x86 stack

  • ​

int b = 10

int a = 0

EBP

Return address

int result

ESP

Stack for sum(10, 0)

15 of 37

Return address

​

Exploitation

ESP

‘A’ * 40

(40 A’s)

BBBB

Address of callme()

RET

EBP

Offset between name[32] and EBP

16 of 37

Exploiting without jumping to a callme() function

  • Write malicious opcodes (shellcode) to the stack and return to those
    • The stack needs executable permissions for this to work
  • Return Oriented programming (ROP)
    • Returning to various instructions within the binary that end in a return (gadgets). Jump to instructions that will help craft an malicious payload
    • ROP is kinda vague, essentially just abusing being able to return to any place in the binary (ret2libc, ret2gadget, etc)

​

​

​

Malicious code injection Vs. Malicious computation

17 of 37

Syscalls and shellcode

  • Syscall is an interface between your application and your operating system invoke request a service from your application (ring 3) to your kernel (ring 0)
  • To invoke a syscall:
    • Load desired syscall number into cpu’s accumulator register (eax)
    • Place arguments for call in specific registers (ebx, ecx, …)
    • execute an ‘int 0x80’ instruction
  • The cpu will switch to ring 0 and exec syscall

18 of 37

Syscalls and shellcode

19 of 37

“I drove to UCF for this! This is trivial, show me the real bugs!!!”

20 of 37

This isn't the 90’s, you don't find buffer overflows anymore… Right?

CVE-2018-2686

21 of 37

This isn't the 90’s, you don't find these bugs anymore… Right?

CVE-2018-2686

22 of 37

This isn't the 90’s, you don't find these bugs anymore… Right?

User controls `mapsize` and `* values`

Stack based buffer overflow found in Chromium (enabled on virtualbox with 3D Acceleration)

​

CVE-2018-2686

23 of 37

Bug class 0x02 - Integer Overflow

  • Occurs when an arithmetic operation attempts to create a numeric value that is outside the range a integer type can represent
  • Commonly appears when signed/unsigned ints interact improperly
  • signed integers are represented in memory by two’s complement

​

INT_MAX is the highest value a signed int can hold

24 of 37

My favorite example for a integer overflow!

NOTE: The code and implementation ahead does not represent the exact implementation in the game, its pseudo code to just demonstrate just the integer overflow

25 of 37

Enemy’s in the game

  • For any enemy to be killed in the game, they must have a zero or NEGATIVE health value
  • Enemy’s will have an assigned health (ex. spider.health=100)
  • So if bullets do 45 damage, the spider will die in 4 shots. Killing an enemy is simple.

26 of 37

Killing an unkillable boss with an int overflow

  • Example of the boss attributes and logic:
    • Magmarok.health = 10000
    • If (health < 5000) then, initiate_heal_state
    • Heal_state added 4975 health back to magmarok, can forever heal himself
    • Ice weapons did small increments of and fire weapons healed him in small increments
  • Killing him by inflicting damage is impossible!
  • What if we healed exceeding his base 10000 eventually exceeding a signed integers max value?

27 of 37

Bug class 0x03 - Format string vulnerabilities

  • Occurs when user supplied data is passed as a format string (i.e “%x”) to argument in various library functions like printf
    • printf
    • fprintf
    • sprintf
    • Etc
  • Consequences:
    • Information leak, will search pull arguments from stack that weren't passed
    • Arbitrary write with “%n” specify
    • %n takes an integer pointer as an argument, and will write amount of bytes written so far to the pointer

28 of 37

Bug class 0x03 - Format string vulnerabilities

29 of 37

Bug class 0x03 - Format string vulnerabilities

30 of 37

Bug class 0x03 - Format string vulnerabilities

  • A computer is completely deterministic! There was nothing in the behavior of that format string that was unexpected
  • I guess hacking is more about following the rules then breaking them...

“%x %x”

Return address

Uninitialized argument

Uninitialized argument

31 of 37

Format string vuln in openssh (very old but funny)

32 of 37

A little bit on mitigations

  • Modern solutions have been put in place to make exploiting difficult vulnerabilities difficult and often times impossible
  • Solutions are memory protections and various mitigations

33 of 37

A little bit on mitigations

  • Canaries (compiler level)
    • Default on most compilers, disable with `-fno-stack-protector`
  • DEP/NX (compiler level)
    • Data Execution Prevention or W ^ X
    • No region in memory should be both writable and executable
    • Disable with `-z execstack`
  • ASLR/PIE (kernel level)
    • Address space layout randomization and Position Independent Executable
    • Randomized base address for memory regions, hindering the ability to return to a known fixed location in memory

34 of 37

Resources to learn!

Less is often more!

​

Look through resources and pick one or two that appeals to your style of learning and apply yourself!

​

​

35 of 37

Courses:

Blogs/forums:

Practice:

36 of 37

Books:

  • Practical Binary Analysis, By. Dennis Adriesse (Most up to date, recommend)
  • Hacking the Art of Exploitation Vol.2 (Personal favorite read, but environment is outdated)

​

​

37 of 37

Thanks for your time!

Don’t forget to support hack ucf, they work hard!