03/02/09amirherzberg.com1 network security: introduction, adversaries and poisoning amir herzberg
TRANSCRIPT
03/02/09 AmirHerzberg.com 1
Network Security: Introduction, Adversaries and PoisoningAmir Herzberg
http://AmirHerzberg.com
03/02/09 AmirHerzberg.com
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 AmirHerzberg.com
Adversaries and Poisoning: Outline Introduction: Internet vs. Security ? Adversary capabilities / models Sniffing ARP poisoning DNS poisoning
03/02/09 AmirHerzberg.com 4
Internet and Security Internet began as a US DoD project in the
1970s 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
03/02/09 AmirHerzberg.com 5
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
Computers are well protected and managed securely
03/02/09 AmirHerzberg.com 6
Today: The Internet is Vulnerable… Internet is global, open, everybody online…
Including the attackers! Computers are unprotected, unmanaged
Insecure platforms (Windows, IE) Naïve users
Many, untrusted clients and peers Many threats / attacks…
03/02/09 AmirHerzberg.com 7
Acute Threats and Attacks
SpamSpam
MalwareMalware Con-SitesCon-Sites
DoSDoS
IntrusionIntrusion
Virus, Trojan, Worm, Spyware, …
Fake (spoofed) sites, Scam/fraud sites
Denial of Service(hate, compete, blackmail)
Ads and phishing
03/02/09 AmirHerzberg.com 8
Threats are Related…
SpamSpam
MalwareMalware Con-SitesCon-Sites
DoSDoS
IntrusionIntrusion
03/02/09 AmirHerzberg.com 9
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
Threat: use of that machine to attack more machines
03/02/09 AmirHerzberg.com 10
Sniffing Requires Proximity Sniffing
Eavesdropping to particular segment/net Easy – if adversary has access to shared media No hardware: ‘Promiscuous mode’
Listen to packets for all destinations Available with most network adapters
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
Same Ethernet cable or same hub Or, hardware sniffing
E.g. long-range WiFi sniffing (war-driving) – easy!
03/02/09 AmirHerzberg.com 11
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
Alice
Bob
Eve
Switch
03/02/09 AmirHerzberg.com 12
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
Alice
Bob
Eve
03/02/09 AmirHerzberg.com 14
Adversarial Capabilities, `Models’
Yes (no block)NoBlind/spoofing
Yes; with or without blocking
YesMITM (spoof, sniff, block)
NoYesEavesdropper /sniffer
NoNoHost / client only
Inject (& block?)InterceptModel \ capability
03/02/09 AmirHerzberg.com
Adversarial Model vs. Network TypeShared
(private)Switched Internet
(routers)
MITM (spoof, sniff, block)
Rare Rare Rare
Sniffer / eavesdropper (no spoof)
Common Rare (exc. same seg.)
Rare
Spoofer / Blind
Rare Common Common
Client only Always Always Always
Adversary
Network
03/02/09 AmirHerzberg.com 16
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)
For internets too (connected by routers)
03/02/09 AmirHerzberg.com
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 AmirHerzberg.com 18
Addresses in Data Link Layer32-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
Used for address resolution (ARP)…
03/02/09 AmirHerzberg.com 19
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:
1.1.24.1 00:30:7b:91:bd:6c
1.1.24.65 00:60:e1:00:9c:70
1.1.24.223 00:60:e1:00:07:91
IP Address MAC Address
8:00
---
8:03
TTL
03/02/09 AmirHerzberg.com 21
ARP Mechanism
A B C D
Broadcast Request: Sender IP, Sender MAC, Target IP
A B C D
Unicast Response
C learns A’s IP, MACB, D could also learn, butusually don’t (since they maynot send to A).
A learns C’s IP, MAC
03/02/09 AmirHerzberg.com 22
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
Sent to A’s MAC address (unicast)
A caches <IP,MAC> in ARP table soft state: throw if not
used for some time “Plug-and-play”
03/02/09 AmirHerzberg.com 23
ARP Poisoning Attack 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
AliceBob
Switch
Eve
03/02/09 AmirHerzberg.com 24
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 Improve chances by loading destination’s segment/host
03/02/09 AmirHerzberg.com 25
Preventing `MITM via ARP Poisoning` Static address resolution tables (IPMAC) 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! May try DNS-Poisoning instead…
03/02/09 AmirHerzberg.com 26
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
Alice
Bob
Switch
EveIP:… MAC:
DHCP ServerGateway
03/02/09 AmirHerzberg.com
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 AmirHerzberg.com 29
DNS Resolution Process
Resolve `A`www.bob.com
Client LocalServer
RootServer
.com TLDServer
132.3.3.4
Authoritativens.bob.com
Server156.4.5.6
Resolve `NS`com
`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.6.6 (IP of www.bob.com)
Request to 156.6.6.6 (www.bob.com)
03/02/09 AmirHerzberg.com 30
Domain Names and IP Addresses IP packets contain source, dest IP addresses
32 bits, e.g. 128.33.44.223 Routers use IP Addresses
To deliver packets to their destinations Users use Domain Names, e.g. www.foo.edu Domain Names are hierarchical, and:
Meaningful: *.edu: university, www.*: web server Easier to manage, remember and use
DNS – Map domain names to IP addresses Fixed IP, current IP, best IP (e.g. proximity)
03/02/09 AmirHerzberg.com 31
DNS Caching 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)
03/02/09 AmirHerzberg.com 32
Reverse DNS `Reverse` DNS query: IP name How? PTR query to in-addr.arpa domain
E.g., rDNS 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:
Servers should have rDNS to domain name Use rDNS to identify (dial-in, DSL,…) clients
03/02/09 AmirHerzberg.com 33
DNS Messages DNS protocol: send request, receive reply Single format for requests & replies
AuthorityQuestionsHeader OtherAnswers
Number of answers
Number of questions
Number of other
Number of authority
FlagsID (16 bits)
Type of RR
Name
TTL in seconds
Value
Type of RR
Name
RR (Resource Record)
03/02/09 AmirHerzberg.com 34
DNS Security: Goals Authenticity
Owners should control mappings (name IP) DNS-Security: cryptographically-signed DNS RR
To ensure security against MITM attacker Although MITM attacker can forget IP addresses anyway See few extra foils after conclusions
Availability Prevent Denial of Service (DoS) attacks
Non-Goal: Confidentiality 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
03/02/09 AmirHerzberg.com 35
MITM via DNS Poisoning Allows blind attacker to become MITM
Web spoofing / phishing attacks Spoof blacklist responses,…
1. DNS request:bob.com
DNS server
Bob.com129.4.4.5
6.6.6.6
0. Poison: bob.com6.6.6.62. Response:
bob.com6.6.6.6
3. DstIP=6.6.6.6Dear Bob, …
03/02/09 AmirHerzberg.com 36
Poisoning by out-of-bailiwick glue RR Normally: RR is received to fulfill request 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!
03/02/09 AmirHerzberg.com
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 AmirHerzberg.com 38
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
Local server must choose ID randomly Same dest IP address and port as source in
request Chosen randomly; preferably: pool of IPs
Same IP address of responding DNS server Most domains have 2-3 likely-to-be-used servers
Response received within reasonable delay And ignore if already received valid response for this
query
03/02/09 AmirHerzberg.com 39
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 Or predictable ports, e.g. consecutively Or don’t confirm port etc. on responses Till Kaminsky’s attack, patch [2008] Many still do (30%?)
03/02/09 AmirHerzberg.com 40
Response Authentication for Blind Adv. Prevent spoofing of response by blind adversary
General technique – used by DNS (this lecture), TCP, …
Alice sends request with random nonceAlice
Referred to as challenge Explicit (e.g. DNS identifier, TCP ISN), implicit (port #, IP)
Bob reply with nonceAlice
Alice knows reply is fresh from Bob! Critical: random, sufficient-long challenges (nonces)
We’ll discuss relevant attacks on DNS (next), TCP (later)
03/02/09 AmirHerzberg.com 41
Kaminsky’s attack
1. Determine (small) set P of DNS requesting ports
Init: i=1
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.6.6
4. Test: query www.bob.com; is resulting IP 6.6.6.6?
i=i+1
No(failed)
Poisoning successful!!
Yes
03/02/09 AmirHerzberg.com 42
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 SpoofProb=DF/NPI
For small values of D. Birthday paradox: with SpoofProb>1/2 if D,F>SQR(NPI) Many local servers allow large D (for stateless design)
03/02/09 AmirHerzberg.com 43
Response must be in `window of opportunity` Could predict request by TTL
Attacker can learn since TTL sent to all clients But: relatively few `windows of opportunity'
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
RFC5321: limit # of DNS queries for each ext. connection
Request non-existing domain (never in cache!)
How to send responses in time?
03/02/09 AmirHerzberg.com 44
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
NAT can also ruin local DNS port randomization and more
How to beat authoritative DNS?
03/02/09 AmirHerzberg.com
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
Kaminsky’s attack, analysis DNS behind NAT attacks (skip refresh on NAT)
03/02/09 AmirHerzberg.com
IP Addresses / Ports and NAPT IP addresses identify (source, dest) host Ports identify (source, dest) process
A port is a 16-bit identifier At beginning of IP payload
Fixed server ports: 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 AmirHerzberg.com
NAPT/NAT: Network Address (Port) Translation
1. SrcIP=10.0.0.1SrcPort=3373DstPort=80
2. SrcIP=133.44.5.8SrcPort=6678DstPort=80
3. DstIP=133.44.5.8SrcPort=80DstPort=6678
4. DstIP=10.0.0.1SrcPort=80DstPort=3373
Goal: share IP addresses among multiple hostsHow: identify host by port
03/02/09 AmirHerzberg.com
NAT Port Assigning Methods NATs differ on how they allocate, free ports
Risks: port exhaustion; packets misrouting/loss When to free assigned port?
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:
If assigned ext-port x to internal (port, srcIP) to dstIP Then reassign x (if available) if (port, srcIP) sents to newdIP
Read: RFC 4787, NAT Behavioral Requirements
03/02/09 AmirHerzberg.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:
Random-port-assigning NAT – impossible? Sequential port assigning NAT - easy Cone NAT: possible Port-preserving NAT (when available)
03/02/09 AmirHerzberg.com 51
Attacks on local DNS behind NAT
Alice10.1.2.4
Eve6.6.6.6
Zombie10.1.2.3
Alice's LocalDNS server
10.2.3.4
NAT7.8.9.1
NS: (authoritative)Name Serverns.bob.com1.2.3.5
W: Bob's web sitewww.bob.com1.2.3.4
ns.bob 1.2.3.5
1025 xxx ns.bob 1.2.3.5
Adam10.3.2.3
ns.bob 1.2.3.5
Adam's LocalDNS server
10.3.3.4
03/02/09 AmirHerzberg.com
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 `breaks` port randomization
Advanced attacks also on Port-preserving NAT, Cone NAT (see paper)
03/02/09 AmirHerzberg.com 53
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 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
03/02/09 AmirHerzberg.com
Extra foils
DNS security
03/02/09 AmirHerzberg.com 55
DNS-Sec 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
03/02/09 AmirHerzberg.com 56
Secure DNS: Hierarchical Key Distribution DNS RRs contain mapping and signature
mapping= <foo.bar.com,123.45.6.7> Foo.bar.comRR=<mapping, Signbar.com.s(mapping)
Resolver needs bar.com.v (public key) How? From its own RR (bar.comRR):
bar.comMap= <bar.com,123.45.6.7> bar.comRR=< bar.comMap, bar.com.v,
Signcom.v(bar.comMap, bar.com.v) `Small` problem: need top level public keys Other problems:
Forces specific trust relationship How we know if bar.com has public key??
03/02/09 AmirHerzberg.com 57
Secure DNS: proof of no (signed) RR What if bar.com has no public key?
Does not yet support Secure DNS Can send unsigned RR… But: attacker may also send unsigned RR…
Even if bar.com does have public key! Proof of no (signed) RR, from bar.comRR? Proposal: bar.comRR=< bar.comMap,
Signcom.v(bar.comMap, “NO bar.com.v”) Problem: efficiency – need to sign *all* keys Worse – if we want to prevent replay !
03/02/09 AmirHerzberg.com 58
Secure DNS: proof of no (signed) RR What if bar.com has no public key?
Does not yet support Secure DNS Can send unsigned RR… But: attacker may also send unsigned RR…
Even if bar.com does have public key! Proof of no (signed) RR, from bar.comRR:
bar.comMap= <bar.com,123.45.6.7> bar.comRR=< bar.comMap, NoSign> NoSign=Signcom.v(ba.com,ba.com.v; bb.com,
bb.com.v, time)
03/02/09 AmirHerzberg.com 59
Secure DNS: Identity Exposure Query? Query to unsigned domain bar.com
Response: NoSign=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