uc davis muri team pi: karl levitt research staff: poornima balasubramanyam, jeff rowe graduate...
Post on 20-Dec-2015
214 views
TRANSCRIPT
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
Protocols
IntrusionDetection
and Response
• on routers• multiple state (scenario)• worms
UC DAVIS - Security of ProtocolsUC DAVIS - Security of Protocols
Attacks
Cryptographic Protocols
Phil RogawayMatt Franklin
SecurityVerification
SecurityProtocol
Workbench
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– authorization information, process table
ConstraintsUser
constraints
Data constraints
Application constraints
Protocol constraints
Program 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, 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.
(1) FTP
TCP
ARP IP
resolver
Ethernet Driver
Ethernet Driver Ethernet Driver
ARPARP
IP
TCP
hostname
IP addr (2) Establish connection w/ IP address
(3) Send IP datagram to IP address
(4) ARP broadcast request for IP address to Eth address mapping
(5) ARP reply
(6) Eth address assigned to IP address
(7) Packet sent
ARP Cache Poisoning
• Unsolicited Response
• Malformed Request
• Bogus Response
• Both a spurious Request and a spurious Response
• Gratuitous ARP
Unsolicited ARP Response
• 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).
ARP REPLY to victim blanc.cs.ucdavis.edu IS-AT 08:00:20:23:71:52
Malformed ARP Request
• 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.
ARP REQUEST WHO-HAS olympus.cs.ucdavis.edu TELL blanc.cs.ucdavis.edu at 08:00:20:23:71:52
Bogus Response
• Attacker waits till a victim (gunnbjornfeld) issues an ARP request.
• Race condition can be exploited by the attacker in sending the 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
Bogus Requests and Responses
• 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.
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
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
i reply_wait cached
ARP Request ARP Response
ARP cache timeout
ARP Request
Monitoring for Intrusions
i reply_wait cached
ARP Request ARP Response
ARP cache timeout
alarmUnsolicitied ARP Response
Bogus ARP Response
Malformed Request ARP Request
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
Centrality Detection Engine
Centrality Detection Engine
Diagnostic Component
-Directed Topology Analysis
Diagnostic Component
-Directed Topology Analysis
IncomingRouting Packets
Network Topology Monitor
- spatial, temporal correlation of link failures - network characteristics - protocol characteristics
Network Topology Monitor
- spatial, temporal correlation of link failures - network characteristics - protocol characteristics
Routing Decision Engine
Routing Decision Engine
SecurityPolicies
SecurityPolicies
PacketForwarding Tables Intrusion
Alerts
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.
• 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
Implementation
Operational assumptions
Security Policy
Specification of systems
Attack
Monitoring
Constraints
Security Policy
Top level
constraints
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
Constraints
Program-based Access Policy
(user, program, access, object)
Constraints Constraints Constraints
Automated Response to Attacks
Directed Search
DETECT
RESPOND
MODIFYSPECIFICATIONS
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
Linux Kernel
Generic Software Wrappers
system calls
IDS
select system calls
alerts IDS GUI
DeceptionSystem
JIGSAW,Firewalls,
etc.
JIGSAW,Firewalls,
etc.
immediateresponse
correlate & prevent
study
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
JIGSAWJIGSAW -- Scenario Attack Correlation-- 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 Spoof
Address Forging
ExecuteCommands
Seq # Probe
Packet Spoofing
Synflood
Seq. Number Guess
Prevent Connection Response
RSHActive
Forged Src Address
Spoofed Packet
RSH Connection
SpoofSpoofed
Connection
RemoteLogin
cat + + >> /.rhosts
Remote Execution
Example attack composed of multiple concepts and capbilities
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.
Events
Concepts
Capabilities
Capability LinkageCapability Linkage
IDS Architecture
InferenceEngine
Jess
Interface
AttackModelSpecification
JIGSAW
System &NetworkSpecification
DBS
Query
User InterfaceCISL
CIDFTest File
Other Input
Probe
JIGSAW to I. E.
Translator
DBS to I. E.
Translator
Sensor Array
Sensor to I. E. Preprocessor
CIDF Components
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
requiresTrusted_Partner: TP;Service_Active: SA;Network_DOS: ND;SeqNumProbe: SNP;ForgedPacketSend: FPS;
withTP.service is RSH, #- The service in the trust relation is RSHND.host is TP.trusted, #- The blocked host is the trusted partnerFPS.dst.host is TP.trustor, #- The spoofed packets are sent to the trustorSNP.dst.host is TP.trustor, #- The probed host is the trustorFPS.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 portSA.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 serverPSC.to <- FPS.dst; #- PSC.using<- RSH; #-
REX.from <- FPS.true_src; #- Capability to execute code on remote hostREX.to <- FPS.dst; #-REX.using<- RSH; #-
end;end.
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
identification
header checksum
version TOSheaderlength
destination IP address
source IP address
TTL protocol
options (if any)
fragment offsetflags
total length
IP Header Format
data
20 bytes
IP/TCP Header Review
source port number
headerlength
acknowledgement number
sequence number
options (if any)
destination port number
reserved window size
TCP Header Format
data (if any)
TCP checksum urgent pointer
URG
ACK
PSH
SYN
FIN
RST
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 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