A remote attack on an aftermarket telematics service
As a part of our ongoing research we decided to study the quickly evolving aftermarket telematics technology. During this study, led by our researchers Ron Ofir and Ofer Kapota, we stumbled upon a substantial cyber security vulnerability in the Zubie connected car service. This finding could allow an attacker to wirelessly and remotely influence a vehicle’s mission critical components such as the engine, brakes steering and others.
Before we dive into the details of our findings and discuss the possible attack scenario we’d like to assure you that we’ve duly approached Zubie and shared our findings with them according to our responsible disclosure policy. In the end – people’s safety is paramount! We’re happy that Zubie has seriously addressed this matter and took care of the problem. We were very impressed by Zubie’s professional attitude and concrete steps to address the issue.
Zubie is a leading connected car service that allows you, among other things, to track your driving habits, detect possible malfunctions in the vehicle and share your location with friends using a very intuitive mobile application. All this is made possible by hooking the Zubie device into the OBD-II port of your car. This device is communicating with the internal network of the vehicle and it also has a mobile GPRS modem that connects it to the Zubie cloud.
Hacking the device
The device is based on a Telit GE865 chip that provides the cellular connectivity and also provides a Python interpreter that enables users to run the actual application directly on the module. The first thing we’ve noticed about the Zubie device is that it had a port that looked like some kind of a maintenance port, embedded inside the OBD-II port (see image below).
After some research (mostly using the publicly available GE865 documentation) we have discovered that it was a +2.8V UART serial port. After translating its levels we were able to hook it up to a laptop using an RS232 connection and access its AT commands interface. For example we could list its files by using the command AT#LCSCRIPT:
The next step was to read all the files and decompile (using Decompyle++) the Python pyo files in order to get the original Python scripts. It seemed as if these scripts contained the entire Zubie application source code. Reading through this code, we learned the details of the communication protocol between the device and its cloud server and that this protocol supported remote over-the-air updates to the Zubie device.
We have found that every time the device is accessing its control server (in order to report about the status of the vehicle and such), it was open to receiving in response a configuration update via its “config_url” command. Upon such a response, the device would download the new configuration file which could contain instructions to update specific files on the device. This is done by downloading them from the server and replacing the current copy of the files with the new downloaded files.
Remote attack on the device
Since the entire communication was based on the non-secure HTTP protocol, the device was not verifying the authenticity of its control server. In addition, the downloaded software updates were not digitally signed. This means an attacker who was able to take over the server or its DNS address and could send malicious software updates to the in-vehicle device. One practical method of taking over the DNS address is to hijack the GPRS cellular connection between the device and its server by setting up a rogue base station and performing what’s commonly referred to as a “Man-In-The-Middle” attack.
We were able to execute such an attack and set up our own “malicious” server that communicated with the in-vehicle device and send it our own software updates by responding with config_url=config.tmp to its HTTP requests. This caused the device to download the new config.tmp configuration file that instructed the device to update its main boot_base.pyo file. The configuration file must also include the correct CRC of the files to update which can be calculated with Python’s crcmod module by:crc16 = crcmod.mkCrcFun(0x11021, 0xffff, True)
Taking control of the vehicle
We used this method to install a Trojan horse on the Zubie device that effectively allows us to take control over the vehicle. The OBD-II port commonly provides direct access, through the CAN bus, to the internal, most critical and sensitive systems in the vehicle. This means that our agent on the Zubie device was able to send out malicious messages over the vehicle’s bus. Doing so, we were able to influence some of the vehicle’s modules, like unlocking the doors and manipulating the instrument cluster. As our colleagues in the field have demonstrated, additional malicious influences on the vehicle may be performed, such as on the brakes, engine and steering. The more advanced the vehicle is, more of its systems are computer controlled, which means the damage such a breach can cause is even greater.
In addition, the Trojan we installed could also keep track of the vehicle’s location, track the driving behaviors and transmit this data to a third party. This clearly violates passengers’ privacy.
Once taken over, the Zubie device may have enabled an attacker to remotely take control of a Zubie equipped vehicle from anywhere in the world. Up till now awareness to cyber security issues in the automotive industry has been limited and definitely did not receive the same attention cyber security has received in other industry sectors. The case we brought here is just one out of potentially many and there will always be new vulnerabilities out there.
This is especially true today, as car connectivity is on the rise, there is a real need to bridge the gap between its tremendous inherent benefits and its potential hazards. This is why we believe the industry should adopt a proactive approach towards cyber security.