Auch ein gut entworfenes, theoretisch absolut sicheres Authentifizierungssystem kann durch Implementierungsfehler unsicher werden. Das können z.B. Informationslecks sein, eine Möglichkeit zum direkten Umgehen des Authentifizierungssystems oder eine allgemeine Schwächung des Systems.

Implementierungsfehler sind schwieriger zu finden als Designfehler wie ein fehlender Schutz vor Brute-Force-Angriffen oder unsichere Regeln für Passwörter. Daher ist eine allgemeine Beschreibung schwierig, die folgenden Hinweise sind also noch allgemeiner als das sonst schon der Fall ist.

Fehler in mehrstufigen Systemen

Manche Webanwendungen verwenden ein mehrstufiges Authentifizierungssystem, bei dem nach der Eingabe von Benutzername und Passwort eine Challenge, z.B. die Auswahl eines bestimmten Bilds oder die Beantwortung einer Sicherheitsfrage, bestanden und/oder ein von einem Security-Token gelieferter Wert eingegeben werden muss. Diese Systeme sollen sicherer sein als eine einfache Benutzername-Passwort-Kombination, indem sich der Benutzer erst durch Benutzername und Passort identifiziert und die Webanwendung ihn danach durch weitere Schritte authentifiziert. Dabei können insbesondere Logikfehler dazu führen, dass das Gesamtsystem am Ende unsicherer ist, als es die Abfrage von Benutzername und Passwort allein wäre.

Die Implementierung könnte z.B. in jedem Schritt falsche Annahmen über die Interaktion des Benutzers mit vorhergehenden Schritten machen:

• Die Anwendung könnte in Schritt 2 Daten vertrauen, weil sie bereits in Schritt 1 überprüft wurden. Ein Angreifer könnte diese Daten vor dem Aufruf von Schritt 2 manipuliert und damit z.B. verschiedene Flags geändert haben, die z.B. seinen Status (Benutzer/Administrator) oder die weiteren zu absolvierenden Schritte festlegen. Dadurch könnte der Zugriff mit unvollständigen Zugangsdaten und/oder höheren Privilegien möglich sein.
• Die Anwendung könnte annehmen, dass ein Benutzer, der Schritt 3 aufruft, zuvor die Schritte 1 und 2 erfolgreich absolviert hat. Dadurch könnte ein Angreifer authentifiziert werden, der von Schritt 1 direkt zu Schritt 3 gesprungen ist. Ein Angreifer müsste also nur die für Schritt 1 und Schritt 3 notwendigen Zugangsdaten kennen, nicht aber die für Schritt 2.
• Die Anwendung könnte annehmen, dass in jedem Schritt die gleiche Benutzeridentität geprüft wird, ohne dies explizit zu prüfen. Z.B. könnte Schritt 1 einen gültigen Benutzername und das zugehörige Passwort prüfen, während Schritt 2 den Wert eines Security-Tokens prüft und dazu den Benutzernamen in einem versteckten Formularfeld überträgt. Ein Angreifer könnte dann mit Benutzername und Passwort eines Benutzers und Benutzername und Token eines anderen Benutzers die Authentifizierung erfolgreich durchlaufen (wobei egal sein soll, welche Benutzeridentität dann angenommen wird). Was auf den ersten Blick nicht schlimm ist, denn der Angreifer muss sich immer noch Benutzername und Passwort bzw. Token verschaffen, nur eben von 2 Benutzern. Was ist aber, wenn der Angreifer selbst ein Benutzer ist? Ein Benutzer, der ein fremdes Token besitzt, könnte sich dann mit seinem Benutzernamen und Passwort sowie dem fremden Benutzernamen und Token anmelden und evtl. auf das fremde Konto zugreifen. Oder ein Benutzer, der das Passwort eines anderen Benutzers kennt, könnte sich mit Hilfe seines eigenen Tokens Zugang zum Benutzerkonto des anderen Benutzers verschaffen.

Fehler suchen

Zuerst wird die Authentifizierung für ein Benutzerkonto unter der Kontrolle des Testers einmal vollständig durchlaufen, wobei alle übertragenen Daten protokolliert werden.

Danach werden die in den einzelnen Schritte verwendeten und übertragene Daten untersucht. Werden bestimmte Daten in mehreren Schritten abgefragt oder an die Webanwendung gesendet? Für letzteres kommen wie üblich Cookies, versteckte Formularfelder oder gesetzte URL-Parameter in Frage.

Danach werden die verschiedenen Schritte der Authentifizierung mit präparierten Requests aufgerufen, indem z.B. die Reihenfolge geändert wird, ein bestimmter Schritt direkt aufgerufen oder aber ausgelassen wird, oder nach anderen Möglichkeiten zur Manipulation gesucht wird.

Werden Daten mehrmals übertragen, wird geprüft, was passiert, wenn in verschiedenen Schritten unterschiedliche Werte übertragen werden. Werden die Daten in jedem Schritt geprüft, oder gibt es Schritte, die sie ungeprüft verwenden? Können diese Schritte durch andere Werte manipuliert werden? Was passiert, wenn der erste Schritt mit einem Benutzernamen erfolgreich durchlaufen wurde und der zweite Schritt mit einem anderen Benutzernamen?

Werden zwischen Client und Webanwendung Daten ausgetauscht, die nicht vom Benutzer eingegeben wurden? Diese könnten Statusinformationen enthalten, deren Manipulation Auswirkungen auf den Authentifizierungsprozess hat. Z.B. könnte ein Parameter die zuletzt erfolgreich durchlaufene Stufe speichern, und durch eine Manipulation des Parameters können Stufen übersprungen werden.

In der nächsten Folge geht es um weitere Implementierungsfehler in mehrstufigen Authentifizierungssystemen.

Carsten Eilers

About Security - Übersicht zum aktuellen Thema:

• About Security #214: Schwachstellen-Suche: Authentifizierung - Grundlagen
• About Security #215: Schwachstellen-Suche: Authentifizierung - Brute Force
• About Security #216: Schwachstellen-Suche: Authentifizierung - Namen finden
• About Security #217: Schwachstellen-Suche: Authentifizierung - Ein Angriff
• About Security #218: Schwachstellen-Suche: Authentifizierung - Die Übertragung
• About Security #219: Schwachstellen-Suche: Authentifizierung - Verschlüsselung
• About Security #220: Schwachstellen-Suche: Authentifizierung - Unsichere Kryptographie
• About Security #221: Schwachstellen-Suche: Authentifizierung - Passwort ändern
• About Security #222: Schwachstellen-Suche: Authentifizierung - Passwort-Reset
• About Security #223: Schwachstellen-Suche: Authentifizierung - Passwort-Reset (2)
• About Security #224: Schwachstellen-Suche: Authentifizierung - "Remember me"
• About Security #225: Schwachstellen-Suche: Authentifizierung - "User Impersonation"
• About Security #226: Schwachstellen-Suche: Authentifizierung - "Halbe Passwörter"
• About Security #227: Schwachstellen-Suche: Authentifizierung - "Doppelte Benutzer"
• About Security #228: Schwachstellen-Suche: Authentifizierung - Vorhersagbares
• About Security #229: Schwachstellen-Suche: Authentifizierung - Daten übertragen
• About Security #230: Schwachstellen-Suche: Authentifizierung - Implementierungsfehler