Skip to content

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.

Carsten Eilers

Trackbacks

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

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 13

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 14

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 15

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 16

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

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!