CSE543 Computer and Network Security Module: Network Securitytrj1/cse543-f16/slides/cse543-network-security.pdf · CSE543 - Introduction to Computer and Network Security Page •

CSE543 - Introduction to Computer and Network Security Page

CSE543 Computer and Network Security

Module: Network Security

Professor Trent Jaeger

1


Networking• Fundamentally about transmitting information

between two devices• Direct communication is now possible between

any two devices anywhere (just about)‣ Lots of abstraction involved‣ Lots of network components‣ Standard protocols‣ Wired and wireless‣ Works in protection environment

• What about ensuring security?

2


The network …

Internet

LAN

(perimeter)

(hosts/desktops)

(edge)

(server)(remote hosts/servers)

3


The big picture ….• Internet Protocol (IP)‣ Really refers to a whole collection of protocols making up

the vast majority of the Internet• Routing‣How these packets move from place to place

• Network management‣Administrators have to maintain the services and

infrastructure supporting everyone’s daily activities

4


Network Security• Every machine is connected‣ What is trust model of the network?

• Not just limited to dogs as users‣ What other ‘dogs’ are out there?

5


Network security: the high bits• The network is …‣ … a collection of interconnected computers‣ … with resources that must be protected ‣ … from unwanted inspection or

modification‣ … while maintaining adequate quality of

service.

• Another way of seeing network security is ...‣ ... securing the network infrastructure such

that the integrity, confidentiality, and availability of the resources is maintained.

6

?


The End-to-End Argument• Clark et al. discussed a property of good systems that

says features should be placed as close to resources as possible‣ In communication, this means that we want the middle

of the network to be simple, and the end-points to be smart (e.g., do everything you can at the end-points)• “Dumb, minimal network”

‣ This is the guiding principle of IP (Internet)‣ Q: Does this have an effect on security?

• Note: this is a departure from the early networks which smart network, dumb terminals

7


Exploiting the network ...• The Internet is extremely vulnerable to attack‣ it is a huge open system ...‣ which adheres to the end-to-end principle

• smart end-points, dumb network

• Can you think of any large-scale attacks that would be enabled by this setup?

8


• Bellovin’s observations about security problems in IP‣ Not really a study of how IP is misused, e.g., IP addresses for

authentication, but really what is inherently bad about the way in which IP is setup

• A really, really nice overview of the basic ways in which security and the IP design is at odds (circa 1989)

Security Problems in the TCP/IP Protocol Suite

9


• TCP/IP uses a three-way handshake to establish a connection1.C -> S: QC

2.S -> C: QS, ack(QC) where sequence number QS is nonce

3.C -> S: ack(QS) … then send data

2. However assume the bad guy does not hear msg 2, if he can guess QS, then he can get S to accept whatever data it wants (useful if doing IP authentication, e.g., “rsh”)

Client Server

Adversary

Sequence number prediction

10


• The only way you really fix this problem to stop making the sequence numbers predictable:‣ Randomize them -- you can use DES or some other

mechanism to generate them randomly‣ There is an entire sub-field devoted to the creation and

management of randomness in OSes

• Also, you could look for inconsistencies in timing information‣ Assumption: the adversary has different timing‣ OK, may be helpful, but far from definitive

Sequence Number Prediction (fixes)

11


• Collaborative TCP Sequence Number Inference Attack -- How to Crack Sequence Number Under A Second

Zhiyun Qian, Z. Morley Mao, Yinglian Xie

In Proceedings of ACM Conference on Computer and Communications Security (CCS) 2012, Raleigh, NC.

• Off-Path TCP Sequence Number Inference Attack -- How Firewall Middleboxes Reduce Security Zhiyun Qian, Z. Morley Mao

In Proceedings of IEEE Security and Privacy (Oakland) 2012, San Francisco, CA.

• Still have TCP sequence number attacks

What’s Changed?

12


• ICMP is used as a control plane for IP messages‣ Ping (connectivity probe)

‣ Destination Unreachable (error notification)

‣ Time-to-live exceeded (error notification)

• These are largely indispensable tools for network management and control‣ Error notification codes can be used to reset connections

without any authentication

• Solution: verify/sanity check sources and content

‣ ICMP “returned packets”

• Real solution: filter most of ICMP, ignore it

Internet Control Message Protocol (ICMP)

13


• Protocol used to map IP address onto the physical layer addresses (MAC)

1) ARP request: who has x.x.x.x?2) ARP response: me!

• Policy: last one in wins• Used to forward packets on the appropriate interfaces

by network devices (e.g., bridges)

• Q: Why would you want to spoof an IP address?

Address Resolution Protocol (ARP)

14


• Attack: replace good entries with your own• Leads to ‣ Session hijacking‣ Man-in-the-middle attacks‣ Denial of service, etc.

• Lots of other ways to abuse ARP.• Nobody has really come up with a good solution‣ Except smart bridges, routers that keep track of MACs

• However, some not worried‣ If adversary is in your perimeter, you are in big trouble‣ You should validate the source of each packet independently

ARP poisoning

15


• Post office protocol - mail retrieval‣ Passwords passed in the clear (duh)‣ Solution: SSL, SSH, Kerberos

• Simple mail transport protocol (SMTP) - email‣ Nothing authenticated: SPAM‣ Nothing hidden: eavesdropping‣ Solution: your guess is as good as mine

• File Transfer protocol - file retrieval‣ Passwords passed in the clear (duh)‣ Solution: SSL, SSH, Kerberos

POP/SMTP/FTP

16


• DNS maps between IP address (12.1.1.3) and domain and host names (ada.cse.psu.edu)‣ How it works: the “root” servers redirect you to the top

level domains (TLD) DNS servers, which redirect you to the appropriate sub-domain, and recursively ….

‣ Note: there are 13 “root” servers that contain the TLDs for .org, .edu, and country specific registries (.fr, .ch)

DNS - The domain name system

17

root edu psu.edu cse.psu.edu

Host Resolver

ada.cse.ps.edu? 216.10.243.112


A DNS query

18

a-root-servers.net

a.gtld-servers.org

ns-patrickmcdaniel.org

ISP Nameserver

User PC

www.patrickmcdaniel.org?

redirect


redirect


207.140.168.131

www.patrickmcdaniel.org? 207.140.168.131

2

3

4

5

6

7

1 8www.patrickmcdaniel.org = 207.140.168.131

DNS Cache


“Glue” information• Suppose you ask a name server for a record and it

redirects you to another name server (NS record)‣ e.g., if you ask a root for a NS (name server) record for NET, it

returns NS records for the authoritative servers for .net• It will also give you the A (resource) record for the

authoritative servers you were directed to‣ avoid looking them up‣ This is known as the “glue” records

19


• Nothing is authenticated, so really the game is over‣ You cannot really trust what you hear …‣ But, many applications are doing just that.‣ Spoofing of DNS is really dangerous

• Moreover, DNS is a catalog of resources‣ Zone-transfers allow bulk acquisition of DNS data‣ … and hence provide a map for attacking the network

• Lots of opportunity to abuse the system‣ Relies heavily on caching for efficiency -- cache pollution‣ Once something is wrong, it can remain that way in caches

for a long time (e.g., it takes a long time flush)‣ Data may be corrupted before it gets to authoritative server

DNS Vulnerabilities

20


A Cache Poisoning Attack• All requests have a unique query ID

• The nameserver/resolver uses this information to match up requests and responses

• If an adversary can guess the query ID, then it can forge the responses and pollute the DNS cache‣ 16-bit query IDs (not hard)

‣ Some servers increment IDs (or use other bad algo.)

‣ First one in wins!!!

• Note: If you can observe the traffic going to a name server, you can pretty much arbitrarily own the Internet for the clients it serves.

21


Kaminsky DNS Vulnerability1.Query a random host in

a victim zone, e.g., 1234.cse.psu.edu

2.Spoof responses* as before, but delegate authority to some server which you own.

1. The glue records you give make you authoritative

3.You now own the domain.

22*the original attack exploited poor ID selection


Kaminski Fixes• Make the ID harder to guess (randomized ports)‣ Amplified ID space from 216 to 227

• Prevent foreign requests from being processed‣ E.g., filter requests from outside domain

• Observe and filter conflicting requests‣ E.g., if you see a lot of bogus looking requests, be careful

• All of this treats the symptoms, not the disease.‣ Lack of authenticated values‣ Thus, if you can observe request traffic, prevent legitimate

responses, or are just plain patient, you can mount these attacks.23


Other Issues (Bailey et al)• DNS Resolvers‣ Amplification attacks - Spoof IP address of DNS requestor‣ Disable recursive DNS resolution

• A and PTR records• Malicious IPs often have inconsistent A and PTR records • Make PTR records consistent with A records

• BGP Misconfiguration• Border Gateway Protocol (BGP) to exchange advertised routes• New route announcements should be infrequent and long-lived

• Egress Filtering‣ Prevent IP address spoofing by filtering egress packets not from

inside your network

24


Configuration Guidelines• Well-documented in published Request for Comments

(RFCs) and Best Current Practices (BCPs)

25

Symptoms Best Current Practices Functions Attacks DatasetOpen Recursive Resolvers BCP 140/RFC 5358 Naming Infrastructure DNS Amplification GlobalDNS Source Port Randomization RFC 5452 Naming Infrastructure DNS Cache Poisoning GlobalConsistent A and PTR records RFC 1912 Naming Infrastructure - PartialBGP Misconfiguration RFC 1918, RFC 6598 Routing Infrastructure - GlobalEgress Filtering BCP 38/RFC 2827 Transit - PartialUntrusted HTTPS Certificates RFC 5246, RFC 2459 Web Application Man-in-the-middle GlobalOpen SMTP Mail Relays RFC 2505 Mail Application SPAM GlobalPublicly Available out-of-band Management Devices Manufacturer’s Guideline Server Compromising Hosts Global

TABLE I. SUMMARY OF MISMANAGEMENT METRICS AND THE THIRD-PARTY, PUBLIC DATA SOURCES USED FOR VALIDATION

In order to determine whether networks have patched theirDNS resolvers with source port randomization, we analyzethe set of DNS queries made against VeriSign’s [17] .comand .net TLD name servers on February 26, 2013. In total,we observed approximately 5 billion queries from 4.7 millionDNS resolvers.

In this experiment, we track the source ports utilized tomake DNS queries against these TLD servers and infer thatresolvers that only utilize the default source port withoutimplementing source port randomization are misconfigured.We find that 226,976 resolvers, which account for 4.8% oftotal resolvers seen in the data, do not utilize source portrandomization.

C. Consistent A and PTR records

DNS supports several types of records, of which Address(A) and Pointer (PTR) records are two of the most common.An A record is used to map a hostname to an IP address. APTR record resolves an IP address to a canonical name.

One merit of PTR records is that they facilitate the valida-tion of connecting clients and are widely used for detecting andblocking malicious IP addresses. For example, SMTP serversoften discard messages from IP addresses without a matchingPTR or MX record. The DNS operational and configurationguidelines (RFC1912 [18]) dictate that every A record shouldhave a corresponding PTR record[19].

In our study, we utilize two datasets in order to estimate theglobal status of DNS records: the .com and .net second leveldomains stored in the VeriSign zone files and the domains inthe Alexa Top 1 Million popular websites [20].

In order to determine which A records have associated PTRrecords, we perform a DNS query for each domain in our twodatasets, finding 116 million A records. We then perform areverse DNS lookup of the IP addresses appearing on these116 million A records. We find that 27.4 million A records,which account for 23.4% of A records we queried, do not havea matching PTR record.

We note that our dataset is biased toward domains withinNorth America and Europe. However, given that .com and .netdomains account for more than half of all domains on theInternet [21] and that Alexa includes the most popular sites inthe world, we believe our results still provide insights into thestatus of DNS records management.

D. BGP Misconfiguration

Publicly routed networks utilize Border Gateway Protocol(BGP) in order to exchange advertised routes. A router canannounce a new route for a prefix or withdraw a route when it

is no longer available. Routers are expected to not send updatesunless there are topological changes that cause its advertisedroutes to change. However, misconfiguration and human errorcan result in unnecessary updates, which can potentially leadto both security vulnerabilities (e.g., Bogons [22], [23]) anddowntime (e.g., AS7007 incidents [24]).

Mahajan et al. note that 90% of short-lived announcements(less than 24 hours) are caused by misconfiguration [25]. Thisis because policy changes typically operate on human time-scales, while changes due to misconfiguration typically lastfor a much shorter time.

In order to measure BGP misconfigurations, we use thissimple heuristic in coordination with BGP updates from12 BGP listeners in the Route Views project [26]. In ourexperiment, we track the time period for every new routeannouncement during the first two weeks of June, 2013 andinfer that routes that last less than a day were likely causedby misconfiguration. We detect 42.4 million short-lived routes,which account for 7.8% of announced routes during the periodof two weeks. We note that the Mahajan methodology is dated,and a fruitful area of future work would be to validate thismethodology in the context of current routing practice (i.e.,the current practice of fine-graned routing announcements).

E. Egress Filtering

Attackers often spoof source IP addresses to achieveanonymity or as part of DDoS attacks [27], [28]. In order tocounter these attacks, it has been a best practice since 2000,to perform egress filtering as documented in BCP 38 [5].

In order to measure which networks have implementedegress filtering, we consider data from the Spoofer Project [29],which utilizes approximately 18,000 active clients to sendprobes to test for the presence of egress filtering. We specifi-cally analyze data from April 29, 2013 and check in whichnetblocks an arbitrary routable source IP address can bespoofed. Because spoofed IP addresses are primarily used byattackers, we consider netblocks that do not implement addressfiltering to be misconfigured. The dataset from April 29thcontained results for 7,861 netblocks, of which 35.6% havenot implemented egress filtering. Unfortunately, the status ofthe remaining 195,000 netblocks is unknown.

F. Untrusted HTTPS Certificates

HTTPS sites present X.509 certificates as part of the TLShandshake in order to prove their identity to clients. Whenproperly configured, these certificates are signed by a browser-trusted certificate authority.

3


• A standard-based (IETF) solution to security in DNS‣ Prevents data spoofing and corruption‣ Public key based solution to verifying DNS data‣ Authenticates

• Communication between servers• DNS data ‣ content

‣ existence

‣ non-existence

• Public keys (a bootstrap for PKI?)

DNSSEC

26


• Securing the DNS records‣ Each domain signs their “zone” with a private key‣ Public keys published via DNS‣ Indirectly signed by parent zones‣ Ideally, you only need a self-signed root, and follow keys down

the hierarchy

cse.psu.eduroot psu.edu.eduSigns Signs Signs

DNSSEC Mechanisms

27


• TSIG : transaction signatures protect DNS operations‣ Zone loads, some server to server requests (master ->

slave), etc.‣ Time-stamped signed responses for dynamic requests‣ A misnomer -- it currently uses shared secrets for TSIG

(HMAC) or do real signatures using public key cryptography

• SIG0: a public key equivalent of TSIG‣ Works similarly, but with public keys‣ Not as popular as TSIG

• Note: these mechanisms assume clock sync. (NTP)

DNSSEC Mechanisms

28

Documents

CSE543 Computer and Network Security Module: Network Securitytrj1/cse543-f16/slides/cse543-network-security.pdf · CSE543 - Introduction to Computer and Network Security Page •