Freitag, 22. Oktober 2010


Topthema

Donnerstag, 3. September 2009 | Topthema

About Security #220: Schwachstellen-Suche: Authentifizierung - Unsichere Kryptographie

(Link zum Artikel: http://www.entwickler.de/entwicklerde/kolumnen/051020)

Der unsichere Einsatz eigentlich sicherer Kryptographie-Algorithmen ist das Thema dieser Folge.

Verschlüsseln, nicht kodieren!

Kodierung und Verschlüsselung werden manchmal als gleichwertig angesehen - mit fatalen Folgen für die Sicherheit. Wird statt eines erwiesenermaßen sicheren Kryptographie-Algorithmus nur ein gar nicht für den Schutz der Daten vorgesehener Kodierungs-Algorithmus wie z.B. die in About Security #219 als Beispiel verwendete Base64-Kodierung verwendet, kann ein Angreifer diese Daten durch Anwendung des entsprechenden Dekodier-Algorithmus "entschlüsseln".

Aber auch eigentlich sichere Kryptographie-Algorithmen werden unsicher und können gebrochen werden, wenn sie falsch verwendet werden.

Beispiel 1: Unsichere Verwendung von HTTPS

Die für HTTPS verwendeten Protokolle Secure Sockets Layer (SSL) und Transport Layer Security (TLS), siehe About Security #73, sind eigentlich sicher. Ein hierarchisches Zertifizierungssystem (siehe About Security #81 und #82) sorgt dafür, dass der Client die Identität des Servers prüfen kann: Der Server präsentiert sein Zertifikat, in dem eine Zertifizierungsstelle (Certification Authority, CA) seine Identität bestätigt, und der Client kann dessen Korrektheit anhand der im Webbrowser vorhandenen Root-Zertifikate prüfen. Das funktioniert alles zufriedenstellend, so lange eine Zertifizierungsstelle verwendet wird, deren Root-Zertifikat im Webbrowser enthalten ist. Liegt dem Webbrowser das Root-Zertifikat der verwendeten Zertifizierungsstelle nicht vor, fragt er beim Benutzer nach, ob der dem präsentierten Zertifikat vertrauen möchte oder nicht. Der Benutzer kann dann entscheiden, ob er diesem bestimmten Server-Zertifikat vertraut oder nicht und sich ggf. auch das fehlende Root-Zertifikat besorgen und im Webbrowser importieren. Außer von Zertifizierungsstellen ausgestellten Zertifikaten können auch selbst-signierte Zertifikate (self-signed certificate), die unabhängig von einer Zertifizierungsstelle erstellt wurden, verwendet werden. Diese müssen ebenfalls manuell bestätigt werden. Eine Authentifizierung ist damit nicht möglich, ein solches Zertifikat ist genau so aussagekräftig wie ein selbst ausgestellter Personalausweis, aber die übertragenen Daten können danach mit dem im Zertifikat enthaltenen Schlüssel verschlüsselt werden.

Werden selbst signierte oder von einer dem Webbrowser unbekannten Zertifizierungsstelle ausgestellte Zertifikate verwendet, ist die Verschlüsselung über einem Man-in-the-middle-Angriff angreifbar, bei dem der Angreifer dem Benutzer sein eigenes, gefälschtes Zertifikat unterschiebt. Da der Benutzer weiß, dass er das Zertifikat bestätigen muss und das auch bereits in der Vergangenheit getan hat, wird er bei der entsprechenden Meldung des Webbrowsers weniger misstrauisch sein. Die prinzipiell sichere Verschlüsselung wird also nicht gebrochen, sondern quasi unterbrochen: Der Angreifer nutzt die unsichere Verwendung von HTTPS, um sich quasi zwischen Client und Server zu drängeln und dort die Daten zu belauschen. Verschärft wird dieses Problem durch die erweiterten Warnungen in neuen Webbrowsern: Wenn die grossflächig vor einem unsicheren Zertifikat warnen und einen Abbruch der Verbindung empfehlen, ist es kontraproduktiv, dem Benutzer vorher zu sagen, das er diese Warnung in diesem Fall ignorieren soll, da sie selbst verursacht wurde. Ob das wirklich der Fall ist oder ob ein tatsächlich gefälschtes Zertifikat vorgezeigt wurde, kann der normale Benutzer meist nicht beurteilen.

Weitere Beispiele zur unsicheren Verwendung von HTTPS gibt es in About Security #218.

Beispiel 2: Ungesalzene Hashwerte
About Security: Die komplette Serie

Statt Passwörter als Klartext zu speichern, werden oft nur deren Hashwerte (siehe About Security #102 ff) 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 bei der Webanwendung anmelden zu können, benötigt er die Passwörter als Klartext. In diesem Zusammenhang kommt 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. Vorberechnete Listen ohne Salt sind dann bei der Bestimmung des zu einem Hashwerts gehörenden Passworts wertlos, der Angreifer muss eine eigene Liste unter Berücksichtigung des Salts berechnen. Weitere Vorteile des Salt: Da die Eingabe für die Hashfunktion durch den Salt länger wird, steigt auch der Rechenaufwand für den Angreifer. Und durch die zufällige Wahl des Salts ergeben sich für zufällig gleiche Passwörter unterschiedliche Hashwerte.

Außer dem Benutzernamen und dem Hashwert des Passworts muss auch der Salt-Wert gespeichert werden, da er bei der späteren Passwortprüfung benötigt wird.

In der nächsten Folge geht es um weitere mögliche Angriffe auf die Authentifizierung.

Wenn Sie Fragen oder Themenvorschläge haben, können Sie diese gerne an die angegebene E-Mail-Adresse senden oder im Security-Forum einbringen!

Carsten Eilers

About Security - Übersicht zum aktuellen Thema:

Kommentare

Folgende Links könnten Sie auch interessieren