Open search

Testing kit

Finding security flaws in CAN devices

Beyond Security has developed a commercially available CAN application and device security testing kit. It consists of the security testing tool Bestorm and the CANbuster ECU simulator.

The HUD devices used in the setup (Photo: Beyond Security)

BESTORM IS A COMMERCIALLY SUPPORTED, multi-protocol, dynamic security testing tool. It is used in a lab environment to test application security during development or to certify software and networked hardware prior to deployment. It is used in the industry to secure aerospace, telecom, manufacturing, and financial applications and their infrastructure components. It is also used on these same systems by governments. For CAN security testing purposes, the tool is teamed up with the CANbuster, a device that simulates a vehicle electronic control unit (ECU) and which allows testing/fuzzing of individual system components in a lab setting.

For the purpose of demonstrating dynamic security testing (fuzzing), the company chose two of many available heads-up devices (HUD). Their internal workings were almost identical, having a STM32F103 processor, a few voltage and current regulators (MC1413BDG), and a CAN transceiver (TJA1050). The CANbuster device has to be connected to the HUD device, as well as to a Windows machine that has Bestorm installed and running.

Dynamic security testing of the CAN network

At this point the user should be able to turn on the system and see that the HUD device boots up. The CANbuster will simulate a real ECU by capturing requests being sent by the HUD device for certain parameters (like car speed) and responding with valid values.

Bestorm’s fuzzing mechanism is not affected by CANbuster's simulated environment. However, without the simulated environment, the HUD device will not accept incoming data. Stopping the simulated environment causes the HUD device to shut down, as it understands that the car engine / electrical system has been turned off. The fuzz testing consists of sending invalid (outside of the valid range), unexpected (incorrect response), and/or malformed (unrequested fields) messages back to the HUD device. The protocol being tested is OBDII (on-board diagnostic 2) over CAN. Depending on the HUD device, the CAN identifier that will be tested will be either 11 bit or 29 bit.

Illustration of how Bestorm and the CANbuster are set up (Photo: Beyond Security)

Results of CAN fuzz testing

The HUD devices that the company tested presented many fatal flaws in that they crashed repeatedly within minutes of starting the testing and their programming allowed inputs that presented as display and sound errors. These are the early indicators of problems that, with some further investigation, could result in the development of input that would assume some degree of control of the device.

Using Bestorm and CANbuster in this setup, any automotive system or device can be tested. The testing tool and ECU simulator are only sold to governments and manufacturers for their use in securing applications. However, the current low level of security in automotive use of the CAN protocol allows widely available fuzzers to also find problems that can then be developed into attacks.

Publish date

Beyond Security