Vorweg, wer im W-Lan-Hotspot, zahlt ist selbst schuld!.
Beim Pentetrationtesting (Pentesting) haben wir mehrfach die rekursive DNS Auflösung aus dem LAN und ganz besonders in Gäste-W-LANs als Schwachstelle (keine Sicherheitslücke!) aufgeführt.
Die Da das Szenario jedoch nie richtig nachvollziehbar für unsere Kunden war, haben wir uns überlegt, wie wir die Schwachstelle greifbarer machen können, das ist der Grund für diesen Artikel.
Warum ist die rekursive, unauthentifizierte Namensauflösung, insbesondere in freien W-LANs oder Gäste-W-LANs mit Vouchersystem, so gefährlich?.
Viele Unternehmen schützen ihre Netzwerke bereits wirksam gegen missbräuchlichen Nutzen – beispielsweise mit einem Proxy – ohne Benutzerdaten gibt es keinen Zugriff auf das Internet. Für das Surfen im Gäste-W-LAN benötigt man einen „Gutschein“ – meist nur wenige Stunden gültig.
In offenen W-LANs, man kennt es vielleicht von Telekom Hotspots vom McDonald’s, kann man oft drei Stunden umsonst surfen, muss sonst aber einen Zugang kaufen. In anderen Hotspots muss man sich mit Facebook authentifizieren oder erhält einen Voucher.
Speziell in Cafés und auch Krankenhäusern aus unserer Region sehe ich immer wieder Clouddienste, die für ein Vouchersystem verwendet werden – startet man den Browser, so landet man auf irgendwelchen URLs im Internet – Gleiches gilt für Telekom und Vodafone Hotspots: Auch hier ist die Adresse im Internet und wird via DNS aufgelöst.
Leider ist es möglich, ohne einen Voucher oder sonstige Authentifizierung, DNS Anfragen in die Welt zu verschicken und zugleich auch noch Antworten zu erhalten. Einfach getestet mit „dig www.google.de“ erhält man brav die IP-Adresse zurück. Das bedeutet, dass es einen Weg ins Internet gibt.
Dazu müssen wir ein wenig in das DNS Protokoll einsteigen – DNS ist ein hierarchisches System, bedeutet, wenn ich nach AAAAA.www.google.de frage, geht diese Anfrage als Erstes an den DNS-Server im (W-)LAN. Dieser kennt die IP-Adresse nicht und fragt zunächst seinen „Vater DNS“ (i. d. R. Der DNS des Providers), ob er die IP kennt. Kennt er diese nicht, wird die Domain, rückwärts beginnend, Stück für Stück von den Zonenverantwortlichen aufgelöst. „.de“, dann „google.de“, dann „www.google.de und so weiter. Da der zuständige DNS-Server für Google unterhalb von de dem de DNS-Server bekannt ist, wird dieser dann von uns für weitere Anfragen direkt angefragt, also für alles, was “unterhalb” von Google kommt.
Genau das ist die Schwachstelle, denn schicken wir nun Anfragen mit Daten, beispielsweise „Text123.www.google.de“, so landet das „Datenpaket“ beim Nameserver von Google.
Wir haben einen NS Record für eine unserer Domains (Nein, diese veröffentlichen wir hier nicht, da wir diese aktiv nutzen) erstellt. Dieser NS Record verweist nun auf einen von uns kontrollierten Server. Hier haben wir nun einen gefälschten DNS-Server aufgesetzt, welcher die Daten entgegennimmt und entsprechende Antworten verschickt; das geschieht in unserem Fall mittels TXT Records. Erhalten wir nun aus einem W-Lan mit Voucher eine DNS (TXT) Anfrage, können wir die Daten normal verarbeiten und Rückantworten senden.
Da es sich bei DNS und TXT Anfragen um Klartext handelt, lässt sich dieser super komprimieren, weshalb durchaus akzeptable Geschwindigkeiten erreicht werden können.
Nun haben wir auf unserem MacBook einen Client programmiert, mit dem es möglich ist, Netzwerkanfragen (verschlüsselt, versteht sich), zu unserem kontrollierten DNS-Server zu tunneln. Hierzu haben wir einige Anpassungen an der Software “Iodine” vorgenommen. Mittels Kennwort-Authentifizierung zu unserem DNS-Server und AES256 Bit Verschlüsselung, sprechen wir nun also via BASE64 Codierung mit unserem DNS-Server.
Hierzu baut unser Client eine dauerhafte Verbindung mittels des DNS-Servers auf. Wir tunneln dann SSH über DNS von unserem Server zu unserem Client (SSH Reverse Tunnel).
Mittels diesem Reverse Tunnel (bereits über das Internet ohne Authentifizierung!) lässt sich SSH als SOCKS Proxy nutzen, sodass man auch im Internet surfen kann – über unseren “Proxy”, wenn man es so nennen mag.
Getestet haben wir dieses in diversen Hotspots von Vodafone und McDonald’s. Im PoC Video sieht man die erfolgreiche SSH Verbindung über das Internet in einem McDonald’s Hotspot der Telekom ohne vorherige Anmeldung, aber überzeugt Euch selbst.
Haben es gestern Nacht auch erfolgreich in einem ICE der Deutschen Bahn testen können, gewundert hat es uns jedoch nicht…
