dns exploit

[Brian Keefer]

On Jul 25, 2008, at 11:20 PM, Chris Buxton wrote:
> On Jul 25, 2008, at 11:02 PM, Brian Keefer wrote:
>
>> On Jul 25, 2008, at 10:43 PM, Chris Buxton wrote:
>>
>>> That sure seems like a lot of work when you could just:
>>>
>>> dig porttest.dns-oarc.net txt +short @server-ip
>>>
>>
>> Also, I noticed that doxpara/noclicky have different results for my
>> nameservers than porttest.dns-oarc.net has.  doxpara says I fail,  
>> dns-
>> oarc.net says I pass. Looking at a tcpdump I see that the queries
>> indeed use the same port for doxpara, but different ports for dns-
>> oarc.  I haven't had a chance to look closely enough yet to figure
>> out why that is.
>>
> As for the different results, all I can say is that's pretty odd.  
> I'd like to know what ISC has to say about this.
>
> Chris Buxton
> Professional Services
> Men & Mice
>


I just looked at it a bit more closely...

I'm using OpenBSD for my firewall and my nameservers.  The firewall  
is 3.5, the nameservers are 4.3.  The firewall is just doing standard  
PF nat for outbound requests.  Whether I used the doxpara tool, or  
dns-oarc the source ports from my recursive resolver were the same  
(pre-patch), but on the external interface of my firewall, the  
packets to doxpara did not get randomized ports, while those to dns- 
oarc did.  Post-patch the resolver itself has random source ports, so  
it's moot.

There have been several suggestions for writing PF nat statements to  
cover this vulnerability, and other folks supposedly had luck with  
them, so perhaps something changed with PF's randomization since  
3.5?  I haven't had enough spare time to comb the commit comments...

Dan did mention something in his blog about not having updated his  
tool to account for iptables or PF randomization, but I'm not sure  
why the tool being able to force the same source port is a bug with  
his script rather than a way to defeat said packet filter  
randomization...

Brian Keefer
Sr. Systems Engineer
www.Proofpoint.com
"Defend email.  Protect data."