Die IoT Top 10, #2: Unsichere Authentifizierung/Autorisierung, Teil 13
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.
NULL oder Nichts?
Ein Problem bei Webanwendungen, die auf verschiedenen Betriebssystemen laufen und/oder verschiedene Technologien verwenden, ist die Behandlung von Sonderzeichen, in diesem Fall insbesondere des NULL-Bytes. Das betrifft die Weboberflächen der IoT-Geräte selbst zwar i.A. nicht, aber auch die arbeiten ja oft mit Servern zusammen. Und dann kann dieses Problem durchaus akut werden.
Das NULL-Byte kann das Ende eines Strings kennzeichnen, ignoriert oder als normales Zeichen betrachtet werden. Solange sich alle Beteiligten in der Interpretation einig sind, ist das kein Problem. Wird das NULL-Byte aber von beteiligten Komponenten unterschiedlich interpretiert, wird es ein Problem und oft sogar eine Schwachstelle.
Exkurs: NULL-Byte-Schwachstelle in SSL-Implementierungen
Eine entsprechende Schwachstelle wurde 2009 von Moxie Marlinspike in
verschiedenen SSL-Implementierungen entdeckt und auf der
Sicherheitskonferenz "Black Hat DC"
vorgestellt:
Ein NULL-Byte im Namensfeld (CN, Common Name) des SSL-Zertifikats
führte in manchen Implementierungen dazu, das alles folgende ignoriert
wird. Beantragte ein Krimineller, dem die Domain
boeser-server.example
gehört, z.B. ein Zertifikat
für
www.bank.example\00.boeser-server.example
prüfen die Zertifizierungsstellen i.A. nur die im Common Name
eingetragene Domain, ignorieren die Subdomain und stellen das Zertifikat
aus. Von der Schwachstelle betroffene SSL-Implementierungen dagegen
prüfen den Common Name nur bis zum ersten NULL-Byte, erkennen daher
ein gültiges Zertifikat für www.bank.example
und ermöglichen dadurch z.B. Phishing und
Man-in-the-Middle-Angriffe.
Das ist zwar lange her, und die SSL-Implementierungen wurden damals natürlich auch so angepasst, dass der Angriff nicht mehr möglich ist, es ist aber nach wie vor ein ideales Beispiel, um die Gefahr dieses kleinen Missverständnisses zu demonstrieren.
Ende des Exkurs
Ähnliches könnte auch einer Webanwendung passieren, wenn z.B. die Registrierung der neuen Benutzernamen und deren spätere Verwendung auf unterschiedlichen Systemen erfolgen, so dass sich Namen bei der Prüfung unterscheiden, bei der späteren Verarbeitung aber übereinstimmen.
Mögliche Angriffe
Ob und was für Angriffe möglich sind, ist von mehreren Faktoren abhängig:
- Wie reagiert die Webanwendung beim Login,
- wie auf eine Registrierung mit einer bereits vorhandenen Benutzername-Passwort-Kombination,
- wie auf eine Passwortänderung, die zu einer bereits vorhandenen Benutzername-Passwort-Kombination führt?
Ein Angreifer könnte sich z.B. so lange mit einem bereits vergebenen Benutzernamen und unterschiedlichen Passwörtern neu registrieren bzw. nach der Registrierung das Passwort ändern, bis er das des zuvor vorhandenen Benutzers gefunden und damit Zugriff auf dessen Benutzerkonto hat. Sehr wahrscheinlich wird er dabei nicht von einem Schutz vor Brute-Force-Angriffen ausgebremst, evtl. aber durch ein CAPTCHA, das automatisierte Benutzerregistrierungen verhindern soll. Aber ein CAPTCHA lässt sich inzwischen meist auf die eine oder andere Art und Weise umgehen.
Nebenwirkungen
Verhindert eine Webanwendung, bei der sich der Benutzer selbst registrieren kann, die doppelte Vergabe von Benutzernamen, führt das zu einem weiteren Problem: Die notwendigerweise ausgegebene Fehlermeldung verrät einem Angreifer, dass ein Benutzername bereits vorhanden, also gültig ist. Er kann also versuchen, eine Liste typischer Benutzernamen zu registrieren und anhand der Fehlermeldung erkennen, welche davon vorhanden sind.
Das Problem lässt sich auch nicht beseitigen, denn selbst wenn der Benutzer bei einer fehlgeschlagene Registrierung nicht über deren Ursache informiert wird, ist es meist sehr wahrscheinlich, das ein bereits vorhandener Benutzername der Grund ist. Vor allem, wenn eine Registrierung mit ansonsten identischen Daten, aber anderen Benutzernamen, gelingt.
Doppelt vergebene Benutzernamen sind ein relativ kleines Problem im Vergleich zu vorhersagbaren Benutzernamen und Passwörtern. Um die geht es in der nächsten Folge.
Trackbacks
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