Wie Angreifer aus kostenpflichtigen WLANs mittels Tunnel ausbrechen

WLAN öffne dich

Kostenpflichtige WLANs gibt heute fast überall: Auf Flughäfen und Bahnhöfen, in Hotels, in Zügen und demnächst vielleicht sogar wieder in Flugzeugen. Gemeinsam haben sie die hohen Kosten für den Benutzer. Dem kreativen Angreifer bieten sich aber Wege, auch ohne Kreditkarte ins Internet zu gelangen.

Um die Schutzmechanismen eines kostenpflichtigen WLANs zu umgehen, muss ein Angreifer zunächst einmal verstehen wie dieser Schutz überhaupt realisiert wird. Bei einem Großteil der sich im Einsatz befindlichen Wlan-Lösungen handelt es sich zunächst um ein offenes, unverschlüsseltes WLAN, welches in den meisten Fällen nach dem Anbieter oder dem Standort beziehungsweise dem Hotelnamen benannt ist. Bindet der Angreifer, der zu diesem Zeitpunkt noch wie ein normaler Kunde wirkt seine Netzwerkkarte nun an dieses Wlan und sendet eine DHCP Anfrage aus erhält er vom Access Point eine LAN-IP Adresse die mit 10. beginnt. Theoretisch wären zwar auch Adressen die mit 192.168. beginnen oder gar globale, von außen erreichbare, IP-Adressen möglich, in der Praxis ist dies jedoch nie anzutreffen. Von nun an ist der Angreifer vollwertiger Netzwerk Teilnehmer und kann mit einem Netzwerk Sniffer wie Wireshark bereits Pakete von anderen Teilnehmern mitschneiden und analysieren. Selber Pakete empfangen und versenden kann er jedoch nicht, da eine Firewall auf dem Access Point sämtlich nach außen gehende Pakete fallen lässt. (Im Detail bedeutet dies, dass der Access Point die Verbindung nicht ablehnt in dem er RST-Pakete sendet, sondern die Verbindung komplett ignoriert. Bei Iptables zum Einsatz entspricht das der Anweisung »DROP« .) Zu dieser kategorischen Ablehnung gibt es eine Ausnahme und das sind Verbindungen auf Port 80 (HTTP). Alle HTTP-Anfragen fängt der Access Point mittels eines transparenten HTTP-Proxy ab und leitet die Anfragen auf eine Webseite des Wlan-Anbieters um. Der normale Kunde bemerkt dies, in dem er den Browser öffnet, eine beliebige Domain eingibt und statt der erwarteten Webseite die Webseite des Anbieters, meist mit einer Login-Möglichkeit und Hinweisen zur Bezahlung, angezeigt bekommt. (Abbildung 1)

Eine typische Login-Seite eines kostenpflichtigen WLANs

Ein Angriff auf diese Login Möglichkeit ist beinahe aussichtslos da die Authentifierzung hier gegen eine zentrale Datenbank mit Benutzername und Passwort, mit One Time Pads die an der Hotel Rezeption erworben wurden, oder sogar gegen die Anbieter von Kreditkarten durchgeführt wird. Hat sich ein Client jedoch erfolgreich authentifiziert wird seine IP-Adresse in der Firewall freigeschaltet und er kann von nun an beliebige Verbindungen nach Außen aufbauen. Sobald sich der Client über die Webseite wieder ausloggt oder seine bezahlte Zeit abgelaufen ist, sperrt die Firewall die IP-Adresse des Clients wieder. Ein offensichtliches Sicherheitsproblem existiert in diesem Aufbau nicht. Doch ein kleines Loch ist dennoch vorhanden. Der lokale DNS Server. DNS, der Dienst, der Domainnamen in IP-Adressen auflöst, ist bei den meisten Wlans in den Access Point integriert. Und bei allen getesteten Wlans löst er Namen auch für nicht authenfizierte Clients auf. Überprüfen können Sie das ganz legal indem Sie resolveip beliebigedomain.tld auf der Konsole eingeben. Entspricht das Ergebnis der tatsächlichen IP Adresse der Domain und nicht zum Beispiel einer lokalen IP Adresse ist dieses Loch vorhanden. Über den Umweg DNS Server gelangen also Informationen in Form von DNS Anfragen an der Firewall vorbei in die Außenwelt und Informationen in Form von DNS Antworten wieder zurück. Doch wie kann der Angreifer auf diese Weise beliebige Pakete versenden und empfangen? Hier kommen DNS Tunnel ins Spiel.

DNS Tunnel

Um eine lange Geschichte möglichst kurz zu machen sei zur Funktionsweise von DNS nur erwähnt, dass eine Domain von rechts nach links hierarchisch aufgebaut ist. Es gibt einen zentralen Server, der weiß welche Server für welche Top Level Domains (.com, .de, .org) zuständig sind. Diese Server wiederum speichern zum einen welche IP einer Domain zugeordnet ist, und zum anderen welcher Server für Subdomains dieser Domain zuständig ist. Ist der Angreifer Besitzer einer Domain, kann er für Subdomains dieser Domain einen eignen Nameserver festlegen. Für die Domain example.com gibt es folglich (mindestens) zwei Einträge. Einen so genannten A-Record, der die für example.com benutze IP speichert und einen NS-Record der auf einen DNS-Server verweist, der für alle Subdomains von example.com zuständig ist. Richtet der Angreifer den NS-Record einer Domain auf seinen eigenen Server, werden alle DNS Anfragen für Subdomains dieser Domain an diesen Server gestellt und können entsprechend bearbeitet und beantwortet werden. Führt man sich jetzt noch vor Augen das DNS Anfragen und Antworten im Grunde nur aus einfachem Text in einem UDP-Paket bestehen ergibt sich eine umständliche aber wirkungsvolle Möglichkeit Nachrichten aus einem geschlossenen Wlan an einen im Internet hängenden Server zu schicken. Der Client im Wlan stellt eine DNS Anfrage, in eine Nachricht kodiert ist, nach einer Subdomain der kontrollierten Domain an den lokalen DNS-Server. Der lokale DNS-Server weiß damit nichts anzufangen, guckt nach, welcher Nameserver für diese Domain zuständig ist, und leitet die Anfrage an den kontrollierten Server weiter. Der Server packt die Nachricht aus der erhaltenen Anfrage aus und kann in seiner Antwort ebenfalls wieder eine Nachricht kodieren, die den gleichen Weg zurück nimmt und vom Client verstanden wird. (Abbildung 2)

Durch den DNS Server gelangen Pakete an der Firewall vorbei zum Server des Angreifers

Was in der Theorie einfache Textnachrichten sind kann, abhängig vom Aufwand den die DNS-Tunnel Implementation treibt, entweder für eine SSH Verbindung benutzt werden oder sogar zu einer kompletten Netzwerk Emulation mittels TUN/TAB ausgebaut werden. Ein Problem ergibt sich jedoch, wenn man den gesamten Netzwerkverkehr über DNS Tunnel möchte. Das Prinzip erlaubt nur das Versenden von Paketen von Seiten des Clients und darauf jeweils eine Antwort des Servers. Der Server kann also von sich aus keine Pakete an den Client senden. Stattdessen muss der Client regelmäßig nachfragen, ob der Server neue Pakete hat. Außerdem muss der Server Pakete, die nicht an ihn sondern an einen anderen Server im Internet gerichtet sind, weiterleiten. Mittels NAT stellt dies jedoch kein Problem da.

Vorbereitungen

Um selber einen DNS Tunnel zu betreiben braucht der Angreifer zum einen einen Server mit fester IP und zum Anderen eine Domain oder eine Subdomain bei der er sowohl den A als auch den NS Record setzen kann. Erfahrungsgemäß ist dies bei vielen großen Anbietern von Webspace oder ähnlichem unverständlicherweise nicht der Fall ist. Zum Glück gibt es jedoch zahlreiche kostenlose Anbieter die das Editieren von ebenfalls kostenlose Subdomains erlauben. Eine Suche nach Schlagwörtern wie free, dns, record, edit sollte recht schnell zum Erfolg führen. Der Autor hat seine Test zum Beispiel mit editdns.net gemacht. Es werden zwei Domains benötigt. Eine, deren A-Record auf die IP-Adresse des Servers zeigt welcher später den DNS Tunnel beherbergen soll und eine deren NS-Record auf die erste Domain zeigt. Dieser kleine Umweg ist nötig, da der NS-Record nur Domains akzeptiert und nicht direkt IP Adressen. Für diesen Artikel wird die erste Domain, deren A-Record auf die Server-IP zeigt, dnsserver.example.tld genannt und die zweite Domain, deren NS-Record auf dnsserver.example.tld zeigt tunnel.example.tld. Auf dem Server muss der Angreifer nun eine DNS Tunnel Implementation installieren. Zwar gibt es dafür verschiedene Lösungen, die meisten fallen aber durch Instabilität auf oder werden nicht aktiv entwickelt, was darauf schließen lässt, dass es sich hierbei nur um Proof-of-Concepts gehandelt hat. Als brauchbare Lösung stellt sich jedoch iodine heraus.

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2019