Sicherheitslücke in SVG Images

Vor einigen Wochen wurden Johan und ich zur #dec0de Frontend-Usergroup Hamburg eingeladen, um etwas über das Thema SEO sowie den damit verbundenen Kommunikationsschwierigkeiten zwischen Entwicklern und Marketing Mitarbeitern Fuzzies zu referieren. Einer spannenden Diskussion folgte ein Vortrag der Frontend-Experten mit dem Titel OMGSVG. Für diejenigen, die nicht ganz so firm mit diesen verrückten Internet-Abkürzungen sind: OMG = Oh, my god. SVG = Scalable Vector Graphic. 

Da SVGs gefühlt eher geringe Verbreitung genießen (und vor allem noch nicht so häufig in der Google Bildersuche bzw. als Universal Search Integration auftauchen) waren meine Erfahrungen mit diesem mächtigen Bild-Vektorformat bislang eher Mau. Es lassen sich wirklich verdammt schicke Dinge damit anstellen wie zum Beispiel diese schicke Pfad-Animation hier. (wird übrigens so gemacht). Hätte ich mich früher damit beschäftigt und etwa diesen netten Grundlagenartikel über SVGs gelesen dann wäre mir die nachfolgende Erkenntnisse wohlmöglich schon früher gekommen.

In einem Nebensatz erwähnte Organisator Martin Schuhfuß dann eher Beiläufig, dass SVGs das embedden von Images erlaubt.

[blockquote indent=“yes“ ]Moment mal… ein Bild im Bild? Das ist ja krass…[/blockquote]

…dachte ich mir und schon fing die „kriminelle Energie“ in mir an zu brodeln. Glücklicher Weise kommt am Ende nur dieser Weltverbesserungs-Artikel hier und nichts Schlimmes dabei heraus.

Ein beliebiges Bild kann also in ein SVG embedded werden und das sogar von einer externen Ressource. Der Quellcode den es dazu im SVG braucht ist erschreckend simpel. Das z.B. mit Illustrator erstellte Image – in meinem Fall ein einfacher roter Kreis – wird einfach ergänzt durch diese Zeilen vor dem :

In meinem Beispiel wird dem schicken kleinen roten Kreis auf dieser Testseite ein transparentes 1×1 Pixel PNG vom externen Host http://test.wngmn.de angefügt. Nachdem dies schon funktionierte fing ich an weiter zu experimentieren und habe das embeddete Bild dann mit einer 301-Weiterleitung zunächst auf ein anderes Bild auf dem selben Server und dann auf ein Bild auf einem weiteren Server weitergeleitet. All dies funktionierte einwandfrei und so habe ich den Test wie folgt erweitert:


RewriteEngine On
RewriteBase /

RewriteRule ^pixel.png$ - [CO=testcookie:YouGotACookie:.wngmn.de:43200:/]
RewriteRule ^pixel.png$ dot.php [R=301,L]

Am Eintrag der .htaccess sehen wir, dass das Bild pixel.png per 301 auf die Datei dot.php weitergeleitet wird. Als wäre das noch nicht genug wird vor der Weiterleitung noch ein Cookie gedroppt. Wohl gemerkt nicht von florian-stelzner.de auf der mein schicker roter Kreis eingebunden war sondern von test.wngmn.de auf der pixel.png, dot.php und pixel2.png gehostet sind.

Die Sicherheitslücke droht dann im dot.php Script:

In meinem Beispiel habe ich ein Logfile mit Zeitstempel, IP-Adresse, Referer, User-Agent und Request-URI erstellt. Über jeden Aufruf des Bildes wurde ich zudem per Mail informiert bevor das Script dann final auf pixel2.png weiterleitet, um dem SVG das benötigte Bild für die korrekte Darstellung zu liefern.

Das Ergebnis sieht man in dieser Netzwerkanalyse recht schön:

Sicherheitslücke in SVG Images

In meinem Beispiel findet nur eine Weiterleitung über einen Host statt. Denkbar wäre auch eine Verkettung von mehreren Hosts, um beispielsweise noch mehr Cookies von unterschiedlichen Domains für Retargeting, Tracking und andere Dinge zu nutzen. Solange die Weiterleitungen zügig von statten gehen und die Scripte dazwischen nicht zu viel Bearbeitungszeit brauchen wird das dem Otto-Normal-Surfer wohl kaum auffallen.

Egal ob Chrome, Firefox, Safari oder Opera. Kein Browser war in der Lage diese Sicherheitslücke zu blockieren! Die einzige Grenze besteht darin, dass das SVG als Objekt oder Iframe im HTML Quellcode eingebunden werden musste oder direkt im Browser geöffnet werden musste. Da die meisten Websites SVGs mit dem IMG-Tag einbinden lindert das zwar etwas den Schmerz jedoch liegt der große Vorteil von SVG Images ja in der Skalierbarkeit, welche gerne durch den Einsatz von Lightboxen zur Vergrößerung eingesetzt werden. In diesem Fall wird das das SVG direkt aufgerufen und *pling* schon habe ich Post. Natürlich hätte man das selbe Ergebnis auch mit einem iFrame oder der direkten Einbindung des 1×1 Pixels erzeugen können. Das gemeine ist ja aber das Versteckspiel an dieser Stelle. Man stelle sich nur mal vor man lässt sich bei Fiverr für 5$ ein Icon-Set erstellen, infiziert dieses und bringt es kostenfrei in den Umlauf. 

Mein Appell an die Damen und Herren der Browser Hersteller: tut was, denn sonst wird es bald bei Wikipedia, in zahlreichen Foren, Icon-Galleries und sonstigen Seiten von diesen manipuliertes SVGs wimmeln und sei es „nur“ um den Aufruf der Datei zu tracken. Als nächstes Teste ich übrigens mal was mit Javascript in SVGs so zu machen ist…


Verlinkt von

[…] in SVG-Bildern: Florian Stelzner von den Wingmen schreibt, dass man Bilder in SVG Images (Scalable Vector Graphic) einbetten kann – inklusive externer […]

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.