Protecting Cars from Viruses

Reuters is running a story that should amuse any computer security professional: Experts hope to shield cars from computer viruses.

An excerpt:

Intel's McAfee unit, which is best known for software that fights PC viruses, is one of a handful of firms that are looking to protect the dozens of tiny computers and electronic communications systems that are built into every modern car.

It's scary business. Security experts say that automakers have so far failed to adequately protect these systems, leaving them vulnerable to hacks by attackers looking to steal cars, eavesdrop on conversations, or even harm passengers by causing vehicles to crash.

Our guess is that when cars get to the point that they drive themselves, those who understand how malware works-- and more important: how undeniably complicated modern software and its hardware architecture can be-- will start donning a pair of Converse Chuck Taylors and resemble a modern Luddite by driving themselves, a la Will Smith in I, Robot.

When you look at the statistics, you are far more likely to get injured or die in a car accident than you are in nearly any other security risk you face in your daily life.  Even with the vast skies being what they are, and the regulations on the airlines industry and their pilots, it's not possible to keep air travel 100% safe, though it's safer than driving (once you get past the TSA checkpoint).

Computerized, self-driving cars may improve (emphasis on "may") safety stats; however, not if their software landscape looks like anything else we operate with a CPU in it these days.  There are agencies with an operating budget larger than the GDP of several nations that are terrified about the possibility of malware injected into things like military aircraft or missile guidance systems.  Given that, how in the world is an automobile for ~$20K (which is at most 1% of the price tag of the military's concerns) ever going to be 100% free of malware?  Simple: it won't be.

Toyota Motor Corp, the world's biggest automaker, said it was not aware of any hacking incidents on its cars.

"They're basically designed to change coding constantly. I won't say it's impossible to hack, but it's pretty close," said Toyota spokesman John Hanson. [emphasis ours]

Oh, we've never heard that before...

Officials with Hyundai Motor Co, Nissan Motor Co and Volkswagen AG said they could not immediately comment on the issue.

A spokesman for Honda Motor Co said that the Japanese automaker was studying the security of on-vehicle computer systems, but declined to discuss those efforts.

Mums the word is a much smarter response to the press.

A spokesman for the U.S. Department of Homeland Security declined to comment when asked how seriously the agency considers the risk that hackers could launch attacks on vehicles or say whether DHS had learned of any such incidents.

They probably declined to comment because they are working on exploits for these as well.  Say it ain't so?  Look no further than Stuxnet and Flame, of which the US Gov takes full authorship credits.  It's the future of the "cyberwarfarestate".

We can't keep malware out of critical infrastructure SCADA systems.  There's no way we can keep it out of your mom's minivan.

Classic Trust

Ken Thompson is on the left. That's not Adam Savage on the right.

If you work in computer security or software development, and you have never read Unix co-creator Ken Thompson's original 1984 speech "Reflections on Trusting Trust" then you are hereby obliged to at least read the following snippet for today's history lesson, which is just as relevant-- actually more so-- today:

The moral is obvious. You can't trust code that you did not totally create yourself. (Especially code from companies that employ people like me.) No amount of source-level verification or scrutiny will protect you from using untrusted code. In demonstrating the possibility of this kind of attack, I picked on the C compiler. I could have picked on any program-handling program such as an assembler, a loader, or even hardware microcode. As the level of program gets lower, these bugs will be harder and harder to detect. A well installed microcode bug will be almost impossible to detect.

Ken was referring to the trojan modifications he embedded into the C compiler, illustrating that you need to rely on more that source code, but the compiler, the assember, the loader, all the way down to the instruction sets of the CPUs.  Or as Schneier famously pitched: "security is a chain; only as strong as its weakest link".

Who operates on a completely self-built system from software to hardware?  We would venture to say: nary a soul.

Just a good reminder for a random Thursday, in case you forgot.

Hacking Hotels

Breaking into a hotel room with less than $50 in hardware

The technical security media has been all abuzz about a recent Black Hat presentation by Cody Brocious on hacking electronic hotel door locks.

The original author's documentation including the paper and slides are here.

Here's the simplified version:

• The vendor of the locks has an overwhelming majority of the market in the U.S. (chances are you stayed in a room that had this exact lock on it)
• The key cards use crypto for implementing the access control
• The mathematical aspect of the crypto is more or less fine (as is usually the case)
• The problem comes in managing keys (which is pretty much always the problem!)
• An administrative feature is easily exploited-- which is only slightly better than vendors shipping products with widely-known default passwords.
• An administrative maintenance device, when connected, can extract the crypto key and break the access control
• You can roll-you-own maintenance device on the very, very cheap
• Yes, this probably looks like a scene in any random Hollywood movie
• This will likely be a majorly expensive pain to fix for the vendor and hotels
• "Compensating controls" in this case include surveillance cameras, internal dead bolt manual locks, et al

MS-CHAPv2 Crack

It should come as no real surprise: MS-CHAPv2 is broken.  It's an ancient scheme.  If you were paying attention, you would have migrated your VPNs and Wireless networks away from it years ago anyway.

Here's a great break down of what this means to your wireless networks.

An even simpler one is to just note that these combinations are still fine:

• IPSEC and OpenVPNs are fine.
• WPA2 Enterprise wireless with PEAP is fine.
• WPA2 Non-Enterprise (i.e. home) wireless is fine (from this).

And, of course, keep in mind it still takes 24 hours (right now, but that's sure to be sped up) to actually crack the DES encryption key with this exploit.  Since it's 24 hours and not 24 ms, that means an attacker will more than just casually find you and exploit you.  Your network will have to be a target first, at least to some degree.