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”.

Den Text der Rede gibt es hier zum Download.

Eine Warnung an alle, die gerne mal etwas schneller unterwegs sind

An dieser Stelle nochmal vielen Dank, Simon, für die gute Beherbergung, Bewirtung und Unterhaltung

Rom ist eine Stadt für Fußgänger – nicht zuletzt weil ab 22:00 Uhr keine Metro mehr von der spanischen Treppe zum Hotel fährt. Das verlängerte Wochenende war natürlich eine reine Sightseeing-Tour, Pflichtprogramm waren: Piazza Venezia, Palazzo Venezia, Kapitol, Kaiserforen, Kolosseum, Domus Aurea, Palatin, Forum Romanum, Circus Maximus, Via del Corso, Pantheon, Piazza Navona, Piazza del Poplo, Villa Borghese (v.a. der Park, der sie umgibt), Fontane die Trevi, Piazza di Spagna, Engelsburg, Petersplatz, Papstgräber, Petersdom (und natürlich dessen Kuppel, mit einem einmaligen Ausblick über ganz Rom).

Übrigens wurde gerade dieses Wochenende das Kolosseum (zweites Foto) zu einem der wichtigsten Bauwerke der Welt auserkoren: Da unter den Denkmälern der ursprünglich aus der Antike übertragenen Liste der sieben Weltwunder nur noch die Pyramiden von Gizeh zu bewundern sind, wurde schon im Jahr 2000 eine Online-Abstimmung über die “New 7 Wonders Of The World” gestartet, deren Ergebnisse am 07.07.07 im Rahmen einer Gala in Lissabon bekannt gegeben wurden. Mehr Informationen dazu unter http://www.new7wonders.com.
(Die UNESCO als Verwaltung des Welterbes der Menschheit distanzierte sich von der Wahl, da sie keinen wissenschaftlichen Ansprüchen genüge).

Eine fertige Anleitung (”BackTrack Hard Drive Installation”, PDF) wird bereits von den Entwicklern der CD bereitgestellt und dient als Grundlage dieser Beschreibung.

Wurden die Partitionen wie in der o.g. Anleitung über fdisk angelegt und das Dateisystem darauf eingerichtet, kann anschließend mit der Installation begonnen werden. Wichtig ist, dass vor dem Start des “BackTrack Installers” die Partitionen wie folgt gemounted werden:


cd /tmp
mkdir boot
mkdir bt2
mount /dev/sda1 boot
mount /dev/sda3 bt2


Der Installer wird anschließend mit folgenden Optionen konfiguriert:

• Source (BackTrack-CD): /boot
• Install BackTrack to: /tmp/bt2
• Write MBR to: /dev/sda
• Installation method: Real

Nach Abschluss des Kopiervorgangs schreibt die offizielle Anleitung vor, die CD aus dem Laufwerk zu entnehmen und neu zu starten. Doch dann schon wenig später das böse Erwachen: Das eben in der virtuellen Maschine installierte BackTrack bootet nicht – warum?
Grund dafür ist, dass die Installationsroutine vergisst, den Linux-Kernel auf die Festplatte zu kopieren und den Bootloader in den MBR zu schreiben.
Vielen Dank für diesen Hinweis an meinen Kollegen Steffen Tröscher.

Das wird nun in wenigen Schritten nachgeholt.

Zunächst muss das Terminal geöffnet und darin folgende Schritte ausgeführt werden:


cp /boot/vmlinuz /tmp/bt2/boot/
cp /boot/splash.bmp /tmp/bt2/boot/
chroot /tmp/bt2/
lilo


Zur Erläuterung: Die ersten beiden Schritte kopieren den komprimierten Linux-Kernel wie er beim Booten geladen wird auf die Festplatte. Im zweiten Schritt muss sozusagen über chroot das Root-Verzeichnis des aktuellen Systems auf die frisch installierte Version geändert werden um darin den Bootloader (lilo) zu installieren.

Nach diesen Maßnahmen noch über den Befehl exit die Chroot-Umgebung verlassen und das eben installierte BackTrack das erste Mal in der virtuellen Maschine starten.

Installation der VMWare-Tools

Um die VMWare Tools in BackTrack 2 zu installieren, sind folgende Schritte notwendig.

1. Im VMWare Menü den Eintrag VM -> Install VMWare Tools wählen.
2. Anschließend den von VMWare virtuell als CD bereitgestellten Datenträger mounten: mount /mnt/hdc_cdrom
3. Nun die VMWare-Tools in das cd /tmp-Verzeichnis kopieren: cp /mnt/hdc_cdrom/VMWareTools*.tar.gz /tmp und dort entpacken: tar xvzf VMWareTools*.tar.gz
4. Für die reibungslose Installation der VMWare-Tools in BackTrack müssen nun noch einige Symlinks und Dummy-Dateien eingerichtet werden:

for x in 0 1 2 3 4 5 6
do
ln -s /etc/rc.d/ /etc/rc$x.d
done
touch /etc/init.d/network /etc/init.d/networking


Grundsätzlich könnte an dieser Stelle nun die Installation gestartet werden – wäre da nicht noch ein Problem Spätestens beim Versuch das Modul vmxnet (Netzwerktreiber für VMWare) zu kompilieren reagiert die Installation mit folgender Fehlermeldung:


Building the vmxnet module.
Using 2.6.x kernel build system.
make: Entering directory `/tmp/vmware-config1/vmxnet-only'
make -C /lib/modules/2.6.20-BT-PwnSauce-NOSMP/build/include/.. SUBDIRS=$PWD SRCR
OOT=$PWD/. modules
make[1]: Entering directory `/usr/src/linux-2.6.20'
CC [M] /tmp/vmware-config1/vmxnet-only/vmxnet.o
/tmp/vmware-config1/vmxnet-only/vmxnet.c: In function `vmxnet_netpoll':
/tmp/vmware-config1/vmxnet-only/vmxnet.c:1058: error: too many arguments to func
tion `vmxnet_interrupt'
make[2]: *** [/tmp/vmware-config1/vmxnet-only/vmxnet.o] Error 1
make[1]: *** [_module_/tmp/vmware-config1/vmxnet-only] Error 2
make[1]: Leaving directory `/usr/src/linux-2.6.20'
make: *** [vmxnet.ko] Error 2
make: Leaving directory `/tmp/vmware-config1/vmxnet-only'
Unable to build the vmxnet module.


Glücklicherweise wird gleich mitgeliefert, an welcher Stelle dieser Fehler seine Ursache hat:
vmxnet.c:1058: error: too many arguments to function `vmxnet_interrupt'

Kurze Analyse ergab folgendes Problem:

Zeilen 991 – 997 definieren die Methode vmxnet_interrupt wie folgt:

#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 19)
static compat_irqreturn_t
vmxnet_interrupt(int irq, void *dev_id, struct pt_regs * regs)
#else
static compat_irqreturn_t
vmxnet_interrupt(int irq, void *dev_id)
#endif


Eine Abfrage der Kernel-Version von BackTrack ergibt: 2.6.20-BT-PwnSauce-NOSMP - AHA! Die Kernelversionsnummer ist also nicht kleiner als 2.6.19 wodurch gemäß oben beschriebenem Quelltext die Methode vmxnet_interrupt mit zwei Parametern aufgerufen werden muss.
Ein Blick in die beim Kompilieren Fehler verursachende Zeile 1058 zeigt aber, dass hier diese Unterscheidung nicht mehr getroffen wird (davon auf jeden Fall betroffen sind VMware Workstation Versionen < = 5.5.4).

Zeile 1058:

vmxnet_interrupt(dev->irq, dev, NULL);