Not sure if my DNS is vulnerable?

Faehl, Chris cfaehl at rightnow.com
Wed Aug 13 14:52:44 UTC 2008


John,
Yes, there have been successful attacks. As you might expect, many of the targets are financial institutions.

Chris Faehl
Hosting Manager, RightNow Technologies

-----Original Message-----
From: bind-users-bounce at isc.org [mailto:bind-users-bounce at isc.org] On Behalf Of John Smith
Sent: Wednesday, August 13, 2008 8:29 AM
To: Chris Buxton
Cc: Ben Croswell; bind-users at isc.org
Subject: Re: Not sure if my DNS is vulnerable?

Has anyone heard of any successful attacks?
On Wed, Aug 13, 2008 at 10:27 AM, John Smith <n6s7a6 at gmail.com> wrote:

> That clears it up for me. Thank you.
>
>
>
> On Wed, Aug 13, 2008 at 10:12 AM, Chris Buxton <cbuxton at menandmice.com>wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> No, that's pretty much it.
>>
>> Step 1) Attacker sets up attacking name server, which waits for contact
>> from a potential victim.
>>
>> Step 2) Attacker hacks a web page, adding a short (and legitimate-looking)
>> JavaScript.
>>
>> Step 3) Innocent web browser in your organization visits the web page,
>> loading the attack script.
>>
>> Step 4) The script tries to load an image from the attacker's domain. This
>> tells the attacking name server your source port for queries, can encode the
>> target domain to be spoofed, and triggers the attack. During the attack, the
>> JavaScript is trying to load images from successive domains in the same zone
>> as the target domain to be spoofed, on a schedule. The attacking name server
>> is trying to spoof each of these nearby names, on the same schedule, by
>> brute-forcing the transaction ID. (It's only 16 bits long - that's not much
>> of a crypto key.) The script can load more images from the attacker's
>> domain, thus informing the attacking name server of its progress and getting
>> status reports back.
>>
>> The whole attack is completely automated, is triggered by a trusted user's
>> web browser, will penetrate firewalls in nearly all cases (but an IPS may be
>> able to stop it - by disabling inbound responses to your resolving name
>> server, rendering it useless), and is fast and deadly.
>>
>> Chris Buxton
>> Professional Services
>> Men & Mice
>>
>> On Aug 13, 2008, at 6:56 AM, Ben Croswell wrote:
>>
>>  I would say you are "less vulnerable", but you are still vulnerable.
>>> It is only a matter of time before someone integrates the exploit code
>>> into
>>> a webpage.
>>> One of your internal users goes to the web page which has the browser
>>> resolve somehost.evil.org.  The attacker now knows the IP of your
>>> outbound
>>> DNS server.  At this point  I would guess, it wouldn't to difficult to
>>> have
>>> javascript on the webpage force the browser to do the actual DNS queries
>>> from the inside.  Once those go out the attacker spams the answer back to
>>> win the race.
>>>
>>> Anyone else can correct me if I am too far off base.
>>>
>>> --
>>> -Ben Croswell
>>>
>>> On Wed, Aug 13, 2008 at 9:15 AM, John Smith <n6s7a6 at gmail.com> wrote:
>>>
>>>  So I have a caching only DNS server that is behind a firewall and has no
>>>> incoming connections allowed unless specifically requested from inside.
>>>> My
>>>> DNS server does contact the root DNS servers upstream. But again
>>>> incoming
>>>> conections are only allowed into my DNS server unless the originated
>>>> from
>>>> the inside.
>>>> As far as I understand the problem for the recent DNS issues is from
>>>> someone
>>>> on the outside of my firewall ( I am ignoring an attack from the inside)
>>>> would have to send my DNS server (which they cannot) some DNS requests
>>>> in
>>>> order to get a reply for them to attack?
>>>> Am I right? so since I do not have external access to port 53 I am
>>>> relatively safe?
>>>>
>>>> Since my DNS is not randomizing ports but is radomizign transaction
>>>> id's?
>>>>
>>>> Just curious.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.8 (Darwin)
>>
>> iEYEARECAAYFAkii6+cACgkQ0p/8Jp6Boi2vwgCgrKvtDF328VuRHml3lavIgOiu
>> 0J8An1bEBeeQ6pCVyXu7vzND68WvQ/VB
>> =Otxk
>> -----END PGP SIGNATURE-----
>>
>
>





More information about the bind-users mailing list