Network Security: Introduction, Adversaries and Poisoning - PowerPoint PPT Presentation

About This Presentation
Title:

Network Security: Introduction, Adversaries and Poisoning

Description:

Title: Network Security: Introduction, Adversaries and DNS+ARP Poisoning Last modified by: Amir Herzberg Document presentation format: On-screen Show – PowerPoint PPT presentation

Number of Views:117
Avg rating:3.0/5.0
Slides: 56
Provided by: csMiamiE9
Learn more at: https://www.cs.miami.edu
Category:

less

Transcript and Presenter's Notes

Title: Network Security: Introduction, Adversaries and Poisoning


1
Network Security Introduction, Adversaries and
Poisoning
  • Amir Herzberg
  • http//AmirHerzberg.com

2
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

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

4
Internet and Security
  • Internet began as a US DoD project in the 1970s
  • Main concern was survivability to a physical
    (atomic) attack
  • Decentralized for survivability
  • Centralized design is simpler, and was already
    known (IBMs SNA)
  • Would not survive atomic bomb on center of Net
  • Hence distributed routing, directory, etc.
  • Connectivity and usability before security

5
Internet and Security Guidelines
  • Decentralized for survivability
  • Connectivity and usability before security
  • Accept from everybody, forward to everybody
  • This holds for Packets (IP), email, etc.
  • Does not validate packet/email source addresses
  • This allows spoofing, but also ensures
    survivability
  • Assumption attackers external to Network
  • Computers are well protected and managed securely

6
Today The Internet is Vulnerable
  • Internet is global, open, everybody online
  • Including the attackers!
  • Computers are unprotected, unmanaged
  • Insecure platforms (Windows, IE)
  • Naïve users
  • Many, untrusted clients and peers
  • Many threats / attacks

7
Acute 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
8
Threats are Related
DoS
Spam
Malware
Con-Sites
Intrusion
9
Private 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

10
Sniffing Requires Proximity
  • Sniffing
  • Eavesdropping to particular segment/net
  • Easy if adversary has access to shared media
  • No hardware Promiscuous mode
  • Listen to packets for all destinations
  • Available with most network adapters
  • Man In The Middle (MITM) attacker for shared
    media
  • Access to shared media
  • Wireless links (home, café, campus, corporate)
  • Or adv in same collision domain as
    sender/recipient
  • Same Ethernet cable or same hub
  • Or, hardware sniffing
  • E.g. long-range WiFi sniffing (war-driving)
    easy!

11
Switches and Traffic Isolation
  • Packets broadcasted inside segments
  • Traffic isolation forward only as needed
  • By learning the link addresses in each segment
  • Goals performance and security
  • MITM on specific segment, blind on others

Switch
Eve
Alice
Bob
12
Switched 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
13
Adversary 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

14
Adversarial Capabilities, Models
15
Adversarial 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
16
MITM in Spite of Switch?
  • Switch ? isolation ? blind attacker
  • How blind attacker becomes MITM?
  • Degradation attack many switches change to Hub
    behavior if MAC table too large
  • Poisoning Attacks
  • Achieve MITM capabilities by poisoning address
    resolution
  • IP address ?MAC address (ARP Poisoning)
  • Domain name ? IP address (DNS Poisoning)
  • For internets too (connected by routers)

17
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

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

19
Address Resolution Table
  • Each host maintains its own address resolution
    table
  • Each entry correlates between IP address and MAC
    address
  • In an entry there is a field that marks the way
    the entry was created (Static or Dynamic)
  • Example

IP Address
MAC Address
TTL
1.1.24.1
00307b91bd6c
800
1.1.24.65
0060e1009c70
---
1.1.24.223
0060e1000791
803
20
ARP 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)

21
ARP 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
22
ARP 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

23
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
24
ARP 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

25
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!
  • May try DNS-Poisoning instead

26
Port Security Mechanisms
  • Block unsolicited mappings
  • Disconnect port which attempts ARP poisoning
  • Allow only one MAC address per port
  • Limit rate of ARP requests/responses per port
  • Block ARP requests/responses conflicting with
    DHCP
  • Notice spoofing DHCP responses would allow
    similar attack prevent by allowing DHCP
    responses only from trusted port

Switch
Eve
Alice
IP MAC
Gateway
DHCP Server
Bob
27
Preventing 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

28
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

29
DNS 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)
30
Domain Names and IP Addresses
  • IP packets contain source, dest IP addresses
  • 32 bits, e.g. 128.33.44.223
  • Routers use IP Addresses
  • To deliver packets to their destinations
  • Users use Domain Names, e.g. www.foo.edu
  • Domain Names are hierarchical, and
  • Meaningful .edu university, www. web server
  • Easier to manage, remember and use
  • DNS Map domain names to IP addresses
  • Fixed IP, current IP, best IP (e.g. proximity)

31
DNS Caching
  • Caching is critical for DNS performance
  • All DNS modules perform caching
  • Client DNS Cache
  • Local DNS Server Cache
  • DNS server used only to cache records
  • Clients always access this server
  • May be nested ( ? DNS.foo.edu ? ISP DNS)
  • Caching is of DNS Resource Records (RR)

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

33
DNS Messages
  • DNS protocol send request, receive reply
  • Single format for requests replies

RR (Resource Record)
34
DNS Security Goals
  • Authenticity
  • Owners should control mappings (name ?IP)
  • DNS-Security cryptographically-signed DNS RR
  • To ensure security against MITM attacker
  • Although MITM attacker can forget IP addresses
    anyway
  • See few extra foils after conclusions
  • Availability
  • Prevent Denial of Service (DoS) attacks
  • Non-Goal Confidentiality
  • Protocol allows any server to query any other
  • Servers may restrict distribution
  • Encrypt records if needed (non-standard)
  • No support for hiding requests
  • Undesirable allowing whats there? query

35
MITM 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
36
Poisoning by out-of-bailiwick glue RR
  • Normally RR is received to fulfill request
  • Gratuitous RR received without request
  • In response to different request or appended to a
    DNS request
  • Use to send glue RR to help resolve referred-to
    NS
  • Query x.foo.co.il A ?
  • Authority foo.co.il NS ns.foo.com, foo.co.il NS
    dns.foo.co.il
  • Additional ns.foo.com A 1.2.3.4, dns.foo.co.il A
    5.6.7.8
  • These are glue RR providing IP for authority
    NS
  • Abuse poison RR for referred-to NA (ns.foo.com)
  • Since 1997 (most) servers accept (glue) RR only
    if in-bailiwick in domain of same name server
  • In above example accept only dns.foo.co.il A
    5.6.7.8
  • If spoofed attacker can poison every address of
    foo.co.il!

37
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

38
Poisoning by Spoofed Response
  • Would local server eat it?
  • RFC 5452 read! Local server must validate
  • Same question section as in request
  • Same (16-bit) ID field
  • Local server must choose ID randomly
  • Same dest IP address and port as source in
    request
  • Chosen randomly preferably pool of IPs
  • Same IP address of responding DNS server
  • Most domains have 2-3 likely-to-be-used servers
  • Response received within reasonable delay
  • And ignore if already received valid response for
    this query

39
Poisoning by Spoofed Response
  • RFC 5452 read! Local server must validate
  • Same question section as in request
  • Same (16-bit) ID field
  • Same dest IP address and port as source in
    request
  • Same IP address of responding DNS server
  • Response received within reasonable delay
  • All these 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?)

40
Response Authentication for Blind Adv.
  • Prevent spoofing of response by blind adversary
  • General technique used by DNS (this lecture),
    TCP,
  • Alice sends request with random nonceAlice
  • Referred to as challenge
  • Explicit (e.g. DNS identifier, TCP ISN), implicit
    (port , IP)
  • Bob reply with nonceAlice
  • Alice knows reply is fresh from Bob!
  • Critical random, sufficient-long challenges
    (nonces)
  • Well discuss relevant attacks on DNS (next), TCP
    (later)

41
Kaminskys 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!!
42
Spoofed 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)

43
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
  • 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!)

44
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

45
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
  • Kaminskys attack, analysis
  • DNS behind NAT attacks (skip refresh on NAT)

46
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

47
NAPT/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
48
NAPT 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
49
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

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

51
Attacks 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
52
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)

53
Conclusions
  • Internet designed to survive bombs, not virus
  • Many threats
  • Malware
  • Spam and Phishing
  • Fake (spoofed) and malicious servers
  • Intrusion via vulnerabilities
  • Reconnaissance/scan to find vulnerabilities
  • Denial of Service
  • Adversarial models
  • MITM - rarely (initially) available
  • Eavesdropper requires physical proximity
    (unusual)
  • Blind/spoofer common, many ISPs dont filter
    properly
  • Client most common domains and IP addrs are
    cheap

54
Extra foils
  • DNS security

55
DNS-Sec
  • DNS-Sec a proposed Internet standard
  • Goal improve DNS authentication
  • How?
  • Use cryptographic public-key signatures
  • Sign DNS mappings (signature in RR)
  • Use private key of authoritative DNS server
  • Signature in a separate DNS RR
  • Higher layer authoritative server signs servers
    public key
  • Not yet widely deployed

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

57
Secure DNS proof of no (signed) RR
  • What if bar.com has no public key?
  • Does not yet support Secure DNS
  • Can send unsigned RR
  • But attacker may also send unsigned RR
  • Even if bar.com does have public key!
  • Proof of no (signed) RR, from bar.comRR?
  • Proposal bar.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 !

58
Secure DNS proof of no (signed) RR
  • What if bar.com has no public key?
  • Does not yet support Secure DNS
  • Can send unsigned RR
  • But attacker may also send unsigned RR
  • Even if bar.com does have public key!
  • Proof of no (signed) RR, from bar.comRR
  • bar.comMap ltbar.com,123.45.6.7gt
  • bar.comRRlt bar.comMap, NoSigngt
  • NoSignSigncom.v(ba.com,ba.com.v bb.com,
    bb.com.v, time)

59
Secure 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
Write a Comment
User Comments (0)
About PowerShow.com