Aid in bypassing DNS issue
hescominsoon at emmanuelcomputerconsulting.com
Mon Jul 28 06:43:00 CDT 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:
> - 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
> - 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
> 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.
if your upstream has not fixed their issues yet..try forwarding to
opendns which IS secured against this issue until your upstream fixes
More information about the NANOG