Outline Crypto failures, contd CSci 5271 Announcements - PDF document

Outline Crypto failures, cont’d CSci 5271 Announcements intermission Introduction to Computer Security Day 21: Firewalls, NATs, and IDSes Firewalls and NAT boxes Stephen McCamant University of Minnesota, Computer Science & Engineering Intrusion detection systems Side-channel attacks WEP “privacy” Timing analysis: First WiFi encryption standard: Wired Number of 1 bits in modular exponentiation Equivalent Privacy (WEP) Unpadding, MAC checking, error handling Probe cache state of AES table entries F&S: designed by a committee that Power analysis contained no cryptographers Especially useful against smartcards Problem 1: note “privacy”: what about Fault injection integrity? Nope: stream cipher + CRC = easy bit Data non-erasure flipping Hard disks, “cold boot” on RAM WEP shared key WEP key size and IV size Original sizes: 40-bit shared key Single key known by all parties on (export restrictions) plus 24-bit IV = network 64-bit RC4 key Both too small Easy to compromise 128-bit upgrade kept 24-bit IV Hard to change Vague about how to choose IVs Also often disabled by default Least bad: sequential, collision takes Example: a previous employer hours Worse: random or everyone starts at zero

WEP RC4 related key attacks New problem with WPA (CCS’17) Session key set up in a 4-message Only true crypto weakness handshake Key reinstallation attack: replay #3 RC4 “key schedule” vulnerable when: Causes most implementations to reset RC4 keys very similar (e.g., same key, nonce and replay counter similar IV) In turn allowing many other attacks First stream bytes used One especially bad case: reset key to 0 Not a practical problem for other RC4 Protocol state machine behavior poorly users like SSL described in spec Key from a hash, skip first output bytes Outside the scope of previous security proofs Trustworthiness of primitives Dual EC DRBG (1) Pseudorandom generator in NIST Classic worry: DES S-boxes standard, based on elliptic curve Obviously in trouble if cipher chosen by Looks like provable (slow enough!) but your adversary strangely no proof In a public spec, most worrying are Specification includes long unexplained unexplained elements constants Best practice: choose constants from Academic researchers find: well-known math, like digits of ✙ Some EC parts look good But outputs are statistically distinguishable Dual EC DRBG (2) Post-quantum cryptography Found 2007: special choice of One thing quantum computers would constants allows prediction attacks be good for is breaking crypto Big red flag for paranoid academics Square root speedup of general search Significant adoption in products sold to Countermeasure: double symmetric security level US govt. FIPS-140 standards Factoring and discrete log become Semi-plausible rationale from RSA (EMC) poly-time NSA scenario basically confirmed by DH, RSA, DSA, elliptic curves totally Snowden leaks broken NIST and RSA immediately recommend Totally new primitives needed (lattices, withdrawal etc.) Not a problem yet, but getting ready

Outline Note to early readers Crypto failures, cont’d This is the section of the slides most Announcements intermission likely to change in the final version If class has already happened, make Firewalls and NAT boxes sure you have the latest slides for announcements Intrusion detection systems More readings coming up HA2 in the home stretch More details on how to set up firewalls All parts due Friday by 11:55pm Burglar alarms and “mimicry” attack on Extra office hour Thursday 10-11am IDSes 4-225E Containing high-speed worms Virus evolution Outline Internet addition: middleboxes Crypto failures, cont’d Original design: middle of net is only routers Announcements intermission End-to-end principle Modern reality: more functionality in the Firewalls and NAT boxes network Security is one major driver Intrusion detection systems

Security/connectivity tradeoff What a firewall is A lot of security risk comes from a Basically, a router that chooses not to network connection forward some traffic Attacker could be anywhere in the world Based on an a-priori policy Reducing connectivity makes security More complex architectures have multiple layers easier DMZ : area between outer and inner Connectivity demand comes from end layers, for outward-facing services users Inbound and outbound control Default: deny Most obvious firewall use: prevent Usual whitelist approach: first, block attacks from the outside everything Often also some control of insiders Then allow certain traffic Block malware-infected hosts Employees wasting time on Facebook Basic: filter packets based on headers Selling sensitive info to competitors More sophisticated: proxy traffic at a Nation-state Internet management higher level May want to log or rate-limit, not block IPv4 address scarcity Network address translation (NAT) Middlebox that rewrites addresses in Design limit of ✷ ✸✷ hosts packets Actually less for many reasons Main use: allow inside network to use Addresses becoming gradually more non-unique IP addresses scarce over a many-year scale RFC 1918: 10.*, 192.168.*, etc. Some high-profile exhaustions in 2011 While sharing one outside IP address Inside hosts not addressable from IPv6 adoption still very low, occasional outside signs of progress De-facto firewall

Packet filtering rules Client and server ports TCP servers listen on well-known port Match based on: numbers Source IP address Often ❁ 1024, e.g. 22 for SSH or 80 for Source port HTTP Destination IP address Destination port Clients use a kernel-assigned random Packet flags: TCP vs. UDP , TCP ACK, etc. high port Action, e.g. allow or block Plain packet filter would need to allow Obviously limited in specificity all high-port incoming traffic Stateful filtering Circuit-level proxying In general: firewall rules depend on Firewall forwards TCP connections for previously-seen traffic inside client Key instance: allow replies to an Standard protocol: SOCKS outbound connection Supported by most web browsers See: port 23746 to port 80 Wrapper approaches for non-aware apps Allow incoming port 23746 Not much more powerful than To same inside host packet-level filtering Needed to make a NAT practical Application-level proxying Tunneling Knows about higher-level semantics Any data can be transmitted on any Long history for, e.g., email, now HTTP channel, if both sides agree most important E.g., encapsulate IP packets over SSH More knowledge allows better filtering connection decisions Compare covert channels, steganography But, more effort to set up Powerful way to subvert firewall Newer: “transparent proxy” Some legitimate uses Pretty much a man-in-the-middle

Outline Basic idea: detect attacks Crypto failures, cont’d The worst attacks are the ones you don’t even know about Announcements intermission Best case: stop before damage occurs Marketed as “prevention” Firewalls and NAT boxes Still good: prompt response Challenge: what is an attack? Intrusion detection systems Network and host-based IDSes Signature matching Network IDS: watch packets similar to Signature is a pattern that matches firewall known bad behavior But don’t know what’s bad until you see it Typically human-curated to ensure More often implemented offline specificity Host-based IDS: look for compromised See also: anti-virus scanners process or user from within machine Anomaly detection Recall: FPs and FNs False positive: detector goes off Learn pattern of normal behavior without real attack “Not normal” is a sign of a potential False negative: attack happens without attack detection Has possibility of finding novel attacks Any detector design is a tradeoff Performance depends on normal between these (ROC curve) behavior too

Signature and anomaly weaknesses Base rate problems If the true incidence is small (low base Signatures rate), most positives will be false Won’t exist for novel attacks Example: screening test for rare disease Often easy to attack around Easy for false positives to overwhelm Anomaly detection admins Hard to avoid false positives E.g., 100 attacks out of 10 million Adversary can train over time packets, 0.01% FP rate How many false alarms? Adversarial challenges Wagner and Soto mimicry attack Host-based IDS based on sequence of FP/FN statistics based on a fixed set of syscalls attacks Compute ❆ ❭ ▼ , where: But attackers won’t keep using ❆ models allowed sequences techniques that are detected ▼ models sequences achieving Instead, will look for: attacker’s goals Further techniques required: Existing attacks that are not detected Minimal changes to attacks Many syscalls made into NOPs Truly novel attacks Replacement subsequences with similar effect Next time Malware and network denial of service