Arbor Networks found that DDoS attack size (in gigabits) nearly doubled in 2008 from the previous year.
(Credit: Arbor Networks)
Internet service providers now spend most of their IT security resources detecting and mitigating distributed denial-of-service attacks, concludes a report from Arbor Networks.
The fourth edition of the Worldwide Infrastructure Security Report, released Tuesday, was based on how 70 lead security engineers responded to 90 questions. As in the previous three reports, ISPs reported attacks where their networks were overloaded with packets, what's called a distributed denial-of-service (DDoS) attack. However, this year, the ISPs indicated the attacks were not only larger in size but that most of them were stretching the upper limits of their security resources in order to deal with such attacks.
Rob Malan, founder and chief technology officer of Arbor Networks, said the DDoS attacks seen this year broke the 40-gigabit barrier, nearly double the volume of last year's attacks. He warned that if next year's attacks again double in size, "most carriers will be unable to deal with those attacks."
In assessing the attacks, Arbor Networks found "brute force," a catch-all term, was the dominant method used. The security firm looked at traditional means of DDoS--syn flood, udp flood--as well as anything else that artificially created network congestion. Malan told CNET News that despite the massive size, the attacks themselves demonstrated "little sophistication" and were simply "trying to overwhelm network bandwidth."
One consequence of this method was that upstream providers of the targets were increasingly being affected. "If an attacker takes out capacity of (the upstream) routers you're (also) starving the target," he said. Malan said attackers were also using reflective attacks, which use different pieces of DNS structure to redirect traffic away from a target.
While flood-based attacks represented 42 percent of the attacks reported, followed by protocol exhaustion-based at 24 percent, Arbor Networks also saw a sharp increase this year in application-based attacks, which accounted for 17 percent of the attacks.
Malan explained that with application-based attacks, bot-infected computers worldwide make connections to a targeted site, then "use an application protocol to deliver a perfectly valid request, not a vulnerability, not something that an IDS or other type of firewall would necessarily flag." For example, a botnet might instruct its zombie computers worldwide to do a back-end query off a database. "By itself it's not bad, but if you have multiple such requests, then you tie up the application--in this case database--resources on the back end," he said.
The report does contain some good news. Arbor Networks found detection and mitigation of these attacks to be increasing as well. Fifteen percent of the respondents said, on average, they can mitigate an attack within 10 minutes of detection. However, 30 percent said mitigation still takes them over an hour.
But finding the criminals responsible for these attacks is not a high priority. Arbor Networks found that ISPs have little time to involve law enforcement. "It's hard on carriers," said Malan. "They get paid on traffic, not to do forensic analysis. So it's hard from their perspective to make the economics work."
(Credit:
Arbor Networks)
Programming note: As of Friday, July 11, 2008, Defense in Depth will now only carry my weekly column plus additional commentary on the state of computer security. My security news blogs will instead appear under the CNET News Security banner going forward. And my CNET News Security Bites podcasts can be found at here. All of these can be subscribed to via RSS.
While security researcher Dan Kaminsky still won't comment on the specific nature of a flaw within the Domain Name System--for fear that criminal hackers might exploit it before the worldwide network of name servers worldwide and client systems that contact them can be updated--he nonetheless went public on July 8 with some details, backed by simultaneous patch releases from Microsoft, Cisco, and others.
There have been other multiparty patch releases, but never has there been one on such a massive scale. It took someone with the gravitas and reputation of Kaminsky to pull together the affected parties.
Dan Kaminsky at DefCon in 2006.
(Credit: Declan McCullagh/CNET News)What he and others he took into his confidence did over the last few months was not only responsible but extraordinary. The flaw that Kaminsky discovered could allow criminal hackers to guess the transaction ID of any request to a DNS server for a particular domain, such as one used for a bank or an e-commerce site, and then redirect that request to another site, a phishing site. It would do so silently, evading most anti-phishing technology because the change would be made not at the desktop level but at the DNS server itself. Certainly this is big, and certainly one would want to get the news out as soon as possible--but Kaminsky took the time to inform the proper vendors and authorities and, only after they were ready with patches, did he disclose some of what he'd discovered.
That isn't to say what Kaminsky did was perfect; he himself admits there are lessons to be learned and improved upon the next time this happens. Whether you agree with the severity of the flaw Kaminsky disclosed last Tuesday, I do think all future vulnerability disclosures could benefit from his example.
Kaminsky, director of penetration testing at IOActive, is no stranger to vulnerabilities. Over the years he's found a fair share and says that in the case of the DNS flaw he wasn't looking for it. In this week's Security Bites podcast, Kaminsky told me that after three days of testing he knew he had something important. At that point, early in 2008, he had a few options.
One was to tell the vendor (or, in this case, vendors) directly. Ari Takanen of Codenomicon told me he prefers that security researchers keep vulnerabilities between them and the vendor. Vendors, Takanen said, have their own development cycles, and for a researcher to burst into a room or go public and demand that everyone work on his or her vulnerability is unrealistic. While Kaminsky was willing to work with the vendors, he wasn't willing to give them forever.
Another option was to sell the vulnerability to a third party like TippingPoint's Zero Day Initiative. ZDI acts as the middleman, talking with the vendor and communicating with the researcher. The advantage here is that a researcher with no connections to the affected vendor can communicate the problem clearly.
ZDI has been credited with several vulnerabilities, such as those announced by Apple and Microsoft. Kaminsky has no qualms with those who opt for this method, although he said he didn't understand why a company would pay for this information. (I know the answer: TippingPoint uses the vulnerability data it purchases to protect its customers first, thereby giving it a competitive advantage in the vulnerability assessment space).
Another option for Kaminsky was to go public, to announce the vulnerability and publish details, including an exploit, on, say, Bugtraq. A few researchers have gone this route, but often as a last resort after getting a cold shoulder from the vendor. A few researchers have published flaw details first without contacting anyone, taking both the public and the vendor by surprise. But such moves are unwise since they give the bad guys all the information they need while everyone is vulnerable.
Finally, as Kaminsky reminded me, there's the option of selling your vulnerability to the criminal underside of the Internet.
With the DNS flaw, Kaminsky was in a very weird position. What he found wrong with DNS, the servers that translate a Web site's common name to its IP address, wasn't just within one vendor's product, it cut across various products, from various vendors. He said he consulted with DNS expert Paul Vixie, and together they decided they had to convene a meeting, and do so within a few weeks of the discovery.
That meeting occurred at Microsoft's Redmond, Wash., headquarters on March 31, 2008. There, representatives from 16 vendors sat down and listened to Kaminsky's pitch. After deciding this was a real and exploitable problem, the vendors decided they would have little choice but to agree to release simultaneously their respective patches.
At some point, July 8, 2008, was agreed upon as the date, perhaps because it coincided with Microsoft's monthly Patch Tuesday. The date was significant in other ways: for example, it fell roughly 30 days before Kaminsky was scheduled to speak at Black Hat in Las Vegas.
Between March and July, there was considerable back and forth among Kaminsky and the vendors, and then, as the date neared, he decided to share the details with a few others.
In retrospect, Kaminsky confessed that he really should have told more people. He had gone through great pains to inform the DNS community, the specific vendors, and few researchers. He did so to keep word from getting out.
But within hours of making his announcement, Kaminsky faced a chorus of public ridicule by other security researchers, most hearing about the flaw for the very first time. The complaints, at times, trivialized the announcement, with fellow researchers citing that similar claims had been made against DNS 3 to 10 years before or even longer. Some suggested Kaminsky was simply trying to advertise his talk at Black Hat next month.
Most vocal was Matasano Security researcher Thomas Ptacek, who blogged his doubts. But Kaminsky called Ptacek and he retracted his comments. He now says, "Dan has the goods. Patch now, ask questions later."
Whether or not Kaminsky knocks the socks off of everyone at Black Hat seems considerably less important than the responsible nature of his disclosure. He could have, as Ptacek notes, made thousands of dollars off this DNS thing. Instead, Kaminsky has set a high mark for future disclosures. He has changed Internet security, and done so for the better of us all.
On Thursday, Check Point Software Technologies released updated versions of all its ZoneAlarm products, addressing an incompatibility with a patch Microsoft released earlier this week.
The fix requires ZoneAlarm users to download the latest version, 7.0.438.000, from its site. A reboot is required to complete installation.
Since Tuesday, ZoneAlarm customers have complained that access to the Internet was denied after installing MS08-037, a patch designed by Microsoft to correct a vulnerability in both the client and server Domain Name System packages within Windows. Earlier on Tuesday, a security researcher announced a massive, multi-vendor patch release to address a fundamental flaw in DNS that could allow attackers to spoof IP addresses.
Workarounds included uninstalling MS08-037, changing ZoneAlarm's settings from high to medium, or temporarily using the Windows Firewall instead.
Check Point provided no additional comments about the cause of the outage.
Check Point Software Technologies, maker of ZoneAlarm, on Wednesday said it is working with Microsoft to resolve an issue with one of the patches within the software maker's July 2008 Patch Tuesday release.
At issue is the Microsoft Update KB951748 (MS08-037) from Microsoft, which addresses the flaw in DNS made public on Tuesday by security researcher Dan Kaminsky.
For ZoneAlarm customers who have automatic update selected for Windows Updates, and whose ZoneAlarm Internet security level is set to "high," they will experience a loss of Internet connectivity upon reboot.
ZoneAlarm users without automatic update may wish to wait to install the update until the matter is resolved.
For those who have already installed the patch, Check Point recommends users remove Microsoft Update KB951748 from their systems. Detailed instructions for doing this can be found here. Another option is to lower the ZoneAlarm Internet security setting to "medium," although Check Point doesn't recommend that.
On Tuesday, security researcher Dan Kaminsky of IO Active calmly explained in a conference call with security reporters how he first stumbled upon a pervasive flaw deep within the Domain Name System (DNS), a series of servers used to translate common Internet names to IP addresses. Kaminsky said he wasn't even looking for a security vulnerability. What he found, however, could explain how criminal hackers have been able to redirect DNS queries recently.
Dan Kaminsky at DefCon in 2006
(Credit: Declan McCullagh / CNET News)What he did next is remarkable: he waited. Instead of selling the vulnerability to a company like TippingPoint through its program Zero Day Initiative, wherein the company would then handle the vendor contact and resolution, Kaminsky took the responsible step of contacting the most affected vendors himself. He discussed with them how best to address the flaw that resides at the most fundamental level of how the DNS currently works.
Together, Kaminsky and the vendors set a date of July 8 in which they would collectively announce and roll out the patches. In the meantime, additional steps were taken, such as notifying US-CERT (United States Computer Emergency Readiness Team) and CERTs in other nations, to minimize the possibility of criminals using the July 8 announcement to cause DNS havoc.
At Tuesday's press conference, Kaminsky refused to provide details about the flaw, preferring to give additional vendors and administrators affected at least 30 days to create or implement the patches.
But within the conference call, during the question-and-answer session, some details and clarifications emerged.
DNS servers translate a popular name such as CNET.com into its numeric IP address. There are 13 principal servers and many subservers located throughout the world to speed the process of IP resolution. Usually a DNS look-up query is assigned a random translation ID, but Kaminsky observed that when a vulnerable DNS server is able to perform recursive DNS queries, it was possible to guess the transaction ID and redirect the result.
DNS queries currently offer a transaction ID that is one of 65,000 possible values. The ID is supposed to be there on every legitimate response. But Kaminsky and others noticed that some weren't particularly random. What has been discovered is that 65,000 is just not enough, said Kaminsky.
Every query has a transaction ID between 0 and 65,000, and the reply must contain the transaction ID. Thus, it may be possible to guess these transaction ID values in advance and insert a malicious server as the authoritative DNS server for a popular bank or e-commerce site.
After applying the patch, Kaminsky said, the transaction ID would now contain the correct transaction ID plus the correct source port, a random identifier located at a different layer in the IP packet. He said when discussing remediation of the flaw the only place they could go for additional randomness within the current infrastructure was the source port. This would increase the size of the translation ID from, say, 16 bits to 32 bits, he said.
The IP protocol has a system for sending small messages and there are various headers. He said think of the source port in this case as a return address on an envelope; it's extra data in addition to the message you are sending. He said you can sign your name on the letter itself. You can also sign your name on the envelope as well. The patch does something similar with the translation IDs.
Kaminsky said he will release more details in time for Black Hat 2008, to be held August 7 and 8 in Las Vegas.
In the meantime he's set a high standard for responsible vulnerability disclosure.
Following a security researcher's announcement of a massive, multivendor patch release, Cisco on Tuesday issued a patch for its products vulnerable to DNS cache-poisoning attacks.
In an advisory, Cisco cited its IOS software, Network Registrar, Application and Content Networking System, and Global Site Selector used in combination with Cisco Network Registrar among those directly affected by the vulnerability announcement.
Earlier Tuesday, Microsoft released its patch for the same DNS vulnerability.
A security researcher has responsibly disclosed a fundamental flaw within the Domain Name System (DNS), the addressing scheme behind the common names used on the Internet. Currently, it may be possible to guess these transaction ID values in advance and assert a malicious server as the authoritative DNS server for a popular bank or e-commerce site. The news was announced Tuesday.
Dan Kaminsky, director of penetration testing services for IO Active, found the DNS flaw earlier this year. Rather than sell the vulnerability, as some researchers have done, Kaminsky decided instead to gather the affected parties and discuss it with them first. Without disclosing any technical details, he said, "the severity is shown by the number of people who've gotten onboard with this patch."
He declined to name the flaw as that would give away details.
On March 31, Kaminsky said 16 researchers gathered at Microsoft to see whether they understood what was going on, as well as what would be a fix to affect the greatest number of people worldwide, and when they would issue this fix.
Toward addressing the flaw, Kaminsky said the researchers all decided to conduct a synchronized, multivendor release. As part of that, Microsoft in its July Patch Tuesday released MS08-037. Cisco Systems, Sun Microsystems, and BIND are also expected to roll out patches later on Tuesday.
The coordinated release covers a wide variety of vendors. Art Manion of US-CERT (United States Computer Emergency Readiness Team) said vendors with DNS servers have been contacted, and there's a longer list of additional vendors that have DNS clients. That list includes AT&T, Akamai, Juniper Networks, Netgear, Nortel, and ZyXEL. Not all of the DNS client vendors have announced patches or updates. Manion also confirmed that other nations with CERTs have also been informed of this vulnerability.
Dan Kaminsky has provided a free DNS checker on his Web site.
(Credit: Doxpara.com)Most systems will be patched automatically. However, those that are not will have 30 days to be patched manually before additional details are made public.
This issue also affects Internet service providers used by home users. In the coming days, ISPs are expected to apply the patch to their systems. Hardware routers used by home users should not be affected.
Kaminsky said he will release details in time for Black Hat 2008, on August 7 and 8 in Las Vegas. However, Microsoft in its security bulletin said its patch uses strongly random DNS transaction IDs, random sockets for UDP (User Datagram Protocol) queries, and updates the logic used to manage the DNS cache."
Kaminsky did confirm that the patches released today will increase DNS randomness: "Where we had 16-bit before, we now have 32 bits."
To check to see if your system is vulnerable, Kaminsky has provided a DNS checker.
Update 3:15 p.m. PDT: The headline and opening sentence have been changed to clarify that VeriSign is expanding its Project Titan initiative to strengthen and secure Net infrastructure.
On Thursday, VeriSign announced plans to increase the level of security within Project Titan, a global initiative to expand the infrastructure of the Internet to anticipate future demand brought by increased e-commerce transactions.
In its announcement, VeriSign said that it is going to spend more than the $100 million-plus initially budgeted.
One of the goals of Project Titan is to increase the overall capacity of the Internet to sustain a predicted increase in the daily load of Domain Name Server (DNS) queries. DNS is how a domain's common name (say CNET.com) is converted to its Internet address consisting of numbers. It also allows major companies to move their Internet-facing servers yet keep the common name for its customers.
Currently the DNS system handles about 400 billion queries today; VeriSign predicts a load of 4 trillion queries by 2010. To do this, Project Titan will better distribute the current infrastructure so that the .com and .net systems will have greater redundancy and reduced latency. This should improve the end-user experience for users by reducing bottlenecks and increasing speed despite ever increasing demand. It will also introduce more security to prevent attacks on the DNS system.
- prev
- 1
- next
