Last Updated: 2012-07-12 23:41:24 UTC
by Adam Swanger (Version: 1)
We just added an Internet Storm Center Events page at https://isc.sans.edu/events/sansfire-2012.html! This can be used for announcing upcoming events and posting updates as they happen involving ISC and our handlers.
The Internet Storm Center Events page lists past, current and upcoming events pertaining to ISC and our handlers. There is also a link to Internet Storm Center Events RSS feed you can subscribe in from your favorite feed reader!
The listings include the Event Host (link to their website if available), Date(s), Location, short description and a link to either the event page on the hosts website or an ISC page where we'll list details of the event as they unfold.
The ISC Event details page content will vary depending on the event type and activities. Check out the first one for SANSFIRE 2012!! Be sure and check back for updates, added talks, presentations, links and to keep up with what's happening at the event!
Post suggestions or comments in the section below or send us any questions or comments in the contact form on https://isc.sans.edu/contact.html#contact-form
Adam Swanger, Web Developer (GWEB, GWAPT)
Internet Storm Center https://isc.sans.edu
Last Updated: 2012-07-12 17:29:22 UTC
by Rob VandenBrink (Version: 1)
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