Skip to content

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

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-Funktion" können zur Gefahr werden. Genauso wie eine

Unsichere "Remember me"-Funktion

Manchmal muss ein Angreifer gar nicht die Login-Funktion angreifen, um sich Zugriff zu einer Webanwendung bzw. IoT-Oberfläche zu verschaffen. Stattdessen nutzt er die oft vorhandene "Remember me"-Option, um sich eine Session zu beschaffen.

Die "Remember me"-Funktion bietet dem Benutzer die Möglichkeit, ohne Eingabe von Benutzername und Passwort Zugriff auf die Webanwendung bzw. -oberfläche zu erlangen, wenn er sie von einem zuvor bereits für den Zugriff genutzten Rechner aus aufruft.

Sie erkennen sicher das Problem: Ein Zugriff ohne Eingabe von Benutzername und Passwort - das ist doch genau das, was ein Angreifer möchte. So eine Funktion muss also besonders sicher implementiert werden. Leider ist oft das Gegenteil der Fall und die Funktion ist schon vom Design her unsicher. Oft sogar so, das sie nicht nur lokal, sondern auch aus der Ferne missbraucht werden kann.

Grundsätzliches Problem: Vertraue nie dem Client

Die "Remember me"-Funktion leidet an einem grundsätzlichen Problem: Sie verstößt gezwungenermaßen gegen den wichtigsten Grundsatz der Web-Sicherheit: Vertraue nie dem Client. Alle vom Client gelieferten Daten können manipuliert sein. Das Problem lässt sich aber in diesem Fall nicht umgehen: Wenn man den Client erkennen möchte, muss man dafür schon von ihm gelieferte Daten verwenden.

Persistenter Cookie - persistente Schwachstelle

Die einzige Möglichkeit, dauerhaft Daten auf dem Client zu speichern und automatisch an die Webanwendung schicken zu lassen bietet ein persistenter Cookie. Er ist also die einzige Möglichkeit, einen bestimmten Client automatisch wiederzuerkennen.

Alternativ kann man die Daten auch in der Datenbank oder dem Local Storage des Browsers speichern und dann vom JavaScript-Code des Webclients an den Server schicken lassen, das ändert aber am Grundproblem nichts: Der Server muss den auf dem Client gespeicherten Daten vertrauen. Im Folgenden beschreibe ich das Problem daher am Beispiel des Cookies, für die beiden andere Möglichkeiten gilt das gleiche.

Manche Webanwendungen implementieren die "Remember me"-Funktion einfach, indem sie einen persistenten Cookie mit dem Benutzernamen des Benutzers anlegen, z.B. RememberUser=donaldduck. Wird dieser Cookie an die Startseite übertragen, erkennt die Webanwendung den betreffenden Benutzer und richtet ihm sofort, ohne vorherige Authentifizierung, eine neue Session ein. So einen Cookie muss ein Angreifer nicht einmal ausspähen, um sich anzumelden - er muss nur den Benutzernamen kennen. Mit einer Liste bekannter oder üblicher Benutzernamen kann der Angreifer sich also problemlos Zugriff zur Webanwendung verschaffen, ohne der Authentifizierungsfunktion auch nur nahe zu kommen.

Andere Webanwendungen verwenden statt des Benutzernamens eine Benutzer-ID. Wird der Cookie an die Startseite übertragen, ermittelt die Webanwendung den zugehörigen Benutzer und richtet ihm eine neue Session ein. Ist diese Benutzer-ID bekannt oder kann sie vom Angreifer berechnet oder erraten werden, kann er sich damit sofort Zugriff auf die Webanwendung verschaffen. Im Prinzip entspricht der Angriff in diesem Fall dem klassischen Session-Hijacking.

Der Unterschied zwischen dem Ausnutzen der "Remember me"-Funktion mit einer Benutzer-ID und dem Session-Hijacking, bei dem eine ausgespähte oder berechnete Session-ID für den Zugriff verwendet wird, ist der Zeitraum, in dem die erlangten Informationen verwendet werden können:

  • Die beim Session-Hijacking angegriffene laufende Session wird i.A. nach einer gewissen Zeit der Untätigkeit beendet, wodurch der Angreifer seine Session-ID nur für einen normalerweise relativ kurzen Zeitraum nutzen kann.
  • Dagegen ist die für die "Remember me"-Funktion verwendete Information normalerweise für einen deutlich längeren Zeitraum gültig, der Benutzer soll ja meistens auch noch nach einigen Tage erkannt werden.

Und während man beim Session-Management zusätzlich die IP-Adresse als Identifizierungsmerkmal hinzuziehen kann, die sich während einer laufenden Session nicht ändern sollte, ist das für die "Remember me"-Funktion nicht möglich, da der Rechner des Benutzers zwischen zwei Sessions durchaus eine neue IP-Adresse bekommen haben kann.

Eine sichere Variante, aber mit Einschränkungen

Ein Angreifer darf keine Möglichkeit haben, die gespeicherte Information zur Erkennung des Benutzers zu erraten und/oder sich durch eine manipulierte Information Zugang zur Webanwendung zu verschaffen. Aber selbst wenn die gespeicherte Information ausreichend geschützt ist, z.B. weil es sich um eine nicht vorhersagbare Zufallszahl handelt oder weil sie verschlüsselt wurde, kann sie noch z.B. über einen Cross-Site-Scripting-Angriff oder von auf dem Client-Rechner installierter Spyware ausgespäht und danach vom Angreifer von dessen Computer aus als Identifikationsmerkmal an die Webanwendung bzw. das IoT-Gerät geschickt werden. Was eigentlich nur einen Schluss zulässt: Auf so eine Funktion sollte man besser verzichten, ihre Vorteile (der Benutzer muss sich nicht einloggen) sind das Risiko (ein Angreifer muss sich nicht einloggen) nicht wert. Vor allem, da vor kritischen Aktionen ja sicherheitshalber doch noch eine Authentifizierung erfolgen sollte.

In der nächsten Folge geht es um eine weitere mögliche Schwachstelle in der Authentifizierung und Autorisierung: Die "User Impersonation"-Funktion mancher Webanwendungen, mit denen ein privilegierter Benutzer die Identität eines anderen Benutzers annehmen kann, um dann Aktionen in dessen Benutzerkontext auszuführen. So eine Funktion wird es in IoT-Weboberflächen eher selten geben, ich möchte sie aber der Vollständigkeit halber nicht unerwähnt lassen.

Carsten Eilers

Trackbacks

Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #2: Unsichere Authentifizierung/Autorisierung, Teil 11

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 12

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

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