That clears it up for me. Thank you. On Wed, Aug 13, 2008 at 10:12 AM, Chris Buxton <[EMAIL PROTECTED]>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 <[EMAIL PROTECTED]> 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----- >
