UC Davis MURI Team

1. UC Davis MURI Team • PI: Karl Levitt • Research Staff: Poornima Balasubramanyam, Jeff Rowe • Graduate Students: • Dustin Lee (MS) • Melissa Danforth (PhD) • Tao Song (PhD) • Steven Templeton (PhD) • Marcus Tylutki (PhD) • C.G. Senthilkumar (MS) • Daisuke Nojiri (PhD) • Ivan Balepin (PhD)

2. Who We Are UC Davis Computer Security Laboratory • 10 faculty with interests in security • Graduates: 30PhD, 56MS • Currently: 25PhD, 30MS • Classes: 11graduate, 1undergradute • NSA Center Excellence University since 1998

3. Accomplishments of UCD Security Laboratory • Intrusion Detection (IDS) : • First: Network Security Monitor, Network IDS, Large scale IDS • Specification-Based IDS: Can detect unknown attacks, applied to privileged programs, protocols, applications • JIGSAW: Language for compositional specification of scenario attacks • Currently working on automated response • Taxonomy of Vulnerabilities • Static Analysis of Source Code for Security Vulnerabilities • Verification of Cryptographic Protocols

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

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

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

7. Useful Types of Constraints (cont.) • 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 semantic • Data Integrity • e.g., passwords, other authentication information • authorization information, process table

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

9. 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, lpr, lprm, lpq, fingerd, at, 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

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

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

12. 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 (2) Establish connection w/ IP address IP addr 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 Ethernet Driver (5) ARP reply ARP ARP IP TCP

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

14. Unsolicited ARP Response ARPREPLY to victim blanc.cs.ucdavis.eduIS-AT08:00:20: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).

15. Malformed ARP Request ARPREQUESTWHO-HAS olympus.cs.ucdavis.edu TELL blanc.cs.ucdavis.edu at 08:00:20: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.

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

17. Bogus Requests and Responses ARPREQUESTWHO-HAS; blanc.cs.ucdavis.edu TELL gunnbjornfeld.cs.ucdavis.edu at 08:00:20:71:FE:95 • 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. ARPREPLY to gunnbjornfeld; blanc.cs.ucdavis.eduIS-AT08:00:20:FF:FF:FF

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

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

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

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

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

23. Security Threats • Illegal attempt to infiltrate the routing process – outsider attacks • attacks that modify the routing information • cause redirection of the network traffic, DoS 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

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

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

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

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

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

29. Ongoing Work • Augmented current link-state algorithm (rtProtoLS) 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.

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

31. 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 QoS metric to prevent traffic congestion)

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

33. Intrusion Monitoring and Adaptive ResponseArchitecture • 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.

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

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

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

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

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

39. Automated Response to Attacks

40. Directed Search DETECT MODIFY SPECIFICATIONS RESPOND LEARN

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

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

43. 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 <validop> -> (OPEN_RD, WorldReadable($F.mode)) | (OPEN_RD, IsFile($F.path, "/etc/shadow")) | (OPEN_RW, $F.path == "/var/run/utmp") | (OPEN_WR, CreatedByProc($P.pid, &$F)) | (chown, CreatedByProc($P.pid, &$F)) | (chmod, CreatedByProc($P.pid, &$F)) | (link, CreatedByProc($P.pid, &$F)) | (unlink, CreatedByProc($P.pid, &$F)) | (rename, IsFile($F.path,"/etc/passwd")) | (read || write) | (socket) | (connect) | (exit) | (setuid || execve) { alert(3, "Really bad operation", $$); } ; END; Spec Example: chfn utility

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

45. JIGSAW-- Scenario Attack Correlation

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

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

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

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

50. Capability Linkage Capabilities Events Concepts