1Cars Penetration Testing Level 1 and Level 2 Explained
Level 1: Receivers To move on to the Level 1 diagram, pick a process to explore. Because we have only the one process in our diagram, let’s dig in to the vehicle process and focus on what each input talks to. The Level 1 map shown in Figure is almost identical to that in Level 0. The only difference is that here we specify the vehicle connections that receive the Level 0 input. We won’t look at the receivers in depth just yet; we’re looking only at the basic device or area that the input talks to.
Notice in Figure that we number each receiver. The first digit represents the process label from the Level 0 diagram in previous article, and the second digit is the number of the receiver. Because the infotainment unit is both a complex process and an input, we’ve given it a process circle. We now have three other processes: immobilizer, ECU, and TPMS Receiver. The dotted lines in the Level 1 map represent divisions between trust boundaries. The inputs at the top of the diagram are the least trusted, and the ones at the bottom are the most trusted. The more trust boundaries that a communication channel crosses, the more risky that channel becomes.
Level 2: Receiver Breakdown
At Level 2, we examine the communication taking place inside the vehicle. Our sample diagram focuses on a Linux-based infotainment console, receiver 1.1. This is one of the more complicated receivers, and it’s often directly connected to the vehicle’s internal network. In Figure, we group the communications channels into boxes with dashed lines to once again represent trust boundaries. Now there’s a new trust boundary inside the infotainment console called kernel space. Systems that talk directly to the kernel hold higher risk than ones that talk to system applications because they may bypass any access control mechanisms on the infotainment unit. Therefore, the cellular channel is higher risk than the Wi-Fi channel because it crosses a trust boundary into kernel space; the Wi-Fi channel, on the other hand, communicates with the WPA supplicant process in user space.
This system is a Linux-based in-vehicle infotainment (IVI) system, and it uses parts common to a Linux environment. In the kernel space, you see references to the kernel modules udev, HSI, and Kvaser, which receive input from our threat model. The udev module loads USB devices, HSI is a serial driver that handles cellular communication, and Kvaser is the vehicle’s network driver. The numbering pattern for Level 2 is now X.X.X, and the identification system is the same as before. At Level 0, we took the vehicle process that was 1.0 and dove deeper into it. We then marked all processes within Level 1 as 1.1, 1.2, and so on. Next, we selected the infotainment process marked 1.1 and broke it down further for the Level 2 diagram. At Level 2, therefore, we labeled all complex processes as 1.1.1, 1.1.2, and so on. (You can continue the same numbering scheme as you dive even deeper into the processes. The numbering scheme is for documentation purposes; it allows you to reference the exact process at the appropriate level.)
Ideally at this stage, you’d map out which processes handle which inputs, but we’ll have to guess for now. In the real world, you’d need to reverse engineer the infotainment system to find this information. When building or designing an automotive system, you should continue to drill down into as many complex processes as possible. Bring in the development team, and start discussing the methods and libraries used by each application so you can incorporate them into their own threat diagrams. You’ll likely find that the trust boundaries at the application level will usually be between the application and the kernel, between the application and the libraries, between the application and other applications, and even between functions. When exploring these connections, mark methods that have higher privileges or that handle more sensitive information.
Now that we’ve gone two levels deep into our threat modeling maps, we can begin to identify potential threats. Threat identification is often more fun to do with a group of people and a whiteboard, but you can do it on your own as a thought exercise. Let’s try this exercise together. Start at Level 0—the bird’s-eye view— and consider potential high-level problems with inputs, receivers, and threat boundaries. Now let’s list all potential threats with our threat models. Level 0: Bird’s-Eye View When determining potential threats at Level 0, try to stay high level. Some of these threats may seem unrealistic because you’re aware of additional hurdles or protections, but it’s important to include all possible threats in this list, even if some have already been addressed. The point here is to brainstorm all the risks of each process and input.
The high-level threats at Level 0 are that an attacker could:
- Remotely take over a vehicle
- Shut down a vehicle
- Spy on vehicle occupants
- Unlock a vehicle
- Steal a vehicle
- Track a vehicle
- Thwart safety systems
- Install malware on the vehicle
At first, it may be difficult to come up with a bunch of attack scenarios. It’s often good to have people who are not engineers also participate at this stage because as a developer or an engineer, you tend to be so involved in the inner workings that it’s natural to discredit ideas without even meaning to. Be creative; try to come up with the most James Bond–villain attack you can think of. Maybe think of other attack scenarios and whether they could also apply to vehicles. For example, consider ransomware, a malicious software that can encrypt or lock you out of your computer or phone until you pay money to someone controlling the software remotely. Could this be used on vehicles? The answer is yes. Write ransomware down.