Broadband Developments

August 25, 2008

Cloud Computing - More Storms Ahead

Filed under: BroadDev — Tags: , , , , , , , , — Greg Ness @ 7:36 pm

The biggest threat to the promise of cloud computing to appear this summer wasn’t the failed trademark attempt by Dell, but rather brilliant research by a leading white hat security researcher. Dan Kaminsky discovered how a well-known and widespread vulnerability in DNS servers could be exploited in seconds and turn any one of millions of servers directing Internet traffic into a cybercrime gold mine in mere seconds.

Note: For those unfamiliar with cloud computing, or the delivery of software and other IT-related functionality as a service, you can read more at Archimedius. Some leading technology players involved or associated with cloud computing include: Google, Microsoft, Dell, VMware and Amazon.

As a result July and August saw unprecedented DNS media attention. Yet the discovery of a DNS exploit was only part of the story. Events soon unfolded that took the exploit from specialized security blogs (like Rational Survivability and Matasano, where the exploit leaked).

When the exploit inadvertently leaked (ahead of the disclosure timeline established to allow service providers ample time to patch their systems) the news quickly spread throughout more generalist blogs and even into mainstream media, including front page coverage in the NY Times referenced at Archimedius on July 31.

The Linux Journal published one of the best high level technical explanations of the exploit and why it matters. Despite the release of a patch and the heroic actions on the part of internet service providers, issues remain.

While the business press dwells on Dell, Microsoft, Google and a handful of key players making investments and strategic moves based on the eventuality of cloud computing, some of us in security and networking are all too aware of the storm clouds. You can read about the security issues at the newly established Infoblox DNS Security Center, with news, developments and resources hand-picked by leading experts.

Dan Kaminsky has openly labeled the patch just applied to protect the DNS vulnerability a temporary fix:

I listened to the Black Hat webcast today to grab as much info as I could on this subject. The biggest thing that I heard from the whole talk is that the patch fixes things to a reasonable point, but that long-term, there will have to be more work done to prevent the issue.

- Nathan McFeters, ZDNet

Unfortunately, it is likely that the DNS summer exploit story will fall back beneath the headlines in coming months; yet the vulnerability will still exist and it will likely require more patches on an ongoing basis. That will place an unprecedented level of demands on the management of the DNS infrastructure, the backbone of the Internet. That infrastructure is made up of millions of servers updated and managed manually. That is a serious problem.

An IDC report sponsored by Microsoft concluded that hardware costs were only a small fraction of the cost of operating a server (see page 5 for the IDC breakdown). Staffing expenses (management) and downtime constituted 75% of a server’s total cost of ownership, according to the April 2007 paper by Randy Perry and Al Gillen. More manual updates will impact both management and availability, the leading cost components before the DNS exploit discovery.

Internet integrity is a critical requirement for cloud computing. It requires a very high level of trust to use an online application for commercial and even personal uses. More management and availability challenges will further increase the cost of internet integrity while introducing new risks. The DNS exploit and the recognition that the recent patch is only a short term measure suggests that internet integrity may be more at risk than ever.

There’s More

A few days ago I discovered this YouTube piece by Cisco promoting green data centers and couldn’t help but to take notice of the points made about other server costs, including power. Cloud computing could suck up huge amounts of energy if cloudplexes are not virtualized properly and managed efficiently. For all of the opportunities posed by cloud computing it is obvious that substantial technical burdens remain before servers will follow the moon In pursuit of cheap electricity.

While low cost electricity and VMotion are important requirements for cloud computing, Internet integrity is the table stake: few will trust IT services from an unknown source. That is why the rise of cloud computing will depend upon the continued success and evolution of utility-grade core network services. Without network integrity the economics of software as a service will always be limited to low value consumers using low value services.

You can read my disclaimer at: About ARCHIMEDIUS.

August 7, 2008

Timeline of DNS Story - It’s Getting Out of Hand - Ok - So What’s the Solution

Filed under: BroadDev — Tags: , , , — John Furrier @ 11:48 am

The old saying if it bleeds it leads but this is getting out of hand. The DNS story is a real one, but lets move on to solutions - it’s clear that this as news is “beating this dead horse”. Enough of the gloom and doom. There is no doubt Dan Kaminsky is lovin the visability, but enough already on the problem. Time to move on to solutions.

Everyone knows DNS has a tons of holes but there are fixes and commercial software like Infoblox (now a sponsor of this blog - Thanks Infoblox).

Here is the timeline of this global conversation on BroadDev on the DNS story (with links externally to other credible sources): All of our contributors have chimed in on this topic.. very relevant.

July 22, 2008 - DNS Vunerability Has Now Gone Wild

July 23, 2008 - DNS Gone Wild - Exclusive Interview with Cricket Lui

July 24, 2008 - ZDNet Reports that DNS Exploit Code Has Been Published

July 24, 2008 - Cert: 60% of Recursive Name Servers UnPatched

July 25, 2008 - DNS Exploit is a Sleeping Zombie - Get the Patch

July 25, 2008 - Is Change Control Making the DNS Worse?

July 29, 2008 - DNS Exploit Again - It Keeps Going and Going - Feels like the Energizer Bunny of Exploits

July 29, 2008 - Breaking News: Now Patch Your Firewalls Because the DSN Patch Won’t Work With Leading Firewalls

July 30, 2008 - DNS SUCKS - Ok I Said It - Now What - Talk to Trusted Sources Until PAT mode is Fixed

July 31, 2008 - DNS Flaw Could Disrupt Unified Communications

July 31, 2008 - Kaminsky’s DNS Exploit Exposes Internet Core Challenge

August 5, 2008 - Black Hat 2008 - Look for Social Nets and DNS to Be Hot Topics

August 7, 2008 - Leaked Memo: DNS Security Flaw - Worst Security Hole Since 1997

These links are just the BroadDev coverage - This thing went supernova when John Markoff put it front and center in the NYTimes.

Time for solutions please - this as news is a dead horse.

Leaked Memo: DNS Security Flaw - Worst Security Hole Since 1997

Filed under: BroadDev, Security — Tags: , , — John Furrier @ 8:52 am

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

Also, Kim Zetter of WIred has a good writeup and coverage.

July 31, 2008

Kaminsky’s DNS Exploit Exposes Internet Core Challenge

Filed under: BroadDev — Tags: , , , , — Greg Ness @ 6:33 pm

John Markoff’s New York Times recent story on the DNS exploit will no doubt draw significant attention to what Cricket Liu called one of the most significant vulnerabilities of all time. A few days after the easy to launch exploit was published on the Internet, evidence of attacks were soon reported, even against security experts including HD Moore, who was apparently also victimized by vulnerable AT&T servers.

This problem is particularly troubling because this flaw is widely known and present in an estimated 11 million servers responsible for directing traffic throughout the Internet. Kaminsky showed how the flaw could be exploited in seconds, in effect revolutionizing the economics of identity theft.

While service providers have been patching the vulnerability with limited success, leaving millions of core servers exposed, the story gets worse. Recent news suggests that firewalls may have been impacted, including those widely deployed to protect servers. Compatibility issues between the DNS vulnerability patch and firewalls have been reported to create additional availability risks, which mean that patching could proceed even more slowly than before. Fixes are on the way.

This is clearly a fluid, dynamic situation and possibly a sign of the times as the Internet comes of age.

While news of vulnerabilities, exploits and the sheer magnitude of this problem spreads, perhaps there is a silver lining. Perhaps CIOs will start dealing with the core challenge inadvertently laid bare by Kaminsky: that the Internet has outgrown its caretakers.

A Historical Perspective

In the early 1990s the Internet quickly encircled the globe, and was soon transporting incomprehensible levels of traffic to mushrooming populations of endpoints. All the while we heard about how resilient the Internet was, because it was architected to survive a nuclear blast. After all, the nuclear blast was and still is the classic metaphor for total destruction. Yet no one ever considered the destructive power of an attack on the core of the Internet: integrity.

From an economic standpoint, the Kaminsky DNS exploit may be the Internet’s equivalent of a nuclear strike; yet it doesn’t require a PhD with years of training, specialized uranium enrichment equipment or even a sophisticated form of delivery. It can be launched in seconds by any one of tens of thousands of hackers from almost anywhere in the world.

A successful DNS exploit wouldn’t destroy the physical Internet per se, but would rather neutralize its core integrity, its ability to act as an ecommerce enabler. Security and availability are, after all, the Internet’s bricks and mortar.

The Core Challenge

As the Internet exploded onto the scene it became responsible for transporting more traffic to more locations between more applications. Managing the domain names and addresses for a mushrooming population of endpoints created a market for more than 11 million DNS servers solely responsible for directing that traffic.

Not only are many of those servers past their prime, the methods for managing them have simply not kept up with their increasingly strategic importance. Hence patching the DNS vulnerability won’t be accomplished in a timely manner for many critical servers, even though the patch is the only protection and it still isn’t a permanent fix.

The core challenge to the success of the Internet going forward from the “Kaminsky event” isn’t really about applying a single patch, although the DNS vulnerability is probably the most significant security threat to the Internet since its inception. The core challenge will be related to how easily this large population of core servers can be managed, secured, updated and tracked.

In essence, the meteor has landed again in the world of technology, and flexibility and control will come to the forefront as a requirement for IT survival.

If an unprecedented vulnerability only gets patched on 1/3 of name servers after 30 days of industry headlines and relentless warnings from security experts; just how well managed will be other critical aspects of Internet integrity? Is anyone naïve enough to think that this will be the last threatening exploit against a list of known vulnerabilities or even zero day attacks (against undiscovered vulnerabilities)?

Kaminsky has indirectly proven that the caretakers of the Internet are today wholly incapable of protecting it. And the widely deployed tools and technologies once depended on are no longer sufficient for keeping up with the mushrooming role, complexity and demands of ensuring the integrity of the Internet.

The Rise of Core Network Services

This recent cache poisoning exploit event is likely to be one of many, and even the patch isn’t a permanent fix. The only long term solution, therefore, will require the automation of core network services and the proliferation of grid computing capabilities throughout public and private networks populated with DNS servers.

Core network services must move from being a scattered, freeware and spreadsheet dominated role to an advanced, strategic function supported by a new generation of dedicated appliances that automate critical functions and ensure proper reporting, accuracy and delegation of duties in seconds instead of days or weeks.

Kaminsky may have exposed a critical vulnerability in the Internet; he may also have become a catalyst for a more secure, more available and more robust Internet. While the New York Times featured the DNS challenge and Kaminsky, it has made it obvious that the solution is far bigger than any single patch or personality. It has heralded a new age in core network services.

You can access technical DNS resources at Cricket Liu’s DNS Resources Page or at DNSstuff.

You can read my disclaimer at: About « ARCHIMEDIUS.

July 29, 2008

The Coming Cloud Computing Dogfight and Recent Implications

Steve Ballmer gets it. While he discusses a strategic interest in search, his head is really in the clouds and beyond (hello new operating system models); in the coming transformation many are calling cloud computing. I think he fully understands the cannibalization risk that Google is posing in the long term as it delivers increasingly sophisticated applications as a service.

Yet there is another storm now appearing on the horizon for cloud computing, in addition to some technology challenges facing the proliferation of virtualization in the data center. Collectively they represent substantial, multifaceted risks to the major technology players.

While the media buzz surrounding Google, Yahoo, VMware and Microsoft has been particularly deafening this summer -between exec changes and various staged media events- the real story beneath the headlines is about a long term positioning battle being played out today between Microsoft and a new generation of upstarts over the delivery of software and how it’s monetized.

The VMware versus Microsoft battle is really a precursor to the coming cloud computing dogfight between Microsoft and Google, because virtualization is a critical enabler of cloud computing. And cloud computing will make certain technologies and capabilities strategic in ways that weren’t possible when data centers were cumbersome and inflexible.

Hypervisor Economics 101

The hypervisor revolution ignited by VMware enables new levels of flexibility and efficiency for managing even the most complex data center infrastructure, with point and click server management and movement. Multiple virtual machines (servers) can share the same hardware, regardless of operating system and be easily moved from one hypervisor to the next.

That new level of flexibility can transform the economics of IT, by delivering servers and processing power on an as-needed basis, versus keeping all hardware powered on even if only for potential use. Yet electricity savings are only part of the value proposition.

By converting broad collections of servers running different dedicated operating systems into sets of VMs running on larger blade servers, IT departments can make changes with minimal effort and their racks and stacks can take up a fraction of the space as was previously required. That could mean major transformations for service providers and large enterprises delivering applications to growing sets of users and partners.

Reducing power consumption and increasing agility could set the stage for a substantial shift to cloud computing. Yet hurdles remain. It is likely that virtualization security concerns have played a factor in VMware’s recent lackluster execution in the data center in 2008. Virtualization security is one of the major hurdles to virtualization and cloud computing.

Virtualization Security

I’ve called the nature of many virtualized production deployments virtualization-lite, because data centers accept a lower payoff from virtualization (less flexibility, less consolidation, reduced savings on electricity, for example) in exchange for maintaining their security posture. Players like Blue Lane Technologies (my alma mater) and others will be among the first to see the transformation of the data center as they are capable of protecting fluid meshes of hypervisors, a limitation for many types of network security appliances. That limitation has boxed in many virtualization projects into hypervisor VLANs, which substantially erode the business case.

Two Promising I/O Front Ends

Moving VMs around across hardware can also tie up additional processing overhead, which makes VMotion less than ideal at this time. Companies like 3 Leaf Systems and Xsigo Systems are addressing these challenges. As they grow they’ll be yet another proof point of the expansion of virtualization beyond hypervisor-VLANS, as their products enable greater flexibility.

There are also compliance and change management issues that might slow virtualization down and inadvertently buy Microsoft enough time to establish an even larger foothold in the data center market. VMware has been very effective in leveraging its partner ecosystem in addressing these issues.

Yet cloud computing faces a fair share or risks, including the biggest security story of perhaps the last ten years: the Kaminsky DNS exploit.

The New Storm Cloud for Cloud Computing

The last few weeks have seen a massive explosion in commentary on the DNS exploit discovered by security researcher Dan Kaminsky, Director of Penetration Testing at IOActive. Since his discovery and an inadvertent series of blog posts DNS cache poisoning exploit attack code has been published; and yesterday a ZDnet blog by security expert Dancho Danchev sited DNS cache poisoning attempts reported from multiple sources. Recent research also notes that a majority of service providers have not patched their systems for the vulnerability.

Infoblox Vice President Cricket Liu, the author of DNS and Bind, called it one of the most significant vulnerabilities of all time. Ironically, he was on a DNS Security: Old Vulnerabilities, New Exploits webinar with Dan Kaminsky just days before the exploit code was published.

The DNS exploit threatens the core integrity of the Internet, as it allows hackers to redirect traffic from exploited servers to spoof sites where they can gather personal information and engage in identity theft on a scale we have yet to experience. That’s a bigger problem than when the “I Love You” virus inconvenienced computer users years ago; it is a major storm front for the future of cloud computing.

An untrusted Internet would be nothing short of an ecommerce disaster; its impact would go far beyond cloud computing. It would be a major disruption for the software as a service model, as well as many other business models that have grown with the Internet. That’s why I predict that core network services will become increasingly strategic to IT. The integrity of the network is about to matter even more than ever.

As reported previously at Archimedius, Google and others have made considerable strides in delivering software as a service. Their success could mean the eventual shrinking of the computer hard drive, the shrinking of the pre-installed software market, not to mention the shrinking of the shrink-wrapped software industry.

Microsoft seems to understand the risks and upside, and has focused on “search” as a strategic roadmap issue, along with their recent Hyper-V attack on VMware. Yet the real Microsoft adversary is Google-driven cloud computing, and the spoiler issue for all of them is an untrusted Internet. Until a few months ago, few saw this issue coming. But now the vulnerability is known, exploits have been published and apparently attacks are now being launched.

You will be hearing much more about these issues, players and risks in coming weeks and probably months as Google and Microsoft prepare for battle in the skies.

You can read my disclaimer at: About ARCHIMEDIUS.

July 24, 2008

CERT: 60% of Recursive Name Servers Unpatched

Based on a recent CERT Report published today at least 2/3 of Austrian recursive name servers have not yet been patched.

The conclusions are rather grim so far – more than two thirds of the Austrian Internet’s recursive

DNS servers are unpatched while at the same time the upgrade adoption rate seems rather slow.

Our findings are matched by the observations of Alexander Klink of Cynops GmbH2 who analyzed

the results of the online vulnerability test on Dan Kaminsky’s doxpara3 site.

- From Patching Nameservers: Austria Reacts to VU#800113

By Otmar Lendl and L. Aaron Kaplan July 24, 2008

It looks like Austria is NOT an anomaly but is rather symptomatic of many other countries behind on patching the DNS vulnerability and now exposed by the release of attack code. As the paper notes further on page 13, Alexander Klink had similar findings for doxpara.com queries.

Despite multiple warnings and the publication of exploit code it looks like successful attacks on the Internet are eminent.

From Cricket Liu’s exclusive Archimedius interview:

DNS experts agree that this vulnerability provides a way for a hacker to poison the cache of an unpatched, open recursive name server in less than a minute.

You can read my disclaimer at: About « ARCHIMEDIUS.

ZDNet Reports that DNS Exploit Code Has Been Published

Filed under: BroadDev — Tags: , , , , , , — Greg Ness @ 9:25 am

A few hours ago Ryan Naraine at ZDnet reported that DNS vulnerability attack code has been published.

The urgency to patch Dan Kaminsky’s DNS cache poisoning vulnerability just went up a few notches.

Exploit code for the flaw, which allows the insertion of malicious DNS records into the cache of the target nameserver, has been added to Metasploit, a freely distributed attack/pen-testing tool.

According to Metasploit creator HD Moore (left), who teamed up with researcher |)ruid to create the exploit, a DNS service has also been created to assist with the exploit.

Ryan Naraine, ZDnet July 23 2:55PM

You can read Cricket Liu’s breaking interview published this AM or attend a prescient webinar featuring Liu and Dan Kaminsky that was recorded just days ago. The original Archimedius coverage from July 22 contains links to various trade articles and resources.

You can read my disclaimer at: About « ARCHIMEDIUS.

July 23, 2008

DNS Vulnerability Gone Wild: Exclusive Cricket Liu Interview

Earlier this week the blogosphere and the press exploded with news about the inadvertent release of an exploit targeting a widely acknowledged vulnerability in about more than 11 million DNS servers. These servers are critical to the security of the Internet, as I mentioned yesterday at: DNS VULNERABILITY NOW IN THE WILD.

I found out about the release yesterday from Cricket Liu, the author of the definitive book on DNS, called DNS and BIND (published by O’Reilly). Cricket was on a DNS Security webcast with Dan Kaminsky a few days ago, and had then just spoken with Dan about the inadvertent release of the DNS vulnerability along with a researchers discovery of how an exploit could be successfully launched.

This of course puts extra pressures on administrators to patch their own DNS servers. If they dont patch they expose users to cache poisoning attacks capable of redirecting them to spoof sites designed to collect personal information. This vulnerability, now in the wild, could turn the Internet into a hackers gold mine of passwords, account numbers and other identity theft resources.

Dan had planned to announce his findings, (discovered six months ago) at an upcoming (August) Black Hat conference, allowing administrators around the world adequate time to patch their DNS servers ahead of his presentation. Since the cat is now out of the bag according to Wired and other sources.

I decided to ask Cricket to get his take:

July 22, 2008 Interview with Cricket Liu

Q: If you were to rank Kaminsky’s recently disclosed DNS vulnerability, how would you rank it?

I assume you’re asking me to rank it among other DNS vulnerabilities. It’s certainly Number 1 today. It’s probably the All-Time Number 1, too, since we’ve always had solutions to address other DNS vulnerabilities. With this one, we have new versions of name servers that make the attacks more difficult to carry out, but no outright solution that’s been agreed on as of yet.

Q) How does it compare to other known vulnerabilities in terms of scope and potential impact and ease of exploit?

Well, the Kashpureff attack, back in July 1997, was easier to exploit. Name servers lacked mechanisms to detect unrelated additional data then, and almost all were open to recursive queries, so Kashpureff really had his pick of targets and could poison their caches almost instantly. It’s fortunate that he did so only to protest unfair business practices, not for his own gain. We didn’t see another exploit of that particular implementation flaw before implementations were fixed and name servers upgraded.

The current vulnerability is much broader in scope. There are many more name servers on the Internet today than there were in 1997, of course. Odds are the vulnerability is now widely known among the hacker community, after being revealed in a couple of security blogs yesterday. And if the anecdotal evidence I’m hearing is correct, many administrators aren’t upgrading their name servers to patched versions.

Q: For anyone who says that this latest DNS vulnerability is “business as usual” what would you tell them?

To dust off their resumes.

Seriously, this is a Big Deal. DNS experts agree that this vulnerability provides a way for a hacker to poison the cache of an unpatched, open recursive name server in less than a minute. Dan Kaminsky did everything he could to buy us time to patch our name servers. The Internet Systems Consortium and a whole lotta vendors—including Infoblox—worked hard to make sure you had patched code available the day of Dan’s announcement. If you stick your head in the sand and ignore the warnings, and a hacker writes code that combs the Internet for vulnerable, open recursive name servers, poisoning the A record for windowsupdate.microsoft.com, say, and you end up with legions of pwned PCs, guess who’ll get the blame.

Q: What is the nature of this vulnerability that makes it noteworthy compared to previous vulnerability and patch announcements?

It’s notable because there are so many hosts affected (from our surveys with The Measurement Factory, there are about 11 million name servers on the Internet) and because the consequences of a successful compromise are so high. If your name server’s cache is poisoned, you could find (but might never notice) that all of your mail to a business partner is re-routed through a mail server-in-the-middle, where it’s copied for later perusal and then sent on to unwitting recipients. Your traffic to critical web sites could be intercepted, and login names, passwords, and credit card numbers sniffed and recorded.

Q: Why do you think some security pros don’t find such a significant vulnerability alarming?

Some aspects of the vulnerability are familiar. We’ve known about attacks involving additional data since 1997. We’ve known the message ID in DNS messages isn’t long enough for a long time, too. But it’s not the components of the attack that are important. It’s that you can assemble them into a very effective attack against recursive name servers. Or a killer robot—your choice.

Q: Why do you think that a number of administrators are hesitating to patch their DNS systems?

Well, it can be a lot of work if you’re running plain vanilla BIND name servers on UNIX or Linux. And Amit Klein of Trusteer found a flaw in the implementation of BIND’s pseudo-random number generator (used to generate message IDs) last year. Some administrators may think that the patches they applied for that vulnerability will protect them from this one. (They won’t.)

NOTE: Cricket also has a DNS Best Practices micro-site at www.infoblox.com.

You can read my disclaimer at: About « ARCHIMEDIUS.

July 22, 2008

DNS Vulnerability in the Wild

Filed under: BroadDev — Tags: , , , , , , — Greg Ness @ 11:19 am

There are about 11 million servers using the Internets Domain Name System (DNS) to coordinate traffic across the Internet to their proper destinations. About 6 months ago Dan Kaminsky, Director of penetration testing at IOActive, discovered a way to exploit long-known DNS vulnerabilities to easily implement cache poisoning attacks that can compromise the integrity of the Internet. A few highlights from Computerworld’s coverage of the DNS flaw follow:

“DNS servers are responsible for routing all Internet traffic to their correct destinations. The so-called cache-poisoning vulnerability that Kaminsky discovered could allow attackers to redirect Web traffic and e-mails to systems under their control, according security researches. The flaw exists at the DNS protocol level and affects numerous products from multiple vendors.”

Jaikumar Vijayan, Computerworld, July 17

Word of the DNS flaw was made public earlier this month thanks to a collaborative update from the likes of Cisco and Microsoft. Details were withheld in order to give administrators time to patch their systems.

The flaw would allow hackers to launch unlimited queries against DNS servers without being detected, allowing them to run simple random number guesses to collect transaction IDs and other critical information that could be used to redirect web traffic to spoof sites. These kinds of attacks can be successful, and in turn, detrimental to an organization’s web presence, in mere seconds.

According to Kaminsky, a weakness exists in a transaction identification process that the DNS protocol uses to determine whether responses to DNS queries are legitimate or not. DNS messages include what are supposed to be random identification numbers, but the problem, according to Kaminsky, is that only about 65,000 different values are currently being used as identifiers. And in reality, the process of assigning the identifiers to packets isn’t especially random and can be guessed, he said.

Jaikumar Vijayan, Computerworld, July 17

While some have speculated whether or not the vulnerability is old news, Mike Fratto had recently delivered a stern warning to patch all DNS servers in his InformationWeek blog:

Since the CERT announcement yesterday about the new vulnerabilities in DNS, there has been a lot of speculation that what Dan Kaminsky found is old news. Thomas Ptacek from Matasano, in an interview with Nathan McFeters at ZDNet, pretty much dismisses the vulnerability as old news and therefore unimportant. That sentiment is echoed on mailing lists and message boards. But in an e-mail today, Kaminsky confirmed that what he found is something very new. I believe him. Forget the arguments. Go patch your DNS servers. Now.

Mike Fratto, InformationWeek, July 9

Making matters worse, a slip-up between security researchers discussing the cache poisoning attack via blog exchanges has inadvertently released details of how to launch an exploit in the wild, making it only a matter of time before real attacks appear.

Here is the coverage from ZDnet yesterday afternoon: Has Halvar figured out super-secret DNS vulnerability?

Clearly irked by a demand request from Kaminsky and others to avoid speculating on the details of the flaw until the patch is fully deployed, Flake (left) published a reliable method to forge and poison DNS lookups.

Ryan Naraine, ZDnet, July 21

You can expect to read much more about this in the coming days, if not hours.

You can find out even more from this recent webinar hosted by Dan Kaminsky and Infoblox VP of Architecture Cricket Liu: DNS Security: Old Vulnerabilities, New Exploits. It is sponsored by Infoblox, and is perhaps one of the most current and informative recorded events on the topic. You can also read more at Kaminsky to discuss DNS flaw at Black Hat sponsored webcast.

For more background, you can read the following articles:

internetnews.com: Who is Really at Risk From the DNS Flaw?

internetnews.com: Is DNSSEC the Answer to Internet Security?

InformationWeek blog: Stop Arguing and Patch your DNS

Computerworld: DNS flaw discoverer says more permanent fixes will be needed

You can read my disclosure at: About Archimedius .

DNS Vulnerability Has Now Gone Wild

There are about 11 million servers using the Internet’s core Domain Name System (DNS) protocol to coordinate traffic across the Internet to their proper destinations. About 6 months ago Dan Kaminsky, director of penetration testing at IOActive, discovered a way to exploit long-known DNS vulnerabilities to easily implement “cache poisoning” attacks that can compromise the integrity of the Internet.

A few highlights from Computerworld’s coverage of the DNS flaw follow:

DNS servers are responsible for routing all Internet traffic to their correct destinations. The so-called cache-poisoning vulnerability that Kaminsky discovered could allow attackers to redirect Web traffic and e-mails to systems under their control, according security researches. The flaw exists at the DNS protocol level and affects numerous products from multiple vendors.

Jaikumar Vijayan, Computerworld, July 17

Word of the DNS flaw was made public earlier this month thanks to a collaborative update from the likes of Cisco and Microsoft. Hackers could launch unlimited queries against DNS servers without being detected, allowing them to run simple random number guesses to collect transaction IDs and other critical information that could be used to redirect web traffic to spoof sites.

These kinds of attacks can be successful, and in turn detrimental to an organization’s web presence, in mere seconds.

According to Kaminsky, a weakness exists in a transaction identification process that the DNS protocol uses to determine whether responses to DNS queries are legitimate or not. DNS messages include what are supposed to be random identification numbers, but the problem, according to Kaminsky, is that only about 65,000 different values are currently being used as identifiers. And in reality, the process of assigning the identifiers to packets isn’t especially random and can be guessed, he said.

Jaikumar Vijayan, Computerworld, July 17

While some have speculated whether or not the vulnerability is old news, Mike Fratto had recently delivered a stern warning to patch all DNS servers in his InformationWeek blog:

Since the CERT announcement yesterday about the new vulnerabilities in DNS, there has been a lot of speculation that what Dan Kaminsky found is old news. Thomas Ptacek from Matasano, in an interview with Nathan McFeters at ZDNet, pretty much dismisses the vulnerability as old news and therefore unimportant. That sentiment is echoed on mailing lists and message boards. But in an e-mail today, Kaminsky confirmed that what he found is something very new. I believe him. Forget the arguments. Go patch your DNS servers. Now.

Mike Fratto, InformationWeek, July 9

Making matters worse, a slip-up between security researchers discussing the cache poisoning attack via blog exchanges has today inadvertently released details of how to launch an exploit in the wild, making it only a matter of time before real attacks appear.

You can expect to read much more about this in the coming days, if not hours.

You can find out more from this recent webinar hosted by Dan Kaminsky and Infoblox VP of Architecture Cricket Liu: DNS Security: Old Vulnerabilities, New Exploits. It is sponsored by Infoblox, and is perhaps one of the most current and informative recorded events on the topic. Ironically, today is my first day at Infoblox.

For more background, you can read the following articles:

internetnews.com: Who is Really at Risk From the DNS Flaw?

internetnews.com: Is DNSSEC the Answer to Internet Security?

InformationWeek blog: Stop Arguing and Patch your DNS

Computerworld: DNS flaw discoverer says more permanent fixes will be needed

HowStuffWorks.com: How Domain Name Servers Work

Wikipedia: DNS cache poisoning

+++++You can read my disclosure at: About Archimedius. +++++

Powered by WordPress