1. The OWASP Top 10 and Buffer Overflow Attacks
Tom Chothia
Computer Security, Lecture 14

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

3. 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, …

4. PHP injection
Get password
Create command executer

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

6. Password shame list

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

8. A4: Insecure Direct Object Reference
Problem: the server trusts the client to request only the resources it should. E.g. which we could replace with: Also common with cookie values.

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

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

11. Path Transversal
The user can type anything they want into the URL bar, or even form the request by hand.
If the webserver is running with root permission this will give me the password file.

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

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

14. Robots.txt

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

16. A7: Missing Function Level Access Control
Query strings are used to tell dynamic webpages what to do
account=tpc&action=add
account=tpc&action=show
What if the attacker tries:
account=admin&action=delete

17. URL hacking
The user can type anything they want into the URL bar, or even form the request by hand.
Attacker can try to guess filenames,
Guessable directory names will be found.

18. No security through obscurity
Fix
No security through obscurity
Never rely on just the URL request for authentication.
E.g. Use cookies to control access.

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

20. 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?

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

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

23. Buffer Overflow Attacks

24. Buffer Overflow Attacks
A simplified, high-level view of buffer overflow attacks.
x86 architecture
overflows on the stack
Exploiting buffer overflows using Metasploit

25. 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, …

26. USS Yorktown
US Navy Aegis missile cruiser

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

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

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

30. The x86 Architecture
Text
Data
Stack
Free Memory

31. The x86 Architecture
The program code
Text
Data
Stack
Free Memory

32. The x86 Architecture The program code Static variables, Strings, etc
Text
Data
Stack
Free Memory

33. The x86 Architecture
The program code Static variables, Strings, etc Data in use
Text
Data
Stack
Free Memory

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

35. 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
EAX
EIP
Free Memory
ESP

36. Screen shot, IDA

37. The Stack …
PUSH 12345
PUSH
POP EAX ….
The stack part of the memory is mostly “Last In, First Out”. We can only write and read to the top of the stack.
Data
Stack
EAX:
EIP: 7797F9CD
Free Memory
ESP: 0018F9B0

38. The Stack You write to the stack with push … PUSH 12345 PUSH 678245
POP EAX ….
You write to the stack with push
Data
Stack
EAX:
EIP: 7797F9CD
Free Memory
ESP: 0018F9B0

39. The Stack You write to the stack with push … PUSH 12345 PUSH 678245
POP EAX ….
You write to the stack with push
Data
Stack
EAX:
123456
EIP: 7797F9CE
Free Memory
ESP: 0018F9B1

40. The Stack You write to the stack with push … PUSH 12345 PUSH 678245
POP EAX ….
You write to the stack with push
Data
Stack
EAX:
123456
EIP: 7797F9CF
678245
Free Memory
ESP: 0018F9B1

41. The Stack …
PUSH 12345
PUSH
POP EAX ….
You write to the stack with push You read and remove an item from the stack with pop
Data
Stack
EAX:
123456
EIP: 7797F9CF
678245
Free Memory
ESP: 0018F9B1

42. The Stack …
PUSH 12345
PUSH
POP EAX ….
You write to the stack with push You read and remove an item from the stack with pop
Data
Stack
EAX:
123456
EIP: 7797F9CF
Free Memory
ESP: 0018F9B1

43. Function calls
void main () { function (1,2); }

44. Function calls void main () { function (1,2); }
Arguments 1 & 2 are passed on the stack.
The CALL instruction runs a function

45. Function calls PUSH <2> void main () { function (1,2); }
CALL <function>
void main () { function (1,2); }
Arguments 1 & 2 are passed on the stack.
The CALL instruction runs a function

46. Function Calls PUSH <arg2> PUSH <arg1>
CALL <function>
Stack

47. Function Calls PUSH <arg2> PUSH <arg1>
CALL <function>
Arg2
Stack

48. Function Calls PUSH <arg2> PUSH <arg1>
CALL <function>
Arg1
Arg2
Stack

49. 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.
Old EIP
Arg1
Arg2
Stack

50. 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
Old EIP
Arg1
Arg2
Stack

51. Screen shot, IDA

52. Buffer Overflows
The instruction pointer controls which code executes,

53. Buffer Overflows The instruction pointer controls which code executes,
The instruction pointer is stored on the stack,

54. Buffer Overflows The instruction pointer controls which code executes,
The instruction pointer is stored on the stack,
I can write to the stack …

55. Buffer Overflows The instruction pointer controls which code executes,
The instruction pointer is stored on the stack,
I can write to the stack … 

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

57. Buffers Function called with “Hello World” … function (user input);
function (char *str) {
char buffer[16];
strcpy(str,buffer); }
Stack

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

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

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

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

62. Buffer Overflow If user input is more than 16 bytes? …
function (user input);
function (char *str) {
char buffer[16];
strcpy(str,buffer); }
Stack

63. Buffer Overflow If user input is more than 16 bytes …
Runs as before …
function (user input);
function (char *str) {
char buffer[16];
strcpy(str,buffer); }
Old EIP
Hello WorldX XXXXXXXXX
Stack

64. Buffer Overflow If user input is more than 16 bytes …
Runs as before …
function (user input);
function (char *str) {
char buffer[16];
strcpy(str,buffer); }
< >
Old EIP
Hello WorldX XXXXXXXXX
Stack

65. Buffer Overflow If user input is more than 16 bytes …
Runs as before
But the string flows over the end of the buffer …
function (user input);
function (char *str) {
char buffer[16];
strcpy(str,buffer); }
< >
Old EIP
Hello WorldX XXXXXXXXX
Stack

66. Buffer Overflow If user input is more than 16 bytes …
Runs as before
But the string flows over the end of the buffer …
function (user input);
function (char *str) {
char buffer[16];
strcpy(str,buffer); }
Hello WorldXX
XXXXIP
Hello WorldX XXXXXXXXX
Stack

67. Buffer Overflow If user input is more than 16 bytes …
Runs as before
But the string flows over the end of the buffer
EIP corrupted, segmentation fault …
function (user input);
function (char *str) {
char buffer[16];
strcpy(str,buffer); }
Hello WorldXX
XXXXIP
Hello WorldX XXXXXXXXX
Stack

68. Once more, with malice
Runs as before
Stack

69. Once more, with malice Runs as before
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 WorldX X7797F9
Stack

70. Once more, with malice Runs as before
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 WorldX X7797F9
Stack

71. Once more, with malice Runs as before
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
The attackers value is copied over the old EIP
Hello WorldXX
7797F9
Hello WorldX X7797F9
Stack

72. Once more, with malice Runs as before
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
The attackers value is copied over the old EIP
When the function returns the attacks code is run
Hello WorldXX
7797F9
Hello WorldX X7797F9
Stack

73. Metasploit website
Metasploit attack demo

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

75. Defenses Stack canaries: Randomisation
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

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

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