Skip to content

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

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. Aber selbst die sichersten Zugangsdaten sind gefährdet, wenn es keine sichere Datenübertragung gibt.

Neben all diesen möglichen Schwachstellen und Angriffen gilt es dann nur noch, einige typische Implementierungs- und Logikfehler zu vermeiden. Und mit denen geht es nun weiter:

Schritt für Schritt für Schritt...

Besteht der Authentifizierungsprozess aus mehreren Schritten, dürfen dabei 1. nie Daten auf dem Client zwischengespeichert werden, und 2. muss die Reihenfolge der Schritte geprüft werden. So weit waren wir schon, und darum geht es nun weiter mit

3. Es muss immer die gleiche Benutzeridentität geprüft werden!

Die Anwendung könnte annehmen, das in jedem Schritt die gleiche Benutzeridentität geprüft wird, ohne dies explizit zu prüfen. Z.B. könnte Schritt 1 einen gültigen Benutzername und das zugehörige Passwort prüfen, während Schritt 2 den Wert eines Security-Tokens prüft und dazu den Benutzernamen in einem versteckten Formularfeld überträgt (was an sich schon gegen Punkt 1 verstößt und allein deshalb schon nicht passieren sollte). Ein Angreifer könnte dann mit Benutzername und Passwort eines Benutzers und Benutzername und Token eines anderen Benutzers die Authentifizierung erfolgreich durchlaufen (wobei egal sein soll, welche Benutzeridentität dann angenommen wird).

Was auf den ersten Blick nicht schlimm ist, denn der Angreifer muss sich immer noch Benutzername und Passwort bzw. Token verschaffen, nur eben von 2 Benutzern. Was ist aber, wenn der Angreifer selbst ein Benutzer ist? Ein Benutzer, der ein fremdes Token besitzt, könnte sich dann mit seinem Benutzernamen und Passwort sowie dem fremden Benutzernamen und Token anmelden und evtl. auf das fremde Konto zugreifen. Oder ein Benutzer, der das Passwort eines anderen Benutzers kennt, könnte sich mit Hilfe seines eigenen Tokens Zugang zum Benutzerkonto des anderen Benutzers verschaffen.

4. Falsche Sicherheitsfrage

Um einmal z.B. über Phishing ausgespähte Zugangsdaten für den Angreifer wertlos zu machen, erfordern manche mehrstufigen Authentifizierungssysteme nach der Eingabe von Benutzername und Passwort z.B. die Beantwortung einer von mehreren geheimen Fragen oder die Eingabe bestimmter Zeichen einer geheimen Zeichenfolge. Ein Angreifer mit ausgespähten Zugangsdaten scheitert dann am zweiten Schritt, da er nur eine von mehreren möglichen Eingaben kennt. Was grundsätzlich funktioniert, kann durch Implementierungsfehler unwirksam werden:

  • Die Webanwendung könnte die möglichen geheimen Fragen statt auf dem Server in versteckten Feldern des HTML-Formulars für den zweiten Schritt speichern und über einen weiteren Parameter, z.B. einen Indexwert, auswählen. Was natürlich beides schon gegen Punkt 1 verstößt und deshalb nicht passieren sollte. Aber Sie wissen ja, was Murphy herausgefunden hat: Wenn etwas schief geht, dann aber richtig.
    Der Angreifer könnte in diesem Fall den Indexwert dann so manipulieren, das ihm die zuvor ausgespähte Frage gestellt wird.
  • Die Webanwendung könnte die möglichen geheimen Fragen auf dem Server speichern und bei jedem Authentifizierungsversuch eine davon zufällig auswählen, aber im Fall einer falschen Antwort nicht speichern, welche Frage gestellt wurde.
    Der Angreifer könnte sich dann solange anzumelden versuchen, bis die richtige Frage gestellt wird.

Das gleiche gilt entsprechend, wenn bestimmte Zeichen einer geheimen Zeichenfolge abgefragt werden.

In manchen Authentifizierungssystemen, in denen eine zufällige Auswahl verwendet wird, werden alle Eingaben auf einer Seite gesammelt. Diese enthält dann außer Formularfeldern für Benutzername und Passwort noch eine Abfrage samt Eingabefeld für die geheime Frage, die bei jedem Aufruf der Seite zufällig aus den auf dem Server gespeicherten Vorgaben ausgewählt wird. In diesem Fall kann der Angreifer die Anmeldeseite solange immer wieder neu aufrufen, bis die ihm bekannte Frage erscheint. Da der Angreifer die Zugangsdaten erst abschickt, wenn die bekannte Frage erscheint, gibt es in diesem Fall auch keine fehlgeschlagenen Authentifizierungsversuche.

Der Versuch, durch den Einsatz eines persistenten Cookies sicher zu stellen, das immer die gleiche geheime Frage gestellt wird, bis sie korrekt beantwortet wurde, ist zum Scheitern verurteilt, da der Angreifer diesen Cookie manipulieren kann. Es ist in diesem Fall auch nicht möglich, diese Information auf dem Server zu speichern, da der Client nur anhand der IP-Adresse erkannt werden kann. Benutzername und Passwort werden ja erst an die Webanwendung gesendet, wenn die dem Angreifer bekannte geheime Frage erscheint. Die IP-Adresse kann aber auch einem Proxy-Server gehören, der von mehreren Benutzern genutzt wird. Außerdem kann die IP-Adresse vom Angreifer i.A. nach Belieben gewechselt werden, oft muss er dazu nur seine Internetverbindung beenden und neu aufbauen. Oder er verwendet verschiedene Proxy-Server. Oder ...

In der nächsten Folge werden einige Logikfehler vorgestellt.

Carsten Eilers

Trackbacks

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!