Not sure if my DNS is vulnerable?

John Smith n6s7a6 at gmail.com
Wed Aug 13 14:27:40 UTC 2008


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