DNS Gurus Talk on Their New Podcast - “Ask Mr. DNS”
I just ran into this podcasts from the two gurus of DNS - Matt Larson and Cricket Liu.
For all you DNS junkies you’ll love this content from two old school DNS players.
January 6, 2009
December 19, 2008
Is Your Network Ready for Infrastructure 2.0?
I find it interesting that its interesting that Cisco, Infoblox, and F5 have come together very quickly around this Infrastructure 2.0 meme.
Interested in Infrastructure 2.0 from Cisco then click here to register.
Network infrastructure will be transformed in coming months by new levels of automation and intelligence driven by new system and endpoint demands and new IT initiatives. Find out how you can boost network availability and flexibility while reducing TCO by transforming your static network infrastructure into a dynamic network infrastructure capable of responding quickly to the needs of more dynamic systems and endpoints. Attendees will learn about:
- Cisco’s perspective on the biggest revolution in data center networking technology since TCP/IP
- Why new initiatives, from RFID/supply chain to voip/wireless and virtualization will require dynamic infrastructure
- Why core network services automation and “connectivity intelligence” are a critical part of the evolution to Infrastructure 2.0
Speakers:
Stuart Bailey, Founder and Chief Technology Officer, Infoblox
Doug Gourlay, Senior Director, Cisco
Moderator:
Richard Kagan, VP Marketing, Infoblox
December 3, 2008
Yahoo Hit By DNS Bug - Was it Cache Poisoning
Yahoo was hit by a massive DNS problem today reported by GigaOm.
Some are saying quietly that there was a DNS cache poisining that effected Yahoo’s main DNS nameservers. Yahoo is not talking to me about this. Of course I’m interested in this because of all the recent DNS security risks which have been well documented by the DNS industry leading company Infoblox.
I will try to dig into this and see if Dan Kaminsky has any insight into this.
DNS problems went mainstream after I started reporting about it here and then John Markoff reported about it on the NYTimes.
Some more info here
Top-line results indicate that despite the fact that most organizations are running recent versions of BIND and no longer using Microsoft DNS Servers for their external DNS servers, many organizations have not taken the necessary precautions to limit access to recursion or secure zone transfers. In addition, many still have not upgraded to the latest DNS software to protect against the recently discovered Kaminsky vulnerability and associated risk of DNS cache poisoning.
“Given the heightened awareness of DNS server vulnerabilities due to the recent Kaminsky discovery, it is surprising to see how many organizations are still leaving their DNS systems as potential victims of attack,” commented Cricket Liu, Vice President of Architecture at Infoblox and author of O’Reilly & Associates’ DNS and BIND, DNS & BIND Cookbook, and DNS on Windows Server 2003. “Even if an enterprise has gone to the trouble of patching against the Kaminsky vulnerability, there are many other aspects of configuration, like recursion and open zone transfers, that should also be secured. If not, organizations are essentially locking their door to their house, but leaving the windows wide open. Organizations clearly need to pay more attention to configurations and deployment architectures that are leaving their DNS infrastructures vulnerable to attacks and outages.”
DNS servers are essential network infrastructure that map domain names (e.g., yahoo.com) to IP addresses (e.g., 66.94.234.13), directing Internet inquiries to the appropriate location. Domain name resolution conducted by these servers is required to perform any Internet-related request, whether for Web browsing, email, ecommerce, or cloud computing. Should an enterprise or organization’s DNS systems become compromised by attacks, the results can be devastating, ranging from loss of a company’s Web presence, inability of employees to access any outside Web services, and perhaps most damaging, redirection of Web and email traffic to bogus sites, resulting in data loss, identity theft, ecommerce fraud and more.
Following are the key 2008 DNS survey results, which are based on a sample that included 5 percent of the IPv4 address space, nearly 80 million addresses.
GOOD NEWS
-- 90% of name servers that run BIND run one of the most recent versions
of BIND 9; a small but significant number of administrators continue to run
older versions of BIND on Internet-facing name servers, putting their
organizations at risk.
-- Only .17% still rely on Microsoft DNS Server, down from 2.7% (2007);
usage of unsecure Microsoft DNS Servers connected to the Internet is
vanishing.
-- Support for Sender Protection Framework (SPF) within DNS for spam
reduction increased from 12.6% of zones sampled to 16.7%; despite the
complexity of SPF configuration, validating email senders is increasing in
importance and organizations are taking email fraud seriously.
BAD NEWS
-- One in four DNS servers does not perform source port randomization --
the "patch" for "the Kaminsky vulnerability"; the effort by vendors and the
Internet's DNS community to encourage administrators to upgrade their name
servers after the announcement of the Kaminsky vulnerability paid off;
however, a surprising number have not been upgraded and are very vulnerable
to cache poisoning.
-- More than 40% of Internet name servers allow recursive queries; there
are still millions of open recursors on the Internet, a danger both to
themselves and others -- they are vulnerable to cache poisoning and
Distributed Denial of Service attacks.
-- 30% of DNS servers surveyed allow zone transfers to arbitrary
requestors; this leaves servers as easy targets for denial-of-service
attacks.
-- Only .002% of DNS zones tested support DNSSEC; administrators have not
been convinced of its importance -- perhaps intimidated by its complexity
-- but new mandates could mean a significant change in the near future.
MISC.
-- Usage of IPv6 name servers continues to increase from .27% to .44%;
while enterprises are investigating IPv6 and concerned about increasingly
scarce IPv4 address space, adoption of IPv6 is still low -- address
scarcity isn't yet considered a serious concern and they feel no urgency to
adopt IPv6.
Call to Action
Based on these statistics, there are some clear calls to action for organizations with external DNS servers. Instead of waiting until they are attacked, all organizations should assess their DNS infrastructure and immediately take the necessary steps to make them more reliable and secure. Infoblox provides a number of free, automated tools that enable organizations to test their DNS infrastructure and identify weaknesses and vulnerabilities.
November 10, 2008
Worldwide Survey: Most DNS Servers And Systems Vulnerable to Attacks
One in Four Servers Still Unpatched for the Kaminsky Vulnerability and Many More Open to Recursion
The Measurement Factory, experts in performance testing and protocol compliance, today announced results from the fourth-annual survey of domain name servers on the public Internet.
Top-line results indicate that despite the fact that most organizations are running recent versions of BIND and no longer using Microsoft DNS Servers for their external DNS servers, many organizations have not taken the necessary precautions to limit access to recursion or secure zone transfers. In addition, many still have not upgraded to the latest DNS software to protect against the recently discovered Kaminsky vulnerability and associated risk of DNS cache poisoning.
“Given the heightened awareness of DNS server vulnerabilities due to the recent Kaminsky discovery, it is surprising to see how many organizations are still leaving their DNS systems as potential victims of attack,” commented Cricket Liu, Vice President of Architecture at Infoblox and author of O’Reilly & Associates’ DNS and BIND, DNS & BIND Cookbook, and DNS on Windows Server 2003. “Even if an enterprise has gone to the trouble of patching against the Kaminsky vulnerability, there are many other aspects of configuration, like recursion and open zone transfers, that should also be secured. If not, organizations are essentially locking their door to their house, but leaving the windows wide open. Organizations clearly need to pay more attention to configurations and deployment architectures that are leaving their DNS infrastructures vulnerable to attacks and outages.”
DNS servers are essential network infrastructure that map domain names (e.g., yahoo.com) to IP addresses (e.g., 66.94.234.13), directing Internet inquiries to the appropriate location. Domain name resolution conducted by these servers is required to perform any Internet-related request, whether for Web browsing, email, ecommerce, or cloud computing. Should an enterprise or organization’s DNS systems become compromised by attacks, the results can be devastating, ranging from loss of a company’s Web presence, inability of employees to access any outside Web services, and perhaps most damaging, redirection of Web and email traffic to bogus sites, resulting in data loss, identity theft, ecommerce fraud and more.
Following are the key 2008 DNS survey results, which are based on a sample that included 5 percent of the IPv4 address space, nearly 80 million addresses.
GOOD NEWS
-- 90% of name servers that run BIND run one of the most recent versions
of BIND 9; a small but significant number of administrators continue to run
older versions of BIND on Internet-facing name servers, putting their
organizations at risk.
-- Only .17% still rely on Microsoft DNS Server, down from 2.7% (2007);
usage of unsecure Microsoft DNS Servers connected to the Internet is
vanishing.
-- Support for Sender Protection Framework (SPF) within DNS for spam
reduction increased from 12.6% of zones sampled to 16.7%; despite the
complexity of SPF configuration, validating email senders is increasing in
importance and organizations are taking email fraud seriously.
BAD NEWS
-- One in four DNS servers does not perform source port randomization --
the "patch" for "the Kaminsky vulnerability"; the effort by vendors and the
Internet's DNS community to encourage administrators to upgrade their name
servers after the announcement of the Kaminsky vulnerability paid off;
however, a surprising number have not been upgraded and are very vulnerable
to cache poisoning.
-- More than 40% of Internet name servers allow recursive queries; there
are still millions of open recursors on the Internet, a danger both to
themselves and others -- they are vulnerable to cache poisoning and
Distributed Denial of Service attacks.
-- 30% of DNS servers surveyed allow zone transfers to arbitrary
requestors; this leaves servers as easy targets for denial-of-service
attacks.
-- Only .002% of DNS zones tested support DNSSEC; administrators have not
been convinced of its importance -- perhaps intimidated by its complexity
-- but new mandates could mean a significant change in the near future.
MISC.
-- Usage of IPv6 name servers continues to increase from .27% to .44%;
while enterprises are investigating IPv6 and concerned about increasingly
scarce IPv4 address space, adoption of IPv6 is still low -- address
scarcity isn't yet considered a serious concern and they feel no urgency to
adopt IPv6.
Call to Action
Based on these statistics, there are some clear calls to action for organizations with external DNS servers. Instead of waiting until they are attacked, all organizations should assess their DNS infrastructure and immediately take the necessary steps to make them more reliable and secure. Infoblox provides a number of free, automated tools that enable organizations to test their DNS infrastructure and identify weaknesses and vulnerabilities.
November 4, 2008
Infoblox Kicks Butt - Quality People and Quality Products For Infrastructure 2.0
I have to say that I really like working with Infoblox -solid company with solid products. Infoblox supports this blog and social media. What a refreshing change from the old way of doing things. The new model is to connect with people in the community - peers and collegues.
Thanks Infoblox.
Here is a post from Greg Ness’ blog on their new bloxNews. Below is the note from Greg Ness
Infoblox Monthly eNewsletter now Online
We started bloxNews(TM) at Infoblox a couple of months ago as a way to collect and share industry developments related to core network services, IP address management as well as relevant trends in networking, security, virtualization and cloud computing. It goes out monthly to more than 10,000 readers.
Would love to hear what you think. We place a heavy content emphasis on industry news and commentary that we think are worth following. We also sprinkle in a bit of bloxTV and bloxRadio on topics like DNS, DNS security, DNSSEC and upcoming episodes on IPAM (IP address management).
I’ve been blogging recently about Infrastructure 2.0, or a dynamic infrastructure capable of keeping up with new initiatives, from RFID and consolidation to virtualization, wireless, VoIP and cloud. I think the automation of core network services (including DNS, DHCP and IPAM) will be strategic to the build-outs of dynamic infrastructure and the establishment of economies of scale. Many of these services are managed manually today, driving up network TCO while eroding availability and flexibility and security.
Without automation of these core network services enterprise networks will experience diseconomies of scale.
You can subscribe to bloxNews here.
October 30, 2008
Core Network Services Interwoven Deploys Infoblox
Infoblox Inc. today announced that Interwoven, a global leader in content management solutions, has deployed Infoblox appliances for delivery of core network services, including internal domain name resolution (DNS) and IP address assignment (DHCP).
Domain name resolution and IP address assignment services are essential for all IP networks; without them, the network and applications can grind to a halt. And, when they are not robust enough or integrated properly, application malfunctions can be the result.
The Interwoven IT team recognized this first-hand when they implemented a network access control (NAC) solution with a legacy Windows-based core network services infrastructure that did not allow for effective dynamic DNS updates, producing data inconsistency. As a result, when certain users attempted to access the network, they were erroneously instructed to scan their system and/or update their end point security software, compromising productivity and causing many end-user frustrations.
Interwoven looked at several core network services solutions and selected Infoblox as its new next-generation infrastructure.
“NAC was the driver to upgrade our entire core network services system,” said Raymond Lockley, CORE systems manager at Interwoven. “And now, our NAC solution is much more effective; since installing Infoblox, we have not had any DNS-based network connectivity issues.”
Yonas Hambissa, senior systems administrator at Interwoven, concluded, “We looked at several competitors, but only Infoblox met our security, reliability and management needs. Simple code propagation, real-time data updates, along with tools for accurate data entry, and reliable service delivery are the real advantages.”
Interwoven purchased and deployed 13 Infoblox appliances running the DNSone package with Infoblox’s unique grid technology that links the distributed appliances into a unified system for central management, one-button upgrades and resilience benefits. In addition to Interwoven’s San Jose, Calif. headquarters, Infoblox appliances are also deployed in their Australia, Singapore, Bangalore, Atlanta, Chicago, Austin, New York, Maryland and UK offices.
September 11, 2008
DNS Security Issues - Podcast with Cricket Lui
I did a podcast for Infoblox’s DNS guru Cricket Lui two weeks ago to talk about the DNS problems and security issues.
Infoblox was actively involved in the discussion around the Kaminsky findings. Greg Ness who contributes here posts on his blog about the big picture in security. He also refers to my podcast with Cricket Lui.
Here is the link to the blog post by Greg Ness.
If you’re interested in adding to Greg’s conversation visit his blog and chime in.
August 7, 2008
Leaked Memo: DNS Security Flaw - Worst Security Hole Since 1997
Security guru Dan Kaminsky in Las Vegas revealed the full details of his discovered DNS security flaw which leaked this week.
We had post on this topic early and then a followup on the firewall problem around transaction id and PAT mode. This conversation has legs. Why? It’s fundamental to the infrastructure of companies and big networks.
That leak (leaked memo below) shows there is more underneath this DNS problem then first reported. Dan Kaminsky describes this new information and flow as the worst internet security hole since 1997.
Here is the leaked memo: This was originally was posted at www.matasano.com/log/1103/reliable-dns-forgery-in-2008-kaminskys-discovery/ then pulled down. Then reposted on beezari.livejournal.com
Reliable DNS Forgery in 2008: Kaminsky’s Discovery
from Matasano Chargen by ecopeland
0.
The cat is out of the bag. Yes, Halvar Flake figured out the flaw Dan Kaminsky will announce at Black Hat.
1.
Pretend for the moment that you know only the basic function of DNS — that it translates WWW.VICTIM.COM into 1.2.3.4. The code that does this is called a resolver. Each time the resolver contacts the DNS to translate names to addresses, it creates a packet called a query. The exchange of packets is called a transaction. Since the number of packets flying about on the internet requires scientific notation to express, you can imagine there has to be some way of not mixing them up.
Bob goes to to a deli, to get a sandwich. Bob walks up to the counter, takes a pointy ticket from a round red dispenser. The ticket has a number on it. This will be Bob’s unique identifier for his sandwich acquisition transaction. Note that the number will probably be used twice — once when he is called to the counter to place his order and again when he’s called back to get his sandwich. If you’re wondering, Bob likes ham on rye with no onions.
If you’ve got this, you have the concept of transaction IDs, which are numbers assigned to keep different transactions in order. Conveniently, the first sixteen bits of a DNS packet is just such a unique identifier. It’s called a query id (QID). And with the efficiency of the deli, the QID is used for multiple transactions.
2.
Until very recently, there were two basic classes of DNS vulnerabilities. One of them involves mucking about with the QID in DNS packets and the other requires you to know the Deep Magic.
First, QIDs.
Bob’s a resolver and Alice is a content DNS server. Bob asks Alice for the address of WWW.VICTIM.COM. The answer is 1.2.3.4. Mallory would like the answer to be 6.6.6.0.
It is a (now not) secret shame of mine that for a great deal of my career, creating and sending packets was, to me, Deep Magic. Then it became part of my job, and I learned that it is surprisingly trivial. So put aside the idea that forging IP packets is the hard part of poisoning DNS. If I’m Mallory and I’m attacking Bob, how can he distinguish my packets from Alice’s? Because I can’t see the QID in his request, and the QID in my response won’t match. The QID is the only thing protecting the DNS from Mallory (me).
QID attacks began in the olden days, when BIND simply incremented the QID with every query response. If you can remember 1995, here’s a workable DNS attack. Think fast: 9372 + 1. Did you get 9372, or even miss and get 9373? You win, Alice loses. Mallory sends a constant stream of DNS responses for WWW.VICTIM.COM. All are quietly discarded —- until Mallory gets Bob to query for WWW.VICTIM.COM. If Mallory’s response gets to your computer before the legitimate response arrives from your ISP’s name server, you will be redirected where Mallory tells you you’re going.
Obvious fix: you want the QID be randomly generated. Now Alice and Mallory are in a race. Alice sees Bob’s request and knows the QID. Mallory has to guess it. The first one to land a packet with the correct QID wins. Randomized QIDs give Alice a big advantage in this race.
But there’s a bunch more problems here:
*
If you convince Bob to ask Alice the same question 1000 times all at once, and Bob uses a different QID for each packet, you made the race 1000 times easier for Mallory to win.
*
If Bob uses a crappy random number generator, Mallory can get Bob to ask for names she controls, like WWW.EVIL.COM, and watch how the QIDs bounce around; eventually, she’ll break the RNG and be able to predict its outputs.
*
16 bits just isn’t big enough to provide real security at the traffic rates we deal with in 2008.
Your computer’s resolver is probably a stub. Which means it won’t really save the response. You don’t want it to. The stub asks a real DNS server, probably run by your ISP. That server doesn’t know everything. It can’t, and shouldn’t, because the whole idea of DNS is to compensate for the organic and shifting nature of internet naming and addressing. Frequently, that server has to go ask another, and so on. The cool kids call this “recursion”.
Responses carry another value, too, called a time to live (TTL). This number tells your name server how long to cache the answer. Why? Because they deal with zillions of queries. Whoever wins the race between Alice and Mallory, their answer gets cached. All subsequent responses will be dropped. All future requests for that same data, within the TTL, come from that answer. This is good for whoever wins the race. If Alice wins, it means Mallory can’t poison the cache for that name. If Mallory wins, the next 10,000 or so people that ask that cache where WWW.VICTIM.COM is go to 6.6.6.0.
3.
Then there’s that other set of DNS vulnerabilities. These require you to pay attention in class. They haven’t really been talked about since 1997. And they’re hard to find, because you have to understand how DNS works. In other words, you have to be completely crazy. Lazlo Hollyfeld crazy. I’m speaking of course of RRset poisoning.
DNS has a complicated architecture. Not only that, but not all name servers run the same code. So not all of them implement DNS in exactly the same way. And not only that, but not all name servers are configured properly.
I just described a QID attack that poisons the name server’s cache. This attack requires speed, agility and luck, because if the “real” answer happens to arrive before your spoofed one, you’re locked out. Fortunately for those of you that have a time machine, some versions of DNS provide you with another way to poison the name server’s cache anyway. To explain it, I will have to explain more about the format of a DNS packet.
DNS packets are variable in length and consist of a header, some flags and resource records (RRs). RRs are where the goods ride around. There are up to three sets of RRs in a DNS packet, along with the original query. These are:
*
Answer RR’s, which contain the answer to whatever question you asked (such as the A record that says WWW.VICTIM.COM is 1.2.3.4)
*
Authority RR’s, which tell resolvers which name servers to refer to to get the complete answer for a question
*
Additional RR’s, sometimes called “glue”, which contain any additional information needed to make the response effective.
A word about the Additional RR’s. Think about an NS record, like the one that COM’s name server uses to tell us that, to find out where WWW.VICTIM.COM is, you have to ask NS1.VICTIM.COM. That’s good to know, but it’s not going to help you unless you know where to find NS1.VICTIM.COM. Names are not addresses. This is a chicken and egg problem. The answer is, you provide both the NS record pointing VICTIM.COM to NS1.VICTIM.COM, and the A record pointing NS1.VICTIM.COM to 1.2.3.1.
Now, let’s party like it’s 1995.
Download the source code for a DNS implementation and hack it up such that every time it sends out a response, it also sends out a little bit of evil — an extra Additional RR with bad information. Then let’s set up an evil server with it, and register it as EVIL.COM. Now get a bunch of web pages up with IMG tags pointing to names hosted at that server.
Bob innocently loads up a page with the malicious tags which coerces his browser resolve that name. Bob asks Alice to resolve that name. Here comes recursion: eventually the query arrives at our evil server. Which sends back a response with an unexpected (evil) Additional RR.
If Alice’s cache honors the unexpected record, it’s 1995 —- buy CSCO! —- and you just poisoned their cache. Worse, it will replace the “real” data already in the cache with the fake data. You asked where WWW.EVIL.COM was (or rather, the image tags did). But Alice also “found out” where WWW.VICTIM.COM was: 6.6.6.0. Every resolver that points to that name server will now gladly forward you to the website of the beast.
4.
It’s not 1995. It’s 2008. There are fixes for the attacks I have described.
Fix 1:
The QID race is fixed with random IDs, and by using a strong random number generator and being careful with the state you keep for queries. 16 bit query IDs are still too short, which fills us with dread. There are hacks to get around this. For instance, DJBDNS randomizes the source port on requests as well, and thus won’t honor responses unless they come from someone who guesses the ~16 bit source port. This brings us close to 32 bits, which is much harder to guess.
Fix 2:
The RR set poisoning attack is fixed by bailiwick checking, which is a quirky way of saying that resolvers simply remember that if they’re asking where WWW.VICTIM.COM is, they’re not interested in caching a new address for WWW.GOOGLE.COM in the same transaction.
Remember how these fixes work. They’re very important.
And so we arrive at the present day.
5.
Let’s try again to convince Bob that WWW.VICTIM.COM is 6.6.6.0.
This time though, instead of getting Bob to look up WWW.VICTIM.COM and then beating Alice in the race, or getting Bob to look up WWW.EVIL.COM and slipping strychnine into his ham sandwich, we’re going to be clever (sneaky).
Get Bob to look up AAAAA.VICTIM.COM. Race Alice. Alice’s answer is NXDOMAIN, because there’s no such name as AAAAA.VICTIM.COM. Mallory has an answer. We’ll come back to it. Alice has an advantage in the race, and so she likely beats Mallory. NXDOMAIN for AAAAA.VICTIM.COM.
Alice’s advantage is not insurmountable. Mallory repeats with AAAAB.VICTIM.COM. Then AAAAC.VICTIM.COM. And so on. Sometime, perhaps around CXOPQ.VICTIM.COM, Mallory wins! Bob believes CXOPQ.VICTIM.COM is 6.6.6.0!
Poisoning CXOPQ.VICTIM.COM is not super valuable to Mallory. But Mallory has another trick up her sleeve. Because her response didn’t just say CXOPQ.VICTIM.COM was 6.6.6.0. It also contained Additional RRs pointing WWW.VICTIM.COM to 6.6.6.0. Those records are in-bailiwick: Bob is in fact interested in VICTIM.COM for this query. Mallory has combined attack #1 with attack #2, defeating fix #1 and fix #2. Mallory can conduct this attack in less than 10 seconds on a fast Internet link.
The repost of this leaked memo is here - go look at the discussion thread - worth reading
July 30, 2008
DNS SUCKS - Ok I Said It - Now What - Talk to Trusted Sources Until PAT mode is Fixed
A new flaw has sharpened the debate over how to come up with a long-term solution to the broader problem of the lack of security in the Domain Name System, which was invented in 1983 and was not created with uses like online banking in mind or huge internetworked enterprises and service providers.
When you see John Markoff of the NYTimes explaining to normal people that there are DNS problems you know the suckiness of DNS has gone mainstream.
I blogged yesterday that Cisco firewalls were affected and rendered the DNS patch useless. Well that was true, BUT it’s not just Cisco - it’s everyone. There is a bigger picture. DNS sucks. There is too much legacy and critical infrastructure that is more important then some sort of url rewrite and a hacking of a 16 bit port translation (or PAT - Port Address Translation). It’s called ‘industrial strength’ software. Companies like Infoblox and Nominum have big businesses because they took the DNS technology and scaled it with security. Can DNS vendors do more with it or has it reached it’s peak? Either way this DNS shit is a big problem for IT and network operators. It seem like they are chasing too many holes out there. Is it time to rip and replace. I’ll keep my official opinion to myself.
Ok I’ll say it DNS sucks! This latest firewall PAT issue rendering the DNS patch useless is the latest example.
Richard Kagan of Infoblox chimed in this morning. Richard said “DNS is just a protocol. The challenges really tem form how it is administered. Companies haven’t historically treated DNS as a strategic asset and this recent vulnerability will likely focus a few more minds on DNS security, architecture, design, implementation and adminstration as well as the implications of past decisions.”
Firewall PAT Problem with DNS Patch
Regarding the firewall (and PAT devices), customers don’t have to really worry about this - just do the patch and get the upgrade from Cisco and others. The big deal is that there is a ton of critical infrastructure built ontop of the feeble DNS. We are talking about big businesses, big service provider networks, big data networks powering mobile devices, cable companies, etc .. all that rely on DNS.
Regarding the Cisco firewall problem - wait for the upgrade. The way Cisco firewalls allocate source ports and rewrite source ports in their PAT devices is sequential. Although this is an issue, it’s not a straightforward issue. There are many instances where multiple devices that rely on those ports need to run in legacy mode. Cisco told me today that they are releasing an option so that PAT can be configured to use a random number generator for their PAT mode devices. Some other disagree and say that there are more secure ways to go than with Cisco.
Depending on the implementation the firewall PAT problem can negate the DNS patch. Cisco will be changing their PAT mode and moving to “hardening of the PAT feature”. The upcoming configuration option will give customers the ability to make the PAT mode more random. The question will remain does this make the devices more secure? The PAT mode is 16 bit (very breakable). I’m waiting to hear.
I really like Cisco, but this has to be a huge pain in the ass for them (or anyone in IT networking). Is this a case of stupid DNS tricks or is this a bigger issue.
I’ll say it again DNS Sucks. This firewall PAT issue isn’t just a Cisco problem. Others are affected. In fact a story out of the UK today shows it’s also Checkpoint.
I am thankful that Cisco spent the time to talk to me. They were great and very candid and transparent. Maybe they could do a guest post to explain more. Or better yet get Ralph Droms (he and Cricket Lui wrote the book on DNS).
This DNS stuff is a mess. A patch will be released in a few weeks that will change the PAT from sequential to random.
The bigger picture is that DNS needs to be replaced. I can’t wait to have some experts talk with me more on this. It’s worth getting to the bottom of this issue.
Cisco says advises their customers to make sure that their devices only talks to a trusted source until the patch comes out in a few weeks”.
If you’re a Cisco customer then go to this link for DNS best practices for dealing with this issue.
July 29, 2008
DNS Exploit Again - It Keep Going and Going - Feels like Energizer Bunny of Exploits
The exploit is still out there. Apple Still has not patched the DNS vunerability. This vunerability here has been running for weeks in the security circles. It feels like the energizer bunny of vunerabilities. People just get the damn patch done will you! Enough already. Ok- my rant is done.
On Slashdot Steve Shockley notes an article up at TidBITS on Apple’s unexplained failure to patch the DNS vulnerability that we have been discussing for a few weeks now. “Apple uses the popular Internet Systems Consortium BIND DNS server, which was one of the first tools patched, but Apple has yet to include the fixed version in Mac OS X Server, despite being notified of vulnerability details early in the process and being informed of the coordinated patch release date.”
More good stuff on Slashdot below:
Related posts from Slashdot
Kaminsky’s DNS Attack Disclosed, Then Pulled
Reverse engineering expert Halver Flake has recently mused on Dan Kaminsky’s DNS vulnerability. Apparently his musings were close enough to the mark to cause one of the Matasano team, who apparently already knew of the attack, to publish the details on the Matasano blog in a post entitled ‘Reliable DNS Forgery in 2008.’ The blog post has since been pulled, but evidence of it exists on Google and elsewhere. It appears only a matter of time now before the full details leak.” Reader Time out contributes a link to coverage on ZDNet as well.
Attack Code Published For DNS Vulnerability 204 comments
That didn’t take long. ZDNet is reporting that HD Moore has released exploit code for Dan Kaminsky’s DNS cache poisioning vulnerability into the point-and-click Metasploit attack tool. From the article: ‘This exploit caches a single malicious host entry into the target nameserver. By causing the target nameserver to query for random hostnames at the target domain, the attacker can spoof a response to the target server including an answer for the query, an authority server record, and an additional record for that server, causing target nameserver to insert the additional record into the cache.’ Here’s our previous Slashdot coverage.”
Patch DNS Servers Faster 143 comments
“Austrian CERT used data from one of their authoritative DNS server to measure the rate at which the latest DNS patch (source port randomization) is being rolled out to larger recursive name servers. While about half the traffic (PDF) they receive is now using source port randomization, their data suggest that this is due to ISPs who roll out such fixes immediately. The rate of patching has fallen to disappointingly low levels since. If your ISP isn’t patched, perhaps it is time to switch.” After details of the DNS vulnerability leaked, researchers |)ruid and HD Moore released attack code; ZDNet’s security blog has an analysis.