Dipl.-Inform. Carsten Eilers

zu vermeiden. Denn 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.

Manche Webanwendungen verwenden ein mehrstufiges Authentifizierungssystem, bei dem nach der Eingabe von Benutzername und Passwort eine Challenge bestanden werden muss, z.B. die Auswahl eines bestimmten Bilds oder die Beantwortung einer Sicherheitsfrage, oder ein von einem Security-Token oder einer App erzeugter oder per SMS vom Server gelieferter Wert eingegeben werden muss (die klassische 2-Faktor-Authentifizierung, oft wird auch die Eingabe des Passworts durch die Eingabe des Werts ersetzt).

Diese Systeme sollen eigentlich sicherer sein als eine einfache Benutzername-Passwort-Kombination, da sich der Benutzer erst durch Benutzername und Passort identifiziert und die Webanwendung ihn danach durch weitere Schritte authentifiziert. Im Fall der 2-Faktor-Authentifizierung kommt hinzu, dass der 2. Faktor nicht ausgespäht wird, sondern an den Besitz des Security-Token, Smartphone mit App oder Mobiltelefons gebunden ist. Fehler, insbesondere Logikfehler, können aber dazu führen, dass das Gesamtsystem am Ende unsicherer ist, als es die Abfrage von Benutzername und Passwort allein wäre.

Im Fall von IoT-Geräten werden solche Probleme sehr wahrscheinlich nur bei der Kommunikation mit einem zentralen Server auftreten, da Weboberflächen der Geräte i.A. nur durch Benutzername und Passwort geschützt sind. Aber gerade ein Angriff auf den zentralen Server kann besonders verheerend sein. Nehmen wir mal an, ihre Heizung könnte über das Web oder über eine App gesteuert werden, wobei der Zugriff über einen Server des Heizungsherstellers erfolgt. Gibt es dabei einen Fehler in der Authentifizierung, könnte ein Angreifer ihrer Heizung z.B. ausschalten oder auf "volle Pulle" stellen. Stellen Sie sich nur mal vor, das passiert, während Sie im Winterurlaub sind. Nicht nur, dass sie dann nach dem Urlaub in ein völlig ausgekühltes oder total überheiztes Zuhause kommen, zusätzlich wären sehr wahrscheinlich auch noch Wasserleitungen eingefroren bzw. enorme Heizkosten entstanden.

Die Implementierung könnte z.B. in einem oder auch mehreren Schritten falsche Annahmen über die Interaktion des Benutzers mit vorhergehenden Schritten machen. Da es ziemlich viele Möglichkeiten gibt, so etwas zu implementieren, führe ich hier nur einige Möglichkeiten auf:

1. Traue nie dem Client!

Die Anwendung könnte im zweiten Schritt Daten vertrauen, weil sie bereits im ersten Schritt überprüft wurden. Das darf aber nur passieren, wenn die Daten nach dem 1. Schritt nicht erneut an den Client und von diesen dann zurück an den Server geschickt werden (egal ob im URL oder in (evtl. auch versteckten) Formularfeldern). Denn sonst könnte ein Angreifer sie vor dem Aufruf des 2. Schritts manipulieren.

Werden z.B. Flags verwendet, um den Status (Benutzer/Administrator) oder die weiteren zu absolvierenden Schritte festzulegen, könnte der Angreifer sich über deren Manipulation höhere Benutzerrechte verschaffen oder sich durch das Überspringen von eigentlich nötigen Schritten mit unvollständigen Zugangsdaten anmelden.

2. Die Reihenfolge der Schritte muss geprüft werden!

Die Anwendung könnte annehmen, das ein Benutzer, der einen Schritt aufruft, zuvor die Schritte davor erfolgreich absolviert hat. Dann könnte ein Angreifer authentifiziert werden, der z.B. von Schritt 1 direkt zu Schritt 3 springt oder auch den letzten Schritt sofort direkt aufruft. Wenn das korrekte Durchlaufen mehrere Schritte nötig ist, muss in jeden Schritt geprüft werden, ob die vorherigen Schritte korrekt durchlaufen wurden.

In der nächsten Folge werden noch einige weitere Implementierungs- und Logikfehler vorgestellt.

Carsten Eilers