The Art of Fingerprinting
Marc Ruef | 19.01.2009

Im Bereich der Computersicherheit nimmt Fingerprinting eine wichtige Stellung ein. Durch verschiedene Techniken sollen eingesetzte Komponenten möglichst exakt ermittelt werden. Dies geschieht in der Regel, um deren charakteristisches Verhalten zum eigenen Vorteil einzuspannen. Spätestens beim Ausnutzen einer Schwachstelle eines Betriebssystems ist es beispielsweise unabdingbar zu wissen, ob nun Microsoft Windows Vista oder Debian GNU/Linux eingesetzt wird. Gutes Beispiel ist das Ausnutzen einer Directory Traversal-Schwachstelle, bei der das Verständnis für die Verzeichnisstruktur und die Eigenschaften des Dateisystems ein zentrales Element bildet. Zur Identifikation der Systeme wird OS-Fingerprinting (z.B. mittels der Option -O von nmap) verwendet.

Die letzten Jahre habe ich mich intensiver mit verschiedenen Bereichen des Fingerprintings, vorzugsweise der Identifikation von Server- und Client-Komponenten, auseinandergesetzt. Die in Projekten wie httprecon (http://www.computec.ch/projekte/httprecon/), browserrecon (http://www.computec.ch/projekte/browserrecon/) und telnetrecon (http://www.computec.ch/projekte/telnetrecon/) zusammengetragene Erfahrung bezüglich der Entwicklung entsprechender Herangehensweisen und Implementierungen will ich hier in ihren Grundzügen diskutieren.

Bei der Entwicklung eines Fingerprintings muss man sich zuerst darüber einigen werden, was man überhaupt untersuchen will. Das erstgenannte Beispiel des OS-Fingerprintings konzentriert sich auf die Erkennung des Betriebssystems, wohingegen sich httprecon und browserrecon mit Software-Komponenten auseinandersetzen. Bei httprecon wird dabei das Verhalten von Webservern, eine klassische Fingerprinting-Technik, angegangen. Dagegen wird bei browserrecon die client-seitige Analyse von Webbrowsern durchgesetzt. Applikationsbasiertes Fingerprinting von Netzwerkanwendungen konzentriert sich also auf eine spezifische Art von Anwendung und/oder Anwendungsprotokoll.

Hat man sich für ein solches entschieden, muss versucht werden, die Modularität der untersuchten Komponenten zu erkennen. Beim HTTP-Fingerprinting von Webserver-Implementierungen sind dies die Header-Zeilen, welche an den Client zurückgeschickt werden. Betrachtet man verschiedene Webserver im Detail, so fällt auf, dass jeweils unterschiedliche Header zurückgeschickt werden. So verzichten einige Implementierungen gänzlich auf gewisse Standardheader (z.B. Date) oder führen proprietäre Header ein (z.B. X-Powered-By). Die Existenz einzelner Header lässt also Rückschlüsse auf das eingesetzte Produkt zu.

Es gibt Anwendungstypen bzw. Produktfamilien, bei denen werden ständig die gleichen Informationen verwendet, wodurch ein solches Fingerprinting anhand von Existenz/Inexistenz nicht möglich ist. Sodann gilt es weitere charakteristische Details zu erkennen. Dies kann die Reihenfolge der ausgegebenen Informationen oder gar die übertragenen Nutzdaten sein. Im Fall des besagten HTTP-Fingerprinting kann zum Beispiel die zur Zeile ETag gelieferten Nutzdaten weiter untersucht werden. Dabei stellen sich Fragen wie, ob der ETag durch Quotes abgegrenzt wird (Ja/Nein), wie lang er ist (Integer) und welcher Zeichensatz verwendet wird (String). Je mehr Details untersucht werden können, desto eher lassen sich auch sehr ähnliche Implementierungen voneinander unterscheiden.

Bei passivem Fingerprinting ist man auf den durch Dritte generierten Datenverkehr, der zum Beispiel mit einem Sniffer mitgelesen wird, angewiesen. Für akkurate und unmittelbar steuerbare Auswertungen wird jedoch ein aktiver Ansatz gewählt, bei dem durch ein Reiz/Reaktion-Schema verräterische Verhaltensmuster provoziert werden. Dabei kann bei der Durchführung der Anfragen ebenfalls auf eine vielfältige Diversität gesetzt werden. Bei der Analyse eines Webservers bieten sich zum Beispiel verschiedene Anfrage-Methoden (GET, HEAD, POST, OPTIONS) an. Oder es werden explizit unbrauchbare Anfragen eingesetzt, um charakteristische Fehlermeldungen provozieren zu können (z.B. eine nicht existente HTTP-Methode oder die Angabe einer falschen Protokollversion).

Das Prinzip des soeben diskutierten HTTP-Fingerprinting kann ebenfalls auf andere Protokolle, natürlich unter Berücksichtigung ihrer individuellen Eigenschaften, übertragen werden. Zu Klartextprotokollen, die in ähnlicher Weise angegangen wurden, gehören zum Beispiel SMTP und FTP. Aber auch proprietäre und komplexere Protokolle wie die Ausgabe eines Oracle TNS-Listener oder NetBIOS/SMB können in derartiger Weise, meist nur mit marginal höherem Aufwand, untersucht werden. Das Verständnis für die eingesetzte Technologie und die charakteristischen Eigenschaften einzelner Implementierungen bleibt aber auch hier unabdingbar.

Je mehr Übereinstimmungen ein Fingerprinting generiert, desto eher ist die erwartete Implementierung identifiziert worden. Kann zum Beispiel durch browserrecon mit 17 Hits ein Mozilla Firefox ausgemacht werden und an zweiter Stelle findet sich mit nur 14 Hits die Angabe des Microsoft Internet Explorers, ist der Fall relativ klar. Die markanten Unterschiede der beiden Implementierungen führen dazu, dass es nicht zu Verwechslungen kommen kann.

Schwieriger wird es jedoch, wenn mit 17 Hits sowohl einmal Mozilla Firefox 3.0.5 und einmal Mozilla Firefox 3.0.1 ausgewiesen wird. Das Fingerprinting sieht sich scheinbar nicht in der Lage, die beiden Implementierungen aufgrund ihrer enormen Ähnlichkeit voneinander zu unterscheiden. Dies mag auf die fehlende Genauigkeit des Fingerprinting-Vorgangs selbst zurückzuführen sein (z.B. weil der entscheidende Unterschied nicht erkannt werden kann). In manchen Fällen ist es aber einfach nicht möglich, eine exakte Determinierung zu treffen, da die unterschiedlichen Produktversionen die gleichen einsetzen.

In solchen Fällen sollte der Prozess des automatisierten Fingerprintings als Hilfestellung verstanden werden. Bestmöglich werden die besten Übereinstimmungen aufgezeigt, so dass der Anwender des Tools entscheiden kann, welche der möglichen Resultate als richtig verstanden werden sollen. Zeigt httprecon zum Beispiel einen Apache-Webserver an, obschon auf diesem offensichtlich ASP.NET betrieben wird, kann dies getrost als False Positive gewertet und korrekterweise ein Microsoft IIS vermutet werden. Jedes Werkzeug braucht schlussendlich jemanden, der es richtig zu nutzen weiss.