Internet infrastructure 1

Infrastructure Security r User expectations  Reliable service  Reliable endpoints – although we know of spoofing and phishing  Partial expectations – “good” route (not through malicious nodes), confidentiality, integrity  Implied expectations: temporary data, blending with the crowd r Unreliable endpoints or routes facilitate attacks on confidentiality and integrity  Routes through malicious nodes = MITM 2

Some Infrastructure Features r Networks  LAN  AS (ISP network)  Inter AS connections, r Routers r Application level servers (e.g. web, mail,…) r Protocols  ARP  DNS  Routing protocols 3

ARP 4

r Resolves IP address to link-layer address r Simple request-reply protocol r Packet includes MAC and IP addresses for sender and target. r If target MAC is unknown send request for target IP and broadcast MAC (all 0xF) r Response includes MAC address r Requester stores MAC-IP mapping in ARP table r Any node in LAN requires at least one ARP request to connect to Internet 5

ARP Spoofing / Poisoning r ARP is stateless – requests are not connected too replies in a session r Implementations update ARP tables in response to ARP replies (even if entries are still valid) r ARP spoofing – send ARP reply with attacker’s MAC and spoofed (usually gateway) IP r Result – poisoned ARP tables r Legitimate use – force registration to receive full network access, e.g. in hotels 6

Countermeasures r Static ARP tables r Update ARP entries only after timeout r Update ARP entries only after sending request (Linux) r Check unusual ARP behavior, e.g. large number of packets r Upgrade to protocol with cryptographic protection (SEND is a secure version of NDP over IPv6)  Example of IPsec problem – chicken and egg with IP addresses in IKE 7

Attack on Behavior Analysis* r Assume node disregards “abnormal” ARP activity, e.g.  If MAC x sends many ARP replies with IP y then node assumes that MAC x is not IP y r Attack:  Attacker spoofs gateway MAC (in Ethernet and ARP headers)  Attacker mimics “bad” behavior for gateway  Node disregards gateway  Attacker sends single reply with its own MAC and gateway IP 8

DNS 9

DNS Architecture r Objective – map name to IP address r Domain – e.g. *.bgu.ac.il. *cse.bgu.ac.il could be a sub-domain or separate domain r DNS client (resolver) r Records: A (IP address), NS (name server), MX (mail server) etc. r Name server –  Authoritative  Recursive r Hierarchy 10

Server Hierarchy r 13 root name servers  Named by letters A,…,M  Responsible for root domain (empty string) r Name limited by 512 byte size of DNS packet over UDP without fragmentation r All root servers are clusters r Some are geographically distributed by anycast r Top Level Domain Servers  20 GTLD (global/generic) – e.g. responsible for.net,.com etc.  ~250 Country code TLD 11

DNS Query r Triggered by application r Local DNS server may  Be authoritative  Cache recently seen record  Send query to root name server r Queries follow recursive path to authoritative name server r Answered queries populate cache. r Each entry in cache has TTL (set by administrator) 12

Cache Poisoning and Defenses r Cache poisoning – fill name server’s cache with mapping of domains to attacker’s IP r Defense:  Response destination port matches request source port  Response Question ID (QID), 16 bits, must match  Bailiwick checking – response is for lower domain in hierarchy, NS for ac.il not accepted for bank.co.il r Weaknesses in “old” implementations – QID incremented by 1 for each query, source port does not change, bad replies are simply dropped 13

DNS poisoning r Attacker sets up name server for attacker domain. r Attacker gets target name server to send DNS request to its own server learning QID  Directly  Open web page and users will ask for it r Attacker sends query through target name server for some domain, e.g. bank.co.il r Attacker floods name server with forged replies, guessing source port and QID. r If attacker reply arrives before real reply, the cache is poisoned. 14

Countermeasures r Randomize QID r Refresh source port  Will have negative impact on performance r Monitor for flood situation  Will have negative impact on performance 15

Kaminsky Attack (2008) r Send request for name that doesn’t exist in a real domain r Send flood of forged replies as in previous attacks r Each reply forges name server of domain r Set very long TTL r Same idea could work for GTLD servers (i.e..com) but not for root servers r Mitigation – randomize source port, currently Windows has 2500 source ports for DNS – 2500*2 16 possibilities 16

DNSSEC r Objectives for DNS traffic  Origin authentication  Integrity protection  Authenticated denial of existence r Method: PKI with certificate for every DNS server anchored (root CA) by root DNS. r PKI is chain of:  DNSKEY – public keys for signature verification  DS – Delegation Signer, includes hash of keys  Parent DNSKEY signs DS. Each DS includes hashes of public keys used for self signing the child DNSKEY and for signing zone data 17

DNSSEC (cont.) r DNSKEY often includes  ZSK – Zone Signing Keys – validating zone data  KSK – Key Signing Keys – Validating other keys r Resolver is configured with root public key  May be configured with additional anchors r Resolver uses DNS to collect DNSKEY and DS records from root to key signing the requested zone r Zone data is signed in RRSIG records 18

Denial of existence r Attackers goal:  Spoof “does not exist” r To solve problem, DNS servers that comply with DNSSEC store NSEC records  Names appear in canonical form  NSEC - signed “next existing” name  Result: signed ranges of non-existent names r Query for name that doesn’t exist is answered with signed range that “covers” this name 19

Zone Enumeration in DNSSEC r Zone enumeration – obtain all addresses in domain  Creators of DNSSEC did not consider this to be a threat  Most organizations consider this secret r Attacker enumerates zone by  Querying random name  Receiving range  Deducing that names in range bounds exist  Iterating 20

Mitigation of Zone Enumeration r Online approach (currently RFC 4470)  Name server signs “does not exist” online  Name server constructs small (and ever-decreasing range to sign) r NSEC3 approach (currently RFC 5155)  Same idea as NSEC, but use hashed name (cryptographic hash) instead of name  Range does not reveal names r Common names may still be found by dictionary attack  NSEC3 uses several hash functions with a counter on the number of iterated uses of the hash, increasing attacker dictionaries. 21

DoS Attacks r October 2002  One hour  All 13 root name servers simultaneously  About 900 Mbps total  ICMP flood, SYN flood, fragment flood  No server crashed, some queries were lost r February 2007  24 hours  4 root servers, 3.info servers  Botnet of ~5000 hosts mostly in Korea  Flood of DNS queries  Two name servers lost up to 90% of the queries 22

BGP 23

Border Gateway Protocol r One of the standard suite of Internet routing protocols r Is the most common inter-domain routing protocol  Connects different AS, often different service providers  Tens of thousand of different AS r Attackers want to break integrity  MITM  Block access to sites  Use rare IP addresses for e.g. spam r Several prominent incidents led to outage or redirection of large part of Internet 24

IP blocks and AS numbers 25

BGP route advertisements 26

False route 27

More specific route 28

Additional problems r Manipulation of BGP attributes  Prepending – adding the same AS multiple times to a route, causing it to be longer r BGP runs over TCP – vulnerable to various TCP issues r Solutions – deployed solutions include route filtering and route registries, nothing strong 29