Skip to content

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

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

Manche Webanwendungen erzeugen bei der Registrierung vorhersagbare Benutzernamen und/oder Passwörter. Wie es damit bei den Weboberflächen der IoT-Geräte aussieht weiß ich zur Zeit gar nicht. Möglich wäre so ein Fehler aber durchaus, immerhin sieht es ja so aus, als gäben sich die Entwickler der IoT-Weboberflächen jede Mühe, uralte Web-Fehler und -Schwachstellen wiederaufleben zu lassen. Weshalb ich hier auch darauf eingehe.

Während die Gefahr eines vorhersagbaren Passworts offensichtlich ist, ist ein vorhersagbarer Benutzername zumindest auf den ersten Blick nicht gefährlich. Aber das ist zumindest zum Teil ein Irrtum.

Wenn die Benutzer ihren Benutzernamen nicht selbst auswählen können, weil sie von der Webanwendung vorgegeben werden, könnten sie z.B. nach dem Muster

user[laufende Nummer]

oder

[fester Suffix][Initialen des Benutzers][laufende Nummer]

oder ähnlich erzeugen. Ein Angreifer, der den Aufbau der Benutzernamen kennt, kann dann eine Liste mit sehr hoher Wahrscheinlichkeit gültiger Benutzernamen erstellen, die er für weitere Angriffe, z.B. einen Brute-Force-Angriff auf das Authentifizierungssystem oder als Teil eines Social-Engineering-Angriffs, nutzen kann. Anders als bei den zuvor beschriebenen Methoden zum Ermitteln gültiger Benutzernamen ist in diesem Fall gar keine oder nur eine minimale Interaktion mit der Webanwendung nötig, dieser Teil des Angriffs kann also nicht bemerkt werden. Die Folgen wie z.B. Brute-Force-Angriffe auf erratene Benutzernamen sowie Social-Engineering-Angriffe fallen dann aber wieder auf.

Vorhersagbare Passwörter

Vergibt die Webanwendung bzw. das IoT-Gerät die Passwörter nach der Registrierung selbst, dürfen sie nicht vorhersagbar sein. Sonst könnte ein Angreifer über ein erratenes und noch nicht vom Benutzer geändertes Passwort Zugriff auf ein fremdes Benutzerkonto erlangen.

Manchmal reicht es aus, eine kleine Anzahl vergebener Passwörter zu kennen, um daraus auf andere Passwörter zu schließen, z.B. weil sie eine immer gleiche, fest vorgegebene Zeichenkette mit einer weiteren, vorhersagbaren oder zumindest auf einen kleinen Wertebereich eingrenzbaren Zeichenkette verbinden.

Bei IoT-Geräte gibt es generell das schon erwähnte Problem der Default-Zugangsdaten, von denen die vorhersagbaren Passwörter im Grunde eine Untergruppe sind. Wenn z.B. bei WLAN Access Points das Default-WPA-Passwort auf Basis der über WLAN abfragbaren MAC-Adresse gebildet wird, dann ist das sozusagen ein "vorhersagbares Default-Passwort". Das gleiche gilt für WPS-PINs, ....

Sichere Startpasswörter

Wird das Passwort von der Anwendung erzeugt, muss es die gleichen Anforderungen erfüllen wie ein vom Benutzer gewähltes. Insbesondere darf es also in keinem Wörterbuch stehen oder erratbar, d.h. aus bekannten Passwörtern ableitbar, sein. Darf der Benutzer das Passwort ändern, ist es empfehlenswert, dieses "Startpasswort" nach dem ersten Login zwangsweise durch ein vom Benutzer selbst gewähltes Passwort ersetzen zu lassen, das dann natürlich auch den Ansprüchen an ein sicheres Passwort genügen muss.

Warum sollte man erst ein Passwort vorgeben, wenn der Benutzer das dann doch ändern darf? Nun, z.B. um bei der Registrierung als zusätzlichen Schritt die Daten des Benutzers zumindest teilweise zu prüfen, z.B. indem das Passwort an die angegebene E-Mail-Adresse gemailt oder an die Postanschrift verschickt wird. Im Fall von IoT-Geräten wird dieser Fall zwar nur selten vorkommen, denkbar ist er aber. Vor allem, wenn das Gerät nur dann wirklich nutzbar ist, wenn es über einen Server des Anbieters konfiguriert wird und der sicher gehen will, dass sich wirklich nur ein befugter Benutzer registrieren kann.

Diese Übertragung der Zugangsdaten an den Benutzer muss ebenfalls sicher erfolgen, und genau darum geht es auch in der nächsten Folge.

Carsten Eilers

Trackbacks

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

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!