Skip to content

Die IoT Top 10, #2: Unsichere Authentifizierung/Autorisierung, Teil 16

Weiter geht es mit der Beschreibung der gefährlichsten Schwachstellen in den Geräten des IoT gemäß den Top IoT Vulnerabilities von OWASP. Zur Zeit sind wir beim Punkt 2: "Insufficient Authentication/Authorization".

Die verschiedenen Möglichkeiten zur Authentifizierung habe ich bereits beschrieben. Ebenso erste Angriffe: Default-Zugangsdaten und schlechte (= unsichere) Passwörter sowie Brute-Force- und Wörterbuch-Angriffe, die durch verräterische Fehlermeldungen erleichtert werden können. Ein weiteres Problem sind ungeschützt übertragene Zugangsdaten und die unsichere Verwendung von HTTPS. Aber auch Funktionen rund um die Passwortverwaltung können zu einer Schwachstelle werden, z.B. unsicher gespeicherte Passwörter. Auch nicht ungefährlich ist die Funktion zur Passwortänderung. Und auch der Passwort-Reset oder eine unsichere "Recovery"-, "Remember me"- oder "User Impersonation"-Funktion können zur Gefahr werden. Genauso wie eine fehlerhafte Passwortprüfung oder nicht eindeutige Benutzernamen. Die können auch entstehen, wenn es Missverständnisse gibt. Ein weiteres Problem sind vorhersagbare Benutzernamen und Passwörter. Aber selbst die sichersten Zugangsdaten sind gefährdet, wenn es keine sichere Datenübertragung gibt.

Neben all diesen möglichen Schwachstellen und Angriffen gilt es dann nur noch, einige typische

Implementierungs- und Logikfehler

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

Trackbacks

Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #2: Unsichere Authentifizierung/Autorisierung, Teil 17

Vorschau anzeigen
Weiter geht es mit der Beschreibung der gefährlichsten Schwachstellen in den Geräten des IoT gemäß den Top IoT Vulnerabilities von OWASP. Zur Zeit sind wir beim Punkt 2: "Insufficient Authentication/Authorization". Die ve

Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #2: Unsichere Authentifizierung/Autorisierung, Teil 18

Vorschau anzeigen
Weiter geht es mit der Beschreibung der gefährlichsten Schwachstellen in den Geräten des IoT gemäß den Top IoT Vulnerabilities von OWASP. Zur Zeit sind wir beim Punkt 2: "Insufficient Authentication/Authorization". Die ve

Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #6: Unsichere Cloud-Interfaces

Vorschau anzeigen
Bei der Beschreibung der gefährlichsten Schwachstellen in den Geräten des IoT gemäß den Top IoT Vulnerabilities von OWASP sind wir bei Punkt 6 angekommen: "Insecure Cloud Interface". Oder auf deutsch: Unsichere Cloud-Int

Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #7: Mobile Cloud-Interfaces

Vorschau anzeigen
Bei der Beschreibung der gefährlichsten Schwachstellen in den Geräten des IoT gemäß den Top IoT Vulnerabilities von OWASP sind wir bei Punkt 7 angekommen: "Insecure Mobile Interface". Oder auf deutsch: Unsichere Mobile-I

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

Noch keine Kommentare

Kommentar schreiben

Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
BBCode-Formatierung erlaubt
Formular-Optionen

Kommentare werden erst nach redaktioneller Prüfung freigeschaltet!