The OWASP Top 10and Buffer Overflow Attacks

Tom ChothiaComputer 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, …

PHP injection

• Get password

• Create command executer

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.

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.

Path Transversal

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

http://nameOfHost/dir/file.html

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.

• Robots.txt

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.

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

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

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

US Navy Aegis missile cruiser

USS Yorktown

US Navy Aegis missile cruiser

Dead in the water for 2 and a half hours due to a buffer overflow.

USS Yorktown

“Because of politics, some things are being forced on us that without political pressure we might not do, …

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.

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

Text

Data

Stack

Free Memory

The x86 ArchitectureThe program code

Text

Data

Stack

Free Memory

The x86 ArchitectureThe program code

Static variables, Strings, etc

Text

Data

Stack

Free Memory

The x86 ArchitectureThe program code

Static variables, Strings, etc

Data in use

Text

Data

Stack

Free Memory

The x86 ArchitectureThe program code

Static variables, Strings, etc

Data in use

Registers e.g. The Accumulator

Instruction point Stack point

Text

Data

Stack

Free MemoryESP

EIP

EAX

The x86 ArchitectureThe program code

Static variables, Strings, etc

Data is use

Registers e.g. The Accumulator

Instruction point Stack point

Text

Data

Stack

Free MemoryESP

EIP

EAX

Screen shot, IDA

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 12345PUSH 678245POP EAX….

Data

Stack

Free MemoryESP: 0018F9B0EIP: 7797F9CD EAX:

The Stack

You write to the stack with push

…PUSH 12345PUSH 678245POP EAX….

Data

Stack

Free MemoryESP: 0018F9B0EIP: 7797F9CD EAX:

123456

The Stack

You write to the stack with push

…PUSH 12345PUSH 678245POP EAX….

Data

Stack

Free MemoryESP: 0018F9B1EIP: 7797F9CE EAX:

678245123456

The Stack

You write to the stack with push

…PUSH 12345PUSH 678245POP EAX….

Data

Stack

Free MemoryESP: 0018F9B1EIP: 7797F9CF EAX:

678245123456

The Stack

You write to the stack with push

You read and remove an item from the stack with pop

…PUSH 12345PUSH 678245POP EAX….

Data

Stack

Free MemoryESP: 0018F9B1EIP: 7797F9CF EAX:

123456

The Stack

You write to the stack with push

You read and remove an item from the stack with pop

…PUSH 12345PUSH 678245POP EAX….

Data

Stack

Free MemoryESP: 0018F9B1EIP: 7797F9CF EAX: 678245

Function calls

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

}

Function calls

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

}

• Arguments 1 & 2 are passed on the stack.

• The CALL instruction runs a function

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>

Stack

Function Calls PUSH <arg2>PUSH <arg1>CALL <function>

StackArg2

Function Calls PUSH <arg2>PUSH <arg1>CALL <function>

StackArg2Arg1

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.

StackArg2Arg1Old EIP

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

StackArg2Arg1Old EIP

Screen shot, IDA

Buffer Overflows

• The instruction pointer controls which code executes,

Buffer Overflows

• The instruction pointer controls which code executes,

• The instruction pointer is stored on the stack,

Buffer Overflows

• The instruction pointer controls which code executes,

• The instruction pointer is stored on the stack,

• I can write to the stack …

Buffer Overflows

• The instruction pointer controls which code executes,

• The instruction pointer is stored on the stack,

• I can write to the stack …

Buffers

…function (user input);…

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

Stack

Buffers

…function (user input);…

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

Stack

1. Function called with “Hello World”

Buffers

…function (user input);…

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

StackHello WorldOld EIP

1. Function called with “Hello World”

2. Arg and EIP written to stack

Buffers

…function (user input);…

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

StackHello WorldOld EIP

1. Function called with “Hello World”

2. Arg and EIP written to stack

3. Function runs

Buffers

…function (user input);…

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

StackHello WorldOld EIP<------16------>

1. Function called with “Hello World”

2. Arg and EIP written to stack

3. Function runs

4. Buffer allocated

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);}

StackHello WorldOld EIPHello World

Buffer Overflow

If user input is more than 16 bytes? …

function (user input);…

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

Stack

Buffer Overflow

If user input is more than 16 bytes

1. Runs as before

…function (user input);…

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

StackHello WorldX XXXXXXXXX

Old EIP

Buffer Overflow

If user input is more than 16 bytes

1. Runs as before

…function (user input);…

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

StackHello WorldX XXXXXXXXX

Old EIP<------16------>

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

…function (user input);…

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

StackHello WorldX XXXXXXXXX

Old EIP<------16------>

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

…function (user input);…

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

StackHello WorldX XXXXXXXXX

XXXXIPHello WorldXX

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);}

StackHello WorldX XXXXXXXXX

XXXXIPHello WorldXX

Once more, with malice

1. Runs as before

Stack

Once more, with malice

1. Runs as before

2. Attacker sends 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

StackHello WorldX X7797F9

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

StackHello WorldX X7797F9

Old EIP

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

StackHello WorldX X7797F9

7797F9Hello 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

StackHello WorldX X7797F9

7797F9Hello WorldXX

• Metasploit website• Metasploit attack demo

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.