Fast jede öffentliche Einrichtung und jedes Hotel bieten heute ein kostenpflichtiges WLAN an. Kreative Zeitgenossen finden jedoch meist schnell eine Möglichkeit, ein solches Netz unautorisiert zu nutzen.

Un zu verstehen, wie Angreifer die Schutzmechanismen kostenpflichtiger WLANs umgehen, gilt es zunächst, die Funktionsweise solcher Netze zu kennen. Bei einem Großteil davon handelt es sich um unverschlüsselte Netze, die in den meisten Fällen den Namen des Anbieters oder des Standorts tragen. Verbindet sich ein Rechner mit dem zugehörigen Access Point, erhält er von diesem eine IP-Adresse, die in der Regel mit 10. beginnt.

Ab diesem Moment ist der Rechner vollwertiger Teilnehmer des Netzwerks und damit imstande, mit einem Sniffer wie Wireshark [1] Pakete anderer Teilnehmer mitzuschneiden und zu analysieren. Pakete ins externe Netz empfangen und versenden kann er jedoch nicht, da eine Firewall auf dem Access Point sämtliche nach außen gehende Pakete blockiert. Im Detail bedeutet das, dass der Access Point die sämtliche Verbindungsversuche außer auf Port 80 verwirft. Die verbleibenden HTTP-Anfragen fängt ein transparenter Proxy ab, der sie auf die Anbieterseite weiterleitet. So lange der Kunde nicht nicht bezahlt und sich angemeldet hat, erscheint bei jeder beliebigen Eingabe einer URL im Browser diese Seite (Abbildung 1).

Abbildung 1: Anfragen nicht authentifizierter Nutzer leitet ein transparenter Proxy des kostenpflichtigen WLAN-Anbieters immer auf eine Login-Webseite.

Da die Authentifizierung gegen eine zentrale Datenbank mit Benutzername und Passwort stattfindet, hat ein Brute-Force-Angriff auf das Login kaum Aussicht auf Erfolg. Die Zugangsdaten erhält der Kunde in der Regel entweder direkt über die Login-Seite des Anbieters oder an der Hotel-Rezeption. Nach dem erfolgreichen Authentifizieren schaltet die Firewall die IP-Adresse des Clients frei, womit er von nun an beliebige Verbindungen nach außen aufbauen darf. Sobald sich der Client abmeldet oder seine bezahlte Zeit abläuft, sperrt die Firewall die IP-Adresse des Clients wieder.

Ein offensichtliches Sicherheitsproblem existiert in diesem Aufbau nicht. Ein kleines Loch ist aber dennoch vorhanden – der lokale DNS-Server. Er dient dazu, Domainnamen in IP-Adressen aufzulösen, und ist bei den meisten WLANs in den Access Point integriert. Bei allen getesteten Bezahl-WLANs löst er auch Anfragen nicht authentifizierter Clients auf. Sie überprüfen das beispielsweise mit der Eingabe von resolveip beliebigedomain.tld in der Konsole. Entspricht das Ergebnis der tatsächlichen IP-Adresse der Domain und nicht etwa einer lokalen IP-Adresse, nimmt der DNS die Anfrage entgegen. Es gelangen also Informationen in Form von DNS-Anfragen an der Firewall vorbei in die Außenwelt und kommen als IP-Adressen wieder zurück. Doch wie gelingt es, auf diese Weise beliebige Pakete zu versenden und zu empfangen?

DNS-Tunnel

Generell ist ein Domainname immer von rechts nach links hierarchisch aufgebaut. Ein zentraler Server zeichnet sich für die Top-Level-Domains wie .com, .de und .org zuständig. Er speichert zum einen die einer Domain zugeordnete IP-Adresse und zum anderen den Server, der sich um die Verwaltung der Subdomains (subdomain.linux-user.de) kümmert. Inhaber von Domains können entsprechend für Subdomains einen eigenen Nameserver bestimmen. Für die Domain http://example.com gibt es folglich mindestens zwei Einträge: einen so genannten A-Record, der die für http://example.com benutze IP-Adresse speichert, und einen NS-Record, der auf einen DNS-Server verweist, der für alle Subdomains von http://example.com zuständig ist. Richten Sie den NS-Record einer Domain auf den eigenen Server, gelangen alle DNS-Anfragen für Subdomains dieser Domain dorthin und lassen sich entsprechend bearbeiten und beantworten.

DNS-Anfragen und die Antworten darauf bestehen im Grunde nur aus einfachem Text, der mit einem UDP-Paket verschickt wird. Daraus ergibt sich die umständliche, aber wirkungsvolle Möglichkeit, Nachrichten aus einem geschlossenen WLAN an einen mit dem Internet verbundenen Server zu versenden.

Der Client im WLAN stellt dazu eine mit einer kodierten Nachricht versehene DNS-Anfrage nach einer Subdomain der kontrollierten Domain an den lokalen DNS-Server. Da der lokale DNS-Server diese nicht auflösen kann, prüft er, welcher Nameserver für diese Domain zuständig ist, und leitet die Anfrage an diesen weiter. Der präparierte Server packt die Nachricht aus der erhaltenen Anfrage aus und kodiert in die Antwort seinerseits eine Nachricht. Sie geht den gleichen Weg zurück wird vom Client mittels einer speziellen Software verstanden (Abbildung 2).

Abbildung 2: In vielen Fällen gelangen DNS-Anfragen auch von nicht authentifizierten Nutzern ins Internet und ermöglichen damit das missbräuchliche Nutzen des Dienstes.

Diese Methode ermöglicht es, abhängig vom Aufwand, entweder eine SSH-Verbindung zu etablieren oder sogar eine komplette Netzwerkemulation mittels TUN/TAP aufzubauen. Ein Problem ergibt sich jedoch beim Tunneln des Netzwerkverkehrs via DNS: Der Server ist von sich aus nicht in der Lage, dem Client Pakete zu schicken. Stattdessen muss darauf warten, dass dieser bei ihm nachfragt, ob er neue Pakete für ihn hat. Des weiteren muss der Server alle nicht an ihn gerichteten Pakete weiterleiten, was jedoch dank NAT kein Problem darstellt.

Vorbereitungen

Um einen DNS-Tunnel zu betreiben, benötigt der Angreifer einen Server mit einer festen IP-Adresse und eine Domain oder eine Subdomain, bei der er sowohl den A- als auch den NS-Record bearbeiten können. Der Autor verwendete für das Testszenario den Anbieter editDNS.net [2]. Notwendig sind zwei Domains. Bei der einen zeigt der A-Record auf die IP-Adresse des Servers, auf dem später der DNS-Tunnel läuft, bei der anderen zeigt der NS-Record auf die erste Domain. Dieser kleine Umweg ist nötig, da der NS-Record nur Domainnamen, nicht jedoch IP-Adressen akzeptiert. Für diesen Artikel bezeichnen wir die erste Domain als dns.example.tld, die zweite – deren NS-Record auf dns.example.tld zeigt – als tunnel.example.tld.

Auf dem Server gilt es nun, den DNS-Tunnel zu installieren. Zwar gibt es dafür verschiedene Lösungen, die meisten fallen aber durch Instabilität auf oder werden nicht aktiv entwickelt. Das lässt darauf schließen, dass es sich dabei um Proofs-of-Concept, also Machbarkeitsnachweise, handelt. Als verhältnismäßig brauchbare Lösung entpuppt sich Iodine [3].

Server

Das Programm finden sich in den Repositories vieler Distributionen, von wo es sich über den Paketmanagers des Systems installieren lässt. Alternativ richtet man Iodine aus den vom Projekt angebotenen Quelldateien mit den üblichen Aufrufen make und sudo make install ein.

Iodine emuliert mittels TUN ein virtuelles Netzwerk-Device und braucht daher das Kernel Modul tun. Dieses gilt es gegebenenfalls über den Aufruf sudo modprobe tun als Modul zu laden. Nun lässt sich auf dem Server der Iodine-Daemon mit folgendem Kommando starten:

# iodined -P geheim 192.168.10.1 tunnel.example.tld

Der Platzhalter geheim steht für ein Passwort, über das sich der Iodine-Client am Server authentifiziert. Bei der IP-Adresse in dem Befehl handelt es sich um jene, die das TUN-Device im virtuellen Netzwerk haben wird. Der Iodine-Server verteilt dann automatisch IP-Adressen an die Clients. Welchen lokale Adressbereich zum Einsatz kommt, spielt hierbei keine Rolle – allerdings muss er sich von dem des WLANs unterscheiden. Da die meisten kostenpflichtigen WLANS den 10er-Bereich verwenden, bietet sich ein 192er-Netz an.

Clients

Nach der Installation der Iodine-Software auf dem Client erstellt auch hier der Aufruf sudo modprobe tun ein Tun-Device. Anschließend baut der Befehl

# iodine -P geheim tunnel.example.tld

den DNS-Tunnel auf. Mit diesem Setup ist der Client bereits in der Lage, Verbindungen über das DNS-Protokoll zum Server aufbauen und damit den Schutz des WLANs erfolgreich zu umgehen. Das lässt sich unschwer entweder mit einem Ping an den DNS-Tunnel-Server oder dem Etablieren einer SSH-Verbindung prüfen.

Connects zu anderen Hosts im Internet gelingen in dieser Phase jedoch noch nicht. Dazu gilt es, den Server zum NAT-Router auszubauen. Unter Linux erledigen das die zwei folgenden Befehle:

# echo 1 > /proc/sys/net/ipv4/ip_forward
# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Das Device eth0 entspricht im Beispiel der Netzwerkschnittstelle des Servers ins Internet. Anschließend sorgt nun das Umbiegen der Default-Route des Clients auf den Tunnelserver dafür, dass lediglich Anfragen an das 10er-Netz zum Access Point des Anbieters gelangen (Abbildung 3). Welche IP-Adresse der Access Point benutzt, gibt die Ausgabe des Befehls route preis. Die Adresse findet sich in der Zeile, die mit default beginnt, in der Spalte Router. Die drei Befehle aus Listing 1 setzen schließlich die neuen Routen.

Abbildung 3: Um über den Tunnel das Internet zu erreichen, gilt es zunächst, die Routen auf dem Client anzupassen.

# route add -net 10.0.0.0 netmask 255.0.0.0 gw IP-Adresse Access Point # route del default gw IP-Adresse Access Point # route add default gw 192.168.10.1

Andere Angriffswege

Alternativ hat der Angreifer die Möglichkeit, die eigene IP-Adresse zu fälschen – dieser Weg bringt jedoch einige Einschränkungen mit sich. Zum einen muss die Firewall die gewünschte IP-Adresse bereits freigeschaltet haben, zum anderen muss diese dem Angreifer bekannt sein. Mit Netzwerksniffern wie Wireshark stellt es jedoch kein Problem dar, die MAC- und IP-Adressen von Peers festzustellen, die durch besonders hohen Datenverkehr auffallen.

Die Pakete lediglich mit einer gefälschter Absenderadresse durch das Netzwerk zu schicken, würde sie zwar durch die Firewall hinaus bringen, die Antwortpakete aber würden an der falschen Stelle ankommen – nämlich an dem Host, dem die Adresse eigentlich gehört. Damit das unter falscher Flagge segelnde System sie dennoch empfangen kann, gilt es, ihm die IP- und MAC-Adresse des abgehörten Hosts zuzuweisen. Das erledigen die Aufrufe in den ersten beiden Zeilen von Listing 2. Danach gilt es das Netzwerkdevice mit den Befehlen der dritten und vierten Zeile neu zu starten. Der Client erscheint jetzt auf Netzwerk-Schicht identisch zu dem anderen, tatsächlich authentifizierten Host.

# ifconfig wlan0 hw ether ersniffte_MAC # ifconfig wlan0 ersniffte_IP # ifconfig wlan0 down # ifconfig wlan0 up

Allerdings verursacht das TCP-Protokoll hier Probleme: Es arbeitet verbindungsbasiert, was grob vereinfacht bedeutet, das sich zwei Peers vor der Kommunikation zunächst kennenlernen, bevor sie Daten austauschen. Dazu gehört auch, dass das System unbekannte TCP-Pakete mit einem Fehler beantwortet. Befinden sich zwei Clients mit der selben IP-Adresse im Netzwerk, erhält jeder der beiden ständig unerwartete TCP-Pakete, die auf vom jeweils anderen Client etablierte Verbindungen antworten. Die Fehlermeldungen, die das Betriebssystem daraufhin aussendet, veranlassen die Gegenseite, die Verbindung zu beenden.

Um das zu vermeiden, muss der Angreifer das Betriebssystem zum einen daran hindern, TCP-Pakete auszusenden und zu beantworten. Zum anderen muss er seine eigene Kommunikation auf das verbindungslos arbeitende UDP beschränken: Im Gegensatz zu TCP ignoriert es unbekannte Pakete. Auf UDP beschränkt, sieht das Internet jedoch recht leer aus, da ein Großteil der Protokolle auf TCP basieren. Die Lösung dieses Problems stellt ein UDP-Tunnel dar, der die gesamte Kommunikation in UDP-Paketen verpackt und über den Server des Angreifers leitet.

UDP-Tunnel

Die einfachste Methode, einen UDP-Tunnel zu realisieren, bietet OpenVPN [4]. Normalerweise dient es dazu, verschlüsselte Verbindungen von A nach B über ein unsicheres Netz aufzubauen. Anleitungen über das Einrichten von OpenVPN finden Sie unter anderem im LinuxUser-Artikel “Durchgetunnelt” aus Ausgabe 02/2009 [5].

Zum Aufbau einer Verbindung gilt es vorab mit openvpn --genkey --secret /etc/openvpn/static.key einen Schlüssel zu erzeugen, den man sowohl auf dem Server als auch dem Client speichern. Anschließend genügt die Eingabe von

# openvpn --secret /etc/openvpn/openvpn.sec --dev tun1 --ifconfig 192.168.2.1 192.168.2.2 --daemon --port 2342

um den OpenVPN-UDP-Tunnel auf dem Server zu starten. Im kostenpflichtigen WLAN startet der Angreifer auf dem mit veränderter MAC- und IP-Adresse operierenden Client den Tunnelaufbau mit dem Aufruf

# openvpn --secret /etc/openvpn/openvpn.sec --dev tun1 --ifconfig 192.168.2.2 192.168.2.1 --remote dns.example.tld --daemon --port 2342

Die im Beispiel genannte Domain dns.example.tld steht als Platzhalter für die des VPN-Servers. Zwar erreicht der Angreifer nun den Server – die TCP-Kommunikation des legalen Clients wird jedoch durch das “doppelte” System im Netz massiv gestört. Mit der Firewall unterbindet der Angreifer deshalb sämtliche Kommunikation seitens seines Clients mit der Außenwelt (Listing 3). Einzige Ausnahme: der relativ ungefährliche UDP-Port 2342, den der Tunnel benutzt.

# iptables -A OUTPUT -o wlan0 -p udp --dport 2342 -j ACCEPT
# iptables -A INPUT -i wlan0 -p udp --dport 2342 -j ACCEPT
# iptables -A OUTPUT -o wlan0 -j DROP
# iptables -A INPUT -i wlan0 -j DROP

Danach gilt es, wie im Beispiel zuvor, die Routen anzupassen, damit das System die UDP-Pakete durch den Tunnelserver routet. Ein kleines Problem in diesem Setup stellt der nun nicht mehr erreichbare DNS-Server dar. Um es zu lösen, trägt der Angreifer in die Datei /etc/resolve.conf einfach einen anderen, im Internet verfügbaren DNS-Server ein, etwa den von OpenDNS (208.67.222.222) [6].

Fazit

Beide hier vorgestellten Methoden schaffen es zwar, die Einschränkungen kostenpflichtiger WLANs zu umgehen, sind aber mit erheblichen Einschränkungen verbunden. Beide benötigen einen ständig laufenden Server, der durch seine IP-Adresse den Nutzer gegenüber dem WLAN-Betreiber verrät. Die Variante mit dem UDP-VPN-Tunnel funktioniert zudem nur dann, wenn legitime Nutzer das WLAN zeitgleich nutzen.

Der DNS-Tunnel hingegen klappt zwar immer, erbringt jedoch nur einen Datendurchsatz von 3 bis 4 kByte/s. Nur unter sehr konstruierten Testbedingungen – wenn sich der Client, der Router (Access Point) und der Iodine-Server in einem kabelgebundenen Netzwerk befanden – ließen sich 30 kByte/s erzielen.

Entsprechend stellen beide Methoden letztendlich nur Machbarkeitsnachweise dar, die Angreifer in der Realität schwer umsetzen können und die relativ ineffizient arbeiten. Ein Versuch damit an eigenen Systemen erbringt jedoch oft wertvolle Hinweise auf vorhandene Sicherheitslücken und hilft so, diese zu schließen und Angreifer auszusperren.