Das Cookie ist mächtiger als das Schwert
Marc Ruef | 20.04.2009

Unsere Firma (http://www.scip.ch) bietet verschiedene Module an, anhand derer wir die Sicherheit von Produkten, Lösungen und Installationen untersuchen können. Klassischerweise wird zum Beispiel ein Penetration Test auf eine Webapplikation durchgeführt, um typische Schwachstellen wie Cross Site Scripting und SQL-Injection ausfindig zu machen.

Aufgrund verschiedener Automatismen sind wir ebenfalls besonders stark darin, wenn es um sogenannte Config Reviews geht. Sodann erhalten wir die Konfiguration eines Systems, Dienstes oder einer Applikation, die auf etwaige Schwächen hin untersucht werden soll. Der Grundlegende Ablauf gestaltet sich dabei stets gleich. Als erstes wird anhand des Handbuchs, durch Interviews mit Administratoren/Entwicklern oder einer allgemeinen Quelltext-Analyse die Funktionsweise und Möglichkeiten des Produkts angeschaut. Damit kann herausgefunden werden, welche Funktionen und Einstellungen dargeboten werden.

In einem zweiten Schritt werden zu sämtlichen Möglichkeiten unsere generischen Wunschvorstellungen festgehalten. Unterstützt ein Webserver zum Beispiel SSL und wird das dedizierte Aktivieren unterschiedlicher Versionen angeboten, so sprechen wir uns für TLS/SSLv3 und gegen SSLv2 als empfohlene Einstellung aus.

Im dritten Schritt werden die applizierten Einstellungen mit unseren Wünschen verglichen. Jegliche Abweichung muss untersucht und spezifisch bewertet werden. Wird denn nun in einer Konfiguration die Generierung von Zufallszahlen mit /dev/urandom vorgesehen, äussern wir unsere Bedenken bezüglich der echten Zufälligkeit dieser Methode. Jenachdem wird ein solcher Punkt mit Low oder gar Medium (in Hochsicherheitsumgebungen) bewertet.

Mögliche und empfohlene Massnahmen werden dokumentiert, damit der Kunde eine Optimierung anstreben kann (z.B. Nutzung von /dev/random oder gar Einsatz eines echten Zufallszahlengenerators auf Hardwarebasis). Es bleibt sodann im Rahmen der klassischen Risikokalkulation dem Kunden überlassen, ob er das durch uns eruierte Risiko akzeptieren oder minimieren will. In jedem Fall muss man sich dessen bewusst sein und mit ihm umgehen können.

Vor einiger Zeit habe ich eine Config Review eines Reverse-Proxies - eine Eigenentwicklung einer Schweizer Firma -  durchgeführt. Dieser sollte im Rahmen meines Auftrags mehrere Hundert Applikationen eines weltweit agierenden Finanzunternehmens schützen. Jeglicher Zugriff aus dem Internet oder Intranet wurde über diese Komponente geschleust, um den traditionellen Common Point of Trust gewährleisten zu können. Dabei wurden beispielsweise die Grösse von POST-Anfragen (maximal 12 MByte), die Prüfung von Formularfeldern (keine Buchstaben in form.postleitzahl) oder das Verbieten unerwünschter HTTP-Methoden (kein OPTIONS und kein PUT) durchgesetzt.

Mitunter sah das Produkt auf der Basis von Apache eine spezielle Funktion vor. Und zwar liess sich über eine ausgewählte Direktive bestimmen, wie sich das Regelwerk verhalten sollte, sollte der Benutzer mit einem definierten Cookie daherkommen. Zu meinem Erstaunen musste ich feststellen, dass gewisse "Debug-Cookies" vorgesehen waren, bei deren Nutzung sämtliche Sicherheitsfunktionen auf dem Proxy für diesen Benutzer temporär umgangen wurden.

Dies ist natürlich ein kritisches Problem, das wir mindestens als High einstufen sollten. Schliesslich ist es einem Endanwender möglich, durch das simple Setzen eines Cookies die durch das Unternehmen auferlegte Sicherheitsrichtlinie zu umgehen. Mit dem Web Developer Plugin (https://addons.mozilla.org/en-US/firefox/addon/60) für Mozilla Firefox ist dies eine Sache von 3 Klicks. Die Mächtigkeit des Proxy-Elements wird damit gänzlich untergraben und die Sicherheit kann dadurch nicht mehr gewährleistet werden.

Die Entwickler und Administratoren argumentieren in diesen Fällen gerne, dass ein solches Debug-Cookie ja geheim sei (wie ein Passwort) und lediglich durch priviligierte Benutzer eingebracht werden sollte. Doch dies ist das klassische Problem der Security By Obscurity, denn spätestens beim Bekanntwerden des Cookie-Namens muss mit Missbräuchen gerechnet werden. Bei mehreren Hundert Mitarbeitern in der IT-Abteilung, die von diesem Cookie wissen, wird wohl mit an 100 % grenzender Wahrscheinlichkeit irgendjemand - wenn auch erst nach seinem Weggang - einer Drittperson von dieser Hintertür erzählen. Eine virale Verbreitung dieser Information ist möglich, ja gar absehbar. Kann das Security-Team dann noch schnell genug reagieren, um das Cookie-Feature abzuschalten oder einen neuen "geheimen" Cookie-Namen zu vergeben?