In der iX 11/2007 erschien ein Artikel von uns, der sich mit dem Ausnutzen von Sicherheitslücken in Java-Anwendungen beschäftigte, die eine Scripting-Schnittstelle anbieten. Damals wurde das Vorgehen und die Auswirkungen am Kapern eines JDBC-Treibers vorgestellt. Hier präsentieren wir ein weiteres mögliches Vorgehen beim Angriff auf Java-Anwendungen mit Scripting-Schnittstelle.

Angriff über abgeleitete Klassen

Die Tatsache, daß sich Java-Interfaces durch fast beliebigen Script-Code implementieren lassen, legt natürlich die Frage nahe, ob das auch für die Ableitung neuer Klassen gilt und ob man damit eventuell ebensolchen Schaden verursachen kann, wie in unserem iX-Artikel mit der JDBC-Schnittstelle demonstriert. Für die Untersuchung dieser Frage haben wir uns auf das in der JavaVM oft benutzte Entwurfsmuster ServiceProvider konzentriert. Es taucht an verschiedenen Stellen auf - etwa beim unserem iX-Artikel untersuchten JDBC-Subsystem, den Socket-Factories oder auch beim Handling von Multimediainhalten. Wir untersuchen auch hier wieder die Erreichbarkeit des Minimal- und Maximalzieles:

Minimalziel

Der versuchte Angriff soll mindestens die
Anwendung so stören, dass der Anwender damit nicht mehr weiterarbeiten kann.

Maximalziel

Als Maximalziel gilt, eine eigene Komponente in die Anwendung einzuschleusen, ohne dass das dem Anwender im Betrieb auffällt.

Demonstration

Zur Demonstration der Durchführbarkeit eines Angriffes über gescriptete
Klassen wurde das ImageIO-Subsystem als Angriffsziel ausgewählt. Diese
Komponente bietet eine abstrakte Schnittstelle zum Laden und Speichern vom
Pixelbildern (JPG, PNG, GIF,...) und kann durch eigene Plugins um weitere
unterstützte Formate erweitert werden. Die Idee dabei ist, in ein Script Code
einzuschleusen, der ein bereits bestehendes Plugin zur Unterstützung des JPEG-Formats
aus dem System entfernt. Das entspricht dem Minimalziel - die korrekte Funktion der
Anwendung, die das Script einbindet zu stören. Statt dessen soll ein Plugin installiert
werden, das das Verhalten des
ursprünglich vorhandenen Plugins nachempfindet und gleichzeitig eine Schadroutine beinhaltet,
die bei jedem Laden eines JPEG-Bildes gestartet wird. Das würde der Erreichung des Maximalzieles
entsprechen.
Die Scripts ImageReaderSPI.bsh und ImageReaderSPI.groovy verdeutlichen die Herangehensweise für die Scriptsprachen
BeanShell und Groovy. Für beide Scriptsprachen liegt wiederum ein
Testprogramm bei, mit dem jeweils das Erreichen des Maximalzieles
verifiziert werden kann - im Beispiel natürlich nicht durch die Ausführung einer
wirklichen Schadroutine sondern durch die Ausgabe einer harmlosen Meldung
über System.out. Dazu laden die Beispielprogramme BeanShellImageReaderSPITester und GroovyImageReaderSPITester jeweils zwei Bilder und geben deren Dimensionen
in der Konsole aus. Vor dem Laden des zweiten Bildes wird jeweils ein Skript
ausgeführt, das versucht, den JPEG-ImageReader durch eine eigene Version auszutauschen.

Fazit

In sensiblen Anwendungsbereichen sollte man sich gut überlegen, ob man Java-Anwendungen mit Scripting-Schnittstellen ausstattet, die Anwender aber auf jeden Fall eindringlich auf die Gefahren der ungeprüften Benutzung von Scripten aus nicht vertrauenswürdigen Quellen warnen.