Erkennen von Kaskadierungen im Fingerprinting
Marc Ruef | 05.10.2009

Durch das Application Fingerprinting ist man bemüht, anhand des charakteristischen Verhaltens einer Netzwerkanwendung die individuelle Implementierung als solche zu identifizieren. Damit verlässt man Identifikationen anhand starrer Zeichenketten, wie sie zum Beispiel im Rahmen des Banner-Grabbings gesucht werden. Selbst wenn ein Banner gelöscht oder verändert wurde, liesse sich das genutzte Produkt anhand des Fingerprints erkennen.

Ein grundlegendes Problem sowohl von OS-Fingerprintnig als auch von Application Fingerprinting ist, dass Kaskadierungen bisher nicht berücksichtigt werden. Ein Webserver schickt sodann eine Response R an den Client zurück. Diese Antwort muss jedoch zuerst durch das Proxy-Element geschickt werden. Dieser weist eine Funktion F auf, die die Reponse untersucht und eventuell Änderungen vornimmt:

centerR' = F(R)/center

Zum Beispiel könnte im Rahmen einer HTTP-Kommunikation der Inhalt der Server-Zeile verändert oder eine Via-Zeile hinzugefügt werden. Diese neue Response R' wird an den Client geschickt. Das Fingerprinting muss nun mit den empfangenen Daten R' arbeiten, die nicht der Original-Response R der eigentlichen Quellkomponente entsprechen:

centerR != R'/center

Da die Fingerprint-Analyse die Kaskadierung nicht berücksichtigt, kann in der Regel keine 100 %ige Übereinstimmung erreicht werden. Ein ausgeklügeltes Fingerprinting wird zwar dennoch die anderen Aspekte berücksichtigen und eine relativ hohe Trefferquote ausweisen können (z.B. 97 %). Dafür verantwortlich ist zudem, dass nicht alle Proxy-Implementierungen gleich arbeiten. So kann es durchaus sein, dass zwei unterschiedliche Produkte/Versionen oder Installationen/Konfigurationen zwei gänzlich unterschiedliche Responses generieren:

center(R1 = F1(R)) != (R2 = F2(R))/center

Es stellt sich nun die Frage, ob und wie eine Kaskadierung erkannt werden kann und wie sich die überlappenden Charakteristiken den kaskadierten Elementen zuweisen lassen. Als erstes sollte das HTTP-Fingerprinting ausschliesslich "klare Fingerprints" (auch reine genannt), also solche ohne Proxy-Elemente, verwalten. Anhand dieser soll die Rückantwort untersucht werden. Die Trefferquote wird zwar nicht 100 % erreichen können, aber dennoch eine relativ solide Ableitung zulassen.

Bei dieser initialen Analyse sollten sämtliche Objekte der Prüfung markiert werden. Diese werden beim zweiten Durchlauf der Analyse nicht mehr berücksichtigt. In einem zweiten Schritt wird nämlich die Response mit der Charakteristik von Proxies verglichen. Je nach Einfluss dessen fördert entweder Phase 1 (Webserver-Analyse) oder Phase 2 (Proxy-Analyse) die genaueren Resultate zu Tage. Hierbei wird dem Prinzip der Mengenlehre gefolgt, wobei die einzelnen Fingerprint-Sets als Teilmengen oder Schnittmengen eingebracht werden.

In den meisten Fällen werden Proxies lediglich einige Header-Zeilen löschen oder hinzufügen. In diesem Fall kann die Kaskadierung relativ einfach erkannt und die individuellen Elemente den jeweiligen Komponenten zugewiesen werden. Problematischer wird es, wenn der Proxy sämtliche Header-Zeilen neu ordnet. Damit wird ein wichtiger Aspekt des HTTP-Fingerprints nicht mehr zugänglich. Die Unterscheidung zwischen einer komplett neuen Implementierung und einer applizierten Kaskadierung ist damit auf Anhieb nicht mehr möglich und nur durch spezifische Algorithmen lösbar.

Bisher gibt es keine Implementierung eines Tools für HTTP-Fingerprinting, welches eine derartige Kaskadierungs-Analyse anbietet. Entsprechend haben Proxies bisher immer eine negative Auswirkung auf die Genauigkeit der Identifikation. Im Rahmen des httprecon project (http://www.computec.ch/projekte/httprecon/) bin ich darum bemüht, die Software dahingehend zu erweitern, Kaskadierungen erkennen und die jeweiligen Eigenschaften den Elementen zuordnen zu können.