The full archive of slides and white papers from this year has been posted too.
While Black Hat and Defcon have both concluded, we’re going to post a few more talks that we think deserve attention. [Sherri Sparks] and [Shawn Embleton] from Clear Hat presented Deeper Door, exploiting the NIC chipset. Windows machines use NDIS, the Network Driver Interface Specification, to communicate between the OS and the actual NIC. NDIS is an API that lets programmers talk to network hardware in a general fashion. Most firewalls and intrusion detection systems monitor packets at the NDIS level. The team took a novel approach to bypassing machine security by hooking directly to the network card, below the NDIS level.
The team targeted the Intel 8255x chipset because of its open documentation and availability of compatible cards like the Intel PRO/100B. They found that sending data was very easy: Write a UDP packet to a specific memory address, check to make sure the card is idle, and then tell it to send. The receive side was slightly more difficult, because you have to intercept all inbound traffic and filter out the replies you want from the legitimate packets. Even though they were writing low level chipset specific code, they said it was much easier to implement than writing an NDIS driver. While a certainly a clever way to implement a covert channel, it will only bypass an IDS or firewall on the same host and not one on the network.
[photo: Big Fat Rat]
Black Hat presenters [Robert “RSnake” Hansen], CEO of SecTheory, and [Tom Stracener], security analyst at Cenzic, criticized Google in their presentation “Xploiting Google Gadgets”. [Hansen] and [Stracener] say that there’s currently no way for Google to confirm whether Google Gadget creations contain malicious content or not; this leaves the application vulnerable to a wide range of hacking ugliness such as data poisoning, worms, and theft of data. [Hansen] himself isn’t exactly on the friendliest terms with Google. He’s got a bit of a contentious history and he claims that Google has threatened legal action against him. Nevertheless, if what was presented is true and accurate, then Google has a huge security issue that needs to be addressed sooner rather than later. Google has not yet commented on the situation.
The first night of Black Hat briefings concluded with the Pwnie Award Ceremony. The awards reward achievements in security… but mostly failures. Notably, this was the first year anyone accepted an award in person. Hack a Day took home an early victory by producing a MacBook mini-DVI to VGA adapter (pictured above). The ceremony was fairly straight forward after that. Best Server-Side Bug went to the Windows IGMP kernel vulnerability. It was a remote kernel code execution exploit in the default Windows firewall. The Best Client-Side Bug went to Multiple URL protocol handling flaws like this URI exploit. Mass 0wnage went to WordPress for many many vulnerabilities. Most Innovative Research went to the Cold Boot Attack team. Lamest Vendor Response was won by McAfee for saying XSS can’t be used to hack a server. The Most Overhyped Bug went to [Dan Kaminsky] for his DNS vulnerability. Most Epic FAIL was won by the team behind Debian for shipping the OpenSSL bug for two solid years. Lifetime Achievement Award was won by [Tim Newsham]. Finally, the Best Song was by Kaspersky Labs for Packin’ The K!, which you can find embedded below.
[Dan Kaminsky]’s much anticipated talk on his DNS findings finally happened at Black Hat 2008 in Las Vegas today. [Dan] has already uploaded the complete slides from his talk as well as posted a short summary to his site. New information in the slides since our previous coverage includes “Forgot My Password” attacks and new attacks on internal network vulnerabilities as a side of effect of DNS cache poisoning. [Dan]’s talk today was over capacity; our shot of the conference room overflow is shown above.
The EFF has just announce the creation of the Coders’ Rights Project website at the Black Hat conference. The sites’ main goal is to centralize legal information for coders, and to help protect important security work from legal actions that may be taken against them with the DMCA and other legal black holes. While this is in no way a fully comprehensive list of everything you need to know, it looks like a good place to start, and provides a few FAQs for suggestions on how to stay in the legal clear as much as possible. At numerous points the documents suggest you speak with a lawyer, if you have any deeper questions, which you absolutely should. This can be very helpful if a person or group finds a security risk, and wants to publish it, or just wants to start looking into possible security risks.