Network Security Introduction Adversaries and Poisoning Amir Herzberg
Network Security: Introduction, Adversaries and Poisoning Amir Herzberg http: //Amir. Herzberg. com 12/6/2020 http: //Amir. Herzberg. com 1
Network Security: Course Plan Introduction, Adversaries and Poisoning Network and transport hacking Reconnaissance / Scan attacks Packet filtering and firewalls Intrusion Prevention & Detection Systems (IPS/IDS) Malicious Input Attacks Code corruption attacks, esp. buffer overflow Service (SQL, command) injection Malicious script attacks (e. g. Cross Site Scripting) Session / credential attacks Inconsistent parsing Email security Email confidentiality and authenticity Spam and phishing Denial of service 03/02/09 Amir. Herzberg. com
Adversaries and Poisoning: Outline Introduction: Internet vs. Security ? Adversary capabilities / models Sniffing ARP poisoning DNS poisoning 03/02/09 Amir. Herzberg. com
Internet and Security Internet began as a US Do. D project in the 1970 s Main concern was survivability to a physical (atomic) attack Decentralized for survivability Centralized design is simpler, and was already known (IBM’s SNA) Would not survive atomic bomb on `center` of Net Hence: distributed routing, directory, etc. Connectivity and usability before security 12/6/2020 http: //Amir. Herzberg. com 4
Internet and Security: Guidelines Decentralized for survivability Connectivity and usability before security Accept from everybody, forward to everybody This holds for Packets (IP), email, etc. Does not validate packet/email source addresses This allows spoofing, but also ensures survivability Assumption: attackers external to Network 12/6/2020 Computers are well protected and managed securely http: //Amir. Herzberg. com 5
Today: The Internet is Vulnerable… Internet is global, open, everybody online… Computers are unprotected, unmanaged Including the attackers! Insecure platforms (Windows, IE) Naïve users Many, untrusted clients and peers Many threats / attacks… 12/6/2020 http: //Amir. Herzberg. com 6
Acute Threats and Attacks Ads and phishing Do. S Spam Denial of Service (hate, compete, blackmail) Malware Virus, Trojan, Worm, Spyware, … 12/6/2020 Con-Sites Fake (spoofed) sites, Scam/fraud sites Intrusion http: //Amir. Herzberg. com 7
Threats are Related… Do. S Spam Malware Con-Sites Intrusion 12/6/2020 http: //Amir. Herzberg. com 8
Private Network Threats Pre-Internet: Private Networks All processors belong to corporation `trusted` Attackers: Remote client (guess password, control system…movies? ) Eavesdropper (sniffer) : in proximity of wiring Insider (controls machine): main threat to private network 12/6/2020 Threat: use of that machine to attack more machines http: //Amir. Herzberg. com 9
Sniffing Requires Proximity Sniffing Eavesdropping to particular segment/net Easy – if adversary has access to shared media No hardware: ‘Promiscuous mode’ Man In The Middle (MITM) attacker for shared media Access to shared media: Wireless links (home, café, campus, corporate) Or: adv in same `collision domain’ as sender/recipient Listen to packets for all destinations Available with most network adapters Same Ethernet cable or same hub Or, hardware sniffing 12/6/2020 E. g. long-range Wi. Fi sniffing (war-driving) – easy! http: //Amir. Herzberg. com 10
Switches and Traffic Isolation Packets broadcasted inside segments Traffic isolation: forward only as needed By learning the link addresses in each segment Goals: performance and security MITM on specific segment, blind on others Switch Eve Alice Bob 12/6/2020 http: //Amir. Herzberg. com 11
Switched Networks and Blind Attackers Consider network connected by switches/routers Easy: Blind Adversary: only inject, can’t eavesdrop Send packet with false IP (and/or MAC) address Harder, rare: Man In The Middle (MITM) Adversary Also: receive packets sent to victim’s IP/MAC address Eve Alice Bob 12/6/2020 http: //Amir. Herzberg. com 12
Adversarial Capabilities, `Models’ Model capability Intercept Inject (& block? ) Host / client only No No Eavesdropper / sniffer Yes No Blind/spoofing No Yes (no block) MITM (spoof, sniff, block) Yes; with or without blocking 12/6/2020 http: //Amir. Herzberg. com 14
Adversarial Model vs. Network Type Network Adversary MITM Shared (private) Rare Switched Common Rare (exc. Rare same seg. ) Rare Internet (routers) Rare (spoof, sniff, block) Sniffer / eavesdropper (no spoof) Spoofer / Rare Blind Client only Always 03/02/09 Common Always Amir. Herzberg. com
MITM in Spite of Switch? Switch isolation blind attacker How blind attacker becomes MITM? Degradation attack: many switches change to `Hub behavior` if MAC table too large Poisoning Attacks: Achieve MITM capabilities by `poisoning` address resolution: IP address MAC address (ARP Poisoning) Domain name IP address (DNS Poisoning) 12/6/2020 For internets too (connected by routers) http: //Amir. Herzberg. com 16
Adversaries and Poisoning: Outline Introduction: Internet vs. Security ? Adversary capabilities / models Sniffing ARP poisoning Quick refresh on ARP (skip this) ARP methods and defenses DNS poisoning 03/02/09 Amir. Herzberg. com
Addresses in Data Link Layer 32 -bit IP address: network-layer address used to route to destination network LAN (or MAC or physical or Ethernet) address: To identify source & destination on same network Known to the adapter (e. g. in PROM) Most LANs: 48 bits, global address space Few LANs: configurable, e. g. as function of IP addr Special broadcast address – send to all nodes 12/6/2020 Used for address resolution (ARP)… http: //Amir. Herzberg. com 18
Address Resolution Table Each host maintains its own address resolution table Each entry correlates between IP address and MAC address In an entry there is a field that marks the way the entry was created (Static or Dynamic) Example: IP Address MAC Address TTL 1. 1. 24. 1 00: 30: 7 b: 91: bd: 6 c 8: 00 1. 1. 24. 65 00: 60: e 1: 00: 9 c: 70 --- 1. 1. 24. 223 00: 60: e 1: 00: 07: 91 8: 03 12/6/2020 http: //Amir. Herzberg. com 19
ARP Mechanism Broadcast Request: Sender IP, Sender MAC, Target IP A B C C learns A’s IP, MAC B, D could also learn, but usually don’t (since they may not send to A). D Unicast Response A learns C’s IP, MAC 12/6/2020 A B http: //Amir. Herzberg. com C D 21
ARP protocol (RFC 826) A wants to send datagram to B, knows B’s IP address. B on same subnet… but her MAC addr not in A’s table A broadcasts ARP query packet, with B's IP address all machines on subnet receive ARP query B receives ARP query, replies to A with its (B's) MAC address 12/6/2020 A caches <IP, MAC> in ARP table soft state: throw if not used for some time “Plug-and-play” Sent to A’s MAC address (unicast) http: //Amir. Herzberg. com 22
ARP Poisoning Attackers are often on isolated segments How to intercept traffic from Alice to Bob? Trick Alice into sending to Eve’s MAC address ARP poisoning attack: Alice uses ARP broadcast to find Bob Eve answers Alice uses Eve’s Link address Eve can forward to Bob becomes MITM Switch Eve Alice Bob 12/6/2020 http: //Amir. Herzberg. com 23
ARP Poisoning Methods Unsolicited Send ARP request with false sender’s IP (some) hosts use to update their ARP tables Send ARP response with incorrect mapping Unsolicited: (some) hosts update their ARP table even if they didn’t make request Solution: ignore unsolicitated mappings Response to ARP request Mapping to attacker’s MAC address Send upon hearing / expecting request Race with legitimate reply 12/6/2020 Improve chances by loading destination’s segment/host http: //Amir. Herzberg. com 24
Preventing `MITM via ARP Poisoning` Static address resolution tables (IP MAC) Monitoring to detect ARP-poisoning packets, ports Port security mechanisms in switch Block unsolicited mappings Disconnect port which attempts ARP poisoning Allow only one MAC address per port Limit rate of ARP requests/responses per port Block ARP requests/responses conflicting with DHCP Separate networks by routers, not switch! 12/6/2020 May try DNS-Poisoning instead… http: //Amir. Herzberg. com 25
Port Security Mechanisms Block unsolicited mappings Disconnect port which attempts ARP poisoning Allow only one MAC address per port Limit rate of ARP requests/responses per port Block ARP requests/responses conflicting with DHCP Notice: spoofing DHCP responses would allow similar attack… prevent by allowing DHCP responses only from trusted port Switch Eve Alice IP: … MAC: Bob 12/6/2020 DHCP Server http: //Amir. Herzberg. com Gateway 26
Adversaries and Poisoning: Outline Introduction: Internet vs. Security ? Adversary capabilities / models Sniffing ARP poisoning DNS poisoning 03/02/09 Reminder: DNS (skip this) DNS security goals DNS poisoning by out-of-bailiwick glue RR DNS poisoning by spoofed responses Amir. Herzberg. com
DNS Resolution Process Client Local Server Resolve `A` www. bob. com Root Server Resolve `NS` com TLD Authoritative Server ns. bob. com 132. 3. 3. 4 Server 156. 4. 5. 6 `NS` 132. 3. 3. 4 Resolve `A` www. bob. com `NS` ns. bob. com `A` 156. 4. 5. 6 Resolve `A` www. bob. com `A` 156. 6 (IP of www. bob. com) Request to 156. 6 (www. bob. com) 12/6/2020 http: //Amir. Herzberg. com 29
Domain Names and IP Addresses IP packets contain source, dest IP addresses Routers use IP Addresses To deliver packets to their destinations Users use Domain Names, e. g. www. foo. edu Domain Names are hierarchical, and: 32 bits, e. g. 128. 33. 44. 223 Meaningful: *. edu: university, www. *: web server Easier to manage, remember and use DNS – Map domain names to IP addresses 12/6/2020 Fixed IP, current IP, best IP (e. g. proximity) http: //Amir. Herzberg. com 30
DNS Caching is critical for DNS performance All DNS modules perform caching Client DNS Cache Local DNS Server Cache DNS server used only to cache records Clients always access this server May be nested (… DNS. foo. edu ISP DNS) Caching is of DNS Resource Records (RR) 12/6/2020 http: //Amir. Herzberg. com 31
Reverse DNS `Reverse` DNS query: IP name How? PTR query to in-addr. arpa domain E. g. , r. DNS for IP=1. 2. 3. 4 : DNS query for PTR record for address 4. 3. 2. 1. in-addr. arpa Note reverse order of address bytes (why? ) 4. 3. 2. 1. in-addr. arpa controlled by ISP/owner Use for security: 12/6/2020 Servers should have r. DNS to domain name Use r. DNS to identify (dial-in, DSL, …) clients http: //Amir. Herzberg. com 32
DNS Messages DNS protocol: send request, receive reply Single format for requests & replies Header Questions Answers Authority Other ID (16 bits) Flags Name Number of questions Number of answers Type of RR Number of authority Number of other 12/6/2020 Name Type of RR TTL in seconds Value RR (Resource Record) http: //Amir. Herzberg. com 33
DNS Security: Goals Authenticity Owners should control mappings (name IP) DNS-Security: cryptographically-signed DNS RR Availability To ensure security against MITM attacker Although MITM attacker can forget IP addresses anyway See few extra foils after conclusions Prevent Denial of Service (Do. S) attacks Non-Goal: Confidentiality 12/6/2020 Protocol allows any server to query any other Servers may restrict distribution Encrypt records if needed (non-standard) No support for hiding requests Undesirable: allowing `what’s there? ` query http: //Amir. Herzberg. com 34
MITM via DNS Poisoning Allows blind attacker to become MITM Web spoofing / phishing attacks Spoof blacklist responses, … Bob. com 129. 4. 4. 5 3. Dst. IP=6. 6 Dear Bob, … 1. DNS request: bob. com 2. Response: bob. com 6. 6 0. Poison: bob. com 6. 6 DNS server 12/6/2020 http: //Amir. Herzberg. com 35
Poisoning by out-of-bailiwick glue Normally: RR is received to fulfill request RR Gratuitous RR: received without request In response to different request or appended to a DNS request Use to send glue RR to help resolve referred-to NS: Query: x. foo. co. il A = ? Authority: foo. co. il NS ns. foo. com, foo. co. il NS dns. foo. co. il Additional: ns. foo. com A 1. 2. 3. 4, dns. foo. co. il A 5. 6. 7. 8 These are `glue RR`: providing IP for authority NS Abuse: poison RR for referred-to NA (ns. foo. com) Since ~1997: (most) servers accept (glue) RR only if in-bailiwick: in domain of same name server In above example: accept only dns. foo. co. il A 5. 6. 7. 8 If spoofed… attacker can poison every address of foo. co. il! 12/6/2020 http: //Amir. Herzberg. com 36
Adversaries and Poisoning: Outline Introduction: Internet vs. Security ? Adversary capabilities / models Sniffing ARP poisoning DNS poisoning 03/02/09 Reminder: DNS (skip this) DNS security goals DNS poisoning by out-of-bailiwick glue RR DNS poisoning by spoofed responses Amir. Herzberg. com
Poisoning by Spoofed Response Would local server `eat it’? RFC 5452 [read!]: Local server must validate: Same question section as in request Same (16 -bit) ID field Same dest IP address and port as source in request Chosen randomly; preferably: pool of IPs Same IP address of responding DNS server Local server must choose ID randomly Most domains have 2 -3 likely-to-be-used servers Response received within reasonable delay 12/6/2020 And ignore if already received valid response for this query http: //Amir. Herzberg. com 38
Poisoning by Spoofed Response RFC 5452 [read!]: Local server must validate: Same question section as in request Same (16 -bit) ID field Same dest IP address and port as source in request Same IP address of responding DNS server Response received within reasonable delay All these won’t help if attacker can eavesdrop (or MITM) [notes] Reality: most servers used fixed source port 12/6/2020 Or predictable ports, e. g. consecutively Or don’t confirm port etc. on responses Till Kaminsky’s attack, patch [2008] Many still do (30%? ) http: //Amir. Herzberg. com 39
Response Authentication for Blind Adv. Prevent spoofing of response by blind adversary Alice sends request with random nonce. Alice General technique – used by DNS (this lecture), TCP, … Referred to as challenge Explicit (e. g. DNS identifier, TCP ISN), implicit (port #, IP) Bob reply with nonce. Alice knows reply is fresh from Bob! Critical: random, sufficient-long challenges (nonces) 12/6/2020 We’ll discuss relevant attacks on DNS (next), TCP (later) http: //Amir. Herzberg. com 40
Kaminsky’s attack Init: i=1 1. Determine (small) set P of DNS requesting ports 2. Sends queries for i+". bob. com" 3. Sends many responses (random ID, port in P): bob. com NS eve. bob. com A 6. 6 4. Test: query www. bob. com; is resulting IP 6. 6? Yes Poisoning successful!! 12/6/2020 http: //Amir. Herzberg. com i=i+1 No (failed) 41
Spoofed response poisoning: analysis I: number of distinct IDs (max. 65536) P: number of ports (max 65536 -1024=64512) N: number of authoritative name servers (~2. 5) F: number of fake packets sent Before local gives up or auth-ns response received D: number of identical outstanding queries Spoof. Prob=DF/NPI 12/6/2020 For small values of D. Birthday paradox: with Spoof. Prob>1/2 if D, F>SQR(NPI) Many local servers allow large D (for stateless design) http: //Amir. Herzberg. com 42
How to send responses in time? Response must be in `window of opportunity` Could predict request by TTL Attacker can learn since TTL sent to all clients Can cause request: From attacker-controlled machine (zombie), or Open recursive DNS resolution (don't allow!), or Link from webpage or script (visited by user), or Request for MX or other email-initiated domains But: relatively few `windows of opportunity' RFC 5321: limit # of DNS queries for each ext. connection Request non-existing domain (never in cache!) 12/6/2020 http: //Amir. Herzberg. com 43
How to beat authoritative DNS? Response must be in `window of opportunity` I. e. , must arrive before auth-DNS's response Can slow down or block response: Some DNS servers don't respond to `bad` domains Can slow down network or server by sending many requests (clogging, Denial of Service) Can cause blocking of request/response in NAT can also ruin local DNS port randomization and more 12/6/2020 http: //Amir. Herzberg. com 44
Adversaries and Poisoning: Outline Introduction: Internet vs. Security ? Adversary capabilities / models Sniffing ARP poisoning DNS poisoning Reminder: DNS (skip this) DNS security goals DNS poisoning by out-of-bailiwick glue RR DNS poisoning by spoofed responses 03/02/09 Kaminsky’s attack, analysis DNS behind NAT attacks (skip refresh on NAT) Amir. Herzberg. com
IP Addresses / Ports and NAPT IP addresses identify (source, dest) host Ports identify (source, dest) process Fixed server ports: A port is a 16 -bit identifier At beginning of IP payload HTTP (Web): 80, SMTP (email): 25 … Fixed so client knows port # to reach server process Client ports assigned (`randomly`) by OS Network Address/Port Translation (NAPT): share IP address, identify host by port 03/02/09 Amir. Herzberg. com
NAPT/NAT: Network Address (Port) Translation Goal: share IP addresses among multiple hosts How: identify host by port 2. Src. IP=133. 44. 5. 8 Src. Port=6678 Dst. Port=80 3. Dst. IP=133. 44. 5. 8 Src. Port=80 Dst. Port=6678 03/02/09 Amir. Herzberg. com 1. Src. IP=10. 0. 0. 1 Src. Port=3373 Dst. Port=80 4. Dst. IP=10. 0. 0. 1 Src. Port=80 Dst. Port=3373
NAT Port Assigning Methods NATs differ on how they allocate, free ports When to free assigned port? Risks: port exhaustion; packets misrouting/loss TCP: can free after closure (RST/FIN) UDP: no closure… free after inactivity period How to assign external ports? Random-port-assigning NAT Sequential port assigning NAT Port-preserving NAT (when available) Cone NAT: 03/02/09 If assigned ext-port x to internal (port, src. IP) to dst. IP Then reassign x (if available) if (port, src. IP) sents to newd. IP Read: RFC 4787, NAT Behavioral Requirements Amir. Herzberg. com
NAT Hole Punching How peers behind NAT communicate? Easy if _one_ of them is not behind NAT Acts as server (known port) If both behind NAT: Use help from peer/server not behind NAT `Hole punching` - allow peers to know port Works (usually) even for 2 levels of NAT Method depends on type of NAT: 03/02/09 Random-port-assigning NAT – impossible? Sequential port assigning NAT - easy Cone NAT: possible Port-preserving NAT (when available) Amir. Herzberg. com
Attacks on local DNS behind NAT 1025 xxx ns. bob 1. 2. 3. 5 NS: (authoritati Name Server ns. bob. com 1. 2. 3. 5 NAT 7. 8. 9. 1 Adam 10. 3. 2. 3 Adam's Local DNS server 10. 3. 3. 4 ns. bob 1. 2. 3. 5 Zombi e 10. 1. 2. 3 Alice's Local DNS server 10. 2. 3. 4 Eve 6. 6 W: Bob's web site www. bob. com 1. 2. 3. 4 ns. bob 1. 2. 3. 5 Alice 10. 1. 2. 4 12/6/2020 http: //Amir. Herzberg. com 51
Attack on local DNS behind NAT Block NAT to authoritative server (by many requests), to delay/block `real’ response Also to `funnel` to single authoritative server NAT `breaks` using random source IP More attacks on some types of NAT: Sequential port assigning NAT – easy 03/02/09 `breaks` port randomization Advanced attacks also on Port-preserving NAT, Cone NAT (see paper) Amir. Herzberg. com
Conclusions Internet designed to survive bombs, not virus Many threats: Malware Spam and Phishing Fake (spoofed) and malicious servers Intrusion via vulnerabilities Reconnaissance/scan to find vulnerabilities Denial of Service Adversarial models 12/6/2020 MITM - rarely (initially) available Eavesdropper – requires physical proximity (unusual) Blind/spoofer – common, many ISPs don’t filter properly Client – most common; domains and IP addrs are cheap http: //Amir. Herzberg. com 53
Extra foils DNS security 03/02/09 Amir. Herzberg. com
DNS-Sec – a proposed Internet standard Goal – improve DNS authentication How? Use cryptographic public-key signatures Sign DNS mappings (signature in RR) Use private key of authoritative DNS server Signature in a separate DNS RR Higher layer authoritative server signs server’s public key Not yet widely deployed 12/6/2020 http: //Amir. Herzberg. com 55
Secure DNS: Hierarchical Key Distribution DNS RRs contain mapping and signature Resolver needs bar. com. v (public key) How? From its own RR (bar. com. RR): mapping= <foo. bar. com, 123. 45. 6. 7> Foo. bar. com. RR=<mapping, Signbar. com. s(mapping) bar. com. Map= <bar. com, 123. 45. 6. 7> bar. com. RR=< bar. com. Map, bar. com. v, Signcom. v(bar. com. Map, bar. com. v) `Small` problem: need top level public keys Other problems: 12/6/2020 Forces specific trust relationship How we know if bar. com has public key? ? http: //Amir. Herzberg. com 56
Secure DNS: proof of no (signed) RR What if bar. com has no public key? Can send unsigned RR… But: attacker may also send unsigned RR… Does not yet support Secure DNS Even if bar. com does have public key! Proof of no (signed) RR, from bar. com. RR? Proposal: bar. com. RR=< bar. com. Map, Signcom. v(bar. com. Map, “NO bar. com. v”) 12/6/2020 Problem: efficiency – need to sign *all* keys Worse – if we want to prevent replay ! http: //Amir. Herzberg. com 57
Secure DNS: proof of no (signed) RR What if bar. com has no public key? Can send unsigned RR… But: attacker may also send unsigned RR… Does not yet support Secure DNS Even if bar. com does have public key! Proof of no (signed) RR, from bar. com. RR: 12/6/2020 bar. com. Map= <bar. com, 123. 45. 6. 7> bar. com. RR=< bar. com. Map, No. Sign> No. Sign=Signcom. v(ba. com, ba. com. v; bb. com, bb. com. v, time) http: //Amir. Herzberg. com 58
Secure DNS: Identity Exposure Query? Query to unsigned domain bar. com Response: No. Sign=Signcom. v(ba. com, ba. com. v; bb. com, bb. com. v, time) This exposes the existence of ba. com, bb. com!! Why care? ? Directed attacks at them Domain name can identify vulnerability… E. g. : proxy. x. com maybe open proxy? ? Possible solution: map h(domain name) [why? ] Example of reconnaissance/scan attack 12/6/2020 http: //Amir. Herzberg. com 59
- Slides: 55