The OWASP Top 10 and Buffer Overflow Attacks

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.

A 1: 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

A 2: 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

A 3: XXS • Cross Side Scripting attacks, as discussed. • A 1 injection is command injection on the server side. • This is Java. Script injection on the client side.

A 4: 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: //name. Of. Host/dir/file. html

Path Transversal • The user can type anything they want into the URL bar, or even form the request by hand. http: //name. Of. Host/. . /etc/shadow

Path Transversal • The user can type anything they want into the URL bar, or even form the request by hand. http: //name. Of. Host/. . /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.

A 5: 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

A 6: 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.

A 7: Missing Function Level Access Control Query strings are used to tell dynamic webpages what to do http: //my. Web. Shop. com/index. php? account=tpc&action=add http: //my. Web. Shop. com/index. php? account=tpc&action=show What if the attacker tries: http: //my. Web. Shop. 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: //name. Of. Host/file. Path • 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.

A 8: CSRF • Cross-Site Request Forgery (CSRF) • As discussed earlier. • Defend against by using unique token in the hidden field of important forms.

A 9: 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?

A 10: 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. – x 86 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, i. Phone 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 US Navy Aegis missile cruiser Dead in the water for 2 and a half hours due to a buffer overflow. “Because of politics, some things are being forced on us that without political pressure we might not do, … Ron Redman, deputy technical director Aegis

USS Yorktown US Navy Aegis missile cruiser Dead in the water for 2 and a half hours due to a buffer overflow. “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

The x 86 Architecture Text Data Stack Free Memory

The x 86 Architecture The program code Text Data Stack Free Memory

The x 86 Architecture The program code Static variables, Strings, etc Text Data Stack Free Memory

The x 86 Architecture The program code Static variables, Strings, etc Data in use Text Data Stack Free Memory

The x 86 Architecture The program code Text Static variables, Strings, etc Data in use Registers e. g. The Accumulator Instruction point Stack EAX EIP ESP Free Memory

The x 86 Architecture The program code Text Static variables, Strings, etc Data is use Registers e. g. The Accumulator Instruction point Stack EAX EIP ESP Free Memory

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. EAX: EIP: 7797 F 9 CD ESP: 0018 F 9 B 0 … PUSH 12345 PUSH 678245 POP EAX …. Data Stack Free Memory

The Stack You write to the stack with push … PUSH 12345 PUSH 678245 POP EAX …. Data Stack EAX: EIP: 7797 F 9 CD ESP: 0018 F 9 B 0 Free Memory

The Stack You write to the stack with push … PUSH 12345 PUSH 678245 POP EAX …. Data Stack EAX: EIP: 7797 F 9 CE ESP: 0018 F 9 B 1 123456 Free Memory

The Stack You write to the stack with push … PUSH 12345 PUSH 678245 POP EAX …. Data Stack EAX: EIP: 7797 F 9 CF ESP: 0018 F 9 B 1 123456 678245 Free Memory

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 EAX: EIP: 7797 F 9 CF ESP: 0018 F 9 B 1 123456 678245 Free Memory

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 EAX: 678245 EIP: 7797 F 9 CF ESP: 0018 F 9 B 1 123456 Free Memory

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); } PUSH <2> PUSH <1> CALL <function> • Arguments 1 & 2 are passed on the stack. • The CALL instruction runs a function

Function Calls PUSH <arg 2> PUSH <arg 1> CALL <function> Stack

Function Calls PUSH <arg 2> PUSH <arg 1> CALL <function> Arg 2 Stack

Function Calls PUSH <arg 2> PUSH <arg 1> CALL <function> Arg 1 Arg 2 Stack

Function Calls PUSH <arg 2> PUSH <arg 1> CALL <function> CALL writes the instruction point (EIP) onto the stack and then sets the EIP to to equal the code for the function. Old EIP Arg 1 Arg 2 Stack

Function Calls PUSH <arg 2> PUSH <arg 1> 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 Old EIP Arg 1 Arg 2 Stack

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 … 1. Function called with “Hello World” function (user input); … function (char *str) { char buffer[16]; strcpy(str, buffer); } Stack

Buffers … 1. Function called with “Hello World” function (user input); … 2. Arg and EIP written to stack function (char *str) { char buffer[16]; strcpy(str, buffer); } Old EIP Hello World Stack

Buffers … 1. Function called with “Hello World” function (user input); … 2. Arg and EIP written to stack function (char *str) { char buffer[16]; 3. Function runs strcpy(str, buffer); } Old EIP Hello World Stack

Buffers … 1. Function called with “Hello World” function (user input); … 2. Arg and EIP written to stack function (char *str) { 3. Function runs char buffer[16]; 4. Buffer allocated strcpy(str, buffer); } <------16 ------> Old EIP Hello World Stack

Buffers … 1. Functions called with “Hello World” function (user input); … 2. Arg and EIP written to stack function (char *str) { 3. Function runs char buffer[16]; 4. Buffer allocated strcpy(str, buffer); 5. String copied } Hello World Old EIP Hello World Stack

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); } Old EIP Hello World. X XXXXX 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); } <------16 ------> Old EIP Hello World. X XXXXX Stack

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); } <------16 ------> Old EIP Hello World. X XXXXX Stack

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); } Hello World. XX XXXXIP XXXXX Stack

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); } Hello World. XX XXXXIP XXXXX Stack

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 Hello World. X X 7797 F 9 Stack

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 Old EIP Hello World. X X 7797 F 9 Stack

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 Hello World. XX 7797 F 9 Hello World. X X 7797 F 9 Stack

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 Hello World. XX 7797 F 9 Hello World. X X 7797 F 9 Stack

• 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 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 90 s. 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.