Aid in bypassing DNS issue

Mon Jul 28 11:43:00 UTC 2008

Steve Bertrand wrote:
> With the time I've had, I've tried my best to keep up with every 
> message related to the current issue upon us related to DNS.
>
> I am a small op, amongst many that I've met the last few days that may 
> need assistance. I would like at least someone from a large operation 
> to read what I've done, what my concerns are and what help might be 
> provided for a scenario. If this is as big an issue as I feel it is, 
> then perhaps those with resources can offer advice. If you will:
>
> I've:
>
> - exploited a legacy machine and hijacked the NS records
> - set up an NS under the phony domain
> - configured A, AAAA and MX records for the hijacked domain (example.com)
> - put in place a simple index.html file for a website
> - configured email accounts
> - you get the point...it all works
>
> Then:
>
> - made some slight changes to the latest (as of 1000hrs 080725) to the 
> bailiwicked_domain.rb file to accept a new parameter 'RECURSCHK', that 
> 'fixes' the problem of a consistent domain showing up in the initial 
> TXT check that from what I can tell tests for recursion: (#set 
> recurschk wwNN.myDdomain.com).
>
> It allows an attacker to set a lookup against a name/record that (s)he 
> knows exists to get the ball rolling initially.
>
> This generally ensures that the first check of the exploit will always 
> pass (at least get an affirmative response, recursive or not), but 
> come under the radar of an expecting IDS filter.
>
> Once one host is exploited, then the rest of the names can be 
> built/run against, well, anything of course ...unfinished, but in 
> progress (I know Perl, never dealt with Ruby... a if/for/while would 
> be handy).
>
> I'd like to change the initial TXT to an A, but I don't think I quite 
> understand the ramifications on the grand scheme of things within the 
> scope of the exploit code, unless I were to focus more time on this. 
> Technically, I'm now on holidays...
>
> Anyway, if you've read this far,
>
> - my true, core name servers are as vulnerable as any name server that 
> has been patched
>
> - I have clients connected to my 'upstream' (if you please)
>
> - I configured a DNS server (implementation regardless) to "FORWARD 
> ONLY" to the 'upstream' DNS servers
>
> - We found that we are vulnerable, due to the fact that our 'upstream' 
> DNS servers are vulnerable because they don't use port randomization
>
> - we have wholesale business clients who are directly connected to 
> this 'upstream', and retrieve DNS server addresses via DHCP from 
> somewhere within their access layer
>
> - the 'upstream' has made no confirmation regarding fixes after 
> discussion
>
> My question:
>
> How to deal with this? It appears as though there are many that state 
> "...the patching has gone down hill", but what to do when your hands 
> are tied?
>
>
>
> Is there a network operations centre capable, able and willing to 
> publicly claim:
>
> "if you've tried your best to tell your 'upstreams' (ISP) to fix the 
> issue but they haven't, tell them to forget patching, ignore the work 
> until the problem goes away, turn off recursion and forward to us, 
> then patch later when you can afford some downtime"?
>
> Thank you to everyone who has already put so much time and 
> determination into this issue.
>
> Steve
>
if your upstream has not fixed their issues yet..try forwarding to 
opendns which IS secured against this issue until your upstream fixes 
their servers.