HTML5 aus Hackersicht
Kommentare

Hartnäckiger XSS-Wurmbefall
Ein weiteres Problem, das durch die Speicherung größerer Datenmengen auf dem Client und damit außerhalb des direkten Zugriffs der Webanwendung entsteht, stellt über Schwachstellen

Hartnäckiger XSS-Wurmbefall

Ein weiteres Problem, das durch die Speicherung größerer Datenmengen auf dem Client und damit außerhalb des direkten Zugriffs der Webanwendung entsteht, stellt über Schwachstellen in der Webanwendung eingeschleuster Schadcode dar.

Als Beispiel soll ein XSS-Wurm dienen. Was passiert, wenn sich ein solcher über eine Schwachstelle verbreitet? Ohne im Client gespeicherte Daten ist die Bereinigung des Systems sehr einfach. Nach dem Beheben der Schwachstelle kann der Wurm sich nicht mehr verbreiten. Dann muss „nur noch“ der eingeschleuste Wurmcode aus allen betroffenen Datenbankfeldern gelöscht werden, danach ist der Wurm restlos beseitig.

Werden Daten auch auf dem Client gespeichert, bleiben sie dort solange erhalten, bis der Benutzer sich wieder mit der Webanwendung verbindet und die Daten im Rahmen der normalen Nutzung bereinigt werden können. Das ist erst mal nicht besonders kritisch, wenn man an die bisherigen XSS-Würmer denkt, die sich auf die eigene Weiterverbreitung beschränkten.

Da die ausgenutzte Schwachstelle in der Webanwendung ja behoben wurde, kann der Wurm keinen Schaden mehr anrichten. Lediglich die Kontrolle aller vom Client gelieferten Daten auf bekannten Schadcode kann lästig werden, immerhin weiß man ja nicht wie lange es dauert, bis ein Benutzer sich wieder mit der Webanwendung verbindet und die betroffenen Daten auf dem Server erscheinen. Aber solange die Webanwendung nicht gleich dutzende Schwachstellen mit entsprechend vielen Wurmangriffen aufweist, kann man damit leben.

Auch aus Angreifersicht ist ein solcher Wurm im lokalen Speicher nicht besonders reizvoll. Aber wer sagt denn, dass ein XSS-Wurm nur eine einzige Funktion, seine Weiterverbreitung, erfüllt? Das war zwar bisher der Fall, aber nichts spricht dagegen, den XSS-Wurm um weitere Schadfunktionen, z. B. zum Ausspähen des Benutzers oder zur Vorbereitung von Drive-by-Infektionen [4] zu erweitern. Dieser zusätzliche Code würde dann bei der Offline-Nutzung der Anwendung Schaden anrichten, lange nachdem er auf dem Server schon gelöscht wurde.

Lokal gespeicherter Schadcode

Im Fall eines Wurms passiert das alles auch, ohne dass es vom Angreifer geplant wird. Aber der Local Storage kann auch gezielt vom Angreifer ausgenutzt werden, denn er bietet eine Möglichkeit, auch bösartigen JavaScript-Schadcode dauerhaft auf dem Client zu speichern.

Das für Penetrationstests eingesetzte Browser Exploitation Framework (BeEF) [5] dient dazu, ausgehend von einer XSS-Schwachstelle den Browser eines Benutzers zu übernehmen und von diesem aus weiter vorzustoßen. Es handelt sich also quasi um eine Hintertür im Browser. Sofern es nicht gelingt, weiteren Code auf dem Rechner des Opfers zu installieren, hat der Angreifer nur solange Zugriff auf den angegriffenen Rechner, wie dort der über XSS eingeschleuste JavaScript-Code läuft.

Kann der im Local Storage gespeichert werden, sodass er bei einem späteren Besuch der betroffenen Website wieder aktiv wird, erhält der Angreifer unabhängig von der XSS-Schwachstelle immer wieder seine Hintertür.

Artur Janc hat auf dem 28. Chaos Communication Congress (28C3) das Konzept eines Webanwendungs-Rootkits vorgestellt [6]. Der Angreifer verschafft sich dabei dauerhaften Zugriff auf eine Webanwendung, indem er seinen Code in deren Client einschleust und im Local Storage oder der SQL-Datenbank speichert. Den auf dem Client gespeicherten XSS-Code nennt Artur Janc „Resident XSS“. Diesem Schadcode kann das Opfer nur schwer entgehen, da er ein Schließen des Fensters oder das Ausloggen überlebt.

Der Angreifer hat dann vollständigen Zugriff auf alle in die Webanwendung eingegebenen sowie von der Webanwendung ausgegebenen Daten. Manipulationen durch den Schadcode, z. B. eine geänderte Ausgabe der Webanwendung, werden von der Webanwendung selbst nicht bemerkt, es gibt keinerlei Hinweise auf die Manipulationen in den Logfiles von Webserver oder -anwendung. Um möglichst lange im Browser aktiv zu bleiben, kann der Schadcode z. B. heimlich ein minimiertes Fenster im Hintergrund öffnen oder iframes in andere Tabs einschleusen.


Auf den kommenden Seiten erwarten euch…:

  • Cross-Origin Requests
  • Ein kleiner Abstecher: Clickjacking
  • Clickjacking the Like-Button = Likejacking
  • Clickjacking + HTML5 = Neue Angriffsmöglichkeiten
  • Ein praktischer Angriff: Cookiejacking
  • iframe: Sandkasten gegen JavaScript
  • Schöne neue Funktionen, schöne neue Möglichkeiten
  • Info zum Autor Carsten Eilers
  • Links und Literatur
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -