L1 Intro Models MITM

Network Security: Introduction,
Adversaries and Poisoning
Amir Herzberg
Bar Ilan University,
Dept. of Computer Science
03/02/09 AmirHerzberg.com 1
Administrative
Requirements: 50% exam, 50% assignments
Books:
The Tangled Web,
The web application hackers handbook,
Network security: Kaufman/Perlman or Stallings
Reception hours by appointment:
Amir Herzberg: Sunday 3pm
Related courses this term
Seminar 89-439 (Sunday 4pm)
Intro to cyber security 89-250 (Tuesday 4pm)
Ethics
We learn attack techniques and approaches
Some attacks, vulnerabilities still relevant
Methods, approach may allow you to attack
Please: dont. Put only to good use !!
Why? Ethics and sense, too: dont mess with
the Mob!
Dont even èxperiment without guidance
People got jailed for (innocent?) hacking
Like it? Many legitimate, good uses
Or at least legal
The Internet is Vulnerable
Internet is global, open, everybody online
Including the attackers!
Computers are unprotected, unmanaged
Insecure platforms (Windows, IE)
Nave users
Many, untrusted clients and peers
Protocols designed for friendly/secure
environment
Many threats / attacks
Network Security: Course Plan
Adversary models, sniffing, ARP-poisoning
Basic network security: scanning, filtering (FW), detecting (IDS)
Incl. malware: worms, viruses, Trojans, botnets
Denial of Service Attacks and Defenses
TCP/IP attacks: DoS, Fragmentation, Injection
DNS poisoning and security
Routing: attacks and defenses
Web attacks (XSS, injection, CSRF, ) and defenses (SOP, )
Email, phishing and spam
Privacy and anonymity: attacks and defenses
03/02/09 AmirHerzberg.com
Man-in-the-Middle (MitM) Attacker
Aka: on-path attacker
Can eavesdrop, inject, modify, block
Usually: both directions
How? Challenging WiFi/router/routing/DNS/ARP
Off-path Attacker
Aka: spoofing, blind

Spoofed sender address (sender: Alice)
Usually: to all parties
Many ISPs fail to ingress filter spoofing is easy
Eavesdropping Attacker
Usually to all parties, sometimes specific
Physical eavesdrop (Wireless, voice,)
Eavesdropping Attacker
Can eavesdrop, often also inject, modify, block
Usually to all parties, sometimes specific
Physical eavesdrop (Wireless, voice,)
Cross-Site Attacker
Main model for web attacks
666.net
Bob.org
Cannot: eavesdrop, inject, modify, block
Accessed by Alice (victim client, browser)
Rogue Client/Server Attacks
Rogue Client Attack 666.net
Examples: SQL injection, ping-of-death
Rogue Server Attack

Browser exploits, Phishing, Scams
Bob.org
Client Attacker
(Web) Attacks by clients on servers
666.net
Bob.org
Cannot: eavesdrop, inject, modify, block
Accessed by Alice (victim client, browser)
Network Adversary Capabilities
Adversary Eavesdrop Drop Inject Can Example
connect?
Eavesdropper Yes No No (if client) Wireless
(sniffing)
MitM Yes Yes Yes Yes Router, ISP
Off-Path No No Yes No ~ 25% of
(blind) clients
Client-only No No No Yes Other
clients
Puppet No No No To origin Javascript
Off-path attacks
ARP poisoning (etc.)
DNS poisoning
IP intercepting, blocking
TCP detecting, killing, injecting
NTP attacks and much more!
:
) :(Off-path Oscar
: , ,
? !
, !
, !
Alice Bob
" " ()Monster-in-the-Middle

, :
, !
, .
, .
MitM vs. Off-path Adversaries
Crypto is about Monster-in-the-Middle Adversary:
Bob, ILU! Alice Bob, I Leave U! Alice
Alice Bob
Folklore: most attackers are weaker, off-path, only inject
`Security is often against Off-Path Oscar
Bob, ILU! Alice
Bob, I Leave U! Alice
Alice Bob

( , ).... ,ingress filtering :
From: 2.2.25
((
To : 3.3.3.7
4.4.4

I leave U

6.6.6 1.1.1

3.3.3
2.2.2 5.5.5
Attacker Model: MitM or Off-Path?
Off-path attackers
Do not control devices en-route
Cannot intercept/modify/block traffic
Easier to prevent attacks: use challenge-response (`cookie`)
MitM attackers
Attacker has to be on path less feasible
Prevention requires crypto: overhead, complexity, PKI
Why bother?
Our thesis: off-path can often obtain MitM capabilities
Defend against MitM even when attacker off-path

) (Off-path
: , ,
Bob, ILU! Alice
Bob, I Leave U! Alice
Alice Bob 3.3.3.7

: .
, DNS :
?www.bob.com :
www.bob.com :3.3.3.7 :
Alice
6.6.6.6 :

) (Off-path
: , ,
Bob, I Love You! Alice
Bob, I Leave You! Alice
Alice Bob 3.3.3.7

: .
, :
12345 : ?www.bob.com :
www.bob.com : .3.3.3.7 :12345 :

Alice
?? 6.6.6.6 :
?
) :(Off-path Oscar
: , ,
() ,
?www.bob.com :12345 :
Alice www.bob.com :6.6.6.6 :

??
6.6.6.6 :
" " ( :)MitM , ,

?www.bob.com :12345 :
.6.6.6.6 :12345 :
Riddle:
Living Eyes Closed
Sniffing ??????
1. Ears open
2. Nose clean
3. WiFi on
4. Hub used
Sniffing is Easy (with Shared Media, Hub)
Sniffing
Eavesdropping to particular segment/net
Easy with access to shared media (hub, WiFi,)
No hardware: Promiscuous mode
Listen to packets for all destinations
Available with most network adapters
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!
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
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
Special case of using DoS for attack!!!
Poisoning Attacks:
Domain name IP address (DNS Poisoning)
Gateway/Resolver x.6.6.6. (DHCP Poisoning)
IP address MAC address (ARP Poisoning)
MAC address Port of switch (Port Poisoning)
MitM vs. Off-Path Hacking
Adversary models: MitM, off-path, others
Sniffing
Off-path attacks:
Quick refresh on ARP (skip this)
DNS poisoning I, II
DNS poisoning III
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
Used for address resolution (ARP)
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
ARP Mechanism
Broadcast Request: Sender IP, Sender MAC, Target IP
C learns As IP, MAC

A B C D B, D could also learn, but
usually dont (since they may
not send to A).
Unicast Response
A learns Cs IP, MAC

A B C D
ARP protocol (RFC 826)
A wants to send datagram A caches <IP,MAC> in
to B, knows Bs IP address. ARP table
B on same subnet but her soft state: throw if not
MAC addr not in As table used for some time

A broadcasts ARP query Plug-and-play
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)
ARP 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
ARP Poisoning Methods
Send ARP request with false senders IP
(some) hosts use to update their ARP tables
Send spoofed response
Using attackers MAC address
When?
Upon hearing / expecting request
Race with legitimate reply
Improve chances by loading destinations segment/host
Unsolicited: (some) hosts update their ARP table
even if they didnt make request
Preventing `MITM via ARP Poisoning`
Static address resolution tables (IP MAC)
Ignore unsolicitated mappings (in req, response)
Monitoring to detect ARP-poisoning packets, ports
Port security mechanisms in switch
Separate networks by routers, not switch!
May try DNS-Poisoning instead
Port Security Mechanisms
Detect then Disconnect
Allow only one MAC address per port
Allow only one IP per port or per MAC address
Limit rate of ARP requests/responses per port
Block ARP requests/responses conflicting with DHCP
Allow DHCP responses only from trusted port (also against
DHCP poisoning)
Switch
Eve
IP: MAC: Alice
Gateway
Bob DHCP Server
Off-path attacks:
DNS poisoning I
Quick refresh on DNS (skip this)
Out-of-Bailiwick Poisoning

Poisoning by spoofed response: Kaminsky
Defenses
DNS poisoning II (NAT)
DNS poisoning III (Frag)
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)
DNS Resolution Process
Client Local Root .com TLD Authoritative
Server Server Server bob.com
132.3.3.4 Server
Resolve À` 156.4.5.6
www.bob.com Resolve `NS`
com
Resolve À` www.bob.com
Resolve À` www.bob.com
À` 156.6.6.6 (IP of www.bob.com)
Request to 156.6.6.6 (www.bob.com)
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)
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
DNS Messages
DNS protocol: send request, receive reply
Single format for requests & replies
Header Questions Answers Authority Other
ID (16 Flags Name Name

bits) Type of RR
Number of Number of
Type of
questions answers RR TTL in seconds
Number of Number of
Value
authority other
RR (Resource Record)
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 `whats there?` query
MITM via DNS Poisoning
Allows blind attacker to become MITM
Web spoofing / phishing attacks
Bob.com
Spoof blacklist responses,
129.4.4.5
3. DstIP=6.6.6.6
Dear Bob,
1. DNS request:
bob.com
0. Poison:
bob.com6.6.6.6
2. Response:
bob.com6.6.6.6 6.6.6.6
DNS server
Gratuitous, glue RR in Responses
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
Client Resolver Root ns.com (auth server
132.3.3.4 for TLD .com)
Resolve A
Resolve A www.bob.com Redirect
www.bob.com (iterative)
(recursive)
com NS ns.com
ns.com A 132.3.3.4 Glue RR
Redirect
Resolve A www.bob.com Glue RR
bob.com NS ns.bob.com, ns.bob.com A 156.4.5.6
Glue RR (cont)
Resolver sends request to auth server
E.g., to ns.com (auth for TLD .com)
Auth Server (e.g. TLD) usually responds with:
One or more NS records, e.g. ns.bob.com
Glue records for them, e.g. ns.bob.com A 156.4.5.6
Client Resolver Root ns.com (auth server
132.3.3.4 for TLD .com)
Resolve A
Resolve A www.bob.com Redirect
www.bob.com (iterative)
(recursive)
com NS ns.com
ns.com A 132.3.3.4 Glue RR
Redirect
Resolve A www.bob.com Glue RR
bob.com NS ns.bob.com, ns.bob.com A 156.4.5.6
Out-of-Bailiwick Glue RR
Suppose bob.com has two name servers:
ns.bob.com at 1.2.3.4 (in US)
ns.bob.co.il at 5.6.7.8 (in Israel)
For efficiency, ns.com may send both:
bob.com NS ns.bob.co.il and bob.com NS ns.bob.com
Glue records for: ns.bob.com A 1.2.3.4, ns.bob.co.il A 5.6.7.8
Ns.bob.ac.il is out-of-bailiwick for ns.bob !!!
Receiving it from ns.com (.com name server) may save time, queries
Abuse: poison RR for referred-to NA (ns.foo.com)
ns.eve.com returns ns.bank.com A 6.6.6.6
Since ~1997: (most) servers accept (glue) RR only if in-

bailiwick: in domain of authoritative name server
E.g., ignore ns.bank.com A 6.6.6.6 from ns.Eve.com !
Off-path attacks:
DNS poisoning I

DNS Poisoning by Spoofed Response
ATTACKER
6.6.6.6
Packet with source

IP: 156.4.5.6
www.bob.com www.bob.com A 6.6.6.6

A 6.6.6.6
6.6.6.6
ATTACKER
6.6.6.6
But, not so easy

The 16 bit
www.bob.com www.bob.com A 6.6.6.6
transaction identifier (TXID) is
A 6.6.6.6
supposed to prevent this!
6.6.6.6
The bad guy can try to guess the TXID value
Or brute-force: send many responses each with a
different TXID value
But, must win the race condition:
It is a race between who can reply with correct TXID
first
First correct response is accepted and cached
For TTL time (minute, hour, day,)
TTL is the duration of validity of a given mapping
Subsequent responses are ignored
Poisoning by Spoofed Response
Idea: send spoofed response to query
Challenges:
16 bit identifier field (TXID)
`Window of opportunity`:
Arrive while waiting for response (up to RTT)
Requests sent only once per TTL
Mostly considered impractical
Attacks showing non-random identifier
Until Kaminskys 2008 Blackhat presentation
And soon again, after `Kaminskys patch`
Kaminskys Observation:
The bad guy does not have to wait to repeat the
attack
ask for: 1.bank.com, 2.bank.com,
Each query is different , so each triggers a request
TTL prevents repeated requests for same query
Since each query is different, each triggers a
request
Eventually the attacker hits the TXID for
i.bank.com and poisoning succeeds
But, what is poisoned?
Using Kaminskys Observation
Option 1: 123.bank.com is at 6.6.6.6
Not very useful
Option 2: go ask ns.bank.com, it is at 6.6.6.6
ns.bank.com is the name server of bank.com
If resolver caches ns.bank.com at 6.6.6.6 attacker
hijacks entire domain of bank.com
Main idea of Kaminskys attack (2008)
BlackHat 2008: Kaminskys Attack
1st idea: cause request - to random, non-
existent domain!
How? Open resolver / link in page / mail /
2nd idea: poison by NS or glue records!
Resolver sends `regular query, to
<rnd>.victim.com
Attacker sends spoofed responses, redirecting:
victim.com NS eve.com OR ns.victim.org A
6.6.6.6
3rd idea: D duplicate requests Birthday

paradox
BlackHat 2008: Kaminskys Attack
1st idea: cause request to non-existent domain!
How? Many ways:
Attacker may be a user of the resolver (e.g. virus)
Many open resolvers - anybody can make query
Script or simply link (e.g. <IMG>) in site visited by user of
resolver
Email received by mail server using resolver (more later)
2nd idea: D duplicate requests (same domain)
Match btw any response and any request (ID+port)
Birthday paradox: probability
But why poison response to non-existing domain??
3rd idea: poison by NS or glue records!
See preceding foil
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
But: relatively few `windows of opportunity'
Can cause request:
From attacker-controlled machine (zombie), or
Recursive DNS resolution (so 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 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
Kaminskys DNS Poisoning [Black-Hat08]
[not here: `birthday paradox` improvement]
Resolver Eve ns.V.com
Step Alice 5.5.5.5 6.6.6.6 1.2.34
A?$1.bob.com
1
A?$1.bob.com, ID=i
2
Id=1, bob.com 6.6.6.6

Id=2, bob.com 6.6.6.6

Id=65536, bob.com 6.6.6.6
3
A?www.bob.com
4
bob.com 6.6.6.6
5
Step Alice 5.5.5.5 6.6.6.6 1.2.34
1
Kaminskys
Attack
[Black-
2
-Hat08]
with 3
birthday 4
5 ignored
Defenses against Kaminskys Attack
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
Antidotes for DNS Poisoning
Long-term defense: DNSSEC [RFC4035]
Cryptographic signatures - against MitM
Changes to resolver and name-server
Not widely deployed
Short-term, entropy increasing defenses:

Unilateral (in resolver), security against spoofers via
increased entropy in DNS packets
Supported by most resolvers
Randomise: Source port, src/dst IP, DNS query
Query derandomisation in [HS2012]
Source Port Randomization
Main anti-poisoning defense
Send requests from random/unpredictable ports
[Bernstein2002, RFC5452]
Port field - 16 bits
Increases the search space ~ 232
But, many resolvers are behind NAT devices

Security depends on port assignment of the NAT
Trivial: predictable allocation vulnerable (e.g., seq.)
Attacks possible on many NATs, allocation methods
Resolver behind NAT
Source Port Randomisation
How resolver, NAT select ports?
Goal: unpredictably
Few methods; today: per-dest incrementing (Linux)
Initial port is random; can attacker predict port?
Source Port deRandomisation
Zombie sends UDP packet
to DNS server
Hole in NAT
Spoofer sends 216 packets each
containing dest port
One gets through to
zombie
Zombie replays it to
spoofer
Spoofer sends 216 fake DNS
responses, for each ID
Response with correct
ID is accepted and
cached
Source Port deRandomisation
Zombie sends UDP packet
to DNS server 2307
Hole in NAT
Spoofer sends 216 packets each
containing dest port
One gets through to
zombie
Zombie replays it to
spoofer
Spoofer sends 216 fake DNS
responses, for each ID
Response with correct
ID is accepted and
cached
Off-path attacks:
DNS poisoning I

Defenses
IP Fragmentation
Nets have limit on max packet size (MTU)
If the packet is larger than MTU: fragment it!
Reassemble at the receiver
Net
Net Net 3.3.3
2.2.2 5.5.5
From: 2.2.2.5
To : 3.3.3.7
Bob, how much Bob, how
From: 2.2.2.5
To : 3.3.3.7 I... much I
Bob, how much I love you
From: 2.2.2.5
love you To : 3.3.3.7
...love you!
MTU=1500
MTU=1200
Fragment Reassembly
Bob receives fragments of a packet
How to reassemble without introducing mistakes
Identify fragments of the same packet
By sender/receiver addresses and protocol (TCP/UDP)
Not enough, add 16 bit, IP-ID
Net
Net Net 3.3.3
2.2.2 5.5.5
Bob, how 34 34 love you Bob how
Bob, how much I much I Bob,
much how
I
love you!! 34 much
need I
love you
a fridge
Ive decided I Ive 35 35 Need a
dont need a decided I
dont fridge
fridge 35
Internet Protocol Identifier (IP-ID)
Recipient identifies fragments of the same IP
packet by sender/receiver IP, protocol and IP-ID
[RFC 1349]
IP-ID is 16 bits (165536)
Typically, globally incrementing or per-
destination
Windows: globally incrementing
Linux: per-destination
Sometimes, IP-ID Exposing Is Easy!
Allowing even to replace 2nd fragment! [fix
checksum?]
For globally-sequential IP-ID senders
Observe any packet from the sender
For per-dest-seq IP-ID, with zombie behind NAT
also intercept fragments!
10.0.6.66
1.2.3.4
10.0.6.78
Oscar Omar
Oscar
Globally-sequential IP-ID Per-dest-sequential IP-ID

Intercepting (by replacing 2nd frag)
SrcIP=Alice, DstIP=NAT,
ID=i+1, Offset=1480, MF=0
A. Src-IP=Alice, Dst-IP=NAT,
ID=i+1, Offset=0, MF=1, Dst-port: Bobs
discarded
B. SrcIP=Alice, DstIP=NAT,
ID=i+1, Offset=1480, MF=0
cached
SrcIP=Alice, DstIP=NAT, ID=i+1,
Offset=0, MF=1, Dst-port: Zombies, No chksum
mis-associated
with Alice frag. B
Defrag &
forward to Zombie
Fragment Interception: Results
Results for IP tables based NAT
Attacking per-destination IP-IDs?
Globally-sequential IP-IDs are common:
Windows, default of FreeBSD, more
Most others (Linux) use per-dest IP-IDs
What then?
Easy: if there is NAT (shown before)
Or, side-channel attacks:
Fragmentation in tunnel
Fragmentation of DNS responses <<<
Off-path attacks:
DNS poisoning I

Defenses
DNS Response Blocking
Step 5.5.5.5 6.6.6.6 1.2.34
ns.org A 6.6.6.6
Resolver avoids
A?$1.org
querying
non-responsive $1.org
name
servers
Discard
response, e.g.,
due to incorrect
checksum, mark
name server as
non-responsive
Challenge: Guessing IP-ID
Typically can be guessed accurately
Global: sample and predict
E.g., see IP-ID increments of one of ORGs name servers
Per-destination: use side channel to find current

value
i.e., first response that times-out
Use `submarines` for better efficiency
Off-Path Discarding and Modifying
Off-path can discard fragments!!
What about modifying?
Exploit fragmentation for poisoning!
In reality fragmentation is rare (<1%)
But, off-path can cause fragmentation!!
Trigger requests whose responses fragment
E.g., DNSSEC protected
Attacker registered domain
Modify Long (DNSSEC) Responses
Poisoning DNSKEY Response
Modify Long Malicious Responses
Attacker creates a subdomain and uses it to
poison other domains
One-Domain-to-Rule-them-All.org
To cause fragmentation:
Register many name servers
Each with long names
Off-path attacks:
DNS poisoning I

Defenses
DNS poisoning III (Frag) Added: DNSSEC
DNSSEC
We saw two problems with challenge-response
Incorrect randmisation
Wrong attacker modelling
Conclusion: non-cryptographic antidotes do not
prevent poisoning
Cryptographic antidotes to poisoning?
DNSSEC (rfc4033,4034,4035): digital signatures over
DNS records
Secure even against MitM attackers
But not sufficiently deployed
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 servers public key
Not yet widely deployed

Public Key Digital Signatures
Sign using a private, secret signature key
Everybody knows the public validation key
Everybody can validate signatures at any time
Provides non-repudiation signer is committed
m
+
m +
SignA.s(m)
Alice Bob
Secret signature Alices public signature
key A.s validation key A.v
Verify using A.v that

is Alices signature on m

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??

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 !

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)
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
Solution: NSEC3 use hashes, not names

DNSSEC: Status
DNSSEC was proposed in 1997, yet still not
widely deployed/supported
Root + (25% of) TLDs are currently signed
82% of the signed domains are islands
Not supported by stub-resolvers
Challenge: DNSSEC failures: interoperability, and
intentional DNS response modification (mainly NX)
Third of resolvers appear to support
DNSSEC
But, only 1% enforce validation
Off-path attacks:
DNS poisoning I

Defenses
TCP Injections: Evolution
Predictable ISNs:
Morris85, Bellovin89, Mitnick95, Zalewski01,05
Address-based client authentication vulnerable
`TCP was not designed to be secure
`PoC` for Windows clients: klm07
2012:
QianMao: `mal-app + no-NAT + seq#-checking-fw
QMXie: faster and w/o FW assumption
GiladH: puppet-only, assume windows
Globally-sequential ports and IP-ID allocation
2013: GiladH: use browser `feature`
Attack Goal and Scenario
1. Alice surfs to Oscars site
2. Alices browser runs Oscars script (puppet)
3. Puppet sends requests to Bob
4. Attacker injects into connection
E.g., sends script to Alice, spoofing as Bob
3. Script opens (hidden) frame of Bob.com
Internet
1. Surf to
Oscar.com
4. Inject (e.g., script)
as content from Bob
2. Send page
With script
TCP Injections: Overview
Learn connection identifiers (IPs:ports)
Learn servers sequence number
Learn clients sequence number
Exploit(s):
XSS
CSRF
Phishing
Persistent (cached) XSS and defacement
[Defenses and conclusions]
Learning connection identifiers
Identifiers: <srcIP:srcPort, dstIP:dstPort>
Puppet opens connection to Bob (server)
ServerIP:port selected by puppet (attacker)
Client IP: known from client connection to Oscar
Client port: sequentially assigned [Windows,]
Not sequential? Or via NAT?

Learning client port: non-seq, w FW
Learning client port for per-dest ports
RFC 6056 recommends ùnpredictable`
choice of client ports, with five algorithms
Linux (and ?) implement: SHPS
SHPS= Simple Hash-based Port Selection
In Android, most NATs, many servers
Choose initial port (pseudo) randomly for
each destination
Increment by one for each new connection
Learning client port for per-dest ports
Learning port: Meet-in-Middle Optimi.
Finding Server SEQuence Number
How? Use TCP responses to probe packets
Empty-ack packets provide useful response:
If SEQ out of WIN: send ACK (to re-sync)
If SEQ is within WIN: no response (to avoid `storm)
How to detect if response is sent?
Use IP-ID side channel!
IP-ID: 16 bit identifier in IP header
Used to correctly reconstruct packet from fragments
In Windows: globally- incrementing counter
One connection (to attacker) leaks info about another!
Old trick: NMAPs idle-scan, Bellovin machine-count,

Finding Server SEQuence Number (1)
1. Puppet opens connection to server
2. Oscar sends query-probe-query:
1. Query: unordered 1-byte packets ACK (ipid)
2. Probe (srcIP:server): empty-Ack with SEQ=iw
w is estimate of WIN size
Found binary search finds exact SEQ !!
Can we find server seq# without IP-ID side
channel? [e.g., Linux]
Solution: use permissive browsers
What do browser do, when response isnt
properly formatted?
Most: render it as a `text response`
Idea:
Send fake responses, one will fall into window
When reached, browser will render
Response will give seq# in plaintext to attacker
Attack and Talk Overview
Puppet opens connection to server
Known IPs and server port
Learn connection identifiers (client port)
Exploit(s):
XSS
CSRF
Phishing
Finding Client SEQuence Number
We already know server seq (and IPs, ports)
To find client seq#: send pkt w/ data
With servers IP:port, correct seq#
TCPs handling depends on Ack#:
For Windows clients: Windows:
As of XP SP2 silently discard
RFC: Process
Silently discards pkt (often, ack) UnAcked
with òld` ack number Process
Otherwise: send ACK Next
Discard and send
Leaks: Ack#>UNA duplicate Ack
Binary search
TCP Injection: Challenges
Firewall passing: Ok
Lost probes: double-check `no-ack` events
Lost query/answer: detect via TCPs Acks
Irrelevant packet sent (IP-ID incremented):
repeat `suspect tests
Not too many extra checks (or failures)
When in doubt, read the paper!
Results
TCP Injection: Success Rates
Scenario:
Apache server, Windows clients, 10Mbps
Attacker: 1Mbps; RTT to client: 100msec
Avg. time: 102sec [std deviation: 18sec]
Attack and Talk Overview
Puppet opens connection to server
Known IPs and server port
Learn connection identifiers (client port)
Exploit(s):
XSS
CSRF
Phishing
Exploiting Injections: XSS, CSRF
Cross Site Scripting (XSS): cause browser to
run MalScript in context of victim.com
Known XSS: exploit bug in site or browser
Off-path-injected XSS: no need for vulnerable
site/browser!
Can post fake requests like CSRF, but
Circumvents: SOP, origin header, CSP, referrer
XSS Exploit: Results
Top 1024 sites, 10Mb win clients, 1Mb Oscar
Avg 32 pkts/s `noise`
Immune sites: mostly SSL or non-persistent
Phishing by Injection
Off-path XSS, CSRF may fail:
To collect user-entered data, e.g., passwords
Esp. if site uses SSL for passwords
Alternative: phish / deface !
Change contents: steal PWDs, push malware
Phishing by Injection
Off-path XSS, CSRF may fail:
To collect user-entered data, e.g., passwords
Esp. if site uses SSL for passwords
Alternative: phish / deface !
Change contents: steal PWDs, push malware
Spoof page only when user asks for it
Puppet maintains open connection
Detect user requesting victim page
By detecting increase in client-seq-number
`Kill` real response from server
Send data with servers SEQ in advance
Defenses and Conclusions
Defenses
Client: Use unpredictable IP-ID, ports
Not random see paper for details
Server / FW: drop connections with too many
suspect (empty) Acks
Conclusions
TCP may not be secure against off-path !
SOP is not much better than client address auth!
Use `real security: SSL/TLS, IPsec, etc.
Attacks may be improved, abused further
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 dont filter properly
Client most common; domains and IP addrs are cheap

L1 Intro Models MITM

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

L1 Intro Models MITM

Hochgeladen von

Copyright:

Verfügbare Formate

Network Security: Introduction,

Adversaries and Poisoning

Can eavesdrop, inject, modify, block

Usually: both directions

How? Challenging WiFi/router/routing/DNS/ARP

Can eavesdrop, inject, modify, block

Usually: to all parties

Many ISPs fail to ingress filter spoofing is easy

Can eavesdrop, inject, modify, block

Usually to all parties, sometimes specific

Physical eavesdrop (Wireless, voice,)

Can eavesdrop, often also inject, modify, block

Usually to all parties, sometimes specific

Physical eavesdrop (Wireless, voice,)

Cannot: eavesdrop, inject, modify, block

Accessed by Alice (victim client, browser)

Rogue Server Attack

Cannot: eavesdrop, inject, modify, block

Accessed by Alice (victim client, browser)

" " ()Monster-in-the-Middle

Bob, I Leave U! Alice

Bob, I Leave U! Alice

Alice Bob 3.3.3.7

Bob, I Leave You! Alice

Alice Bob 3.3.3.7

www.bob.com : .3.3.3.7 :12345 :

Alice www.bob.com :6.6.6.6 :

" " ( :)MitM , ,

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

C learns As IP, MAC

A learns Cs IP, MAC

MAC addr not in As table used for some time

Resolve `A` www.bob.com

Resolve `A` www.bob.com

`A` 156.6.6.6 (IP of www.bob.com)

Request to 156.6.6.6 (www.bob.com)

ID (16 Flags Name Name

Since ~1997: (most) servers accept (glue) RR only if in-

Packet with source

www.bob.com www.bob.com A 6.6.6.6

But, not so easy

3rd idea: D duplicate requests Birthday

Recursive DNS resolution (so don't allow!), or

Link from webpage or script (visited by user), or

Request for MX or other email-initiated domains

Id=1, bob.com 6.6.6.6

Short-term, entropy increasing defenses:

But, many resolvers are behind NAT devices

Globally-sequential IP-ID Per-dest-sequential IP-ID

Per-destination: use side channel to find current

03/02/09 AmirHerzberg.com 107

Verify using A.v that

03/02/09 AmirHerzberg.com 108

03/02/09 AmirHerzberg.com 109

03/02/09 AmirHerzberg.com 110

03/02/09 AmirHerzberg.com 112

Not sequential? Or via NAT?

Old trick: NMAPs idle-scan, Bellovin machine-count,

03/02/09 AmirHerzberg.com 140

Das könnte Ihnen auch gefallen