Ein externer Angreifer, der auf das Web-basierte Administrations-Interface
des lokalen Routers zugreifen kann, und das womöglich auch noch interaktiv
- das klingt eigentlich ziemlich unmöglich. Genau das hat aber Craig
Heffner auf der Konferenz "Black Hat USA 2010"
gezeigt.
Besonders erstaunlich ist, dass es sich dabei eigentlich nur um die
Kombination einiger altbekannter Angriffe und Schwachstellen, insbesondere
DNS-Rebinding, handelt. Auch eigentlich längst als erledigt geglaubte
Angriffe oder Schwachstellen sind also immer noch für eine
Überraschung gut
(Paper
und
Präsentation
als PDF).
In dieser Folge gibt es eine Beschreibung der Grundlagen des Angriffs, d.h.
der alten Angriffe und Schwachstellen, in der nächsten Folge dann die
des eigentlichen Angriffs sowie mögliche Gegenmaßnahmen.
Wieso, weshalb, warum
Angriffe auf Router der "SOHO-Klasse" (Small Office, Home Office) gibt es
schon seit einiger Zeit, und es gibt sogar schon
Trojaner, z.B. Zlob.P,
die den Router im lokalen Netz eines infizierten Windows-Rechners
manipulieren. Im Allgemeinen kann ein externer Angreifer diese Router aber
nur indirekt angreifen, indem er den Angriff über einen lokalen Client
leitet, z.B. bei einem Cross-Site-Request-Forgery-Angriff. Ihre Nachteile
für den Angreifer: Sie müssen an den jeweiligen Router angepasst
werden, der Angreifer muss zumindest den Routertyp sowie die interne
IP-Adresse raten. Außerdem bekommt er die Ergebnisse seines Angriffs
aufgrund der Same-Origin-Policy der Webbrowser nicht zu sehen.
All diese Einschränkungen lassen sich mit einem DNS-Rebinding-Angriff
umgehen, der vereinfacht so abläuft: Ein Benutzer wird dazu gebracht,
JavaScript-Code vom Webserver des Angreifers zu laden. Nach dem Laden wird
über DNS-Rebinding der Domainname des Angreifer-Servers mit der
IP-Adresse des lokalen Routers verknüpft. Danach kann der
JavaScript-Code ungehindert von der Same-Origin-Policy XMLHttpRequests an
den Router senden, der dazu über den Domainnamen des Angreifers
angesprochen wird. Die Requests werden von der Same-Origin-Policy erlaubt,
da für die Zuordnung der Origin der Domainname verwendet wird und der
JavaScript-Code für den Webbrowser von der Domain stammt, auf die er
zugreift.
DNS-Rebinding allgemein: Eine Domain wechselt die IP-Adresse
DNS-Rebinding lässt sich am besten an einem Beispiel erklären.
Angegriffen wird der Server www.opfer.example mit der
IP-Adresse 1.2.3.4.
- Der Benutzer ruft aus irgendeinem Grund, z.B. aufgrund eines
Cross-Site-Scripting-Angriffs, die Domain das Angreifers
www.angreifer.example auf. Dafür muss der Browser dessen
IP-Adresse erfragen und bekommt vom zuständigen DNS-Server die
IP-Adresse 9.8.7.6 mit einem DNS-Time-to-live-Timeout (TTL)
von einer Sekunde mitgeteilt.
- Die geladene Seite enthält einen Refresh-Aufruf nach mehr als
einer Sekunde, z.B. zwei Sekunden. Der Refresh kann z.B. über das
Refresh-Meta-Tag oder JavaScript-Code erfolgen.
- Der DNS-Eintrag ist inzwischen ungültig, da die TTL abgelaufen
ist. Die IP-Adresse von
www.angreifer.example wird erneut
beim DNS-Server angefordert. Der DNS-Server des Angreifers kann jetzt eine
beliebige gefälschte IP-Adresse zurückliefern, z.B. die Adresse
1.2.3.4 von www.opfer.example.
- Wenn der Webbrowser dann die IP-Adresse
1.2.3.4 aufruft,
denkt er, dass er sich auf www.angreifer.example befindet,
obwohl er auf www.opfer.example landet. Dadurch kann z.B. von
www.angreifer.example geladener Schadcode auf die Daten von
www.opfer.example zugreifen.
DNS-Pinning verhindert erschwert DNS-Rebinding
DNS-Rebinding ist ein altbekanntes Problem, dem die Webbrowser auf
verschiedene Arten zu begegnen versuchen. Der verbreitetste Ansatz
dafür ist das DNS-Pinning: Die Antwort auf die erste vom Browser
für einen Domainnamen durchgeführte DNS-Abfrage wird für
einen bestimmten Zeitraum in einem Cache gespeichert. Für weitere
Zugriffe auf diese Domain wird dann die gespeicherte IP-Adresse verwendet,
es finden keine weiteren DNS-Abfragen statt. Eine neue DNS-Abfrage wird
erst durchgeführt, wenn die Speicherzeit abgelaufen ist oder der
Browser neu gestartet wurde.
Mit DNS-Pinning funktioniert der oben beschriebene DNS-Rebinding-Angriff
nicht, da der Webbrowser die Zuordnung der IP-Adressen zu den Domainnamen
unabhängig von der DNS-TTL-Einstellung in seinem Cache speichert.
Gegen das DNS-Pinning setzen die Angreifer Anti-DNS-Pinning-Angriffe
ein, bei denen versucht wird, das cachen zu verhindern und eine zweite
DNS-Abfrage zu erzwingen, bei der dann der Domainname des Angreifers mit
einer anderen IP-Adresse verknüpft wird.
DNS-Rebinding-Angriff mit doppelten Adressen
Ein weiterer altbekannter DNS-Rebinding-Angriff arbeitet mit zwei
"A-Records". Die Antwort des DNS-Servers des Angreifers in Punkt 2 des
Beispiels enthält dann zwei IP-Adressen: Die tatsächliche Adresse von
www.angreifer.example, 9.8.7.6, und die Adresse,
mit der der Angreifer seinen Domainnamen verknüpfen möchte,
1.2.3.4. Der Browser des Opfers verbindet sich mit der ersten
angegebenen IP-Adresse und lädt von dort z.B eine HTML-Seite mit bösartigen
JavaScript-Code. Nachdem die Seite geladen wurde, verhindert der Angreifer
z.B. durch Anpassung der Firewall-Regeln weitere Zugriffe von der
IP-Adresse des Opfers. Sendet der eingeschleuste Schadcode einen
XMLHttpRequest an www.angreifer.example, ist der Server über
die erste dem Browser bekannte IP-Adresse nicht erreichbar und er verwendet
die zweite ihm bekannte Adresse 1.2.3.4, die aber zu
www.opfer.example gehört - das DNS-Rebinding war erfolgreich.
Bei diesem Angriff können keine internen IP-Adressen wie die des
Routers verwendet werden, da diese nicht-routbaren Adressen vom Browser
bevorzugt verwendet werden. Auch wenn die interne Adresse erst an zweiter
Stelle der DNS-Antwort steht, wird sie vom Browser zuerst verwendet. Schon
der erste Request würde also an die interne IP-Adresse gesendet, so
dass der Schadcode des Angreifers gar nicht erst geladen wird.
Was innen nicht geht, geht außen
Craig Heffner hat eine Lösung für dieses Problem gefunden: Er
verwendet als zweite IP-Adresse die externe, öffentliche IP-Adresse
des Routers, d.h. die, über die er im Internet erreichbar ist. Viele
TCP/IP-Implementierungen akzeptieren alle einkommenden Pakete, sofern sie
an irgend eine der eigenen IP-Adressen gerichtet sind. Die IP-Adresse muss
nicht zu dem Interface gehören, über das das Paket empfangen
wird. Insbesondere werden Pakete an die externe IP-Adresse auch am internen
Interface entgegen genommen und sofort verarbeitet, sie gelangen also gar
nicht bis zum externen Interface. Betroffen von dieser unsicheren
Konfiguration sind u.a. Linux und viele SOHO-Router.
Die Verwendung der öffentlichen IP-Adresse hat für den Angreife
einen weiteren Vorteil: Er muss die interne IP-Adresse des Routers nicht
kennen. Und die öffentliche erfährt er ja beim Zugriff auf seinen
Server.
Und noch ein Baustein...
Noch ein weiterer Schwachpunkt trägt dazu bei, dass der von Craig
Heffner entwickelte Angriff möglich ist: Häufig sind alle Dienste
des Routers, insbesondere auch der Webserver für die
Administrationsoberfläche, an alle Interfaces gebunden. Eingehende
Verbindungen auf dem öffentlichen (WAN) Interface werden meist
über Firewallregeln abgeblockt, so dass von außen kein Zugriff
auf die Administrationsoberfläche möglich ist. Dass der
Netzwerkverkehr dabei anhand des Interfaces und nicht der IP-Adresse
identifiziert wird, ist ungünstig, aber kaum zu ändern, da die
externe Adresse meist vom ISP dynamische vergeben wird und sich daher
jederzeit ändern kann.
Was bedeutet dass nun für den Fall, dass ein interner Client über
das interne Interface auf die externe IP-Adresse zugreifen möchte?
Der Zugriff ist möglich, da die Daten schon vom internen Interface
verarbeitet werden und das externe, von dem sie nicht akzeptiert
würden, nie erreichen.
Wie man aus diesen Angriffen und Schwachstellen den Angriff auf das
Web-basierte Administrations-Interface zusammenstellt, erfahren Sie in der
nächsten Folge.
Carsten Eilers
Übersicht über alle Artikel zum Thema
- WEP, WPA, WPA2 - WLAN-Schutz, aber richtig!
-
- "Hole196" - Eine neue Schwachstelle in WPA2
-
- DNS-Rebinding - Ein altbekannter Angriff kompromittiert Router
-
- Von außen durch den Client in den Router
-
- Ciscos "WPA Migration Mode" öffnet den Weg ins WLAN
-
- NAT-Pinning, Angriffe auf Cisco-WLANs und ein Tool
-
- Angriffe auf den WLAN-Client
-
- BEAST - Ein neuer Angriff auf SSL und TLS 1.0
-
- Konfigurationsänderungen am Router per UPnP - aus dem Internet
-
- WLAN-Sicherheit - Stand der Dinge
-
- WPS-Schwachstelle gefährdet WLANs
-
