Sicherheitslücken: Fehler in der Browser-Logik
Auf der Konferenz Hack in the Box in Amsterdam(öffnet im neuen Fenster) hat der 18-jährige Webentwickler Bas Venis berichtet, wie er eine Reihe von Browser-Sicherheitslücken aufdeckte(öffnet im neuen Fenster). Venis nutzte dabei laut eigenen Angaben keine externen Tools und es handelte sich nicht wie sonst oft um komplexe Fehler in der Speicherverwaltung.
URL-Spoofing durch blockierende Javascript-Funktion
Zum Einstieg berichtete Venis über eine URL-Spoofing-Lücke, die er vor zwei Jahren im Chrome-Browser entdeckte. Versucht man, mittels Javascript ein neues Fenster mit einer URL auf einer fremden Domain zu öffnen und anschließend sofort in das Fenster zu schreiben, wird der Ladevorgang unterbrochen und die URL der Seite auf about:blank gesetzt. Bestimmte Javascript-Befehle, die ein Dialogfenster öffnen, unterbrechen jedoch diesen Vorgang. Allerdings überlagert dieses Dialogfenster, beispielsweise durch den alert()-Befehl, auch das neu geöffnete Fenster und verhindert die Interaktion des Nutzers mit der Seite.
Chrome hat jedoch eine Javascript-Funktion print(), die einen Druckdialog öffnet. Dieser blockiert ebenfalls die URL-Änderung, er überlagert jedoch ausschließlich das Fenster, aus dem er aufgerufen wird. Dadurch war es Venis möglich, mit wenigen Zeilen Javascript ein Fenster zu öffnen, das beispielsweise die URL https://www.google.com/ anzeigte, jedoch einen von ihm kontrollierten HTML-Code enthielt. Dass Venis mit so wenig Aufwand auf eine Sicherheitslücke stieß, motivierte ihn, weiter nach ähnlichen Lücken zu suchen.
Sandbox-Kontext von Flash
Die Sandbox des Flash-Plugins arbeitet in verschiedenen Kontexten, die dem laufenden Flash-Code bestimmte Rechte einräumen. Eine SWF-Datei auf dem lokalen Dateisystem darf dabei auf andere Dateien zugreifen, verschiedene Mechanismen sollen aber verhindern, dass Daten ins Netz übertragen werden. Zugriffe sind nur auf lokale URLs (file://) möglich, also auf andere Dateien auf dem Dateisystem.
Chrome konvertiert bei lokalen URL-Aufrufen alle mehrfachen Slashes und Backslashes zu einzelnen Slashes. Nicht umgewandelt werden aber Slashes und Backslashes, die mit einem Prozent-Zeichen codiert sind. Dadurch lassen sich mit URLs der Form file:///C:/Users/Bob/%5C%2F%5C%2Ftest.html Daten an eine andere lokale HTML-Datei übertragen. Von dort aus kann man dann diese Daten problemlos mittels Javascript weiterverarbeiten und ins Netz übertragen.
Slashes ermöglichen Datenextraktion
Mit diesem Trick, den Venis "Ex File Tration" nennt, lassen sich mittels einer lokalen Flash-Datei Daten aus einem System herausschleusen. Als Venis dieses Problem an das Google-Security-Team meldete, fragte ihn Google-Mitarbeiter Chris Evans, ob es auch möglich sei, diese Methode von einer Webseite aus auszunutzen. Evans verwies dabei auf einen möglichen Angriffsvektor hierfür: Links haben ein Attribut "download" mit einem optionalen Dateinamen, mit dem man den Browser anweisen kann, Dateien direkt herunterzuladen. Den Klick auf den Link kann man mittels Javascript simulieren. Damit gelang es Venis nun auch, diesen Exploit direkt von einer bösartigen Webseite aus auszuführen.
Mittels dieser Download-Links schaffte er es außerdem, Daten von externen Webseiten herunterzuladen und anschließend mit den oben beschriebenen Tricks an eine bösartige Webseite weiterzuleiten. Damit lässt sich dann beispielsweise der Inhalt einer Gmail-Mailbox zunächst lokal als Datei abspeichern und anschließend mittels des Flash-Sandbox-Tricks aus dem System herausschleusen.
Durch die Ausnutzung sogenannter Data-URLs konnte Venis es vermeiden, den Exploit über verschiedene Dateien zu verteilen. Mit diesen URLs der Form data:text/plain;charset=utf-8;base64,YWxlcnQoMSk= lassen sich in Webseiten Daten einbinden, die direkt in der URL codiert sind, sich aber wie eine Datei verhalten. Wie sich herausstellte, läuft ein Flash-Script, das als Data-URL codiert ist, im lokalen Kontext und kann auf das Dateisystem zugreifen.
Data-URLs sind nützlich für Angreifer
Doch die Data-URLs erwiesen sich noch in einem weiteren Fall als nützlich für Angreifer. Wenn man einen Iframe mittels einer Data-URL benutzte und darin wiederum ein Flash-Applet, ebenfalls als Data-URL, dann war die Sandbox-Funktionalität von Flash verwirrt. Das entsprechende Flash-Applet wurde im lokalen Kontext ausgeführt, erhielt also wieder Zugriff auf alle lokalen Dateien.
Dabei fand Venis gleich noch eine weitere Möglichkeit, Daten aus dem lokalen Kontext ins Netz zu senden: Fehlerhafte HTTP-URLs, in denen nur ein Slash genutzt wurde, zum Beispiel http:/www.google.com, korrigiert Chrome automatisch. Vom Flash-Plugin werden solche URLs jedoch als lokale Dateien behandelt.
Venis' Schlussfolgerung: Mehr Menschen sollten versuchen, mit etwas Kreativität nach ähnlichen Sicherheitslücken in Browsern zu suchen. "Ich bin überzeugt, dass jeder mit grundsätzlichen technischen Kenntnissen über den Web-Stack Sicherheitslücken wie diese finden könnte", schreibt Venis in einem Whitepaper, in dem er die Details zu allen Sicherheitslücken erläutert hat(öffnet im neuen Fenster).
- Anzeige Hier geht es zu Hacking & Security: Das umfassende Handbuch bei Amazon Wenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.