Protection Mechanisms

6048CEM Week 3

Introduction

Introduction

  • Look at Protection Mechanisms that can effect exploit dev
    • “High Level” Application based
    • “Low Level” Binary / Kernel Based

Why

  • Links to CW1

High Level

  • Application (can be hardware)
  • Outside of the OS / Binary
    • Firewalls
    • AV

Low Level

  • Inside the OS / Kernel
    • ASLR / PIE etc.
  • Inside the Binary
    • Canaries / NX etc.

Firewalls

Firewalls

  • A lot of the time we assume we are past them
  • Can have a impact on exploit dev
    • Services we want to break are behind them
    • Filter Bind / Reverse shells

Firewall

  • Will Focus on “Packet Filtering” Type
  • Stateful / NGFW exist, and add more complexity

Firewall

  • Filter Network Traffic (Ports, Protocols)
  • Two main approaches
    • Allow List
    • Deny List

Firewall

  • Checks network traffic, compares to ruleset
    • If in ruleset either drop / allow packet.

Firewall

  • General Observations
    • Can be less restrictive once we are in
      • Shell Direction
    • Filter based on Ports can be Spoofed
      • Evil over HTTP

Firewall and Exploit Dev

  • Have to bypass to get to our exploit
  • Can effect IO and any network based communications

Antivirus

Antivirus

  • Aims to Detect malware at download / runtime
    • Quarantine or Stop execution of a program
  • Can be static of Dynamic analysis

AV: Signature Based

  • Static analysis of sequences of bytes in a file
    • Hash or Byte Stream
  • Compares to a database of known signatures

/bin/sh Shellcraft

    xorq    %rdx, %rdx
    movq    $0x68732f6e69622fff,%rbx
    shr $0x8, %rbx
    push    %rbx
    movq    %rsp,%rdi
    xorq    %rax,%rax
    pushq   %rax
    pushq   %rdi
    movq    %rsp,%rsi
    mov $0x3b,%al   # execve(3b)
    syscall

    pushq   $0x1
    pop %rdi
    pushq   $0x3c       # exit(3c)
    pop %rax
    syscall

/bin/sh Pwntools

    /* execve(path='/bin///sh', argv=['sh'], envp=0) */
    /* push b'/bin///sh\x00' */
    push 0x68
    push 0x732f2f2f
    push 0x6e69622f
    mov ebx, esp
    /* push argument array ['sh\x00'] */
    /* push 'sh\x00\x00' */
    push 0x1010101
    xor dword ptr [esp], 0x1016972
    xor ecx, ecx
    push ecx /* null terminate */
    push 4
    pop ecx
    add ecx, esp
    push ecx /* 'sh\x00' */
    mov ecx, esp
    xor edx, edx
    /* call execve() */
    push SYS_execve /* 0x3b */
    pop eax
    int 0x80

AV: Signature Based

  • Downsides
    • Can only detect known signatures
    • Many Different approaches to getting a shell
    • Obfuscation / Encryption

AV: Heuristics

  • Looks for Common behaviour in “Family” of malware
    • “Junk” Data
    • Groups of Instruction Calls

AV: Heuristics

  • Doesn’t need such an extensive database
    • What is Suspicious in the file
    • Compare to a Threshold

Heuristics

Building a /bin/sh string

Shell-storm

xorq    %rdx, %rdx
movq    $0x68732f6e69622fff,%rbx

Pwntools

push 0x68
push 0x732f2f2f
push 0x6e69622f

Heuristics

Exec Syscall

mov $0x3b,%al   # execve(3b)
syscall
push SYS_execve /* 0x3b */
pop eax
int 0x80

Behaviour based detection

  • Check for suspicious behaviour in the files
    • Open Network Connections
    • Drop Shells
    • Run Crypto

Behaviour

  • Can be Static or Dynamic
  • Fits well with sand boxing

Scanning

  • Periodic
  • On Demand

Sandbox

  • Run the program in a separate “Safe” environment
  • Greater detection of malware
    • Encoding / Encryption will happen

AV and Exploit Dev

  • Conceal payload from scanner
    • Encoding or Encryption
    • Custom Payloads
  • Sandbox makes this harder due to decode / decrypt

OS and Binary Level Protections

OS / Binary Level Protection

  • Protection provided as part of the Kernel or OS
  • Can also be Features turned on at compile time

NX Stack / DEP

  • Around since ~1997
  • Marks data sections of memory non-executable
  • Prevents the classic Aleph One style buffer overflow / shellcode injection.

NX Stack

Stack

NX Flaws

  • Code that doesn’t rely on itself
    • Ret2Win
    • Ret2LibC
    • Rop
    • Change Write state of memory

Stack Canaries

  • Around since ~1998
  • Write a value somewhere on the buffer, usually just before IP
  • If the value changes, stop execution

No Stack Canaries

No Canary From (https://www.usenix.org/legacy/publications/library/proceedings/sec98/full_papers/cowan/cowan.pdf)

With Stack Canaries

With Canary

Null / Terminator Canaries

  • First was NUL 0x00000000
  • Terminator 0x000aff0d
  • Bad Characters stop string functions

Random Canaries

  • Terminator Canaries could be guessed
    • Inputting it can be another matter
  • Random Canary Value can help avoid this
  • Value to check against has to be to stored somewhere.
    • Usually starts with 0x00

Bypass Canaries

  • Terminators. Depends on input methods
  • Random: Need to leak canary address values

ASLR

ASLR

  • Randomise addresses on the stack, heap and maps
  • Helps to Prevent attacks that rely on Guessing addresses in program

ASLR

ASLR

How Random

  • Depends on the size of memory
    • 32 Bit ~= 16 Bits
    • 64 Bit ~= 28 Bits

What it stops

  • Attacks where we have to jump to a known memory address
    • Ret2Win style
    • Classic Overflows

Weaknesses

  • Amount of Randomisation
    • 32bit systems, might be bruteforceable
    • 64bit systems, its unlikely

Strategies

  • Jump to functions with a static address
  • Infer the offset used for the stack
    • Leak current memory addresses
    • Examine memory maps
    • Forks and Threads.

PIE

PIE

  • Position Independent Code / Executable
  • Randomise addresses of code in Executable
  • Bases addresses on offsets within binary

PIE vs ASLR

  • Similar approach, make addresses hard to guess
  • PIE is Binary level, and compiled into program
  • ASLR is Kernel Level, so depends on he OS

PIE for Exploit Dev

  • Makes it hard to determine locations of Functions or Gadgets
  • Effects Shared Library’s, reducing the number of static functions we can use to leak addresses.

Weaknesses of PIE

  • Offsets are the biggest weakness.
  • If we can infer an known address, we can infer the offset and position of rest of the code
  • Depending on Program this can be hard.

Working against PIE

  • Try to leak a know address
    • Return pointer etc
  • Use This to infer PIE offsets
  • If library, GOT / PLT can help resolve addresses.

Summary

Summary

  • Covered some of the more common protection Mechanisms
  • Application Level
  • OS / Binary Level

Application Level

  • Firewalls. Can prevent network based attacks
  • AV: Examine programs for malicious code
    • Static or Dynamic

Application Level, Mitigation

  • Depends on target OS / Configuration
    • Spoofing Protocols, Working around Firewall Rules
    • Encoding / Encryption Conceal code from AV

OS / Binary Level

  • NX Stack: Marks portions of the stack non Executable
  • Stack Canaries: Guards against modification of the stack through overflow

OS / Binary Level

  • ASLR: Kernel randomises memory addresses, making Jump instructions harder
  • PIE: Binary level protection to Randomise addresses

Working Round OS / Binary Level

  • In combination can be quite formidable
    • Leak information, to understand state of memory
    • Use this to inform exploit jump locations
  • Will look at these in future weeks

Tasks

Tasks

CW1: Report (1500 words),

Evaluating how well-known off-the-shelf exploits, for example from Metasploit, are detected by protection mechanisms, and evaluating methods of avoiding this protection

Tasks

  • Coursework will ask you to research, discuss and critically analyse protection Mechanisms.
    • What they are
    • Why they are effective?
    • How they can be bypassed?
  • Use the Time this week to get started