Vulnerabilities detected by Karamba’s VCode binary analysis tool and during Penetration Testing projects, and how they can be addressed
Karamba Security’s annual Threats and Vulnerabilities report (2023) includes both the findings of Karamba’s VCode binary scanning software and the results of the penetration testing. The research team analyzed both Rich OS (Linux/Android) and RTOS devices. VCode, a web-based tool for automotive and IoT software testing and SBOM creation, was used to scan firmware from hundreds of types of ECUs, while penetration-testing projects were performed on dozens of ECUs and vehicle types.
The research identified many weaknesses and risks, most of which are addressed with suggested mitigations in the report.
Rich OS
Scans of Linux and Android images exposed a variety of issues to be addressed, including the following:
- Each scanned ECU contained at least 20 tools that VCode defines as risky – for example: changing permissions, such as su and chmod, and compile or debugging tools, such as gcc and gdb. 60% of the ECUs contained many more, with 30 to 40 such tools in each.
- There were ten libraries (such as zlib, openssl, and glibc) for which high/critical vulnerabilities exist. 31% to 66% of the tested and scanned ECUs contain at least one of these libraries.
- Significant numbers of ECUs were found to contain binaries which lack security features such as stack canaries (100% of the tested ECUs), position-independent code (PIE, 40%), and relocation read-only (RELRO, 20%).
In addition, not surprisingly, infotainment systems emerged as a common entry point for attackers, with vulnerabilities in Bluetooth and Wi-Fi connectivity.
Penetration testing of Rich OS firmware revealed issues in these main categories:
- Improper security protocols or procedures implementation: “Bad Security Practices”, the most prevalent problem, constitutes over 40% of the findings.
- Incorrect configuration settings: “Misconfiguration” accounts for over a quarter of the issues.
- In addition, close to 15% of the findings centered around various “Missing Security Capabilities”.
RTOS
The scanned AUTOSAR/RTOS systems exhibited issues to be addressed in four categories:
1. Common Security Weaknesses
- Missing stack canaries: As the name suggests, stack canaries act as an early-warning system, utilizing a randomly generated value placed on the stack, which functions as a sentinel against buffer overflow attacks. When stack canaries are missing, the application is susceptible to attacks that could overwrite the return address or other important stack contents, leading potentially to arbitrary code execution.
- Insertion of Sensitive Information into Debugging Code: This vulnerability occurs when developers inadvertently leave sensitive information such as passwords, encryption keys, or personal data within debugging code. This could lead to unintentional exposure of sensitive data.
- Excessive McCabe Cyclomatic Complexity: McCabe’s cyclomatic complexity is a metric used to measure the complexity of a program. Excessive complexity can make the code difficult to understand, maintain, and test, increasing the likelihood of errors and vulnerabilities.
- Other findings, such as: Missing checks for error state of a conversion from string to a numeric value; Suspicious data/crypto functions; Other potentially dangerous functions (see Unsecure Functions below), and functions that call themselves, either directly or indirectly.
2. Matches to the Common Weakness Enumerations (CWE) Database
Findings include:
- CWE-1121: An improper check for unusual or exceptional conditions. This means the system or application doesn’t adequately anticipate or handle exceptional states, which can lead to unexpected behavior.
- CWE-120: Known as “Classic Buffer Overflow”. This occurs when a program writes more data to a buffer than it is allocated to hold, which can corrupt data, crash the program, or allow the execution of malicious code.
- CWE-327: Broken or Risky Cryptographic Algorithm used, raising the high likelihood of exploitation.
3. Violations of the AUTOSAR Requirements
An open, highly-popular and evolving standard, AUTOSAR defines a multi-layer automotive architecture for use by OEMs and Tier-1 suppliers.
- AUTOSAR-M18.0.5: This could be a metric indicating widespread non-compliance with memory management conventions. Since the percentage is extremely high, it might reflect a systemic issue with how memory is allocated, managed, or released in ECUs, leading to potential risks of memory leaks or buffer overflows.
- AUTOSAR-M18.0.3: This violation might point to issues in the communication protocol adherence, such as errors in CAN (Controller Area Network) or LIN (Local Interconnect Network) communications, and unreliable exchange of information.
4. Unsecure Functions
VCode identified risky functions such as memset/memcpy/memmove, sprint/vsnsprintf, abort and longjmp.
In RTOS penetration tests, key issues identified fall into three groupings:
- The majority of issues, crossing the 90% mark, were related to Unified Diagnostic Services (UDS) configuration.
- Accounting for more than half of the findings were keys and certificate-related issues, indicating challenges with encryption and authentication mechanisms.
- In a small number of findings, the researchers encountered security access issues: unauthorized access or control of vehicle systems.
Recommended Actions
Recommendations provided in the report include specific and organization-wide activities, such as:
- Immediate actions: - Revise faulty UDS protocol implementations in ECUs to restrict reset functionality to appropriate operational modes. - Encrypt all keys used in the automotive system, using robust encryption standards. - Replace weak key calculation algorithms with more robust, complex, and industry-standard algorithms.
- Scan 3rd-party libraries and keep them updated, after ensuring that the update mechanism is secured.
- Introduce multi-layered security protocols to reduce the reliance on a single key for system security; Review keys and passwords definition and storage to overcome a “false sense of security” due to misuse.
- Verify compiler, linker and OS security configurations.
- Identify and remove risky tools from the development stage before production.
- Consider advanced binary protection controls, especially if frequent patching is impossible.
- Use dynamic analysis tools, pen-testing, and fuzzing techniques to expose risks and vulnerabilities posed by new combinations of attack vectors.
- Implement secure key management practices, including secure key generation, storage, and destruction protocols.
- Create a monitoring, evaluation, prioritization, and patching mechanism, as required by UN regulations UN R155 (vulnerability management) and UN R156 (patching).
Conclusions
The report highlights the essential need for continuous advancement in cybersecurity measures within the automotive industry. It is evident that traditional security protocols need to be re-evaluated and reinforced to counteract the evolving nature of cyber threats.
Implementing robust encryption, secure authentication mechanisms, and regular security audits is no longer optional but imperative for the safety and integrity of automotive systems, as well as expansion of CSMS protocols across the industry.
Collaborative efforts among manufacturers, suppliers, and cybersecurity experts are vital to developing resilient defense mechanisms, safeguarding against potential cyber-attacks, and ensuring road safety and privacy.
For additional details, request your copy of the full report using the Download button below.
