Network Security: Introduction,
Adversaries and Poisoning
Amir Herzberg
http://AmirHerzberg.com
03/02/09
AmirHerzberg.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
AmirHerzberg.com
Adversaries and Poisoning: Outline





Introduction: Internet vs. Security ?
Adversary capabilities / models
Sniffing
ARP poisoning
DNS poisoning
03/02/09
AmirHerzberg.com
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
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

03/02/09
Computers are well protected and managed
securely
AmirHerzberg.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…
03/02/09
AmirHerzberg.com
6
Acute Threats and Attacks
Ads and
phishing
DoS
Spam
Denial of Service
(hate, compete, blackmail)
Malware
Virus, Trojan,
Worm, Spyware, …
03/02/09
Con-Sites
Fake (spoofed) sites,
Scam/fraud sites
Intrusion
AmirHerzberg.com
7
Threats are Related…
DoS
Spam
Malware
Con-Sites
Intrusion
03/02/09
AmirHerzberg.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

03/02/09
Threat: use of that machine to attack more machines
AmirHerzberg.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

03/02/09
E.g. long-range WiFi sniffing (war-driving) – easy!
AmirHerzberg.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
03/02/09
AmirHerzberg.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
03/02/09
AmirHerzberg.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
Yes; with or
without blocking
03/02/09
AmirHerzberg.com
14
Adversarial Model vs. Network Type
Switched
Internet
(routers)
Rare
Rare
Common
Rare (exc.
same seg.)
Rare
Spoofer /
Blind
Rare
Common
Common
Client only
Always
Always
Always
Network
Adversary
Shared
(private)
MITM (spoof, Rare
sniff, block)
Sniffer /
eavesdropper
(no spoof)
03/02/09
AmirHerzberg.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)

03/02/09
For internets too (connected by routers)
AmirHerzberg.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
AmirHerzberg.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

03/02/09
Used for address resolution (ARP)…
AmirHerzberg.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:7b:91:bd:6c
8:00
1.1.24.65
00:60:e1:00:9c:70
---
1.1.24.223
00:60:e1:00:07:91
8:03
03/02/09
AmirHerzberg.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
03/02/09
A
B
AmirHerzberg.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

03/02/09


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)
AmirHerzberg.com
22
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
Switch
Eve
Alice
Bob
03/02/09
AmirHerzberg.com
23
ARP Poisoning Methods

Unsolicited
 Send ARP request with false sender’s IP


Send ARP response with incorrect mapping



(some) hosts use to update their ARP tables
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

03/02/09
Improve chances by loading destination’s segment/host
AmirHerzberg.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!

03/02/09
May try DNS-Poisoning instead…
AmirHerzberg.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:
Gateway
Bob
03/02/09
DHCP Server
AmirHerzberg.com
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
AmirHerzberg.com
DNS Resolution Process
Client
Local
Server
Resolve `A`
www.bob.com
Root
Server
Resolve `NS`
com
.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.6.6 (IP of www.bob.com)
Request to 156.6.6.6 (www.bob.com)
03/02/09
AmirHerzberg.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

03/02/09
Fixed IP, current IP, best IP (e.g. proximity)
AmirHerzberg.com
30
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
31
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:


03/02/09
Servers should have rDNS to domain name
Use rDNS to identify (dial-in, DSL,…) clients
AmirHerzberg.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
03/02/09
Name
Type of RR
TTL in seconds
Value
RR (Resource Record)
AmirHerzberg.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 (DoS) attacks
Non-Goal: Confidentiality





03/02/09
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
AmirHerzberg.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. DstIP=6.6.6.6
Dear Bob, …
1. DNS request:
bob.com
2. Response:
bob.com6.6.6.6
0. Poison:
bob.com6.6.6.6
6.6.6.6
DNS server
03/02/09
AmirHerzberg.com
35
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
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
AmirHerzberg.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


Most domains have 2-3 likely-to-be-used servers
Response received within reasonable delay

03/02/09
Chosen randomly; preferably: pool of IPs
Same IP address of responding DNS server


Local server must choose ID randomly
And ignore if already received valid response for this
query
AmirHerzberg.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




03/02/09
Or predictable ports, e.g. consecutively
Or don’t confirm port etc. on responses
Till Kaminsky’s attack, patch [2008]
Many still do (30%?)
AmirHerzberg.com
39
Response Authentication for Blind Adv.

Prevent spoofing of response by blind adversary


Alice sends request with random nonceAlice





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 nonceAlice
Alice knows reply is fresh from Bob!
Critical: random, sufficient-long challenges (nonces)

03/02/09
We’ll discuss relevant attacks on DNS (next), TCP (later)
AmirHerzberg.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.6.6
4. Test: query www.bob.com; is
resulting IP 6.6.6.6?
Yes
i=i+1
No
(failed)
Poisoning successful!!
03/02/09
AmirHerzberg.com
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
SpoofProb=DF/NPI



03/02/09
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)
AmirHerzberg.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'
RFC5321: limit # of DNS queries for each ext. connection
Request non-existing domain (never in cache!)
03/02/09
AmirHerzberg.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
NAT can also ruin local DNS port
randomization and more
03/02/09
AmirHerzberg.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)
AmirHerzberg.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
AmirHerzberg.com
NAPT/NAT:
Network Address (Port) Translation
Goal: share IP addresses among multiple hosts
How: identify host by port
2. SrcIP=133.44.5.8
SrcPort=6678
DstPort=80
3. DstIP=133.44.5.8
SrcPort=80
DstPort=6678
03/02/09
AmirHerzberg.com
1. SrcIP=10.0.0.1
SrcPort=3373
DstPort=80
4. DstIP=10.0.0.1
SrcPort=80
DstPort=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, srcIP) to dstIP
Then reassign x (if available) if (port, srcIP) sents to newdIP
Read: RFC 4787, NAT Behavioral Requirements
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:




03/02/09
Random-port-assigning NAT – impossible?
Sequential port assigning NAT - easy
Cone NAT: possible
Port-preserving NAT (when available)
AmirHerzberg.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
Zombie
10.1.2.
3
Alice's Local
DNS server
10.2.3.4
Eve
6.6.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
03/02/09
AmirHerzberg.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)
AmirHerzberg.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




03/02/09
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
AmirHerzberg.com
53
Extra foils
DNS security
03/02/09
AmirHerzberg.com
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
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.comRR):




mapping= <foo.bar.com,123.45.6.7>
Foo.bar.comRR=<mapping, Signbar.com.s(mapping)
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:


03/02/09
Forces specific trust relationship
How we know if bar.com has public key??
AmirHerzberg.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.comRR?
Proposal: bar.comRR=< bar.comMap,
Signcom.v(bar.comMap, “NO bar.com.v”)


03/02/09
Problem: efficiency – need to sign *all* keys
Worse – if we want to prevent replay !
AmirHerzberg.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.comRR:



03/02/09
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)
AmirHerzberg.com
58
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
03/02/09
AmirHerzberg.com
59