Skip to content

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

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. Für die Richtung vom Browser des Benutzers zur Webanwendung oder zum IoT-Gerät nimmt man dafür HTTPS, das ist weiter kein Problem. Aber was ist mit der Übertragung der von der Webanwendung im Rahmen der Registrierung erzeugten Zugangsdaten? Oder den vom zentralen Server der IoT-Geräte erzeugten?

Die müssen an den Benutzer übermittelt werden, und das, ohne das Unbefugte sie dabei zu sehen bekommen. Und zusätzlich i.A. über einen anderen Übertragungskanal als den für die Registrierung verwendeten. Denn sonst besteht die Gefahr, dass ein Angreifer sich mit fremden Daten anmeldet und danach die Webanwendung oder das IoT-Gerät in Namen seines Opfers missbräuchlich nutzt.

Die Übertragung der Zugangsdaten "out of band" bietet zumindest einen gewissen Schutz vor Registrierungen unter falschen Namen: Durch das Mailen der Zugangsdaten an die angegebene E-Mail-Adresse oder ihr Schicken an die angegebene Postanschrift soll geprüft werden, ob das E-Mail-Konto bzw. der Briefkasten unter der Kontrolle der Person steht, die sich damit registriert hat.

Noch einfacher ist das Ganze natürlich, wenn der Benutzer seine Daten persönlich abholt, denn dann kann dabei sogar eine direkte Identitätsprüfung erfolgen. Das ist z.B. im Intranet eines Unternehmens oder allg. einer Organisation sehr einfach, da können die Benutzer die vom Server erzeugten Zugangsdaten z.B. in der IT-Abteilung abholen oder sie bekommen sie von ihrem Vorgesetzten oder in der Personalabteilung oder ... .

Im Internet muss man dagegen meist auf E-Mails oder normale Briefe ausweichen. Dabei gibt es ein paar Fallstricke:

  • Übertragung von Benutzername und Passwort gemeinsam
    Enthält die Nachricht sowohl Benutzername als auch Passwort, und gibt es weder ein Zeitlimit für deren Gültigkeit noch einen Zwang zur Passwortänderung bei der ersten Anmeldung, werden viele Benutzer das Passwort nicht ändern, und jeder, dem die Daten in die Hände fallen, kann sich damit anmelden. Und zumindest bei einem Brief, der irgendwann im Altpapier landet, weiß man nie, ob den nicht noch mal irgend jemand liest.
  • Aktivierungs-Links
    Wird statt der vollständigen Zugangsdaten oder des Passworts nur ein Aktivierungs-Link verschickt, mit dem sich die Benutzer einmalig anmelden können, um dann ein eigenes Passwort zu setzen, können vorhersagbare URLs einen Angreifer in die Lage versetzen, fremde Benutzerkonten zu übernehmen.
  • Übertragung sämtlicher Daten
    Werden nicht nur Benutzername und Passwort bzw. ein Aktivierungs-Link übertragen, sondern sämtliche bei der Registrierung angegebenen Daten wie z.B. Name und Adresse, weitere Kontaktmöglichkeiten wie Telefonnummern oder (ggf. weitere) E-Mail-Adressen oder die Antwort auf die Sicherheitsfrage, hilft auch eine zeitliche Begrenzung der Gültigkeitsdauer der Zugangsdaten oder der Zwang zum Setzen eines Passworts bei der ersten Anmeldung nicht vor einem Angriff, der dann z.B. durch Nutzung der Passwort-Reset-Funktion mit der bekannten Antwort auf die Sicherheitsfrage oder in Form eines Social-Engineering-Angriffs erfolgen kann.
  • "Fremde Briefkästen"
    Werden die Zugangsdaten an die angegebene Postanschrift geschickt, beweist das nur, das der sich registrierende Benutzer diesen Brief empfangen hat. Ob er den aus seinem eigenen Briefkasten genommen hat oder ihn z.B. aus einen ungenutzten Briefkasten geangelt hat oder einfach einen Briefkasten mit passenden Namen in einer anonymen Wohngegend an die Wand geschraubt hat, weiß man nicht. Will man sicher sein, dass die angegebene Anschrift stimmt, muss man schon zu einem dafür vorgesehen Verfahren, z.B. dem Postident-Verfahren der Deutschen Post, greifen.

Schwachstellen verhindern

Diese Schwachstellen lassen sich recht einfach verhindern:

  • Statt Benutzername und Passwort gemeinsam zu übertragen sollte nur das Passwort übertragen werden. Den Benutzernamen kennt der Benutzer ja schon von der Registrierung.
    Außerdem darf das Passwort nicht unbegrenzt gültig sein, sondern nur für einen relativ kurzen Zeitraum. Wie lang der ist, muss im Einzelfall entschieden werden, da die neu registrierten Benutzer ja Zeit haben müssen, um sich damit anzumelden. Außerdem sollte es nach der ersten Anmeldung mit diesen Zugangsdaten einen Zwang zum Setzen eines neuen Passworts geben, so dass das übertragene Passwort danach unbrauchbar ist.
  • Werden Aktivierungs-Links verschickt, müssen die wirklich zufällig und nicht vorhersagbar erzeugt werden. Es spricht nichts dagegen, z.B. den Benutzernamen oder weitere Daten im URL zu speichern, zusätzlich muss aber ein wirklich zufälliger Wert verwendet werden, so dass ein Angreifer keine gültigen Aktivierungs-Links erzeugen kann.
    Im Extremfall, in dem der Link alle zum Anlegen des neuen Benutzerkontos verwendeten Daten enthält, könnte ein Benutzer sogar die Registrierung umgehen und nur durch das Erzeugen eines entsprechenden Links ein neues Benutzerkonto anlegen.
    Außerdem dürfen die Aktivierungs-Links nur einmal zu benutzen sein, damit ein Angreifer, dem so ein Link in die Hände fällt, darüber nicht später noch die Kontrolle über das betreffende Benutzerkonto erlangen kann.
  • Vollständige Daten sollten sicherheitshalber nicht übertragen werden. Wozu auch - die kennt der Benutzer ja. Insbesondere dürfen keine Informationen, die zum Zurücksetzen des Passworts oder für ähnliche Fallback-Funktionen verwendet werden, übertragen werden. Geraten die in falsche Hände, ist das entsprechende Benutzerkonto danach kompromittiert.

Auch in der nächsten Folge geht weiter um die Sicherheit der Authentifizierung.

Carsten Eilers

Trackbacks

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

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!