Unsolicited Response Podcast: Rios on WhiteScope and Medical Device Security

Billy Rios of Laconicly joined me on the Unsolicited Response Podcast to discuss two topics:

  1. WhiteScope – an online ICS/SCADA whitelist that is trying to solve the last mile supply chain problem until vendors start signing their code. The WhiteScope data repository is available to all, free of charge.
  2. Medical Device Security – an area that Billy is a pioneer on. We discuss progress, FDA involvement and how similar or different it is as compared to the classic SCADA/DCS/Process Control.

Attacking CANBus – Part 2

In part 1 we looked at what CAN is and what the difference between CAN and OBDII traffic is on a vehicle network. In this part we’re going to look at simple reverse engineering techniques to determine which CAN IDs are of interest to us. For this exercise, we’d like to see if we can confuse the tachometer display.

First, we need to identify which ID Toyota is using for the Engine RPM on the CAN. Manufacturer specific IDs are not published so we’re going to have to figure it out ourselves. For this work, I hooked up my beaglebone canbus tool (you can build your own by following instructions here: https://github.com/digitalbond/canbus-beaglebone). Then I started my truck and let it run for about 15 seconds before powering it off. Dumping all CAN messages shows us a lot of traffic and it can be difficult to make sense of what’s going on. We’re going to use the unique_ids tool (part of the canbus-utils repo available at https://github.com/digitalbond/canbus-utils) l to get a list of all of the IDs that were seen while the tool was running. My list was:


We need to do some filtering and looking at the data to identify which data bytes are of importance. We’re going to be using the watch_id tool that I wrote. Cheating, we’ll start by looking at ID 0x2C4. The bytes that change are color coded red for ease of display. Some fields may be a single byte, multiple bytes, or have multiple values in a bitmask.

$ node watch_id.js –id 0x2c4

The results from the tool were:


Looking at the results we can see that the first two bytes remained at zero until a point where they increase and remain steady at around 0x08CC (2252 decimal). The 5th byte goes from zero to 08 and then never changes. The last byte changes frequently. Later, the 4th byte changes from 0x10 to 0x0F.

We can figure that the first two bytes are a 16 bit integer, the 4th byte contains some kind of bitmask, the 5th likely contains a bitmask or flag, and the 4th is a single byte integer. Converting the first two bytes to a decimal integer we see that it appears to be a direct value of the current engine RPM which starts at 0, ramps up, and then settles lower as the engine comes to idle. We correlate this with the readout from the tachometer and can be pretty confident that we’ve found the RPM.

In this case, the RPM was a direct value. For other values (or even other manufacturers) there may be a static value or formula applied to get the proper result (e.g. RPM=bytes 1&2 + 1k). Now, we know the ID and packet formula for the RPM on the CAN. We can write a little tool that spams the bus with our “attack” messages in order to confuse the tachometer into displaying an incorrect value.

S4x16 Moves To South Beach

Save the date: S4x16 is January 12-16

S4x16 is moving to the Fillmore Miami Beach at Jackie Gleason Theater in the heart of South Beach. It’s literally 3 blocks from the beach, 1 block from Lincoln Road and right in the middle of all the SoBe restaurants, shops and night life.

This is a classic art deco venue where The Dick Clark Show, The Ed Sullivan Show and the Miss USA and Miss Universe Pageants were often filmed in the auditorium. In 1964, Jackie Gleason even moved his hugely popular tv show there, hence the name.

In 2007, the Jackie Gleason Theater underwent a major renovation and now has state of the art lighting, sound, video and just about any staging option we can think of — all without losing that cool art deco feel that is South Beach. In fact, the planning team is feeling the challenge of coming up with unique content, formats and staging worthy of this non-traditional ICSsec conference facility.

You often hear this security professional or that automation engineer is a “rock star”. At S4x16 we will see who the real rock stars are on a real stage that today is a major concert venue. Speakers will literally be in the spotlight on the big stage.


In addition to the main theater, the venue has so many interesting rooms for us to use. For example, the ICS Village will be held in the Red Star Lounge, a VIP lounge for concerts with coffee and cocktails and comfortable couches and tables to better get to know your fellow S4 attendees. Much like the staging, taking full advantage of all the rooms is a fun, creative challenge.

The Kimpton Surfcomber will again be an official S4x16 hotel, and it is only a 3 block walk to the Fillmore Miami Beach at Jackie Gleason Theater. Attendees raved about this hotel last year … except for the bus ride to Kovens. No buses for S4x16!


Note: We want to publicly thank the Kovens Conference Center that has been the home of S4 since the inaugural event back in 2007. They did a fantastic job for us each and every year. Unfortunately we outgrew the ballroom there and wanted to move somewhere that buses were not required. We highly recommend Kovens if you need a South Florida venue for an event.

Attacking CANBus – Part 1

I thought I’d take a step back after releasing tools and presenting on CAN to do a quick intro into what communications are going on inside a vehicle anyway. What is CANBus? What is OBDII? Is there a difference?

We’re going to skip all the electrical fun parts, the packet formats, and the theory and move right into using some tools to look at CAN traffic. This means my language is simplified for example purposes. For this exercise I’m going to be analyzing traffic from my 2013 Toyota Tundra.

This is CANBus (image courtesy Wikipedia):

As you can see, it is a bus. We have a bunch of systems on a 2 wire bus. Each system has a particular job. In the case of a vehicle that might be the Engine controller, instrument display, or the tire pressure sensor. CAN is also used in industrial control as well.

This is what CAN traffic looks like:

630   [8]  17 00 00 00 00 00 00 00
638   [8]  13 00 1E 00 00 00 00 00
440   [8]  42 02 00 00 00 00 00 00

The first number is the ID or address of the device sending the message (e.g. 0x630, 0x638). This is not unlike an ethernet MAC address or an IP address. The following numbers are the data bytes (up to 8 per message).

ANY device on the CAN is able to view and send a message to ANY ID. Therein lies the entire problem with vehicle security. There is zero authentication, verification, non-repudiation, or any other accountability whatsoever. Anything on the bus can pretend to be anything else per the spec. Further, you only have 8 bytes of data so adding in something like encryption or cryptoverification is particularly challenging. Basically in order to not suck we have to ditch the whole thing (sound familiar ICS people?).

Ok so that’s CAN in a nutshell. What is OBDII? OBDII is a standard SUBPROTOCOL to CANBus. It’s a set of ID’s that all the vehicle manufacturers must support.

Every manufacturer builds their cars differently. In a vehicle, for example, the RPM may show up on the CANBus on ID 0x2C4 as a 16-bit integer on bytes 1 and 2. Another manufacturer may decide to put the RPM on CAN at ID 0x310 bytes 7-8. OBDII is an attempt to create a standard method of finding out that information. Rather than standardize on IDs, however, a query/response system was created.

The method for obtaining the engine RPM via OBDII is:

  1. Diagnostic tool sends a message on ID 0x7DF, the standard OBDII query ID. The message contains the number of additional data bytes, the “Mode”, and the “PID” of the requested information.
    For querying the RPM the Mode is 1 and the PID is 0x0C. The message would look like:
    0x7DF [8] 02 01 0C 00 00 00 00 00
  2. The modules in a vehicle respond to these diagnostics messages. The ID for the response depends on the module but the IDs start at 0x8 higher than the standard query ID. Thus, the ECU responding to an RPM request will respond on ID 0x7E8. The message contains the number of data bytes, the mode + 0x40, the PID, and the value.
    For responding to RPM the Mode is 0x41, the PID is 0x0C. That message may look like:
    0x7E8 [8] 03 41 0C 09 C4 00 00 00

In summary, OBDII is simply a sub-protocol that runs on top of CAN. It uses standardized CAN IDs and message formats to request vehicle information. The problem with plugging in third party dongles to the OBDII port is that that port still gives you direct CAN access. The OBDII port can be used to write arbitrary CAN IDs to the bus. In practice, this is used to do things like provide vehicle software updates (e.g. flashing new firmware to the ECU).

An attacker is not interested in the OBDII spec or most of the information it provides. An attacker is not interested in querying a vehicle for diagnostic information. Instead, an attacker wants to see what kind of control over vehicle operations is possible by writing to the CAN.

In part two of this series, we’ll do some CANBus reverse engineering to figure out what CAN messages we have an interest in if we want to cause the vehicle to behave erratically.

iSight Partners Acquires Critical Intelligence

meBelden buys Tofino, GE buys Wurldtech, Lockheed Martin buys Industrial Defender and now iSight Partners acquires Critical Intelligence. The trend continues of larger organizations buying ICS security expertise.

Bob Huber and Sean McBride left Idaho National Labs (INL), after being involved in setting up what became ICS-CERT, to form Critical Intelligence. Critical Intelligence in many ways competed, or augmented if you want to play nice, the information ICS-CERT provided. However, the depth and breadth of the Critical Intelligence product far exceeded what ICS-CERT provided. Whether this was due to the talent disparity, fewer restrictions on what could be written, or both is not known.

I spoke with Bob and Steve Ward of iSight yesterday to understand the motivation for partnering and what future ICS services, products and events will look like. It is too early to answer the later question, but the motivation was clear.

iSight is looking to improve their threat intelligence in the ICS area, basic and easily understood reason. From a Critical Intelligence standpoint it’s more interesting. iSight has 200+ analysts that speak 16 different languages.

  • A lot of the important ICS threat info is written in Chinese, Russian and Arabic, not to mention the videos and podcasts that require the ability to understand the spoken language.
  • A fair amount of the technical analysis of malware and other attack code is not ICS specific. Look at the work that Kyle Wilhoit is doing over at Trend Micro on Havex and Black Energy for an example.
  • iSight has a methodology that will add rigor to the analysis and reporting process.

What iSight was missing was an understanding of what matters in an ICS, who are the players, important protocols and products, and the ability to task all those resources in a smart way that would lead to useful product. If the two companies can integrate the capabilities well the result should be more than the sum of the parts.

The biggest question then will be are the asset owners able to take in and act on this better threat intel?

Admittedly I’m a big fan of Critical Intelligence’s work. They helped with content on our site for a couple of years, were guests on the podcast, speakers at S4 and one of the people I talked to when I was trying to figure out who was doing what to whom.

Another thing this latest acquisition has in common with the other ICSsec acquisition is the price and terms were not disclosed.

Congratulations to Bob and Sean and the rest of the team at Critical Intelligence.