Transcript UC Davis MURI Team - University of California, Davis

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)
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
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
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
(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
User
constraints
Constraints
Access
constraints
Program
constraints
Data
constraints
Protocol
constraints
Application
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, 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
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
Ethernet Driver
(5) ARP reply
ARP
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: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).
Malformed ARP Request
ARP REQUEST WHO-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.
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: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: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
ARP Request
i
ARP Response
reply_wait
ARP cache timeout
cached
Monitoring for Intrusions
Unsolicitied ARP
Response
Malformed
Request
alarm
ARP Request
ARP Request
i
Bogus ARP
Response
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, 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
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 (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.
• 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 QoS 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
Constraints
Constraints
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
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
<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;
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
Execute
Commands
Connection
Spoof
RSH
Connection
Spoof
Spoofed
Connection
Remote
Execution
Remote
Login
RSH
Active
Spoofed
Packet
cat + + >> /.rhosts
Packet
Spoofing
Seq. Number
Guess
Seq # Probe
Prevent
Connection
Response
Example attack
composed of multiple
concepts and capbilities
Forged Src
Address
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 <concept_name> [extends concept_name]
requires
[sensor|capability|config] <CapabilityTypes:LABEL_LIST>+
with
<expression list>
end;
provides
<CapabilityTypes:LABEL_LIST>+
with
<assignments>*
end;
action
<external actions>*
[reportable <when|unless> <condition>]
end;
end.
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,
ND.host is TP.trusted,
FPS.dst.host is TP.trustor,
SNP.dst.host is TP.trustor,
FPS.src is [ND.host,ND.port]
#####-
The service in the trust relation is RSH
The blocked host is the trusted partner
The spoofed packets are sent to the trustor
The probed host is the trustor
claimed source of forged packets is blocked
SNP.dst is [SA.host,SA.port]
SA.port is TCP\RSH,
SA.service is RSH,
#- The probed host must be running RSH on the
#normal port
#-
SNP.dst is FPS.dest
#- probed host must be where forged packets are sent
active(FPS) during active(ND)
end;
provides
push_channel
: PSC;
remote_execution : REX;
with
PSC.from <- FPS.true_src;
PSC.to
<- FPS.dst;
PSC.using<- RSH;
REX.from <- FPS.true_src;
REX.to
<- FPS.dst;
REX.using<- RSH;
end;
end.
#- forged packets must be sent while DOS is active
#- Capability to move code from attacker to RSH server
###- Capability to execute code on remote host
##-
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
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
Detection Methods
• Routing-based
• Active
– proactive
– reactive
• Passive
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