Bevor Session-Token analysiert werden können, müssen sie erst einmal gefunden und gesammelt werden. Außerdem muss eine Möglichkeit gefunden werden, selbst erstellte Token zu testen.

Gründliche Vorbereitung zahlt sich aus

Bereits bei der Analyse der Webanwendung (siehe About Security #144 ff.) wurden die Seite der Webanwendung ermittelt, auf denen sich die Benutzer anmelden müssen, um auf weitere Seiten zu gelangen. Für die Vergabe neuer Session-Token gibt es dabei im wesentlichen zwei Möglichkeiten: Entweder, die Webanwendung erzeugt jedes Mal ein neues Token, wenn sie ohne vorhandenes Token aufgerufen wird, oder sie erzeugt ein neues Token nach der erfolgreichen Authentifizierung eines Benutzers. Da für die Analyse der Token eine große Anzahl davon benötigt wird, wird nach Möglichkeit ein einzelner Request gesucht, der bei jedem Aufruf ein neues Token zurück liefert. Im ersten Fall reicht dazu idealerweise ein "GET /", im zweiten das Senden gültiger Zugangsdaten. Allerdings gibt es im zweiten Fall viele Webanwendungen, die erst eine neue Session anlegen, nachdem die vorhandene abgelaufen ist oder beendet wurde. In dem Fall sind für das Sammeln von Token mindestens 2 Requests notwendig: Erst einer zum Abmelden, dann ein zweiter zum Anmelden, ggf. mit einer Bestätigung dazwischen. Das scheint beim automatisierten Sammeln der Token eigentlich egal zu sein, ergibt aber u.U. unterschiedliche Ergebnisse: Während bei einer Folge von "GET /"-Requests mit ziemlich hoher Wahrscheinlichkeit aufeinander folgende Token gesammelt werden, steigt beim Senden mehrerer Requests die Wahrscheinlichkeit dafür, dass zwischen zwei erhaltenen Token ein weiteres erzeugt und an einen anderen Benutzer vergeben worden ist.

Proben sammeln

Mit den ermittelten Requests werden dann in so kurzer Zeit wie möglich sehr viele Token gesammelt, mindestens einige Hundert. Dazu kann ein selbst geschriebenes Skript oder ein vorhandenes Tool wie z.B. der Burp Intruder (in der kostenpflichtigen Version) verwendet werden.

Muster suchen - zuerst automatisiert

Danach muss in den gesammelten Token nach Mustern gesucht werden. Es gibt auch Tools zur Analyse von Session-Token, die dabei zumindest helfen können, auch wenn sie evtl. kein zufriedenstellendes Ergebnis liefern. Ein solches Tool ist z.B. WebScarab vom Open Web Application Security Project (OWASP), das Session-Identifier aus Cookies oder Webseiten sammeln und auf Vorhersagbarkeit testen kann und die gesammelten Werte und Informationen zur Weiterverarbeitung auch ausgibt. Die grafische Darstellung kann dabei aber in die Irre führen, nur weil etwas auf dem Bildschirm wie ein Muster aussieht, muss es noch lange nicht nach einem erzeugt worden sein.

Jetzt kommt die Handarbeit

Sofern die automatische Analyse nicht bereits ein Muster ergeben hat, müssen die Token manuell analysiert werden. Dafür gibt es keinen festen Algorithmus o.Ä. (sonst gäbe es längst Programme, die das ganze viel effektiver erledigen könnten als ein Mensch), sondern nur eine Reihe von Anhaltspunkten:

• Wird nur ein Teil des Tokens von der Webanwendung ausgewertet (siehe About Security #245), wird nur dieser Teil genauer untersucht. Auch dann, wenn sich auch die nicht ausgewerteten Teile des Tokens verändern, das könnte z.B. der Tarnung dienen oder in einem anderen Kontext eine Bedeutung haben, der jetzt (noch) nicht interessiert.
• Ist nicht klar, um was für einen Datentyp es sich handelt, werden die Token auf verschiedene Weisen dekodiert - evtl. ergibt sich danach schon ein ganz anderes Bild (siehe About Security #245).
• Gibt es irgend welche Muster in den Token, z.B. Sequenzen, die sich gleichmäßig ändern? Wie verhalten sich die Differenzen aufeinander folgender Token bzw. erkannter Sequenzen aufeinander folgender Token?
• Um zeitabhängige Werte zu erkennen, wird die Sammlung und automatisierte Analyse nach einer gewissen Zeit wiederholt. Ergeben sich beim Vergleich der beiden Token-Reihen Muster?

Schwache Zufallsgeneratoren

Schwache Zufallsgeneratoren erkennt man z.B. mit Hilfe statistischer Methoden, darauf wird in einer zukünftigen Folge von About Security eingegangen, in der dann (Pseudo-)Zufallsgeneratoren allgemein beschrieben werden. Gibt es im verwendeten System/Webserver/... eine bekannte Schwachstelle, muss der Zusammenhang zwischen den Zufallszahlen und den Session-Token ermittelt werden (sofern diese nicht einfach übernommen werden), bevor mit einem Tool erzeugte Zufallszahlen zum Fälschen der Token verwendet werden können.

Gegenprobe

Wurde ein mögliches Muster erkannt, muss es überprüft werden. Dazu werden Daten von einer anderen IP-Adresse und/oder mit einem anderen Benutzernamen gesammelt: Wiederholt sich das Muster? Wenn ja: Lassen sich aus den zuerst gesammelten Token die danach gesammelten extrapolieren? Unter Umständen liefert die Analyse von einem Client aus ein Muster, das sich von einem anderen Client aus nicht bestätigen lässt, weil die IP-Adresse in die Token-Erzeugung einbezogen wird, z.B. als Startwert eines Pseudo-Zufallszahlengenerators o.Ä.

Zum Schluss: Ein Test

Wurde ein gefundenes Muster bestätigt, müssen Token vorhergesagt und getestet werden. Dazu wird eine Reihe von möglichen Token erzeugt und an eine Seite der Webanwendung geschickt, die nur mit gültigen Token zugänglich ist. Ist der Zugriff möglich? Im Erfolgsfall kann ein Angreifer nun Aktionen als angemeldeter Benutzer ausführen, ohne sich authentifizieren zu müssen.

Damit ist die Untersuchung von Session-Token und ähnlichen Werten abgeschlossen. Diese Verfahren können analog z.B. bei der Untersuchung der von der Webanwendung erzeugten Passwörter angewendet werden. In der nächsten Folge gibt es eine Übersicht über die notwendigen Schritte bei der Schwachstellensuche in Webanwendungen.

Carsten Eilers

About Security - Übersicht zum aktuellen Thema:

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