SANS is reporting that Kaminsky's DNS bug may be now being exploited in
the wild. See:
http://isc.sans.org/diary.html?n&storyid=4765
Jon Kibler
- --
Jon R. Kibler
Chief Technical Officer
Advanced Systems Engineering Technology, Inc.
Charleston, SC USA
o: 843-849-8214
c: 843-224-2494
s: 843-564-4224
My PGP Fingerprint is:
BAA2 1F2C 5543 5D25 4636 A392 515C 5045 CF39 4253
matasano blogged about it
cache of the original post here..
http://beezari.livejournal.com/
matasano apologizes here
http://www.matasano.com/log/1105/regarding-the-post-on-chargen-earlier-today/
dan posts (13 - 0) 13 days left to blackhat opposed to the 0 days since the
details were discussed
http://www.doxpara.com/?p=1176
halvar flake speculation
http://addxorrol.blogspot.com/2008/07/on-dans-request-for-no-speculation.html
post on daily dave
It has been public for a while now. Even on the print media, there are some
articles about it on the latest Computerworld mag without giving too much
detail about how to exploit it.
ie PATCH NOW !!!
Cheers
Jorge
Kaminsky's blog says "Patch. Today. Now. Yes, stay late."
--Steve Bellovin, http://www.cs.columbia.edu/~smb
Let me add that folks need to understand that the "patch" is not a fix to a
problem that has been there for long time and
it is just a workaround to reduce the chances for a potential
attack, and it must be combined with best practices and
recommendations to implent a more robust DNS setup.
There are plenty of documents out there (check cert.org for example) that
can provide some guidance.
Perhaps this situation will help move things on the DNSSEC front, as far as
I remember there are some IETF drafts on
the standards track addressing these issues.
Cheers
Jorge
Having just seen some enterprise types spend time patching their nameservers, it's also perhaps worth spelling out that "patch" in this case might require more than upgrading resolver code -- it could also involve reconfigurations, upgrades or replacements of NAT boxes too. If your NAT reassigns source ports in a predictable fashion, then no amount of BIND9 patching is going to help.
(Reconfiguring your internal resolvers to forward queries to an external, patched resolver which can see the world other than through NAT-coloured glasses may also be a way out.)
Joe
After a bit of looking around, I have not been able to find a list of
firewalls/versions which are known to provide appropriate randomness in
their PAT algorithms (or more importantly, those that do not).
I would be very interested in such a list if anyone knows of one.
As a side note, most people here realize this but, while people mention
firewalls, keep in mind that if a load-balancer or other device is your
egress PAT device, you might be interested in checking those systems
port-translation randomness as well.
--D
FWIW, anyone using iptables for NAT can use --random, e.g.:
iptables -t nat -A POSTROUTING -o ethX -j SNAT --to x.x.x.x --random
Useful for Linux NAT/load-balancer boxes, or for Linux-powered embedded
devices where the vendor has not been forthcoming with a firmware patch
to alter the rules they generate.
I believe this requires kernel >= 2.6.21.
-Jasper
Joe Abley (jabley) writes:
Having just seen some enterprise types spend time patching their
nameservers, it's also perhaps worth spelling out that "patch" in this case
might require more than upgrading resolver code -- it could also involve
reconfigurations, upgrades or replacements of NAT boxes too. If your NAT
reassigns source ports in a predictable fashion, then no amount of BIND9
patching is going to help.
Case in point, we've got customers running around in circles
screaming "we need to upgrade, please help us upgrade NOW",
but they have _3_ layers of routers and firewalls that are hardcoded to
only allow DNS queries from port 53.
regnauld@catpipe.net (Phil Regnauld) writes:
Case in point, we've got customers running around in circles
screaming "we need to upgrade, please help us upgrade NOW",
but they have _3_ layers of routers and firewalls that are hardcoded to
only allow DNS queries from port 53.
please take this problem, and all related threads, to
<dns-operations@lists.oarci.net>. this is NANOG. there
are plenty of people on that other mailing list willing
to help and interested in helping with DNS issues.
fwiw, we all know that udp port randomization isn't a
panacea and that it will break many previously-working
configurations. we just don't know what else to do NOW
while we wait for godot or whomever to deliver us DNSSEC.