In zwei Jahrzehnten als Vollzeitnerd hat sich der ein oder andere Text angesammelt, mit denen ich unseren Azubis versucht habe, Grundlagen über unseren Job (TCP/IP, aber auch bevorzugt Telefonie) zu erklären.

Das stelle ich hier, wann immer ich so einen Text nochmal irgendwo finde, zusammen. Diese Texte haben nicht den Anspruch, zu 100% exakt zu sein (sondern manches ist des besseres Verständnisses wegen vereinfacht worden). 

Heute:

Nach all der Theorie rund um IP-Grundlagen wird es Zeit, sich das in der Praxis einmal anzugucken.

Bob arbeitet inzwischen bei der "Innovativ und Gut GmbH" in der Entwicklung. Alice ist beim Mitbeweber "Klauen und Klonen AG" gelandet. Auf einer Fachtagung sind sie beide im gleichen Hotel untergebracht.

Alice interessiert sich sehr für Bobs Arbeit. Ihr Ziel ist es,

• ihn an der Einwahl in sein Firmen-VPN zu hindern
• und sein Outlook unbrauchbar zu machen, 
• damit er seine Mails per Webmail abfragen und auf eine von Alice bereitgestellte Phishing-Seite hereinfallen soll.

Gucken wir mal, wie sie das machen könnte.

Im ersten Step versucht sie, die Hostnamen "vpn.innoundgut.de", "mail.innoundgut.de" und "webmail.innoundgut.de" auf andere IPs zu lenken.

Versuch 1: DNS-Poisoning

Als erstes konfiguriert sie auf ihrem Firmen-Nameserver eine Subdomain

alice-test.klauen-und-klonen.de.   IN CNAME  vpn.innoundgut.de.

trägt die Zone "innoundgut.de" auch auf ihrem Firmennameserver ein und setzt da einen A-Eintrag auf ihren Bastelserver:

*.innoundgut.de.  IN A 89.90.91.92

Jetzt macht sie vom Hotel-WiFi aus ein "ping alice-test.klauen-und-klonen.de". Ihre Hoffnung: Der Hotel-DNS-Server wird ihren Firmen-DNS-Server fragen, bekommt als Antwort "is an alias for: vpn.innoundgut.de"; weil ihr Firmenserver glaubt, auch für letzteres zuständig zu sein, wird er die IP dazu (89.90.91.92) direkt mitliefern. Klappt leider nicht, der Hotel-DNS ist darauf nicht reingefallen, das ping führt zur richtigen IP-Adresse. Schade.

Versuch 2: DHCP-Hijacking

Ihr zweiter Ansatz ist, die DHCP-Anfrage von Bobs Notebook abzufangen und zu manipulieren. Dazu sammelt sie erstmal Informationen über das Hotel-WiFi:

• Da das ein kleines Hotel ist, lautet die Subnet mask 255.255.254.0, es gibt also nur maximal nur 512 IP-Adressen
• Sie lädt sich einen Network Scanner runter und scannt das Netz.  
• Jetzt sucht sie sich aus den offensichtlich freien IP-Adressen eine raus, die Bob gleich bekommen soll.

Nun muss sie in etwa den Zeitpunkt abschätzen, wann Bob sein Notebook ins Hotel-WLAN einwählt. Passend zu diesem Zeitpunkt sind die nächsten Schritte:

• Ihr PC schickt ein paar tausend "DHCPDISCOVER"-Nachrichten mit unterschiedlichen und gefälschten MAC-Adressen als Absender. Der Hotel-eigene DHCP-Server wird entweder unter der Last zusammenbrechen. Oder er hält tapfer durch, hat aber irgendwann keine IPs mehr zu vergeben, weil er jede der Fake-Anfragen mit einer freien IP beantwortet und diese erstmal ein paar Sekunden reserviert. So oder so: Wenn dann Bob online geht, wird er vom Hotel keine IP-Adresse mehr zugewiesen bekommen. (Übrigens: Das wäre aufgrund der gefälschten MAC-Adressen der einzige Punkt an dieser Geschichte, wo Alice mit Windows-Standardmitteln nicht weiterkommt, sondern etwas tiefer in ihren PC eindringen muss.)
• Gleichzeitig startet sie auf ihrem eigenen PC einen DHCP-Server, der nur darauf wartet, Bob eine IP zuzuweisen. IP ist die, die sie sich vorher ausgesucht hat, Subnet mask passt zum Hotel-WLAN. Als DNS-Server bekommt er ihren manipulierten Firmen-DNS genannt und als Gateway ihr Notebook (dort läuft der Standard-Windows-Routingdienst, d.h. der leitet die Anfragen einfach ins Internet weiter, aber Bobs Verkehr läuft eben dann durch Alice' Notebook durch und sie kann zumindest die unverschlüsselten Protokolle mitlesen).

Aber je länger sie drüber nachdenkt, desto weniger Lust hat sie, die ganze Zeit am Türspion zu warten, bis Bob sein Hotelzimmer gegenüber von ihr betritt, nur um den Zeitpunkt seines WLAN-Verbindungsaufbaus abzupassen. Die Hotelbar reizt sie eher.

Versuch 3: Fake-WLAN

Also die einfachste Methode: Sie spannt ein eigenes WLAN auf. Dafür genügt ein 20 Euro teurer WLAN-Router, wie ich ihn in der Rubrik Reisetechnologie vorgestellt habe. Den steckt sie in die Steckdose an der Zimmertür, loggt sich darauf ein, verbindet ihn mit dem Hotel-WLAN und überlegt noch, welchen Namen sie dem Router-WLAN geben soll,

• entweder einen, der zum Hotel passt. Da das das WLAN mit der besten Empfangsstärke ist (kein Wunder, der Router ist ja fast vor seiner Zimmertür) wird Bob das bevorzugen.
• oder ein WLAN, das Bobs PC schon kennt (und dann entweder das ebenfalls Bob bekannte Passwort, oder kein Passwort). Da sie weiß, dass Bob gerne Telekom-Hotspots nutzt, nennt sie ihr WLAN: "Telekom"

Der WLAN-Router selbst spielt DNS-Relay. Welchen Server er abfragen soll, kann Alice konfigurieren und trägt ihren vorher manipulierten Firmenserver ein.

Bob schaltet sein Notebook ein, und das fackelt nicht lange: Es findet ein WLAN, das es bereits kennt ("Telekom", [x] automatisch verbinden) und Bob ist sofort online. Bob bekommt eine 192.168.1.irgendwas-IP zugewiesen, auch als Nameserver die 192.168.1.1 (Alice' Router - d.h. er würde nicht mal sehen können, dass er mit Alice' Firmen-DNS verbunden ist).

Jetzt klickt er in seinem VPN-Client auf "Verbinden" ... klappt nicht. Der manipulierte DNS-Server (mit dem * IN A 89.90.91.92-Eintrag) sorgt dafür, dass sich sein VPN-Client mit Alice' Testserver verbinden will, und da läuft gar kein VPN-Service. Bob wird nicht stutzig, denn dass VPN in öffentlichen WLANs nicht funktioniert, passiert ab und zu schon mal. 

Dann startet er sein Outlook. Das verbindet sich mit "mail.innoundgut.de", ein Hostname, der auch wieder auf Alice' Server zeigt, wo gar kein Mailserver antwortet. Das Outlook zeigt eine Fehlermeldung.

Bob ist irritiert und versucht es per Webmail aus seiner Lesezeichen-Leiste. Wieder landet er auf Alice' Server, der auch auf Port 443 (=HTTPS) nicht antwortet. Denn: Würde der Server auf 443 antworten und eine Seite ausliefern, dann bräuchte er ja ein "passendes" SSL-Zertifikat (was Alice nicht hat). Und da würde Bobs Browser eine Verbindung verweigern und Bob würde stutzig werden.

So aber bekommt Bob auch hier nur eine Fehlermeldung, dass die Seite nicht erreichbar sei.

Bob ist langsam genervt und vermutet, dass er sich im Hotel-WLAN erstmal anmelden muss. Also ruft er den Browser auf und öffnet irgend eine beliebige Webseite (z.B. spiegel.de) und erwartet, dass er jetzt auf eine "bitte bestätigen Sie die AGB und geben Sie Ihre Zimmernummer ein"-Landingpage kommt.

Doch: Spiegel online funktioniert. Na also: Er tippt in der Adressleiste seines Browsers nun "webmail.innoundgut.de" ein und drückt Enter.

Was nun passiert, hängt vom Browser ab:

• Ältere Browser haben jahrzehntelang das als http-URL aufgefasst. Also rufen die auf: http + webmail.innoundgut.de - Weiter im Text.
• Neuere Browser haben eine "https first"-Regel. Also versucht der Browser automatisch, sich per https zu verbinden. Das aber hatten wir ja eben schon (per Lesezeichen probiert): Alice Testserver antwortet nicht auf Port 443, damit es nicht zu einem Zertifikatsfehler kommt. Da Bob nur "webmail.innoundgut.de" ohne http/https davor eingetippt hat, ist das für den Browser jetzt kein Fehler, dass die Seite nicht antwortet, sondern der Browser probiert es per http - Weiter im Text.

Weiter im Text heißt: Der Browser ruft also jetzt die Seite webmail.innoundgut.de per http auf. Als IP-Adresse kennt er die von Alice Testserver, 89.90.91.92. Und da erwartet ihn ein Webserver, der per http antwortet:

301 Moved permanently
Location: https: // webmail.innnoundgut.de/

Als eine Weiterleitung auf eine https-URL. Und der folgt sein Browser. Und Bob bekommt eine Login-Seite seines Firmen-Webmail-Tools, der Browser zeigt ein Schloss an (weil die Verbindung einerseits verschlüsselt ist und auch mit dem richtigen Gegenüber, der ein passendes SSL-Zertifikat hat). Er loggt sich ein, Benutzername, Passwort, 2-Faktor-Authentifizierung mit einem am Handy generierten Code, er überfliegt kurz den Posteingang, klickt auf "Logout", sieht die Logout-Seite, klappt das Notebook zu und geht runter in die Hotelbar.

In Wahrheit hat er mit einem zweiten Server von Alice gesprochen, der auf eine Domain so ähnlich wie die seines Arbeitgebers hört (das zusätzliche n, was bei der 302-Weiterleitung dazugekommen ist, hat er übersehen). Und der wie ein Proxy das Webmail-Tool einfach weitergeleitet hat. Bis auf das Logout-Kommando, das hat er nicht weitergeleitet, so dass Alice über diesen Proxy weiterhin im Webmail eingeloggt ist und sich nun ungestört in Bobs E-Mail-Verkehr umgucken, aber auch z.B. "Passwort-vergessen"-Funktionen auf anderen Webseiten aufrufen kann. 

Am nächsten Morgen, wenn sie das Hotel verlässt, steckt Alice den WLAN-Router noch in die Doppelsteckdose hinter der Minibar und lässt ihn hinter dem Schreibtisch verschwinden. In den nächsten Monaten freuen sich die nächsten Gäste über besseren WLAN-Empfang, und Alice kann die DNS-Anfragen der Gäste auf ihrem DNS-Server mitlesen und bei Bedarf umlenken.