Posts Tagged Kaminsky
Is the Internet Really Ready for Prime Time?
Fundamental elements of Internet infrastructure have been in the news lately, and it hasn’t been a pretty picture.
Last month a serious security problem with the Domain Name System (DNS) was described by Dan Kaminsky at the Black Hat/DefCon show. I took at shot at describing the vulnerability here when the news first broke in July. Now Kim Zetter of Wired Magazine lays out another scary possibility – large scale interception of internet traffic simply by exploiting the properties of Border Gateway Protocol (BGP), the way large networks exchange traffic on the Internet:
http://blog.wired.com/27bstroke6/2008/08/revealed-the-in.html
Apparently this weakness has been known for years. But in the past it was assumed that it would result in the traffic not reaching its destination, therefore making it obvious something was wrong. But Anton Kapela and Alex Pilosov have demonstrated a tweak that forwards the traffic to its proper destination after the hijack, making the interception hard to detect without detailed analysis:
But in the past, known IP hijacks have created outages, which, because they were so obvious, were quickly noticed and fixed. That’s what occurred earlier this year when Pakistan Telecom inadvertently hijacked YouTube traffic from around the world. The traffic hit a dead-end in Pakistan, so it was apparent to everyone trying to visit YouTube that something was amiss.
Pilosov’s innovation is to forward the intercepted data silently to the actual destination, so that no outage occurs.
Ordinarily, this shouldn’t work — the data would boomerang back to the eavesdropper. But Pilosov and Kapela use a method called AS path prepending that causes a select number of BGP routers to reject their deceptive advertisement. They then use these ASes to forward the stolen data to its rightful recipients.
“Everyone … has assumed until now that you have to break something for a hijack to be useful,” Kapela said. “But what we showed here is that you don’t have to break anything. And if nothing breaks, who notices?”
I’m surprised there hasn’t been more coverage of this problem. The only other story I found was by Tom Claburn of InformationWeek. As I was reading, I couldn’t help thinking about the rise of SaaS and cloud computing, and how they depend on reliable, secure internet connectivity. If the Internet is going to become the main conduit for the applications both businesses and consumers depend on, fundamental issues of security need to be addressed.
1 comment September 2, 2008
Kaminsky “Officially” Reveals DNS Flaw at Black Hat
Dan Kaminsky has had quite a month. Early in July, it was announced that months earlier he had discovered a major security problem with DNS, the addressing system of the Internet. But he didn’t make the news public. Instead he worked for months behind the scenes with major technology providers so patches could be programmed and made available. http://cparente.wordpress.com/2008/07/09/its-tuesday-must-be-time-to-fix-dns/
He wanted to give companies a full month to implement steps to protect their recursive nameservers. Then he promised to reveal all during an address today at the Black Hat security conference in Las Vegas. http://www.blackhat.com/html/bh-usa-08/bh-usa-08-speakers.html#Kaminsky
But it didn’t quite work out that way. Details of the vulnerability leaked out on July 22nd, stealing some of Dan’s thunder. But from all reports the presentation was jam packed, and Dan was shown the appreciation he deserved as he detailed the seriousness of the problem. Joe Menn from LA Times:
He called the problem the worst discovered since 1997. The standing-room only crowd gave Kaminsky two ovations, in part for the technical significance of the find and in part for his handling of the crisis. Microsoft, Google, Yahoo, Facebook, MySpace, EBay and many Internet service providers have secured their machines.
“We got lucky with this bug,” Kaminsky said in his talk, saying other profound flaws are lurking that will be just as hard to resolve. “We have to have disaster-recovery planning. The 90-days-to-fix-it thing isn’t going to fly.” http://latimesblogs.latimes.com/technology/2008/08/internet-securi.html#comments
Interestingly what few of the articles on this problem talk about is, what now? The patches greatly reduce the danger that this flaw could be used for DNS cache poisoning attacks, but they don’t prevent it entirely. Many are touting DNSSEC as the ultimate answer, but that is years away in a best case scenario. Even after the final nameserver is patched against this latest threat, the issue of DNS security will remain critical. Too many things — cloud computing, SaaS, ecommerce, wireless NAC, VOIP — depend on reliable DNS for the status quo to continue. “Patched” isn’t good enough — DNS needs to be fixed.
Add comment August 6, 2008
It’s Tuesday — Must Be Time to Fix DNS
Tuesday a big story broke that could have impacted millions of web users. A researcher discovered a major security flaw involving the Domain Name System (DNS), and instead of selling the information or using it to market himself he went to major internet vendors and discussed the vulnerability with them. Today Microsoft, Cisco, Sun and BIND (via the Internet Software Consortium) issued patches to this problem, before the bad guys could exploit. Good report from Rob Vamosi of CNET:
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.
http://news.cnet.com/8301-10789_3-9985618-57.html?hhTest
Here’s a description straight from Dan himself off his DoxPara Research blog:
I’m pretty proud of what we accomplished here. We got Windows. We got Cisco IOS. We got Nominum. We got BIND 9, and when we couldn’t get BIND 8, we got Yahoo, the biggest BIND 8 deployment we knew of, to publicly commit to abandoning it entirely.
It was a good day.
http://www.doxpara.com/?p=1162
For the most technical, here’s the US Computer Emergency Readiness Team (US-CERT) Vulnerability Note, which includes a long list of the vendors affected:
http://www.kb.cert.org/vuls/id/800113
I spoke with a DNS expert I know well for some context around the announcement. He confirmed the magnitude of the potential problem, saying that it puts the majority of web nameservers at risk for DNS cache poisoning. He also noted that the initial reporting portrayed the problem as being with the DNS itself, which is true to some extent.
But BIND and Microsoft nameservers are particularly susceptible to cache poisoning, due to a weakness in how the query response number is randomized when the recursive server responds with the proper IP address. Other name servers, like PowerDNS, are much less at risk.
Here’s how he tried to describe the attacks to me in layman terms. The attack sends repeated queries for the same resource record (IP address) to the recursive server, which causes multiple open queries to be opened. Think of these as tickets started but not completed.
Then the attack also sends a number of answers using spoofed addresses to make it appear they are coming from the legitimate nameserver for that resource record. What the attacker is trying to do is “guess” the socket number and transaction ID of the actual, correct response. So the machine asks a server for an IP number, but then floods the server with false answers to that same query, racing to see which answer gets accepted first by the resolver.
Because of weak randomization in many nameservers, the attacker was highly likely to eventually hit on a correct transaction address, which means the resolver would give an answer the attacker assigned, not the correct IP address. That false answer would then be cached by the server, and every request for that IP address would be given the new, fraudulent destination. And users might never know the difference.
This description makes sense, based on this from the CNET story that refers to beefed up randomization:
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.”
Beyond the technology, this is a very heartening story of collaboration and discretion in the name of the greater good. By waiting until Microsoft, BIND and others could issue a patch for this problem before making any public statements, a great deal of online harm was avoided. I’m sure Kaminsky will get the royal treatment at Black Hat, and it sure sounds like he deserves it. Dan, here’s a big thank you from this Internet user.
Add comment July 9, 2008
