Skip to content

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

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

Fehlerhafte Passwortprüfungen

Schwachstellen im Bereich der Authentifizierung müssen nicht automatisch sofort dazu führen, dass ein Angreifer sich ohne Zugangsdaten zu kennen, anmelden kann. Viele Schwachstellen erleichtern "nur" andere Angriffe, sollten aber trotzdem nicht auf die leichte Schulter genommen werden. Wie z.B. die unvollständige Prüfung der Zugangsdaten.

Gute Passwörter

Gute Passwörter sind möglichst lang (oft werden mindestens 8 Zeichengefordert), bestehen aus Gross- und Kleinbuchstaben, Ziffern und Sonderzeichen und sind keine Wörter. So oder so ähnlich beschreiben viele Webanwendungen die Anforderungen an ein Passwort.

Schlechte Passwörter

Die Veröffentlichung der Anforderungen an ein gutes Passwort ist nur die halbe Miete: Sie müssen auch umgesetzt, d.h. geprüft, werden. Und daran scheitern viele Webanwendungen. Was noch nicht besonders schlimm ist, wenn die Benutzer sich selbst daran halten.

Manche Webanwendungen gehen aber weiter und schwächen die Passwörter, z.B. indem sie nur die ersten n Zeichen des Passworts prüfen oder die Eingabe Case-insensitiv prüfen, d.h. für die Prüfung alle Zeichen in Groß- oder Kleinbuchstaben umwandeln. Manche Anwendungen löschen auch die Sonderzeichen, z.B. um Probleme durch evtl. unterschiedliche Kodierungen zu vermeiden. Alle diese Maßnahmen schwächen die Passwörter, da sie die Menge möglicher Passwörter teilweise drastisch reduzieren.

Wenn statt 10 Gross- und Kleinbuchstaben, Ziffern und Sonderzeichen nach der Umwandlung nur 8 Buchstaben geprüft werden, schränkt das den bei einem Brute-Force-Angriff zu prüfenden Bereich stark ein. Die Wahrscheinlichkeit, ein gültiges Passwort zu ermitteln, steig also stark an. Vor allem, wenn Benutzer ihr Passwort aus einem normalen Wort gebildet haben, in das sie Zahlen und Sonderzeichen eingefügt haben. Vielleicht hat der Benutzer sein Passwort aus den Wörtern 'sicheres' und 'Paßwort' und seinem Geburtsdatum gebildet:

si1ch0er1es1Pa1ß9wo7rt7

ist ein auf den ersten Blick ganz gutes Passwort, es enthält Groß- und Kleinbuchstaben, mit dem ß ein Sonderzeichen und Ziffern. Wenn die Webanwendung nun aber die Zahlen und das Sonderzeichen streicht, bleibt nur

sicheresPawort

Wenn davon dann nur die ersten 8 Zeichen geprüft werden, ergibt das

sicheres

Das ist zwar nicht unbedingt ein typisches Passwort, aber doch ein Wort aus einem Wörterbuch. Ist es nun auch noch egal, ob es gross, klein oder gemischt geschrieben wird, wird es bei einem Brute-Force-Angriff eher früher als später gefunden.

Nicht eindeutige Benutzernamen

Eine weitere mögliche Schwachstelle sind nicht eindeutige Benutzernamen. Kann der Benutzer den Benutzernamen bei der Registrierung selbst wählen, muss die Anwendung darauf achten, das ein vorhandener Benutzername nicht erneut verwendet wird. Ansonsten kann es zu unerwarteten Verhalten der Webanwendung sowie evtl. einer Angriffsmöglichkeit kommen.

Dazu ein Beispiel: Der Default-Benutzername für den Administrator der Anwendung sei admin. Benutzernamen sind Case-insensitiv und werden beim Login auch so behandelt, die Prüfung auf bereits vergebene Benutzernamen erfolgt aber durch einen Fehler Case-sensitiv. Was passiert, wenn ein Benutzer sich mit den Benutzernamen Admin registriert?
Je nachdem, wie die Passwortprüfung implementiert ist, kann das beim Login zu unterschiedlichen Reaktionen führen: Admin kann sich mit seinem Passwort als admin anmelden, der Administrator admin landet im Benutzerkontext des normalen Benutzers Admin, keinem von beiden ist eine Anmeldung möglich, oder es passiert etwas ganz anderes.

Außer dem Fall der absichtlich oder auf Grund eines Programmierfehlers nicht durchgeführten Prüfung können "Missverständnisse" dazu führen, das Benutzernamen doppelt vergeben werden. Darum geht es in der nächsten Folge.

Carsten Eilers

Trackbacks

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!