Embedded security, cryptography, software protection
The next Baysec meeting is tomorrow at Pete’s Tavern. Come out and meet fellow security people from all over the Bay Area. As always, this is not a sponsored meeting, there is no agenda or speakers, and no RSVP is needed. Thanks go to Ryan Russell for planning all this.
See you tomorrow, August 14th, 7-11 pm.
Pete’s Tavern
128 King St. (at 2nd)
San Francisco
Here are the slides from my FasTrak talk and a short summary of my findings. I’m hoping what I’ve found can help officials improve the security and privacy of these systems.
FasTrak and related toll collection systems have been around since the mid-90’s. I started looking at them because I had never signed up due to privacy concerns. However, while the underlying Title 21 standard is public, I couldn’t find any details about the internal workings of the system or any security measures. I bought a few transponders and took them apart to find out.
Besides support for the standard messages, I found no encryption. So it’s easy for an attacker to use a simple RFID reader to collect transponder IDs from cars in a parking lot, then replay them to bill tolls to the real owners. By only using each stolen ID once, it would be difficult to track them down.
Even more surprising, I found support for a lot of proprietary messages that go far beyond toll collection. By sending a few packets, an attacker can activate a hidden “update mode” that allows the ID to be wiped or overwritten with a different one. This goes against claims that the transponder is “read-only” and “there is no memory to write anything to”.
The ability to clone and/or overwrite IDs over-the-air calls into question the admissibility of FasTrak logs as evidence. They get regular subpoenas for these logs, and I wonder how many innocent people were convicted based on the claimed reliability of this system. A non-technical attack is to steal a transponder from the victim and surrepititiously plant it in someone else’s car, creating fraudulent evidence that the victim was somewhere they were not.
Also, the 511.org service creates a massive collection of data, logging every section of freeway traveled by each car that has a transponder. FasTrak has told a reporter (story) that this data is discarded after 24 hours but I can find no written evidence of this. Since all this system does is generate statistics of average travel times, it could be significantly reduced from its current form. Instead of querying and logging all cars, it could randomly sample cars so only 1 out of every 100 were used. Each record could be discarded after 10 minutes or so since the readers are located approximately at each freeway exit. A car that was logged at one sign but not the next probably exited.
This updated system would still achieve the stated goals while reducing the chances for a privacy compromise. It also would only require changing the server software, not the readers or transponders.
I’m working on an add-on “privacy kit” to retrofit transponders. It consists of a timer circuit and activation button, similar to a garage door opener. It keeps the transponder powered off except for a minute or so after the user presses the button. This protects the user from privacy exposure (except while paying tolls) and cloning or overwrite attacks. The downside is it would require technical skills to attach to the transponder. However, newer models are coming out that have an open battery bay, making it easy to add this privacy kit.
I hope to release schematics free of charge and create a kit that would be available at no profit to myself. Hopefully this will convince transponder vendors to add an opt-out capability into future designs.
Transit agencies interested in more details on my research can contact me here.
I haven’t revealed all the details yet about my Blackhat talk on RFID toll pass security. One reason was I hoped to speak with Bay Area transit officials to alert them beforehand. The other reason is that I’ve still been analyzing the potential impact of the flaws I found.
Well, the results are in and it’s pretty serious. I’m reasonably certain an attacker can send a couple messages to a FasTrak transponder and wipe its internal ID. Also, the ID can be overwritten with a different one. There is a population of at least 1 million of these vulnerable transponders in California, sold over the past 15 years. They conduct 50 million transactions per year on Bay Area bridges. This does not include their use on southern California toll roads.
I think this is a big deal. If anyone reading this is responsible for engineering at FasTrak, please contact me. The messages I’ve sent via your website haven’t worked. Thanks.
Inspired by Chris Eng, here is a list of Blackhat talks I will probably attend. It’s frustrating to have so many talks in conflicting time slots while some times have almost none relevant to me.
Highway to Hell: Hacking Toll Systems (11:15 am). As much as I’d like to see the other talks, someone has to present this one. If you’re just getting into hardware hacking or wondering how to secure toll systems, please drop in. Too bad I also have to miss Ilfak’s talk on adding a decompiler to IDA (watch out Veracode!) Oh, and there was some DNS thing too.
Software Radio and the Future of Wireless Security (1:45 pm). After lunch, I’m interested in hearing more about software radio. I do most of my work by soldering directly to the logic side, bypassing any demodulation circuitry. Temporal Reverse Engineering looks interesting also.
Return-Oriented Programming: Exploits Without Code Injection (3:15 pm). This should be good since I haven’t seen an exhaustive treatment of this approach. I think the stack has been overlooked since NX became common. But it can still control program flow even without executing directly from it.
Pwnie Awards (6 pm). The Oscars without the speeches and with more embarassment. Awesome.
Developments in Cisco IOS Forensics (10 am). I can get up early to enjoy FX getting back into Cisco again.
Timing Attacks on the MSP430 Bootstrap Loader (1:45 pm). The BSL sometimes gives access to the flash even if the JTAG fuse has been blown. I’ve become familiar with the MSP430 due to this FasTrak research so this is quite relevant to me.
How To Impress Girls With Browser Memory Protection Bypasses or Mifare – Little Security, Despite Obscurity (3:15 pm). Augh, can’t decide: amusing heap fung shui or more updates on the CRYPTO1 train wreck. I’ll probably flip a coin.
Inducing Momentary Faults Within Secure Smartcards/Microcontrollers (4:45 pm). Chris Tarnovsky is the leading silicon hacker. You’d have to be crazy to miss this.
[Edit: added Travis Goodspeed’s talk. I inadvertently left it out the first time]
Being his usual humble self, Halvar casually discovers what I think is Dan Kaminsky’s DNS flaw. The Register has a story that quotes me on this. While I’m not certain it is the same attack, I’m moderately confident it is.
Note that neither Halvar nor I was part of the secret briefing Dan gave to researchers. I didn’t receive that inside information and believe Halvar didn’t either. This reinforces the perspective that information about a bug should be revealed quickly, given the likelihood that another party might rediscover it. It’s possible a black hat hacker even beat Halvar, even though he’s very smart.
The debate about full or partial disclosure is really all about control. In this case, the information about the patch (randomize source port and double check the randomization on TXID) was enough to independently rediscover the attack. Even though there is not a direct connection between the attack and the patch, knowing that it was possible was enough. Once the information was out there, Dan and the vendors had given up control.
So, patch your servers and back to business as usual…
Well-funded and motivated attackers are typically the hardest to defend against when designing a system. Governments can attack systems in different ways and with more resources than a typical threat. Consider a recent example where a British aide lost his Blackberry after spending the night with a woman who approached him in a Chinese disco. While it’s possible he just lost it while drunk, this is a good example of how unconventional threats need to be carefully considered.
Let’s analyze the cost of two routes to getting this same information: hacker or hooker. The hacker might try to crack passwords or develop a 0-day exploit against the Blackberry server. Or, build a custom trojan and send it via a forged email that appears to come from the Prime Minister. The hooker would try to get to his hotel room and steal the phone. It would actually suffice to just borrow it for a few minutes and dump the RAM since passwords are often cached there. This has the added advantage that he might never know anything had happened.
A 0-day exploit could be in the $20,000 range. Hiring someone to develop and target a trojan at this aide would be less, but the chance of succeeding would be lower. According to the stories about Eliot Spitzer, a high-end call girl is $1,500 per hour. Assuming it takes four hours, the total cost would be $6,000. The fact that both these approaches could be done in China means the actual cost would be lower but probably still a similar ratio.
There are a lot of other advantages to the hooker approach besides cost. There is good deniability if the call girl gets caught. Since the call girl remains within the attacking country’s jurisdiction, the police can be used to recover the Blackberry if she makes an extortion attempt. The hacker approach has a lot more uncertainty as flaws could be patched or blocked, making the exploit useless.
I also think this gives good support to my claim that software protection techniques are on the verge of wider adoption. With cold boot attacks and growing news of governments seizing laptops or stealing cell phones, systems must remain secure even when an attacker has physical possession of a powered-up device. The only way to do this is to adopt software and hardware techniques that are already used to protect games, DRM, and satellite TV. Traditional approaches like those used in network security are no longer enough.
I’ll be speaking on this topic along with Thomas Ptacek at WOOT, co-hosted at USENIX on July 28th in San Jose. Since this event is invite-only, send me email if you’re a security researcher who would like to attend. Please include a brief summary of your background.
rdist 