Automotive Security Testing Checklist

Is it really possible for hackers to remotely control all cars’ autonomous driving systems and connected vehicle terminals as depicted in “Fast and Furious”?

Automotive Security Testing Checklist

With the commercialization of 5G technology and the continuous advancement of intelligent and connected vehicles, the emergence of high-risk vulnerabilities in systems like Jeep Uconnect and BMW ConnectedDrive poses a threat to user safety and property. The security of intelligent connected vehicles has become a crucial factor in the rapid development of the Internet of Vehicles.Now, let us outline the attack surface for automotive security penetration testing.1. Attack Surface of Vehicles1. Physical Access1.1 OBD Online Diagnostic Interface (On Board Diagnostic interface)The OBD vehicle diagnostic system (Figure 1-1), also known as the Diagnostic Link Connector (DLC), is generally located in a concealed position between the vehicle’s clutch pedal and steering wheel. As the external interface of the vehicle, OBD can access the CANBus, allowing control over the vehicle through specialized control devices connected to the OBD port, even enabling modifications to certain driving computer configurations.Through the OBD interface, one can read the vehicle’s operational status data and perform active tests (controlling injectors or ignition systems). This interface allows direct access to the vehicle’s CAN bus, thereby fully controlling the vehicle’s physical functions.

Automotive Security Testing Checklist

Figure 1-1 Complete OBD Pin Connection for General VehiclesUsing the OBD interface to connect to a CAN analyzer allows for the analysis of message data.The CAN bus consists of nodes, IDs, messages, and arbitration.The CAN-Bus communication frame protocol has five types: data frame, remote frame, error frame, overload frame, and inter-frame.Data Frame:The frame start, arbitration segment, control segment, data segment, CRC segment, ACK segment, and frame end indicate the beginning of a frame, composed of a single bit of dominant level.(1) Frame Start:Indicates the start of the frame, composed of a single dominant bit. When the bus is idle, the sending node sends the frame start, and other receiving nodes synchronize to this frame start bit.

Automotive Security Testing Checklist

Figure 1-2 Detailed Explanation of CAN Messages(2) Arbitration Segment:CAN-Bus does not specify the priority of nodes, but the arbitration segment frame ID defines the priority of the data frame. The smaller the frame ID value, the higher the priority. Depending on the version of the CAN 2.0 standard, frame IDs can be either 11 bits or 29 bits.(3) Control Segment:Divided into standard format (IDE, r0, DLC) and extended frame (r1, r0, DLC).(4) Data Segment:Composed of 0 to 8 bytes, used for payload transmission data, with data output starting from MSB.(5) CRC Segment:Composed of a 15-bit CRC Sequence and a 1-bit CRC Delimiter, used to check for errors in the frame data. The CRC check value is stored in the CRC segment, consisting of a 15-bit CRC value and a 1-bit CRC delimiter.CRC Sequence: The CRC sequence is calculated over the SOF, arbitration domain, control domain, and data domain.CRC Delimiter: The CRC delimiter is a normal dominant bit.(6) ACK Segment:ACK (Acknowledgment Field) is 2 bits long, including ACK Slot and ACK Delimiter. ACK Slot: When the sending node sends data, it sets both the ACK Slot and ACK Delimiter to dominant. If the receiving node calculates the CRC Sequence correctly, it will send a dominant bit to the sender during the ACK Slot to acknowledge receipt. ACK Delimiter: The ACK delimiter is a normal dominant bit.(7) Frame End:Indicates the end of the frame, composed of 7 consecutive dominant bits.Remote Frame:Used for a receiving unit to request data from a sending unit with the same ID. ID: The ID of the requested sending node. SRR: 1 (dominant level). RTR: 1 (dominant level). DLC: The requested data length, with no data segment. The CRC check range is: frame start + arbitration segment + control segment.Error Frame:Used to notify other units of errors when detected, with five types of errors.(1) CRC Error: Occurs when the CRC value calculated by the sending node does not match the received CRC value.(2) Format Error: Occurs when the transmitted data frame format does not conform to any valid frame format.(3) Acknowledgment Error: Occurs when the sending node does not receive an acknowledgment signal during the ACK phase.(4) Bit Sending Error: Occurs when the sending node detects that the bus level does not match the sending level during transmission.(5) Bit Stuffing Error: Occurs when the signal transmitted over the communication cable violates the “bit stuffing” rule.Overload Frame:Used to notify other units that are not ready to receive data. When a receiving node is not ready to receive the next data frame, it will send an overload frame to notify the sending node. The overload frame consists of an overload flag and an overload frame delimiter. If multiple nodes are overloaded simultaneously and there is a timing issue in sending the overload frame, the overload flag may stack and exceed 6 bits.Inter-frame:Used to separate data frames and remote frames from the previous frame, but no inter-frame is inserted before overload frames and error frames.

Automotive Security Testing Checklist

Figure 1-3 Data Flow Processing in CAN-Bus Link LayerSo what can we do by accessing CAN?We can sniff CAN bus traffic, send CAN messages, replay CAN traffic, perform fuzz testing, and using the diagnostic tools of the CAN analyzer, we can see the actual RPM, vehicle speed, battery voltage, and other information. For example, if we want to deceive the RPM gauge, we can press the accelerator while in neutral to change the gauge’s value and then replay the data. We can also try to control the headlights, door locks, air conditioning, seats, etc.

Automotive Security Testing Checklist

Figure 1-4 CAN Analyzer1.2 In-Car Entertainment SystemThe automotive entertainment system generally uses Linux or Android-based operating systems. The in-car entertainment system interacts with CDs, USB interfaces, mobile phones, and headphones. The entertainment system is connected to the CAN bus, and the onboard multimedia system displays vehicle parameters (vehicle health, tire pressure, remaining battery power for electric vehicles, etc.). The entertainment system serves as the entry point for users to install system updates, including firmware upgrades for the vehicle’s ECU.1.3 Main Control PanelThe main control panel of the vehicle is generally the gateway system for smart vehicles. It can be disassembled to check for a TTL to USB interface. The system is generally based on Linux. By connecting through serial tools, testing can be conducted.2. Short-Distance Wireless Attack SurfaceShort-distance vectors include Bluetooth, in-car hotspots, Wi-Fi, keyless entry, tire pressure sensor RF signals, RFID, Dedicated Short Range Communications (DSRC), distance sensors, automatic parking systems, and GPRS, 3G, 4G, 5G communications between vehicles and base stations.2.1 BluetoothMobile phones connect to cars via Bluetooth, allowing calls to be output through speakers and multimedia to be transmitted, with a typical range of about 10 meters.Bluetooth Attack Schemes2.1.1 Bluetooth Vulnerability Attack (Bluesnarfing)Bluesnarfing allows attackers to exploit firmware vulnerabilities in older devices to access devices with Bluetooth enabled. This attack forces a connection to the Bluetooth device and allows access to data stored on the device, including the device’s International Mobile Equipment Identity (IMEI). The IMEI is a unique identifier for each device, and attackers may use it to route all incoming calls from the user’s device to the attacker’s device.2.1.2 Bluetooth Hijacking (Bluejacking)Bluejacking is an attack implemented on devices with Bluetooth enabled, such as mobile phones. Attackers send unsolicited messages to users of Bluetooth-enabled devices to initiate Bluejacking. The actual messages do not harm the user’s device, but they can entice the user to respond in some way or add new contacts to the device’s address book. This type of message-sending attack is similar to spam and phishing attacks on email users. When a user responds to a Bluejacking message with harmful intent, it can cause harm.2.1.3 Bluetooth Eavesdropping (Bluebugging)Bluebugging exploits a vulnerability present in the firmware of some older devices to gain access to the device and its commands. This attack allows the attacker to use the device without notifying the user, enabling access to data, making calls, eavesdropping on conversations, sending messages, and utilizing other services and functions provided by the device.2.1.4 Car WhispererCar Whisperer is a software tool developed by European security researchers that exploits a critical implementation issue in the Bluetooth hands-free car kit. The Car Whisperer software allows attackers to send audio to or receive audio from the car kit. Attackers can send audio to the car’s speakers or receive (eavesdrop) audio from the car’s internal microphone.2.1.5 Denial of Service (DoS)Like other wireless technologies, Bluetooth is also susceptible to DoS attacks. Effects include rendering the device’s Bluetooth interface unusable and draining the device’s battery. These types of attacks are not very significant, and because they require proximity to use Bluetooth, they can usually be easily avoided by simply moving out of effective range.2.1.6 Fuzzing AttacksBluetooth fuzzing attacks involve sending malformed or other non-standard data to the device’s Bluetooth RF interface and observing how the device reacts. If a device’s operation is slowed or stopped by these attacks, a serious vulnerability may exist in the protocol stack.2.1.7 Pairing EavesdroppingPIN code/traditional pairing (Bluetooth 2.0 and earlier) and LE pairing (Bluetooth 4.0) are both susceptible to eavesdropping attacks. Given enough time, a successful eavesdropper can collect all pairing frames, allowing them to determine the secret keys that allow trusted devices to simulate and actively/passively decrypt data.2.1.8 Secure Simple Pairing AttacksMany techniques can force remote devices to use immediate working SSP, then exploit its lack of MITM protection (e.g., the attacking device claims it has no input/output capabilities). Additionally, fixed universal keys may allow attackers to conduct MITM attacks.It is also possible to attempt to connect Bluetooth wireless keyboard and mouse devices to control the in-car entertainment system and perform some operations.2.2 In-Car Hotspot and Wi-FiSmart vehicles are equipped with IoT cards, and the hotspot can be activated through the entertainment system’s screen, similar to operating a mobile phone.The in-car system has a wireless network card, allowing users to create Wi-Fi configurations for the entertainment system to access wireless networks.In-car hotspots and Wi-Fi enable attackers and vehicles to be in the same network environment, allowing for ARP spoofing attacks.Using Ettercap for ARP spoofing, one can capture vehicle communication traffic with Wireshark.

Automotive Security Testing Checklist

Figure 2-1 ARP Spoofing Sniffing TrafficListening to the communication traffic between the vehicle and the outside world can capture and analyze the vehicle’s new firmware version when sent from the cloud.2.3 Keyless EntryThe keyless entry system allows the vehicle to be unlocked and started without using a mechanical key.When the driver triggers the system via a button or touch sensor, the vehicle sends a random signal to the key. The key receives the signal and uses an encryption algorithm to generate a response signal, which the vehicle receives and verifies for legitimacy, executing the corresponding operation, such as unlocking or starting the vehicle.Types of Keyless Entry Systems(1) Unidirectional RKE: Requires the manual pressing of a button to execute operations. The vehicle receives the signal and determines its legitimacy before executing the corresponding operation. For rolling code systems, a cryptographic secure pseudo-random number generator (PRNG) installed in the vehicle and key card is used to change the encryption key after the button is pressed, typically using a buffer to address accidental out-of-range button presses (false touches). Unidirectional RKE is the simplest and most common form of keyless entry system.(2) Bidirectional RKE requires the vehicle to send a signal for the key fob to respond to achieve unlocking.(3) Passive RKE (PKE) automatically unlocks when within a certain radius or when the user touches the door handle; typically paired with a button ignition switch.Regarding keyless entry security research, full-duplex SDR devices are needed to generate interference signals to block the vehicle and key from receiving the correct signals. The interference signal bandwidth will be wider, and the signal will be stored for later use. When the user presses the button again, the device captures the second signal and sends the first signal, allowing the vehicle to perform the operation normally, but one of the signals has already been captured.

Automotive Security Testing Checklist

Figure 2-2 Raspberry Pi-Based Keyless Entry Detection Device2.4 Tire Pressure Management System (TPMS)The tire pressure sensors in vehicles transmit collected tire pressure data to the management module via short-range wireless communication, issuing alarm information when the pressure is too low. The TPMS operates at frequencies of 315MHz/433MHz.Tire pressure sensors do not frequently send wireless data; they typically send such data when the sensor is installed or removed, or wait for the next signal transmission to capture. It is possible to test whether this signal is encrypted and conduct spoofing attacks, as the receiving ECU may encounter issues when parsing the code.

Automotive Security Testing Checklist

Figure 2-3 Composition of Tire Pressure Sensor SignalsTire pressure sensor signals consist of: preamble, sync code, ID recognition code, voltage, pressure, temperature, valve, CRC16, stop code.By modifying values too high or too low, alarms can be triggered, leading to vehicle alerts.2.5 RFIDAutomotive keys embed an RFID, and vehicles install RFID antennas. When the driver approaches or enters the vehicle, the RFID authenticates with the ECU. Hitag uses a 48-bit password, which is a widely used passive RFID.2.6 V2X Vehicle-to-Everything CommunicationCan be divided into three categories: V2V (Vehicle to Vehicle), V2I (Vehicle to Infrastructure), and V2P (Vehicle to Pedestrian). Transport entities, such as vehicles, roadside infrastructure, and pedestrians, can collect and process information about the local environment (such as information received from other vehicles or sensor devices) to provide more intelligent services, such as collision warnings or autonomous driving.V2X communication technology currently has two routes: DSRC and LTE-V2X.DSRC is based on the IEEE802.11p standard, using a reserved frequency band of 5.85GHz~5.925GHz for V2V/V2I communication with a 75MHz spectrum. The effective communication distance of DSRC devices is determined by the transmission power used. Roadside devices can transmit at higher power levels, with a maximum range of up to 1000 meters, while vehicles can only use lower transmission power, resulting in a lower communication distance of only 300 meters.

Automotive Security Testing Checklist

Figure 2-4 DSRC Technology DiagramLTE-V (Long Term Evolution-Vehicle) is a V2V solution based on TD-LTE technology. LTE-V is an evolution of the 4G LTE system, including two operating modes: LTE-V-Cell and LTE-V-Direct. LTE-V-Cell relies on existing cellular networks to support high bandwidth and wide coverage communication, meeting Telematics application needs; LTE-V-Direct can operate independently of cellular networks, enabling low-latency, high-reliability direct communication between vehicles and surrounding environmental nodes, meeting driving safety requirements.

Automotive Security Testing Checklist

Figure 2-5 LTE-V Technology DiagramTesters can purchase devices with DSRC functionality or use Software Defined Radio (SDR) to create their own DSRC receivers, which can receive relevant vehicle information such as size, location, speed, direction, and driving paths within the last 300 meters. This information can be used to track target vehicles.Assuming an attacker obtains the target vehicle’s manufacturer and model, they can place a DSRC receiver near the target’s home to remotely detect when the target vehicle leaves the range of the DSRC receiver, allowing the attacker to continuously track and identify the vehicle’s activities.Secure data transmission for V2V and V2I systems relies on PKI and CA, and attempts can be made for certificate hijacking attacks to intercept short-range communication information from vehicles.2.7 Vehicle Communication with Base Stations via GPRS, 3G, 4G, 5GSmart vehicles use IoT cards to communicate with nearby operator base stations, connecting to the internet. Programs like openbts, openbsc, and yatebts can be used to simulate base stations, intercept communication traffic, forge data packets, and conduct replay attacks, such as requesting website information or conducting penetration tests on some vehicle networking platforms, or attempting to modify parameters during man-in-the-middle attacks to see if they can interfere with or modify vehicle data.

Automotive Security Testing Checklist

Figure 2-5 OpenBTS Environment SetupStart asterisk, sipauthserver, smqueue, openbts, and the OpenBTS control console OpenBTSCLI for management configuration.In OpenBTSCLI, modify the gain (default minimum is 25)

OpenBTS> devconfig GSM.Radio.RxGain 25

Modify the GSM frequency band

OpenBTS> config GSM.Radio.Band 900

Modify the ARFCN parameters

OpenBTS> config GSM.Radio.C0 118

Enable GPRS

OpenBTS> config GPRS.Enable 1

Here, the network requested by the device communicates through the virtual network card sgsntun, so it is necessary to configure the iptables forwarding rules so that the connected devices can access the internet via GPRS.Check device connection status

OpenBTS> tmsis

And you can see

Automotive Security Testing Checklist

Figure 2-6 View Connected DevicesThe configuration of the base station setup will not be elaborated further.3. Long-Distance Wireless Attack SurfaceGPS, satellite receivers, digital broadcast receivers, and other public communication links, cellular networks, remote assistance systems, remote control systems, and dedicated vehicle networking platforms from manufacturers, as well as cloud servers. These long-distance attack vectors pose the greatest threat, as hackers can launch attacks from anywhere.

Automotive Security Testing Checklist

Figure 3-1 Vehicle Networking Management Platform

Automotive Security Testing Checklist

Figure 3-2 Vehicle Networking Management Platform4. A Real Automotive Security TestRecently, researchers conducted tests on a smart vehicle and would like to share some testing points.We first disassembled the vehicle’s main control panel and connected via USB to TTL to Gnd, Tx, Rx serial port set to 115200 baud rate for direct connection, allowing access to the SSH login entry of a gateway device. Unable to guess the password, we used GRUB to change the password.

Automotive Security Testing Checklist

Figure 1 TTL Serial Connection to GatewayDuring the boot process, hold down shift or esc to enter the GRUB interface:

Automotive Security Testing Checklist

Select the “Advanced options for Ubuntu” option

Automotive Security Testing Checklist

Select “Ubuntu, with Linux 5.0.0-32-generic (recovery mode)” and press e to enter:

Automotive Security Testing Checklist

Change “ro recovery nomodeset” to “quiet splash rw init=/bin/bash” as shown in the image above.

Automotive Security Testing Checklist

Press F10, wait a few seconds, and enter to change the password.

Automotive Security Testing Checklist

By leading out the RJ45 network cable through the serial port, connect to a laptop to configure IP, gateway, and subnet mask to access the gateway network, directly using tcpdump to capture traffic packets and analyze traffic logs, exposing the vehicle’s communication cloud URL.

Automotive Security Testing Checklist

Figure 2 Cloud URL of LogsCaptured data between the gateway and MCU was transmitted in plaintext, with no verification by the receiving party. By constructing data packet instructions, it was possible to cause a malfunction in the vehicle’s automatic parking system.

Automotive Security Testing Checklist

Figure 3 MCU Communication TrafficConstructed POC for vehicle automatic parking system alarm

Automotive Security Testing Checklist

Figure 4 Automatic Parking System Malfunction POCThe gateway system runs the vehicle firmware, which can be directly downloaded for analysis.

Automotive Security Testing Checklist

Figure 5 Vehicle FirmwareThe gateway system is a multi-network card Linux, and host alive detection can reveal that the T-BOX is 192.168.2.16 with an empty SSH password.

Automotive Security Testing Checklist

Figure 6 T-BOX Host PermissionsReferences:https://blog.csdn.net/huan447882949/article/details/80042417http://unicorn.360.cn/hackcube/forum.php?mod=viewthread&tid=48&extra=page%3D1https://kns.cnki.net/KCMS/detail/detail.aspx?dbcode=CJFQ&dbname=CJFDLAST2017&filename=CCGY201707011&v=MTE1NDV4WVM3RGgxVDNxVHJXTTFGckNVUkxPZVp1Wm5GeS9tVTdySUppN01kN0c0SDliTXFJOUVaWVI4ZVgxTHU=Original source: Waterdrop Security Laboratory

Leave a Comment