Die IoT Top 10, #2: Unsichere Authentifizierung/Autorisierung, Teil 6
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
Statt Passwörter als Klartext zu speichern, werden i.A. nur deren Hashwerte gespeichert. Bei der Authentifizierung wird dann der Hashwert des eingegebenen Passworts berechnet und mit dem gespeicherten Wert verglichen.
Werden die Benutzerdaten z.B. über eine Directory-Traversal-Schwachstelle ausgespäht, kann der Angreifer mit den gespeicherten Hashwerten nichts anfangen: Um sich anmelden zu können, benötigt er die Passwörter als Klartext. Und die hat er ja nicht. Zumindest in der Theorie.
In der Praxis kommt in diesem Zusammenhang eine notwendige Eigenschaft von Hashwerten negativ zum Zuge: Hashwerte sind eindeutig, gleiche Eingaben führen zu gleichen Ausgaben. Man kann also eine Liste gebräuchlicher Passwörter erstellen, deren Hashwerte berechnen und sie mit den Hashwerten aus den Benutzerdaten vergleichen. Stimmen zwei Hashwerte überein, kennt man das zugehörige Passwort. Entsprechende Listen können entweder in Form von Wörterbüchern oder platzsparend als sog. Rainbow Tables gespeichert werden und sind in größerer Anzahl im Internet verfügbar.
Um den Cyberkriminellen im wahrsten Sinne des Wortes die Suppe zu versalzen, setzt man bei der Berechnung der Hashwerte einen sog. Salt ein, einen Zufallswert, der mit der Eingabe kombiniert wird, bevor daraus der Hashwert berechnet wird. Da der Salt-Wert für die Prüfung des Passworts benötigt wird muss er zusammen mit dem Passwort gespeichert werden, daher fällt er einem Angreifer i.A. zusammen mit den Passwort-Hashes in die Hände, aber das macht nichts.
Denn vorberechnete Listen ohne Salt sind dadurch bei der Bestimmung des zu einem Hashwerts gehörenden Passworts wertlos, der Angreifer muss eine eigene Liste unter Berücksichtigung des Salts berechnen. Und wenn für jedes Passwort ein individueller Salt-Wert verwendet wird, macht dass die Suche noch aufwendiger, da nun für den Angriff auf ein Benutzerkonto berechnete Daten nicht für den Angriff auf weitere Benutzerkonten verwendet werden können. Leider lassen sich die meisten Hashfunktionen so effektiv berechnen, dass dieser Schutz im Zeiten schneller Rechner und insbesondere der Cloud nicht mehr ausreichend erscheint.
Deshalb gibt es speziell zur Speicherung von Passwörtern inzwischen spezielle Hashfunktionen, die u.a. in Hinblick auf ihre Langsamkeit(!) optimiert wurden, um Angreifern das Leben schwer zu machen. Diese Funktionen erfüllen mehrere besondere Anforderungen:
- Die benötigte Rechenzeit kann einfach erhöht werden, wenn die Rechenleistung steigt.
- Für jeden Benutzer kann eine individuelle Anzahl von Iterationen
verwendet werden.
Normalerweise sinkt die Sicherheit kryptographischer Algorithmen, wenn man sie mehrfach anwendet, im Fall von Passwort-Hashes erhöht das mehrmalige Hashen aber den Rechenaufwand für den Angreifer und damit die Sicherheit. Individuelle Iterationsraten sorgen dafür, dass keine allgemeingültigen Rainbow Tables erstellt werden können. - Der Hashwert ist für jeden Benutzer eindeutig, so dass nicht festgestellt werden kann, ob zwei Benutzer das gleiche Passwort verwenden.
Es gibt mehrere solcher spezieller Funktionen zur Speicherung von Passwörtern, z.B.
- die in RFC 8018 definierte "Password-Based Key Derivation Function 2" (PBKDF2)
- das auf Blowfish basierende crypt_blowfish, das weitgehend kompatibel zum beispielsweise von OpenBSD genutzten bcrypt ist oder
- das ursprünglich für das Online-Backup-Tool Tarsnap entwickelte scrypt.
IoT-Geräte sollten ihre Passwörter zumindest als gesalzene Hashwerte speichern, besser noch mit Hilfe einer der speziellen Passwort-Hash-Funktionen.
In der nächsten Folge geht es um weitere mögliche Angriffe auf die Authentifizierung.
Trackbacks
Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #2: Unsichere Authentifizierung/Autorisierung, Teil 7
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #2: Unsichere Authentifizierung/Autorisierung, Teil 8
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #2: Unsichere Authentifizierung/Autorisierung, Teil 9
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #2: Unsichere Authentifizierung/Autorisierung, Teil 10
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #2: Unsichere Authentifizierung/Autorisierung, Teil 11
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #2: Unsichere Authentifizierung/Autorisierung, Teil 12
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #2: Unsichere Authentifizierung/Autorisierung, Teil 13
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #2: Unsichere Authentifizierung/Autorisierung, Teil 14
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #2: Unsichere Authentifizierung/Autorisierung, Teil 15
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #2: Unsichere Authentifizierung/Autorisierung, Teil 16
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #2: Unsichere Authentifizierung/Autorisierung, Teil 17
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #2: Unsichere Authentifizierung/Autorisierung, Teil 18
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #6: Unsichere Cloud-Interfaces
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #7: Mobile Cloud-Interfaces
Vorschau anzeigen