0
DNS Security for CERTs
- Attack Scenarios & Demonstrations –
           Cache Poisoning


              Chris Evans
      ...
What You Will Need for the Exercise

• Your Ubuntu VM
   – VMWare Web Console Access
   – SSH with X11 Forwarding (for Adv...
Description

• A Change in Recursive DNS Server Causes Spoofed or
  Incorrect Resolutions
   – Attack Doesn’t Target Regis...
Description

• Cache poisoning attacks target a specific DNS server, and
  therefore, only the users which use that DNS se...
Case Study – External Poisoning

• Unverified report of a Brazilian
  bank victimized by cache
  poisoning attack.
• Attac...
Case Study – External Poisoning

• Hackers poisoned local ISP DNS server and
  redirected users to a login page that looke...
Case Study – Internal Poisoning

 • Partido Colorado – political statement made by one
   organization against another dur...
Case Study – Internal Poisoning

 • The local ISP (Copaco) modified its own recursive name
   servers to redirect users lo...
Attack Demonstration
                                   External Poisoning


              DNS Cache                  Web ...
Demonstration – Attacker View
                                  _       _
               _                 | |     (_)_
  ...
Demonstration – Attacker View (cont.)


[*]   Targeting nameserver 192.168.80.10 for injection of www.tld1. as 192.168.85....
Demonstration – Server View

• Wireshark Capture
  – Note the queries like “031PtyJamG6o.tld1”




                       ...
Demonstration – User View

• Please open a browser and connect to the webmail
  server: http://192.168.101.50/squirrelmail...
Demonstration – User View

        1

                            3

2
                                 May look legit
   ...
Impact

• Users are dependent on the answers from the DNS
  being accurate and legitimate

• Cache Poisoning can be used t...
Mitigation & Response Strategies

• DNSSEC – will mitigate effect of external poisoning
  attacks, but will not address co...
Mitigation & Response Strategies

• Know WHO to contact at the ISPs within your span
  of control
• Know the procedures fo...
Questions?




             ?
                 18
Upcoming SlideShare
Loading in...5
×

Day 2 Dns Cert 4a Cache Poisoning

889

Published on

Presentation by ICANN

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
889
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
28
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Day 2 Dns Cert 4a Cache Poisoning"

  1. 1. DNS Security for CERTs - Attack Scenarios & Demonstrations – Cache Poisoning Chris Evans Delta Risk, LLC 7 March 2010 1
  2. 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. 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. 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. 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. 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. 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. 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. 9. Attack Demonstration External Poisoning DNS Cache Web Server DNS Server Hacker Normal Request Poisoned Request Victim Web Server 9
  10. 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. 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. 12. Demonstration – Server View • Wireshark Capture – Note the queries like “031PtyJamG6o.tld1” 12
  13. 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. 14. Demonstration – User View 1 3 2 May look legit but is the hacker’s IP and webserver!!!!! 14
  15. 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. 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. 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
  18. 18. Questions? ? 18
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×