Skip to content

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.

Carsten Eilers

Trackbacks

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

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