Outline Malware and the network, cont’d Denial of service and the network CSci 5271 Introduction to Computer Security Announcements intermission Malware and anonymity combined lecture Anonymous communications techniques Stephen McCamant Tor basics University of Minnesota, Computer Science & Engineering Tor experiences and challenges Malware/anti-virus arms race Signature-based AV “Anti-virus” (AV) systems are really Similar idea to signature-based IDS general anti-malware Would work well if malware were static Clear need, but hard to do well In reality: No clear distinction between benign Large, changing database Frequent updated from analysts and malicious Not just software, a subscription Endless possibilities for deception Malware stays enough ahead to survive Emulation and AV Polymorphism Simple idea: run sample, see if it does Attacker makes many variants of something evil starting malware Obvious limitation: how long do you Different code sequences, same wait? behavior Simple version can be applied online One estimate: 30 million samples observed in 2012 More sophisticated emulators/VMs used in backend analysis But could create more if needed
Packing Fake anti-virus Sounds like compression, but real goal Major monentization strategy recently is obfuscation Your system is infected, pay $19.95 for Static code creates real code on the fly cleanup tool Or, obfuscated bytecode interpreter For user, not fundamentally Outsourced to independent “protection” distinguishable from real AV tools Outline DoS versus other vulnerabilities Malware and the network, cont’d Effect: normal operations merely Denial of service and the network become impossible Software example: crash as opposed Announcements intermission to code injection Anonymous communications techniques Less power that complete compromise, Tor basics but practical severity can vary widely Airplane control DoS, etc. Tor experiences and challenges When is it DoS? Algorithmic complexity attacks Can an adversary make your algorithm Very common for users to affect have worst-case behavior? others’ performance ❖ ✭ ♥ ✷ ✮ quicksort Focus is on unexpected and unintended Hash table with all entries in one bucket effects Exponential backtracking in regex Unexpected channel or magnitude matching
XML entity expansion Compression DoS XML entities (c.f. HTML ✫❧t ) are like C Some formats allow very high macros compression ratios Simple attack: compress very large input ★❞❡❢✐♥❡ ❇ ✭❆✰❆✰❆✰❆✰❆✮ More powerful: nested archives ★❞❡❢✐♥❡ ❈ ✭❇✰❇✰❇✰❇✰❇✮ Also possible: “zip file quine” ★❞❡❢✐♥❡ ❉ ✭❈✰❈✰❈✰❈✰❈✮ decompresses to itself ★❞❡❢✐♥❡ ❊ ✭❉✰❉✰❉✰❉✰❉✮ ★❞❡❢✐♥❡ ❋ ✭❊✰❊✰❊✰❊✰❊✮ DoS against network services Tiny bit of queueing theory Mathematical theory of waiting in line Common example: keep legitimate Simple case: random arrival, sequential users from viewing a web site fixed-time service Easy case: pre-forked server supports M/D/1 100 simultaneous connections If arrival rate ✕ service rate, expected Fill them with very very slow downloads queue length grows without bound SYN flooding SYN cookies Change server behavior to stateless SYN is first of three packets to set up approach new connection Embed small amount of needed Traditional implementation allocates information in fields that will be echoed space for control data in third packet However much you allow, attacker fills MAC-like construction with unfinished connections Other disadvantages, so usual Early limits were very low (10-100) implementations used only under attack
DoS against network links Traffic multipliers Third party networks (not attacker or Try to use all available bandwidth, victim) crowd out real traffic One input packet causes ♥ output Brute force but still potentially effective packets Baseline attacker power measured by Commonly, victim’s address is forged packet sending rate source, multiply replies Misuse of debugging features “Smurf” broadcast ping Distributed DoS Many attacker machines, one victim ICMP echo request with forged source Easy if you own a botnet Sent to a network broadcast address Impractical to stop bots one-by-one Every recipient sends reply May prefer legitimate-looking traffic Now mostly fixed by disabling this over weird attacks feature Main consideration is difficulty to filter Outline Upcoming deadlines Malware and the network, cont’d Project meetings mostly this week Denial of service and the network Final progress reports due Friday Announcements intermission Includes formatting sample Exercise set 5 due next Wednesday Anonymous communications techniques Available now Tor basics Project presentations 4/25 and 5/2 Tor experiences and challenges
Outline Traffic analysis Malware and the network, cont’d Denial of service and the network What can you learn from encrypted data? A lot Announcements intermission Content size, timing Anonymous communications techniques Who’s talking to who Tor basics ✦ countermeasure: anonymity Tor experiences and challenges Nymity slider (Goldberg) Nymity ratchet? Verinymity It’s easy to add names on top of an Social security number anonymous protocol Persistent pseudonymity The opposite direction is harder Pen name (“George Eliot”), “moot” Linkable anonymity But, we’re stuck with the Internet as is Frequent-shopper card So, add anonymity to conceal Unlinkable anonymity underlying identities (Idealized) cash payments Steganography Dining cryptographers One approach: hide real content within bland-looking cover traffic Classic: hide data in least-significant bits of images Easy to fool casual inspection, hard if adversary knows the scheme
Dining cryptographers Dining cryptographers Dining cryptographers Dining cryptographers DC-net challenges Mixing/shuffling Computer analogue of shaking a ballot Quadratic key setups and message box, etc. exchanges per round Reorder encrypted messages by a Scheduling who talks when random permutation One traitor can anonymously sabotage Building block in larger protocols Improvements subject of ongoing Distributed and verifiable variants research possible as well
Anonymous remailers Outline Malware and the network, cont’d Anonymizing intermediaries for email First cuts had single points of failure Denial of service and the network Mix and forward messages after Announcements intermission receiving a sufficiently-large batch Anonymous communications techniques Chain together mixes with multiple layers of encryption Tor basics Fancy systems didn’t get critical mass Tor experiences and challenges of users Tor: an overlay network Low-latency TCP applications Tor (originally from “the onion router”) Tor works by proxying TCP streams ❤tt♣s✿✴✴✇✇✇✳t♦r♣r♦❥❡❝t✳♦r❣✴ (And DNS lookups) Focuses on achieving interactive An anonymous network built on top of latency the non-anonymous Internet WWW, but potentially also chat, SSH, etc. Designed to support a wide variety of Anonymity tradeoffs compared to anonymity use cases remailers Tor Onion routing Client perspective Stream from sender to ❉ forwarded Install Tor client running in background via ❆ , ❇ , and ❈ Configure browser to use Tor as proxy One Tor circuit made of four TCP hops Or complete Tor+Proxy+Browser bundle Encrypt packets (512-byte “cells”) as Browse web as normal, but a lot slower ❊ ❆ ✭ ❇❀ ❊ ❇ ✭ ❈❀ ❊ ❈ ✭ ❉❀ P ✮✮✮ Also, sometimes ❣♦♦❣❧❡✳❝♦♠ is in TLS-like hybrid encryption with Swedish “telescoping” path setup
Entry/guard relays Exit relays “Entry node”: first relay on path Forwards traffic to/from non-Tor Entry knows the client’s identity, so destination particularly sensitive Focal point for anti-abuse policies Many attacks possible if one adversary controls entry and exit E.g., no exits will forward for port 25 Choose a small random set of “guards” (email sending) as only entries to use Can see plaintext traffic, so danger of Rotate slowly or if necessary sniffing, MITM, etc. For repeat users, better than random each time Centralized directory Outline Malware and the network, cont’d How to find relays in the first place? Denial of service and the network Straightforward current approach: central directory servers Announcements intermission Relay information includes bandwidth, Anonymous communications techniques exit polices, public keys, etc. Tor basics Replicated, but potential bottleneck for scalability and blocking Tor experiences and challenges Anonymity loves company Who (arguably) needs Tor? Consumers concerned about web Diverse user pool needed for tracking anonymity to be meaningful Businesses doing research on the Hypothetical Department of Defense competition Anonymity Network Citizens of countries with Internet Tor aims to be helpful to a broad range censorship of (sympathetic sounding) potential Reporters protecting their sources users Law enforcement investigating targets
Recommend
More recommend