Mailbag 2
This month's answers created by:
[ Kapil Hari Paranjape, René Pfeiffer, Rick Moen ]...and you, our readers!
Editor's Note
In followup to Rick Moen's article in LG153, a collection of the DNS discussion in TAG from July and August.DNS Exploit: Fix for older Fedora machines??
Rick Moen [rick at linuxmafia.com]
Thu, 24 Jul 2008 19:45:20 -0700
Two posts that help clarify the threat model.
----- Forwarded message from Keith Owens <[email protected]> -----
X-Mailer: exmh version 2.7.2 01/07/2005 (debian 1:2.7.2-12) with nmh-1.2
From: Keith Owens <[email protected]> To: [email protected] Date: Fri, 25 Jul 2008 12:10:40 +1000 Subject: Re: DNS Exploit: Fix for older Fedora machines??"Leigh Sharpe" (on Fri, 25 Jul 2008 11:56:41 +1000) wrote:
> I have a couple of older FC2 machines running bind DNS. Is there an rpm >available with the fix for the recent DNS exploit? Or am I stuck with >the choice of compiling from source or upgrading the OS?
You need a version of bind9 that is less than 2 months old. bind8 is not being fixed. If Redhat do not have a recent bind9 for FC2 then get the latest src.rpm and build your own.
Alternatively install a small machine running a newer OS with a fixed DNS server and direct all DNS queries via that machine. It is only the final query (the one that hits the outside world) that needs to come from a fixed DNS server. Add firewall rules to block DNS queries from any other machine to the outside world.
Also turn off recursion for DNS queries that come from outside your site and are not for sites in your DNS. One of the ways that attackers are getting information is by issuing recursive requests to your DNS and pointing back at their machines. If you allow external recursive requests then it is much easier for an attacker to get information about your DNS's internal state.
Not sure how to turn off recursion for external requests? See http://www.cymru.com/Documents/secure-bind-template.html
----- End forwarded message ----- ----- Forwarded message from Keith Owens <[email protected]> -----
X-Mailer: exmh version 2.7.2 01/07/2005 (debian 1:2.7.2-12) with nmh-1.2
From: Keith Owens <[email protected]> To: James Harper <[email protected]>cc: [email protected]
Date: Fri, 25 Jul 2008 11:24:36 +1000 Subject: Re: DNS exploit: watch out for NAT boxes"James Harper" (on Fri, 25 Jul 2008 11:04:15 +1000) wrote:
[ ... ]
[ Thread continues here (1 message/5.23kB) ]
DNS exploit: watch out for NAT boxes
Rick Moen [rick at linuxmafia.com]
Thu, 24 Jul 2008 17:22:51 -0700
Again, I'd suggest a direct fix to any suspect nameserver software, rather than iptables wrapping -- but it's good to know that sharp eyes are attempting to ensure that the latter approach can also be made workable.
----- Forwarded message from Keith Owens <[email protected]> -----
X-Mailer: exmh version 2.7.2 01/07/2005 (debian 1:2.7.2-12) with nmh-1.2
From: Keith Owens <[email protected]> To: Brian May <[email protected]>cc: [email protected]
Date: Fri, 25 Jul 2008 10:08:09 +1000 Subject: Re: DNS exploit: watch out for NAT boxesKeith Owens (on Fri, 25 Jul 2008 09:52:53 +1000) wrote:
>Brian May (on Fri, 25 Jul 2008 09:17:56 +1000) wrote: >>Keith Owens wrote: >>> Bottom line: check if your DNS server is behind a NAT box that does >>> sequential port mapping. The 'Check My DNS' widget at >>> http://www.doxpara.com will tell you if the outside world is seeing >>> sequential ports or not. >>> >>How does Linux NAT assign port numbers? > >2.6.26 should do random port mapping. It starts off by trying to >preserve the original (hopefully random) source port number. If the >original source port number is already in use by another NAT entry then >it should generate a random source port number. I say "should" because >the code tests for flag IP_NAT_RANGE_PROTO_RANDOM and a quick check of >the source did not find anywhere where that flag was set, I'm still >looking.
Recent kernels should do random mapping but they do not. I just ran a
test masquerading DNS queries to a small range of source port numbers
and it went sequential 
. This has not been fixed as of yesterday's
git patch; a bug report is on its way.
Having said that it goes sequential, the fact that masquerade tries to preserve the original source port number will mitigate against this bug. In most cases the original (random) source port number will be preserved, unless you force the source port into a particular range.
----- End forwarded message ----- ----- Forwarded message from hannah commodore <[email protected]> -----
Date: Fri, 25 Jul 2008 10:15:02 +1000 From: hannah commodore <[email protected]> To: [email protected] Subject: Re: DNS exploit: watch out for NAT boxesKeith Owens wrote:
>test masquerading DNS queries to a small range of source port numbers >and it went sequential
As mentioned on Dan's blog however, there is a work-around that does create random source ports: http://cipherdyne.org/blog/2008/07/mitigating-dns-cache-poisoning-attacks-with-iptables.html
----- End forwarded message -----
[conspire] Kaminsky presentation slides
Rick Moen [rick at linuxmafia.com]
Wed, 6 Aug 2008 16:57:58 -0700
----- Forwarded message from Rick Moen <[email protected]> -----
Date: Wed, 6 Aug 2008 16:52:29 -0700 From: Rick Moen <[email protected]> To: [email protected] Subject: [conspire] Kaminsky presentation slidesDan Kaminsky gave his "Black Ops 2008" talk (continuing a series he's been giving for years at LISA conferences and elsewhere) about two hours ago at Black Hat, Caesar's Palace, Las Vegas. No downloadable audio file (one very nice thing about LISA conferences) yet, but Kaminsky has committed PowerPoint: http://www.doxpara.com/DMK_BO2K8.ppt
Major points:
0. Bad guy induces a nameserver to issue queries for 1.foo.com,
2.foo.com,... and floods it with forged responses delegating the
query to claimed nameserver (or CNAME alias) "www.foo.com", and
trying to race that info back before the genuine response does.
Any response that succeeds and gets cached also carries the
(unrequested) "ADDITIONAL INFORMATION" datum that the forward-lookup
IP of www.foo.com is $EVIL_IP. That unrequested info then gets
cached for a long time-to-live (TTL). Voila! Cache poisoning.
Notice that the forged, malign data is in-bailiwick for foo.com.
1. There are a huge number of ways to induce "safe" machines behind
firewalls to ask about hostnames of an attacker's choosing:
o Web hyperlinks, with or without Typhoid Marys Javascript, Flash,
Java, etc. (though an attack can use those Typhoid Marys to
induce severe mischief by inducing reverse-DNS lookups).
o Practically any part of an attempted SMTP mail delivery.
o Logfiles that do reverse-DNS lookup (e.g., Web servers).
o "Web bugs" in documents.
o IDS paranoia that makes them do reverse-DNS lookups.
(Kaminsky talks at length about ways to make this scale, practical,
and more revealing of details of company-internal networks.)
2. Making sure UDP source ports are random is a stopgap, as DNS's
protocol design leaves it pretty unreliable. (Duh.)
3. DNS clients (resolver libs) are a little vulnerable if you
can flood them with fake responses -- but at least don't cache.[1]
4. Web (etc.) SSL certs don't necesssarily paper over the problem,
because of dependency on DNS. (For example: Did you make your
browser trust my Thawte cert for example.com? Cool!
That means it'll typically also accept my cert for paypal.com
that has the same signature. Or, hey, if I can convincingly forge
paypal.com's DNS, I can register a Thawte certificate for paypal.com
myself, because I can make the confirmation mails come to me.
Ditto, almost everyone's "I forgot my password" link trusts DNS
to some extent.)
5. Risks also affect some internal networks, for several reasons including
active internal code and routing that rely on DNS. (Duh.)
6. NAT is a sore point.
Choice quotation from the first slide:
"-- I found a really bad bug a while ago.
o You might have heard of it...."
As usual for a Kaminsky talk, he's also done quite a great deal to trace out possible ramifications. Recommended.
[ ... ]
[ Thread continues here (1 message/3.83kB) ]
[conspire] DNS vulnerability details
Rick Moen [rick at linuxmafia.com]
Thu, 24 Jul 2008 09:28:43 -0700
----- Forwarded message from Eric De MUND <[email protected]> -----
Date: Wed, 23 Jul 2008 22:37:55 -0700 To: [email protected]X-Mailer: VM 7.19 under Emacs 21.4.1
From: Eric De MUND <[email protected]> Reply-To: Eric De MUND <[email protected]> Subject: Re: [conspire] DNS vulnerability detailsRick,
First of all, a huge thank you for posting this very clearly written report /with prescription/. I'm an expert in some tiny little areas, and DNS isn't one of them. This is useful to me in quickly getting from poor safety maybe not to excellent safety but perhaps to "pretty good" safety.
I appreciate the sharing tremendously. Rick, you are a guy.
] Testing your nameserver's randomness of source port selection: ] ] Or use this Web facility: ] https://www.dns-oarc.net/oarc/services/dnsentropy
Ok, in repeated tests, I'm getting 2/3 POORs and 1/3 GOODs for source port randomness, and all GREATs for transaction IDs. This is Comcast.
DNS Resolver(s) Tested:
1. 68.87.76.179 (sjos-cns01.sanjose.ca.sanfran.comcast.net)
appears to have POOR source port randomness and GREAT transaction
ID randomness.
2. 68.87.76.181 (sjos-cns03.sanjose.ca.sanfran.comcast.net)
appears to have POOR source port randomness and GREAT transaction
ID randomness.
3. 68.87.78.131 (utah-cns01.saltlakecity.ut.utah.comcast.net)
appears to have GOOD source port randomness and GREAT transaction
ID randomness.
So what DNS-related debian package(s) do I need to get and run?
Regarding my Linksys WRT54G broadband router which is running DD-WRT v23 SP2 (09/15/06) std firmware, I think that if a patch is required, one will be made available shortly.
Regards, Eric
-- Eric De MUND | Ixian Systems | Jab: [email protected]/main [email protected] | 650 Castro St, #120-210 | Y!M: ead0002 ixian.com/ead/ | Mountain View, CA 94041 | ICQ: 811788http://linuxmafia.com/mailman/listinfo/conspire
----- End forwarded message ----- ----- Forwarded message from Rick Moen <[email protected]> -----
Date: Thu, 24 Jul 2008 09:20:00 -0700 From: Rick Moen <[email protected]> To: [email protected] Subject: Re: [conspire] DNS vulnerability detailsQuoting Eric De MUND ([email protected]):
> Ok, in repeated tests, I'm getting 2/3 POORs and 1/3 GOODs for source > port randomness, and all GREATs for transaction IDs. This is Comcast. > > DNS Resolver(s) Tested:
Please don't read this as a complaint, but rather as a caution about terminology: Most people reserve the term "DNS resolver" to refer only to the DNS client piece (the one that on Linux is built into libc and has conffile /etc/resolv.conf). Being careful about terminology can help avoid confusing one's self.
[ ... ]
[ Thread continues here (10 messages/42.45kB) ]
DNS source port randomisation
Kapil Hari Paranjape [kapil at imsc.res.in]
Thu, 10 Jul 2008 17:29:27 +0530
Hello,
Most of you must have heard about Dan Kaminsky's discovery of a flaw in the DNS protocol and its standard implementation (in glibc and bind 8).
I thought of a quick fix for source port randomisation for DNS queries using iptables.
http://www.imsc.res.in/~kapil/blog/dns_quickfix-2008-07-10-17-07
Basically, the idea is to use iptables feature of source nat coupled with source randomisation.
iptables -t nat -A POSTROUTING -o ! lo -p udp --dport 53 \
-j MASQUERADE --to-ports 1024-65535 --random
iptables -t nat -A POSTROUTING -o ! lo -p tcp --dport 53 \
-j MASQUERADE --to-ports 1024-65535 --random
After writing this I realised that the randomisation only works with kernels version than 2.6.22.
Regards,
Kapil. --
[ Thread continues here (12 messages/40.02kB) ]
