CVE-2015-2906 in OBD-II Dongle
Summary
by MITRE
** DISPUTED ** Mobile Devices (aka MDI) C4 OBD-II dongles with firmware 2.x and 3.4.x, as used in Metromile Pulse and other products, store SSH private keys that are the same across different customers' installations, which makes it easier for remote attackers to obtain access by leveraging knowledge of a private key from another installation. NOTE: the vendor states "This was a flaw for the developer/debugging devices (again not possible in production versions)."
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 11/07/2024
The vulnerability described in CVE-2015-2906 represents a critical security flaw in Mobile Devices (MDI) C4 OBD-II dongles that were deployed in automotive telematics systems including the Metromile Pulse platform. These devices operate as embedded systems that connect to vehicle diagnostic networks and transmit data to remote monitoring services. The flaw manifests in the firmware versions 2.x and 3.4.x where SSH private keys are hardcoded and reused across multiple customer installations, creating a persistent security weakness that undermines the fundamental principles of secure key management. This issue falls under the CWE-310 vulnerability category, specifically addressing cryptographic weaknesses related to the improper generation and storage of cryptographic keys. The vulnerability exists within the device's secure communication infrastructure, where the same private key is distributed to numerous installations, effectively creating a massive attack surface that adversaries can exploit.
The technical implementation of this vulnerability stems from poor security practices during the development phase of these automotive telematics devices. The SSH private keys are stored in a manner that makes them accessible to anyone who can obtain a copy from a single installation, essentially eliminating the security benefits of asymmetric cryptography. This flaw enables attackers to establish unauthorized connections to multiple devices simultaneously, creating a scalable attack vector that can compromise numerous vehicles and their associated data. The vulnerability is particularly concerning because it operates at the device level within the automotive ecosystem, where compromised systems can potentially lead to vehicle control manipulation or unauthorized data access. This weakness directly relates to the ATT&CK technique T1566, specifically the use of spearphishing attachments that can be leveraged to gain initial access to these devices, and T1071.004, which involves application layer protocols for command and control communications.
The operational impact of this vulnerability extends beyond simple unauthorized access, as it fundamentally compromises the security model of the entire telematics ecosystem. Attackers can leverage the shared private keys to infiltrate multiple vehicles simultaneously, potentially accessing sensitive driving data, location information, and vehicle diagnostics. The vendor's statement that this was a flaw for developer/debugging devices suggests that these production systems were not properly secured before deployment, indicating a failure in the security testing and validation processes. This vulnerability creates a persistent risk that cannot be resolved through simple updates, as the compromised keys would need to be replaced across all affected installations. The impact is particularly severe in the automotive industry where vehicle security is increasingly critical, and where compromised telematics systems can lead to privacy violations, insurance fraud, or even vehicle control manipulation.
Mitigation strategies for this vulnerability require immediate action to address the hardcoded cryptographic keys and implement proper key management practices. Organizations should replace the compromised SSH keys across all affected installations and implement dynamic key generation for each device during the provisioning process. The solution must incorporate secure key distribution mechanisms that prevent the reuse of cryptographic material across different installations, aligning with industry best practices for embedded system security. Additionally, the vulnerability highlights the need for robust security testing during the development lifecycle, particularly for IoT and automotive devices where security cannot be addressed as an afterthought. Implementation of secure boot processes, hardware security modules for key storage, and regular security assessments would prevent similar issues from occurring in future deployments, addressing the root cause of the vulnerability rather than merely patching symptoms. The incident underscores the critical importance of proper cryptographic key management in embedded systems and demonstrates how development shortcuts can create lasting security vulnerabilities in production environments.