Transcript CSCI6268L11 - Computer Science

Foundations of Network and
Computer Security
John 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
Client 1 Move
Client 1 Move
Enforce Chess
Rules, Manage
Clocks
Chess Client 1
Chess Client 2
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
……
0000000000600820
0000000000400458
0000000000600828
0000000000400420
0000000000600834
0000000000400448
……
W
T
b
t
b
T
data_start
descriptive_function_name
dtor_idx.6147
frame_dummy
interesting_variable_name.1627
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 Input x
32 MSB = L0
32 LSB = R0
f
L1
R1
16 Rounds
64 Bit Key
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
xn+1 = 3xn + 1 mod 43060573
yn+1 = 17yn
pad = xn
mod 2413871
yn
(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)
www.cs.colorado.edu/~jrblack/papers.html
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 1.1.1.1
– Client B replies “I am 1.1.1.1 with MAC
01:01:01:01:01:01” (broadcast)
– Client C hears reply and caches
• 1.1.1.1  01:01:01:01:01:01
• Unsolicited replies are also cached
– Suppose gateway IP is 10.10.10.10 and A’s IP is
2.2.2.2
– B tells A: 10.10.10.10  01:01:01:01:01:01
– B tells gateway: 2.2.2.2  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 www.x.com
– 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 www.evil.com, which has a legitimate
link to www.amazon.com
– 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
• Adding crypto to DNS!
– Proposed in 1993
• Was at least 15 years before it started being implemented
– DNS records are signed by a chain of certificates,
rooted at a DNS root zone
• DNS is an example of authentication without encryption: all
records are sent in the clear
– As of 2011, 25% of DNS queries were protected by
DNSSEC
– As of 2013, Google’s Public DNS server was
validating with DNSSEC by default