Ok, so I'm a bit late on this - my SANSFIRE presentation was actually on Tuesday (July 10).

In this presentation, we discussed the basics of the on board computer and network within your car.  Well-established and legislated SAE and ISO standards define the basics of the OBD (On Board Diagnostic) interface and the network behind it.  Unfortunately, these standards don't include such security basics as authentication or authorization - in fact.  Even worse, the wireless interfaces in your car (Tire Pressure sensors, in-car Bluetooth etc) don't include these concepts either, and in most cases connect directly back to same network.  Any command injected into this computer is blindly followed by the target

Current work into future standards for automotive communications is even bleaker - with peer-to-peer networks for cars (for accident avoidance for instance) and roadside data collection (for emissions monitoring and other uses) on the horizon.  The current guidance document for roadside data collection (remote OBD communications) includes such sage advice as "your database should be password protected", but the wireless communications guidance is all about maximizing range and minimizing the impacts of handing off a session between successive peers as the car moves - - not a word about protecting data in transit (wireless encryption or authentication for instance).

A common thread at SANSFIRE this year is security exposures of embedded devices and security issues on SCADA controlled critical infrastructure networks.  The automotive OBD network combines these two alarming issues on one critical infrastructure network that most of us use every day.  And no-one seems to be working on addressing this issue. 

Combining these threats with wireless interfaces (tire pressure sensors, bluetooth and newer zigbee-like interfaces) and recent research (University of Michigan, UCSD etc) describes a significant threat and a viable potential for attack against the civilian population.  We discussed the potential for an cellphone-sized magnetic or remote device that could kill or control a car for law enforcement (or malicious actors), or a roadside "accident generator" - a very possible attack would be to engage the front-left brake of a single (or many, or many-many) target vehicle(s).  Worse yet, if remote OBD is deployed in high traffic areas (as is currently being discussed) to monitor things such as speed, safe driving or emmissions in real-time, the platform for such an attack might be supplied to the attacker, all they'd need to do would be to hijack this benign platform for evil.

Interfacing to the OBD bus in useful ways was demonstrated, starting with the basics using Putty (or Hyperterminal) to query for OBD parameters. 

From there we discussed using higher level languages to perform more useful functions - a Python library was used for similar queries, then leveraged to write two "real time dashboards" in Python. 

An OBD packet capture utility was also shown, with a nifty time-mark function that is useful in network forensics within the car.

This presentation and example code used will all be posted in our presentations area - watch for them at https://isc.sans.edu/presentations/#sansfire