Title: Network Security: Introduction, Adversaries and Poisoning
1Network Security Introduction, Adversaries and
Poisoning
- Amir Herzberg
- http//AmirHerzberg.com
2Network 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
3Adversaries and Poisoning Outline
- Introduction Internet vs. Security ?
- Adversary capabilities / models
- Sniffing
- ARP poisoning
- DNS poisoning
4Internet 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 (IBMs SNA) - Would not survive atomic bomb on center of Net
- Hence distributed routing, directory, etc.
- Connectivity and usability before security
5Internet 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
6Today 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
7Acute Threats and Attacks
Ads and phishing
DoS
Spam
Denial of Service(hate, compete, blackmail)
Malware
Con-Sites
Fake (spoofed) sites, Scam/fraud sites
Virus, Trojan, Worm, Spyware,
Intrusion
8Threats are Related
DoS
Spam
Malware
Con-Sites
Intrusion
9Private Network Threats
- Pre-Internet Private Networks
- All processors belong to corporation ? trusted
- Attackers
- Remote client (guess password, control
systemmovies?) - Eavesdropper (sniffer) in proximity of wiring
- Insider (controls machine) main threat to
private network - Threat use of that machine to attack more
machines
10Sniffing 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!
11Switches 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
12Switched Networks and Blind Attackers
- Consider network connected by switches/routers
- Easy Blind Adversary only inject, cant
eavesdrop - Send packet with false IP (and/or MAC) address
- Harder, rare Man In The Middle (MITM) Adversary
- Also receive packets sent to victims IP/MAC
address
Eve
Alice
Bob
13Adversary Capabilities / Models
- Corruptions (of processors / parties)
- Internal vs. External Adversary
- Limits on internal (how many or which)
- In internet adversary has machine, addresses
- Internal adv specific machine / network
- Link/network adversary models
- Man In The Middle (MITM) inject, modify, listen
- Eavesdropping/passive adversary listen only
- Blind/spoofing adversary inject only
14Adversarial Capabilities, Models
15Adversarial Model vs. Network Type
Shared(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
Network
Adversary
16MITM 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)
17Adversaries 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
18Addresses 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
- Used for address resolution (ARP)
19Address 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
00307b91bd6c
800
1.1.24.65
0060e1009c70
---
1.1.24.223
0060e1000791
803
20ARP Address Resolution Protocol
- Each IP node (Host, Router) on LAN has ARP table
- ARP Table IP/MAC address mappings for some LAN
nodes - lt IP address MAC address TTLgt
- TTL (Time To Live) time after which address
mapping will be forgotten (typically 20 min)
21ARP Mechanism
Broadcast Request Sender IP, Sender MAC, Target
IP
C learns As IP, MAC B, D could also learn,
butusually dont (since they maynot send to A).
A
B
C
D
Unicast Response
A learns Cs IP, MAC
A
B
C
D
22ARP protocol (RFC 826)
- A wants to send datagram to B, knows Bs IP
address. - B on same subnet but her MAC addr not in As
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 As MAC address (unicast)
- A caches ltIP,MACgt in ARP table
- soft state throw if not used for some time
- Plug-and-play
23ARP Poisoning Attack
- Attackers are often on isolated segments
- How to intercept traffic from Alice to Bob?
- Trick Alice into sending to Eves MAC address
- ARP poisoning attack
- Alice uses ARP broadcast to find Bob
- Eve answers? Alice uses Eves Link address
- Eve can forward to Bob ?becomes MITM
Switch
Eve
Alice
Bob
24ARP Poisoning Methods
- Unsolicited
- Send ARP request with false senders 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 didnt make request - Solution ignore unsolicitated mappings
- Response to ARP request
- Mapping to attackers MAC address
- Send upon hearing / expecting request
- Race with legitimate reply
- Improve chances by loading destinations
segment/host
25Preventing 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!
- May try DNS-Poisoning instead
26Port 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
Gateway
DHCP Server
Bob
27Preventing MITM via ARP Poisoning
- Static address resolution tables (IP?MAC)
- Ignore unsolicitated mappings in responses,
requests - Requires change in every host ?
- 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 - Notice spoofing DHCP responses would allow
similar attack prevent by allowing DHCP
responses only from trusted port - Work best in switched LANs (no hubs/shared
segments) - Separate networks by routers, not switch!
- Cant ARP-Poison from separate subnet
- May try DNS-Poisoning instead
28Adversaries 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
29DNS Resolution Process
Root Server
.com TLD Server 132.3.3.4
Authoritative ns.bob.com Server 156.4.5.6
Client
Local Server
Resolve A www.bob.com
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)
30Domain 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)
31DNS 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)
32Reverse DNS
- Reverse DNS query IP ? name
- How? PTR query to in-addr.arpa domain
- E.g., rDNS for IP1.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
33DNS Messages
- DNS protocol send request, receive reply
- Single format for requests replies
RR (Resource Record)
34DNS 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 whats there? query
35MITM via DNS Poisoning
- Allows blind attacker to become MITM
- Web spoofing / phishing attacks
- Spoof blacklist responses,
Bob.com 129.4.4.5
3. DstIP6.6.6.6 Dear Bob,
1. DNS requestbob.com
0. Poison bob.com?6.6.6.6
2. Response bob.com?6.6.6.6
6.6.6.6
DNS server
36Poisoning 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!
37Adversaries 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
38Poisoning 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
39Poisoning 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 wont help if attacker can eavesdrop
(or MITM) notes - Reality most servers used fixed source port
- Or predictable ports, e.g. consecutively
- Or dont confirm port etc. on responses
- Till Kaminskys attack, patch 2008
- Many still do (30?)
40Response 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) - Well discuss relevant attacks on DNS (next), TCP
(later)
41Kaminskys attack
Init i1
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.6.6
4. Test query www.bob.com is resulting IP
6.6.6.6?
ii1
No(failed)
Yes
Poisoning successful!!
42Spoofed response poisoning analysis
- I number of distinct IDs (max. 65536)
- P number of ports (max 65536-102464512)
- 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
- SpoofProbDF/NPI
- For small values of D.
- Birthday paradox with SpoofProbgt1/2 if
D,FgtSQR(NPI) - Many local servers allow large D (for stateless
design)
43How 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
- 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!)
44How 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
- NAT can also ruin local DNS port randomization
and more
45Adversaries 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
- Kaminskys attack, analysis
- DNS behind NAT attacks (skip refresh on NAT)
46IP 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
47NAPT/NAT Network Address (Port) Translation
Goal share IP addresses among multiple
hosts How identify host by port
1. SrcIP10.0.0.1 SrcPort3373 DstPort80
2. SrcIP133.44.5.8 SrcPort6678 DstPort80
4. DstIP10.0.0.1 SrcPort80 DstPort3373
3. DstIP133.44.5.8 SrcPort80 DstPort6678
48NAPT Network Address/Port Translation
NAT translation table WAN side addr LAN
side addr
138.76.29.7, 5001 10.0.0.1, 3345
10.0.0.1
10.0.0.4
10.0.0.2
138.76.29.7
10.0.0.3
4 NAT router changes datagram dest addr
from 138.76.29.7, 5001 to 10.0.0.1, 3345
3 Reply arrives dest. address 138.76.29.7,
5001
49NAT 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
50NAT 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)
51Attacks on local DNS behind NAT
1025 xxx
ns.bob 1.2.3.5
NS (authoritative)Name Server ns.bob.com1.2.3.5
NAT7.8.9.1
Adam10.3.2.3
W Bob's web sitewww.bob.com1.2.3.4
Eve 6.6.6.6
Zombie10.1.2.3
Alice's LocalDNS server10.2.3.4
Adam's LocalDNS server10.3.3.4
ns.bob 1.2.3.5
Alice10.1.2.4
ns.bob 1.2.3.5
52Attack 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)
53Conclusions
- 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 dont filter
properly - Client most common domains and IP addrs are
cheap
54Extra foils
55DNS-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 servers
public key - Not yet widely deployed
56Secure DNS Hierarchical Key Distribution
- DNS RRs contain mapping and signature
- mapping ltfoo.bar.com,123.45.6.7gt
- Foo.bar.comRRltmapping, Signbar.com.s(mapping)
- Resolver needs bar.com.v (public key)
- How? From its own RR (bar.comRR)
- bar.comMap ltbar.com,123.45.6.7gt
- bar.comRRlt 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??
57Secure 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.comRRlt bar.comMap,
Signcom.v(bar.comMap, NO bar.com.v) - Problem efficiency need to sign all keys
- Worse if we want to prevent replay !
58Secure 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 ltbar.com,123.45.6.7gt
- bar.comRRlt bar.comMap, NoSigngt
- NoSignSigncom.v(ba.com,ba.com.v bb.com,
bb.com.v, time)
59Secure DNS Identity Exposure Query?
- Query to unsigned domain bar.com
- Response NoSignSigncom.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