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 Kirchoffs 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
(1) FTP
resolver
(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
ARP REPLY to victim blanc.cs.ucdavis.edu IS-AT
080020237152

• ARP reply will be accepted by a victim machine,
  even though it hasnt sent a request.
• Sending a arbitrary IP to Ethernet mapping will
  poison the victims ARP cache.
• Sending an unsolicited response to the broadcast
  ethernet address poisons the cache of all
  machines (Solaris, Windows, Linux).

15
Malformed ARP Request
ARP REQUEST WHO-HAS olympus.cs.ucdavis.edu TELL
blanc.cs.ucdavis.edu at 080020237152

• ARP implementations cache entries based upon
  broadcast requests.
• Even if the host isnt 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 everyones cache.

16
Bogus Response
ARP REQUEST WHO-HAS blanc.cs.ucdavis.edu TELL
gunnbjornfeld.cs.ucdavis.edu at 08002071FE95
ARP REPLY to gunnbjornfeld blanc.cs.ucdavis.edu
IS-AT 080020FFFFFF

• Attacker waits till a victim (gunnbjornfeld)
  issues an ARP request.
• Race condition can be exploited by the attacker
  in sending the response.

17
Bogus Requests and Responses
ARP REQUEST WHO-HAS blanc.cs.ucdavis.edu TELL
gunnbjornfeld.cs.ucdavis.edu at 08002071FE95
ARP REPLY to gunnbjornfeld blanc.cs.ucdavis.edu
IS-AT 080020FFFFFF

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

18
Gratuitous ARP

• Some machines will send ARP requests where the
  source and target IPs 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
reply_wait
cached
ARP Request
ARP Response
ARP cache timeout
20
Monitoring for Intrusions
alarm
Bogus ARP Response
Unsolicitied ARP Response
Malformed Request
ARP Request
i
reply_wait
cached
ARP Request
ARP Response
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(n3) time and O(n2) 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(enlog(n)))
  time and O(ne) 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
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
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, IDSs, 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
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

• ltvalidopgt
• -gt (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

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
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
51
IDS Architecture
JIGSAW to I. E. Translator
DBS to I. E. Translator
Attack Model Specification JIGSAW
System Network Specification DBS
Query
Probe
User Interface
CISL
Sensor Array
CIDF Components
CIDF
Test File
Other Input
Sensor to I. E. Preprocessor
52
JIGSAW Concept Template

• abstract concept ltconcept_namegt extends
  concept_name
• requires
• sensorcapabilityconfig ltCapabilityTypesLABE
  L_LISTgt
• with
• ltexpression listgt
• end
• provides
• ltCapabilityTypesLABEL_LISTgt
• with
• ltassignmentsgt
• end
• action
• ltexternal actionsgt
• reportable ltwhenunlessgt ltconditiongt
• end
• end.

53
RSH Connection Spoofing - Jigsaw

• concept RSH_Connection_Spoofing
•  
• requires
• Trusted_Partner TP
• Service_Active SA
• Network_DOS ND
• SeqNumProbe SNP
• ForgedPacketSend 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 TCP\RSH, - normal port
• SA.service is RSH, -
•  

54
RSH Connection Spoofing - Jess

• (defrule rsh_connection_spoofing
• (trusted_partner (service rsh) (trusted
  ?tp_trusted)
• (trustor ?tp_trustor))
• (service_active (service ?sa_servicersh)
• (host ?sa_host?tp_trustor)
• (port ?sa_porttcp-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_porttcp-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 )))

55
Detecting Spoofed Packets
56
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

57
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

58
IP/TCP Header Review
IP Header Format
version
TOS
header length
total length
identification
fragment offset
flags
header checksum
TTL
protocol
20 bytes
source IP address
destination IP address
options (if any)
data
59
IP/TCP Header Review
TCP Header Format
source port number
destination port number
sequence number
acknowledgement number
20 bytes
header length
reserved
window size
TCP checksum
urgent pointer
options (if any)
data (if any)
60
Significance

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

61
Detection Methods

• Routing-based
• Active
• proactive
• reactive
• Passive

62
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

63
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

64
Approach

• Specification-based intrusion detection at host
  and network components
• Correlation of IDS reports to determine if
  worm-like 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