Before founding Gravwell, I was doing quite a bit of vehicle cybersecurity. Lately I haven't had much opportunity for that kind of fun -- turns out founding a company is time consuming work. Today is a throwback Thursday, however, as I'll be presenting on CANBus and vehicle security at the local DEFCON meetup. We didn't build Gravwell for car hacking but I gotta say, having Gravwell years ago would have made my life a lot easier…
Having the ability to rapidly search data, look for trends, identify changing values, and create aggregates is amazing when poking at proprietary protocols and message formats. That's what makes Gravwell super handy when working with IoT and OT tech.
I'm going to get on a soap box for a moment because, hey this is my blog post and you can ctrl+w anytime you want. With embedded systems, it's very common to have to carve values out of raw packets or messages. It's very rare to see a component like a PLC do any sort of logging and unheard of for such a component to support remote logging. This recent tweet from Michael Toecker, a former colleague and expert in the field, exposes the future of ICS security as we move to more secure protocols:
🤔 So, if every ICS detection tool relies on open, insecure protocols to do it's magic, then where does that lead efforts to secure the protocols?
— Ⓜɪᴄʜᴀᴇʟ ᴛᴏᴇᴄᴋᴇʀ (@mtoecker) April 8, 2019
The trouble is, if we move to secure ICS protocols without also adding support for remote logging into OT components, we've gained some local security in exchange for loss of monitoring capability. Considering that the most serious threats to these systems are using existing communication channels, not creating new ones, I'm not sure that's a good tradeoff right now. We should absolutely move to better protocols for ICS, but everyone should be demanding visibility and remote logging capabilities out of your vendors!
Anyway, we were talking about car hacking. Going into great detail about CANBus is outside the scope of this post but let's do a quick primer about what's in CAN messages. CANBus, for you greenhorns, is a bus used in vehicles for messaging between vehicle components. For example, your engine will spit out periodic messages containing the current RPMs.
A CAN data frame is actually very simple. It consists of an ID and 8 bytes of data. Sure there are other things like CRCs and R bits for indicating a message request, but basically all that matters is the ID and the data (8 bytes!). These are the messages that make your drive-by-wire vehicle actually function. In my Toyota Tundra, the RPMs are being sent on ID 0x2C4 as a Big Endian integer at offset 0. The really annoying thing about messing with canbus is that every manufacturer uses different IDs and message formats for their components. It can be difficult to find references for these but some great projects like OpenGarages are out there to help.
Back when I was doing a lot of car hacking I was using some rough tools and writing a lot of code for plotting ID trends and searching for activity on the CANBus. Here's a code snippet for using Javascript (yes, haters gonna hate) for printing out those RPM values:
var can = require('can');
var channel = can.createRawChannel("vcan0", true);
//CANBus messages contain information for operation of the vehicle
// this varies by manufacturer and possibly model which ID means what
channel.addListener("onMessage", function(msg) {
if (msg.id === 0x2C4) {
//see node docs for how to get values out of buffers
// http://nodejs.org/api/buffer.html
// console.log(msg.data);
var rpm = msg.data.readUInt16BE(0);
console.log("RPM is ", rpm);
}
});
channel.start();
Plotting values meant reading from the bus, extracting what I wanted, maybe putting it in a spreadsheet or using gnuplot, and so on and so on. There are a few nicer tools out there but they are very pricey as they're built for dealerships, not consumers or hobbyists, so they don't support mucking with CANBus messages either.
For newer vehicle security enthusiasts, there's Gravwell. Our CANBus ingester is being published open source. We've also created a native CANBus module for interpreting the fields from CAN messages. Using Gravwell, extracting the RPMs and dropping them on a chart looks like:
tag=canbus canbus ID==708 data | slice uint16be(data[0:2]) as rpm | mean rpm | chart mean
Getting a table of ID frequencies is done with `tag=canbus canbus | count by ID | table ID count`. Protip: sort by count asc for interesting IDs.
I spent some time reversing CAN messages for my vehicles and built out a dashboard of vehicle activity. Using this dashboard, I can keep an eye on my vehicle fleet, observe how my drivers are treating the vehicles, and use behavioral and predictive analytics to keep ahead of maintenance schedules. My teenagers are going to LOVE it.
Gravwell is extremely useful when working with binary data or exploring data that may not be familiar. These same techniques are how we're able to provide OT insights to that section of our customer base.
Try Gravwell
With Gravwell Community Edition, you are able to unlock the power of Gravwell at your place of work or in your Homelab. A license is free and allows you to ingest up to 13.9 GB a day of ingestion. Request a license by clicking on the button below.
For you Car Hacking hobbyists, once you are up and running, stop by our Discord and share questions or your build's success with the team:
