Skip to content

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

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- Fehler zu vermeiden. Und das gleiche gilt natürlich für

Logikfehler

Die führen schnell zu sog. "Fail-Open-Mechanismen".

Je komplexer ein Mechanismus, desto anfälliger ist er für Logikfehler, die am Ende zum genau falschen Ergebnis führen: Statt bei einem auftretenden Fehler die Authentifizierung abzubrechen und den Benutzer nicht zu authentifizieren, wird ihm der Zugriff gewährt. Evtl. in einer unvollständig initialisierten Session oder mit anderen Einschränkungen, aber doch so, das er sensitive Daten erlangen oder sonstwie Schaden anrichten kann. Das kann z.B. durch einen nicht aufgefangenen oder falsch ausgewerteten Fehler passieren, durch den Prüfungen übersprungen oder fälschlich als korrekt bestanden betrachtet werden.

Beispiele für Logikfehler habe ich bereits hier im Blog behandelt, so dass ich hier nicht erneut darauf eingehe, sondern auf die vorhandene Text verweise:

  • Beispiel 1: Onlinebanking mit Authentifizierung in 2 Schritten
  • Beispiel 2: Eine einfache Messaging-Anwendung
  • Beispiel 3 und 4: Der Hashwert ist genau so gut wie der Klartext-Passwort, und der Benutzer admin ist Administrator, basta!
  • Beispiel 5: Kryptographie tritt auf Orakel

Auch das Finden und Vermeiden von Logikfehlern habe ich bereits behandelt.

Autorisierung

Die Autorisierung ist verglichen mit der Authentifizierung sehr viel einfacher: Wenn nötig, muss es unterschiedliche Rollen für die Benutzer geben, und diese müssen eingehalten werden.

Nehmen wir mal an, es gibt 3 Rollen: Administrator, Benutzer und Gast-Benutzer. Der Administrator darf alle Funktionen nutzen und sämtliche Einstellungen ändern, ein normaler Benutzer einen Teil der Funktionen nutzen und manche individuellen Einstellungen ändern, und ein Gast-Benutzer hat nur Zugriff auf einige wenige Funktionen und darf keinerlei Einstellungen ändern.

Dann muss für jedes Interface sichergestellt sein, dass den Benutzern nach der Authentifizierung eine Rolle zugewiesen wird und sie nur auf die Funktionen und Einstellungen zugreifen dürfen, die ihrer Rolle entsprechen. Insbesondere darf es nicht möglich sein, sich höhere Rechte zu verschaffen und auf eine eigentlich nicht zugängliche Funktion oder Einstellung zuzugreifen.

Schwachstellen in diesen Bereich treten oft schon im Rahmen der Authentifizierung auf, indem z.B. ein normaler Benutzer die Rolle des Administrators annimmt oder ein Gast-Benutzer mangels Authentifizierung ungehindert auf eine eigentlich für den Administrator vorgesehene Funktion zugreifen kann. Aber auch bei der Autorisierung kann es zu Fehlen kommen, z.B. weil eine eigentlich für Administratoren vorgesehen Funktion von allen authentifizierten Benutzern aufgerufen werden kann.

Bei jedem Aufruf einer Funktion und bei jeden Zugriff auf Daten müssen immer zwei Punkte geprüft werden:

  1. Wer ist das?
    und
  2. Darf der das?

Nur wenn der Aufruf oder Zugriff zulässig ist, darf er durchgeführt werden.

Sichere Authentifizierung und Autorisierung nach OWASP im Überblick

Zum Abschluss des Bereichs "Unsichere Authentifizierung/Autorisierung" noch einmal die Anforderungen an eine sichere Authentifizierung/Autorisierung laut Punkt 2 der Top IoT Vulnerabilities, der "Insufficient Authentication/Authorization" im Überblick, allerdings etwas zusammengefasst.

  1. Sicher stellen, dass starke Passwörter verwendet werden müssen (siehe z.B. hier und hier).
  2. Sicher stellen, dass überall wo es nötig ist, eine granulare Zugriffskontrolle gibt (s.o.).
  3. Sicher stellen, dass die Zugangsdaten (Credentials) ausreichend geschützt sind (siehe z.B. hier, hier und hier).
  4. Verwenden einer 2-Faktor-Authentifizierung, wo das möglich ist (siehe z.B. ab hier).
  5. Sicher stellen, dass der Passwort-Recovery-Mechanismus sicher ist (siehe z.B. hier und hier).
  6. Sicher stellen, dass für sensible Funktionen eine erneute Authentifizierung erfolgt.
  7. Sicher stellen, dass die Passwortregeln konfigurierbar sind.
  8. Sicher stellen, dass Zugangsdaten (Credentials) widerrufen werden können.
  9. Sicher stellen, dass die Authentifizierung für App, Gerät und Server erzwungen wird (jeweils sofern vorhanden, natürlich).
  10. Die Zuordnung der Benutzer-ID mit den zugehörigen Zugangsdaten, der Geräte-ID und der App-ID muss auf dem Server verwaltet werden.
  11. Sicher stellen, dass das an den Client gelieferte Authentifizierungs-Token bzw. die Session-ID sich jedes Mal ändert.
  12. Sicher stellen, dass Benutzer-ID, Geräte-ID und App-ID eindeutig sind.

Und damit ist Punkt 2 der OWASP Top 10 für das IoT endlich angeschlossen. In der nächsten Folge geht es also um Punkt 3, die "Insecure Network Services".

Carsten Eilers

Trackbacks

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

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!