housekeeping

something awesome

would anyone like to discuss their progress

secedu conference

• there’s a secedu conference in week 6
• $20 admission for students?
• they’ll talk about jobs and stuff
• come along

collaborative class notes

we’re writing the class notes for this weeks extended lecture

class notes

hall of fame

does anyone have a presentation (for bonus marks)

side channel attacks

• what is a side channel attack
• what are some examples of them

“2” factor authentication

what is the problem with 2 factor authenticator

• by sms
• through a phone app

phishing

what’s the difference between

• phishing
• spear phishing

when might each be used?

stack frames

• what are they?
• what register stores the stack, and frame pointer?
• why are the parameters stored below frame pointer?

the stack grows ???

• the stack grows from high address to low addresses
• so the top of the stack, is lower down in memory
• this doesn’t really change how you exploit, you also just write up the stack

stack frames

basic example

    0x18  [   ARGS   ] <- parameters
    0x14  [   EIP    ] <- stored return pointer
    0x10  [   EBP    ] <- stored frame pointer
    0x0C  [ AAAAAAAA ] <- local vars
    0x08  [ 00000001 ] <- an int?
    0x04  [ DEADBEEF ] <- a pointer
    0x00  [ 59454554 ] <- 4 characters

where are vars

referenced in relation to ebp e.g. ebp-0x4

• local vars are above later, so ebp-0x4
• arguments are below earlier so ebp+0x8

buffer overflows

tldr: trust is bad

reading into a buffer

what happens when you write more content than a buffer can hold

• mordern languages might just resize (python)
• some languages might throw an exception
• maybe it would crash? (sometimes it will)
• C (& lower-level languages) just kinda run with it

overflowing

so where exactly does that content go

• we’ve talked about stack frames
• if we write more content, it’ll just start overwriting other content on the stack
  • other variables
  • control stuff (EBP, EIP)

what can I overwrite?

• local variables
• return addresses
• content from other processes?

this could allow us to change the application flow

demo

when is a program vulnerable

what functions cause buffer overflows?

char buffer[32] a;

// read content
gets(a);
fgets(a, 0x32, stdin)

// printf, but write to a string not stdout
sprintf(a, "%s %s %d", some, random, vars);
snprintf(a, "%s %s %d", 0x32, and, more, vars);

but that’s not all

it’s not just reading content, but also copying?

char buffer[32] a, buffer[64] b;

// copy contents of b into a 
strcpy(a, b);
strncpy(a, b, 64);

// append contents of b onto a
strcat(a, b);
strncat(a, b, strlen(a) + strlen(b));

how do I find offsets

binja

binja is really nice and tells us the distance

• int is 0xC (12) bytes away from the return address
• buffer is 0x34 (52) bytes away

if we wrote 40 bytes of padding, and one additional byte into the buffer, we would overwrite the int

cyclic

kinda like bruteforce but smart

• what if we gave a random string as input
• then found what part of the string overwrote EIP

# gets(buffer)
$ AAAABBBBCCCCDDDDEEEEFFFF

# we SIGSEGV at EIP = EEEE

then we need 16 bytes of padding before the return address

how to generate random strings

pwntools

#  
cyclic(20) # generate a chunk of length 20

#   
c = cyclic_gen()
c.get(n)        # get a chunk of length n
c.find(b'caaa') # (8,0,8): pos 8, which is chunk 0 at pos 8

bash

# you can also do it on commandline
cyclic 12      # aaaaaaabaaac
cyclic -l aaab # -> 1  = find chunk
cyclic -o aaae # -> 13 = find offset

memory protections

ew cringe security stuff

PIE (yum)

position independent execution

• every time you run the binary, it gets loaded into a different location in memory
• this means just can’t simply set EIP to win()
• binja will only show the offset from the binary base

what does it look like

notice the region is entirely different

# no PIE
$ ./leak
win() is at 0x8041234

# with PIE
$ ./leak
win() is at 0x5650161
$ ./leak
win() is at 0x5650911

ASLR

address space layout randomization

using ASLR

# turn aslr off
sudo sysctl kernel.randomize_va_space=0

# check if it's on
cat /proc/sys/kernel/randomize_va_space

wait what’s the difference

ASLR is a kernel protection, PIE is a binary protection

• aslr is kinda like PIE for libc

stack canaries

they save the day and make overflows impossible

• a random value between the user buffers and [ER]IP
• if the value of that canary changes during execution, the program will abort
• this is what the __stack_chk_fail() thing is in some of the source code you’ll have read

canaries in memory

    0x1C  [  ARGS  ] <- parameters
    0x18  [   EIP  ] <- stored return pointer
    0x14  [   EBP  ] <- stored frame pointer
    0x00  [ canary ] <- canary goes here
    0x0C  [  AAAA  ] <- these are local vars
    0x08  [  AAAA  ]
    0x04  [  AAAA  ]
    0x00  [  AAAA  ]

real value stored somewhere else, and checked before the function returns

how do I defeat them

memory leaks basically

• PIE/ASLR: leak function pointer and you’re good
• canaries: leak the canary’s value
• the stack sometimes has some interesting values, but how can we leak them (this comes in week 4)