Making Protocols Secure Overview Karl Levitt UCD

Making Protocols Secure • Overview: Karl Levitt (UCD) • Intrusion Detection in Routers: Poornima Balasubramanyam, Ph. D (UCD) • Simulation Experiments for Router Intrusion Detection: Akshay Aggarwal (UCD) • Intrusion Detection in Ad hoc Networks: Elizabeth Belding-Royer (UCSB) • Mitigating Routing Misbehavior in Ad hoc Networks: Mary Baker (Stanford) • Security Multicast Protocols for CORBA: Louise Moser (UCSB) • Automatic Response to Attacks: Ivan Balepin (UCD) • Detection of Spoofed Packets, Challenge Problem -- Defense in the Large: Karl Levitt

Approach to Security • Prevent, or • Tolerate – – Detect, and Stop attack, and Fight Back, and Recover

UC DAVIS - Security of Protocols Security Protocol Workbench Intrusion Detection and Response Protocols Security Verification Cryptographic Protocols Phil Rogaway Matt Franklin Attacks • on routers • multiple state (scenario) • worms

Outline • Specification-Based Intrusion Detection – Overview – Application to attacks on protocols, e. g. , ARP – Application to attacks on routers – Towards verifying the completeness of an IDS – Basis for automated response • JIGSAW: Specification and composition of attacks • Protocols for Large-Scale IDS, e. g. , for Defense Against Worms • Detection of Spoofed Packets - a difficult problem for intrusion detection

Approaches to Integrity Attack Detection • Static: Detect an inconsistency in system state – Tripwire: Inconsistency in a file – Diagnosis: Test a component • Dynamic: 1. Misuse: Detect known attacks through their signatures 2. Anomaly: Detect activity that does not match a profile; can profile users, processes, programs, systems, networks, … 3. Specification-Based: Detect activity that is inconsistent with a priori specification (aka constraints) for an object. Can write specifications for: programs; protocols; policies on users, … 4. Hybrid (2 and 3): a priori template specifications with parameters discovered by profiling Only Static and Dynamic (2, 4) can detect unknown attacks

Useful Types of Constraints • Protocols -- Invariant and assumptions – IP Routers approximate Kirchoff’s law – Packets are not sniffed by third-party – Packet source must be a non-congested/non-DOSed host • Programs -- valid access constraints – Programs access only certain objects • Programs - Interaction constraints – program interaction should not change the semantics • Data Integrity – e. g. , passwords, other authentication information

User constraints Program constraints Data constraints Protocol constraints Application constraints Constraints Access constraints Interaction constraints Operational constraints Message constraints Protocol Invariants

Access Constraints for Programs • Can Detect – remote users gain local accesses – local users gain additional privileges – Trojan Horses • Work well for many programs, e. g. , passwd, lprm, lpq, fingerd, atq, … • Some program can potentially access many files, e. g. , httpd, ftpd – break the execution into pieces (or threadlets). Define the valid access for each sub-thread. – Threadlet defined by transition operations

Generic Constraints • A privileged process should discard all its privileges and capabilities before it gives control to a user. • The temporary file for a program should be accessible only by the program execution and should be removed when the program exits • An application should read only configuration files owned by the user that it is running as

Useful Types of Constraints • Policy on Users – Files a user can access – Resources a user is allowed to possess • Protocol Specifications -- operational view – Defines allowable transitions – Defines allowable time in a given state • Protocol Specifications -- message content – Mappings delivered by DNS should accurately represent view of authoritative router – IP addresses are not spoofed

Operation of ARP • When using TCP/IP, the ARP protocol maps a 32 -bit IP address into a 48 -bit local hardware address. hostname resolver (1) FTP IP addr (2) Establish connection w/ IP address TCP (3) Send IP datagram to IP address ARP IP (6) Eth address assigned to IP address (4) ARP broadcast request for IP address to Eth address mapping Ethernet Driver (7) Packet sent Ethernet Driver (5) ARP reply ARP IP TCP

ARP Cache Poisoning • • Unsolicited Response Malformed Request Bogus Response Both a spurious Request and a spurious Response • Gratuitous ARP

Unsolicited ARP Response ARP REPLY to victim blanc. cs. ucdavis. edu IS-AT 08: 00: 23: 71: 52 • ARP reply will be accepted by a victim machine, even though it hasn’t sent a request. • Sending a arbitrary IP to Ethernet mapping will poison the victim’s ARP cache. • Sending an unsolicited response to the broadcast ethernet address poisons the cache of all machines (Solaris, Windows, Linux).

Malformed ARP Request ARP REQUEST WHO-HAS olympus. cs. ucdavis. edu TELL blanc. cs. ucdavis. edu at 08: 00: 23: 71: 52 • ARP implementations cache entries based upon broadcast requests. • Even if the host isn’t involved in any resolution their cache will update with the information contained in third-party requests. • Sending out an request with bogus sender information poisons everyone’s cache.

Bogus Response ARP REQUEST WHO-HAS; blanc. cs. ucdavis. edu TELL gunnbjornfeld. cs. ucdavis. edu at 08: 00: 20: 71: FE: 95 ARP REPLY to gunnbjornfeld; blanc. cs. ucdavis. edu IS-AT 08: 00: 20: FF: FF • Attacker waits till a victim (gunnbjornfeld) issues an ARP request. • Race condition can be exploited by the attacker in sending the response.

Bogus Requests and Responses ARP REQUEST WHO-HAS; blanc. cs. ucdavis. edu TELL gunnbjornfeld. cs. ucdavis. edu at 08: 00: 20: 71: FE: 95 ARP REPLY to gunnbjornfeld; blanc. cs. ucdavis. edu IS-AT 08: 00: 20: FF: FF • Attacker sends out both the bogus request and a bogus response. • Poisons the ARP cache of machines that implement solutions to the broadcast reply problem.

Gratuitous ARP • Some machines will send ARP requests where the source and target IP’s are the same. • Used in some DHCP situations to see if someone else is using a newly assigned address.

An ARP specification ARP Request i ARP Response reply_wait ARP cache timeout cached

Monitoring for Intrusions Unsolicitied ARP Response Malformed Request alarm ARP Request i Bogus ARP Response reply_wait ARP cache timeout cached

ARP Monitor Implementation • Built on the snort open-source IDS platform - Uses the snort preprocessor plug-in feature - No measurable difference in baseline IDS performance due to the low volume of ARP traffic. • Single ARP correctness specification catches all five ARP vulnerabilities • DHCP traffic produces significant false alarms.

Intrusion Monitoring in Network Routing Protocols • Fundamental motivation – provide a systematic framework for • developing specifications/constraints such that security breaches may be described as violations of these constraints, and • establishing bounds for secure network behavior. • Two aspects to this study – describe knowledge available to each router – employ this knowledge in order to create a more secure enhancement to an existing protocol.

Security Threats • Illegal attempt to infiltrate the routing process – outsider attacks – attacks that modify the routing information – cause redirection of the network traffic, Do. S attacks, etc. – countermeasure - use of strong integrity mechanisms to protect routing information • Subverted or compromised rogue routers that legitimately participate in a routing protocol - insider attacks – deliberately mis-configured router designed to influence local routing behavior – active attempts to disrupt the global routing behavior • Routers do not masquerade as other routers. Integrity mechanisms are in place • Routers masquerade as other routers. Integrity mechanisms are not in place

Centrality Analysis • captures the structurally central part of a network. • depends on the point of view – may be nodes with most direct connections to neighbors, or – nodes that are most connected to network, or – the nodes that are closest to other points. .

• Degree Centrality – Number of nodes to which a node is directly linked – Reflective of potential communication activity – Measure of vulnerability of node since high degree nodes will be less vulnerable to attack – Node of low degree is isolated and cut off from active participation in ongoing network activity

• Betweenness centrality – Defines potential for control of communication – Based on frequency with which a node falls between pairs of other points on shortest paths between them – Overall index determined by summing partial values for all unordered pairs of points – Betweenness centrality of a node is greater if it lies on a greater number of shortest paths between other node pairs

• Computation of betweenness centrality – Traditional summation methods costly, requiring O(n^3) time and O(n^2) space for n nodes and e edges – Approaches to resolve computational issues • Modified definitions – egocentric approach, simplified egocentric approaches • Heuristics – Exploit sparsity of connections in large networks – Exploit correlation between degree centrality and betweenness centrality – Employing a single source, shortest path solution for each node, the betweenness centrality can be computed in O(n(e+nlog(n))) time and O(n+e) space

• Recent Work in Intra-domain Routing Protocols (Application to OSPF) – Modified Definition of Betweenness Centrality: • Centrality of a node is determined with respect to root router of SPF tree – Advantages • Each router independently computes betweenness centrality indices of other routers • Piggyback betweenness centrality computation within Dijkstra SPF algorithm at each router • Each router can adopt independent response decisions based on this metric

• Ongoing Work – Augmented current link-state algorithm (rt. Proto. LS) implemented in network simulator, ns-2, to incorporate centrality computations and perform comparative performance analysis on this augmented algorithm – Running simulations on ns-2 for realistic network scenarios to test validity of centrality indices for various cases of spatial and temporal as well as random and correlated link failures – Reference: Poornima Balasubramanyam and Karl Levitt, Using Properties of Network Topology to Detect Malicious Routing Behavior, Technical Report # ECS-2002 -26, Department of Computer Science, University of California, Davis, 2002.

• Centrality Analysis in Ad hoc Networks – Points of Interest • the absence of a communication infrastructure • each mobile node must also perform the duties of a router • dynamically establish routing among themselves to form an ad hoc network – Routing Protocols being considered • two routing protocols considered for standardization by IETF, namely, DSR and AODV • hybrid ad hoc routing protocols that employ clustering and hierarchical techniques

• Ongoing Work – For each of DSR, AODV, other hybrids: examining development of a functionality that abstracts the global centrality information locally as well as studying limits of this approach – Using ns-2, simulate aspects of intrusive behavior of malicious hosts involving dense, complex networks with high node mobility and substantially dynamic topologies. – Tasks • Modify ns-2 simulator in order to support elements of centrality analysis within ad hoc routing protocols. • Performance analysis of estimates of centrality in the presence of both node mobility and dynamic topologies as well as under specific node failure/link failure scenarios. • As a response mechanism, study feasibility of employing this information as a metric (both for isolating intrusive behavior of a malicious node as well as a Qo. S metric to prevent traffic congestion)

System Architecture for Intrusion Monitoring and Adaptive Response Packet Forwarding Tables Intrusion Alerts Routing Decision Engine Security Policies Diagnostic Component Network Topology Monitor -Directed Topology Analysis - spatial, temporal correlation of link failures - network characteristics - protocol characteristics Incoming Routing Packets Centrality Detection Engine

Intrusion Monitoring and Adaptive Response Architecture • Centrality Detection Engine: Topological discoveries made here. • Network Topology Monitor: This monitors durability, correlation information about link failures, node centralities, routing path centralities • Diagnostic Component: Monitoring computations not resource-intensive trigger more detailed diagnostic monitoring processes, if necessary • Routing Decision Engine: The final forwarding tables constructed as a result of – – – the dictates of the particular routing protocol, the results of the centrality analysis, the network topological analysis, any security policies that may need to be enforced, and the results of any diagnostic tests that may have been triggered.

• Conclusions – Centrality descriptions abstract global network control behavior locally at a router. – Capturing changing centrality description of routing topology will enable detection of some large scale network wide routing attacks. – Detection can occur early, before the changed forwarding tables are in place and packet forwarding occurs. – Subverting such monitoring, while causing a network wide attack, is harder because of this abstraction. – Given nature of information being abstracted, centrality-based monitoring might not detect attacks where the compromised routers are selectively misrouting packets; such attacks would typically not have a disruptive effect on the network.

Verification • Verification provides a formal proof of the security provided by the spec-based mechanisms. • Requires formal statements of: – – Unix security policy Behavior of monitored programs Behavior of monitored system calls Assumptions, e. g. , “/bin/passwd” writes correct password

Reasoning About the Constraints Security Policy Top level constraints Constraints Specification of systems Operational assumptions Security Policy Attack Monitoring Implementation

Overview of Verification Methodology • Goal: Use formal methods to reason about the completeness of specifications. • Methodology: Show specifications and other information project up to a UNIX access control policy • Unix access control policy: Subjects can access only those objects allowed by file permissions. • Access control policy defined by rules for Kuang and Net-Kuang Specification-based intrusion detection system will, then, detect any activity that would violate the Unix policy

Reason from bottom up: an Example Program-based Access Policy (user, program, access, object) Constraints

Automated Response to Attacks

Directed Search DETECT MODIFY SPECIFICATIONS RESPOND LEARN

Why Automated Response? • Immediate: contain the attack quickly. Gain some time before human intervention. – Kill offending process. – Slow down the attacker. – Roll back to a safe state, etc. • Prevent the same attack from happening on this system. – Tighten IDS specs on certain programs. – Report the attack to other security systems (firewalls, IDS’s, JIGSAW, etc). • Long term: generalize the attack and warn others. – Synthesize an attack signature and report it. – Deceive and study the attacker. • It needs to be done carefully – High cost of false positives – can be used for DOS attacks – Weighing cost of response against potential attack damage

Extending IDS to Support Response alerts IDS GUI correlate & prevent study select system calls immediate response JIGSAW, Firewalls, etc. Deception System Generic Software Wrappers Linux Kernel system calls

Spec Example: chfn utility • A recent flaw in chfn creates a race condition on a temp file • That could be used to cause buffer overflow, start a shell, setuid root • SHIM catches setuid call before it is done, currently does not respond • Possible responses to setuid: – – – change permissions kill the process kill the shell reboot the system block the user start checkpointing slow down the process(es) roll back return a random result perform a random action tunnel to a sandbox -> (OPEN_RD, World. Readable($F. mode)) | (OPEN_RD, Is. File($F. path, "/etc/shadow")) | (OPEN_RW, $F. path == "/var/run/utmp") | (OPEN_WR, Created. By. Proc($P. pid, &$F)) | (chown, Created. By. Proc($P. pid, &$F)) | (chmod, Created. By. Proc($P. pid, &$F)) | (link, Created. By. Proc($P. pid, &$F)) | (unlink, Created. By. Proc($P. pid, &$F)) | (rename, Is. File($F. path, "/etc/passwd")) | (read || write) | (socket) | (connect) | (exit) | (setuid || execve) { alert(3, "Really bad operation", $$); } ; END;

Response: Project Plan • Current progress – Defined the problem and the scope of study – Initial experiments with IDS: hard-coding immediate response – Collecting material on the web page: http: //wwwcsif. cs. ucdavis. edu/~balepin • Work to be done – Declarative response specifications – Experiments to determine effectiveness of response

JIGSAW -- Scenario Attack Correlation

Technical Objectives • Create a model for scenario attacks focusing on how the capabilities provided by single point attacks combine to accomplish higher order objectives. • Use model to drive intrusion detection, vulnerability analysis and attack generation efforts. • Understand issues surrounding complex, multi-stage attacks. • Set stage for higher level reasoning

Technical Approach -- Overview • Model scenario attacks as “graph” of events, sub-goals, and policy violations linked by the capabilities the attack concepts provide. • Model based signature analysis. • New single point attack specifications integrate into model without additional effort.

Example w/ Capabilities Connection Spoofed Connection Remote Login cat + + >> /. rhosts Packet Spoofing Seq # Probe Remote Execution RSH Active Spoofed Packet Seq. Number Guess RSH Connection Spoof Execute Commands Prevent Connection Response Example attack composed of multiple concepts and capbilities Forged Src Address Forging Synflood

Technical Approach -- Details • Model of scenario attacks created using Jigsaw – Domain specific language for specifying the capabilities required for some sub-goal, and the capabilities the sub-goal provides for continuing attacks • Inference Engine uses Jess/Java – Efficient, flexible system – Allows both UNIX and Windows Implementations • System/Network configuration in external DB. Imported into I. E. as needed via queries and system probes.

Capability Linkage Capabilities Events Concepts

IDS Architecture JIGSAW to I. E. Translator Attack Model Specification DBS to I. E. Translator Inference Engine System & Network Specification Jess Query Probe Interface DBS JIGSAW User Interface CISL Sensor Array CIDF Components Test File CIDF Other Input Sensor to I. E. Preprocessor

JIGSAW Concept Template [abstract] concept [extends concept_name] requires [sensor|capability|config] + with end; provides + with * end; action * [reportable ] end; end.

RSH Connection Spoofing - Jigsaw concept RSH_Connection_Spoofing requires Trusted_Partner: TP; Service_Active: SA; Network_DOS: ND; Seq. Num. Probe: SNP; Forged. Packet. Send: FPS; with TP. service is RSH, #- The service in the trust relation is RSH ND. host is TP. trusted, #- The blocked host is the trusted partner FPS. dst. host is TP. trustor, #- The spoofed packets are sent to the trustor SNP. dst. host is TP. trustor, #- The probed host is the trustor FPS. src is [ND. host, ND. port] #- claimed source of forged packets is blocked SNP. dst is [SA. host, SA. port] #- The probed host must be running RSH on the SA. port is TCPRSH, #- normal port SA. service is RSH, # SNP. dst is FPS. dest #- probed host must be where forged packets are sent active(FPS) during active(ND) #- forged packets must be sent while DOS is active end; provides push_channel : PSC; remote_execution : REX; with PSC. from <- FPS. true_src; #- Capability to move code from attacker to RSH server PSC. to <- FPS. dst; #- PSC. using <- RSH; # REX. from <- FPS. true_src; #- Capability to execute code on remote host REX. to <- FPS. dst; #REX. using <- RSH; #-

RSH Connection Spoofing - Jess (defrule ) rsh_connection_spoofing (trusted_partner (service rsh) (trusted ? tp_trusted) (trustor ? tp_trustor)) (service_active (service ? sa_service&rsh) (host ? sa_host&? tp_trustor) (port ? sa_port&tcp-rsh)) (network_dos (host ? nd_host&? tp_trusted) (port ? nd_port) (startt ? nd_startt) (endt ? nd_endt)) (forged_packet_send (src_host ? fps_src_host&? nd_host) (src_port ? fps_src_port) (dst_host ? fps_dst_host&? tp_trustor) (dst_port ? fps_dst_port&tcp-rsh) (true_src_host ? fps_true_src_host) (true_src_port ? fps_true_src_port) (startt ? fps_startt) (endt ? fps_endt)) (test (or (eq ? fps_src_port ? nd_port) (eq ? nd_port *))) (test (and (>= ? fps_startt ? nd_startt) (<= ? fps_endt ? nd_endt))) ; active(fps) during active( nd) (seq_num_probe (dst_host ? snp_dst_host&? sa_host&? fps_dst_host) (dst_port ? snp_dst_port&? sa_port&? fps_dst_port)) => (assert (push_channel (from_host ? fps_true_ src_host) (from_port ? fps_true_src_port) (to_host ? fps_dst_host) (to_port ? fps_dst_port) (using rsh) (startt ? fps_startt))) (assert (remote_execution (from_host ? fps_true_ src_host) (from_port ? fps_true_src_port) (to_host ? fps_dst_host) (to_port ? fps_dst_port) (using rsh) (startt ? fps_startt)))

Detecting Spoofed Packets A problem believed to be difficult for intrusion detection

Detecting Spoofed Packets: Motivation • “Next-generation” ID approaches require greater information than predecessors. • Appropriate IDS sensors are not available • Require inference about external entities and local entities when direct sensing is not available • Examples – – – Knows/Has _____ Same source Exploitable _____ exists Sniffer active Spoofed packet Successful exploit • e. g. Forged TCP handshake

What is a “Spoofed Packet” • Packets sent by an attacker such that the true source is not authentic – MAC spoofing – IP packet spoofing – Email spoofing • Not same as routing attacks – These cause packets to be redirected • e. g. DNS cache poisoning; router table attacks; ARP spoofing • This talk will focus on IP source address spoofing

IP/TCP Header Review IP Header Format version header length TOS identification TTL total length flags protocol fragment offset header checksum source IP address destination IP address options (if any) data 20 bytes

IP/TCP Header Review TCP Header Format source port number destination port number sequence number acknowledgement number header length reserved U A P R S F R C S S Y I G K H T N N TCP checksum window size urgent pointer options (if any) data (if any) 20 bytes

Significance • Spoofed packets are a part of many attacks – SYN-flood – Smurf Attack – Connection Spoofing – Bounce Scanning – Stealth Communication

SYN-flood • TCP Handshake Review SYN – client • sends SYN packet to server • waits for SYN-ACK from server – server SYN-ACK • responds w/ SYN-ACK packet • waits for ACK packet from client – client • sends ACK to server ACK

SYN-flood TCP Buffers • Attacker causes TCP buffer to be exhausted w/ halfopen connections • No reply from target needed, so source may be spoofed. • Claimed source must not be an active host. 169. 237. 5. 23 168. 150. 241. 155 169. 237. 7. 114 Half-open connection; Waiting for ACK Completed handshake; connection open empty buffer

SYN-flood TCP Buffers • Attacker causes TCP buffer to be exhausted w/ halfopen connections • No reply from target needed, so source may be spoofed. • Claimed source must not be an active host. 128. 120. 254. 1 128. 120. 254. 2 128. 120. 254. 3 128. 120. 254. 4 128. 120. 254. 5 128. 120. 254. 6 128. 120. 254. 7 128. 120. 254. 8 128. 120. 254. 9 128. 120. 254. 10 128. 120. 254. 11 128. 120. 254. 12 128. 120. 254. 13 128. 120. 254. 14 169. 237. 7. 114 128. 120. 254. 15 Half-open connection; Waiting for ACK Completed handshake; connection open empty buffer

Smurf Attack • Allows attacker to send flood target w/ ICMP packets • Attacker does not need to see returned packets. • Uses network broadcast address as packet amplifier. • Claimed source address is address of target. Attacker sends an ICMP echo request to a particular IP address Source address is set to target host

Smurf Attack • Allows attacker to send flood target w/ ICMP packets • Attacker does not need to see returned packets. • Uses network broadcast address as packet amplifier. • Claimed source address is address of target. ICMP echo request causes an ICMP echo reply to be sent to target

Smurf Attack • Allows attacker to send flood target w/ ICMP packets • Attacker does not need to see returned packets. • Uses network broadcast address as packet amplifier. • Claimed source address is address of target. Because destination address was the network broadcast address, a large number of hosts flood target with ICMP echo replies.

TCP Connection Spoofing • TCP Handshake Review – client • sends SYN packet and ACK number to server • waits for SYN-ACK from server w/ matching ACK number – server • responds w/ SYN-ACK packet w/ initial “random” sequence number • waits for ACK packet from client with matching sequence number – client • sends ACK to server w/ matching sequence number (and data) SYN ack-number SYN-ACK seq-number ack-number ACK seq_number ack-number+data

Connection Spoofing • Allows attacker to send data to a target as if it originated with a trusted host • Requires guessing sequence numbers. • Attacker does not see returned packets; attacker must infer/guess what is sent. Attacker causes DOS on intermediate (the trusted host)

Connection Spoofing • Allows attacker to send data to a target as if it originated with a trusted host • Requires guessing sequence numbers. • Attacker does not see returned packets; attacker must infer/guess what is sent. Attacker sends spoofed packet to target with a claimed source of the intermediate.

Connection Spoofing • Allows attacker to send data to a target as if it originated with a trusted host • Requires guessing sequence numbers. • Attacker does not see returned packets; attacker must infer/guess what is sent. Target sends SYN-ACK reply to intermediate. Because of DOS, intermediate does not see packet and does not reply (w/ RST)

Connection Spoofing • Allows attacker to send data to a target as if it originated with a trusted host • Requires guessing sequence numbers. • Attacker does not see returned packets; attacker must infer/guess what is sent. Attacker sends ACK packet to target with guessed sequence number (+data)

Bounce Scanning • Allows attacker to scan a target without revealing the true source of the scan • Requires an intermediate host with little traffic • Relies on change pattern of IP ID (fragmentation ID) • Attacker sees effects; does not need to see actual returned packet Attacker sends packets to intermediate, monitoring IP ID in replies. (e. g. TCP SYN Packets)

Bounce Scanning • Allows attacker to scan a target without revealing the true source of the scan • Requires an intermediate host with little traffic • Relies on change pattern of IP ID (fragmentation ID) • Attacker sees effects; does not need to see actual returned packet Attacker sends SYN packet with spoofed source address to scan target

Bounce Scanning • Allows attacker to scan a target without revealing the true source of the scan • Requires an intermediate host with little traffic • Relies on change pattern of IP ID (fragmentation ID) • Attacker sees effects; does not need to see actual returned packet Target sends SYN-ACK to intermediate if port is open, RST otherwise.

Bounce Scanning • Allows attacker to scan a target without revealing the true source of the scan • Requires an intermediate host with little traffic • Relies on change pattern of IP ID (fragmentation ID) • Attacker sees effects; does not need to see actual returned packet ? If intermediate receives a RST nothing happens. If intermediate receives a SYNACK, it will send a RST and increment its IP ID

Bounce Scanning • Allows attacker to scan a target without revealing the true source of the scan • Requires an intermediate host with little traffic • Relies on change pattern of IP ID (fragmentation ID) • Attacker sees effects; does not need to see actual returned packet Attacker sends packets to intermediate, monitoring IP ID in replies. If ID incremented by 1, port was closed If ID incremented by 2, port was open

Stealth Communication • Allows attacker to send data to a target as if it originated from an arbitrary host • Uses TTL timeout. • Attacker does not need to see returned packets. • Packets sent to target do not have a spoofed source address. • Info for target passed as ICMP data (original IP header + 8 bytes data). Attacker sends packet to arbitrary host, w/ source address spoofed to be target.

Stealth Communication • Allows attacker to send data to a target as if it originated from an arbitrary host • Uses TTL timeout. • Attacker does not need to see returned packets. • Packets sent to target do not have a spoofed source address. • Info for target passed as ICMP data (original IP header + 8 bytes data). Packet is passed between routers toward destination

Stealth Communication • Allows attacker to send data to a target as if it originated from an arbitrary host • Uses TTL timeout. • Attacker does not need to see returned packets. • Packets sent to target do not have a spoofed source address. • Info for target passed as ICMP data (original IP header + 8 bytes data). Each hop decrements TTL. When TTL reaches zero, packet is dropped an ICMP TTL-expired message is sent to claimed sender.

Detection Methods • Routing-based • Active – proactive – reactive • Passive

Routing-based Methods • For a given network topology certain source IP addresses should never be seen – Internal addresses arriving on external interface – External addresses arriving on internal interface – IANA non-routable addresses on external interface – Other special addresses External NIC Internal NIC

Special Addresses • • • 0. 0/8 127. 0. 0. 0/8 169. 254. 0. 0/16 172. 16. 0. 0/12 192. 0/24 192. 168. 0. 0/16 240. 0/5 248. 0. 0. 0/5 255/32 - Historical Broadcast - RFC 1918 Private Network - Loopback - Link Local Networks - RFC 1918 Private Network - TEST-NET - RFC 1918 Private Network - Class E Reserved - Unallocated - Broadcast

Routing-based Methods • Most commonly used method – firewalls, filtering routers • Relies on knowledge of network topology and routing specs. • Primarily used at organizational border. • Cannot detect many examples of spoofing – Externally spoofed external addresses – Internally spoofed internal addresses

Proactive methods • Looks for behavior that would not occur if client actually processed packet from server. • Method: change IP stack behavior • Can observe suspicious activity • Examples – – TCP window games – SYN-Cookies (block w/o detection)

TCP Window Games SYN • Modified TCP Handshake – client • • – server • • • – sends SYN packet and ACK number to server waits for SYN-ACK from server w/ matching ACK number responds w/ SYN-ACK packet w/ initial “random” sequence number Sets window size to zero waits for ACK packet from client with matching sequence number • • SYN-ACK seq-number, ack-number window = 0 ACK seq_number, ack-number (no data) ACK client • ack-number sends ACK to server w/ matching sequence number, but no data Waits for ACK w/ window > 0 After receiving larger window, client sends data. Spoofer will not see 0 -len window and will send data without waiting. seq-number, ack-number window = 4096 ACK seq_number, ack-number w/ data

SYN-Cookies • • Modified TCP Handshake Example of “stateless” handshake – • • SYN-ACK responds w/ SYN-ACK packet w/ initial SYN-cookie sequence number Sequence number is cryptographically generated value based on client address, port, and time. No TCP buffers are allocated NO BUFFER ALLOCATED client • – sends SYN packet and ACK number to server waits for SYN-ACK from server w/ matching ACK number server • – ack-number client • • – SYN sends ACK to server w/ matching sequence number seq-number as SYN-cookie, ack-number ACK seq_number ack-number+data server • • If ACK is to an unopened socket, server validates returned sequence number as SYN-cookie If value is reasonable, a buffer is allocated and socket is opened. . Spoofed packets will not consume TCP buffers SYN-ACK seq-number, ack-number TCP BUFFER ALLOCATED

Reactive methods • When a suspicious packet is received, a probe of the source is conducted to verify if the packet was spoofed • May use same techniques as proactive methods • Example probes – – Is TTL appropriate? Is ID appropriate? Is host up? Change window size

Passive Methods • Learn expected values for observed packets • When an anomalous packet is received, treat it as suspicious • Example values – – Expected TTL – Expected client port – Expected client OS idiosyncrasies

Experiments • determine the validity of various spoofedpacket detection methods • Predictability of TTL (active) • Predictability of ID (active)

Experiment Description - Passive • Monitor network traffic • Record – Source IP address – TTL – Protocol • Count occurrences of all unique combinations • Statistically analyze predictability of the data

Results - Passive • Data collected over several 2 week periods – data being reported: finals + spring break • Seclab traffic at Olympus • 23, 000 IP packets observed – 23461 source IP addresses • 110 internal • 23351 external

Results - Passive • Predictability measure – Conditional Entropy (unpredictability) • Values closer to zero indicate higher predictability

Results - Passive All packets Protocol H mean H variance Number Addresses Number Packets All 0. 055759 0. 029728 23461 22999999 ICMP 0. 027458 0. 023726 801 223341 IGMP 0 0 23 297 TCP 0. 046149 0. 023114 15891 20925893 UDP 0. 065164 0. 040655 7397 1850468

Results - Passive External addresses only Protocol H mean H variance Number Addresses Number Packets All 0. 055505 0. 029731 23351 9229608 ICMP 0. 026159 0. 023271 780 88371 IGMP 0 0 3 26 TCP 0. 046324 0. 023201 15825 8857983 UDP 0. 065537 0. 041015 7306 283228

Results - Passive Internal Addresses Only H mean H variance Number Addresses Number Packets 0. 109633 0. 026097 110 13770391 0. 075714 0. 03822 21 134970 0 0 20 271 0. 004189 Protocol 0. 000321 66 12067910 0. 035207 0. 010859 91 1567240 All ICMP IGMP TCP UDP

Results - Passive Only Addresses w/ more than 250 packets Protocol H mean H variance Number Addresses Number Packets All 0. 060041 0. 035521 2876 22338795 ICMP 0. 035778 0. 020212 33 219605 IGMP 0 0 1 0 TCP 0. 051132 0. 027288 2713 20332940 UDP 0. 165818 0. 175238 148 1779896

Results - Passive Only Addresses w/ more than 500 packets Protocol H mean H variance Number Addresses Number Packets All 0. 050635 0. 031506 2306 22140140 ICMP 0. 022401 0. 014516 30 218560 IGMP 0 0 1 0 TCP 0. 042716 0. 022273 2190 20150197 UDP 0. 164326 0. 209436 104 1764716

Results - Passive • TTL differs by protocol • UDP most unreliable – traceroute is major contributor (can be filtered) – certain programs set TTL anomalously – To. S may be useful in reducing inconsistencies • TTL on local network highly regular – must filter traceroute traffic

To. S Review priority minimize delay maximize throughput maximize reliability Minimize $$ cost • May differ by protocol and service – – Telnet: DNS - UDP: DNS - TCP: NNTP: 1 1 0 0 0 0 1 reserved

Experiment Description Reactive • Monitor network traffic • Record IP address, Protocol, TTL and ID • Send probe packet(s) – ICMP echo reply packet – TCP syn packet – UDP packet • Note the differences between the stored TTL/ID to that of the returning probes.

Results - Reactive • Evaluate – – initial vs. probe reply TTL – Initial vs. probe reply ID (delta from original) • Predictability measure – Conditional Entropy (unpredictability) • Values closer to zero indicate higher predictability

Results - Reactive • Preliminary only – Ran for 18 hours – 8058 probes sent – 218 unique addresses • 173 external • 45 internal

Results - Reactive • TTL off by: – Total # probes 8058 1591 – +/- 2 or less 6467 371 80% – +/-1 or less 6096 986 75% – 0 5110 63%

Results - Reactive • ID off by: – Total # probes 8058 – – – – Offset 1 2 4 6 5 7 8 Count 601 57 21 16 14 11 9 – – – Offset 256 512 768 1280 Count 73 5 22 10

Future and Ongoing Work • Complete and evaluate reactive experiments • Evaluate predictability of unobserved IP addresses using neural network or other ML method. • Complete and test SPD program – Monitor network traffic – Determine if packet is suspicious using passive system – If suspicious, use reactive methods to determine if packet was spoofed.

Conclusion • Spoofed-packets used in many different attacks • Spoofed-packets can be detected by a number of methods • High predictability in TTL and ID allow use of passive and active methods

Protocols to Defend Against a Fast Moving Worm Objectives • Block worm from compromising more than 10% of vulnerable sites • Little performance impact on normal traffic • Scalable to very large networks A real application for intrusion detection and response

Approach • Specification-based intrusion detection at host and network components • Correlation of IDS reports to determine if wormlike traffic is present • Distributed decision making • Scalable “friends” protocol to transmit reports, results of correlation, actions taken by components • Blocking of suspicious packets at border gateways or firewalls

Peer based strategies • Built from small collections of partners with limited trust sharing information. – Cooperating enterprise boundary controllers: commercial, government, military, university – Cooperating personal firewalls: home, office and wireless. – Mobile military computing devices: laptops, PDAs • Features of peer-to-peer mitigation strategies – – Single compromised or malicious partners carry less weight Network topology details are less important No global optimization of mitigation measures Creates a kind of White Worm to fight back

Preliminary Simulation • Based upon Swarm biological agent simulation package • Evaluate the ability of mitigation strategies to suppress worms • Cooperative mitigation strategy parameters – # of friends – Time step to cost reducing backoff – Time to cleanup and recovery • Simple worm model parameters – Initial density – Likelihood of success – Scanning method (permutative, random) – Propagation speed

4 Friends

8 Friends

16 Friends

Cost Reducing Backoff

Response with Ambient False Alarms

Hierarchical Cooperation • • Graphs abstract network activity Configurable rulesets determine when graphs combine Host-based data is included as node attributes Attack assessment is made using global aggregated graph attributes. Network based reports Data Sources: spurr Host based reports kanab Ruleset Correlation Aggregated graph: spurr kanab R olympus erebus R R sierra tallac

Hierarchical Aggregation/Correlation • Graph building engines arranged in a hierarchy • Unresolved graph fragments propagate up Audits Widgets Inc. Payroll Audits A Human Resources Financial Office of CFO Personnel B Training Office of CFO H Audits x, y, . . . J I Payroll E F Office of CFO Payroll x, y, . . . C G D

Scalability • • • All data sources reside at the bottom of the hierarchy Rulesets accept everything with destination port < 1023 & != 80 Report volume at each engine is measured in proportion to the average input report volume. 1. 3 1. 6 0. 79 1. 0 0. 80 0. 79 Data source input traffic volume is defined to be one. 1. 0

Hierarchical Mitigation • Authority/Subordinate relationship • Summarized, reduced alarms flow up • Mitigation directives flow down • Large numbers of uninfected sites can be protected in a short time period • Top node could be the CCDC • Hybrid systems with both hierarchical and peer based cooperation may perform best.

Issues and Goals • Which cooperative mitigation strategies are effective against different worm types? • Mitigation strategies influence detection strategy. • Scalable to very large networks • Cost effectiveness – Performance in the face of false alarms – Cure isn’t worse than the disease • Cooperative trust protocol useful at many levels – – Small personal groups of users ISP to customer security Security manager to client CCDC control hierarchies

Analysis Topics • Learning from worm instances: Melissa Danforth, Jeff Rowe, Karl Levitt, Jim Just • Information Visualization of Worm Traffic: Kwan-Liu Ma, Felix Wu, Soon Tee Teoh • Static Analysis of Code to Detect Potential for Specific Malicious Activity: Raymond Lo, Ron Olsson, Karl Levitt