Protecting Cyber-TA Contributors: Risks and Challenges

1. Protecting Cyber-TAContributors:Risks and Challenges • Vitaly Shmatikov • The University of Texas at Austin

2. 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

3. 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

4. Basic Tradeoffs privacy and anonymity • Do not enable attackers to track attack propagation • Do not announce site defenses • Do not reveal network topology, configuration, enabled services tradeoffs Low overhead; no complicated crypto utility efficiency Support (at least) coarse-grained analysis: event trends, identification of common attack sources, connection patterns, blacklisting, etc.

5. 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 • Sometimes, the only difference is intent • Hard to tell by looking at data requests alert database

6. 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 Example: Probe-Response Attack repository IP hashing doesn’t help!Attacker knows targeted subnet, stages simple dictionary attack with small (<256) dictionary

7. “Fingerprinting” Attacks • Unique attack signature • Port combinations • Rare IDS rules • Multiple scans (to cross • statistical thresholds) Attacker completely maps out network defenses and avoids them in the future Attacker wants attack to be detected alert Attack is detected and alert reported to repository repository [E.g., see Bethencourt et al., USENIX Security 2005]

8. Current IP Address Sanitization Is this IP address on my network? Yes: use HMAC with secret key No: use SHA-1 • Can only be compared for equality with IP addresses reported by IDS on the same network • Dictionary attack not feasible • A and B can compare their observations of events on C’s network • Dictionary attack possible, but address space is large • Enables detection of widely observed IP addresses

9. 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

10. 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

11. 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)

12. Future Work: Backpropagation Propagate analysis results back to contributors (e.g., hashed IP addresses for filtering) Internet Overlay peer-to-peer randomized routing

13. 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

14. 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

15. Observe outgoing connection (sniff or attack 1st overlay node) De-anonymize alert origin by correlating message timings Timing Attack Internet Overlay peer-to-peer randomized routing

16. 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!

17. 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. Sample Intrusion Detection Alert