Transcript Protecting Cyber-TA Contributors

Protecting Cyber-TA
Contributors:
Risks and Challenges
Vitaly Shmatikov
The University of Texas at Austin
Big Picture
How to do collaborative analysis if
networks don’t trust each other?
• Intrusion
detection data
• Security alerts
• Firewall data
Goal: stop attackers from abusing these data
Sample Intrusion Detection Alert
 may contain victim’s IP address
 reveals relationships with other networks
 reveals target’s IP address
 reveals topology of targeted network
and attack propagation
 may reveal organization that owns it
 leaks information stored on
targeted systems
Basic Tradeoffs
• Do not enable attackers to
track attack propagation
• Do not announce site defenses
• Do not reveal network topology,
configuration, enabled services
privacy and
anonymity
Low overhead; no
complicated crypto
tradeoffs
utility
efficiency
Support (at least) coarse-grained analysis:
event trends, identification of common attack
sources, connection patterns, blacklisting, etc.
Fundamental Problem
Alerts may be used to track progress of
attacks and find new vulnerabilities
Hard to tell the difference between an
attacker and a legitimate researcher
alert database
Sometimes, the only difference is intent
- Hard to tell by looking at data requests
Example: Probe-Response Attack
attack a particular
IP address
attacker looks up the alert
and learns the address of
the detecting IDS sensor
alert
attack is detected and
alert reported to repository
repository
IP hashing doesn’t help! Attacker knows targeted subnet,
stages simple dictionary attack with small (<256) dictionary
“Fingerprinting” Attacks
Unique attack signature
• Port combinations
• Rare IDS rules
• Multiple scans (to cross
statistical thresholds)
Attacker wants attack
to be detected
Attacker completely maps
out network defenses and
avoids them in the future
alert
Attack is detected and
alert reported to repository
repository
[E.g., see Bethencourt et al., USENIX Security 2005]
Current IP Address Sanitization
Is this IP address on my network?
Yes: use HMAC with secret key
No: use SHA-1
 A and B can compare
their observations of
events on C’s network
 Can only be compared for
equality with IP addresses
reported by IDS on the same
network
 Dictionary attack possible,
but address space is large  Dictionary attack not feasible
 Enables detection of widely
observed IP addresses
Current Alert Sanitization
Content fields scrubbed
- InfectedFile, CapturedData, etc.
Timestamps rounded
- Tradeoff: limit sequence analysis
High port numbers rounded
- Tradeoff: limit port analysis possibilities
Unique contributor IDs (not stored)
- Rely on source anonymity to hide identity
Data Sanitization Challenges
Formalization of fingerprinting attacks +
secure alert correlation schemes
IP address virtualization that preserves
topological structure of address space
without revealing true addresses
- Reconstruct topology of attack graphs
Protocols that reveal attack data only if
similar attack has been observed by a
threshold number of contributors
Protecting Source Identity
Internet
Overlay peer-to-peer
randomized routing
(robust even if some
nodes are compromised)
Based on Tor (low-latency
TCP-level anonymity)
Future Work: Backpropagation
Propagate analysis results back
to contributors (e.g., hashed IP
addresses for filtering)
Internet
Overlay peer-to-peer
randomized routing
Source Anonymity Issues
Dataset poisoning and denial of service
- Deliberate attacks or accidental flooding
Pre-registration and vetting are needed
Group membership credentials
- Issued through “blind” registration;
unlinkable to contributor’s true identity
- Hard to guess, easy to check
- Linkability of same-source contributions?
Possible attacks on registration process
Contributor Registration
Contributor IDs issued by Cyber-TA
Coordination Center
- Random IDs unlinkable to true identity
Repositories can blacklist certain
contributor IDs
Current research:
- Prevention of flooding and data poisoning
- Revocation mechanisms
- Reputation systems
Timing Attack
Observe outgoing connection
(sniff or attack 1st overlay node)
De-anonymize alert origin by
Internet
correlating
message timings
Overlay peer-to-peer
randomized routing
Additional Protection
Re-keying by alert repository
- Additional keyed hashing of IP addresses
Randomized hot list thresholds
- Publish only the hot list of reported alerts
that have something in common
 Need randomness to prevent flushing attacks
Delayed alert publication
… all of these rely on repository integrity!
Sample Intrusion Detection Alert
Source address: can be used as a marker to
learn sensor coverage
Port number: rare port numbers can be used
as markers to link alerts to sensors
Destination address: reveals sensor
coverage, capabilities, network topology
Port number: reveals network services
Timestamp: can be used to link an alert to the
sensor that produced it
SensorID: reveals defensive services and
capabilities, organization that owns sensor
EventID: reveals defensive services,
capabilities, policies
Outcome: reveals target site’s vulnerabilities,
topologies, policies, etc.
Captured data, Infected file: reveals private
user data, topology and applications,
vulnerabilities.