Aid in bypassing DNS issue

Steve Bertrand steve at ibctech.ca
Sat Jul 26 05:14:48 UTC 2008


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




More information about the NANOG mailing list