Skip to content

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

Bei der Beschreibung der gefährlichsten Schwachstellen in den Geräten des IoT gemäß den Top IoT Vulnerabilities von OWASP sind wir beim Punkt 2 angekommen: "Insufficient Authentication/Authorization". Die verschiedenen Möglichkeiten zur Authentifizierung habe ich bereits beschrieben. Ebenso erste Angriffe: Default-Zugangsdaten und schlechte (= unsichere) Passwörter. Als nächstes kommt:

Der digitale Vorschlaghammer - Brute-Force- und Wörterbuch-Angriffe

Neben schwachen Passwörtern ist die Möglichkeit, beliebig viele Kombinationen von Benutzername und Passwort ausprobieren zu können, eine weitere sehr häufige Schwachstelle im Bereich der Authentifizierung. Die Aufgabe "Durchprobieren aller möglichen Kombinationen" lässt sich, egal für was, sehr einfach einem Computer übertragen. Entsprechend gibt es auch etliche Programme, die solche Brute-Force-Angriffe auf Authentifizierungssysteme durchführen, wie z.B. Burp Intruder oder THC-Hydra. Dabei können zum einen übliche Werte aus einem Wörterbuch durchprobiert werden, zum anderen alle möglichen Werte systematisch erzeugt und ausprobiert werden. Besonders gefährdet sind dann Standard-Benutzerkonten wie z.B. admin oder administrator: Die sind in vielen IoT-Weboberflächen vorhanden, und der Angreifer muss "nur noch" das zugehörige Passwort ermitteln.

Um Brute-Force-Angriffe abzuwehren, darf nur eine bestimmte Anzahl fehlgeschlagener Login-Versuche pro Zeiteinheit möglich sein. Wie das am besten realisiert wird, hängt von den jeweiligen Bedingungen ab. Einige Möglichkeiten, die sich auch kombinieren lassen, sind:

  • Nach dem z.B. dritten fehlgeschlagenen Login-Versuch für einen Benutzernamen gibt es eine Zwangspause
  • Nach dem z.B. zehnten fehlgeschlagenen Login-Versuch von einer bestimmten IP-Adresse aus gibt es eine Zwangspause, wobei berücksichtigt werden muss, das es sich auch um die IP-Adresse eines Proxy-Servers handeln kann, hinter dem sehr viele Benutzer stecken können.
  • Nach jedem fehlgeschlagenen Login-Versuch für einen Benutzernamen gibt es eine Zwangspause, die sich mit jedem weiteren Fehlschlag erhöht, z.B. verdoppelt - z.B. von 1 Sekunde nach dem ersten Fehlversuch auf 2 Sekunden nach dem zweiten, 4 Sekunden nach dem dritten usw.. Was ein normaler Benutzer kaum merkt, behindert einen automatisierten Angriff stark.

Dabei darf die Abwehr von Brute-Force-Angriffen nicht auf dem Client implementiert werden. Dort könnte sie vom Angreifer problemlos manipuliert und umgangen werden. Gibt es z.B. einen Cookie, der die fehlgeschlagenen Login-Versuche zählt, könnte ein Angreifer diesen laufend auf 0 zurück setzen und damit einen durchgeführten Brute-Force-Angriff vor der Webanwendung verbergen.

Als Benutzer können Sie Brute-Force-Angriffe natürlich nicht verhindern. Wenn die Weboberfläche (oder auch z.B. der Telnet-Zugang) ihres IoT-Geräts keinen Schutz enthält, kann ein Angreifer in Ruhe alle möglichen Passwörter ausprobieren. Sie können aber durch die Wahl eines vor Brute-Force-Angriffen sicheren Passworts verhindern, dass der Angriff Erfolg hat. Und falls Sie die Möglichkeit haben, den Benutzernamen frei zu wählen, sollten sie einen verwenden, der sich nicht leicht erraten lässt. Denn dann muss ein Angreifer nicht nur das Passwort, sondern auch den Benutzernamen richtig raten. Was das Ganze deutliche schwerer macht. Jedenfalls wenn er keine zusätzlichen Hilfestellungen bekommt. Womit wir beim nächsten Problem sind:

Verräterische Fehlermeldungen

Für die Authentifizierung werden i.A. (mindestens) zwei Informationen benötigt: Ein gültiger Benutzername und das zugehörige Passwort. Kennt der Angreifer keinen gültigen Benutzernamen, muss er bei einem Brute-Force-Angriff also zwei Parameter erraten. Und das im Idealfall gleichzeitig, da er ja nicht weiß, ob sein Anmelde-Versuch bereits am ungültigen Benutzername oder erst am falschen Passwort gescheitert ist.

Verrät ihm die Webanwendung aber, ob ein gewählter Benutzername gültig ist oder nicht, muss er nachdem er einen gültigen Benutzernamen gefunden hat nur noch das zugehörige Passwort finden.

Bei einem fehlgeschlagenen Login sollte also besser eine neutrale Meldung wie "Benutzername und Passwort passen nicht zusammen" ausgegeben werden, statt den Angreifer direkt darauf hin zu weisen, wo der Fehler liegt: "Benutzername nicht gefunden" oder "Passwort falsch" verraten ihm sofort, ob er schon einen gültigen Benutzernamen erraten hat und nun nur noch das passende Passwort suchen muss, oder ob er bei der Suche nach einem gültigen Benutzernamen weitermachen muss.

Dieser Schutz ist natürlich überflüssig, wenn es einen wirksamen Schutz vor Brute-Force-Angriffen gibt. Dann kann man dem Benutzer auch eine hilfreichere Fehlermeldung liefern, so dass er erkennen kann, ob er sich beim Benutzernamen oder beim Passwort vertippt hat.

In der nächsten Folge geht es um weitere Schwachstellen in und Angriffe auf die Authentifizierung.

Carsten Eilers

Trackbacks

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

Vorschau anzeigen
Bei der Beschreibung der gefährlichsten Schwachstellen in den Geräten des IoT gemäß den Top IoT Vulnerabilities von OWASP sind wir beim Punkt 2 angekommen: "Insufficient Authentication/Authorization". Die verschiedenen Mög

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

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 6

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

www.ceilers-news.de am : PingBack

Die Anzeige des Inhaltes dieses Trackbacks ist leider nicht möglich.

www.ceilers-news.de am : PingBack

Die Anzeige des Inhaltes dieses Trackbacks ist leider nicht möglich.

www.ceilers-news.de am : PingBack

Die Anzeige des Inhaltes dieses Trackbacks ist leider nicht möglich.

www.ceilers-news.de am : PingBack

Die Anzeige des Inhaltes dieses Trackbacks ist leider nicht möglich.

www.ceilers-news.de am : PingBack

Die Anzeige des Inhaltes dieses Trackbacks ist leider nicht möglich.

www.ceilers-news.de am : PingBack

Die Anzeige des Inhaltes dieses Trackbacks ist leider nicht möglich.

www.ceilers-news.de am : PingBack

Die Anzeige des Inhaltes dieses Trackbacks ist leider nicht möglich.

www.ceilers-news.de am : PingBack

Die Anzeige des Inhaltes dieses Trackbacks ist leider nicht möglich.

www.ceilers-news.de am : PingBack

Die Anzeige des Inhaltes dieses Trackbacks ist leider nicht möglich.

www.ceilers-news.de am : PingBack

Die Anzeige des Inhaltes dieses Trackbacks ist leider nicht möglich.

www.ceilers-news.de am : PingBack

Die Anzeige des Inhaltes dieses Trackbacks ist leider nicht möglich.

www.ceilers-news.de am : PingBack

Die Anzeige des Inhaltes dieses Trackbacks ist leider nicht möglich.

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