1

The OWASP Top 10 and Buffer Overflow Attacks

Tom Chothia Computer Security, Lecture 14

OWASP top 10.

The Open Web Application Security Project Open public effort to improve web security:

•  Many useful documents. •  Open public meetings & events.

There “10 top” lists the current biggest web threats.

A1: Injection

•  Server side command injection, e.g., SQL injection.

•  Not just SQL injection, any command language can be injected.

•  E.g. PHP, shell commands, XML processing commands, …

A2: Broken Auth.

Many web developers implement their own log in systems. Often broken, e.g. •  No session time outs.

•  Passwords not hashed •  E.g. password shame list.

A3: XXS

•  Cross Side Scripting attacks, as discussed.

•  A1 injection is command injection on the server side.

•  This is JavaScript injection on the client side.

A4: Insecure Direct Object Reference

Problem: the server trusts the client to request only the resources it should. E.g.

http://site.com/view?user=alice!

which we could replace with: !

http://site.com/view?user=bob!

Also common with cookie values.

!

2

Path Transversal

•  The user can type anything they want into the URL bar, or even form the request by hand.

http://nameOfHost

Path Transversal

•  The user can type anything they want into the URL bar, or even form the request by hand.

http://nameOfHost/../../../etc/shadow

Path Transversal

•  The user can type anything they want into the URL bar, or even form the request by hand.

http://nameOfHost/../../../etc/shadow •  If the webserver is running with root

permission this will give me the password file.

Path Transversal: Fix

•  Use access control settings to stop Path Transversal.

•  Best practice, make a specific user account for the webserver.

•  Only give that account access to public files.

A5: Security Misconfiguration

Make sure your security settings don’t give an attacker an advantage, e.g.

•  Error Messages: should not be made public.

•  Directory Listings: It should not be possible to see the files in a directory.

•  Admin panels should not be publically accessible.

A6: Sensitive Data Exposure

All sensitive data should be protected at all times.

•  Is SSL used everywhere?

•  Credit card numbers not encrypted: •  CC no. should be encrypted in database.

PHP page should decrypt these, if needed. •  This means that the hacker needs to attack

the page and the database.

3

A7: Missing Function Level Access Control

Query strings are used to tell dynamic webpages what to do

http://myWebShop.com/index.php? account=tpc&action=add

http://myWebShop.com/index.php? account=tpc&action=show

What if the attacker tries: http://myWebShop.com/index.php?

account=admin&action=delete

URL hacking

•  The user can type anything they want into the URL bar, or even form the request by hand.

http://nameOfHost/filePath •  Attacker can try to guess filenames,

•  Guessable directory names will be found.

Fix

No security through obscurity Never rely on just the URL request for

authentication. E.g. Use cookies to control access.

A8: CSRF

•  Cross-Site Request Forgery (CSRF)

•  As discussed earlier.

•  Defend against by using unique token in the hidden field of important forms.

A9: Using Components with Known Vulnerabilities

•  If a new security patch comes out has it been applied? •  A patch might require you to bring

down the site and so lose money. • Or it might even break your website.

•  Is it worth applying the patch?

A10: Invalidated Redirects and Forwards

•  If attackers can forward a user to another page then they can use it for:

•  Phishing (e.g. a fake log in page) •  Ad Fraud. •  Launch exploits on browser.

•  Not a major threat (IMHO).

4

Web Security

•  To secure a website you need to know how it works: •  How clients request resources. •  How clients are authenticated. •  How HTTP and webservers work.

•  Errors are often down to bad app logic

•  Always sanitize everything.

Buffer Overflow Attacks

•  A simplified, high-level view of buffer overflow attacks. •  x86 architecture •  overflows on the stack

•  Exploiting buffer overflows using Metasploit

Introduction

•  In languages like C, you have to tell the compiler how to manage the memory. •  This is hard.

•  If you get it wrong, then an attacker can usually exploit this bug to make your application run arbitrary code.

•  Countless worms, attacks against SQL servers, Web Servers, iPhone Jailbreak, SSH servers, …

USS Yorktown

“Because of politics, some things are being forced on us that without political pressure we might not do, like Windows NT. If it were up to me I probably would not have used Windows NT in this particular application.”

Ron Redman, deputy technical director Aegis

US Navy Aegis missile cruiser Dead in the water for 2 and a half hours due to a buffer overflow.

The x86 Architecture The program code Static variables,

Strings, etc Data is use Registers e.g. The Accumulator

Instruction point Stack point

Text

Data

Stack

Free Memory ESP EIP EAX

Screen shot, IDA

5

The Stack

The stack part of the memory is mostly “Last In, First Out”.

We can only write and read to the top of the stack.

… PUSH 12345 PUSH 678245 POP EAX ….

Data

Stack

Free Memory ESP: 0018F9B0 EIP: 7797F9CD EAX:

123456

The Stack

You write to the stack with push You read and remove

an item from the stack with pop

… PUSH 12345 PUSH 678245 POP EAX ….

Data

Stack

Free Memory

ESP: 0018F9B1 EIP: 7797F9CF EAX: 678245

Function calls

void main () { function (1,2); }

•  Arguments 1 & 2 are passed on the stack.

•  The CALL instruction runs a function

PUSH <2>

PUSH <1>

CALL <function>

Function Calls PUSH <arg2> PUSH <arg1> CALL <function> CALL writes the instruction point (EIP) onto the stack and

then sets the EIP to to equal the code for the function. Later a return instruction restores the old EIP and the

program continues

Stack Arg2 Arg1 Old EIP

Buffer Overflows

•  The instruction pointer controls which code executes,

•  The instruction pointer is stored on the stack,

•  I can write to the stack … J

Buffers

1.  Functions called with “Hello World”

2.  Arg and EIP written to stack

3.  Function runs

4.  Buffer allocated

5.  String copied

… function (user input); … function (char *str) { char buffer[16]; strcpy(str,buffer); }

Stack Hello World Old EIP Hello World

6

Buffer Overflow If user input is more

than 16 bytes

1.  Runs as before

2.  But the string flows over the end of the buffer

3.  EIP corrupted, segmentation fault

… function (user input); … function (char *str) { char buffer[16]; strcpy(str,buffer); }

Stack Hello WorldX XXXXXXXXX XXXXIP Hello WorldXX

Once more, with malice 1.  Runs as before

2.  Attack send a very long message, ending with the address of some code that gives him a shell.

•  The attackers code could also be part of the message

3.  The attackers value is copied over the old EIP

4.  When the function returns the attacks code is run

Stack Hello WorldX X7797F9 7797F9 Hello WorldXX

Over Writing Other Values

Attacking the instruction pointer (EIP) is

the most powerful technique. However, any memory value can be attacked:

•  Over write arguments on the stack

•  e.g. change the parameters to a chmod call •  Overflows on the heap

•  e.g. rewrite a password in memory

Defenses •  Stack canaries:

•  values placed on the stack, which are later tested.

•  if the stack is over written then the value test will fail.

•  Randomisation •  Layout of the memory is randomised. •  This makes it very hard for the attack to find

the memory to overwrite or code to jump to.

For more information see the Secure Programming Module

Recommend Paper:

•  “Smashing the Stack for Fun and Profit” Elias Levy (Aleph One)

A simple introduction to buffer overflows

from the mid 90s. Standard defences now stop the attacks

in this paper, but it gives an excellent introduction.

Conclusion

Buffer overflows are the result of poor memory management in languages like C •  even the best programmers sometimes make

mistakes. Buffer overflow attacks exploit these to over

write memory values. This often lets an attack execute arbitrary

code.