Exploit for vehicle-subsystem-security-assessment

Name: Exploit for vehicle-subsystem-security-assessment
Rating: 5 (78 reviews)
2026-06-10 | CVSS 6.2
## https://sploitus.com/exploit?id=20B0B80E-8F18-519B-9C29-A0CDC6C4AEEC
# 🚗 End-to-end security assessment of vehicle subsystems

[! [Methodology](https://img.shields.io/badge/Methodology-ISO%2FSAE_21434-blue)](https://www.iso.org/standard/70918.html)
[! [Python](https://img.shields.io/badge/Python-3.11+-green)](https://python.org)
[! [Docker](https://img.shields.io/badge/Docker-Compose-blue)](https://docs.docker.com/compose/)
[! [License](https://img.shields.io/badge/License-MIT-yellow)](LICENSE)

**Professional-grade Vehicle Cybersecurity Assessment Platform**, demonstrating the complete ISO/SAE 21434 security engineering workflow: TARA analysis → vulnerability assessment → vulnerability exploitation → defense → intrusion detection.

> 🎯 Built specifically for cybersecurity engineers entering the automotive security field. Demonstrates real-world vehicle security skills applicable to Chinese automotive OEMs and Tier-1 suppliers.

## 📋 Catalog.

- [Project Conduct Process](# - Project Conduct Process)
- [Architecture](#-Architecture)
- [Quick Start](#-Quick Start)
- [Project Structure](#-Project Structure)
- [Phases](#-Phases)
- [Vulnerability Matrix](#-Vulnerability Matrix)
- [Attack Demo](#-Attack Demo)
- [Defense Results](#-Defense Results)
- [IDS Detection](#-ids-detection)
- [Tools](#-Tools)
- [Skill Show](#-Skill Show)

## 🗺️ Project Conduct Process

The execution of this project strictly follows the vehicle network security engineering process specified in the ISO/SAE 21434 standard, building a complete vehicle subsystem from scratch, and then progressively completing security assessment, attack verification, defense hardening, and intrusion detection.

### Overall methodology

``##
Environment build → TARA threat analysis → vulnerability assessment → attack exploitation → defense implementation → intrusion detection → final report
(Step 1) (Step 2) (Step 3) (Step 4) (Step 5) (Step 6) (Step 7)
``

### Detailed execution steps

---

#### 🔧 Step 1: Build the simulation environment (`environment/`)

**Objective**: build a complete remote vehicle control subsystem containing the full link from the cloud to the CAN bus.

| Substeps | What to do | Output | Verification Methods |
|:---|:---|:---|:---|
| 1.1 | Write `docker-compose.yml`, define 5 services (PostgreSQL, EMQX, Cloud API, T-BOX, ECU) | `docker-compose.yml` | `docker compose up -d` All started successfully | | 1.2 | Develop
| 1.2 | Develop **Cloud API** (Flask) to implement 20+ REST endpoints for user authentication, vehicle management, remote commands, etc. | `cloud-api/` All code | `curl` Test register/login/send commands |
| 1.3 | Develop **T-BOX gateway** (Python) for MQTT ↔ CAN bi-directional bridging | `tbox-simulator/` All code | MQTT messages are correctly forwarded to CAN bus |
| 1.4 | Develop **ECU simulator** (Python) for body control + UDS diagnostic service | `ecu-simulator/` All code | CAN messages trigger correct vehicle state changes |
| 1.5 | Write `setup.sh` one-click deployment script + SQL seed data | `setup.sh`, `init-db.sql` | Execute `. /setup.sh` and end-to-end command flow works |
| 1.6 | Develop 3 security assessment tools | `tools/` all code | each tool runs independently and produces results |

**The key to this step**: 19 vulnerabilities** (V-01 through V-19) were intentionally planted in the code** that mimic common security flaws in real vehicle systems to provide targets for subsequent security assessments and attack demonstrations.

---

#### 📊 Step 2: TARA Threat Analysis and Risk Assessment (`tara/`)

**Objective**: perform a systematic threat analysis and risk assessment of the system built in step 1 according to ISO/SAE 21434.

| Substeps | Output Documentation | Content |
|:---|:---|:---|
| 2.1 | `project-definition.md` | System description, architecture diagram, data flow diagram (DFD), external interfaces, communication protocols, security assumptions |
| 2.2 | `asset-inventory.md` | Identify 25 security assets (data/functional/communication/physical/software) and assign a C/I/A rating to each | 2.3 | `asset-inventory.md` | Identify and assign a C/I/A rating to each
| 2.3 | `threat-scenarios.md` | Identify 26 threat scenarios using the STRIDE methodology and build an attack tree | 2.4 | `threat-scenarios.md` | Identify 25 security assets (data/functional/communication/physical/software) and assign a C/I/A rating to each
2.4 | `attack-paths.md` | Describes each step of four high-risk attack paths in detail, labeling existing security control points | 2.5 | `threat-scenarios.md` | Identifies 26 threat scenarios using the STRIDE methodology to build an attack tree.
| 2.5 | `risk-assessment.md` | 5×4 risk matrix (Impact I0-I3 × Feasibility E0-E3) with R1-R4 ratings | 2.6 | `attack-paths.md` | Detailed description of each step of the 4 high-risk attack paths, with existing security control points labeled
| 2.6 | `security-requirements.md` | Derivation of 22 security requirements from R3/R4 risks, creation of traceability matrix | 2.7 | `risk-assessment.md` | 5×4 risk matrix (impacts I0-I3 × feasibility E0-E3)

**Expected results**: 15 R4 (severe) risks + 11 R3 (high) risks, clear baseline of security requirements.

---

#### 🔍 Step 3: Vulnerability Assessment (`assessment/`)

**Objective**: perform systematic security testing of every component of the system to discover and document all vulnerabilities.

| Sub-steps | Test Objects | Test Methods |
|:---|:---|:---|
| 3.1 | Cloud API | Authentication Bypass Testing, BOLA Testing, SQL Injection, JWT Weakness, Rate Limiting, CORS, Error Handling |
| 3.2 | MQTT Broker | TLS Configuration Check, ACL Testing, Subject Enumeration, Credential Strength, Message Injection | 3.3 | TQTT Broker | TLS Configuration Check, ACL Testing, Subject Enumeration, Credential Strength, Message Injection
| 3.3 | T-BOX Gateway | Port Scanning, Credential Extraction, CAN Interface Accessibility, Firewall Rule Analysis | 3.4 | CAN Interface Accessibility, Firewall Rule Analysis
| 3.4 | CAN Bus | Sniffing and Protocol Reversal, Message Injection, Replay Attacks, DoS Flooding, UDS Service Enumeration | 3.5 | Aggregate | T-BOX Gateway | Port Scanning, Credential Extraction, CAN Interface Accessibility, Firewall Rules Analysis
| 3.5 | Aggregation | Generate Vulnerability Matrix (19 vulnerabilities with CVSS scores, reproduction steps, remediation scenarios) + Attack Chain Mapping

---

#### ⚔️ Step 4: Attack Exploitation (`exploitation/`)

**Objective**: develop a runnable PoC attack script to validate the actual harm of the vulnerability from the attacker's perspective.

| Attack Scenarios | Exploit Vulnerability | Attack Link | Run Command |
|:---|:---|:---|:---|:---|
| **Remote Control Chain** | V-01, V-04, V-05, V-06 | Low-privilege login → BOLA overpass → Unsigned command injection → Take control of someone else's vehicle | `python exploit.py --base-url http://localhost:5000` |
| **CAN injection** | V-15, V-16 | Direct connection to vcan0 → Reverse CAN protocol → Inject forged messages → Control doors/engine | `sudo python can_inject.py --channel vcan0` |
| **MQTT injection** | V-11, V-12, V-13, V-14 | Steal credentials → connect to Broker → issue forged commands → fleet-level impact | `python mqtt_attack.py --host localhost` |
| **UDS Exploit** | V-17 | Enumerate UDS Services → XOR Crack SecurityAccess → Read/Write DID → ECU Control | `sudo python uds_exploit.py --channel vcan0` |

---

#### 🛡️ Step 5: Defense Implementation (`defense/`)

**Objective**: implement the security requirements derived in step 2, fix all vulnerabilities, and verify the effectiveness of the defense.

| Substeps | Hardened Content | Fixed Vulnerabilities |
|:---|:---|:---|
| 5.1 | **API Hardening**: add Ownership Authentication Middleware, Password Policies, Rate Limiting, HMAC Signatures, Parameterized Queries, CORS Limitations, OTP Authentication, RBAC | V-01 to V-10 |
| 5.2 | **MQTT Security**: enable TLS, per-vehicle independent credentials, topic-level ACLs, message signature verification | V-11 through V-14 | 5.3 | **MQTT Security**: enable TLS, per-vehicle independent credentials, topic-level ACLs, message signature verification
| 5.3 | **CAN SecOC**: Enforce secure in-vehicle communication (counters + AES-CMAC) to prevent replay and injection | V-15, V-16 | 5.4 | *MQTT Security**: Enable TLS, per-vehicle independent credentials, subject-level ACLs, message signature validation
| 5.4 | **Gateway Filtering**: CAN ID whitelisting, frequency restriction, content validation, source authentication | V-15, V-16 (enhanced) |
| 5.5 | **Validation**: retest with attack scripts from step 4 → Generate pre- and post-enforcement comparison report | `validation-results.md` |

**Expected Results**: **90.5% of attacks completely blocked**, remaining 9.5% mitigated to acceptable residual risk.

---

#### 📡 Step 6: Intrusion Detection System (`ids/`)

**Objective**: build a multi-layer IDS to achieve real-time detection of attacks and cross-layer correlation analysis.

| Components | Functionality | Detection Capability |
|:---|:---|:---|
| `can_ids.py` | CAN Bus Anomaly Detection | Whitelist Filtering, Frequency Anomaly, Content Checking, Sequence Anomaly |
| `mqtt_ids.py` | MQTT Traffic Monitoring | Authentication Monitoring, Subject Access Monitoring, Message Frequency, Load Checking |
| `api_monitor.py` | API Attack Detection | Brute Force Detection, BOLA Detection, SQL Injection Detection, Endpoint Scanning Detection | `correlation_ids.py` | MQTT Traffic Monitor
| `correlation_engine.py` | Cross-layer correlation engine | 7 attack chain pattern matching, duplicate alarm suppression, confidence calculation | `dashboard.py` | API attack detection | Violent crack detection, BOLA detection, SQL injection detection, endpoint scan detection
| `dashboard.py` | Endpoint real-time dashboard | Three-layer status panel, real-time alarms, attack chain timeline |

**Expected results**: **85% detection rate**, false alarm rate below 5%, average detection delay 2.3 seconds.

---

#### 📝 Step 7: Final Report (`report/`)

**Objective**: to produce a two-tier report for management and technical teams.

| reports | readers | content |
|:---|:---|:---|
| `executive-summary.md` | management | One-page summary: Key Findings Top 5, Risk Overview, Prioritized Recommendations, Security Posture Score |
| `technical-report.md` | Technical Team | Full technical report: methodology, TARA summary, vulnerability details, exploitation results, defense validation, IDS performance, lessons learned |

---

### Process Overview Diagram

``
┌─────────────────────────────────────────────────────────┐
│ Vehicle Subsystem End-to-End Security Assessment Process │
└─────────────────────────────────────────────────────────┘

┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│ Step 1 │ │ │ Step 2 │ │ Step 3 │ │ Step 4 │ │ Step 5 │ │ Step 6 │ │ │ Step 7 │
│ 🏗️ │───→│ 📊 │───→│ 🔍 │───→│ ⚔️ │───→│ 🛡️ │───→│ 📡 │──→│ 📝 │
│ Environment Setup │ │ TARA Analysis │ │ Vulnerability Assessment │ │ Attack Exploitation │ │ Defense Implementation │ │ Intrusion Detection │ │ Final Report │
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │
│ 5 Services │ │ 25 Assets │ │ 19 Vulnerabilities │ │ 4 PoCs │ │ 22 Hardenings │ │ 5 IDSs │ │ 2 Reports │
│ 19 Vulnerabilities │ │ 26 Threats │ │ CVSS Score │ │ Operational │ │ 90.5% Blocking │ │ 85% Detection Rate │ │ Management+Technology │
│ Intentionally implanted │ │ 22 requirements │ │ Attack chain diagram │ │ Attack script │ │ Residual receivable │ │ Low false positives │ │ Technical level │
└──────────┘ └──────────┘ └──────────┘ └──────────┘ └──────────┘ └──────────┘ └──────────┘ └──────────┘ └──────────┘ └──────────┘ └──────────┘ └──────────┘ └──────────┘ └──────────┘
↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │
environment/ tara/ assessment/ exploitation/ defense/ ids/ report/
```

### Corresponds to ISO/SAE 21434 standard.

| Steps in this project | Correspondence to ISO/SAE 21434 Clause | Description |:---|:---|:---|
|:--- |:--- |:--- | Step 1.
| Step 1 Environment Setup | Clause 9 - Conceptual Phase | Define Relevant Items, System Boundaries, Preliminary Architecture | Step 2 TARA
| Step 2 TARA Analysis | Clause 15 - Threat Analysis and Risk Assessment | Asset Identification, Threat Scenarios, Impact Ratings, Attack Feasibility, Value at Risk Determination |
| Step 3 Vulnerability Assessment | Clause 10 - Product Development (Cybersecurity Validation) | Systematic Testing, Vulnerability Discovery, CVSS Scoring |
| Step 4 Attack Exploitation | Clause 10 - Product Development (Penetration Testing) | Attack Path Verification, PoC Development, Proof of Hazard |
| Step 5 Defense Implementation | Clause 10 - Product Development (Cybersecurity Measures) | Security Requirements Implementation, Vulnerability Remediation, Verification Testing |
| Step 6 Intrusion Detection | Clause 12 - Production/Operation (Cybersecurity Monitoring) | Real-Time Detection, Incident Response, Continuous Monitoring | Step 7 Final Reporting
| Step 7 Final Reporting | Clause 15 - Risk Assessment Reporting | TARA Reporting, Vulnerability Reporting, Verification Reporting |

## 🏗 Architecture

ðŸ "ðŸ "ðŸ "ðŸ "ðŸ
┌──────────────┐ HTTPS/JSON ┌──────────────┐ MQTT ┌──────────────┐
│ Mobile Apps │ ──────────────────→│ Cloud API │ ───────────────→│ MQTT Proxy │
│ (External) │ │ (Flask) │ │ (EMQX) │
└──────────────┘ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘
│ PostgreSQL │ MQTT
▼ ▼
┌──────────────┐ ┌──────────────┐
│ Database │ │ T-BOX │
└──────────────┘ │ Gateway │
└──────┬┘ │ ───────┘
│ CAN (vcan0)
▼
┌──────────────┐
│ Body Control │
│ ECU (BCM) │
└──────────────┘
```

**Five components** to simulate the complete remote vehicle control chain:
1. **Cloud API** (Flask + JWT + PostgreSQL) - user authentication, vehicle management, command distribution
2. **MQTT proxy** (EMQX) - real-time message relaying
3. **T-BOX Gateway** (Python) - telematics unit connecting the cloud to the CAN bus
4. **CAN bus** (SocketCAN vcan0) - 500kbps legacy CAN
5. **Body Control ECU** (Python + UDS) - door locks, engine, lights, HVAC simulation

## 🚀 Quick Start

### Prerequisites

- **Linux** (Ubuntu 22.04+) with `docker`, `python3.11+`, `curl` installed.
- Windows users: using WSL2

### One-click installation

``bash``
## Clone and install
cd environment
chmod +x setup.sh
. /setup.sh

# This script will:
# 1. create the virtual CAN interface (vcan0)
# 2. start all 5 Docker services
# 3. initialize the database with seed data
# 4. verify end-to-end command flow
``

### Manual installation

``## bash
# 1. Create the CAN interface
sudo modprobe vcan
sudo ip link add dev vcan0 type vcan
sudo ip link set up vcan0

# 2. Start the service
cd environment
docker compose up -d --build

# 3. Initialize the database
curl -X POST http://localhost:5000/api/v1/auth/register \
-H "Content-Type: application/json" \
-d '{"username": "alice", "email": "alice@example.com", "password": "password123"}'
```

### Quick test

```bash.
### Login
TOKEN=$(curl -s -X POST http://localhost:5000/api/v1/auth/login \
-H "Content-Type: application/json" \
-d '{"username": "alice", "password": "password123"}' \
| python3 -c "import sys,json; print(json.load(sys.stdin)['access_token'])")

# Send command
curl -X POST http://localhost:5000/api/v1/vehicles/SIMULATED12345678/commands \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $TOKEN" \
-d '{"command_type": "lock", "parameters":{}}'

# Monitor CAN bus
candump vcan0
\ -d '{"command_type": "lock": "parameters":{}}'

### Service endpoints

| Service | URL | credentials |
|:---|:---|:---|
| **Cloud API** | http://localhost:5000 | - |
| **API Health Check** | http://localhost:5000/health | - |
| **EMQX Dashboard** | http://localhost:18083 | admin / admin123 |
| **MQTT proxy** | localhost:1883 | tbox_client / tbox_pass_2024 |
| **PostgreSQL** | localhost:5432 | admin / admin123 / vehicle_security |

### Test account

| username | password | role | vehicle |
|:---|:---|:---|:---|
| alice | password123 | owner | SIMULATED12345678, SIMULATED87654321 |
| bob | bob2024 | owner | SIMULATED1111111111 |

## 📁 Project structure

``
vehicle-security-assessment/
├── README.md # ← current file
│
├── environment/ # Docker + application code
│ ├── docker-compose.yml # 5 Service Orchestration
│ ├── setup.sh # 1-click install scripts
│ ├── init-db.sql # Database schema + seed data
│ ├── cloud-api/ # Flask REST API (Python)
│ │ ├── app.py # Application factory
│ ├── config.py # Configuration (V-03, V-04, V-08)
│ │ ├── models.py # SQLAlchemy models
│ ├── auth.py # /api/v1/auth/* Endpoints
│ ├── vehicles.py # /api/v1/vehicles/* (V-01, V-06)
│ │ ├── commands.py # /api/v1/vehicles/*/commands/* (V-05, V-09)
│ ├── diagnostics.py # /api/v1/vehicles/*/diagnostics/* (V-10)
│ │ ├── mqtt_publisher.py # MQTT Client (V-11, V-12)
│ └── crypto_utils.py # HMAC utilities (V-05)
│ ├── tbox-simulator/ # T-BOX gateway (Python)
│ │ └── tbox_simulator/ # T-BOX Gateway (Python)
│ │ ├── main.py # Entry point
│ │ ├── config.py # Configuration (V-11, V-12, V-14,V-15,V-16)
│ │ ├── mqtt_client.py # MQTT connection
│ │ ├── can_bridge.py # CAN bus interface
│ │ ├── command_processor.py # Command Routing (V-14)
│ │ ├── firewall.py # CAN firewall (V-15, V-16)
│ │ ├── crypto_utils.py # HMAC/SecOC
│ └── uds_handler.py # UDS forwarding
│ ├── ecu-simulator/ # Body Control ECU (Python)
│ │ └── ecu_simulator/ # Body Control ECU (Python)
│ │ ├── main.py # Entry point
│ │ ├── state.py # Vehicle state management
│ │ ├── body_control.py # door/engine/light/HVAC control
│ │ ├── can_handler.py # CAN Message Handler
│ │ ├── uds_server.py # UDS Diagnostics (V-17)
│ └── logger.py # Event Logging
│ └── mqtt-broker/ # EMQX Configuration (V-11, V-13)
│ └── emqx.conf
│
├── tara/ # Phase 1: TARA Analysis
│ ├── project-definition.md # System description + DFD
│ ├── asset-inventory.md # 25 assets with C/I/A ratings
│ ├── threat-scenarios.md # 26 STRIDE threats + attack tree
│ ├── attack-paths.md # 4 detailed attack paths
│ ├── risk-assessment.md # impact × feasibility matrix
│ └── security-requirements.md # 22 requirements + traceability
│ └─ security-requirements.md # 22 requirements + traceability
├── assessment/ # Stage 2: Vulnerability Assessment
│ ├─ api-assessment.md # 10 API vulnerabilities
│ ├── mqtt-assessment.md # 4 MQTT vulnerabilities
│ ├── tbox-assessment.md # T-BOX security test
│ ├── can-assessment.md # CAN bus security test
│ └── vulnerability-summary.md # Full Vulnerability Matrix
│
│ ├── exploitation/ # Phase 3: Attack Demonstration
│ ├── attack-remote-control/ # API → Vehicle Chain of Control
│ │ ├── exploit.py # Runnable PoC Scripts
│ └── README.md # Step-by-step instructions
│ ├── attack-can-injection/ # Direct CAN injection
│ │ ├── can_inject.py # Runnable PoC Scripts
│ └── README.md
│ ├── attack-mqtt-injection/ # MQTT proxy vulnerability exploitation
│ │ ├── mqtt_attack.py # Runnable PoC scripts
│ │ └── README.md
│ └── attack-uds-abuse/ # UDS diagnostic exploit
│ ├── uds_exploit.py # Runnable PoC script │ └── README.md │ └── attack-uds-abuse/ # UDS diagnostic exploit
│ └── README.md
│ └─ README.md
├── defense/ # Phase 4: Defense Implementation
│ ├── api-hardening/ # Hardened APIs (SR-01 to SR-10)
│ ├── mqtt-security/ # TLS + ACL Configuration (SR-13 to SR-15)
│ ├── can-secoc/ # SecOC implementation (SR-12, SR-20)
│ ├── gateway-filter/ # Enhanced Firewall (SR-17 to SR-19)
│ └── validation-results.md # Before and after enhancements
│ └── validation-results.md
├── ids/ # Phase 5: Intrusion Detection
│ ├─ can_ids.py # CAN bus anomaly detection
│ ├── mqtt_ids.py # MQTT Traffic Monitoring
│ ├── api_monitor.py # API Attack Detection
│ ├── correlation_engine.py # Cross-layer attack chain detection
│ ├── dashboard.py # Terminal real-time dashboards
│ └── detection-results.md # Detection rate analysis
│
│ ├── tools/ # Security assessment tools
│ ├── can_analyzer.py # CAN protocol reverse engineering
│ ├── mqtt_fuzzer.py # MQTT protocol fuzzer tester
│ └── api_scanner.py # API security scanner
│ └── api_scanner.py # API security scanner │
└── report/ # Final report
├── executive-summary.md # One-page management summary │ └── technical-report.md # API security scanner
└── technical-report.md # Comprehensive technical report
``

## 🔬 phases

### Phase 1: TARA Analysis
- 25 assets covering 5 categories (data, functional, communications, physical, software)
- 26 threat scenarios analyzed using the STRIDE methodology
- "Unauthorized Remote Vehicle Control" Full Attack Tree
- 5×4 Risk Matrix: 15 Critical (R4), 11 High Risk (R3)
- 22 derived security requirements with full traceability

### Phase 2: Vulnerability Assessment
- Systematic testing of all 5 components
- 19 vulnerability documents with CVSS scores, reproduction steps and remediation options
- Attack chain mapping, showing combinations of vulnerabilities

### Phase 3: Exploitation
- **4 runnable Python PoC scripts** with detailed README instructions
- Demonstrates the complete remote control chain
- CAN injection with replay and DoS
- MQTT proxy intrusion affecting entire fleet
- Breaking UDS security access in 1 attempt

### Phase 4: Defense Implementation
- 22 security requirements implemented
- **90.5% of attacks completely blocked
- All R3/R4 risks eliminated
- Pre- and post-hardening validation results documented

### Phase 5: Intrusion Detection
- Multi-layer IDS (CAN + MQTT + API)
- Cross-layer correlation engine with 7 attack pattern definitions
- Endpoint-based real-time dashboard
- **85% Detection rate** with less than 5% false alarm rate

## 🔴 Vulnerability Matrix

| ID | Component | Vulnerability | CVSS | Risk |
|:---:|:---|:---|:---:|:---:|:---:|
| V-01 | Cloud API | BOLA - No Ownership Authentication | 9.1 | R4 |
| V-01 | Cloud API | BOLA - No Ownership Authentication | 9.1 | R4 | V-02 | Cloud API | Weak Password Policies | 5.3 | R3 |
| V-03 | Cloud API | Hard-Coded JWT Key ("secret123") | 8.0 | R4 | V-02 | Cloud API | Weak Password Policy | 5.3 | R3
| V-04 | Cloud API | Login without Rate Limit | 7.5 | R3 | V-03 | Cloud API | Hard-Coded JWT Key ("secret123")
| V-05 | Cloud API | Command Signature Optional | 8.6 | R4 |
| V-06 | Cloud API | SQL Injection in Vehicle Search | 9.8 | R4 | V-06 | Cloud API | SQL Injection in Vehicle Search | 9.8 | R4 | V-07 | Cloud API
| V-07 | Cloud API | Detailed Error Messages Leaked | 5.3 | R3 | V-08 | Cloud API | SQL Injection in Vehicle Search | 9.8 | R4 | Cloud API
| V-08 | Cloud API | CORS Allow All Sources (*) | 6.5 | R3 | V-08 | Cloud API | CORS Allow All Sources (*) | 6.5 | R4 |
| V-09 | Cloud API | No OTP Validation for Sensitive Commands | 7.4 | R3 | V-08 | Cloud API | CORS Allow All Sources (*) | 6.5 | R3 |
| V-10 | Cloud API | Diagnostic Interface without Role Checking | 8.1 | R3 | V-11 | MQTAG | Cloud API

| V-11 | MQTT | No TLS encryption | 7.5 | R4 | V-12 | MQTT | Shared T-BOX credentials | 8.0 | R4 |
| V-12 | MQTT | Shared T-BOX Credentials | 8.0 | R4 | V-12 | MQTT | Shared T-BOX Credentials | 7.5 | R4

| V-15 | T-BOX | Firewall No Source Checking | 7.5 | R4 |
| V-16 | T-BOX | Firewall no content validation | 6.5 | R3 |
| V-17 | ECU | Weak UDS SecurityAccess (XOR) | 6.5 | R3 |
| V-18 | Infrastructure | Weak Database Passwords | 7.5 | R3 |
| V-19 | Infrastructure | Weak MQTT Dashboard Password | 6.5 | R3 |

## ⚔️ Attack Demo

### 1. Remote control via cloud APIs
```bash
cd exploitation/attack-remote-control
python exploit.py --base-url http://localhost:5000
```
Exploitation Vulnerabilities: V-01 (BOLA), V-04 (No Rate Limit), V-05 (No Signature), V-06 (SQL Injection)

### 2. Direct CAN bus injection
```bash
sudo python exploitation/attack-can-injection/can_inject.py --channel vcan0
```
Exploitation Vulnerabilities: V-15 (no source checking), V-16 (no content validation), CAN protocol weaknesses

### 3. MQTT proxy vulnerability exploitation
```bash
python exploitation/attack-mqtt-injection/mqtt_attack.py --host localhost
```
Exploitation Vulnerabilities: v-11 (no TLS), v-12 (shared credentials), v-13 (no ACL), v-14 (no signature checking)

### 4. UDS Diagnostics Vulnerability Exploits
```bash
sudo python exploitation/attack-uds-abuse/uds_exploit.py --channel vcan0
```
Exploitation Vulnerability: V-17 (Weak XOR SecurityAccess)

## 🛡️ Defense results

| Attack | Pre-Hardened | Post-Hardened | Status |
|:---|:---|:---|:---:---:|
| BOLA | Full Access | 403 Banned | ✅ Blocked |
| SQL Injection | Data Extraction | ORM Queries | ✅ Blocked |
| JWT Forgery | Token Forgery | Random 256-bit Keys | ✅ Blocked
| JWT Forging | Token Forgery | Random 256-bit Key ✅ Blocked | Brute Force | Unlimited | 5x/minute + Lockout ✅ Blocked
| Unsigned Commands | Executable | Signature Verification Required ✅ Blocked | CAN Injection | Executable | Random 256-bit Keys ✅ Blocked
| CAN Injection | Executable | SecOC MAC Invalid | ✅ Blocked | | CAN Replay | Executable | Signature Verification ✅ Blocked
| CAN Replay | Executable | Counter Expired | ✅ Blocked | CAN DoS | 500 | CAN DoS | 500 | Signature Verification ✅ Blocked
| CAN DoS | 500 bars/sec | 10 bars/sec limit | ⚠️ Mitigated |
| MQTT Eavesdropping | Visible in Plaintext | TLS 1.3 | ✅ Blocked |
| MQTT Injection | Executable | Signature Invalid | ✅ Blocked |
| UDS Cracking | 1 attempt | AES Challenge | ⚠️ mitigated |

**Overall: 90.5% fully blocked, 9.5% mitigated to an acceptable residual risk**

## 📊 IDS Detection

| Attacks | CAN IDS | MQTT IDS | API Monitoring | Correlation Engine | Detection Results |
|:---|:---:|:---:|:---:|:---:|:---:|
| Remote Control Chain | ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✅ |
| CAN Injection | ✓ | - | - | - | ✅ |
| MQTT Injection | - | ✓ | - | - ✅ |
| UDS Brute Force | | ✓ | - | - | - ✅ |
| CAN DoS | ✓ | - | - | - ✅ |
| CAN Replay | ✓ | - | - | - ✅ |
| API Brute Force | - | - | ✓ | - ✅ | ✅ |
| SQL Injection | - | - | ✓ | - | ✅ |

**Detection Rate: 85% | False Alarm Rate:
Built for automotive cybersecurity engineers entering the vehicle security space.
All simulations are containerized - no real vehicle hardware required.