Wenn Frontends Autos öffnen: 8 Architekturfehler aus einem echten Dealer-Portal-Hack

An der DEF CON 33 hat der Security-Experte Eaton Zveare gezeigt, wie er sich in ein Händlerportal eines grossen Autoherstellers gehackt hat – und damit theoretisch jedes verbundene Auto entsperren, starten und orten konnte.

Das Brisante: Er brauchte keinen Fahrzeugzugang vor Ort, sondern nur einen Webbrowser und ein paar Tricks. Was passiert ist, liest sich wie ein Thriller – für uns Webentwickler ist es aber vor allem ein Lehrstück, wie Software-Architektur nicht aussehen sollte.

Die Slides zur Präsentation vom 10. August 2025 findest Du hier: DEF CON 33: How I Hacked a Car Dealership Portal.

Was ist passiert?

(Kurz und knackig)

• Fehlerhafte Login-Logik im Client: Beim Laden der Login-Seite wurde Code in den Browser gezogen, den man manipulieren konnte, um Auth-Checks zu umgehen.
• Privilegien-Eskalation: Aus einem Händler-Login wurde ein „National Admin“-Account mit Zugriff auf über 1’000 Händlerkonten.
• Fehlerhafte Kopplung: Über das B2B-Händlerportal konnte man B2C-App-Accounts mit Fahrzeugen verknüpfen – Name oder VIN reichten.

Das Ergebnis: Volle Kontrolle über fremde Fahrzeuge – inklusive Türen, Motor und Standort.

Die 8 grössten Fehler

...und wie Du deine Architektur besser machst

1. Vertrauen ins Frontend (Client-Side Auth/ACL)
   Fehler: Sicherheitslogik lief im Browser und war manipulierbar.
   Besser: Authentifizierung und Autorisierung nur auf dem Server durchführen. Niemals “isAdmin=true” im JWT ohne Server-Side Introspection. Frontend darf nur UX-Gates zeigen – kein Gatekeeper sein.
2. Horizontale/vertikale Rechte nicht strikt getrennt
   Fehler: Händler konnten sich Admin-Rechte verschaffen.
   Besser: Least Privilege – nur minimal nötige Rechte, keine Self-Service-Upgrades, MFA für kritische Aktionen.
3. Keine sauberen Systemgrenzen
   Fehler: Händlerportal durfte direkt Consumer-App-Daten verändern.
   Besser: B2B- und B2C-Dienste strikt trennen, nur minimal notwendige API-Endpunkte freigeben.
4. Unsichere Objektzugriffe
   Fehler: Name/VIN reichten als Besitznachweis.
   Besser: Besitz mit kryptografischen Challenges oder Mehrfaktor prüfen.
5. Überexponierte Admin-Funktionen
   Fehler: Hochprivilegierte Endpunkte waren erreichbar.
   Besser: Admin-Oberflächen isolieren, per IP oder VPN schützen, keine Admin-Logik im SPA-Bundle.
6. Kein Defense-in-Depth
   Fehler: Ein Exploit führte direkt zum vollen Zugriff.
   Besser: Mehrere Schutzschichten, Angriffe automatisch erkennen und bei Gefahr sofort mit einem Not-Aus (Kill-Switch) kritische Funktionen blockieren.
7. Fehlendes Monitoring
   Fehler: Solche Angriffe hätten frühzeitig auffallen müssen (z. B. Massen-Suche nach Kunden/VINs).
   Besser: Zentrales Überwachungssystem einsetzen, welches Log-Daten analysiert und bei ungewöhnlichem Verhalten – wie massenhaften Suchanfragen oder Logins aus fremden Ländern – automatisch Alarm schlägt.
8. Blindheit bei Dritt-Software
   Fehler: Kritische Funktion in externer, kaum überprüfter Dealer-Software.
   Besser: Regelmässig prüfen, ob externe Dienste sicher sind, Penetrationstests durchführen und sicherstellen, dass ein Problem in einem Dienst nicht das ganze System lahmlegt.

Konkrete Umsetzungstipps

(für moderne Web-Stacks, z. B. Laravel + Vue/Nuxt)

• Server-seitige Gatekeeper
  • Laravel: Policies und Gates im Backend nutzen, keine versteckten Admin-Flags im Client.
  • Form Requests + Rate Limiting (per Aktion), signed URLs nur als zusätzliche Schutzschicht – nie als alleinige Autorisierung.
• Step-Up-Auth für High-Risk-Flows
  • Zusätzliche Authentifizierung bei besonders sensiblen Aktionen abfragen.
• Domänen-Trennung & API-Gateway
  • Dealer-Portal und Consumer-Services strikt trennen, Gateway mit klaren Regeln einsetzen.
• Sichere Besitzprüfung
  • Besitz mit kryptografischen Herausforderungen bestätigen lassen.
• Hardening der Admin-Oberfläche
  • Admin-Bereich isolieren, IP-Restriktionen setzen und jeden kritischen Vorgang auditieren.
  • Separates Deployment, IP-Allowlist, Conditional Access, No SPA-Bundling von Admin-Privileg-Logik ins allgemeine Frontend.
  • Audit-Pflicht: Kein Admin-Write ohne fälschungssicheren Audit-Eintrag.
• Threat Modeling & Security Tests
  • Vor jedem Release überlegen: Wo könnte ein Angriff möglich sein?
  • Automatische Sicherheitsscans im Entwicklungs- und Testprozess nutzen.
  • Externe Sicherheitsforscher einladen (Bug-Bounty).
  • Angriffe gezielt simulieren, um zu prüfen, ob andere Schutzmassnahmen greifen.

Was Du aus dem Fall mitnehmen kannst

Dieser Vorfall zeigt: Es war kein klassischer “Auto-Hack”, sondern ein Web-Architektur-Problem. Ein client-seitiger Authentifizierungsfehler, fehlende Systemtrennung und schwache Besitznachweise reichten, um aus einem B2B-Portal die Kontrolle über Consumer-Fahrzeuge zu erlangen.

Sicherheit muss von Anfang an Teil der Architektur sein – nicht ein nachträgliches Extra. Jeder dieser Fehler hätte einzeln schon Schaden anrichten können, zusammen führten sie zum Worst-Case.

Tipp: Genau diese Themen vertiefen wir in unseren Developer-Lehrgängen und den offenen Sessions unserer Barcamps, Hackathons und Friends Treffen – mit praxisnahen Beispielen, die Dir helfen, Sicherheitslücken von Anfang an zu vermeiden.

PS: Der Kommentar von unserem Dozenten Veith Zäch zu diesem Fall: "Die haben ihre Ausbildung definitiv nicht bei Web Professionals gemacht!" 😄