Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
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.