Skip to content

Filet-o-Firewall - ein neuer browserbasierter Angriff auf die Firewall

Jetzt habe ich gestern doch glatt vergessen, den Text online zu stellen. :-( Also mit kurzer Verzögerung:

Wie angekündigt geht es ab dieser Folge erst mal wieder um aktuellere Themen. Den Anfang machen Schwachstellen in und Angriffe auf (SOHO-)Router. Los geht es mit einem alten Bekannten: Es gibt mal wieder ein Problem mit UPnP.

Der von seinem Entdecker Grant Harrelson "Filet-o-Firewall" genannte Angriff kombiniert mehrere Schwachstellen und Angriffe, um über eine präparierte Webseite aus dem Browser (Chrome oder Firefox) heraus UPnP-Requests an die Firewall zu schicken und dort den Zugriff von außen auf alle Geräte im lokalen Netz freizuschalten.

Filet-o-Firewall im Überblick

Die Firewall dient bekanntlich dazu, die unbefugte Kommunikation mit dem Internet zu verhindern. Die meisten SOHO-Router verwenden Network Address Translation (NAT) zur Umsetzung lokaler IP-Adressen in die öffentliche Internet-Adresse des Routers und dienen parallel als Firewall, die unbefugte Anfragen aus dem Internet an lokale Geräte hinter dem Router verhindert.

Filet-o-Firewall erlaubt es einem Angreifer, die Geräte hinter der Firewall von außen zugänglich zu machen. Dazu wird über UPnP für diese Geräte ein Port in der Firewall geöffnet. Dafür reicht es, dass ein Benutzer eine präparierte Webseite mit einem betroffenen Browser und eingeschalteten JavaScript aufruft. Da sowohl Chrome als auch Firefox betroffen sind, ist das erste gar nicht mal so unwahrscheinlich. Und was das zweite betrifft: JavaScript ja ja sowieso fast immer eingeschaltet.

Filet-o-Firewall im Detail

Die Schwachstelle besteht aus einem Implementierungsfehler (Grant Harrelson nennt es Logikfehler, aber ich sehe da keine Zusammenhang mit irgend einer Logik, und eigentlich sollte der Fehler in aktuellen Implementierungen nicht mehr vorkommen) in manchen Routern.

Für den Angriff muss der Angreifer zum einen mit der Firewall auf dem für UPnP-Requests verwendeten Port kommunizieren und zum anderen dabei die korrekte URL für die Requests verwenden. Der UPnP-Port lässt sich über einen Portscan ermitteln und ist aus dem Browser erreichbar, und die URL lässt sich bei vielen Routern ebenfalls herausfinden. Und darin besteht auch schon die Schwachstelle - wären UPnP-Port und URL nicht ermittelbar, wäre der Angriff nicht möglich.

Für den Angriff müssen dann noch mehrere bereits bekannte Angriffe kombiniert werden. Benötigt werden

Nachdem der Benutzer die präparierte Webseite aufgerufen hat läuft der gesamte Angriff dann so ab:

  1. Über WebRTC wird die IP-Adresse des Rechners ermittelt.
  2. Über den JavaScript-Portscan wird das Gateway des lokalen Netzes (= der SOHO-Router) nach üblichen UPnP-Ports gescannt.
  3. Die erkannten UPnP-Ports und die Informationen über den Router werden an den Server des Angreifers gesendet.
  4. Der Server sendet die Informationen (über memcache, aber der Weg ist eigentlich egal) an den DNS-Server des Angreifers.
  5. Der JavaScript-Schadcode im Browser leitet den Benutzer zu einer speziell für diesen Benutzer erzeugten Subdomain der Angreifer-Domain und den ermittelten UPnP-Port weiter.
  6. Um die IP-Adresse des individuellen Domain-Namens zu ermitteln sendet der Browser einen Request an den DNS-Server des Angreifers. Der antwortet mit einem doppelten A-Record: Der erste A-Record enthält die Adresse des Webservers des Angreifers, der zweite die IP-Adresse des Routers des Benutzers.
  7. Der Browser folgt der Weiterleitung zur speziell erzeugten Domain und erreicht zuerst den Webserver des Angreifers.
  8. Der sendet JavaScript-Code an den Browser, der als erstes seine Einsatzbereitschaft an den Webserver meldet.
  9. Danach erzeugt der Webserver eine iptable-Regel, die Traffic von der IP-Adresse des Benutzers an seinen UPnP-Port blockiert.
  10. Der Schadcode im Browser versucht nun, den Router zu erreichen. Dazu sendet er mehrere Requests an den UPnP-Port des Webservers des Angreifers.
  11. Der erste Request scheitert, da der Server auf dem UPnP-Port ja keine Requests von der IP-Adresse des Benutzers akzeptiert. Der Browser verwendet für den nächsten Versuch deshalb die Daten aus dem zweiten A-Record (und damit die IP-Adresse des Routers des Benutzers).
  12. Alle weiteren Request erreichen also den Router auf dem UPnP-Port.
  13. Der JavaSCript-Schadcode benötigt nun die für die Konfiguration zuständige Control-URL. Die befindet sich in der XML-Datei, die die Devices darüber informiert, wie sie Requests an den UPnP-Service senden müssen. Die URL für diese Datei ist in den Informationen enthalten, die der Router nach der Kontaktaufnahme an den Anfragenden schickt. Der JavaScript-Schadcode kann diese Information nicht auswerten und probiert daher eine kurze Liste üblicher URLs durch, siehe das Listing unten.
  14. Nachdem die korrekte Control-URL ermittelt wurde sendet der JavaScript-Code UPnP-Requests für eine vorgegebene Menge von Ports, um Netzwerkverbindungen sowohl zur interne IP-Adresse des Routers als auch des Benutzer-Rechners zu öffnen.
  15. Der Schadcode sendet dem Server des Angreifers eine Liste mit den Zuordnungen (Mappings) von öffentlicher und privaten IP-Adressen.

    Die bisherigen Schritte benötigen auf normalen Systemen ca. 2-3 Sekunden.

  16. Als nächstes beginnt der Schadcode, für alle Geräte in lokalen Netz des Benutzers Ports in der Firewall zu öffnen.

    In einem /24-Netzwerk mit 255 IP-Adressen dauert das weniger als 45 Sekunden.

  17. Zuletzt teilt der Schadcode dem Server des Angreifer das von ihm geänderte Mapping mit. Danach kann der Angreifer von außen auf die nun freigeschalteten Geräte im lokalen Netz zugreifen.

Meist bleiben diese Änderungen bis zum nächsten Neustart des Routers erhalten.

Der Proof-of-Concept-Code wurde auf GitHub veröffentlicht.

Die getesteten URLs für die XML-Datei:

/DeviceDescription.xml
/rootDesc.xml
/upnp/rootdevice.xml
/upnpdev.xml
/igd.xml
/InternetGatewayDevice.xml
/IGDdevicedesc.xml
/xml/igdIPDesc.xml
/WFADevice.xml 
/Public_UPNP_gatedesc.xml
/description.xml
/gatedesc.xml

Der Angriff ist nur bei Routern möglich, die eine feste URL für die XML-Datei verwenden. Von diesen Routern ist bisher bekannt, dass die verwundbar sind:

  • DD-WRT
  • FITELnet-F60
  • Linksys WRT-400N
  • Mikrotik Router OS 6.30.2
  • PFSense (wenn das per Default nicht eingeschaltete UPnP aktiviert wurde)

Das US-CERT hat ein Advisory zur Schwachstelle veröffentlicht, dass nach und nach um Informationen über betroffene und nicht betroffene Geräte erweitert wird. Bisher gibt es dort noch keine Informationen

Filet-o-Firewall abwehren

Als Workaround können Sie UPnP im Router ausschalten. Was auch noch andere Angriffe verhindert.

Die Schwachstelle beseitigen können nur die Router-Hersteller. Am einfachsten, in dem die URL für die XML-Datei um eine für jedes anfragende Gerät individuelle, zufällige Komponente erweitert wird. Da die Geräte die URL der XML-Datei aus der Antwort auf ihren ersten Request erfahren, stört sie so ein Zufallswert nicht. Der Angriff ist aber nicht mehr möglich, da der JavaScript-Schadcode die Antwort nicht auswerten kann und daher die URL weder erfährt noch erraten kann.

In der nächsten Folge geht es um weitere mehr oder weniger aktuelle Schwachstellen in und Angriffe auf SOHO-Router.

Carsten Eilers

Trackbacks

Dipl.-Inform. Carsten Eilers am : Die Router-Schwachstellen des Jahres 2015 als eBook

Vorschau anzeigen
Die Übersicht über die Router-Schwachstellen des Jahres 2015 ist komplett. Allerdings auch etwas unübersichtlich: Filet-o-Firewall - ein neuer browserbasierter Angriff auf die Firewall Router-Schwachstellen 2015, Teil

Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #3: Unsichere Netzwerk-Dienste

Vorschau anzeigen
Bei der Beschreibung der gefährlichsten Schwachstellen in den Geräten des IoT gemäß den Top IoT Vulnerabilities von OWASP sind wir bei Punkt 3 angekommen: "Insecure Network Services". Oder auf deutsch: Unsichere Netzwerk