Transcript UC Davis MURI Team

Making Protocols Secure
• Overview: Karl Levitt (UCD)
• Intrusion Detection in Routers: Poornima Balasubramanyam, PhD
(UCD)
• Simulation Experiments for Router Intrusion Detection: Akshay
Aggarwal (UCD)
• Intrusion Detection in Ad hoc Networks: Elizabeth Belding-Royer
(UCSB)
• Mitigating Routing Misbehavior in Ad hoc Networks: Mary Baker
(Stanford)
• Security Multicast Protocols for CORBA: Louise Moser (UCSB)
• Automatic Response to Attacks: Ivan Balepin (UCD)
• Detection of Spoofed Packets, Challenge Problem -- Defense in the
Large: Karl Levitt
Approach to Security
• Prevent, or
• Tolerate
–
–
–
–
Detect, and
Stop attack, and
Fight Back, and
Recover
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
• 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 semantics
• 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
A problem believed to be difficult for
intrusion detection
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
SYN-flood
• TCP Handshake Review
SYN
– client
• sends SYN packet to server
• waits for SYN-ACK from server
– server
SYN-ACK
• responds w/ SYN-ACK packet
• waits for ACK packet from client
– client
• sends ACK to server
ACK
SYN-flood
TCP
Buffers
• Attacker causes TCP buffer
to be exhausted w/ halfopen connections
• No reply from target
needed, so source may be
spoofed.
• Claimed source must not
be an active host.
169.237.5.23
168.150.241.155
169.237.7.114
Half-open
connection;
Waiting for
ACK
Completed
handshake;
connection
open
empty
buffer
SYN-flood
TCP
Buffers
• Attacker causes TCP buffer
to be exhausted w/ halfopen connections
• No reply from target
needed, so source may be
spoofed.
• Claimed source must not
be an active host.
128.120.254.1
128.120.254.2
128.120.254.3
128.120.254.4
128.120.254.5
128.120.254.6
128.120.254.7
128.120.254.8
128.120.254.9
128.120.254.10
128.120.254.11
128.120.254.12
128.120.254.13
128.120.254.14
169.237.7.114
128.120.254.15
Half-open
connection;
Waiting for
ACK
Completed
handshake;
connection
open
empty
buffer
Smurf Attack
• Allows attacker to send
flood target w/ ICMP
packets
• Attacker does not need to
see returned packets.
• Uses network broadcast
address as packet amplifier.
• Claimed source address is
address of target.
Attacker sends an
ICMP echo request to a
particular IP address
Source address is set to target host
Smurf Attack
• Allows attacker to send
flood target w/ ICMP
packets
• Attacker does not need to
see returned packets.
• Uses network broadcast
address as packet amplifier.
• Claimed source address is
address of target.
ICMP echo request
causes an ICMP echo reply
to be sent to target
Smurf Attack
• Allows attacker to send
flood target w/ ICMP
packets
• Attacker does not need to
see returned packets.
• Uses network broadcast
address as packet amplifier.
• Claimed source address is
address of target.
Because destination address
was the network broadcast address,
a large number of hosts flood target
with ICMP echo replies.
TCP Connection Spoofing
• TCP Handshake Review
– client
• sends SYN packet and ACK
number to server
• waits for SYN-ACK from server
w/ matching ACK number
– server
• responds w/ SYN-ACK packet w/
initial “random” sequence number
• waits for ACK packet from client
with matching sequence number
– client
• sends ACK to server w/ matching
sequence number (and data)
SYN
ack-number
SYN-ACK
seq-number
ack-number
ACK
seq_number
ack-number+data
Connection Spoofing
• Allows attacker to send data
to a target as if it originated
with a trusted host
• Requires guessing sequence
numbers.
• Attacker does not see
returned packets; attacker
must infer/guess what is
sent.
Attacker causes DOS on
intermediate (the trusted host)
Connection Spoofing
• Allows attacker to send data
to a target as if it originated
with a trusted host
• Requires guessing sequence
numbers.
• Attacker does not see
returned packets; attacker
must infer/guess what is
sent.
Attacker sends spoofed packet to
target with a claimed source of
the intermediate.
Connection Spoofing
• Allows attacker to send data
to a target as if it originated
with a trusted host
• Requires guessing sequence
numbers.
• Attacker does not see
returned packets; attacker
must infer/guess what is
sent.
Target sends SYN-ACK reply to
intermediate.
Because of DOS, intermediate
does not see packet and does not
reply (w/ RST)
Connection Spoofing
• Allows attacker to send data
to a target as if it originated
with a trusted host
• Requires guessing sequence
numbers.
• Attacker does not see
returned packets; attacker
must infer/guess what is
sent.
Attacker sends ACK packet to
target with guessed sequence
number (+data)
Bounce Scanning
• Allows attacker to scan a
target without revealing the
true source of the scan
• Requires an intermediate
host with little traffic
• Relies on change pattern of
IP ID (fragmentation ID)
• Attacker sees effects; does
not need to see actual
returned packet
Attacker sends packets to
intermediate, monitoring IP
ID in replies.
(e.g. TCP SYN Packets)
Bounce Scanning
• Allows attacker to scan a
target without revealing the
true source of the scan
• Requires an intermediate
host with little traffic
• Relies on change pattern of
IP ID (fragmentation ID)
• Attacker sees effects; does
not need to see actual
returned packet
Attacker sends SYN packet
with spoofed source address
to scan target
Bounce Scanning
• Allows attacker to scan a
target without revealing the
true source of the scan
• Requires an intermediate
host with little traffic
• Relies on change pattern of
IP ID (fragmentation ID)
• Attacker sees effects; does
not need to see actual
returned packet
Target sends SYN-ACK to
intermediate if port is open,
RST otherwise.
Bounce Scanning
• Allows attacker to scan a
target without revealing the
true source of the scan
• Requires an intermediate
host with little traffic
• Relies on change pattern of
IP ID (fragmentation ID)
• Attacker sees effects; does
not need to see actual
returned packet
?
If intermediate receives a RST
nothing happens.
If intermediate receives a
SYN-ACK, it will send a RST
and increment its IP ID
Bounce Scanning
• Allows attacker to scan a
target without revealing the
true source of the scan
• Requires an intermediate
host with little traffic
• Relies on change pattern of
IP ID (fragmentation ID)
• Attacker sees effects; does
not need to see actual
returned packet
Attacker sends
packets to intermediate,
monitoring IP ID in replies.
If ID incremented by 1, port
was closed
If ID incremented by 2, port
was open
Stealth Communication
• Allows attacker to send data
to a target as if it originated
from an arbitrary host
• Uses TTL timeout.
• Attacker does not need to
see returned packets.
• Packets sent to target do not
have a spoofed source
address.
• Info for target passed as
ICMP data (original IP
header + 8 bytes data).
Attacker sends packet to arbitrary
host, w/ source address spoofed
to be target.
Stealth Communication
• Allows attacker to send data
to a target as if it originated
from an arbitrary host
• Uses TTL timeout.
• Attacker does not need to
see returned packets.
• Packets sent to target do not
have a spoofed source
address.
• Info for target passed as
ICMP data (original IP
header + 8 bytes data).
Packet is passed between routers
toward destination
Stealth Communication
• Allows attacker to send data
to a target as if it originated
from an arbitrary host
• Uses TTL timeout.
• Attacker does not need to
see returned packets.
• Packets sent to target do not
have a spoofed source
address.
• Info for target passed as
ICMP data (original IP
header + 8 bytes data).
Each hop decrements TTL.
When TTL reaches zero,
packet is dropped and an
ICMP TTL-expired message
is sent to claimed sender.
Detection Methods
• Routing-based
• Active
– proactive
– reactive
• Passive
Routing-based Methods
• For a given network topology
certain source IP addresses
should never be seen
– Internal addresses arriving on
external interface
– External addresses arriving on
internal interface
– IANA non-routable addresses
on external interface
– Other special addresses
External NIC
Internal NIC
Special Addresses
•
•
•
•
•
•
•
•
•
•
0.0.0.0/8
10.0.0.0/8
127.0.0.0/8
169.254.0.0/16
172.16.0.0/12
192.0.2.0/24
192.168.0.0/16
240.0.0.0/5
248.0.0.0/5
255.255.255.255/32
- Historical Broadcast
- RFC 1918 Private Network
- Loopback
- Link Local Networks
- RFC 1918 Private Network
- TEST-NET
- RFC 1918 Private Network
- Class E Reserved
- Unallocated
- Broadcast
Routing-based Methods
• Most commonly used method
– firewalls, filtering routers
• Relies on knowledge of network topology and
routing specs.
• Primarily used at organizational border.
• Cannot detect many examples of spoofing
– Externally spoofed external addresses
– Internally spoofed internal addresses
Proactive methods
• Looks for behavior that would not occur if
client actually processed packet from server.
• Method: change IP stack behavior
• Can observe suspicious activity
• Examples –
– TCP window games
– SYN-Cookies (block w/o detection)
TCP Window Games
•
Modified TCP Handshake
–
client
•
•
–
server
•
•
•
–
sends SYN packet and ACK number to server
waits for SYN-ACK from server w/ matching
ACK number
responds w/ SYN-ACK packet w/ initial
“random” sequence number
Sets window size to zero
waits for ACK packet from client with
matching sequence number
client
•
•
•
SYN
ack-number
SYN-ACK
seq-number, ack-number
window = 0
ACK
seq_number, ack-number
(no data)
ACK
sends ACK to server w/ matching sequence
number, but no data
Waits for ACK w/ window > 0
After receiving larger window, client sends
data.
Spoofer will not see 0-len window and will send
data without waiting.
seq-number, ack-number
window = 4096
ACK
seq_number, ack-number
w/ data
SYN-Cookies
•
•
Modified TCP Handshake
Example of “stateless” handshake
–
•
•
responds w/ SYN-ACK packet w/ initial SYN-cookie
sequence number
Sequence number is cryptographically generated value
based on client address, port, and time.
No TCP buffers are allocated
client
•
–
sends SYN packet and ACK number to server
waits for SYN-ACK from server w/ matching ACK
number
server
•
–
ack-number
client
•
•
–
SYN
sends ACK to server w/ matching sequence number
SYN-ACK
seq-number as SYN-cookie,
ack-number
NO BUFFER ALLOCATED
ACK
seq_number
ack-number+data
server
•
•
If ACK is to an unopened socket, server validates
returned sequence number as SYN-cookie
If value is reasonable, a buffer is allocated and socket is
opened.
.
Spoofed packets will not consume TCP buffers
SYN-ACK
seq-number, ack-number
TCP BUFFER ALLOCATED
Reactive methods
• When a suspicious packet is received, a probe of
the source is conducted to verify if the packet was
spoofed
• May use same techniques as proactive methods
• Example probes
–
–
–
–
Is TTL appropriate?
Is ID appropriate?
Is host up?
Change window size
Passive Methods
• Learn expected values for observed packets
• When an anomalous packet is received,
treat it as suspicious
• Example values –
– Expected TTL
– Expected client port
– Expected client OS idiosyncrasies
Experiments
• determine the validity of various spoofedpacket detection methods
• Predictability of TTL
• Predictability of TTL (active)
• Predictability of ID (active)
Experiment Description - Passive
• Monitor network traffic
• Record
– Source IP address
– TTL
– Protocol
• Count occurrences of all unique combinations
• Statistically analyze predictability of the data
Results - Passive
• Data collected over several 2 week periods
– data being reported: finals + spring break
• Seclab traffic at Olympus
• 23,000,000 IP packets observed
– 23461 source IP addresses
• 110 internal
• 23351 external
Results - Passive
• Predictability measure
– Conditional Entropy (unpredictability)
H (Y | X )   P( x, y) log P( x | y)
x, y
• Values closer to zero indicate higher
predictability
Results - Passive
All packets
Protocol
H mean
H variance
Number
Addresses
Number
Packets
All
0.055759
0.029728
23461
22999999
ICMP
0.027458
0.023726
801
223341
IGMP
0
0
23
297
TCP
0.046149
0.023114
15891
20925893
UDP
0.065164
0.040655
7397
1850468
Results - Passive
External addresses only
Protocol
H mean
H variance
Number
Addresses
Number
Packets
All
0.055505
0.029731
23351
9229608
ICMP
0.026159
0.023271
780
88371
IGMP
0
0
3
26
TCP
0.046324
0.023201
15825
8857983
UDP
0.065537
0.041015
7306
283228
Results - Passive
Internal Addresses Only
Protocol
H mean
H variance
Number
Addresses
Number
Packets
0.109633
0.026097
110
13770391
0.075714
0.03822
21
134970
0
0
20
271
0.004189
0.000321
66
12067910
0.035207
0.010859
91
1567240
All
ICMP
IGMP
TCP
UDP
Results - Passive
Only Addresses w/ more than 250 packets
Protocol
H mean
H variance
Number
Addresses
Number
Packets
All
0.060041
0.035521
2876
22338795
ICMP
0.035778
0.020212
33
219605
IGMP
0
0
1
0
TCP
0.051132
0.027288
2713
20332940
UDP
0.165818
0.175238
148
1779896
Results - Passive
Only Addresses w/ more than 500 packets
Protocol
H mean
H variance
Number
Addresses
Number
Packets
All
0.050635
0.031506
2306
22140140
ICMP
0.022401
0.014516
30
218560
IGMP
0
0
1
0
TCP
0.042716
0.022273
2190
20150197
UDP
0.164326
0.209436
104
1764716
Results - Passive
• TTL differs by protocol
• UDP most unreliable
– traceroute is major contributor (can be filtered)
– certain programs set TTL anomalously
– ToS may be useful in reducing inconsistencies
• TTL on local network highly regular
– must filter traceroute traffic
ToS Review
priority
minimize
delay
maximize
throughput
maximize
reliability
Minimize
$$ cost
• May differ by protocol and service
–
–
–
–
Telnet:
DNS - UDP:
DNS - TCP:
NNTP:
1
1
0
0
0
0
0
0
0
0
0
0
0
0
0
1
reserved
Experiment Description Reactive
• Monitor network traffic
• Record IP address, Protocol, TTL and ID
• Send probe packet(s)
– ICMP echo reply packet
– TCP syn packet
– UDP packet
• Note the differences between the stored TTL/ID to
that of the returning probes.
Results - Reactive
• Evaluate –
– initial vs. probe reply TTL
– Initial vs. probe reply ID (delta from original)
• Predictability measure
– Conditional Entropy (unpredictability)
• Values closer to zero indicate higher
predictability
Results - Reactive
• Preliminary only
– Ran for 18 hours
– 8058 probes sent
– 218 unique addresses
• 173 external
• 45 internal
Results - Reactive
• TTL off by:
–
–
–
–
Total # probes
8058 1591
+/- 2 or less 6467 371 80%
+/-1 or less 6096 986 75%
0
5110 63%
Results - Reactive
• ID off by:
– Total # probes 8058
–
–
–
–
–
–
–
–
Offset
1
2
4
6
5
7
8
Count
601
57
21
16
14
11
9
–
–
–
–
–
Offset
256
512
768
1280
Count
73
5
22
10
Future and Ongoing Work
• Complete and evaluate reactive experiments
• Evaluate predictability of unobserved IP addresses
using neural network or other ML method.
• Complete and test SPD program
– Monitor network traffic
– Determine if packet is suspicious using passive system
– If suspicious, use reactive methods to determine if
packet was spoofed.
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
Peer based strategies
• Built from small collections of partners with limited trust
sharing information.
– Cooperating enterprise boundary controllers: commercial,
government, military, university
– Cooperating personal firewalls: home, office and wireless.
– Mobile military computing devices: laptops, PDAs
• Features of peer-to-peer mitigation strategies
–
–
–
–
Single compromised or malicious partners carry less weight
Network topology details are less important
No global optimization of mitigation measures
Creates a kind of White Worm to fight back
Preliminary Simulation
• Based upon Swarm biological agent simulation package
• Evaluate the ability of mitigation strategies to suppress
worms
• Cooperative mitigation strategy parameters
– # of friends
– Time step to cost reducing backoff
– Time to cleanup and recovery
• Simple worm model parameters
– Initial density
– Likelihood of success
– Scanning method (permutative, random)
– Propagation speed
4 Friends
8 Friends
16 Friends
Cost Reducing Backoff
Response with Ambient False
Alarms
Hierarchical Cooperation
•
•
•
•
Graphs abstract network activity
Configurable rulesets determine when graphs combine
Host-based data is included as node attributes
Attack assessment is made using global aggregated graph
attributes.
Network based reports
Data Sources:
spurr
Host based reports
kanab
kanab
Ruleset
Correlation
Aggregated graph:
R
olympus
spurr
kanab
sierra
erebus
tallac
R
R
Hierarchical
Aggregation/Correlation
• Graph building engines arranged in a hierarchy
• Unresolved graph fragments propagate up
Audits
Widgets Inc.
Payroll
Audits
A
Human Resources
Financial
Office of CFO
Personnel
B
Training
Office of CFO
H
Audits
x,y,...
J
I
Payroll
E
F
Office of CFO
Payroll
x,y,...
x,y,...
C
G
D
Scalability
•
•
•
All data sources reside at the bottom of the hierarchy
Rulesets accept everything with destination port < 1023 & != 80
Report volume at each engine is measured in proportion to the average input report volume.
1.3
1.6
0.79
1.0
1.0
0.80
0.79
Data source input traffic volume is defined to be one.
1.0
Hierarchical Mitigation
• Authority/Subordinate relationship
• Summarized, reduced alarms flow up
• Mitigation directives flow down
• Large numbers of uninfected
sites can be protected in a short
time period
• Top node could be the CCDC
• Hybrid systems with both
hierarchical and peer based
cooperation may perform best.
Issues and Goals
• Which cooperative mitigation strategies are effective
against different worm types?
• Mitigation strategies influence detection strategy.
• Scalable to very large networks
• Cost effectiveness
– Performance in the face of false alarms
– Cure isn’t worse than the disease
• Cooperative trust protocol useful at many levels
–
–
–
–
Small personal groups of users
ISP to customer security
Security manager to client
CCDC control hierarchies
Analysis Topics
• Learning from worm instances: Melissa
Danforth, Jeff Rowe, Karl Levitt, Jim Just
• Information Visualization of Worm Traffic:
Kwan-Liu Ma, Felix Wu, Soon Tee Teoh
• Static Analysis of Code to Detect Potential for
Specific Malicious Activity: Raymond Lo, Ron
Olsson, Karl Levitt