März 2009 Archive

Abstact:
This paper discusses the automatic enumeration and fingerprinting of web applications. In this case, the popular WordPress blogging software was usedas an example to gain insight about the patch levels in "casual" environments.

Deprecated versions of WordPress are known to include several critical vulnerabilities, which make them an easy target to compromise systems in order to perform browser-based exploitation on their visitors or use the underlying infrastructure for several malicious purposes, for example sending spam or hosting malware.

In the first part of the paper, the technical solution to identify installations of the target application using openly available technology is being discussed. Further, the basic method of fingerprinting different versions of WordPress
(1.2 up to 2.7.1) are being illustrated.

In the second part of this document, some analysis of a enumeration scenario can be found. The scenario includes the enumeration, fingerprinting and analysis of thousand blogs powered by WordPress in Switzerland and Liechtenstein of which 60 per cent were found to be deprecated and partly prone to certain well-known security vulnerabilities.

Sprache: Englisch
Download: PDF, 450kb

Nächste Woche findet die erste Ausgabe des scip )talk( im Jahr 2009 statt. Wie auch schon in 2008, werde ich ein technisches Segment präsentieren - und wie gehabt gibt es daher im Vorfeld schon ein paar Informationen zum besprochenen Thema.

Taming a Beast with a Thousand Heads: Configuration Management

Wir propagieren grundsätzlich sehr oft eine transparente Herangehensweise für Sicherheitsüberprüfungen. Gerade in komplexen Umgebungen macht es oftmals schlicht und ergreifend keinen Sinn, in einem sehr limitierten Zeitrahmen die oft zitierte Nadel im Heuhaufen - in diesem Fall eine kritische Schwachstelle - zu suchen.

Wenn Umgebungen periodisch geprüft werden, so wird ab einem gewissen Punkt gerne auf Konfigurationsanalysen zurückgegriffen. Die populärsten Form ist dabei die Analyse von Firewall Regelwerken, aber auch die Einstellungen artverwandter Gerätschaften, wie zum Beispiel Reverse Proxies, werden gerne auf diese Art und Weise untersucht.

Das Ziel einer Konfigurationsanalyse ist relativ simpel: Es werden Einstellungen gesucht, die eine negative Implikation auf die Sicherheit des Systems besitzen. Diese werden anschliessend bewertet (Kritikalität, Wahrscheinlichkeit, etc.) und mit Gegenmassnahmen versehen dokumentiert. Ein Beispiel wäre im Fall eines Apache Servers die Zeile:

SSLProtocol ALL

Diese Direktive würde bemängelt werden, weil sie SSLv2 unterstützt, was aus verschiedenen Gründen unerwünscht ist. Es würde daher empfohlen werden, die Zeile dahingehend zu modifizieren, dass SSLv2 nicht mehr erlaubt wird:

SSLProtocol ALL -SSLv2

Es würde als weitere Massnahme vorgeschlagen werden, dass eine themenverwandte Direktive eingesetzt werden sollte, um einen bestimmten Effekt, zu erreichen. In diesem Fall würde empfohlen werden, nur als kryptografisch sicher geltende Algorithmen zuzulassen. Dies entspricht der Konfiguration, die benötigt wird um PCI Compliance zu erreichen:

SSLCipherSuite HIGH:!SSLv2:!ADH:!aNULL:!eNULL:!NULL

In einem kompakten, klar abgesteckten Kontext, ist eine solche Analyse relativ simpel: Meistens ist höchstens eine handvoll Dateien mit ein paar Dutzend sicherheitsrelevanten Direktiven zu betrachten.

Interessant wird es aber, wenn plötzlich mehrere hundert Systemkonfigurationen mit tausenden (!) Konfigurationsdirektiven eines Dienstes normalisiert, analysiert und untereinander nach verschiedenen Kriterien verglichen werden sollen. Wie eine solche Analyse realisiert werden kann und was dabei beachtet werden muss, ist eines der weitergehenden Themen, auf das ich im )talk( eingehen werde.

scip )talk( 01/09
18. März 2009, Zurich
Invite Only (www.scip.ch)