Viele Schwachstellen innerhalb einer Applikation sind das Ergebnis weit verbreiteter Programmierfehler. Um diesen Fehlern schon während der Entwicklung entgegenwirken zu können, veröffentlichte das SANS Institute gemeinsam mit der MITRE Corporation zu Beginn des Jahres eine Liste der “Top 25 der gefährlichsten Programmierfehler”.

In der ab morgen erhältlichen März-Ausgabe des iX-Magazin schreibe ich über die Veröffentlichung der “Top 25″, die Vor- und Nachteile derartiger Schwachstellen-Sammlungen und über die organisatorischen Rahmenbedingungen sicherer Programmierung.

Statische Quellcode-Analyse ist ein mächtiges Verfahren, um nach Schwachstellen im Sourcecode einer Applikation zu suchen, ohne diese auszuführen. Automatisierte Quellcode-Scanner unterstützen dabei durch die Verfolgung des Datenflusses und das Erkennen von Schwachstellen. Wo liegen die Möglichkeiten, wo die Grenzen dieser Werkzeuge?

In der ab morgen erhältlichen Ausgabe des iX-Magazin (02/2009) beschreibe ich die automatisierte Schwachstellen-Analyse von Quelltexten.

Eine Leseprobe ist hier erhältlich.

Since there is no vendor-patch available at the moment, every Openfire installation should be secured manually:
The simplest and most recommended solution is to deactivate access to the entire admin interface. This can for example be achieved by blocking the according ports (tcp/9090 & tcp/9091 by default) with a firewall. Subsequent communication to the admin interface can be done via SSL tunnels.

The sections below outline the most critical findings. Complete details could be extracted from the related advisory: AKADV2008-001-v1.0.

Bypass Authentication
Authentication to the Openfire admin interface is secured by a filter in the Tomcat application server. This filter guarantees that access to the admin interface is only granted to authenticated users. Otherwise they get redirected to a login page.
A design error in Openfire enables access to internal functions without the need for admin user credentials. The deployment descriptor (web.xml) configures some exclude values for the AuthCheckFilter.

When a request URL contains one of these Exclude-Strings the auth check mechanism can be totally circumvented. This was considered necessary for the initial setup process or the presence plugin.

Following POC demonstrates how an attacker could access internal functions by manipulating the URL providing one of these excludes(/setup/setup-/../../):

http://www.foo.bar:9090/setup/setup-/../../log.jsp?log=info&mode=asc&lines=All

SQL injection despite using Prepared Statements
In the meantime many developers have noted (or got obligated by secure coding guidelines) that the usage of prepared statements could prevent SQL injection. But in order to successfully prevent such attacks, prepared statements have to be used the right way.

During many static source code analyses which I conducted the last months, I was often confronted with the following problem: Strings were dynamically concatenated before there were passed to the prepared statement object. The proper set()-methods to bind the strings to the prepared statement were not used. In the scenario outlined sql injection is still possible despite using prepared statements.

The openfire case:

Untrusted user data enters the application
String type = ParamUtils.getParameter(request, "type");

A function processes this user input (SQLCondition) and constructs a SQL statement:
String sql = "SELECT * FROM sipPhoneLog";
sql = ... + " WHERE " + SQLCondition;

That statement is passed over to a prepared statement.
return con.prepareStatement(sql);

Schwachstellen in einer Webanwendung können die gesamte IT-Infrastruktur eines Unternehmens gefährden. Als wirkungsvolle Schutzkomponente haben sich sogenannte Web Application Firewalls etabliert.

In der seit heute erhältlichen Ausgabe des iX-Magazin (08/08) vergleiche ich zusammen mit meinem Kollegen Michael Dipper “Acht Web Application Firewalls”.

In einer anschließenden Live-Demo zeigte Marc genau dieses Problem auf: Neben einer Schwachstelle in der aktuellen JRE von Sun (1.5.10, 1.6.0) über die beliebiger Code zur Ausführung gebracht werden kann, entdeckte das eEye-Team auch eine Privilege Escalation Schwachstelle in Microsofts kürzlich auf den Markt gebrachtem Windows Vista.
Marc bootet Windows Vista (auf aktuellem Patch-Level) in einer virtuellen Maschine und surft darin mit dem Internet Explorer auf eine von ihm präpariete Seite, die einen Exploit in Form eines Java Applet enthält. Folgendes passiert: Rechts unten im Systemtray erscheint zunächst die Meldung, dass die Vista-Firewall deaktiviert wurde. Kurz darauf öffnet sich auf dem Angreifer-Rechner eine Reverse Shell, die Vollzugriff auf die Vista-Maschine erlaubt – Microsoft wurde bereits informiert – bis dafür jedoch ein Patch zur Verfügung steht und eEye-Security Details dieser Schwachstelle bekannt gibt, können erfahrungsgemäß noch Monate vergehen.

Die Techniken, die in dieser Demonstration verwendet wurden, sind alte Bekannte – faszinierend war viel mehr die Tatsache, dass so bald schon eine Privilege Escalation Schwachstelle in Microsofts neuem Betriebssystem gefunden wurde und der primäre Angriff auf die Java Runtime Environment abzielt (auch Sun wurde informiert, ein Patch steht noch aus).

Paradoxerweise stellte Dominik Langrehr gerade einen Tag zuvor Vista’s grundlegende Sicherheitsfunktionen und –verbesserungen in den Vordergrund

Dort ist diese Woche die IT-Defense – ein Sicherheitskongress mit international bekannten Referenten.

Besonders gespannt bin ich auf die Vorträge von Kevin Mitnick (weltweit bekannter Ex-Hacker und Social-Engineering-Experte) und Tobias Klein, der am Donnerstag seinen generischen Rootkit-Profiler zur Erkennung von Linux-Kernel-Rootkits vorstellen wird.

Aber: Heute Abend entspann ich erst mal im Pool und an der Hotelbar Bilder folgen…vielleicht!

Neben Fingerprinting der Datenbank und Brutefore-Angriffen auf den “sa”-Benutzer wird auch eine xp_cmdshell erstellt, falls diese gelöscht wurde. Zudem besteht die Möglichkeit automatisch Binärdateien (z.B. netcat) über HTTP-GET/POST-Methoden hochzuladen.

Eine sehr ausgefeilte Möglichkeit ist ein anschließender TCP/UDP-Portscan vom betroffenen Server aus, um einen Port in der Firewall zu entdecken über den eine Reverse Shell geöffnet werden kann. Alternativ bestehet auch die Möglichkeit eine “Pseudo-Shell” zu nutzen, die über DNS getunnelt wird.

• Live-Demo
• Homepage

Neben Möglichkeiten zur Umgehung einer Authentisierung, dem Ausspähen von sensitiven Daten und der Manipulation von Inhalten werden auch Ansätze zum Schutz vor SQL-Injection aufgezeigt.

Nachdem in den HL7-Versionen 2.X keine expliziten Sicherheitsmechanismen spezifiziert wurden, realisierte man in der Praxis verschlüsselte Kanäle auf Netzerk- bzw. Transportschicht (SSL, IPSec).
Neben einigen grundlegenen Neuerungen in der Version 3 des HL7-Standards beschreibe ich deshalb kurz ein paar Sicherheitsmechanismen auf Anwendungsebene. Grundsätzlich muss festgehalten werden, dass die Entwicklung in diesem Gebiet gegenwärtig noch in den Kinderschuhen steckt und abzuwarten ist, wie sich die Realisierung von Sicherheitsmechanismen auf Anwendungsebene entwickelt.

Nicht zuletzt auf Grund der empfohlenen Transportform über Webservices kommen mit großer Wahrscheintlichkeit langfristig auch Techniken wie XML-Signature und XML-Encryption zum Einsatz. Ob hier aber der HL7-Standard Vorgaben machen sollte, ist fragwürdig. Auf Grund der Dynamik von Entwicklungen in der Sicherheitsbranche, sollte von der genauen Festlegung zu verwendender Sicherheitsmechanismen weitestgehend abstrahiert werden.