DNS Tunneling: Getting The Data Out Over Other Peoples’ WiFi

[KC Budd] wanted to make a car-tracking GPS unit, and he wanted it to be able to phone home. Adding in a GSM phone with a data plan would be too easy (and more expensive), so he opted for the hacker’s way: tunneling the data over DNS queries every time the device found an open WiFi hotspot. The result is a device that sends very little data, and sends it sporadically, but gets the messages out.

This system isn’t going to be reliable — you’re at the mercy of the open WiFi spots that are in the area. This certainly falls into an ethical grey zone, but there’s very little harm done. He’s sending a 16-byte payload, plus the DNS call overhead. It’s not like he’s downloading animated GIFs of cats playing keyboards or something. We’d be stoked to provide this service to even hundreds of devices per hour, for instance.

If you’re new here, the idea of tunneling data over DNS requests is as old as the hills, or older, and we’ve even covered this hack before in different clothes. But what [KC] adds to the mix is a one-stop code shop on his GitHub and a GPS application.

Why don’t we see this being applied more in your projects? Or are you all tunneling data over DNS and just won’t admit it in public? You can post anonymously in the comments!

SIGGRAPH 2008: The Quest For More Pixels


Long before we started reporting on [Dan Kaminsky]’s DNS chicanery, he contributed a guest post about one of our favorite sources of new technology: SIGGRAPH. The stars have aligned again and we’re happy to bring you his analysis of this year’s convention. [photo: Phong Nguyen]

So, last week, I had the pleasure of being stabbed, scanned, physically simulated, and synthetically defocused. Clearly, I must have been at SIGGRAPH 2008, the world’s biggest computer graphics conference. While it usually conflicts with Black Hat, this year I actually got to stop by, though a bit of a cold kept me from enjoying as much of it as I’d have liked. Still, I did get to walk the exhibition floor, and the papers (and videos) are all online, so I do get to write this (blissfully DNS and security unrelated) report.

Continue reading “SIGGRAPH 2008: The Quest For More Pixels”

Black Hat 2008: Pwnie Award Ceremony


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.

Continue reading “Black Hat 2008: Pwnie Award Ceremony”

Black Hat 2008: Dan Kaminsky Releases DNS Information


[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.

Securing DNS On OSX


It’s been a few weeks since [Dan Kaminsky] announced the nature of the DNS vulnerability and allowed 30 days of non-disclosure for patches to be applied before details of the exploit went public. Unfortunately, the details were leaked early and it didn’t take long for a functional exploit to be released into the wild. Since then, many ISPs have taken steps to prevent their users from falling victim to the attack, and BIND, the widely-used DNS protocol implementation, was updated to minimize the threat. Even then, there were reports of a version of the attack being actively used on AT&T’s DNS servers.

Mac OSX uses a BIND implementation but as of yet, Apple has not released a patch updating the system (Microsoft, on the other hand, patched this up on July 8). As a result, machines running OSX are at risk of being exploited. Individual users are less likely to be targeted, since the attacks are directed towards servers, but it’s not a smart idea to leave this vulnerability open. [Glenn Fleishman] has published a way to update BIND on OSX manually, rather than waiting on Apple to patch it themselves. It requires Xcode and a bit of terminal work, but it’s a relatively painless update. When we tried it, the “make test” step skipped a few tests and told us to run “bin/tests/system/ifconfig.sh up”. That allowed us to re-run the tests and continue the update without further interruption. [Fleischman] warns that people who manually update BIND may break the official update, but he will update his instructions when it happens with any possible workarounds. Unfortunately, this fix only works for 10.5 but alternative, yet less effective methods may work for 10.4 and earlier.

If you’d like to know if your preferred DNS servers are vulnerable or not, you can use the DNS checker tool from Doxpara. As an alternative to your ISP’s DNS servers, you can use OpenDNS, which many prefer for its security features and configuration options.

DNS Cache Poisoning Webcast


UPDATE: Full audio of the webcast is now available

Today Black Hat held a preview webcast with [Dan Kaminsky] about the massive DNS bug he discovered. On July 8th, multiple vendors announced a patch for an undisclosed DNS vulnerability. [Dan Kaminisky] did not release the details of the vulnerability at that time, but encouraged security researchers to not release their work, if they did happen to discover the bug. On the 21st, the full description of the vulnerability was leaked.

In today’s webcast, [Dan] covered how he felt about the handling of the vulnerability and answered a few questions about it. He started out by talking about how he stumbled across the bug; he was working on how to make content distribution faster by using DNS to find the server closest to the client. The new attack works because DNS servers not using port randomization make it easy for the attacker to forge a response. You can read the specifics of the attack here.

Continue reading “DNS Cache Poisoning Webcast”