Disclaimer. The disclaimer from the 1st in the series completely applies to this and all further additions to the series of articles.
The vehicle seemingly on a cursory review from the layperson is a mostly mechanical piece of equipment. The person may see the tires, door hinges, and part of the engine. The car provides a much more complete machine upon further and more in-depth examination. The computer networks and systems allow for many more endpoints and communications intra- and inter-vehicle than what had been experienced. The communication between the endpoints and the endpoints allow for points of attack where the system had not been hardened. Each attack vector noted may not be applicable across all of the manufacturer lines for all vehicles. The attack is dependent on the model’s information security architecture.
The attack surfaces for the vehicle have been getting much worse (Simonite, 2016). This is a function of the increased use of technology in the vehicles. In a recent study, 62% of people are worried their vehicle may be easily hacked (Vanian, 2016). The attack surfaces may be divided under separate facets, such as the equipment involved (Checkoway, McCay, Kantor, Anderson, Shacham, & Savage, 2011). As an example, this could be sectioned by the physical equipment (CD, DVD, USB, auxiliary jacks, touchscreens, and the head unit (HU)) or wireless attack vector (blue tooth, cellular, digital radio, GPS, WiFi (Koscher, Czechis, Roesner, Patel, & Kohno, 2010)).
An alternative would be to view the individual attack points. The vehicle’s diagnostic trouble codes (DTCs). Each manufacturer has their respective diagnostic codes, which are proprietary. The manufacturers and dealerships need these to read and manipulate reports, messages, and use these for informational purposes. Under normal conditions the DTCs are erased after checked three times and the soft DTCs may be cleared with a scan tool.
The vehicle can be fuzzed for DTC and freeze frame data, which is a temporary condition. The attacker may be able to view the proprietary interface with the proper tool. In this action, any unexpected items noted in the interface may be indicative of a vulnerability. This may also show nothing out of the ordinary.
The attacker may also monitor CAN Bus communication for data leakages. This may show enough data for the attacker to understand how the model’s components communicate with each other. This may be done with monitoring the CAN packets with an OBD connector. This would also show the size of the packets moving and the relevant data in the packet. The packets can also be grouped together to review for trends. The OBD-II port is much like an Ethernet jack. This connects to the different computer systems (Vanian, 2016). This is often used by mechanics to retrieve diagnostic information.
Each manufacturer has different equipment and protocols. As this is the environment, the attacker will have a varied set of tools to attack the different models and manufacturers. With the proper tools for each model, the packet flow is easier to read and analyze. This may show the accelerator pedal position, brake pedal status, fuel level, location, odometer, and many other data fields. After the initial review, the attacker may be able to message the CAN Bus and other the data in the fields. The attacker may be able to replay the packet.
The attacker may also modify the ECU. This mode of attack may be very effective. The attacker may use as the links a third party piece of equipment plugged into the OBD-II port, which is connected to the ECU. The ECU could be reprogrammed maliciously. The attacker could monitor the API calls on your laptop or watch and analyze the packets. The access, dependent on the model, maybe limited by an authentication algorithm. This may be bypassed by analyzing any keys being exchanged.
There may be the opportunity for a successful attack when the vehicle receives an update or patch. This update may be to the overall system, program, app, or functionality. At several points during the lifetime of the vehicle, there will be updates to the app, O/S, or other areas. Generally this is done through over the air (OTA), much like with your cell phone. These updates could be with .zip, .cab, .bin, .dat, .exe, or .dll files, dependent on the manufacturer. The update could be a few files or a bundle. Once the attacker knows the O/S, its architecture and how the updates are managed, the next step is to analyze the possibility to modify an update or create a new update packet. This may be difficult if the packet is sent in a secure communication channel (TLS 1.2 for now) and/or appropriate level of encryption.
Vehicles are connecting with each other at this point. This connectivity is not far-reaching yet as this is being actively tested across the US. As one vehicle drives in the far right lane on I-75, the vehicle would communicate with the other vehicles approaching the middle lane. This is much like the vehicles in I, Robot and other movies with driverless vehicles. This communication may be within the cellular network, IP traffic, dedicated short range communication (DSRC) or a hybrid method.
The standard security for these includes the cellular provider’s security already in place, encryption for the non-cellular traffic and other security measures. Each of these provides an avenue for attack or a vulnerability. As an example, the DSRC uses the 5.85-5.925 GHz band based on the 802.11p protocol.
The attacker could also look to the tire pressure monitoring system (TPMS). This was one of the first attacks, however it is still good to verify this vulnerability is closed. This communication from the tire to the ECU and may use Bluetooth or simple radio to communicate. The Bluetooth can use a secure communication channel. The attacks can sniff the communication from the TPMS. The signal is relatively weak, and the attacker needs to be proximate to the vehicle.
A recent attack involves the key fob for the vehicle. This uses a RFID for the key fob to communicate with the vehicle. This poses an opportunity for a vulnerability and an attacker to exploit. This uses a 315 MHz signal generally in North America. The code to unlock the vehicle is not sent in the clear text. Most late model vehicles use a rolling code or a challenge (e.g. a task such as a calculation). This traffic can be monitored and analyzed with a tool. This attack could jam the key fob signal to the vehicle. The owner would be unable to enter the vehicle. If the attacker had the time and a safe place to sit, the attacker could brute force the code. The attacker would need to write their own code using an SDR, customized hardware to do this, or a hybrid of this. There also is a known MitM attack available (Doctorow, 2015).
A new version of the attacks involves sideloading the attack. In this case there is a device infected with malware. This device is attached to the vehicle via Wi Fi or a cable of some form. The vehicle is then infected with the malware, virus, or ransomware. There may be MP3 malware from unauthorized downloaded music to infect the vehicle (Barry, 2011).
The late model vehicles do have available for review the addressable channels. This is more familiar as the remote telematics systems (Ford Sync, GM Onstar, Toyota Safety Connect, Lexus Enform, BMW BMW Assist, and Mercedez-Benz mbrace).
The hardware in the vehicle could be hacked. This is defined as physically manipulating some of the equipment. This may be shown as the attacker taking apart part of the dash to reach a port that needs to be modified or connected with. Other methods generally are much more covert. This avenue is not being fully explored at this junction due to the act being so overt, the mass amount of time generally needed for these, and the legal issues associated with physically touching and manipulating the tangible asset.
Learn more ways to protect your business at The National Cybersecurity Institute.
Barry, K. (2011, July). Can your car be hacked? Retrieved from http://www.caranddriver.com/features/can-your-car-be-hacked-feature
Checkoway, S., McCay, D., Kantor, B., Anderson, D., Shacham, H., & Savage, S. (2011, August 10-12). Comprehensive experimental analysis of automotive attack surfaces. USENIX Security 2011. Retrieved from http://www.autosec.org/
Doctorow, C. (2015, August 23). Car information security is a complete wreck-here’s why. Retrieved from http://boingboing.net/2015/08/23/car-information-security-is-a.html
Koscher, K., Czechis, A., Roesner, F., Patel, S., & Kohno, T. (2010). Experimental security analysis of a modern automobile. 2010 IEEE Symposium on Security and Privacy. Retrieved from http://www.autosec.org/
Simonite, T. (2016, January 26). Your future self-driving car will be more hackable. Retrieved from http://www.technologyreview.com/news/546086/your-future-self-driving-car-will-be-way-more-hackable/
Vanian, J. (2016, January 26). Security experts say that hacking cars is easy. Retrieved from http://fortune.com/2016/01/26/security-experts-hack-cars/
Charles Parker, II has been working in the info sec field for over a decade, performing pen tests, vulnerability assessments, consulting with small- to medium-sized businesses to mitigate and remediate their issues, and preparing IT and info sec policies and procedures. Mr. Parker’s background includes work in the banking, medical, automotive, and staffing industries.
Mr. Parker has matriculated and attained the MBA, MSA, JD, LLM, and is in the final stage of the PhD in Information Assurance and Security (ABD) from Capella University. Mr. Parker’s areas of interest include cryptography, AV, and SCADA.