03/02/09amirherzberg.com1 network security: introduction, adversaries and poisoning amir herzberg

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


Adversaries and Poisoning: Outline Introduction: Internet vs. Security ? Adversary capabilities / models Sniffing ARP poisoning DNS poisoning


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


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


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…


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


Threats are Related…

SpamSpam

MalwareMalware Con-SitesCon-Sites

DoSDoS

IntrusionIntrusion


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


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!


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


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


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


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


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)


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


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)…


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


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


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”


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


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


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…


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



Reminder: DNS (skip this) DNS security goals DNS poisoning by out-of-bailiwick glue RR DNS poisoning by spoofed responses


DNS Resolution Process

Resolve À`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 À` www.bob.com

`NS` ns.bob.com À` 156.4.5.6

Resolve À` www.bob.com

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

Request to 156.6.6.6 (www.bob.com)


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

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)


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


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, …


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!


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


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


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)


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


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)


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?


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?




Kaminsky’s attack, analysis DNS behind NAT attacks (skip refresh on NAT)


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


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


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


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)


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


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)


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


Extra foils

DNS security


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


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

03/02/09amirherzberg.com1 network security: introduction, adversaries and poisoning amir herzberg

Documents

security mitm

comnetwork security

network adaptersman

peersmany threats attacks

hardware sniffing

shared mediano hardware

shared mediaaccess

attackers external