Tag der offenen Tür

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