-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiF1T8ACgkQUVxQRc85QlMN1ACfTR8oJRy2V27+c5PjERcUjgIU evAAn1sDR9xMc1bEmTeygXl7QkF9er2T =eqbc -----END PGP SIGNATURE----- ================================================== Filtered by: TRUSTEM.COM's Email Filtering Service http://www.trustem.com/ No Spam. No Viruses. Just Good Clean Email.
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.htm... post on daily dave http://seclists.org/dailydave/2008/q3/0070.html On Tue, Jul 22, 2008 at 8:40 AM, Jon Kibler <Jon.Kibler@aset.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkiF1T8ACgkQUVxQRc85QlMN1ACfTR8oJRy2V27+c5PjERcUjgIU evAAn1sDR9xMc1bEmTeygXl7QkF9er2T =eqbc -----END PGP SIGNATURE-----
================================================== Filtered by: TRUSTEM.COM's Email Filtering Service http://www.trustem.com/ No Spam. No Viruses. Just Good Clean Email.
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
On Tue, 22 Jul 2008 08:00:51 -0500 "Jorge Amodio" <jmamodio@gmail.com> wrote:
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 !!!
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 On Wed, Jul 23, 2008 at 2:31 AM, Steven M. Bellovin <smb@cs.columbia.edu> wrote:
On Tue, 22 Jul 2008 08:00:51 -0500 "Jorge Amodio" <jmamodio@gmail.com> wrote:
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 !!!
Kaminsky's blog says "Patch. Today. Now. Yes, stay late."
--Steve Bellovin, http://www.cs.columbia.edu/~smb
On 23 Jul 2008, at 12:16, Jorge Amodio wrote:
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.
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 On Wed, Jul 23, 2008 at 10:11 AM, Joe Abley <jabley@ca.afilias.info> wrote:
On 23 Jul 2008, at 12:16, Jorge Amodio wrote:
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.
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
-- -- Darren Bolding -- -- darren@bolding.org --
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 On Wed, 2008-07-23 at 12:16 -0700, Darren Bolding wrote:
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
On Wed, Jul 23, 2008 at 10:11 AM, Joe Abley <jabley@ca.afilias.info> wrote:
On 23 Jul 2008, at 12:16, Jorge Amodio wrote:
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.
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
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. -- Paul Vixie -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
participants (9)
-
Christian Koch -
Darren Bolding -
Jasper Bryant-Greene -
Joe Abley -
Jon Kibler -
Jorge Amodio -
Paul Vixie -
Phil Regnauld -
Steven M. Bellovin