Wormholes and a Honeyfarm: Automatically Detecting Novel Worms (and other random stuff) Nicholas Weaver Vern Paxson Stuart Staniford UC Berkeley ICIR Silicon Defense

Problem: Automatically Detecting New Worms Detect a new worm on the Internet before many machines are infected Use this information to guide defenses 30-60 seconds to detect (and stop) Slammer Honeypots are accurate detectors Monitor egress to detect worms k vulnerable honeypots will detect a worm when ~1/k of the vulnerable machines are infected But impractical Cost: time, not machines Trust: must trust all honeypots!

Idea: Split the Network Endpoints from the Honeypots Wormholes are traffic tunnels Routes connections to a remote system Untrusted endpoints Honeyfarm consists of Virtual Machine honeypots Create virtual honeypots on demand See honeynet.org Route internally generated traffic to other images Classify based on what can be infected This is the resulting split. The endpoints, “Wormholes”, are traffic tunnels. The honeyfarm itself uses virtual machine techniques so it doesn’t need to create a honeypot for each endpoint. The honeyfarm needs to use VM techniques simply because of the number of wormholes and you need to create images on demand. For more information on virtual honeypots, see the honeynet project.

How Wormholes Work Low cost “appliance”: Clear Box: Plugs into network, obtains address through DHCP Contacts the Honeyfarm Reconfigures local network stack fool nmap style detection Forwards all traffic to/from the Honeyfarm Clear Box: Deployers have source code Restrictions built into the wormhole code so it doesn't trust the honeyfarm, can't contact the local network! Instead/addition to wormholes, one can... Route small telescopes to the honeyfarm Route ALL unused addresses in an institution... The goal of the wormholes is to design traffic tunnels that people will deploy. Exception: DNS requests can be generated to local DNS server. Wormhole CAN forward requests from the honeyfarm out, to prevent “phone home” based detection strategies. But it can’t forward requests to the local network, allowing it to be deployed more safely. The goal is to build devices which the deployers can trust, but the Honeyfarm does not have to Since the functionality is simple, we can run on low cost, commodity hardware We might want to also route entire address ranges, although such address ranges, although sensitive, represent more valuable “secrets” from an attacker’s viewpoint, so they can't be relied on as heavily. Image is random DS9 screen capture, found on the net.

How a Honeyfarm Works Creates Virtual Machine images to implement Honeypots Using VMware or similar Images exist "in potential" until traffic received Niels Provos suggested: Use honeyd as a first pass filter Completes the illusion that a honeypot exists at every wormhole location Any traffic received from wormhole Activate and configure a VM image Forward traffic to VM image Honeypot image generated traffic is monitored and redirected Wormhole IP: aa.bb.cc.dd Honeyfarm VM Image IP: xx.xx.xx.xx VM Image IP: aa.bb.cc.dd The honeyfarm needs to use virtual machine honeypots, as otherwise it would require too many resources. The goal is to detect behaviors in the system. Thus we need to have images almost ready to go, they need to be reconfigured and connected when traffic is received. We monitor the traffic to serve as the detector. VM Image IP: aa.bb.cc.ee

What Could We Automatically Learn From a Honeyfarm? A new worm is in the Internet Triggered based on ability to infect VMs What the worm is capable of Types of vulnerable configurations Including patch level Creates a “Vulnerability Signature” Some overt, immediate malicious behavior Immediate file erasers etc Possible attack signatures Works best for tracking: Human attackers Scanning worms Slow enough to react effectively Randomness hits wormholes Note the one limitation: Can only detect worms which can infect the VM images. We note capabilities based on what other VM image the captured worm can succeed in infecting. A “vulnerability signature” could be used by response mechanisms to block all traffic to vulnerable machines, without affecting immune machines. Noticing overtly malicious behavior is useful secondary information, but not the primary objective

What Trust is Needed? Wormhole deployers: Honeyfarm operator: Need to trust wormhole devices, not the honeyfarm operator Honeyfarm operator: Attackers know of some wormholes, but most are generally unknown Wormhole locations are “open secrets” Does not trust wormhole deployers Detection is based on infected honeypots, not traffic from a wormhole Dishonest wormholes are filtered out Responding systems receiving an alert: Either the honeyfarm and operator are honest and uncompromised OR rely on multiple, independent honeyfarms all raising an alarm "If CERT and DOD-CERT say..." When building distributed systems and systems which trigger automatic responses, we need to be very concerned about trust issues. The wormhole deployers trust the wormholes, NOT the honeyfarm. The honeyfarm doesn’t trust the wormhole deployers. Responding systems either trust the honeyfarm, or trust 2 independent honeyfarms to both raise an alarm. (Image is taken from http://www.sonypictures.com/movies/matilda/assets/car.jpg ), copyright sony.

Status and Acknowledgements Status: Paper design Idea, attacks, costs, development time Lots of attacks on the honeyfarm system and possible defenses Plan to build honeyfarm first, attached to a small telescope Wormholes can be built for <$350, no moving parts, 50 Watts power, quantity 1 Acknowledgements: Honeypot technology: Honeynet project, honeyd, DTK Feedback from many people: Stefan Savage, David Moore, David Wagner, Niels Provos, etc etc etc.

Random Slide: 1 Gb (ASAP), 10 Gb (+2-3 years) Need wiring-closet defenses: As close to the endpoint as possible, need to be reprogrammable <$1000 for GigE today (build for $500) Optical ideal, +$100 for 1000-base-T <$2000 for 10GigE in 2-3 years (build for $1000) New FPGAs with SERDESes, embedded processors, massive parallelism and pipelining DIMM 1000-BaseT PHY SX Transceiver FPGA SX Transceiver 1000-BaseT PHY SX Transceiver DIMM

Random Slide: Colonel John R. Boyd’s OODA “Loop” Observe Orient Decide Act Implicit Guidance & Control Implicit Guidance & Control Unfolding Circumstances Cultural Traditions Observations Genetic Heritage Decision (Hypothesis) Analyses & Synthesis Action (Test) Feed Forward Feed Forward Feed Forward New Information Previous Experience Outside Information Unfolding Interaction With Environment Unfolding Interaction With Environment Feedback This slide (but not the following notes) is Copyright by the estate of John R Boyd. Permission was granted to use this slide in theses talks as long as the attribution remains. The OODA (Observe, Orient, Decide, Act) “loop/cycle” was developed by John Boyd as a way of describing competitors, with each participant (or group) having its own OODA loop. John R. Boyd was a retired USAF Colonel. As a military serviceman, he wrote the book on air-to-air tactics, was a driving force behind both the F15, F16, and F18 designs, and developed many of the concepts used in current US military strategies and tactics. Robert Corman’s biography “Boyd”, is a good biography for the curious. (Need good reference for understanding OODA concepts however) Feedback Note how orientation shapes observation, shapes decision, shapes action, and in turn is shaped by the feedback and other phenomena coming into our sensing or observing window. Also note how the entire “loop” (not just orientation) is an ongoing many-sided implicit cross-referencing process of projection, empathy, correlation, and rejection. From “The Essence of Winning and Losing,” John R. Boyd, January 1996. From Defense and the National Interest, http://www.d-n-i.net, copyright 2001 the estate of John Boyd Used with permission

Ranom Slide: What is the OODA loop? The OODA (Observe, Orient, Decide, Act) cycle was designed as a semi-formal model of adversarial decision making Really a complex nest of feedback loops Originally designed to represent strategic and tactical decision-making Implicit shortcuts are critical in human-based systems Every participant or group has its own OODA loop Attack the opponent’s decision making process Avoid/confuse/manipulate the opponent’s observation/detection Stealthy worms Take advantage of errors in orientation/analysis Not yet but will begin to happen! Move faster than the opponent’s reaction time Why autonomous worms outrace “human-in-the-loop” systems Reactive worm defenses need fully-automated OODA loops The fastest, accurate OODA loop usually wins The OODA loop is a semi-formal model of adversarial decision making: each participant has their own “loop”, and groups create loops as well. The term loop is a misnomer, rather it is a collection of numerous feedback loops. This was primarily developed to model strategies and tactics, based around the idea of attacking the opponent’s decision making process rather than just the opponent's physical resources. This is critical in understanding worm defenses, because there are at least two competing processes: the worms and the defenses. During propagation, if a worm can avoid triggering the detection mechanisms, then the worm can avoid the entire defense, as nothing will get triggered. Likewise, any errors in the orientation/analysis portion can be exploited. Finally, and this is the worm’s greatest advantage against the defenders, if an individual’s OODA loop is operating effectively within the reaction-timescale of the opponent, then the opponent really can’t do anything, because he’s always one (or many) steps behind, and gets farther behind over time. As long as humans are in the response patch necessary to stop a worm, the defense OODA loop is always insufficiently slow

Random Slide: Automated OODA Loops Since both the worms and worm-defense routines are automatic while a fast worm is spreading, the OODA loops are much simpler No implicit paths, everything is now explicit Orientation and decision making are combined Communication is also made explicit The OODA loops are shaped by the designer’s goals, objectives, and skills Observation is often critical for both sides In an automated loop, there are no implicit fast-paths, as all paths are now explicit. Orientation and decision is combined, simply because orientation in the original OODA formulation represents the implicit decision making, as opposed to explicit decision making. With an automated system, there is no longer a significant distinction between the two. Communication is made explicit in this simplification... It’s implicit in the original OODA loop formulation: actions can communicate to others (both friend and foe), and communication is one of the areas observed. But when thinking about both worms and worm-defense, communication becomes such an important part (in creating a wider viewpoint), that this version explicitly includes communication between decision-making systems. Likewise, since observation techniques can leak information to the opponents, this diagram isolates observation into three classes: passive, local, and active. Observe Orient/Decide Act Passive Automatic Decision Making Information Control Local Actions Control Feedback Active Interaction with Environment Communication