Skip to content

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

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 muss sicher sein

Webanwendungen und auch die Weboberflächen des IoT benötigen eine Funktion, mit der ein vergessenes Passwort zurück gesetzt werden kann bzw. mit der ein neues Passwort angefordert werden kann. Denn wenn der Benutzer sein Passwort vergisst, ist er sonst von der Webanwendung bzw. IoT-Oberfläche ausgesperrt. Und während es bei Webanwendungen i.A. noch einen Betreiber und damit Administrator gibt, an den der Benutzer sich notfalls wenden kann, bliebe ihm beim IoT-Gerät ohne eine solche Funktion im Notfall nur noch die Möglichkeit, das Gerät in den Auslieferungszustand zurück zu setzen und damit sämtliche Einstellungen und womöglich auch gesammelten Daten zu löschen. Denn der Administrator ist er ja i.A. selbst.

Auch ein vergessenes Passwort ist ein Passwort!

Funktionen, mit denen eine vergessenes Passwort zurück gesetzt oder ein neues Passwort angefordert werden kann, enthalten oft die Schwachstellen, die bei der Anmeldefunktion umgangen wurden: Möglichkeiten zum Ermitteln gültiger Benutzernamen und für Brute-Force-Angriffe. Da diese Funktion notwendigerweise ohne vorherige Authentifizierung erreichbar sein muss, fordert sie Angriffe darauf geradezu heraus. Daher dürfen Fehlermeldungen keinen Hinweis darauf geben, ob der eingegebene Benutzername gültig ist oder nicht, und sie darf auch nicht für einen Benutzernamen beliebig oft ausgeführt werden können.

Ein zusätzliches Problem sind Designschwachstellen, die einem Angreifer in die Hände spielen, indem sie die Nutzung der Funktion durch Unbefugte ermöglichen oder erleichtern.

Designfehler 1: Unsichere Sicherheitsfragen

Die "Vergessenes Passwort"-Funktion enthält i.A. eine Möglichkeit, den Benutzer auch ohne das Passwort zu identifizieren, meist mit einem Challenge-Response-Verfahren: Die Webanwendung fragt den Benutzer etwas, und der muss durch die richtige Antwort seine Identität beweisen. Am beliebtesten sind dabei vorgegebene Sicherheitsfragen, die manchmal auch "Geheime Fragen" genannt werden, obwohl sie gar nicht geheim sind. Was geheim sein sollte, sind dagegen die Antworten, die der Benutzer darauf gibt.

Fest vorgegebene Sicherheitsfragen sind ein großes Risiko, da die Antwort darauf meist leichter zu erraten ist als ein gutes Passwort. Man hat nun mal nur eine Mutter, deren Mädchennamen man angeben kann, nur ein erstes Haustier, nur einen Geburtsort, ... - und meist lassen sich die Antworten auf diese Fragen durch Social Engineering oder noch einfacher das Auswerten von Social Networks ermitteln. Lieblingsbuch, -autor, -film, -schauspieler oder -sänger? Ein Blick in Facebook und Co. genügt oft, um die Frage richtig beantworten zu können.

Auch wenn die Sicherheitsfrage vom Benutzer gewählt werden kann, wird sie dadurch meist nicht besser. Denn die Benutzer tendieren dazu, dann besonders einfache Fragen zu verwenden, wie "Wie heiße ich?" oder "Wann bin ich geboren?". Viele Benutzer denken sich nichts dabei, weil sie annehmen, das sie die einzigen sind, die diese geheime Frage jemals zu sehen bekommen. Das ist aber ein Irrtum: Ein Angreifer kann einen Brute-Force-Angriff auf die "Vergessenes Passwort" starten, indem er ermittelte oder übliche Benutzernamen ausprobiert und dann die auswählt, bei denen eine einfach zu ratende Sicherheitsfrage erscheint.

Designfehler 2: Passwort-Hinweise

Manche Anwendungen implementieren die "Vergessenes Passwort"-Funktion, indem sie einem vom Benutzer während der Registrierung bzw. bei der Änderung des Passworts zu setzenden Hinweis auf das Passwort ausgeben. Selbst wenn die Anwendung dabei verhindert, das der Hinweis einfach aus dem Passwort besteht, bleiben genug Möglichkeiten, einem Angreifer dadurch das Passwort zu verraten oder zumindest das Erraten zu erleichtern. Auch hierbei denken viele Benutzer, dass sie die einzigen sind, die diesen Hinweis zu sehen bekommen.

Leider lässt sich dieses Problem technisch kaum lösen, aber als Benutzer können Sie darauf achten, es einem Angreifer nicht zu leicht zu machen. Verwenden Sie also einen Hinweis, mit dem Sie selbst zwar etwas anfangen können, nicht aber ein Angreifer. Wie der aussehen kann? Das kann ich Ihnen leider auch nicht verraten, ich weiß ja nicht, wie ihr Passwort aussieht.

Ich verwende schon seit langem keine einfachen Passwörter mehr, sondern bilde sie aus mehr oder weniger langen Sätzen. Daher reicht mir als Hinweis i.A. ein Stichwort.

In der nächsten Folge geht es um weitere mögliche Angriffe auf und über die Authentifizierung, zunächst um die Recovery-Funktion, über die der Benutzer nach seiner Identifikation ein neues Passwort bekommt.

Carsten Eilers

Trackbacks

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

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 10

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 11

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 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

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!