DOC PREVIEW
Berkeley COMPSCI 161 - Network Attacks / Control

This preview shows page 1-2-21-22 out of 22 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 22 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 22 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 22 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 22 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 22 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

1Network Attacks / ControlCS 161 - Computer SecurityProfs. Vern Paxson & David WagnerTAs: John Bethencourt, Erika Chin, Matthew Finifter,Cynthia Sturton, Joel Weinbergerhttp://inst.eecs.berkeley.edu/~cs161/Feb 17, 20102Focus of Today’s Lecture• Finish discussion of DNS attacks• Begin discussion of approaches forcontrolling network traffic:– Firewalls: restricting allowed communication– NATs: Network Address Translators3DNS Blind Spoofing, conʼtAdditional information(variable # of resource records)Questions(variable # of resource records)Answers(variable # of resource records)Authority(variable # of resource records)# Authority RRs # Additional RRsIdentification Flags# Questions # Answer RRs16 bits 16 bitsAttacker can send lots of replies,not just one …However: once reply from legitserver arrives (with correctIdentification), it’s cached andno more opportunity to poison it.Victim is innoculated!Once we randomize theIdentification, attacker has a1/65536 chance of guessing itcorrectly.Are we pretty much safe?Unless attacker can send1000s of replies before legitarrives, we’re likely safe -phew!?4DNS Blind Spoofing (Kaminsky 2008)• Two key ideas:–Spoof uses Additional field (rather than Answer)–Attacker can get around caching of legit repliesby generating a series of different name lookups:<img%src="http://random1.google.com"%…><img%src="http://random2.google.com"%…><img%src="http://random3.google.com"%…>...<img%src="http://randomN.google.com"%…>5;; QUESTION SECTION:;randomk.google.com. IN A;; ANSWER SECTION:randomk.google.com 21600 IN A doesn’t(matter;; AUTHORITY SECTION:google.com. 11088 IN NS mail.google.com;; ADDITIONAL SECTION:mail.google.com 126738 IN A 6.6.6.6Kaminsky Blind Spoofing, conʼtFor each lookup of randomk.google.com,attacker returns a bunch of records like this,each with a different IdentifierOnce they win the race, not only have they poisonedmail.google.com … but also the cached NS record forgoogle.com’s name server - so any future X.google.comlookups go through the attacker’s machine6;; QUESTION SECTION:;randomk.google.com. IN A;; ANSWER SECTION:randomk.google.com 21600 IN A doesn’t(matter;; AUTHORITY SECTION:google.com. 11088 IN NS mail.google.com;; ADDITIONAL SECTION:mail.google.com 126738 IN A 6.6.6.6Kaminsky Blind Spoofing, conʼtFor each lookup of randomk.google.com,attacker returns a bunch of records like this,each with a different IdentifierOnce they win the race, not only have they poisonedmail.google.com … but also the cached NS record forgoogle.com’s name server - so any future X.g oogle.comlookups go through the attacker’s machine7Defending Against Blind SpoofingAdditional information(variable # of resource records)Questions(variable # of resource records)Answers(variable # of resource records)Authority(variable # of resource records)# Authority RRs # Additional RRsIdentification Flags# Questions # Answer RRs16 bits 16 bitsCentral problem: all that tells aclient they should accept aresponse is that it matches theIdentification field.With only 16 bits, it lackssufficient entropy: even if trulyrandom, the search space anattacker must brute force is toosmall.Where can we get moreentropy? (Without requiring aprotocol change.)8Defending Against Blind SpoofingAdditional information(variable # of resource records)Questions(variable # of resource records)Answers(variable # of resource records)Authority(variable # of resource records)# Authority RRs # Additional RRsIdentification Flags# Questions # Answer RRsDNS (primarily) uses UDP fortransport rather than TCP.UDP header has: 16-bit Source & Destination ports (identify processes, like w/ TCP) 16-bit checksum, 16-bit length SRC port DST portchecksum length16 bits 16 bitsUDP Payload9Defending Against Blind SpoofingAdditional information(variable # of resource records)Questions(variable # of resource records)Answers(variable # of resource records)Authority(variable # of resource records)# Authority RRs # Additional RRsIdentification Flags# Questions # Answer RRsDNS (primarily) uses UDP fortransport rather than TCP.UDP header has: 16-bit Source & Destination ports (identify processes, like w/ TCP) 16-bit checksum, 16-bit lengthSrc=53 Dest=53checksum length16 bits 16 bitsFor requestor to receive DNSreply, needs both correctIdentification and correct ports.On a request, DST port = 53.SRC port usually also 53 - butnot fundamental, just convenientTotal e ntropy : 16 bits10Defending Against Blind SpoofingAdditional information(variable # of resource records)Questions(variable # of resource records)Answers(variable # of resource records)Authority(variable # of resource records)# Authority RRs # Additional RRsIdentification Flags# Questions # Answer RRsSrc=rnd Dest=53checksum length16 bits 16 bits“Fix”: use random source port32 bits of entropy makes itorders of magnitude harder forattacker to guess all thenecessary fields and dupe victiminto accepting spoof response.This is what primarily “secures”DNS today. (Note: not allresolvers have implementedrandom source ports!)Total e ntropy : 32 bits11• DHCP threats highlight:– Broadcast protocols inherently at risk of attacker spoofingo Attacker knows exactly when to try it– When initializing, systems are particularly vulnerable becausethey can lack a trusted foundation to build upon– Tension between wiring in trust vs. flexibility/convenience– MITM attacks insidious because no indicators they’re occurringSummary of DHCP/DNS Security Issues12• DHCP threats highlight:– Broadcast protocols inherently at risk of attacker spoofingo Attacker knows exactly when to try it– When initializing, systems are particularly vulnerable becausethey can lack a trusted foundation to build upon– Tension between wiring in trust vs. flexibility/convenience– MITM attacks insidious because no indicators they’re occurring• DNS threats highlight:– Attackers can attack opportunistically rather than eavesdroppingo Cache poisoning only requires victim to look up some name underattacker’s control– Attackers can often manipulate victims into vulnerable activityo E.g., IMG%SRC in web page to force DNS lookups– Crucial for identifiers associated with communication to havesufficient entropy (= a lot of bits of unpredictability)– “Attacks only get better”:


View Full Document

Berkeley COMPSCI 161 - Network Attacks / Control

Documents in this Course
Rootkits

Rootkits

11 pages

Load more
Download Network Attacks / Control
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Network Attacks / Control and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Network Attacks / Control 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?