Dipl.-Inform. Carsten Eilers

JavaScript-basierte Portscans in lokalen Netz sind ein alter Hut. Ich würde jetzt gerne die im Herbst 2007 veröffentlichten entsprechenden Folgen von About Security hier verlinken, aber die sind zur Zeit leider offline.

Vereinfacht ausgedrückt, funktionierte der Portscan mit JavaScript bisher so: Es wird ein Timer gestartet und dann versucht, ein bestimmtes Bild vom vermuteten Server zu laden. Dafür bieten sich zum Beispiel die Default-Icons der Webserver an. Je nachdem, ob das Bild geladen werden kann und/oder der Time ausgelöst wird, kann man auf das Vorhandensein bzw. Nichtvorhandensein des zugehörigen Servers schließen. Und wenn das Default-Icon geladen wurde, weiß man auch gleich noch, das und was für ein Webserver auf dem Server läuft.

Mit HTML5 haben wir Cross Origin Requests und WebSockets, und damit lässt sich der Portscan weiter vereinfachen. Wie das funktioniert, haben die Attack and Defense Labs beschrieben. Übrigens auch schon 2010, in der IT also vielleicht nicht vor einer halben, aber doch vor einer viertel Ewigkeit. Das von den Attack and Defense Labs entwickelte Tool JS-Recon nutzt die readystate-Statuswerte der CORs und WebSockets, um Rechner im lokalen Netz zu erkennen. Das funktioniert vereinfacht folgendermaßen:

• Der readystate wird auf den Default-Wert gesetzt.
• Ein Timer wird gestartet.
• Ein Cross-Origin- oder WebSocket-Request wird an den vermuteten Rechner geschickt.
• Es wird auf die Änderung des readystate-Werts gewartet.
• Die Zeit bis zur Änderung des readystate-Werts verrät, ob der kontaktierte Port offen, geschlossen oder gefiltert ist und damit, ob der vermutete Rechner existiert (Port ist offen oder geschlossen) oder nicht (Port ist "gefiltert").

Dabei gibt es einige Einschränkungen zu beachten, zum Beispiel erfolgt der Portscan auf Anwendungsebene und das Ergebnis ist damit von der am getesteten Port lauschenden Anwendung abhängig. Außerdem sind keine Verbindungen zu den "Well known Ports" möglich, da diese von den Browsern gefiltert werden. Zumindest WebSocket-Verbindungen sind laut Standard aber auch zu Port 80 (HTTP) und 443 (HTTPS) möglich, und damit lassen sich wunderbar Webserver im lokalen Netz erkennen.

Um in einem lokalen Netz nach anderen Rechnern zu suchen, müssen nun nur die möglichen IP-Adressen durchgegangen und für jede IP-Adresse nach einem Port gesucht werden. Dass das Ganze funktioniert, können Sie an der von den Attack and Defense Labs entwickelten Proof of Concept JS-Recon ausprobieren. Das funktioniert unter Windows mit Firefox, Chrome und Safari und unter Mac OS X zumindest mit Safari, auch wenn auf der Website "Currently works on WINDOWS ONLY." steht. Wahrscheinlich hat der Code gar nicht bemerkt, dass er auf einem Mac lief.

Nachdem weitere Rechner im lokalen Netz gefunden wurden, können die über den zuerst kompromittierten Webbrowser angegriffen werden. Wie wäre es zum Beispiel mit einem Angriff auf den SOHO-Router, der das lokale Netz mit dem Internet verbindet?

Angriffe auf SOHO-Router

Auf der Sicherheitskonferenz Black Hat USA 2012 haben Phil Purviance und Joshua Brashars beschrieben, wie ein Angreifer aus dem Browser heraus die Firmware von SOHO-Routern manipulieren kann.

Sie kombinieren dafür bereits seit langem bekannte Angriffe mit den neuen Möglichkeiten von HTML5. Zuerst wird mit einem JavaScript-basierten Portscan nach dem Router gesucht, der anhand Gerätespezifischer Ressourcen, zum Beispiel Logo-Grafiken oder bestimmten Skripten, identifiziert werden kann.

Auf viele SOHO-Router ist der Zugriff mit Default-Zugangsdaten möglich, aber auch wenn der Router durch ein individuelles Passwort geschützt ist, ist der Angriff noch nicht am Ende: Zum einen kann die Authentifizierung mittels Cross-Site Request Forgery unterlaufen werden, zum anderen sind Brute-Force-Angriffe auf die Authentifizierung möglich.

Nachdem der Angreifer sich Zugriff auf den Router verschafft hat, kann er über einen "Cross- Origin Remote-File Upload" eine manipulierte Firmware auf den Router installieren. Darüber kann der Angreifer dann beispielsweise als Man-in-the-Middle den gesamten Internetverkehr des lokalen Netzes überwachen und manipulieren.

Beim Cross-Origin Remote-File Upload wird zuerst über einen XMLHttpRequest die präparierte Firmware vom Server des Angreifers geholt. Nachdem sie in einer Variablen zwischengespeichert wurde, kann sie über einen weiteren XMLHttpRequest an den Router geschickt werden.

Schwierige Abwehr

Das ist natürlich äußerst unschön. Und das Schlimmste: Sie selbst können als potentielles Opfer außer dem Setzen eines sicheren Passworts für den Router nichts dagegen tun. Für alle anderen Schutzmaßnahmen sind andere zuständig:

Alle Webentwickler müssen dafür sorgen, dass ihre Anwendungen keine XSS-Schwachstellen enthalten, über die ihre Benutzer angegriffen werden können. Aber selbst dann könnten die Angreifer ihre Opfer noch per Social Engineering auf ihre eigenen, präparierten Seiten locken.

Die Router-Hersteller müssen ihre Router vor entsprechenden Angriffen schützen. Die Weboberflächen der Router müssen mit einem CSRF-Schutz versehen werden, Brute-Force-Angriffe müssen abwehrt werden, und das Setzen eines Passworts sollte erzwungen werden. Auch eine sichere und zuverlässige Möglichkeit zur Verteilung von Firmware-Updates, evtl. auch automatisiert, wäre sicher eine gute Idee.

Und auch die Browser-Hersteller könnten für mehr Sicherheit sorgen: Das Cross-Origin Resource Sharing sollte restriktiver gehandhabt werden, zum Beispiel indem aus dem Internet geladenem Code der Zugriff auf lokale Adressen verboten wird.

In der nächsten Folge werden zum Abschluss des Themas "HTML5 Security" noch weitere Angriffe beschrieben.

Carsten Eilers

---

Übersicht über alle Artikel zum Thema

HTML5 Security - Eine Einführung

HTML5 Security - SVG und Resident XSS

HTML5 Security - Formulare auf Abwegen

HTML5 Security - Gift für den Application Cache

HTML5 Security - Der Local Storage

HTML5 Security - Die SQL-Datenbank

HTML5 Security - Cross Origin Requests

HTML5 Security - Gefährliche WebSockets

HTML5 Security - postMessage() sicher nutzen

HTML5 Security - Angriffe im lokalen Netz