Warum ist Automotive Security anders?

• Ein Bug kann Leben kosten (nicht nur Daten) -> Fehler können Menschen verletzen, nicht nur Daten verlieren. Beispiele im Auto:
  • Bremssteuerung:
    • Wenn ein Software-Bug die Bremssignale falsch interpretiert oder blockiert, reagiert das Bremssystem möglicherweise nicht richtig – Unfallgefahr.
  • Lenkung / Assistenz:
    • Ein Fehler in Lenkassistenten (z. B. Lane Assist) kann falsche Lenksignale erzeugen -> Kollision.
  • Anzeigefehler:
    • Falsche Geschwindigkeit oder Warnlampen können den Fahrer in die Irre führen.
• Autos werden 10-20 Jahre genutzt, deshalb bleiben alte, unsichere Technologien lange im Einsatz. Komponenten, Protokolle und Software werden oft über ein Jahrzehnt oder länger genutzt. Beispiel im Auto:
  • Alte ECUs:
    • Eine Steuergerät-Firmware aus dem Jahr 2008 fährt vielleicht noch 2028 im gleichen Auto und hat nie Security-Updates bekommen.
  • Protokolle:
    • Ältere Protokolle ohne Schutzmechanismen bleiben Jahrzehnte im Einsatz.
• Viele Protokolle aus den 80er/90er Jahren ohne Security. Viele Kommunikationsprotokolle (z. B. frühe Varianten von CAN, K-Line) wurden entwickelt, bevor Cybersecurity ein Thema war — sie haben keine Authentifizierung oder Verschlüsselung. Beispiel im Auto:
  • CAN:
    • Jede ECU kann Nachrichten senden, ohne nachzuweisen, wer sie ist -> Spoofing möglich.
  • K-Line / ältere Diagnoseprotokolle:
    • Kein Schutz vor Manipulationen oder Replay-Angriffen.
• Hunderte Zulieferer, verschiedene Sicherheitsniveaus. Ein modernes Auto ist aus Teilen vieler Zulieferer zusammengesetzt. Jeder Lieferant bringt eigene Hardware, Software und Prozesse mit – nicht alle sind gleich sicher. Beispiel im Auto:
  • Gateway von Hersteller A, Infotainment von Lieferant B, TCU von Lieferant C – jeder mit eigener Firmware, eigenen Update-Prozessen und unterschiedlichen Sicherheitsstandards.
• physischen Zugang (z. B. OBD-Port) ist oft nötig, anders als Web/Cloud Testing. Viele Angriffe erfordern, dass jemand nah am Fahrzeug ist oder es berührt – z. B. über den OBD-II-Port, USB-Ports oder durch manipulierte Hardware.
  • OBD-II-Port:
    • Unter dem Lenkrad erreichbar — über ein simples Kabel bekommst du oft direkten CAN-Zugriff.
  • USB/SD:
    • Ein eingeschobener USB-Stick kann Malware auf das Infotainment laden.
  • Ladeanschluss (EV):
    • Bei E-Fahrzeugen kann der Ladepunkt ein Angriffsvektor sein, wenn er nicht sicher implementiert ist.
• Latenz kann kritisch sein. Das System muss innerhalb einer bestimmten, sehr kurzen Zeit reagieren, sonst kann es gefährlich werden. Beispiel im Auto:
  • Bremsen:
    • Wenn du auf die Bremse trittst, muss die ECU sofort (innerhalb von Millisekunden!) reagieren.
    • Wenn die Nachricht über den CAN-Bus zu spät kommt, bremst das Auto zu spät -> Unfallgefahr.
  • Airbag:
    • Der Airbag darf nicht 0,5 Sekunden zu spät auslösen – er muss in Millisekunden reagieren.
  • Motorsteuerung:
    • Sensoren (Drehzahl, Temperatur, Druck) liefern ständig Daten -> die ECU muss diese schnell verarbeiten, sonst läuft der Motor schlecht oder geht aus.

Beim Testen musst du extrem vorsichtig sein

• Tests dürfen keine sicherheitskritischen Funktionen stören. Sonst kann: A) der CAN-Bus blockieren, B) ECUs in Fehlerzustände gehen, C) oder sicherheitskritische Systeme nicht rechtzeitig reagieren.
• In Produktionsfahrzeugen nur lesen, kontrollierte Labors für aktive Tests.
• Dokumentation und Notfallpläne bereit haben, falls etwas schiefgeht.
• Du musst auch Legacy-Systeme testen — nicht nur neueste Modelle.
• Teste, ob fehlende Authentifizierung ausgenutzt werden kann (Message Injection, Replay).
• Suche nach Workarounds der Hersteller (z. B. proprietäre Filter/Gateways).
• Empfehle moderne Gegenmaßnahmen: Authentifizierung, Message Integrity, Gateway-Filters.
• Prüfe Schnittstellen zwischen Komponenten — dort entstehen oft Schwachstellen.
• Berücksichtige Supply-Chain-Risiken (z. B. Default-Credentials, schwache Signaturen).
• Empfehlungen sollten Governance, Secure Development und Zulieferer-Audits umfassen.
• Prüfe, welche Funktionen per physischem Port zugänglich sind.
• Simuliere Angriffe mit typischen Tools (OBD-Adapter) — aber nur im Labor oder mit ausdrücklicher Erlaubnis.
• Empfehle physische Schutzmaßnahmen: Port-Abdeckungen, Zugangskontrolle, Logging von physischen Verbindungen.

Fahrzeug-Netzwerk-Grundlagen

1. CAN Bus (Controller Area Network)

Was ist CAN?

• CAN ist das zentrale Kommunikationsprotokoll in Fahrzeugen.
• Stell dir einen Broadcast-Bus vor, an dem alle ECUs hängen und mithören können.
• CAN bus ist das Kommunikationssystem, das die vielen kleinen Computer (ECUs) im Auto miteinander verbindet.
• Ohne CAN würde dein Auto gar nicht funktionieren – keine Kommunikation zwischen Motor, ABS, Airbag, Lenkung usw.
• Wenn eine ECU etwas sendet, hören alle anderen mit.
• Jede ECU entscheidet selbst, ob die Nachricht für sie relevant ist oder nicht.

Aufbau & Grundprinzip

Das Netzwerk besteht aus zwei verdrillten Drähten:
CAN-High und CAN-Low.

So sieht’s aus:

ECU 1 ----+
          |
ECU 2 ----+---- CAN Bus (2 Drähte: CAN-High, CAN-Low)
          |
ECU 3 ----+
          |
ECU 4 ----+

Alle ECUs (z. B. Motorsteuerung, ABS, Lichtsteuerung, Türen, Airbag usw.) sind parallel mit dem Bus verbunden.

Wie CAN kommuniziert

Im Gegensatz zu Computernetzwerken (z. B. Ethernet) gibt es im CAN-Bus keine IP-Adressen oder Sender-/Empfänger-IDs. Stattdessen:

• Nachrichten werden über eine CAN-ID identifiziert (z. B. 0x123).
• Diese ID beschreibt den Inhalt der Nachricht, nicht den Absender.
  -> Beispiel: ID 0x123 steht vielleicht für „Motordrehzahl“, egal welche ECU sie sendet.

Das ist wie ein Radiokanal:

• Der Sender ruft „Drehzahl = 8000 U/min“.
• Alle hören zu, aber nur die ECUs, die diese Info brauchen, reagieren.

Wichtige Eigenschaften:

• Broadcast-Natur: Jede Nachricht wird an alle ECUs gesendet. Keine direkte Adressierung.
• Message-basiert: Nachrichten sind nach Funktion organisiert, nicht nach Gerät. (keine Sender/Empfänger-Adressen)
• Prioritätsbasiert: Niedrige CAN-ID = höhere Priorität
• Geschwindigkeit: Je nach Bus: 125 kbit/s bis 1 Mbit/s
• Keine Authentifizierung: Jeder Teilnehmer kann theoretisch jede Nachricht senden. Das ist das größte Sicherheitsproblem

+----------+--------+-----+--------+
| CAN ID   | Length | Data| CRC    |
| (11/29bit)| (0-8)  |(0-8)| (15bit)|
+----------+--------+-----+--------+

Beispiel:

CAN ID: 0x123 (Motor ECU sendet Drehzahl)
Length: 2 bytes
Data: [0x1F, 0x40] = 8000 RPM

Das bedeutet: Die ECU mit der ID 0x123 sendet, dass der Motor gerade mit 8000 U/min läuft.

CAN Message Typen

High-Speed CAN:

• Geschwindigkeit: 500 kbit/s bis 1 Mbit/s
• Wird verwendet für sicherheitskritische Systeme:
  • Motorsteuerung
  • ABS / ESP
  • Airbags
  • Getriebe
• Hat 120 Ohm Abschlusswiderstände an beiden Enden (zur Signalstabilisierung).

Low-Speed CAN:

• Geschwindigkeit: bis 125 kbit/s
• Verwendet für Komfortfunktionen:
  • Fensterheber
  • Spiegel
  • Klimaanlage
• Fehlertoleranter (wenn eine Leitung ausfällt, läuft es langsamer weiter).

Weitere Bus-Systeme

Neben CAN gibt es noch andere Bussysteme – jedes hat seinen eigenen Zweck:

LIN (Local Interconnect Network):

• Einfacher, günstiger als CAN
• Master-Slave Architektur (eine zentrale ECU steuert mehrere Untergeräte)
• Geschwindigkeit: bis 20 kbit/s.
• Verwendung: Türmodule, Sitzverstellung, Klimasteuerung
• Vorteil: spart Kosten bei einfachen Steuerungen.

FlexRay:

• Sehr schnell (bis 10 Mbit/s) und deterministisch (genaue Zeitslots).
• Verwendet bei sicherheitskritischen Anwendungen:
  • Lenkung
  • aktive Federung
  • Steer-by-Wire-Systeme
• Nachteil: teuer, komplex, schwer zu warten.

Automotive Ethernet:

• Modernster Bus in neuen Fahrzeugen.
• Geschwindigkeit: 100 Mbit/s bis 1 Gbit/s.
• Einsatzgebiete:
  • Kameras und Radar (ADAS)
  • Infotainment (Navigation, Streaming)
  • Vernetzte Systeme (z. B. OTA-Updates)
• Unterstützt moderne Sicherheitsmechanismen (z. B. Firewalls, Verschlüsselung).

Warum ist das CAN-Bus für Pentesting wichtig?

• Sicherheitsmechanismen wie Authentifizierung oder Verschlüsselung fehlen – das macht CAN so interessant für Pentesting.
• CAN ist die Hauptkommunikationsebene, über die du Fahrzeugfunktionen beeinflussen kannst.
• Wenn du verstehst, wie Nachrichten aussehen und was sie bedeuten, kannst du:
  • Nachrichten mithören (Sniffen)
  • Nachrichten analysieren (Reverse Engineering)
  • Nachrichten senden oder fälschen (Injection, Replay)

Das ist die Grundlage jedes Automotive-Pentests.

2. ECUs (Electronic Control Units)

Was ist eine ECU? Ein eingebetteter Computer im Fahrzeug mit spezifischer Funktion. Eine ECU ist im Grunde ein kleiner, spezialisierter Computer im Auto, der eine bestimmte Funktion steuert – z. B. Motor, Getriebe, Türen oder Infotainment. Viele ECUs zusammen koordinieren das komplette Fahrzeugverhalten.

Typische ECU Komponenten:

+----------------------------------+
|  Mikrocontroller (z.B. Infineon  |
|  TriCore, ARM Cortex, PowerPC)   |
|                                  |
|  Flash Memory (Firmware)         |
|  RAM (flüchtig)                  |
|  EEPROM (Config, VIN, etc.)      |
|                                  |
|  CAN Transceiver                 |
|  I/O Pins (Sensoren/Aktuatoren)  |
+----------------------------------+

Wichtige ECU-Typen:

1. Engine Control Unit (ECU / ECM)

• Funktion: Steuerung Motor (Einspritzung, Zündung, Luftmassenregelung, Abgasregelung).
• Echtzeit: Sehr hohe Anforderungen an Timing und Determinismus.
• Sicherheitsrelevanz: Kritisch — Fehler können Motorstillstand, Leistungsverlust oder unerwartetes Verhalten verursachen.
• Kommunikation: Häufig eigene CAN-IDs (z. B. 0x000–0x0FF), teils über Powertrain-Bus.

2. Transmission Control Unit (TCU)

• Funktion: Automatik-/Doppelkupplungsgetriebe steuern, Schaltpunkte, Kupplungssteuerung.
• Eigenschaften: Enge Interaktion mit Motor-ECU (timing-kritisch), oft proprietäre Steuerstrategien.

3. Body Control Module (BCM)

• Funktion: Komfort- und Karosseriefunktionen (Licht, Zentralverriegelung, Fenster, Spiegel).
• Besonderheit: Schnittstelle zu Keyless-Systemen; oft viele I/Os.
• Risiko: Kompromittierung kann Zugang zum Fahrzeug erlauben.

4. Instrument Cluster

• Funktion: Anzeige für Fahrer (Geschwindigkeit, Warnlampen, Drehzahl).
• Einsatzzweck: Aggregiert Werte aus mehreren ECUs; kann Fehlanzeigen erzeugen (Security -> Safety Issue).

5. Gateway ECU

• Funktion: Verbindet mehrere Busse (z. B. Powertrain-CAN, Body-CAN, Infotainment-CAN), filtert/übersetzt Nachrichten.
• Security-Rolle: Erste Verteidigungslinie; implementiert oft Filter, Routing, Firewall-ähnliche Regeln.
• Herausforderung: Komplex; Sicherheitsfehler im Gateway öffnen viele Pfade.

6. Telematics Control Unit (TCU)

• Funktion: Mobilfunk, GPS, Remote-Services, OTA.
• Angriffsfläche: Remote erreichbar -> primäres Ziel für ferngesteuerte Angriffe.
• Besonderes: Verknüpfung zu Backend-Cloud-Services; komplexe Software-Stacks (Linux, custom stacks).

7. Infotainment / Head Unit

• Funktion: Multimedia, Navigation, Apps, oft mit Internetzugang.
• Gefährdung: Oft komplexes OS (Android, QNX) mit Drittanbieter-Apps — häufiges Einfallstor für Exploits.
• Pivot-Risiko: Über schlecht isolierte Gateways kann ein kompromittiertes Infotainment in Fahrfunktionen tauchen.

Interfaces & Diagnosetools einer ECU

• CAN / LIN / FlexRay / Ethernet – Kommunikationsschnittstellen.
• OBD-II-Port – standardisierter Diagnosezugang (UDS, ISO-TP).
• JTAG / SWD / UART / Bootpins / SPI / I²C – Hardware-Schnittstellen für Debugging, Firmware-Dump oder Programming.
• USB / SD / SDIO – Media- oder Update-Interfaces (Infotainment).

Lebenszyklus & Updates

• Firmware-Updates erfolgen über:
  • Dealer-Tool / Werkstatt (UDS Programming Session)
  • OTA (Over-The-Air) bei vernetzten ECUs (TCU/Infotainment)
  • JTAG / Flash-Programmer im Labor
• Secure Boot & Code-Signing sind wichtige Schutzmaßnahmen, die verhindern sollen, dass unsignierte Firmware geladen wird.

Workflow: So analysierst du eine unbekannte ECU (Übersicht)

1. Identifizieren: Welche ECU (physisch / via CAN-ID / UDS) ist es?
2. Passiv sniffen: Welche Nachrichten sendet sie? Frequenzen, DLC, Muster.
3. Diagnose: Unterstützt sie UDS? Welche Session-Levels? (0x10/0x27 etc.)
4. Hardware-Check: Gibt es JTAG/SWD/UART? Sind Pins offen?
5. Firmwarezugang: OTA/Update-Mechanismen prüfen, Secure Boot prüfen.
6. Exploit-Surface: Suche nach default creds, offene Ports, Buffer-Handling.
7. Bericht & Empfehlungen: Exploit-PoC, Risiko-Assessment, Mitigations.

3. OBD-II (On-Board Diagnostics)

Was ist OBD-II?

• OBD-II ist der standardisierte Diagnoseanschluss im Fahrzeug.
• Pflicht in den USA seit 1996, EU seit 2001 (Benzin) / 2004 (Diesel).
• Physischer 16-poliger Stecker, genormte Form.

OBD-II Port Location: Normalerweise unter dem Lenkrad, Fahrerseite.

Pin-Belegung (wichtigste)

  1  2  3  4  5  6  7  8
  9 10 11 12 13 14 15 16

• Pin 4: Chassis Ground
• Pin 5: Signal Ground
• Pin 6: CAN High (ISO 15765-4)
• Pin 14: CAN Low (ISO 15765-4)
• Pin 16: +12 V Batterie (Dauerplus)

Weitere (je nach Fahrzeug/Protokoll):

• Pin 7: K-Line (ISO 9141-2 / KWP2000)
• Pin 15: L-Line (früher für Init, oft unbelegt)
• Pin 2/10: SAE J1850 (VPW/PWM, v. a. ältere US-Modelle)

Über bestimmte Pins kannst du direkt auf den Bus (oder Diagnose-Protokolle) zugreifen- das macht ihn für Security-Tests attraktiv:

• Pin 6 / 14 = CAN High / CAN Low -> direkter Zugang zum CAN-Bus (Sniffing, in manchen Fällen Injection).
• Pin 7 = K-Line -> Zugriff auf ältere Diagnoseprotokolle (KWP2000).
• Pin 2 / 10 = J1850 -> ältere US-Protokolle.
• Pin 16 = +12V und Pin 4/5 = Masse -> Stromversorgung des Diagnose­adapters.

OBD-II Protokolle:

1. ISO 15765-4 (CAN) – Standard heute
   • 11-Bit/29-Bit CAN, 250–500 kbit/s (oft 500 k)
   • Transport: ISO-TP (ISO 15765-2) zerlegt/lappt große UDS/OBD-Nachrichten
2. ISO 9141-2 / K-Line – älter
   • Serielle 10,4 kbit/s, Ein-Draht (Pin 7)
   • Vorgänger von UDS: KWP2000 (ISO 14230) lief oft darauf
3. SAE J1850 (VPW/PWM) – ältere US-Fahrzeuge
   • Heute im Feld zunehmend selten

Was kannst du über OBD-II machen?

A) Standard-OBD-Funktionen (emissionsbezogen)

Das ist das, was alle OBD-II-Fahrzeuge können müssen:

• DTCs (Fehlercodes) lesen/löschen
• Live-Daten/PIDs (Geschwindigkeit, RPM, Temperatur, Lambda, Fuel Trim, …)
• Readiness/Monitors (Katalysator-, EVAP-, O2-Monitorstatus)
• VIN/Calibration IDs auslesen

Diese Funktionen sind unter SAE J1979 / ISO 15031 standardisiert.
Sie arbeiten mit sogenannten „Modes“ (Service-Modi) und PIDs (Parameter IDs).

Wichtige OBD-Modes (Auszug):

• Mode 01 – Aktuelle Live-Daten (PIDs) – aktuelle Messwerte.
• Mode 02 – Freeze-Frame (Status zum Fehlerzeitpunkt)
• Mode 03 – Abgas-relevante DTCs lesen
• Mode 04 – DTCs löschen / MIL zurücksetzen
• Mode 09 – Fahrzeuginfo (z. B. VIN)

Beispiele beliebter PIDs (Mode 01):

• 010C → Engine RPM – Motordrehzahl
  • Antwort: 41 0C AA BB
  • Formel: RPM = ((A*256) + B) / 4
  • Beispiel: 41 0C 1F 40 → ((0x1F*256)+0x40)/4 = ((31*256)+64)/4 = (7936+64)/4 = 8000 rpm
• 010D → Vehicle speed – Fahrzeuggeschwindigkeit (km/h)
  • Antwort: 41 0D AA
  • Formel: km/h = A
  • Beispiel: 41 0D 3C → 60 km/h
• 0105 → Coolant temperature – Kühlmitteltemperatur (°C)
  • Antwort: 41 05 AA
  • Formel: °C = A - 40
  • Beispiel: 41 05 7B → 0x7B=123 => 123-40=83°C
• 0104 → Calculated Engine Load
  • Load% = (A*100)/255
• 0111 → Throttle position
  • % = (A*100)/255
• 0100 → PIDs supported 01-20 (Bitmap)
• 0902 → VIN (Mode 09 PID 02) — häufig kommt eine längere, über ISO-TP gesendete Antwort (First + Consecutive Frames).

B) Hersteller-spezifische / „Erweiterte“ Diagnostik

Über OBD-Buchse erreichbar, aber nicht Teil des Standard-OBD-Katalogs:

• UDS (ISO 14229) Services: ECU Reset (0x11), Read/WriteDataByIdentifier (0x22/0x2E), SecurityAccess (0x27), Firmware-Flash (0x34/0x36/0x37) …
• KWP2000 (älter, ISO 14230) – ähnliche Services über K-Line

Diese erweiterten Funktionen sind oft authentifiziert (Seed/Key) und je nach Gateway geblockt, um sicherheitskritische Bereiche zu schützen.

Tools & Adapter (Praxis)

• ELM327-Adapter (USB/Bluetooth/Wi-Fi): günstig, beherrschen OBD-Standardfunktionen; Qualität sehr unterschiedlich (Achtung: viele Clones, Timing-Probleme).
• J2534 Pass-Thru: professioneller Standard für Werkstattsoftware (Hersteller-Diagnose, Flash).
• SocketCAN-Adapter (z. B. CANable/CANtact, ValueCAN): optimal für eigene Tools/Skripte unter Linux.
• Software: can-utils, python-can, isotp, UDSim/ICSim, Scan-Apps.

Direkter CAN-Zugang – ja/nein?

• Früher: OBD-Pins 6/14 oft direkt am Fahrzeug-CAN -> volle Einsicht und ggf. Injection möglich.
• Heute: In vielen Fahrzeugen hängt OBD am Diagnose-CAN oder geht durch ein Gateway, das filtert (nur Diagnose-Frames, keine sicherheitskritischen IDs durchlassen).
• Ergebnis: „Manche Fahrzeuge: Direkter CAN-Zugang“ stimmt – aber immer seltener und stark modellabhängig.

DTCs (Fehlercodes) – kurz & nützlich

Format: B/P/C/U + vier Ziffern:

• P0xxx = Powertrain, generisch (OBD-Standard)
• P1xxx = herstellerspezifisch
• C = Chassis, B = Body, U = Netzwerk
  Beispiel: P0301 → „Zündaussetzer Zylinder 1“.
• Mode 03: DTCs lesen
• Mode 04: DTCs löschen (setzt Monitore zurück → Readiness beachten!)

Mini-Cheatsheet (für die Praxis)

• Geschwindigkeit (Mode 01 PID 0x0D) → km/h = A
• Drehzahl (Mode 01 PID 0x0C) → RPM = ((A*256)+B)/4
• Kühlmitteltemp (Mode 01 PID 0x05) → °C = A - 40
• VIN (Mode 09 PID 0x02) → mehrteilige ISO-TP-Antwort, als ASCII zusammensetzen
• Functional Req → an 0x7DF, Antwort 0x7E8–0x7EF

4. Diagnose-Protokolle

UDS (Unified Diagnostic Services) – ISO 14229

Was ist UDS? Das Standard-Protokoll für Fahrzeugdiagnostik. Denk an es wie eine API für ECUs. Werkstatt-Tools (oder deine Testsoftware) sprechen standardisierte Services (Befehle) mit Subfunktionen und Daten, um Infos zu lesen, Tests auszuführen oder Firmware zu flashen.

Wichtige UDS Services:

# Service IDs (SID)
0x10 - Diagnostic Session Control
0x11 - ECU Reset
0x22 - Read Data By Identifier
0x23 - Read Memory By Address
0x27 - Security Access
0x2E - Write Data By Identifier
0x31 - Routine Control -> Start/Stop/Result einer Routine (z. B. Test, Kalibrierung, Erase Memory, Checks)
0x34 - Request Download (Flash)
0x35 - Request Upload
0x36 - Transfer Data
0x37 - Request Transfer Exit
0x3E - Tester Present -> verhindert Session-Timeout

Beispiel-Flow für Security Access:

Tester -> ECU: [0x10, 0x03] (Extended Diagnostic Session)
ECU -> Tester: [0x50, 0x03] (Positive Response)

Tester -> ECU: [0x27, 0x01] (Request Seed)
ECU -> Tester: [0x67, 0x01, 0xAB, 0xCD, 0xEF, 0x12] (Seed)

# Tester berechnet Key aus Seed mit geheimem Algorithmus
Key = seed_to_key_algorithm(seed)

Tester -> ECU: [0x27, 0x02, Key[0], Key[1], Key[2], Key[3]]
ECU -> Tester: [0x67, 0x02] (Access Granted!)

Session-Typen: 0x10 – Diagnostic Session Control

• 0x01 – Default Session (eingeschränkt)
• 0x02 – Programming Session (für Firmware-Updates)
• 0x03 – Extended Diagnostic Session (mehr Zugriff) – mehr Diagnosefunktionen

KWP2000 (Keyword Protocol 2000) – ISO 14230

Älteres Protokoll, Vorgänger von UDS. Ähnliche Services, aber über K-Line.

Typische Angriffsvektoren

Angriffsflächen-Übersicht

External Attack Surface:
├── Remote
│   ├── Cellular (4G/5G)
│   ├── WiFi
│   ├── Bluetooth
│   └── V2X (Vehicle-to-Everything)
├── Proximity
│   ├── Key Fob (RF 315/433 MHz)
│   ├── TPMS (RF 315/433 MHz)
│   └── NFC
└── Physical
    ├── OBD-II Port
    ├── USB Ports
    ├── SD Card Slots
    └── Charging Port (EVs)

Internal Attack Surface:
├── CAN Bus
├── Automotive Ethernet
├── ECU Firmware
└── Infotainment OS

Typische Angriffsflächen an ECUs

1) Unsichere Diagnose-Services (UDS ohne Auth):

• UDS bietet mächtige Dienste (Read/Write DIDs, Flash, Reset).
• Wenn diese Dienste ohne angemessene Authentifizierung zugänglich sind, kann ein Angreifer kritische Funktionen lesen oder schreiben.
• kann zu unerlaubtem Zugriff, Flashen führen.

Wie könnte ein Angreifer das ausnutzen (hoch-level)?

• Er verbindet sich physisch (OBD, kompromittiertes Infotainment) oder über eine schlecht geschützte TCU (remote).
• Sendet UDS-Service-Requests (z. B. RequestDownload, TransferData, WriteDataByIdentifier) und versucht, Parameter zu ändern oder Firmware zu flashen.
• Ziel: Prüfen, ob UDS-Dienste (z. B. Read/Write, Download, Transfer) ohne angemessene Authentifizierung oder nur mit schwacher Auth zugänglich sind.

Erfolgskriterien / Findings:

• Niedriger Schweregrad: Nur Standard-DIDs lesbar (erwartet).
• Mittlerer/hoher Schweregrad: Programming/Write/Download-Services erreichbar ohne Security-Access oder mit trivialer/fehlender Authentifizierung.

2) Fehlende Secure Boot / Signatur

• Ohne Secure Boot und validierte Signaturen kann eine ECU beliebige (manipulierte) Firmware akzeptieren und ausführen.

Wie könnte ein Angreifer das ausnutzen (hoch-level)?

• Er schafft physischen Zugriff (JTAG, Boot-Pins, Firmware-Update-Mechanismus) oder nutzt einen offenen Update-Service (OTA), lädt manipulierte Firmware hoch → persistent compromise.
• Ziel: Feststellen, ob die ECU Firmware-Authentizität prüft und ob unsignierte Images akzeptiert werden könnten.

Erfolgskriterien / Findings:

• Kritisch: Bootloader akzeptiert Firmware ohne signaturprüfungen oder keine Rollback-Prevention.
• Mittel: Signaturprüfung vorhanden, aber Schlüssel unsicher oder leicht extrahierbar (nur durch kombinierte Hardware-Analysen).

3) Default-Credentials / offene Management-Ports

• Alte oder schlecht konfigurierte ECUs/TCUs können Dienste (Telnet, SSH, Web) mit Default-Passwörtern oder offenen Accounts haben.

Wie könnte ein Angreifer das ausnutzen (hoch-level)?

• Scannen auf offenen Ports (remote/über Telematik); Anmelden mit Default-Credentials → Shell → Pivot ins Fahrzeugnetzwerk.
• Ziel: Feststellen, ob Management-Dienste (SSH/Telnet/HTTP) offen sind und ob schwache/default Authentifizierung möglich ist.

Erfolgskriterien / Findings:

• Hoch: Offene unverschlüsselte Dienste mit Default-Credentials oder keine Zugangsbeschränkung aus dem Mobilfunknetz.
• Mittel: Dienste vorhanden, aber mit starken Schlüssel-/Zertifikat-Mechanismen.

4) Hardware-Debug-Interfaces offen (JTAG / SWD)

• Offene JTAG/SWD-Pins ermöglichen direktes Auslesen/Schreiben von Flash, setzen Breakpoints, extrahieren Firmware.

Wie könnte ein Angreifer das ausnutzen (hoch-level)?

• Physischer Zugang → Verbinde JTAG → Firmware dumpen → Offline-Analyse → Schwachstellen finden oder Bootloader ändern.
• Ziel: Prüfen, ob Debug-Interfaces zugänglich sind und ob sie produktiv deaktiviert/sicher gemacht wurden.

Erfolgskriterien / Findings:

• Kritisch: Debug-Interfaces offen und nicht gesichert in Produktionshardware.
• Mittel: Debug vorhanden, aber erfordert spezielle Jumper/Service-Mode.

5) Schlechte Netzwerksegmentierung (Pivoting)

• Nicht-kritische Systeme (Infotainment) sind mit kritischen Bussen (Powertrain/Gateway) verbunden ohne strikte Isolation → Kompromittierung erlaubt laterale Bewegung (Pivot).

Wie könnte ein Angreifer das ausnutzen (hoch-level)?

• Angreifer exploitet Infotainment (z. B. Buffer overflow in Media-Parser) → erlangt Code Execution → nutzt schlecht konfigurierte Gateway-Regeln, um CAN-Messages in Powertrain Bus zu senden.
• Ziel: Prüfen, ob Kompromittierung einer nicht-kritischen ECU zur lateral movement (z. B. Infotainment → Gateway → Powertrain) erlaubt.

Erfolgskriterien / Findings:

• Kritisch: Gateway routet oder setzt keine valide Whitelist durch → non-privileged ECU kann sicherheitskritische IDs erreichen.
• Mittel: Gateway filtert, aber erlaubt einige sensitive DIDs/IDs.

6) Timing-Angriffe / Denial-of-Service (Bus-Flooding, dominante Bits)

Was ist das?
CAN ist zeitkritisch und arbitrationsbasiert. Wenn ein Knoten ständig sendet oder dominante Bits hält, kann er anderen Knoten die Übertragung verhindern (DoS). Auch übermäßiges Traffic kann Latenz erzeugen und timeouts hervorrufen.

Wie könnte ein Angreifer das ausnutzen (hoch-level)?

• Physischer Zugang → sendet sehr hohe Frequenz an Nachrichten (Bus-Flooding) oder setzt dominante Bits → andere ECUs können kritische Frames nicht senden.
• Ergebnis: Safety-Funktionen werden verzögert oder deaktiviert.
• Ziel: Überprüfen, ob Bus-Schutzmaßnahmen existieren und wie ECUs auf hohe Last / Arbitration-Abuse reagieren.

Erfolgskriterien / Findings:

• Kritisch: Bereits moderate Erhöhung der Last führt zu Safety-relevanten Timeouts oder Bus-Off einzelner ECUs.
• Mittel: ECUs werden Error-Passive/BusOff aber recovery funktioniert; hohe Latenz bis kritische Messages verzögert sind.

Kern-Hardware (must-have)

1. USB → CAN Adapter (Budget / Open-Source) — zum Senden/Empfangen von CAN-Frames auf dem PC

• Warum: Grundgerät für jeden CAN-Test (Sniffen, Senden, Replay).
• Beispiel: CANable / CANable Pro (Open Hardware, gute Linux-Unterstützung, günstig).
• Preis: ≈ €20–40 (günstige Varianten).

2. USB → CAN Adapter (professionell / robust) — zuverlässiges, getestetes Interface für Arbeit an echten Fahrzeugen

• Warum: Bessere Treiber, galvanische Trennung, stabile Timing-Eigenschaften; empfehlenswert wenn du ernsthaft testest.
• Beispiel: Peak-System PCAN-USB / ValueCAN (Peak ist Industriestandard).
• Preis: ≈ €110–180 (je nach Modell).

3. Raspberry Pi + CAN-HAT (oder Pi + USB-CAN) – mobiles, eigenständiges Labor/Logger

• Warum: Ideal als tragbarer Logger, Replay-Box oder kleines Test-Gateway; viele HATs mit MCP2515-Transceivern verfügbar.
• Beispiel: 2-Channel MCP2515 CAN HAT für Raspberry Pi.
• Preis: HAT ≈ €25–40 + Pi ≈ €35–70.

4. OBD-II → DB9 / OBD-Kabel

• Warum: Verbindung zwischen Adapter (z. B. CANable) und OBD-Port des Fahrzeugs. Unverzichtbar.
• Beispiel: OBD-II to DB9 / OBDLink-Kabel (verschiedene Ausführungen).
• Preis: ≈ €10–25.

5. Professionelles OBD-Interface (optional alternativ zum CAN-Adapter)

• Warum: Wenn du viel mit UDS/OBD arbeitest und stabile, fahrzeugspezifische Tools brauchst (z. B. FORScan, Hersteller-Software).
• Beispiel: OBDLink EX / OBDLink SX.
• Preis: ≈ €70–100.

Nützliche Zusatz-Hardware (empfohlen)

6. Logic Analyzer / Protocol Analyzer

• Warum: Für Debugging von UART, SPI, I²C oder zum Analysieren von Boot-Pins/JTAG Signalen. Unverzichtbar bei Hardware-Reverse-Engineering.
• Beispiel (Pro): Saleae Logic (Logic 8 / Pro) — sehr gute Software/UI.
• Preis: ≈ €500 (Logic 8), höher für Pro-Modelle.

7. RTL-SDR (z. B. RTL-SDR Blog v3)

• Warum: Günstiger Einstieg in Funkanalyse (Key-Fob Research, RF-Sniffing, ASK/OOK/FSK). Nicht nur für Keyfob, viele Experimente möglich.
• Preis: ≈ €25–120 (je nach Kit/Version).

8. JTAG / SWD Adapter / Debug-Kabel (Adapter + Probe)

• Warum: Für Hardware-Debugging und Firmware-Dumping auf Testboards (nur im Labor!).
• Beispiel: Adafruit JTAG↔SWD Adapter, passende Probe-Kabel.
• Preis: ≈ €5–60 (Adapter und Probe).

9. USB-OBD Dongles (ELM327 Clones) – nur für einfache OBD/Mode01-Messungen

• Warum: Günstig für schnelle Tests mit Apps (Torque); nicht zuverlässig für tiefere Diagnostics.
• Warnung: Viele Billig-ELM-Clones verhalten sich fehlerhaft — für ernsthafte Arbeit lieber CANable oder OBDLink.
• Preis: ≈ €8–25.

Attack Vector #1: CAN Bus Injection

1) Worum geht’s genau bei „CAN Injection“?

• Prinzip: Der Angreifer sendet gefälschte CAN-Frames auf dem Fahrzeugbus. Wegen der Broadcast-Natur und fehlender Authentifizierung akzeptieren ECUs diese Nachrichten, sofern sie vom System als gültig erachtet werden.
• Ziel: Werte imitieren, Steuerbefehle auslösen, Statusanzeigen/manipulieren, selten: kritische Aktoren beeinflussen.

2) Warum funktioniert das?

• CAN ist message-basiert: Inhalt wird durch CAN-ID und Datenbytes interpretiert — nicht durch Absenderauthentizität.w
• Priorität: Niedrigere ID gewinnt Arbitration – ein Sender mit niedriger ID kann zeitkritische Nachrichten vorrangig platzieren.
• ISO-TP/UDS: Längere Diagnosenachrichten laufen über ISO-TP; Programmier/Flash-Flows erfordern oft Session- und Security-Mechanismen.
• Kein Authentifizierungslayer: Ohne zusätzliche Schutzschichten (MAC, Gateway-Filter) akzeptieren ECUs fremde Frames.

Szenario: Du hast Zugang zum CAN Bus (via OBD-II oder kompromittiertes Infotainment)

Was kannst du tun?

1. Sniffen & Reverse Engineering:
   • Sniffen-Ziel: Bus-Topologie und Message-Bedeutungen verstehen.
   • Reverse-Engineering-Ziel: Bit-/Byte-Bedeutung identifizieren
   • Logger starten: candump can0 (oder dein Python-Sniffer). Sammle Baseline-Logs in verschiedenen Fahrzeugzuständen (Zündung OFF/ON, Tür öffnen, Bremsen betätigen, Fahren, Park).
   • Frequenzanalyse: Welche IDs senden regelmäßig? (z. B. jede 100 ms für Geschwindigkeit).

# Linux mit SocketCAN
candump can0

# Ausgabe:
can0  0C9   [8]  00 00 00 00 28 64 00 00
can0  244   [8]  FE FF 00 00 00 00 15 0D
can0  309   [8]  00 3F 19 00 00 00 00 7C

2. Message Replay:
   • Ziel: Reproduktion bekannter Frames in einer sicheren Umgebung (vcan/test harness) um Effekte zu sehen.
   • Aufzeichnen: candump -l can0 speichert Logfile.
   • Replay in vcan: Verwende canplayer oder python-can um Log auf vcan0 zu spielen und beobachte Verhalten. Dadurch sieht man, ob eine ECU auf Replay reagiert.
   • Beobachte: ACK-Verhalten, Fehlerframes, ob Anzeigen/Simulator reagieren.

# candump erzeugt candump-LOGFILES; canplayer spielt diese auf dem Bus ab
canplayer -I candump-<timestamp>.log -g 1
# -g 1 = tempo factor (langsamer spielen)

# Eine Nachricht senden
cansend can0 244#FEFF00000000150D

3. Fuzzing:
   • Ziel: Robustheit von ECUs gegenüber unerwarteten/formatwidrigen Frames testen.
   • Scope & Limits: Begrenze Rate, Dauer, ID-Bereiche. Teste zuerst auf vcan bzw. Test-ECUs.
   • Monitor: ECU error counters, bus load, whether ECUs enter Error Passive/Bus Off.
   • DoS-Simulation: Simuliere erhöhte Last und beobachte, ob kritische Nachrichten verloren gehen oder ECUs zeitkritisch reagieren.

import can
import time

bus = can.interface.Bus(channel='can0', bustype='socketcan')

# Alle möglichen IDs durchprobieren
for can_id in range(0x000, 0x7FF):
    for data_byte in range(0x00, 0xFF):
        msg = can.Message(
            arbitration_id=can_id,
            data=[data_byte, 0x00, 0x00, 0x00],
            is_extended_id=False
        )
        bus.send(msg)
        time.sleep(0.01)

Mögliche Auswirkungen:

• Dashboard-Anzeigen manipulieren
• Warnleuchten auslösen
• Türen entriegeln
• Motor abstellen (bei älteren Fahrzeugen)
• Bremsen/Lenkung beeinflussen (sehr schwierig, oft nur bei Spezialsystemen)

3) Welche Effekte sind realistisch — und welche selten?

• Hoch realistisch / häufig: Manipulation von Anzeigen, Fehlermeldungen auslösen, Türen verriegeln/entriegeln (bei älteren Systemen oder wenn entsprechende IDs ohne Auth zugänglich sind).
• Mittel: Engine start/stop, Steuerparameter ändern — abhängig von Hersteller-Gateways und Security.
• Selten / schwer: Direkt Bremsen/Lenkung beeinflussen — moderne Fahrzeuge haben starke Segmentierung und Safety-Mechanismen; Ausnutzung erfordert deutlich mehr Wissen und oft physische Interaktion.

4) Zusammenfassung — das Wichtigste in Kürze

• CAN Injection ist möglich, weil CAN keine Authentifizierung hat.
• Beginne immer mit passivem Sniffing und Mapping.
• Replay / Injection nur in isolierten Lab-Setups (vcan, Test-ECUs).
• Fuzzing/Stress kann Schwachstellen aufdecken, aber nur kontrolliert und sicher.

Attack Vector #2: Key Fob Relay Attack

1) Wie funktioniert Keyless Entry?

Ein modernes Fahrzeug mit „Keyless Entry“ oder „Passive Entry/Start“ erkennt automatisch, wenn sich der Schlüssel (Key Fob) in der Nähe befindet.
Das System basiert auf zwei Funkfrequenzen:

2) Der normale Ablauf (Challenge-Response-Protokoll)

1. LF Wake-Up:
   Das Auto sendet ein 125 kHz Signal, um nach einem Schlüssel in der Nähe (1–2 Meter) zu „rufen“.
2. Key Activation:
   Der Key Fob empfängt das Signal, „wacht auf“ und antwortet per RF-Signal.
3. Challenge:
   Das Auto sendet eine zufällige „Challenge“ (Zufallszahl).
4. Response:
   Der Key berechnet mit seinem geheimen Schlüssel eine „Response“ (z. B. über symmetrische Verschlüsselung wie AES).
5. Verification:
   Das Auto prüft die Antwort — stimmt sie, wird das Auto entsperrt oder gestartet.

Das System ist sicher, solange der Key wirklich in der Nähe ist.
Aber genau das ist der Knackpunkt, den der Relay-Angriff ausnutzt.

3) Was passiert beim Relay Attack?

Hier ist die Idee:

Der Angreifer verlängert einfach die Reichweite der Funkverbindung zwischen Auto und Schlüssel.

Dadurch glaubt das Fahrzeug, der Key sei in der Nähe – obwohl er z. B. noch im Haus liegt.

4) Ablauf eines Relay-Angriffs:

Angreifer Gerät 1 (beim Auto)  <--WiFi/Radio-->  Angreifer Gerät 2 (beim Key)
         |                                                    |
    [Verstärkt Signal]                              [Verstärkt Signal]
         |                                                    |
      [Auto]                                              [Key Fob]

1. Angreifer A steht mit einem Relaisgerät (z. B. Funkverstärker) beim Auto auf der Straße.
2. Angreifer B steht mit einem zweiten Gerät in der Nähe des echten Schlüssels (z. B. im Hausflur).
3. Das Fahrzeug sendet sein normales LF-Wake-up.
4. Angreifer A fängt das Signal ab und leitet es drahtlos an Angreifer B weiter (über WLAN, Bluetooth oder andere Funktechnik).
5. Angreifer B sendet das Signal an den echten Key Fob.
6. Der Key Fob antwortet per RF, wie immer.
7. Das Signal wird über die Relaisstrecke wieder zurück zum Auto übertragen.
8. Das Auto erhält eine gültige Antwort und öffnet sich — es denkt, der Key sei direkt daneben.

5) Warum das funktioniert:

• Das Auto prüft nicht, wie lange das Signal gebraucht hat.
• Es gibt keine Distanzprüfung („Distance Bounding“).
• Der Funkverkehr wird nur „verlängert“, aber nicht verändert – die kryptografischen Werte bleiben gültig.

6) Typische Distanz & Reichweiten

• LF-Signal (normal): 1–2 m
• RF-Signal (normal): bis 10 m
• Mit Relay-Geräten: bis 30–100 m möglich (durch Wände hindurch)
• Einige Versuche im Labor (z. B. Universität Zürich, ETH, NCC Group) haben gezeigt, dass einfache Verstärker mit handelsüblicher Funktechnik ausreichen, um diese Reichweite zu überbrücken

7) Warum das sicherheitsrelevant ist

Ein Angreifer kann:

• Das Auto öffnen, ohne sichtbare Spuren zu hinterlassen.
• Das Fahrzeug starten, falls das System Keyless Start erlaubt (weil das Auto denkt, der Key sei innen).
• Danach wegfahren, solange der Motor läuft (bei vielen Modellen kein Reauth nötig).
• Wenn der Motor aus ist, kann er nicht mehr starten, aber das Auto ist bereits entwendet.

8) Verteidigung:

• Distance Bounding: Fahrzeug misst Laufzeit zwischen Challenge & Response (Nanosekunden-Genauigkeit). Relay verursacht messbare Verzögerung.
• Ultra-Wideband (UWB): UWB misst Entfernung präzise (< 10 cm). Viele neue Fahrzeuge (z. B. VW, BMW, Tesla) nutzen das.
• Motion Sensors im Key: Key sendet nur, wenn er bewegt wird. Wenn er still liegt (z. B. im Haus), antwortet er nicht.
• Key Shielding / Faraday Box: Nutzerseitig: Key in Metallhülle legen, um Signale zu blockieren.

Attack Vector #3: Infotainment Exploitation

1) Warum Infotainment so angreifbar wirkt

Ziel: Shell auf Infotainment -> Gateway-Bypass -> CAN-Zugang

• Große Angriffsfläche: USB, SD, Media-Parser, Bluetooth, Wi-Fi/Hotspot, Apps, Browser, oft auch OTA/Telematik.
• Heterogener Stack: Linux / Android Automotive / QNX / proprietär + Drittanbieter-Komponenten (Codec-Libraries, BT/Wi-Fi-Chips, Browser-Engines).
• Brückenfunktion: Sitzt häufig an Ethernet/CAN-Gateways (Infotainment-CAN, Diagnose-CAN, ggf. Zugriff auf SOME/IP/DoIP-Dienste).

2) Angriffspunkte:

1. USB Stack: Badische USB-Devices
2. WiFi: Standard-Passwords, WPS-Schwachstellen
3. Bluetooth: Pairing-Schwachstellen, RCE in Stack
4. Apps: Third-party Apps mit Schwachstellen
5. Media Parser: Buffer Overflows in MP3/Video-Parser

3) Woran man Probleme erkennt (Red Flags)

• ADB/SSH aktiv im Feld, default creds, offener Root-Dropbear.
• WPS on / schwache Passwörter im Hotspot.
• Automount & autoplay von Medien.
• Parser-Crashes bei kaputten Dateien; Watchdog-Reboots.
• Infotainment kann direkt Diagnose-Dienste (DoIP/SOME-IP) talken ohne Gateway-Policy.
• Fehlende Sandbox/SELinux: alle Prozesse laufen „unconfined“.

4) Erfolgskriterien (ohne Ausnutzung)

• Keine Automounts, keine Dev-Ports offen, robuste Parser (keine Crashes), Gateway blockt interne Requests, strikte Trennung der Netze.

Attack Vector #4: Telematics (Remote)

Was ist Telematics? Eine Telematics Control Unit (TCU) ist ein vernetztes Modem+Computer im Fahrzeug. Sie spricht mit OEM-Backends und lokal mit anderen ECUs.

[ Internet/Carrier ]
       │   (APN, VPN, TLS, SMS/Wakeup)
       ▼
[ OEM Backend / Cloud ]  ──(MQTT/HTTPS/NGTP/DoIP)──  [ TCU ]
                                                 │
                                     (Eth/CAN/LIN/GW)
                                                 ▼
                                     [ Gateway ECU ] ── (CAN/Powertrain/Body)

• Nach außen: Mobilfunk (4G/5G), teils SMS/USSD für Wakeup, Protokolle wie HTTPS/TLS, MQTT, NGTP, OEM-APIs, OTA-Update-Kanäle.
• Nach innen: Ethernet/Diagnose-CAN, UDS/DoIP-Bridges, manchmal serielle Side-Links zu Head-Unit.

Angriffskette:

1. Identify Target Vehicle (VIN, License Plate) - indirekt über OEM-App-Konten, Serviceauftragsdaten, Leaks.
2. Enumerate TCU (Telematics Control Unit)
   - IP Address (via carrier network)
   - Open Ports (SSH, Telnet, HTTP, Custom Protocols)
3. Exploit Service
   - Default Credentials, Schwache Session-Prüfung
   - Buffer Overflow - RCE in Web/Daemon
   - Command Injection in Update-/Diag-Pfaden
4. Gain Shell on TCU
5. Pivot to CAN Bus - Interne Schnittstellen (Ethernet/DoIP/Diag-CAN). Gateway-Policy entscheidet, ob UDS/IDs durchkommen

Angriffsflächen? (nach außen & innen)

• Öffentliche Angriffsfläche (Mobilfunk): Fehlkonfiguration (öffentliche IP, schwache APN-Isolation), schwache Auth, exponierte Services.
• Reichweite: Remote erreichbare Schwachstellen → großflächiger Impact.

Nach außen (Mobilfunk/Cloud)

• APN/Netzpfad: Ist die TCU in einem privaten APN hinter Carrier-NAT/VPN, oder hat sie öffentliche IP?
• Management-Ports: Historisch: offen/unsicher (SSH/Telnet/HTTP); heute: geschlossen, nur mTLS/VPN.
• OTA/Device-Mgmt: OMA-DM/HTTPS/MQTT-Broker – falsche AuthZ, fehlende Signaturprüfung, unsichere Update-Flows.
• App/Backend-APIs: Schwache Auth (Token-Reuse, Insecure Direct Object Reference), mangelhafte Rate-Limits.

Nach innen (Fahrzeug-Seite)

• DoIP / SOME/IP: Diagnose über IP – benötigt strikte Whitelists, Session-/SecurityAccess.
• UDS-Bridges: TCU fungiert als Proxy – muss hart gefiltert werden (kein Programmieren via Remote ohne strikte Freigaben).
• Head-Unit Link: Seitliche Verbindung zur Infotainment – lateral movement bei HU-Kompromittierung.

Reale Beispiele:

• Jeep Cherokee Hack (2015) – Sprint Cellular -> Uconnect -> CAN
• BMW ConnectedDrive (2015) – NGTP Protocol Vulnerability

Grundlegende Tools & Setup

Software-Setup (Linux empfohlen)

SocketCAN – was ist das überhaupt?

SocketCAN ist die Linux-Schnittstelle für CAN, so wie eth0 für Ethernet.

• Du kannst mit CAN so arbeiten, als wäre es ein normales Netzwerk-Interface.
• Tools wie candump, cansend, python-can nutzen alle diese Kernel-Integration.
• Vorteil: Du brauchst keine Spezialsoftware – nur Linux + Treiber.

Es gibt zwei typische Arten von Interfaces:

• Virtuelle Interfaces → vcan0 (nur zum Testen, kein echtes Auto).
• Echte CAN-Interfaces → can0, can1, … (z. B. über USB-Adapter wie CANable).

SocketCAN einrichten:

# Virtual CAN für Tests
sudo modprobe vcan
sudo ip link add dev vcan0 type vcan
sudo ip link set up vcan0

# Echtes CAN-Interface (z.B. mit CANable)
sudo ip link set can0 type can bitrate 500000
sudo ip link set up can0

Was passiert hier?

1. modprobe vcan
   – Lädt das Kernel-Modul für virtuellen CAN. Das ist wie ein „Fake-CAN-Kabel“ im RAM.
2. ip link add dev vcan0 type vcan
   – Erstellt ein neues Interface mit Namen vcan0.
   – Es verhält sich wie ein CAN-Bus, aber ohne physische Leitung.
3. ip link set up vcan0
   – Aktiviert das Interface (wie ifconfig up bei Netzwerkkarten).

Wenn du ein USB-CAN-Interface hast (CANable, CANtact, Peak, etc.), taucht es in Linux z. B. als can0 auf (oder du konfigurierst es so).

1. ip link set can0 type can bitrate 500000
   – Sagt dem Kernel: Interface can0 ist ein CAN-Interface mit 500 kbit/s (typisch für High-Speed-CAN im Fahrzeug: 500.000 Bits pro Sekunde).
   – Die Bitrate muss zum Bus passen. Wenn dein Auto 500 kbit/s spricht und du 250 kbit/s einstellst → Chaos.
2. ip link set up can0
   – Aktiviert das Interface.

Wenn du ein USB-CAN-Interface hast (CANable, CANtact, Peak, etc.), taucht es in Linux z. B. als can0 auf (oder du konfigurierst es so).

can-utils installieren:

sudo apt-get install can-utils

# Wichtigste Befehle:
candump can0              # Zeigt alle Nachrichten auf dem Interface
cansniffer can0           # Änderungen highlighten - Welche ID ändert sich, wenn ich das Licht anmache?
cansend can0 123#DEADBEEF # Nachricht senden - Syntax: ID#DATA
canplayer -I logfile.log  # Replay von Log. z.B. Replayed einen zuvor mit candump -l aufgezeichneten Log. 
cangen can0               # Generiert zufälligen Traffic - Zufällige IDs, Daten, Rate konfigurierbar

Python für CAN: (python-can)

pip install python-can

# Python Script (Sniffer)
import can
# Öffnet das Linux-CAN-Interface can0 via SocketCAN.
bus = can.interface.Bus(channel='can0', bustype='socketcan')
# Blockiert und liefert dir für jede ankommende Nachricht ein Message-Objekt
for msg in bus:
    print(f"ID: {msg.arbitration_id:03x} Data: {msg.data.hex()}")

# Dasselbe kannst du natürlich mit vcan0 machen

Hardware Minimum-Setup

Budget-Option (~100€):

1. CANable/CANtact USB-Adapter (~50€)
   - USB zu CAN Converter -> Macht aus USB → CAN.
   - Hängt an deinem PC wie ein „Netzwerkkabel“, aber für CAN.
   - Open Source Hardware.
   
2. OBD-II zu DB9 Kabel (~15€)
   - Das OBD-Port im Auto ist meistens eine 16-polige Buchse.
   - Verbindet OBD-II Port mit CANable
   
3. Raspberry Pi + CAN Hat (~80€)
   - Alternative zu CANable bzw. zu einem USB-Adapter.
   - CAN-HAT steckt oben auf dem Pi: Enthält z. B. MCP2515 + Transceiver.
   - Du kannst dir eine portable Sniffer-Box bauen: 
         - Pi + HAT + SD-Karte -> einstecken, Logging starten, später Logfiles auslesen.

Test-Setup ohne echtes Auto:

[Computer] --- USB --- [CANable #1] ---+
                                        |
                                      [CAN Bus]
                                        |
[Computer] --- USB --- [CANable #2] ---+

Beide senden/empfangen auf gleichem Bus

Varianten:

• Ein Computer mit zwei USB-Adaptern:
  • z. B. can0 und can1
  • Du kannst:
    • auf can0 senden
    • auf can1 sniffen
    • so „Man-in-the-Middle“, Gateway- oder Bridge-Labors bauen.
• Zwei Computer, je ein Adapter:
  • Perfekt, um Sender/Empfänger/Sniffer-Setups zu simulieren.

candump vcan0

cansniffer vcan0

cansend vcan0 244#0000000000FF0000

Erste praktische Schritte

Lab 1: ICSim (Instrument Cluster Simulator)

Was ist ICSim überhaupt?

ICSim (Instrument Cluster Simulator) ist ein kleines Programm, das:

• ein virtuelles Kombiinstrument (Tacho, Blinker, Türen etc.) als Fenster auf deinem Bildschirm anzeigt
• über CAN-Nachrichten auf vcan0 gesteuert wird

Und das controls-Programm:

• simuliert z. B. Gaspedal, Türen, Zündung → es sendet CAN-Nachrichten, die ICSim anzeigt.

Du hast damit also:

• eine „ECU“ (controls), die CAN sendet
• ein „Instrument Cluster“ (icsim), das CAN empfängt und visualisiert
• und du selbst schnüffelst dazwischen mit candump & Co.

Installation:

git clone https://github.com/zombieCraig/ICSim
cd ICSim
sudo apt-get install libsdl2-dev libsdl2-image-dev
make

# Setup Virtual CAN
sudo modprobe vcan                      # lädt das vcan-Modul
sudo ip link add dev vcan0 type vcan    # erstellt ein Interface mit Namen vcan0
sudo ip link set up vcan0               # Interface aktivieren, damit es benutzt werden kann

# Starten
./icsim vcan0 &
./controls vcan0

• ./icsim vcan0 &
  → startet den Instrument Cluster Simulator im Hintergrund und sagt ihm:
  • „höre auf vcan0“.
  Du siehst jetzt ein Fenster mit Tacho, Türen, Blinker etc.
• ./controls vcan0
  → öffnet ein zweites Fenster (oder Terminal-GUI), mit dem du:
  • Gas geben,
  • Blinker setzen,
  • Türen öffnen/schließen,
  • Zündung an/aus machen kannst.

Wenn du in controls z. B. „rechts blinken“ drückst, sendet controls eine CAN-Nachricht auf vcan0 → icsim reagiert und zeigt den Blinker an.

# Beispiel: Geschwindigkeit auf Maximum
cansend vcan0 244#0000000000FF0000

Lab 2: CAN Traffic Reverse Engineering

Methodik:

1. Baseline Recording:

candump -l can0  # Loggt in candump-*.log
# Fahrzeug im Ruhezustand, keine Aktionen

2. Action Recording:

# Aktion durchführen (z.B. Tür öffnen)
# Weiter loggen

3. Diff Analysis:

# Zwei Logs vergleichen
diff baseline.log action.log

4. Pattern Identification:

# Beispiel-Skript
import can

counts = {}
bus = can.interface.Bus(channel='can0', bustype='socketcan')

for msg in bus:
    id = msg.arbitration_id
    counts[id] = counts.get(id, 0) + 1
    
    if counts[id] % 100 == 0:
        print(f"ID 0x{id:03x}: {counts[id]} messages")

Lab 3: UDS Security Access

Ziel: ECU Security Access knacken (schwaches Seed-to-Key)

Vorgehen:

import isotp
import time

# ISO-TP Socket für UDS
s = isotp.socket()
s.bind(("can0", 0x7E0, 0x7E8))  # Tester, ECU

# Extended Session
s.send(bytes([0x10, 0x03]))
response = s.recv()
print(f"Session Response: {response.hex()}")

# Security Access - Request Seed
s.send(bytes([0x27, 0x01]))
response = s.recv()
seed = response[2:]  # Skip Service ID und Sub-function
print(f"Seed: {seed.hex()}")

# Seed-to-Key (Beispiel: einfaches XOR)
def simple_seed_to_key(seed):
    key = bytes([s ^ 0x42 for s in seed])
    return key

key = simple_seed_to_key(seed)

# Send Key
s.send(bytes([0x27, 0x02]) + key)
response = s.recv()
if response[0] == 0x67:
    print("Access Granted!")
else:
    print("Access Denied")

Grundlagen der Threat Analysis

STRIDE für Automotive:

• Spoofing: ECU impersonation auf CAN
• Tampering: Firmware Manipulation
• Repudiation: Keine Logs von CAN Messages
• Information Disclosure: Sensitive Daten über OBD-II
• Denial of Service: CAN Bus Flooding
• Elevation of Privilege: Default Session -> Programming Session

Attack Tree Beispiel:

Goal: Remote Code Execution im Fahrzeug
├── Via Telematics
│   ├── Cellular Network
│   │   ├── Find TCU IP
│   │   └── Exploit TCU Service
│   └── Via Backend Server
│       └── Compromise OEM Cloud
└── Via Proximity
    ├── Bluetooth
    │   └── Exploit Infotainment BT Stack
    └── WiFi
        └── Connect to AP + Exploit Service

Safety vs Security

Wichtig zu verstehen:

Safety (ISO 26262):

• „Wird das System sich sicher verhalten?“
• Schutz vor zufälligen Fehlern
• ASIL Levels (A-D)

Security (ISO 21434):

• „Wird das System gegen Angriffe geschützt?“
• Schutz vor böswilligen Akteuren
• CAL Levels (Cybersecurity Assurance Level)

Overlap: Ein Security-Exploit kann zu Safety-Problem werden! Beispiel: CAN Injection -> Fehlerhafte Sensor-Daten -> Falsches ABS-Verhalten

Deine Learning Path

Phase 1 – Grundlagen (2-4 Wochen):

• [ ] CAN Bus Protokoll verstehen
• [ ] OBD-II und UDS lernen
• [ ] ICSim komplett durchspielen
• [ ] can-utils meistern

Phase 2 – Praktisch (1-2 Monate):

• [ ] Hardware kaufen (CANable)
• [ ] Eigenes Auto analysieren (nur lesen!)
• [ ] CAN IDs für Basic-Funktionen mappen
• [ ] UDS Scanner schreiben

Phase 3 – Vertiefung (3-6 Monate):

• [ ] Infotainment System analysieren
• [ ] Key Fob Protokolle mit SDR
• [ ] Gateway-Implementierung studieren
• [ ] Echtes Pentest-Projekt