Transcript CSCI6268L11

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
•
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