Full Report
In the previous two posts, they got root access to the system by breaking the update functionality. So, now what? Let's build some software! ccOS(Connected Car Operating System) is an OS developed by Nvidia and Hyundai for all recent vehicles. While reading the OS, they found several header files for doing development on the OS! The author downloaded VS code, the G++ ARM cross compiler stack and a few other things in order to start compiling. They started off with a simple C++ program to view the status of the door using the library. That's pretty neat! From there, they made a slightly more complicated CLI interface to unlock and lock the doors using the known interface. To finish off the research, they built a simple GUI application with QT in order to pop a screen on the entertainment console. The only complication with this was registering the GUI app with the Helix package manager. With this, they could start up their application from the CLI to display on the screen! Overall, a good blog series on reverse engineering and getting a good setup for hacking. They may wrote more posts in the future, which I'd love to see.
Analysis Summary
# Tool/Technique: Custom Exploitation via ccOS/IVI Access
## Overview
This summary details the attacker's subsequent actions and custom tools developed after achieving root access to the vehicle's infotainment system (IVI), which runs the ccOS (Connected Car Operating System). The focus shifts from initial exploitation (detailed in prior posts) to developing custom software utilizing internal vehicle APIs made available via the compromised system's header files.
## Technical Details
- Type: Technique / Custom Tool Development (Proof-of-Concept)
- Platform: ccOS (Nvidia/Hyundai Connected Car Operating System), likely running on an ARM-based Linux environment within the IVI.
- Capabilities: Reading vehicle state (door status), executing vehicle commands (locking/unlocking doors), and displaying custom GUI applications on the infotainment screen.
- First Seen: Related to research published around May 2022, following prerequisite posts detailing initial access.
## MITRE ATT&CK Mapping
The described activities fall under post-exploitation and execution phases, leveraging existing system capabilities for malicious (or proof-of-concept) purposes.
- **TA0002 - Execution**
- T1059 - Command and Scripting Interpreter
- T1059.006 - Command and Scripting Interpreter: Python (though C++ was used, CLI execution is key)
- T1204 - User Execution
- **TA0005 - Defense Evasion**
- T1564.002 - Hide Artifacts: Hidden Files and Directories (Implied by placing custom apps in system directories like `/appdata/`)
- **TA0007 - Discovery**
- T1083 - File and Directory Discovery (Reading header files, exploring `/usr/include`)
- **TA0011 - Persistence**
- (Potential mapping if the custom app was intended to run automatically)
## Functionality
### Core Capabilities
1. **Reverse Engineering and Setup:** Installing necessary development tools (VS Code, G++ ARM cross compiler stack) targeting the ARM architecture of the IVI.
2. **API Interaction (C++ Headers):** Leveraging internal ccOS header files (e.g., `HBody.h`, `HChassis.h`) found in `/usr/include` to interact with vehicle subsystems.
3. **Status Checking:** Developing a CLI application to query vehicle status, specifically checking the open/closed state of doors using the `HBody` singleton and its `isDoorOpened` method.
4. **Action Execution:** Developing functionality to lock and unlock doors using known HAL interfaces (implied use of `HBody` methods for actuation).
### Advanced Features
1. **GUI Development:** Creating a custom Graphical User Interface (GUI) application using the **QT framework** designed to run on the IVI's entertainment console.
2. **Package Management Integration:** Successfully registering the custom GUI application with the **Helix Package Manager** by creating a custom `.appconf` configuration file (e.g., defining `Name`, `Exec`, and `AppView`).
3. **Application Launching:** Utilizing the pre-installed command-line utility **`appctl`** to initiate the custom GUI application via the command `appctl startAppView {componentName}`.
## Indicators of Compromise
Since this describes the setup of custom PoC tools rather than deployed malware, specific IOCs are related to the development environment and operational commands used:
- File Hashes: N/A (Custom compiled binaries)
- File Names: `HBody.h`, `HChassis.h` (Internal system files/headers), Custom compiled binary (e.g., `guiExample`), `.appconf` (Custom configuration file).
- Registry Keys: N/A (Linux-based system)
- Network Indicators: N/A (Operations were primarily local after gaining root access, though communication with the IVI services is implied).
- Behavioral Indicators:
* Modification of configuration directories (e.g., `/etc/appManager/appconf/`).
* Use of the native utility `appctl` with commands like `startAppView` or `emitEvent`.
* Successful compilation using an **ARM cross-compiler**.
## Associated Threat Actors
The actions described are associated with independent security researchers and penetration testers (in this case, the author "greenluigi1") focusing on proprietary operating systems in automotive environments. No established criminal threat group is linked to this specific technique set described in the article.
## Detection Methods
Detection would rely on monitoring system integrity and execution chains typical of system manipulation following initial compromise:
- Signature-based detection: N/A for custom binaries unless the specific compiled application signature is known.
- Behavioral detection: Monitoring for the introduction of new executable files into untrusted locations (`/appdata/`) or modifications to critical configuration directories (`/etc/appManager/`). Detection of the specialized `appctl` utility being used outside of maintenance windows.
- YARA rules if available: N/A.
## Mitigation Strategies
Mitigation focuses on preventing the initial root access and hardening the system against post-exploitation misuse of internal APIs:
- **Update Management:** Applying security updates patched by OEMs (e.g., the mentioned DAudio2 134.100.220927 update, which fixed the vulnerability used to gain access and removed development headers).
- **Restrict Write Access:** Ensuring the system partition (`/`) is mounted read-only or strictly enforcing mandatory access controls (MAC) to prevent unauthorized binaries from being placed in executable paths.
- **Application Sandboxing/Whitelisting:** Ensuring that the Helix package manager only loads and executes applications verified through rigorous cryptographic signing, preventing custom-compiled utilities from being launched via `appctl`.
## Related Tools/Techniques
- **Cross-Compilation:** Using ARM cross compilers is a common technique when targeting embedded systems or specialized hardware without having a native build environment.
- **Reverse Engineering Frameworks:** The general concept aligns with research exploiting proprietary systems like those found in automotive IVI units.
- **Appctl:** A specific OEM utility used for managing services on the ccOS; similar utilities exist on other proprietary embedded systems for application lifecycle management.