Predictive Blacklisting With DShield


The DShield project is hoping to change how we protect our networks from malware with predictive blacklisting. Using a method similar to Google’s PageRank, DShield collects logs from network administrators to help develop a score based on maliciousness. They combine this score with information about where the malware has already hit to determine an overall threat level.

Similar to antivirus programs, the system still relies on networks being attacked to rate the threat level. They have shown though, that the predictive method is consistently more effective than manual blacklisting. The system has been available for free for the past year. Those utilizing the system have been reporting positive results. They do note that there are a few people whose network infrastructure doesn’t match up with the predictions very well. If you would like to participate, go to their site and sign up.

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”

HOPE 2008: Methods Of Copying High Security Keys


[Barry Wels] is well known for his lockpicking talks, but this year he wanted to talk about how he copies high security keys. If a key blank is available, you could make a copy just by viewing the original. High security keys generally have profiles with more side cuts, which means you can guess at how deep a specific pin is by observing how many cuts it crosses. He also showed that you could imprint your arm with the key and use that as a guide. If a blank isn’t available, you could fill a similar key with solder and file that down.

[Barry] showed two different kits for casting keys. The first used soft clay in a clam shell to make an imprint of the original key. The form is then filled with a low melting point alloy (probably Wood’s metal) to create the new key. A second style uses a metal form and two part silicone to create the mold. This method works for most high security keys, but will not work on keys with active elements like sliders or magnets.

Finally, [Barry] talked about his favorite method: impressioning. Unlike picking a lock, when you’re done impressioning you have a funtional key. You start with key blank and file off the top layer. Place the blank in the lock and turn it till it jams. Then, you rock the key up and down. Observing the key under light you’ll see a small mark where each pin is. File a bit where the marks appear and repeat the process. You can’t use too much force or you might break the blank. This also works on dimple keys and as this video shows, laser cut keys. [Barry] highly recommends the impressioning book by [Oliver Diederichsen].

[photo: Rija 2.0]

DNS Exploit In The Wild


We’ve been tracking Metasploit commits since Matasano’s premature publication of [Dan Kaminsky]’s DNS cache poisoning flaw on Monday knowing full well that a functional exploit would be coming soon. Only two hours ago [HD Moore] and [I)ruid] added a module to the Metasploit Project that will let anyone test the vulnerability (with comment: “ZOMG. What is this? >:-)“). [HD] told Threat Level that it doesn’t work yet for domains that are already cached by the DNS server, but it will automatically wait for the cached entry to expire and then complete the attack. You can read more about the bailiwicked_host.rb module in CAU’s advisory. For a more detailed description of how the attack works, see this mirror of Matason’s post. You can check if the DNS server you are using is vulnerable by using the tool on [Dan]’s site.

[photo: mattdork]

HOPE 2008: Cold Boot Attack Tools Released


The team from Princeton has released their cold boot attack tools at The Last HOPE. Earlier this year they showed how to recover crypto keys from the memory of a machine that had been powered off. Now they’ve provided the tools necessary to acquire and play around with your own memory dumps. The bios_memimage tool is written in C and uses PXE to boot the machine and copy the memory. The package also has a disk boot dumper with instructions for how to run it on an iPod. There’s also efi_memimage which implements the BSD TCP/IP stack in EFI, but it can be problematic. aeskeyfind can recover 128 and 256bit AES keys from the memory dumps and rsakeyfind does the same for RSA. They’ve also provided aesfix to correct up to 15% of a key. In testing, they only ever saw 0.1% error in there memory dumps and 0.01% if they cooled the chips first.

Continue reading “HOPE 2008: Cold Boot Attack Tools Released”

ARDAgent.app Still Vulnerable


When Apple pushed their most recent security update, the first thing we checked was whether the ARDAgent issue was fixed. It’s not. This vulnerability lets anyone execute code as a privileged user and versions of this attack have already been found in the wild. While several Ruby, SMB, and WebKit issues were addressed it, ARDAgent is still unpatched. [Dino Dai Zovi] has published the method by which ARDAgent actually becomes vulnerable: when it starts, it installs its own Apple Event handlers and calls AESetInteractionAllowed() with kAEInteractWithSelf. This should restrict it only to its own events, but for some reason that’s not the resulting behavior. He also pointed out that SecurityAgent has displayed similar weirdness; it is vulnerable to Apple Events even though it doesn’t calls an Apple Events function. We can see how this unexpected behavior could make patch development take much longer and may end up uncovering an even bigger problem. Check out [Dino]’s post for more information.

U.S. And China Host Majority Of Malware


StopBadware.org has released their May 2008 Infected Sites Report(PDF). They took their current list of 213K active badware websites and resolved the IP addresses. These addresses were used to determine the network block owner and country. The results could be skewed to networks Google scans more often, but they should give a decent overall picture. China hosts 52% of all the badware sites while the U.S. has 21%. There weren’t any other countries maintaining over 4% of the total. They also calculated the number of infected sites per capita, which China also led. Last year’s report resulted in several AS block maintainers cleaning up to the point that they don’t even make the top 250 this year.