Android-IVI-Security-Checks, die jede Head Unit bestehen sollte

Eine Android-Infotainment-Einheit ist ein Gerät der Smartphone-Klasse, das an ein Auto angeschlossen ist, und der größte Teil ihrer Sicherheit hängt an der Konfiguration: Build-Typ, Debug-Schalter, was ADB offenlegt, ob SELinux durchsetzt und welche App-Komponenten für andere Apps offen sind. Diese Checks gehen schnell, brauchen keinen Exploit und finden einen großen Teil dessen, was wir an Head Units berichten: ADB aktiv auf Builds, die es nicht haben sollten, debuggable Apps, ohne Permission exportierte Komponenten und System-Properties, die jeder lesen kann. Dieser Leitfaden listet die Checks, den Wert, den du sehen willst, und was eine Abweichung bedeutet.

Build- und Plattform-Flags

Beginne mit den System-Properties. Diese zeigen dir in Sekunden, welche Art von Build auf der Einheit läuft.

Property	Erwartet auf einem Serien-Build	Finding, wenn
ro.build.type	user	userdebug oder eng
ro.build.tags	release-keys	test-keys (Plattform mit öffentlichen Test-Keys signiert)
ro.debuggable	0	1 (jede App debuggable, Root-Shell möglich)
ro.secure	1	0
ro.adb.secure	1	0 (ADB ohne Host-Key-Bestätigung)
ro.build.version.security_patch	aktuelles Datum	weit hinter dem aktuellen Patch-Level der Plattform

Eine Abfrage sieht so aus:

$ getprop ro.build.type
user
$ getprop ro.debuggable
0

Ein test-keys-Build verdient besondere Aufmerksamkeit: die Plattform-Signierschlüssel des AOSP-Testsatzes sind öffentlich, also gilt alles, was damit signiert ist, als Systemcode.

ADB-Erreichbarkeit

ADB ist der Transport für die Checks selbst, und am Prüfstand ist das in Ordnung. Die Frage ist, wie ADB am Produkt erreichbar ist. Prüfe, ob ADB im Netzwerk lauscht (service.adb.tcp.port gesetzt oder ein Listener auf TCP-Port 5555), ob ein USB-Port im Innenraum eine Device-Mode-Verbindung erlaubt und ob sich die Entwickleroptionen über die Bedienoberfläche aktivieren lassen. Ein Finding an dieser Stelle heißt, dass physische oder Netzwerk-Nähe für eine Shell reicht, und das verschiebt die Attack-Feasibility-Bewertung in der TARA deutlich.

SELinux

getenforce sollte Enforcing liefern. Permissive auf einer Serieneinheit heißt, dass die Mandatory Access Control Verstöße protokolliert, aber nicht verhindert, also reicht ein schwacher Service, um den Rest des Systems zu erreichen. Schau dir auch die Domains an: Hersteller-Services in einer unbeschränkten oder zu breiten Domain sind eine mildere Form desselben Problems.

Apps und ihre Komponenten

Die meisten Head Units bringen Dutzende Hersteller-Apps mit. Prüfe für jede die Manifest-Flags und die offenen Komponenten:

• android:debuggable="true" in einem Serien-APK: ein Debugger kann sich anhängen und den Speicher der App lesen.
• android:allowBackup="true": App-Daten lassen sich eventuell über ein Backup herausziehen.
• Activities, Services, Receiver und Provider mit android:exported="true" und ohne Permission: jede App auf der Einheit kann sie starten oder abfragen. Auf einem IVI kann das Fahrzeugeinstellungen, Diagnosemenüs oder Daten eines gekoppelten Telefons betreffen.
• usesCleartextTraffic="true": die App spricht eventuell HTTP mit ihrem Backend.
• Gefährliche Permissions für Apps, die sie nicht brauchen, und Permissions, die dem Shell-User gewährt sind.

Die statische Analyse der APKs ergänzt den Secrets-Check: API-Keys, Backend-Zugangsdaten, private Schlüssel und fest eingetragene URLs interner Endpunkte in Ressourcen oder Code. Ein Secret in einem APK ist ein Secret auf jeder Einheit der Flotte.

Dateien und Properties

Liste auf, was eine Shell ohne Rechte lesen kann: weltlesbare Dateien unter /data, /sdcard, Hersteller-Partitionen und Logs. Achte auf VINs, Kontakte vom Telefon, Tokens und Konfiguration mit Zugangsdaten. System-Properties kann jede App lesen, eine Property mit einem Token oder einer URL samt Zugangsdaten ist also praktisch öffentlich. Logcat ist die dritte Stelle: Debug-Logging von personenbezogenen Daten oder Schlüsseln ist in Entwicklungs-Builds üblich und überlebt manchmal bis in die Serie.

Die Ergebnisse lesen

Nicht jede Abweichung wiegt gleich. Eine brauchbare Rangfolge für den Bericht:

1. Plattformebene: test-keys, ro.debuggable=1, SELinux permissive, ADB ohne Bestätigung erreichbar. Das untergräbt alles andere.
2. Erreichbarkeit: exportierte Komponenten ohne Permission, ADB über das Netzwerk, Secrets in APKs.
3. Hygiene: allowBackup, Klartext-Verkehr, veralteter Patch-Level, ausführliches Logging.

Halte je Finding den Build-Fingerprint (ro.build.fingerprint), die Paketversion und die exakte Ausgabe fest. Am Fingerprint erkennt ein Entwickler, ob der nächste Build das Problem noch hat.

Wie AutoST diese Checks ausführt

AutoST verbindet sich über ADB mit der Head Unit oder einem Emulator und führt die Aufklärung automatisch aus: Pakete, Permissions, exportierte Komponenten, abziehbare Dateien und den SELinux-Zustand, dazu statische Analyse der APKs auf Manifest-Flags und Secrets. Es kann auch funktionale Tests mit Screenshots und Live-Logcat ausführen. Jedes Finding kommt mit einer Behebung und landet im selben Fix Plan wie die UDS- und DoIP-Findings. Die tiefere IVI-Arbeit, etwa Hersteller-IPC-Schnittstellen, der Update-Pfad oder die Brücke zum Fahrzeugbus, bleibt Penetrationstest.