Curiosity Killed The Twit, Twitter Clickjacking

February 12, 2009 by Eliot 24 Comments

Twitter was flooded this morning with users posting “Don’t Click: http://tinyurl.com/amgzs6”. TinyURL has since terminated the URL. The original page doesn’t seem to be live either. It displayed a button that said “Don’t Click”. If the user happened to be logged into Twitter, it would automatically update their status. The instigator partially describes the method on his blog (translated). The page would load the user’s Twitter page in an invisible iframe. The status would be pasted in and the “Don’t Click” button is placed on top of the update button. You can find the code snippets here and the original author credits this post for the inspiration. Twitter has since added a JavaScript fragment to each page to break out of iframes.

if (window.top !== window.self) { window.top.location.href = window.self.location.href; }

BackTrack 4 Beta Released

February 10, 2009 by Eliot 101 Comments

backtrack

The Remote Exploit Development Team has just announced BackTrack 4 Beta. BackTrack is a Linux based LiveCD intended for security testing and we’ve been watching the project since the very early days. They say this new beta is both stable and usable. They’ve moved towards behaving like an actual distribution: it’s based on Debian core, they use Ubuntu software, and they’re running their own BackTrack repositories for future updates. There are a lot of new features, but the one we’re most interested in is the built in Pico card support. You can use the FPGAs to generate rainbow tables and do lookups for things like WPA, GSM, and Bluetooth cracking. BackTrack ISO and VMWare images are available here.

The 2009 ShmooBall Gun

February 6, 2009 by Eliot 10 Comments

larry

The registration desk hasn’t opened yet at ShmooCon 2009, but we’re already running into old friends. We found [Larry Pesce] and [Paul Asadoorian] from the PaulDotCom Security Weekly podcast showing off their latest ShmooBall gun. ShmooBalls have been a staple of ShmooCon from the very beginning. They’re soft foam balls distributed to each of the attendees who can then use them to pelt the speakers when they disagree. It’s a semi-anonymous way of expressing your dismay physically. [Larry] has been building bigger and better ways to shoot the ShmooBalls for the last couple years. You may remember seeing the 2008 model. This year the goal was to make the gun part much lighter. The CO2 supply is mounted remotely with a solenoid valve and coiled air line. The pistol grip has a light up arming switch and trigger. The gun is fairly easy to transport: the air line has a quick disconnect and the power is connected using ethernet jacks.

Parking Violation Leads To Malware Download

February 5, 2009 by Eliot 26 Comments

parking

It seems some enterprising individual in Grand Forks, North Dakota has been placing fake parking violations on cars. If the recipient visited the URL on the flyer, they would be told to install a toolbar to view pictures of their vehicle. That piece of malicious software would then attempt to install several more. The actual vehicle pictures were from Grand Forks, but we wouldn’t be surprised to see a similar attack happen in a much larger city.

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]