Foundations of Network and Computer Security J J ohn Black CSCI 6268/TLEN 5550, Spring 2013

Security of Network Protocols Virtually any network protocol you can name has the following features –When it was designed, security was not considered –Since that time, security has been added –There have been many known vulnerabilities in the protocol, and –(Some) are still insecure Examples: –Ethernet, ARP, DHCP, DNS, BGP, TCP/IP, DNS, HTTP, FTP, WEP Let’s look at a few of these

Ethernet Ethernet is a broadcast protocol –Sniffing reveals all plaintext on a given segment –Switches can help, but they can be fooled Main tool is libpcap/tcpdump –Put interface into “promiscuous mode” Most cards support this; may require privs –Wireshark is a popular GUI/filter

Wireshark

Case Study: Internet Chess Club ICC (Internet Chess Club) Over 30,000 members Pay Site ($60/year) Madonna, Nicholas Cage, Will Smith, Sting, even Kasparov Best choice for online chess Written by and run by: Daniel Sleator –Theoretical Computer Science Professor –Carnegie Mellon University

Basic Idea ICC Server Chess Client 1 Chess Client 2 Client 1 Move Enforce Chess Rules, Manage Clocks Client 1 Move

Move Timestamping Critical Issue –Serious chess is timed –Each player’s clock ticks during his turn –Player’s clock runs out, he loses Difficulty –Network lag appears as player’s thinking time Solution –Timestamp each move locally at client

Security Overview Players now send time themselves Can they lie? –There are cash prizes on ICC sometimes! Sleator’s solutions –Source code to any timestamping software is not released –Encrypt all data to and from server (homebrew encryption protocol) Later Emboldened –Web page encourages you to send sensitive information including CC#’s

What We Did Two main attacks on server –Timestamping (how to cheat) Adversarial model like DRM –Encryption (how to steal CC numbers, etc) Normal crypto adversarial model, and… Block cipher has bad differentials Mode of operation easily broken Key exchange horribly weak No message authentication Suggest Remedies

Timestamping Crack Sleator’s solutions –Control source code –Encrypt Our solution –Reverse engineer binary Linux timestamper only 27KB Not stripped! Yummy!

Symbols can be Useful main() { static int interesting_variable_name; descriptive_function_name(); } descriptive_function_name() { }

Symbols (cont) $ nm a.out …… W data_start T descriptive_function_name b dtor_idx t frame_dummy b interesting_variable_name T main ……

How to Strip $ strip a.out $ nm a.out nm: a.out: no symbols $

Timestamping Remedies Could have been harder –Strip symbols –Obfuscate code No perfect solution –Smartcards (expensive) –Other network services to try and catch cheaters (can spoof everything…. arms race)

Block Cipher (Feistel) 64 Bit Key 64 Bit Input x 32 MSB = L 0 32 LSB = R 0 f R1R1 L1L1 16 Rounds

Block Cipher f() does not use the highest bit of input! –Changing bit 31 or 63 of input changes only bit 31 or 63 of output (respectively) –(In Geek-Speak: there is a probability 1 differential characteristic) Very poor property –Distinguish in 2 chosen plaintexts –Cipher used as random number generator

Mode of Operation Pad formed by XOR of two LCGs x n+1 = 3x n + 1 mod y n+1 = 17y n mod pad = x n y n (just low byte) Given 10 pad bytes, we get the rest 1.1 secs on my student’s laptop

Key Exchange Seeds for symmetric keys exchanged in the clear!!! We sniff the connection (pcap) and read all the traffic trivially –Get CC #s –Get usernames and passwords Active attacks would be even MORE damaging

Remedies Solution –Use SSL (ok, wasn’t around in 1992) –Use really old stuff that works Diffie-Hellman RSA CBC encryption with CBC MAC –Ok, but now just use OpenSSL

Software Products –Sniffer/decryptor using libpcap Linux Blitzin (a little more work) –Timestamping Client (lets you cheat) Didn’t release any of this Sleator was notified –Web page has been changed; perhaps more –But he had to update 30,000+ clients

The Moral People say the easiest way to break a system is not via the crypto… guess what? People, even very smart people, shouldn’t invent their own crypto –You’ll get it wrong without experience –This is kind of an old lesson, but somehow it still hasn’t sunk in (as we’ll see with WEP)

ARP: Address Resolution Protocol We already went through this protocol at a high level: –ARP_REQUEST –ARP_REPLY –Passive caching –Easily Spoofed –Note: this is for LANs only

ARP Packet Hardware Type 1 = Ethernet; ProtocolType 0x0800 = IP; Operation 1 = Request, 2 = Reply; Source MAC and IP, then Target MAC and IP follow

ARP Cache Poisoning Client A requests MAC for IP –Client B replies “I am with MAC 01:01:01:01:01:01” (broadcast) –Client C hears reply and caches  01:01:01:01:01:01 Unsolicited replies are also cached –Suppose gateway IP is and A’s IP is –B tells A:  01:01:01:01:01:01 –B tells gateway:  01:01:01:01:01:01 –Note: these are unicast ARP_REPLYs

Man-in-the-Middle A Gateway B (MAC: 01:01:01:01:01:01) B now proxies all traffic between A and the outside world

Tools: Ettercap Ettercap is a freely-available tool that does ARP cache poisoning for you –I had a grad student do his thesis on this topic –It was easy to set up and use –Handles SSH as well Uses OpenSSL library

Defenses Static ARP tables –Administrative headache –Doesn’t scale ARPWatch –Watches all traffic and detects anomolies –But only alerts admin after an attack has already occurred –Sometimes generates false positives

Using Cryptography AuthARP (Hector Urtubia) –Each client must sign replies with a private key –Unapproved users cannot issue ARP_REPLYs –Downside: PKI

DNS: Domain Name System Already covered this service (roughly) Distributed database mapping names to IP addresses –13 (logical) root servers –Locally cached like ARP –Recursive algorithm: If colorado.edu doesn’t know, ask edu, if they don’t know, ask a root server

DNS: Security BIND –Berkeley DNS implementation –Ubiquitous –History of bugs Even without vulnerabilities, DNS is a flawed protocol –No authentication –Spoofing not too hard

Unsolicited Replies Not Accepted Can’t just send a DNS record to a client who did not request it But we CAN send a reply to a client who DID request it –Problems: we have to know the request was made Not too hard if we control origin of the request (eg, a web page) Not too hard if we can sniff local network –Problems: we have to throttle legitimate replier

DNS Spoofing A requests –Local DNS server may have it cached, or may not; if cached, replies to A –Evil host (on local network) throttles DNS server Ping of death, DoS, overflows, etc Evil host answers for DNS server, redirecting A to bad IP address

Remote Attacks You visit which has a legitimate link to –evil.com then throttles your DNS server and spoofs –evil.com knows you’re waiting for a resolution for amazon.com Doesn’t always work: –Sequence numbers are used, and they are sniffable on a LAN, but not remotely They used to be sequential (thus easy to guess) but now they are randomized Makes remote attacks much harder

Remote DNS Poisoning Attack a local nameserver –Send hundreds of requests to a victim nameserver for the same (bogus) name, bogus.com nameserver must ask someone else, since he won’t have this cached –Send hundreds of replies for bogus.com Problem: sequence numbers of nameserver’s help requests much be matched Answer: birthday phenomenon –Random numbers aren’t that random, which helps –Chance of a collision very high –Now users of this local nameserver will get the IP of your choice when asking for bogus.com

Remote DNS Poisoning

DNSSEC DNSSEC is a project to have a central company, Network Solutions, sign all the.com DNS records. Here's the idea, proposed in 1993: Network Solutions creates and publishes a verification key. (They are the CA) Each *.com creates a key and signs its own DNS records. Yahoo, for example, creates a key and signs the yahoo.com DNS records under that key. Network Solutions signs each *.com key. Yahoo, for example, gives its cert to Network Solutions, and Network Solutions signs a document identifying that key as the yahoo.com key. Computers around the Internet are given the Network Solutions key, and begin rejecting DNS records that aren't accompanied by the appropriate signatures. As of November 2005, Network Solutions simply isn't doing this. There is no Network Solutions key. There are no Network Solutions *.com signatures. Good news: As of 2011, about 25% of DNS queries are signed Stub resolvers must still trust link to recursive name servers (usually the ISP)

CA Cert Fingerprint, 2013 % openssl x509 -in cacert.pem - fingerprint –noout SHA1 Fingerprint = 3D:E9:8C:7D:F5:6A:5C:0A:76: 50:CC:C7:70:C5:74:F4:B1:68: EF:E2