Dieser Beitrag wurde ursprünglich durch Rolf Eggenberger auf web-professionals.ch veröffentlicht und für the Stack leicht angepasst.
An der DEF CON 33 hat Security-Forscher Eaton Zveare gezeigt, wie er sich in ein Händlerportal eines großen 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. Für uns bei the Stack ist dieser Fall ein Paradebeispiel dafür, warum Security by Design kein Luxus ist, sondern Pflicht – gerade bei komplexen Webplattformen.
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
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.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.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.Unsichere Objektzugriffe
Fehler: Name/VIN reichten als Besitznachweis.
Besser: Besitz mit kryptografischen Challenges oder Mehrfaktor prüfen.Ü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.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.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.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 Fall ist kein „Auto-Hack“ im klassischen Sinn – er ist ein Web-Architektur-Hack. Genau hier setzen wir bei the Stack an: Wir entwickeln Plattformen mit Security by Design, damit schon auf Architektur-Ebene verhindert wird, dass einzelne Fehler zu einem Totalausfall oder gar Sicherheitsvorfall führen.
Mehr zu unserer Arbeitsweise
Sichere Architektur ist kein Zusatzfeature – sie ist die Basis.
Sprich mit uns, wenn Du eine Plattform entwickeln willst, die sowohl leistungsfähig als auch von Grund auf sicher ist.
