Tag der offenen Tür

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].