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


              Chris Evans
              Delta Risk, LLC

               7 March 2010


                                        1
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
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
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
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
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
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
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
Attack Demonstration
                                   External Poisoning


              DNS Cache                  Web Server
                           DNS
                          Server




                                             Hacker
 Normal
 Request

                                                      Poisoned
                                                      Request
     Victim



                                   Web Server


                                                             9
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
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
Demonstration – Server View

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




                                                12
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
Demonstration – User View

        1

                            3

2
                                 May look legit
                                   but is the
                                hacker’s IP and
                                 webserver!!!!!




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




             ?
                 18

Day 2 Dns Cert 4a Cache Poisoning

  • 1.
    DNS Security forCERTs - Attack Scenarios & Demonstrations – Cache Poisoning Chris Evans Delta Risk, LLC 7 March 2010 1
  • 2.
    What You WillNeed 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 Changein 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 poisoningattacks 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 – AttackerView _ _ _ | | (_)_ ____ ____| |_ ____ ___ ____ | | ___ _| |_ | / _ ) _)/ _ |/___) _ | |/ _ | | _) | | | ( (/ /| |_( ( | |___ | | | | | |_| | | |__ |_|_|_|____)___)_||_(___/| ||_/|_|___/|_|___) |_| =[ 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 – AttackerView (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 – ServerView • Wireshark Capture – Note the queries like “031PtyJamG6o.tld1” 12
  • 13.
    Demonstration – UserView • 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 – UserView 1 3 2 May look legit but is the hacker’s IP and webserver!!!!! 14
  • 15.
    Impact • Users aredependent 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 & ResponseStrategies • 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 & ResponseStrategies • 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.