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.