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