Die IoT Top 10, #2: Unsichere Authentifizierung/Autorisierung, Teil 11
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-" oder "Remember me"-Funktion können zur Gefahr werden. Genauso wie eine
Unsichere "User Impersonation"
Manche Webanwendungen stellen privilegierten Benutzern eine "User Impersonation"-Funktion zur Verfügung, mit der sie die Identität eines anderen Benutzers annehmen können, um dann Aktionen in dessen Benutzerkontext auszuführen. Das kann z.B beim Nachvollziehen der Benutzeraktionen durch den Helpdesk oder bei der Untersuchung aufgetretener Probleme durch den Administrator hilfreich sein. Es kann aber, wenn die Funktion ungeschickt implementiert ist oder Schwachstellen enthält, auch einem Angreifer nützen.
So eine Funktion wird es in IoT-Weboberflächen eher selten geben, ich möchte sie aber der Vollständigkeit halber nicht unerwähnt lassen.
Designfehler und -schwachstellen
Für die "User Impersonation"-Funktion ebenso wie für viele andere eigentlich nur privilegierten Benutzern zugängliche Funktionen gibt es eine Reihe typischer Designfehler und Schwachstellen, die einem Angreifer in die Hände spielen.
Verstecken ist kein Schutz
Oft werden solche Funktionen nur versteckt, statt sie mit einer richtigen
Zugriffskontrolle vor unbefugten Zugriffen zu schützen. Z.B.
könnte der Zugriff auf /admin/admin.php
mit einem
Passwortschutz versehen sein, auf den sich die davon aufgerufenen Skripte
wie /admin/userimpersonate.php
verlassen. Jeder, der den Pfad
zum Skript und dessen Namen kennt oder errät, kann es dann direkt
aufrufen und dadurch die Identität eines anderen Benutzers annehmen.
Das gleich gilt dann natürlich auch für alle anderen Funktionen
des Administrationsbereichs, die von separaten Skripten bereit gestellt
werden, wie z.B. Passwortänderungen, das Anlegen neuer Benutzer,
Datenbankbackups usw. usf. Der schlimmste Fall ist dann eine Funktion,
die das Heraufladen von Skripten oder Programmen oder die Änderung von
Skripten erlaubt, so dass ein Angreifer darüber eigenen Code
einschleusen kann.
Immer dran denken: Traue nie dem Client!
Manche Webanwendungen vertrauen vom Benutzer manipulierbaren Daten, wenn sie prüfen, ob ein Benutzer die "User Impersonation"-Funktion nutzen darf und welche Benutzeridentität er aktuell hat. Das kann z.B. zusätzlich zu einem gültigen Session-Token ein Cookie sein, der bestimmt, mit welchem Benutzerkonto die Session genutzt wird. Ein Angreifer, der ein Benutzerkonto kontrolliert und dadurch nach der Authentifizierung ein gültiges Session-Token besitzt, kann das ausnutzen, und durch Setzen dieses Cookies auf andere Benutzerkonten zuzugreifen.
Ein zusätzliches geheimes Passwort ist auch keine Lösung
Die "User Impersonation"-Funktion könnte auch durch ein spezielles Passwort realisiert werden, über das sich ein privilegierter Benutzer (dessen Privilegien womöglich nur dadurch bewiesen werden, das er das Passwort kennt) über die normale Authentifizierungsfunktion mit jedem beliebigen Benutzernamen anmelden kann.
Dass das ein sehr unsicherer Lösungsansatz ist, dürfte klar sein. Gelangt ein Angreifer an dieses Passwort, hat er danach Zugriff auf jedes beliebige Benutzerkonto. Unter Umständen gelingt das schon bei einem einfachen Brute-Force-Angriff. Dazu muss nur bei 2 Benutzerkonten dieses "Generalschlüssel-Passwort" vor dem eigentlichen Passwort ausprobiert werden, so dass der Angreifer mit dem gleichen Passwort auf zwei verschiedene Konten zugreifen kann.
Das könnte zwar Zufall sein, aber so etwas wird einen Angreifer immer neugierig machen, und schon nach kurzer Zeit wird er feststellen, dass das gefundene Passwort bei jedem Benutzerkonto funktioniert. Noch verdächtiger ist ein Benutzerkonto, auf das mit zwei Passwörtern zugegriffen werden kann. Sofern der Angreifer den Brute-Force-Angriff nicht nach dem ersten gefundenen Passwort abbricht (was allerdings meistens der Fall ist, da das Ziel ja erreicht wurde), wird ihn ein Konto mit zwei Passwörtern stutzig machen und dadurch das "Generalschlüssel-Passwort" verraten.
Vielleicht ist auch eine Privilegieneskalation möglich?
Wenn privilegierte Benutzer die Identität anderer Benutzer annehmen können, könnte eine Schwachstelle in der "User Impersonation"-Funktion dazu führen, das normale Benutzer die Identität eines privilegierten Benutzers annehmen und dadurch die Kontrolle über die Webanwendung erlangen können. Im Fall der Erkennung des Benutzerkontos anhand eines Cookies könnte es z.B. möglich sein, durch das Setzen des Cookies auf den Benutzernamen eines privilegierten Benutzers, z.B. admin, Zugriff auf dessen Konto zu erlangen.
Auch in der nächsten Folge geht es weiter um Schwachstellen in der Authentifizierung und Autorisierung, und zwar um ungenügende Passwortprüfungen.
Trackbacks
Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #2: Unsichere Authentifizierung/Autorisierung, Teil 12
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #2: Unsichere Authentifizierung/Autorisierung, Teil 13
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #2: Unsichere Authentifizierung/Autorisierung, Teil 14
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #2: Unsichere Authentifizierung/Autorisierung, Teil 15
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #2: Unsichere Authentifizierung/Autorisierung, Teil 16
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #2: Unsichere Authentifizierung/Autorisierung, Teil 17
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #2: Unsichere Authentifizierung/Autorisierung, Teil 18
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #6: Unsichere Cloud-Interfaces
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #7: Mobile Cloud-Interfaces
Vorschau anzeigen