Preview question A captive portal on a WiFi network directs all HTTP - PDF document

Preview question A “captive portal” on a WiFi network directs all HTTP traffic to a login web server. Which kind of tunneling might slowly circumvent this? CSci 5271 A. DNS over HTTPS Introduction to Computer Security Middleboxes and malware combined slides B. UDP over TCP Stephen McCamant C. SOCKS over SSH University of Minnesota, Computer Science & Engineering D. IP over DNS E. HTTPS over HTTP Outline Random numbers and entropy More causes of crypto failure Cryptographic RNGs use cipher-like techniques to provide indistinguishability Firewalls and NAT boxes But rely on truly random seeding to stop brute force Intrusion detection systems Extreme case: no entropy ✦ always same “randomness” Modern best practice: seed pool with 256 bits of Malware and the network entropy Denial of service and the network Suitable for security levels up to ✷ ✷✺✻ Netscape RNG failure Debian/OpenSSL RNG failure (1) Early versions of Netscape SSL (1994-1995) seeded OpenSSL has pretty good scheme using with: ✴❞❡✈✴✉r❛♥❞♦♠ Time of day Also mixed in some uninitialized variable values Process ID “Extra variation can’t hurt” Parent process ID From modern perspective, this was the original sin Best case entropy only 64 bits Remember undefined behavior discussion? (Not out of step with using 40-bit encryption) But had no immediate ill effects But worse because many bits guessable Debian/OpenSSL RNG failure (2) Detected RSA/DSA collisions 2012: around 1% of the SSL keys on the public net Debian maintainer commented out some lines to fix are breakable a Valgrind warning Some sites share complete keypairs “Potential use of uninitialized value” RSA keys with one prime in common (detected by large-scale GCD) Accidentally disabled most entropy (all but 16 bits) One likely culprit: insufficient entropy in key Brief mailing list discussion didn’t lead to generation understanding Embedded devices, Linux ✴❞❡✈✴✉r❛♥❞♦♠ vs. ✴❞❡✈✴r❛♥❞♦♠ Broken library used for ✘ 2 years before discovery DSA signature algorithm also very vulnerable

Side-channel attacks WEP “privacy” Timing analysis: Number of 1 bits in modular exponentiation First WiFi encryption standard: Wired Equivalent Unpadding, MAC checking, error handling Privacy (WEP) Probe cache state of AES table entries F&S: designed by a committee that contained no Power analysis cryptographers Especially useful against smartcards Problem 1: note “privacy”: what about integrity? Fault injection Nope: stream cipher + CRC = easy bit flipping Data non-erasure Hard disks, “cold boot” on RAM WEP shared key WEP key size and IV size Original sizes: 40-bit shared key (export restrictions) Single key known by all parties on network plus 24-bit IV = 64-bit RC4 key Easy to compromise Both too small Hard to change 128-bit upgrade kept 24-bit IV Also often disabled by default Vague about how to choose IVs Least bad: sequential, collision takes hours Example: a previous employer 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 handshake Only true crypto weakness Key reinstallation attack: replay #3 RC4 “key schedule” vulnerable when: Causes most implementations to reset nonce and replay counter RC4 keys very similar (e.g., same key, 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 users like SSL Protocol state machine behavior poorly described in Key from a hash, skip first output bytes spec Outside the scope of previous security proofs Trustworthiness of primitives Dual EC DRBG (1) Pseudorandom generator in NIST standard, based on Classic worry: DES S-boxes elliptic curve Obviously in trouble if cipher chosen by your Looks like provable (slow enough!) but strangely no adversary proof In a public spec, most worrying are unexplained Specification includes long unexplained constants elements Academic researchers find: Best practice: choose constants from well-known Some EC parts look good math, like digits of ✙ But outputs are statistically distinguishable

Dual EC DRBG (2) Outline Found 2007: special choice of constants allows More causes of crypto failure prediction attacks Firewalls and NAT boxes Big red flag for paranoid academics Significant adoption in products sold to US govt. Intrusion detection systems FIPS-140 standards Malware and the network Semi-plausible rationale from RSA (EMC) NSA scenario basically confirmed by Snowden leaks Denial of service and the network NIST and RSA immediately recommend withdrawal Internet addition: middleboxes Security/connectivity tradeoff A lot of security risk comes from a network Original design: middle of net is only routers connection End-to-end principle Attacker could be anywhere in the world Modern reality: more functionality in the network Reducing connectivity makes security easier Security is one major driver Connectivity demand comes from end users What a firewall is Inbound and outbound control Most obvious firewall use: prevent attacks from the Basically, a router that chooses not to forward some outside traffic Often also some control of insiders Based on an a-priori policy Block malware-infected hosts More complex architectures have multiple layers Employees wasting time on Facebook DMZ : area between outer and inner layers, for Selling sensitive info to competitors outward-facing services Nation-state Internet management May want to log or rate-limit, not block Default: deny IPv4 address scarcity Design limit of ✷ ✸✷ hosts Actually less for many reasons Usual whitelist approach: first, block everything Addresses becoming gradually more scarce over a Then allow certain traffic many-year scale Basic: filter packets based on headers Some high-profile exhaustions in 2011 More sophisticated: proxy traffic at a higher level IPv6 adoption still quite low, occasional signs of progress

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

Outline Basic idea: detect attacks More causes of crypto failure The worst attacks are the ones you don’t even know Firewalls and NAT boxes about Best case: stop before damage occurs Intrusion detection systems Marketed as “prevention” Still good: prompt response Malware and the network Challenge: what is an attack? Denial of service and the network Network and host-based IDSes Signature matching Network IDS: watch packets similar to firewall Signature is a pattern that matches known bad But don’t know what’s bad until you see it behavior More often implemented offline Typically human-curated to ensure specificity Host-based IDS: look for compromised process or See also: anti-virus scanners user from within machine Anomaly detection Recall: FPs and FNs Learn pattern of normal behavior False positive: detector goes off without real attack “Not normal” is a sign of a potential attack False negative: attack happens without detection Has possibility of finding novel attacks Any detector design is a tradeoff between these (ROC curve) Performance depends on normal behavior too Signature and anomaly weaknesses Base rate problems If the true incidence is small (low base rate), most Signatures 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 admins Anomaly detection E.g., 100 attacks out of 10 million packets, 0.01% FP Hard to avoid false positives rate Adversary can train over time How many false alarms?