entwickler.com

Auch Sessiontoken und ähnliche Werte, die im Gegensatz zu den in About Security #245 beschriebenen Ansatz keinerlei Bedeutung haben, müssen irgendwie erzeugt werden. Bekommt ein Angreifer heraus, wie das passiert, kann er danach u.U. eigene Token erstellen, indem er den Wert eines ihm bekannten Tokens extrapoliert: Die Token sind vorhersagbar.

Bedrohungspotential

Wie gefährlich ist es, wenn ein Angreifer ein Muster zum Erstellen gültiger Token erkannt hat? Selbst wenn der Angreifer bei der Vorhersage des Tokens zum größten Teil auf "Trial & Error" angewiesen und z.B. nur eins von 1000 erzeugten Token korrekt ist, können durch die Automatisierung des Angriffs in relativ kurzer Zeit viele gültige Token erzeugt werden. Die Anzahl neu erzeugter Token wird i.A. nur durch die Rechenkapazität des Rechners des Angreifers beschränkt, und sehr wahrscheinlich kann der mehr Token erzeugen, als überhaupt gleichzeitig zur Prüfung an die Webanwendung geschickt werden können. Wenn man davon ausgeht, dass dem Angreifer meist ein gültiges Token reicht, kann man die Gefahr also gar nicht hoch genug einschätzen.

Token analysieren

Je mehr Token man analysieren kann, desto eher kann man ein Muster darin erkennen. Laborversuche, bei denen die zu untersuchende Anwendung dem Tester allein zur Verfügung steht und eine sehr große Anzahl aufeinander folgender Token analysiert werden kann, führen daher oft recht schnell zum Ziel. Beim Testen einer Webanwendung, die man sich mit anderen Benutzern teilen muss, dauert das Erkennen eines Musters meist deutlich länger, da i.A. gar keine oder zumindest nur wenige direkt aufeinander folgenden Token zur Verfügung stehen und zwischen zwei erhaltenen Token eine unbekannte Anzahl weiterer Token erzeugt wurde.

Simpel und Stupid

Im einfachsten Fall besteht das Token aus einer einfachen sequentiellen Zahl, so dass der Angreifer schon nach wenigen untersuchten Token in der Lage ist, weitere gültige Token zu erzeugen. Die muss er dann nur noch an die Webanwendung senden, um eine noch nicht beendete Session zu übernehmen. Daher sollten Benutzer ihre Sessions immer beenden, wenn sie mit der Nutzung der Webanwendung fertig sind (was bei manchen Anwendungen mangels entsprechender Funktion nicht möglich ist!), und die Webanwendung sollte sich nicht nur auf das Token verlassen, um einen Benutzer zu erkennen.

Mögliche Muster

Prinzipiell gibt es unendlich viele Möglichkeiten, Token zu erzeugen. Trotzdem werden einige Ansätze immer wieder verwendet:

• Verborgene/getarnte Sequenzen
• Zeitabhängige Werte
• Schwache Zufallszahlengeneratoren

Bevor die Token untersucht werden können, muss eine größere Anzahl davon gesammelt werden, und das in möglichst kurzer Zeit, damit die Werte möglichst nah beieinander liegen.

Verborgene Sequenzen

Eine Liste mit Token, die auf dem ersten Blick wie Zufallswerte aussehen, verrät evtl. ein Muster, wenn man sie umkodiert: Kommt in den Werten ein + vor, können es Base64-kodierte Werte sein, kommen nur die Ziffern 0 bis 9 und die Buchstaben a bis f vor, können es Hexadezimal kodierte Werte sein. Ein Dekodierversuch kann nie schaden. Auch die Subtraktion jedes Werts vom Vorherigen ist einen Versuch wert, die Token könnten um einen festen Wert erhöht werden.

Zeitabhängige Werte

Machmal wird die Uhrzeit für die Erzeugung der Token verwendet, so liefert z.B. die PHP-Funktion uniqid() beim Aufruf ohne Prefix und ohne das Hinzufügen von Entropie einfach den Unix-Timestamp plus den Zähler für die Mikrosekunden als Hexadezimalwert. Man sollte die Funktion daher nie ohne Entropie verwenden. Zur Tarnung des Werts kann er zusätzlich gehasht werden. Aber zurück zur Untersuchung von Token: Gibt es in der Liste der Token irgend welche Muster? Ändern sich manche Teile häufiger als andere? Z.B. könnte das Token nach dem Muster

[Aufsteigende Zahlensequenz][Millisekunden]

oder

[Millisekunden][Aufsteigende Zahlensequenz]

aufgebaut sein. Bei der Beobachtung eines solchen Tokens ändert sich ein Teil langsam, während sich ein anderer schnell ändert. Bei Zeitabhängigen Werten ist es hilfreich, zwei Reihen von Token zu sammeln, zwischen denen z.B. 10-20 Minuten Pause liegen. In der Zwischenzeit wurden sehr wahrscheinlich Token an andere Benutzer vergeben, so dass eine Zahlensequenz zwar einen Sprung nach oben machen wird, der zeitabhängige Wert aber deutlich stärker steigt.

Schwache Zufallszahlengeneratoren

Da es in Computern i.A. keine Quelle echten Zufalls gibt, müssen Zufallszahlen auf irgend eine Weise berechnet werden. Manche Algorithmen zur Berechnung dieser Pseudozufallszahlen enthalten Schwachstellen, über die aus bekannten Zufallszahlen auf die folgenden geschlossen werden kann. Ein berühmt-berüchtigtes Beispiel dafür ist die 2009 entdeckte Schwachstelle in der OpenSSL-Bibliothek von Debian, und auch im Zufallszahlengenerator von Windows 2000 und XP wurden entsprechende Schwachstellen entdeckt. Wird ein schwacher Zufallszahlengenerator für die Erzeugung von Token verwendet, kann ein Angreifer über die Schwachstelle gültige Token ermitteln.

In der nächsten Folge werden Angriffe auf und über vorhersagbare Token beschrieben. Zum Abschluss folgt nun noch die

Auflösung zu About Security #245

Beide Token entsprechen dem aus dem ersten Beispiel,

maxmus;admin;04.03.2010

Für das Token

6Q61786Q75733O61646Q696R3O30342R30332R32303130

wurde der String erst in Hexadezimalwerte umgewandelt und dann mit Rot-13 bearbeitet, das Token

7A6E6B7A68663B6E717A76613B30342E30332E32303130

wurde genau umgekehrt (erst Rot-13, dann Umwandlung in Hexadezimalwerte) kodiert.

Carsten Eilers

About Security - Übersicht zum aktuellen Thema:

• About Security #245: Schwachstellen-Suche: Session-Token
• About Security #246: Schwachstellen-Suche: Session-Token (2)