Der Zahn der Zeit
Marc Ruef | 27.07.2009

Im Juni des vergangenen Jahres habe ich einen Web Application Penetration Test bei einem grösseren Finanzinstut durchgeführt. Dabei sollte ich in einer der zentralen Webanwendungen Schwachstellen ausmachen, die Kunden nutzen könnten, um das Zielsystem oder andere Kunden (z.B. mittels Cross Site Scripting) zu attackieren. Das einzig Besondere am Auftrag war, dass es sich um eine sehr komplexe und schwerfällige Anwendung handeln sollte, die auf simple HTML-Forms verzichtet und stattdessen obskure Javascript-Anweisungen für die Übermittlung der Daten nutzt. Es schien, als wollten sich die Applikationsentwickler das Leben so schwer wie möglich machen (diesen Effekt beobachten wir in den letzten Jahren vermehrt).

Es kam wie es kommen musste und nach kompliziertem Herumgebastel des inkonsistenten und mit Mozilla Firefox teilweise inkompatiblen HTML-Codes konnte ich eine Reihe von kritischen Schwachstellen ausmachen. Halt die typischen Geschichten wie Cross Site Scripting und erweiterte Leserechte auf dem Webserver.

Wie gehabt dokumentierte ich die Findings in einem Report, der dem Kunden nach Abschluss der Prüfung bereitgestellt wurde. Die Gesamteinstufung der Lösung war aufgrund der Vielzahl gefundener Schwachstellen kritischen Ausmasses eher unterdurchschnittlich. Es bestand also unweigerlich Handlungsbedarf. Der Kunde sah dies entsprechend ein.

Das Entwicklerteam des Kunden war sodann um die Behebung der Fehler bemüht. Nach 3 Monaten, mittlerweile war September, kontaktierte mich der Kunde. Er bestellte einen sogenannten Re-Check. Bei diesem sollten die in der initial durchgeführten Analyse gefundenen Schwachstellen erneut geprüft werden. Da diese mittlerweile behoben sein sollten, sollten sie nicht mehr ausgemacht und ausgenutzt werden können. Damit lässt sich im Rahmen der Qualitätssicherung der endgültige Beweis antreten, dass die gewünschte Sicherheit des Produkts erreicht werden konnte.

Aufgrund eines sehr engen Zeitplans sah ich mich leider nicht in der Lage, diesen Re-Check selbst durchzuführen. Aus diesem Grund musste ein anderer Pentester aus meinem Team diese Aufgabe wahrnehmen. Wahrlich wurden die zuvor beanstandeten Fehler behoben und damit ein solider Stand in Bezug auf die Sicherheit erreicht. Eine Entwicklung, die wir natürlich sehr begrüssen, konnten wir nämlich dabei helfen, die Sicherheit des Kunden massgeblich zu verbessern.

Beim Re-Check konnte jedoch per Zufall eine neue Schwachstelle ausgemacht werden, die sich in speziellem Zusammenhang mit dem Internet Explorer ausnutzen liess. Normalerweise werden bei einem Re-Check wirklich nur die zuvor determinierten Schwachstellen re-validiert. Stösst man jedoch auf ein neues Problem, pflegen wir dieses ausserhalb des vordefinierten Rahmens dennoch zu melden. Quasi als freie Zusatzleistung, die unser Bemühen zur Wahrung und Erhöhung der Sicherheit unserer Kunden unterstreichen sollte.

Der Kunde reagierte jedoch nicht so, wie man das hätte erwarten können. Anstatt froh darüber zu sein, dass der Pentester ausserhalb des abgesteckten Rahmens agierte, beanstandete er die Qualität der initialen Prüfung. Die zentrale Frage war, wieso beim Re-Check ein neuer Fehler gefunden wurde, der bei der initialen Prüfung nicht ausgemacht werden konnte. Hatte ich beim ersten Test geschlampt?

Die Antwort lautet Nein. Die Begründung ist sehr einfach. Und zwar war der beim Re-Check als neu identifizierte Fehler erst im gleichen Monat (September) bekannt geworden. Dies bedeutet, dass er im initialen Test (Juni) noch gar nicht publiziert und mir bekannt war. Ein Fehler, der mir und anderen nicht bekannt ist, kann ich auch nicht finden. Da es sich um einen speziellen Fehler im Zusammenhang mit einem spezifischen Client handelt - dessen Relation zur Webapplikation nie zur Diskussion stand - konnte ich ihn auch gar nicht finden.

Leider vergessen viele Kunden, dass eine Sicherheitsüberprüfung stets eine Bestandesaufnahme ist. Die dabei gesammelten und ausgewerteten Daten entsprechen immer dem jeweiligen Zeitpunkt. Man kann als Pentester nur jene Informationen berücksichtigen, die von der Vergangenheit bis zur Gegenwart zugänglich sind. Informationen, wie sich eine Lösung in Zukunft verhalten wird, liegen nicht vor. Man kann zwar Mutmassungen anstellen, jedoch sind diese oftmals nicht gewünscht. Sicherheit ist ein Zustand, der sofort wieder verfallen kann (Tractatus 3.3.1.1 (http://www.computec.ch/projekte/tractatus/?s=tractatus&m=liste&h=3.3.1.1&l=6)). Für alles, was nach einem Test passiert, können wir keine Verantwortung übernehmen. Auch wenn wir dies gerne tun würden.