Die große DNS-Schwachstelle und NAT-Router (2)

Oder ‘Wie die Fritzbox die DNS-Patch-Anstrengungen zu nichte machte’

Wie bereits in meinem vorhergehendem Eintrag erklärt, zerstören viele NAT-Router den Sicherheitsgewinn durch die Patches. Ja schlimmer noch, sie sorgen sogar dafür, dass man gepatchte Systeme weiterhin angreifen kann. (Ein Administrator / Benutzer der sich in Sicherheit wiegt kann also angegriffen werden.)

Warum ist das so?

Dazu muss man erst einmal wissen warum denn jetzt überhaupt die Quell-Ports der DNS-Anfragen zufällig sein sollten.

Um das zu verstehen muss man erstmal verstehen wie DNS-Anfragen ablaufen. (Stark vereinfacht, detaillierte Information zu DNS in der Wikipedia. Detaillierte Begründungen für die zufällige Portwahl finden sich im Skript von Dan Kaminsky)

Jeder Rechner der einen DNS-Adresse auflösen möchte fragt dazu bei seinem DNS-Server an. Dieser leitet die Anfrage entweder weiter oder probiert sie selber aufzulösen.

Um zu verhindern, dass einfach irgendjemand die eigene DNS-Anfrage beantwortet, wurde die Transaction ID eingeführt. Diese ID wird in die Anfrage eingebunden und nur der anfragende Server und der angefragte Server kennen diese. (Z.b. der eigene Rechner und die Fritzbox)

Diese ID ist 2 byte groß. Es gibt also 65536 mögliche IDs. Bis vor kurzem dachte man, dass dies ausreichend wäre um Schutz gegen gefälschte DNS-Einträge zu liefern.

Wie sich nun herausgestellt hat war das ein Irrtum. Um nun das Polster das man gegen gefälschte DNS-Einträge hat zu vergrößern hat man sich nun entschieden die Quellports auch zufällig zu wählen.

Vor dem Patch haben die meisten DNS-Server einen bekannten Quell-Port gewählt (oder er war zumindest vorhersagbar). Der Angreifer musste also nur die Transaction ID erraten um einem Anfragendem Server einen gefälschten Eintrag unterzujubeln.

Nach dem Patch muss er zusätzlich den Quell-Port erraten. Da der Quell-Port auch ein  2 byte großer Wert ist, hat der Angreifer also nun keine 65536:1 Chance, sondern eine Chance zwischen 163.840.00:1 und 2.14.483.648:1.

NAT-Router sind des Teufels Handlanger

Was in Gottes Namen machen die dämlichen NAT-Router aber? Sie machen die ganze schöne zufällige Wahl kapputt indem sie die Ports einfach so umsetzen. (Um technisch genau zu bleiben handelt es sich um PAT. Da sich der Begriff NAT für solche Router aber eingebürgert hat, bleibe ich der Einfachheit halbe dabei.)

Auch hier muss ich kurz etwas ausholen.

Um mit dem Internet kommunizieren zu können braucht jeder Rechner eine, eindeutige, öffentliche IP-Adresse. Leider hat man sofern man mehr als einen Rechner an seinen heimischen Internetanschluss hängen möchte, dass man trotzdem nur eine IP-Adresse hat. Um dieses Problem zu umgehen gäbe es zwei Möglichkeiten.

1. Jeder Rechner bekommt seine eigene öffentliche IP-Adresse. Das machen die Provider aber leider nicht mit. Da sonst jeder Haushalt x IP-Adressen bekommen müsste.
2. Man setzt eine NAT ein. Dabei wird jeder Rechner durch den Router maskiert. Der Router ersetz also bei einem abgehenden IP-Paket die IP-Adresse des Clients durch seine eigene öffentliche IP-Adresse.

Die zweite Methode wird aktuell fast jedem Haushalt und einem Großteil der Firmen eingesetzt werden.

Um mit einem Rechner im Internet kommunizieren zu können muss ein Client nicht nur eine vom Internet erreichbare IP-Adresse haben, sondern auch einen vom Internet heraus erreichbaren Port.

Daher maskiert ein Router nicht nur die IP-Adressen der Clients sondern auch die Ports von denen sie aus angefragt haben.

Bei diesem Schritt gibt es aber ein Problem. Die meisten Router arbeiten bei diesem Schritt nach einem System. Der abgehende Port wird in den meisten Fällen überhaupt nicht abhängig vom Port des Clients gewählt sondern einfach hochgezählt.

IP-Client:Port-Client <-> IP-Router:Port-Router

10.0.0.1:2568<->1.2.3.4:5000

10.0.0.1:56887<->1.2.3.4:5001

10.0.0.3:3652<->1.2.3.4:5002

10.0.01:8021<->1.2.3.4:5003

Das war vor dem DNS-Patch schlicht egal. Jetzt führt es aber dazu, dass im Falle von DNS die gesamte Arbeit des Patches zu nichte gemacht wird.

Vor dem Patch (Anfragen der Clients haben aufsteigende Ports)

10.0.0.1:56886<->1.2.3.4:5000

10.0.0.1:56887<->1.2.3.4:5001

10.0.01:56888<->1.2.3.4:5003

Nach dem Patch (Anfragen der Clients haben zufällige Ports)

10.0.0.1:32546<->1.2.3.4:5000

10.0.0.1:56887<->1.2.3.4:5001

10.0.01:59713<->1.2.3.4:5003

Es wird noch schlimmer – Auftritt DSL-Router

Das alleine ist ja schon schlimm genug. In den meisten Fällen fragt der Client hinter dem Router nicht selber bei sich im Internet befindenden DNS-Servern an, sondern fragt den in seinem eigenen Netz vorhandenen DNS-Server. Ausnahmen sind hier DNS-Server die selber bei den Internetservern nachfragen. Etwa Windows DNS-Server die keine Weiterleitung konfiguriert haben, sondern bei den Root-Server selber nachfragen.

In der normalen SOHO-Umgebung fragt allerdings niemand den DNS-Server von z.B. google.de nach der IP-Adresse von www.google.de sondern man fragt den DSL-Router.

Moderne DSL-Router sind wenn sie eingestöpselt werden auch schon Betriebsbereit. Auf ihnen läuft in der Regel ein DHCP-Server der alle im Netz verfügbaren Geräte gleich mit einer IP-Adresse versorgt.

Dieser DHCP-Server teilt seinen angeschlossenen Clients mit welche IP-Adresse sie haben, wie das Standardgateway lautet (die IP-Adresse des Routers) und wie der DNS-Server lautet(die IP-Adresse des Routers), an den sie ihre Anfragen schicken sollen.

Die gesamte DNS-Auflösung wird (aus der Sicht des Netzes hinter der NAT) also vom Router durchgeführt. Das bedeutet (da DNS hierarchisch aufgebaut ist) das die Sicherheit des Netzes mit der Sicherheit des Router steht und fällt.

Das wäre ja alles kein Problem gäbe es da nicht das folgende Problem: Die verdammten Router sind alle (zu einem Großteil) ungepatcht.

Es ist ja nun nicht so als sei der Fehler so schwerwiegend, als hätten sich die fünf großen DNS-Server Hersteller zusammengeschlossen um an einem Tag alle gemeinsam zu patchen. (Wer den Wink nicht verstanden hat, es war so.)

Cache Poisening leicht gemacht – Beispiel Fritzbox

Nachdem jetzt die Grundlagen geklärt sind, nun der interessante Teil.

Ich habe (wie vermutlich viele andere DSL-Kunden auch) eine Fritzbox. Diese dient als DSL-Router. Wenn man nach der WLAN-Mac-Verteilung geht (und die Verteilung in meiner Nachbarschaft repräsentativ ist) dürften mindestens 50% aller DSL-Nutzer eine Fritzbox haben.

Auf der Fritzbox läuft ein DNS-Server. Genauer, ein reiner DNS-Forwarder, der alle DNS-Anfragen an die Box an den DNS-Server des Provider weiterleitet.

Jetzt kommt endlich das auf was ich die ganze Zeit hinaus will.

Alle DNS-Anfragen der Fritzbox gehen vom Quellport 2050 ab. (Zumindest von meiner Fritzbox 7050. Wenn es in anderen Modellen anders ist, lasst es mich wissen)

Das ist eigentlich das Beste was einem aus Angreifer sicht passieren kann. Ein Ziel, dass sich nicht bewegt. (Genauer sitzt es eigentlich sehr still da.)

Aber, wo liegt da die Gefahr?

Der Übersicht halber spalte ich das mal in einen neuen Eintrag ab. (Den ich aber erst veröffentlichen werde, sobald ich AVM von dieser Lücke informiert habe. Von ihrer Antwort werde ich das Veröffentlichungstempo abhängig machen.)