The Mobile Devices C4 OBD2 dongle is the base model for several rebranded consumer devices, such as the Metromile pay-by-mile insurance dongle. These devices are plugged into a vehicle's on-board diagnostics port (OBD-II), usually located under the wheel. The device itself contains a GPS receiver, cellular chip, and on board microprocessors. When a user operates the vehicle, the device communicates with the vehicle's CAN bus and extracts information as needed by the device manufacturer (usually speed, braking, etc). The device then communicates via the cell network to the service provider to share data on the vehicle's operation. Access to the OBD-II port on a vehicle has been shown to provide an attacker with complete control of the vehicle's functions.
The status of some of the below vulnerabilities are disputed by the vendor. Mobile Devices asserts that the devices acquired by the vulnerability reporter were developer devices not intended for production use. As such, some of the vulnerabilities listed are not present in commercial devices. CERT/CC is unable to verify this claim, but we can confirm from the research presented to us that the devices acquired by the vulnerability reporters contain the list of vulnerabilities below.
CWE-306: Missing Authentication For a Critical Function
The device contains a number of debug services (telnet, ssh, http) enabled by default that are accessible remotely.
Vendor response: This was a flaw for the developer/debugging devices (again not possible in production versions) and is fixed (disabled) in recent releases.
CERT/CC analysis: According to the reporter, it's not clear if all customers are informed of this and have updated their device.
CWE-321: Use of a Hard-Coded Cryptographic Key - CVE-2015-2906
The device contains a number of services (telnet, ssh, http) enabled by default that are accessible remotely, possibly intended to be used for debug purposes. The device itself contains six ssh private keys (for the root account, update server, and for the device itself) which are the same across all C4 OBD-II dongles. If one key is extracted by an attacker, all C4 dongles are exposed to attack, because they share the same key and the dongle is not user-configurable.
Vendor response: This was a flaw for the developer/debugging devices (again not possible in production versions) and is fixed (disabled) in recent releases.
CERT/CC analysis: According to the reporter, it's not clear if all customers are informed of this and have updated their devices.
CWE-798: Use of Hard-Coded Credentials - CVE-2015-2907
The C4 dongle's ssh username and passwords are hard-coded and remain the same on all devices. An attacker with knowledge of the credentials may be able to gain access to any C4 dongles.
Vendor response: This was a flaw for the developer/debugging devices (again not possible in production versions) and is fixed (disabled) in recent releases.
CERT/CC analysis: According to the reporter, it's not clear if all customers are informed of this and have updated their devices.
CWE-285: Improper Authorization
The C4 dongle utilizes SMS administration to remotely update the device. SMS is an insecure protocol without any encryption or authentication. The device relies on a whitelist of phone numbers as a method of authorization.
Vendor response: Our guidelines specifies that customers in production should use a SIM card with no SMS support to prevent this issue.
CERT/CC analysis: According to the reporter it's not clear if all customers are informed of this and have disabled SMS.
CWE-345: Insufficient Verification of Data Authenticity - CVE-2015-2908
The C4 dongle does not validate updates to the device firmware. A remote, unauthenticated attacker may be able to upload arbitrary code to the device by directing the device to pull updates from an attacker-controlled server.
Vendor response: 1) This was a flaw for the developer/debugging devices, and was fixed in production version about 3 years ago. Developer versions still enable local.
2) This server security issue only occurs if SMS is enabled (or with old software - more than 3 years old)
CERT/CC analysis: According to the reporter, it's not clear if all customers are informed of this and have updated their devices.
Mobile Devices' OBD-II platform is used by a number of OBD-II resellers, and we have been unable to obtain a list of affected vendors (other than Metromile). We encourage any affected vendors not listed here or concerned customers to contact cert@cert.org and include VU#209512 in the subject line. CERT/CC is actively working with Mobile Devices to ensure all affected vendors are informed of these issues.
Metro Mile has released the following statement about these vulnerabilities:
In June, Metromile learned that several vulnerabilities were discovered in Mobile Devices (MDI) OBD-II dongles that could be used to compromise the devices remotely. Metromile worked with MDI to ensure that all common configurations of Metromile Pulse, used by our per-mile insurance customers, received OTA updates as soon as possible. By July 24th, MDI had released updated versions of its 2.x and 3.4.x firmware which resolved the discovered exploits. As of today, most devices have successfully downloaded and applied the appropriate firmware update and we expect the remainder of devices to be patched by mid-August. Most devices that have not yet taken the patch show no signs of network activity and have not contacted update servers since before updated firmware was made available.
MDI has released the following statement about these vulnerabilities:
Since our devices have access to vehicle electronics, security is a very serious topic in our company and we handle it with a high attention. Ensuring security is a never ending effort which is handled in 3 ways :
\t•\tR&D / anticipating security threats
\t•\tCompany security
\t•\tSecurity in production / deployment
Regarding the recent study: generally speaking our devices are sold to integrators, and provided with the maximum flexibility and openness for the development of applications. In the telematics industry our mission for 13 years has been to provide the most advanced tools to 1) allow innovation teams to implement and test their concepts and 2) deploy the solution to mass market.
So the tools – typically OBD Dongles and device management tools – have 2 modes
\t•\tA “development” mode in which it is very easy to implement a program to remotely communicate with the vehicle network and even control a vehicle like the researchers have been doing
\t•\tA “production” mode for the deployment phases which can be activated at any time and ensures protection, in which the devices local and remote access are closed and secured.
About this production mode: devices and device management tools are provided with mechanisms allowing to ensure security but it is usually our customers’ choice to decide when and how to activate them.
With the very recent concern of the industry regarding vehicle hacking, we are adopting a different approach to security handling.
In addition to providing a set of recommendations that allow to secure the devices, we offer a full security package which includes in standard all the mechanisms activated. In addition we are defining rules for activating automatically this package in deployment phases. The purpose of these rules is that there can’t be any deployment without all the security features activated. If you want to know more about this, we will posting updates on www.munic.io.
During summer we have been identifying – together with our customers – all the deployments that were made without activating all the security mechanisms and making sure the security pack gets applied to all vehicles that are concerned.
Telematics is posing an interesting and very important challenge to all the automotive industry: how can we ensure top security AND keep turning this whole industry into modern open platforms with evolving services ?
This is one of the topics we are deeply involved in at Mobile Devices and we will be communicating on.
The CVSS score reflects CVE-2015-2908. |