what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New

dns-poison.txt

dns-poison.txt
Posted Apr 17, 2007
Authored by Makoto Shiotsuki

Whitepaper discussing Windows DNS cache poisoning by forwarder DNS spoofing.

tags | paper, spoof
systems | windows
SHA-256 | a8edfacf63fc3159336647ddf759fbe145f1138297489817602d348e2b57d3a4

dns-poison.txt

Change Mirror Download
------------------------------------------------------------------------
Windows DNS Cache Poisoning by Forwarder DNS Spoofing

2007.4.16

Makoto Shiotsuki <shio@st.rim.or.jp>

Introduction
============

About two years ago, SANS Handler's Diary reported that Windows DNS
server is vulnerable to the cache poisoning attack despite "Secure cache
against pollution" setting if it is configured to forward requests to
the forwarder DNS server [1][2].

According to the Handler's Diary, this poisoning attack against Windows
DNS would be successful in the case when the forwarder DNS server itself
is vulnerable to the poisoning attack or the forwarder DNS server does
not filter out the bogus records in the poisoning attack. So, it is
believed that using Bind9 as forwarder is safe to protect Windows DNS
server from cache poisoning attack through forwarder.

But there seems to be other possible scenario, and in this case, the
possibility of successful attack does not depend on the type or version
of the forwarder DNS server. Therefore, the risk of the Windows DNS
cache poisoning attack is higher than generally perceived.

As far as I tried, DNS service of the Windows Server 2003 SP2 still has
this vulnerability.

Details
=======

As described above, Windows DNS is vulnerable to the cache poisoning
attack through the forwarder DNS server. This seems because Windows DNS
blindly trusts replies from forwarder DNS and caches every resource
records regardless of their domain.

Windows DNS also has characteristic that it is vulnerable to the DNS
spoofing attack using "birthday attack" [3]. By sending multiple
simultaneous queries and forged replies to the Windows DNS server,
attacker can inject a spoofed reply relatively easily if its arrival is
earlier than the reply from the legitimate DNS server.

Both of these are known vulnerabilities (or characteristics? ;) on
Windows DNS, and each of them individually is not high risk because
they require some preconditions to be successfully exploited. However,
by executing the cache poisoning attack in conjunction with DNS
spoofing, it will be more effective attack and the risk will be higher
than before.

Following is the scenario.

+-----------+ (1)Query +-----------+
| | -------------------------> | |
| | -------------------------> | |
| Attacker | -------------------------> | Windows |
| | | DNS |
| | -------------------------> | |
| | -------------------------> | (Victim) |(6)Poisoned!!
| | -------------------------> | |
+-----------+ (5)Answer(poisoning) +-----------+
|||
||| (2)Query
|||
vvv
+-----------+ (3)Query +-----------+
| | <------------------------- | |
| | <------------------------- | |
| Attacker | <------------------------- | Forwarder |
| DNS | | DNS |
| | | |
| | (4) no reply | |
| | | |
+-----------+ +-----------+

1) Attacker sends multiple simultaneous recursive queries (e.g. 500
queries) to the Windows DNS server, resolving the name in
attacker's domain.
2) Windows DNS forwards those queries to the Forwarder DNS server.
3) Forwarder DNS sends queries to the Attacker DNS server to resolve
the name.
4) Attacker DNS does not reply at all and Forwarder DNS waits for
timeout.
5) Attacker sends multiple simultaneous replies (e.g. 500 replies)
spoofing Forwarder DNS ip address with random query id. Each reply
includes forged resource records to poison the Windows DNS cache.
6) Windows DNS accepts certain spoofed reply if its query id matches
one of the queries from the Windows DNS and finally Windows DNS
cache is poisoned.

To accomplish this attack, the attacker must know the udp port number
of the Windows DNS server. The attacker can know it simply by sending
a query packet to the Windows DNS server resolving some names in
attacker's domain, because, by default, Windows DNS issues recursive
query by itself if the forwarder does not respond. (This behavior can
be changed using the DNS property window by setting "Do not use
recursion for this domain" check box ON.)

Windows DNS uses same source port number unless the service restarts.
Thus the attacker can use this port number for the attacking reply
packets as udp destination port.

Affected products
=================

Windows Server 2003 (up to and including SP2)
Windows 2000 Server (up to and including SP4)

Vendor status
=============

According to Microsoft response I've got through IPA/ISEC, this kind of
poisoning attack is caused by design of the Windows DNS service, and
they are considering the design change at service pack level.

Solutions
=========

Stop using forwarder.

Mitigating factors
==================

Reject recursive queries to the Windows DNS server from outside of the
site. This will help to prevent direct attacks from the Internet.

References
==========

[1] http://isc.sans.org/presentations/dnspoisoning.html
[2] http://isc.sans.org/diary.php?date=2005-04-07
[3] http://www.lurhq.com/cachepoisoning.html
------------------------------------------------------------------------
Login or Register to add favorites

File Archive:

May 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    May 1st
    44 Files
  • 2
    May 2nd
    5 Files
  • 3
    May 3rd
    11 Files
  • 4
    May 4th
    0 Files
  • 5
    May 5th
    0 Files
  • 6
    May 6th
    28 Files
  • 7
    May 7th
    0 Files
  • 8
    May 8th
    0 Files
  • 9
    May 9th
    0 Files
  • 10
    May 10th
    0 Files
  • 11
    May 11th
    0 Files
  • 12
    May 12th
    0 Files
  • 13
    May 13th
    0 Files
  • 14
    May 14th
    0 Files
  • 15
    May 15th
    0 Files
  • 16
    May 16th
    0 Files
  • 17
    May 17th
    0 Files
  • 18
    May 18th
    0 Files
  • 19
    May 19th
    0 Files
  • 20
    May 20th
    0 Files
  • 21
    May 21st
    0 Files
  • 22
    May 22nd
    0 Files
  • 23
    May 23rd
    0 Files
  • 24
    May 24th
    0 Files
  • 25
    May 25th
    0 Files
  • 26
    May 26th
    0 Files
  • 27
    May 27th
    0 Files
  • 28
    May 28th
    0 Files
  • 29
    May 29th
    0 Files
  • 30
    May 30th
    0 Files
  • 31
    May 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close