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