blueredix logo
SCAN Schwachstellenscans auf Abruf ab 149 €
info vuln-class-auth-bypass

Auth-Bypass, verständlich erklärt

Auth-Bypass ist eine Bug-Kategorie, bei der Angreifer eine geschützte Ressource erreichen, ohne die nötigen Credentials vorzulegen. Die peinlichsten CVEs der letzten Dekade leben hier.

Worum es geht

Authentication Bypass ist der Sammelbegriff für jeden Bug, der es einem Angreifer erlaubt, an eine geschützte Ressource zu kommen, ohne die geforderten Credentials vorzulegen. Die Kategorie deckt sehr unterschiedliche Fehler ab; gemeinsam ist das Resultat: der Angreifer ist drin.

Subtypen, die in CVE-Beschreibungen auftauchen:

  • Fehlende Authentifizierung an einem Endpoint. Der Login-Screen ist geschützt, der dahinterliegende API-Endpoint, der die eigentliche Arbeit erledigt, dagegen nicht. Wer die URL des Endpoints kennt, ruft ihn direkt auf und umgeht die Anmeldung vollständig.
  • Logikfehler im Auth-Code. Die Prüfung gibt aus dem falschen Grund “true” zurück: getipptes == statt ===, leeres Passwort als Match akzeptiert, “Admin-Override”-Header in der Produktion vergessen.
  • IDOR (Insecure Direct Object Reference). Authentifizierung funktioniert, Autorisierung fehlt. Eingeloggt als man selbst, aber Zugriff auf /orders/123456 einer anderen Kundin.
  • Pfad-basierter Bypass. Geschützt ist /admin/..., das Schutz-Regex ist ^/admin/, der Angreifer ruft /admin/../admin/... oder /admin;extra/... auf und rutscht durch.
  • Default-Credentials. “admin” / “admin” funktioniert weiterhin in vielen Geräten und Diensten: Router im Auslieferungszustand, MongoDB-Instanzen am Standardport ohne Authentifizierung, Jenkins-Installationen, bei denen die Ersteinrichtung nie abgeschlossen wurde.
  • JWT-Signaturen-Bypass. Eine lange Liste an Fehlbildern (alg: none, Key-Confusion zwischen symmetrisch und asymmetrisch, kid-Header-Path-Traversal) taucht in JWT-Libraries alle paar Jahre wieder auf.
  • OAuth-/OpenID-Fehlkonfiguration. Ein schwach validierter redirect_uri, ein state-Parameter, der nicht an die Session gebunden ist, ein Implicit Flow, wo der Auth-Code-Flow nötig wäre.

Warum es immer wieder passiert

Authentifizierung ist ein Feature, das man am Anfang eines Projekts ausliefert. Autorisierung (die endpoint- und record-bezogenen Prüfungen) wird in jedes spätere Feature von jedem Teammitglied eingewebt. Sobald das Team mehr als zwei Personen umfasst und die Codebasis ein paar Jahre alt ist, baut irgendjemand einen Endpoint, der den “darf-diese-Person-hier-hin”-Aufruf vergisst.

Die OWASP Top Ten führen Broken Access Control seit 2021 auf Platz 1, genau deshalb, weil die Lösung “jeder Endpoint, jedes Mal, für immer” lautet.

Was ein Angreifer gewinnt

Die Reichweite reicht von “ein Datensatz preisgegeben” (ein IDOR, ein Datensatz, den die Person nicht hätte sehen dürfen) bis “vollständige administrative Kontrolle” (unauth Admin-Endpoint in einem CMS, Default-Credentials in einem Router, JWT-Bypass in einer SaaS-API).

Aktuelle Beispiele, die das Muster zeigen:

  • Confluence Data Center CVE-2023-22518. Unauthentifizierter Admin-Zugriff über fehlrouteten Pfad. CVSS 10,0. Aktive Ausnutzung innerhalb einer Woche.
  • MOVEit Transfer CVE-2023-34362. SQL-Injection plus Auth-Bypass. 2023 für Datendiebstahl bei Shell, BBC, BA und Dutzenden weiteren.
  • Citrix NetScaler CVE-2023-3519. Unauthentifizierte Remote-Code-Execution via Auth-Bypass. Innerhalb von 24 Stunden nach Veröffentlichung als aktiv ausgenutzt gelistet.

Der Preis einer solchen CVE in einem Produkt, das Sie betreiben, ist typischerweise eine Pflichtmeldung an Ihre Kund:innen nach DSGVO Art. 33–34 plus ein Emergency-Patch.

Wie das behoben wird

Anwendungs-Code:

  1. Default-Deny. Das Autorisierungs-Framework so bauen, dass ein Endpoint ohne explizite Regel abgelehnt wird, nicht akzeptiert. Das Gegenteil (Default-Allow) bedeutet, dass jeder neue Endpoint kaputt ist, bis jemand daran denkt, ihn abzuriegeln.
  2. Prüfung zentralisieren. Ein einziger Helper (requireAuth() / requirePermission(role, resource)), den jeder Endpoint nutzt, ist prüfbar. Per-Endpoint-Handarbeit ist es nicht.
  3. Grenze testen. Ein Integrations-Test, der jeden geschützten Endpoint ohne Session aufruft und ein “unauthorisiert” erwartet. Als automatisierten Test ausführen.
  4. Bei Multi-Tenant-Daten Tenant-ID auf Framework-Ebene in jede Query parametrisieren (Rails acts_as_tenant, Django django-multitenant, in der Repository-Schicht hartkodiertes WHERE tenant_id = ?). Macht IDOR-anfällige Queries strukturell schwer zu schreiben.

Eingesetzte Drittanbieter-Software:

  1. Zügig patchen. Auth-Bypass-CVEs ziehen Exploit-Aufmerksamkeit innerhalb von Stunden.
  2. Admin-Panels und Management-Oberflächen nicht ins Internet stellen. Hinter VPN oder IP-Allowlist halten.
  3. Default-Credentials beim Deployment ändern und im Runbook dokumentieren, damit nicht der nächste Operator die Änderung rückgängig macht.

Wie blueredix Auth-Bypass-Befunde meldet

Der Scanner meldet:

  • CVEs in Drittanbieter-Software, deren Beschreibung Auth-Bypass / Authentication-Bypass / unauth-RCE nennt.
  • Default-Credentials und exponierte Admin-Panels über die kuratierten Templates.
  • Cookie-Attribut-Befunde (cookie-missing-secure, cookie-missing-httponly, cookie-missing-samesite): Cookie-Hygiene, die Session-Diebstahl bei Folgefehlern erleichtert.

Wir testen keine Credentials aktiv gegen Ihre Anwendung. Das wäre autorisiertes Pentest-Territorium.

Mehr dazu