TEMPEST: A Signal Problem

January 25, 2009 by Eliot 12 Comments

TEMPEST is the covername used by the NSA and other agencies to talk about emissions from computing machinery that can divulge what the equipment is processing. We’ve covered a few projects in the past that specifically intercept EM radiation. TEMPEST for Eliza can transmit via AM using a CRT monitor, and just last Fall a group showed how to monitor USB keyboards remotely. Through the Freedom of Information Act, an interesting article from 1972 has been released. TEMPEST: A Signal Problem (PDF link dead, try Internet Archive version) covers the early history of how this phenomenon was discovered. Uncovered by Bell Labs in WWII, it affected a piece of encryption gear they were supplying to the military. The plaintext could be read over that air and also by monitoring spikes on the powerlines. Their new, heavily shielded and line filtered version of the device was rejected by the military who simply told commanders to monitor a 100 feet around their post to prevent eavesdropping. It’s an interesting read and also covers acoustic monitoring. This is just the US history of TEMPEST though, but from the anecdotes it sounds like their enemies were not just keeping pace but were also better informed.

[via Schneier]

Manual Protocol Analysis

January 24, 2009 by Eliot 2 Comments

packetfu

As a followup to last week’s post on automated protocol analysis, [Tod Beardsley] has written up how to start analyzing a protocol manually. He walks through several examples to show how to pull out the interesting bits in binary protocols. His first step was sending 10 identical select statements and capturing the outbound packets. He used the Ruby library PacketFu to help with the identification. It compared the ten packets and highlighted one byte that was incrementing by four with each packet, probably a counter. Looking at the response indicated a few other bytes that were also incrementing at the same rate, but at different values. Running the same query on two different days turned up what could be a timestamp. Using two different queries helped identify which byte was responsible for the statement length. While you may not find yourself buried in HEX on a daily basis, the post provides good coverage of how to think critically about it.

Use The CPU Cache To Prevent Cold Boot? No.

January 18, 2009 by Eliot 21 Comments

coldboot

Frozen Cache is a blog dedicated to a novel way to prevent cold boot attacks. Last year the cold boot team demonstrated that they could extract encryption keys from a machine’s RAM by placing it in another system (or the same machine by doing a quick reboot). Frozen Cache aims to prevent this by storing the encryption key in the CPU’s cache. It copies the key out of RAM into the CPU’s registers and then zeroes it in RAM. It then freezes the cache and attempts to write the key back to RAM. The key is pushed into the cache, but isn’t written back to RAM.

The first major issue with this is the performance hit. You end up kneecapping the processor when you freeze the cache and the author suggests that you’d only do this when the screen is locked. We asked cold boot team member [Jacob Appelbaum] what he thought of the approach. He pointed out that the current cold boot attack reconstructs the key from the full keyschedule, which according to the Frozen Cache blog, still remains in RAM. They aren’t grabbing the specific key bits, but recreating it from all this redundant information in memory. At best, Frozen Cache is attempting to build a ‘ghetto crypto co-processor’.

We stand by our initial response to the cold boot attacks: It’s going to take a fundamental redesign of RAM before this is solved.

[via Slashdot]

Malware Posing As Change.gov

January 17, 2009 by Eliot 13 Comments

change

PandaLabs has identified a botnet running a malware campaign impersonating president-elect Obama’s website. The front page of the site features a sensational story titled “Barack Obama has refused to be a president”. Clicking the link will download the malware and make the target’s machine part of the botnet. They’re using fast-flux to assign the malicious domains to the massive number of compromised nodes that are hosting the actual site. The team has contacted the domain name registrar in China to get the domains removed. Using a sensational headline is not new to malware; it’s how the Storm Worm got its name.

[via lithium]

Dismantling The Storm Worm Botnet

January 16, 2009 by Eliot 26 Comments

malware

Zero Day has an interview with German researchers who have found a way to take down the Storm Worm botnet. Their program, Stormfucker, takes advantage of flaws in Storm’s command network: Nodes that are NAT‘d only use a four-byte XOR challenge. Nodes that aren’t NAT’d are only using a trivial 64bit RSA signature. Their solution can clean infected machines and also distribute to other nodes. Unfortunately, installing software without the user’s consent is the exact same behavior as malware. Don’t expect to see this in any sort of widespread use. The researchers did point out that some ISPs have moved to shutting off service for infected customers until their machines are cleaned.

Interview With An Adware Author

January 14, 2009 by Strom Carlson 41 Comments

toolbars2

Philosecurity has an interview with [Matt Knox], a former coder for Direct Revenue, an adware company which was sued in 2006 by New York governor Eliot Spitzer. The interview contains some interesting details of how the adware code worked internally: it created a Browser Helper Object, then ensured that the Browser Helper Object stayed up by creating a poller to check every ten seconds and regenerate the Browser Helper Object if it had stopped running. The poller ingeniously masked itself partly by exploiting Windows’ Create Remote Thread function to run itself as a series of threads instead of as an executable.

The truly fascinating bit of the interview is how [Knox] defies your initial suspicion that he’s a complete scumbag; he started off writing spam filtering software, was hired by Direct Revenue to do traffic analysis, started writing tiny bits of code to improve the adware, and eventually wound up knee-deep in the code. [Knox] notes that you can get ordinary people to do incredibly distasteful things if you break those things into small enough chunks and introduce them gradually.

[via Waxy]

[photo: xcaballe]

Automated Protocol Analysis

January 13, 2009 by Eliot 4 Comments

wireshark

[I)ruid] from BreakingPoint Labs has been doing quite a bit of protocol reverse engineering as part of his work. He put together a post covering some of the tools that have been useful for this task. Text-based protocols have a lot of human readable characters that can help you identify fields. Binary protocols don’t have this luxury though. He recommends the Protocol Informatics Project for tackling these situations. It applies bioinformatics algorithms to network traffic. You give it a packet dump of the protocol and it compares them to find similarities the same way genetic sequences are compared. It can be confused by protocols that waste a lot of space, but it’s still a very clever approach to reversing.

[photo: slashcrisis]