Auf Mastodon ansehen
Es wird gezeigt, was diese Signale über per WLAN vernetzte Geräte und ihre Besitzer offenlegen können. Wie im ersten Teil kommt wieder eine Fritzbox zur Aufzeichnung und das Programm Wireshark zur Analyse der Daten zum Einsatz. Zur Einführung in diese Werkzeuge wird auf den ersten Teil verwiesen.
1. Tracking mit WLAN Probe-Requests
Endgeräte mit eingeschaltetem WLAN (Clients) können die verfügbaren Netze, Router (Access Points - AP) in der Umgebung bereits anzeigen, bevor sie sich mit einem davon verbunden haben, z.B. wenn Anwender einen Scan der verfügbaren Netze anstoßen. Dieser erste Kontakt zwischen Client und Router, vor der eigentlichen Datenverbindung, erfolgt über WLAN Probe-Requests. Clients senden diese mehr oder weniger kontinuierlich aus, gehäuft nach Abschalten des Flugmodus, wenn WLAN-Empfang eingeschaltet wird oder bei dem genannten Scan zu verfügbaren Netze. Aber selbst wenn ein Gerät mit einem Netz verbunden ist, können weiterhin Probe-Requests ausgesandt werden. Wenn ein Router empfangsbereit ist, antwortet er auf diese Anfrage mit einer Probe-Response. Über diesen Dialog erkennen Clients und Router einander und teilen sich die Daten, über die eine Datenverbindung aufgebaut werden kann. Um sich eindeutig identifizieren zu können, verfügen Clients und Router über Adressen, die MAC-Adressen (Media-Access-Control). Jedes vernetzbare Gerät hat eine eindeutige MAC-Adresse, die als Geräteadresse schon bei der Herstellung vergeben wird und sich über die Lebensdauer des Geräts nicht ändert.
Dies ist ein Problem für die Privatsphäre von Nutzern dieser Geräte. Nachdem WLAN mit der Verbreitung von Smartphones in mobilen Geräten Einzug hielt, dauerte es nicht lange, bis Geräte und ihre Nutzer über die mit den Probe-Requests verbreiteten MAC-Adressen getrackt wurden. Ein Tiefpunkt wurde 2013 erreicht, als ein Trackingunternehmen Mülleimer mit WLAN-Routern ausstattete und Millionen Smartphones und ihre Besitzer durch die Londoner Innenstadt und die Geschäfte dort verfolgte [1]. Das Problem wurde damals zusätzlich verschärft, weil Geräte Probe-Requests selbst dann sendeten, wenn Nutzer den WLAN-Empfang abschalteten. Dies betraf Stand 2018 sowohl Android- als auch Apple-Smartphones [2]. Ein Grund dafür ist, dass Probe-Requests auch zur WLAN-basierten Standortbestimmung verwendet werden, die Hersteller auch bei abgeschaltetem WLAN anbieten wollten.
Die Smartphonehersteller reagierten schließlich. Apple führte 2014 mit iOS8 die Randomisierung der MAC-Adressen von WLAN Probe-Requests ein, Android folgte kurz darauf ab V.10. Randomisierung bedeutet, dass in Probe-Requests nicht die Geräte MAC-Adresse verwendet wird, sondern eine regelmäßig zufällig generierte, neue MAC-Adresse. Sobald sich ein Gerät aber mit einem Netz verbindet, wird normalerweise wieder die Geräteadresse übergeben, die eine eindeutige Identifizierung ermöglicht.
2. Aufzeichnung mit der Fritzbox, Filterung mit Wireshark
Das Thema ist also komplex und Anwender können sich nicht sicher sein, ob die Probe-Requests, die von ihren diversen Geräten ausgehen, tatsächlich randomisiert sind, wie wirksam die Randomisierung ist und ob sich Probe-Requests durch die Schalter für WLAN und Flugmodus wirklich ausschalten lassen. Wer sicher gehen will, sollte sich die Probe-Requests seiner Geräte anschauen. Dies ist wieder mit einer Fritzbox auf einfache Weise möglich. Der Paketmitschnitt einer Fritzbox zeichnet alle Probe-Requests und -Responses auf, die von der Box empfangen und ausgesandt werden. Anders als im Fall des DNS-Protokolls, im ersten Teil der Reihe, ist nun aber nicht das Ziel, ein Gerät isoliert zu analysieren. Es liegt in der Natur von Probe-Requests, dass alle Clients und alle Router in Reichweite untereinander kommunizieren. Ziel ist, diesen ganzen Datenverkehr zu erfassen. Daher kommt in diesem Fall nicht meine alte Fritzbox 7330SL zum Einsatz, die nur im 2,4GHz-Band funkt, sondern der Hauptrouter im Heimnetz, mit dem sich alle Clients im Haushalt normalerweise verbinden und der auch im 5GHz-Band arbeitet. In meinem Fall ist das eine Fritzbox 6591 Cable. Das Debugmenü für Paketmitschnitte wird wie in Teil 1 beschrieben, erreicht. Mitschnitte werden parallel an 4 Schnittstellen der Fritzbox gestartet (siehe Teil 1, Abb.1):
AP (5GHz, ath1)-Schnittstelle 1
AP (2.4GHz, ath0)-Schnittstelle 1
Guest (5GHz, guest5)-Schnittstelle 1
Guest (2.4GHz, guest4)-Schnittstelle 1
Bei anderen Fritzboxen können diese Schnittstellen leicht unterschiedliche Bezeichnungen haben. Es handelt sich um die Logikschnittstellen der WLAN-Netze der Box (siehe Teil 1). Die Aufzeichnung erfolgt also im 5GHz- und 2,4GHz-Band sowohl im Haupt- als auch Gästenetz. Das Gästenetz wird hier eingeschaltet und mit aufgezeichnet um den Einfluss eines zusätzlichen Netzes zu beobachten, bei Geräten, die bereits mit einem anderen Netz verbunden sind. Um eine gute Übersicht aller Probe-Requests zu bekommen, dürfen die Aufzeichnungen eine Stunde oder länger laufen. Die 4 Schnittstellen ergeben 4 ETH-Dateien, die groß sein können. Daher ist beim Laden der Dateien wieder eine Filterung sinnvoll. Die Filter, einzugeben in die Kommandozeile von Wireshark, sind in diesem Fall:
wlan.fc.type_subtype == 0x0004 Filter für Probe-Requests
wlan.fc.type_subtype == 0x0005 Filter für Probe-Responses
Um Requests und Responses gleichzeitig zu sehen, können die beiden Filter mit einem logischen OR verknüpft werden:
wlan.fc.type_subtype == 0x0004||wlan.fc.type_subtype == 0x0005
Für logische UND-Verküpfungen von Filtern verwendet Wireshark "&&" anstatt "||".
Abb. 1: Ausschnitt eines Paketmitschnitts, gefiltert nach Probe-Requests und -Responses. MAC-Adressen und SSIDs sind gekürzt zur Wahrung der Privatsphäre.
In Abb. 1 ist ein mit der Fritzbox aufgezeichneter Mitschnitt von Probe-Requests und -Responses zu sehen. No., Time ist wie beim DNS-Verkehr die Nummer und Zeit in Sekunden des Datenpakets seit Beginn der Aufzeichnung. Source und Destination sind nun keine IP-, sondern die genannten MAC-Adressen der Geräte. In den Adressen tauchen Herstellernamen, wie Apple oder Intel auf. Der Grund ist, dass bei festen Geräteadressen die ersten 6 Stellen der 12-stelligen MAC-Adresse aus Hex-Zahlen die Herstellerkennung enthalten. Dieser Teil der Adressen ist in der Aufzeichnung bereits dekodiert und gibt Aufschluss auf den Gerätetyp. Hinter "Intel_.." steckt im allgemeinen ein PC, hinter "Apple_.." meist ein iPhone oder iPad, hinter "SamsungEl.." ein Androidgerät dieses Herstellers und hinter "AVM.." eine Fritzbox. Der Datenverkehr in Abb. 1 besteht also ausschließlich aus nicht-randomisierten, festen Geräteadressen, da bei Randomisierung keine Herstellerkennung gesendet würde. Broadcast erscheint als Destination, wenn der Probe-Request kein bestimmtes Ziel hat, daher alle Router zur Antwort aufgefordert sind. Jeder Probe-Request und -Response hat eine bestimmte Länge, Length in Byte. Die kurze Sequenz in Abb. 1 zeigt, dass diese Länge in aufeinanderfolgenden Probes für dasselbe Gerät konstant bleibt und über eine große Bandbreite von ca. 50 Bytes bis zu mehreren 100 Bytes zwischen Geräten variiert. Im Feld Info tragen die Probe-Requests eine Seriennummer. Wenn auf SN=182 SN=183 folgt, sind dies aufeinanderfolgende Probes desselben Geräts. Schließlich enthält Info die SSID, also den Namen des Netzes, an das sich der Probe richtet. Im Fall von SSID=Wildcard wird kein bestimmtes Netz angesprochen, der Client spricht alle Netze in Reichweite an. Wird ein SSID mit Namen genannt, wie im Beispiel "He**" sucht der Client eine Verbindung mit dem genannten Netz. Wird in Wireshark ein Datenpaket markiert, wird im Fenster links unterhalb der Datenpakete der "Payload", also Inhalt des Datenpakets angezeigt, im Beispiel in Abb. 1 also die 58 Bytes an Daten, die das Samsunggerät sendet. Wireshark erlaubt, auf beliebige Parameter eines Datenpakets zu filtern, indem der Parameter markiert wird und mit Rechtsklick im sich öffnenden Menü als Filter ausgewählt wird. In Abb. 2 wird auf den Parameter "OUI: 00:17:f2 (Apple, Inc.)" ein Filter angewandt, den Applegeräte nicht nur als MAC-Prefix, sondern auch als Vendor-Tag im Payload tragen. Wireshark erzeugt damit selbständig den Filter "wlan.tag.oui == 6130", der auf Applegeräte filtert.
Abb. 2: Filtern nach beliebigen Parametern eines Datenpakets in Wireshark. Apple signiert Probe-Requests mit dem Vendor Tag "Apple, Inc." im Payload
Im folgenden werden auf diese Weise Filter für Wireshark erzeugt, um auf MAC-Adressen oder Payload-Parameter wie "Supported Rates", "Extended Supported Rates" zu filtern. Wird im Payload ein Filter markiert, der die Überschrift eines ganzen Datenblocks ist, benutzt Wireshark den ganzen Datenblock unter der Überschrift als Filter. Auf diese Weise entstehen sehr komplexe Filter.
3. Tracking trotz MAC-Randomisierung
Soweit zur Einführung. Im ersten Schritt ist nun das Ziel eine Reihe bekannter Geräte an Hand ihrer Probe-Requests wiederzuerkennen, nachdem bei Ihnen die Randomisierung der MAC-Adressen eingeschaltet ist, die das ja verhindern soll. Zuerst werden die Probe-Requests wie in Abb. 1 ohne Randomisierung aufgezeichnet, um das Verhalten der enthaltenen Metadaten bei den verwendeten Geräten zu erkennen. Danach wird die Randomisierung eingeschaltet und versucht, jedes Gerät mit anderen Parametern der Probe-Requests, als der MAC-Adresse wiederzuerkennen (Fingerprinting). In meiner vorstädtischen Wohngegend empfange ich mit der Fritzbox die WLAN Probe-Requests von einer zweistelligen Anzahl von verschiedenen Geräten aus der Nachbarschaft. Die Aufgabe besteht also darin, diese ca. zweistellige Anzahl an Geräten per Fingerprinting, ohne MAC-Adresse, an Hand von Metadaten ihrer Probe-Requests, eindeutig zu unterscheiden und zu identifizieren. Für den Vergleich der Probe-Requests mit und ohne Randomisierung werden Geräte verwendet, auf die ich administrativen Zugriff habe:
3 Notebooks der Hersteller HP, MSI, Dell mit aktuellem Windows 11. Auf dem DELL Notebook wird zusätzlich Linux Mint 21 (Basis Ubuntu 22.04) gestartet.
2 Androidgeräte, Samsung mit Stock-ROM, Google Pixel 4a mit CalyxOS, beide Android 14
1 Apple iPad mit iPadOS 18.6.2
Die Geräte haben aktuelle Sicherheits- und Systemupdates, bis auf die beiden Androidgeräte, die zuletzt vor ca. 10 Monaten aktualisiert wurden. Die Hardware ist zwischen 9 Monaten und fünf Jahren alt.
Hier die Ergebnisse:
Bei allen Geräten hängt die Length der Probe-Requests nur von zwei Faktoren ab: Sie unterscheidet sich zwischen dem 2,4GHz- und 5GHz-Band, sowie zwischen Probes mit Wildcard und Probes an eine bekannte SSID. Ansonsten ist die Length auch nach Randomisierung unverändert. Somit ist die Length für Fingerprinting gut geeignet. Die Length kann als ein Hashwert, Maß für die Payload aufgefasst werden. Je mehr Metadaten eine Probe enthält, umso größer die Length.
Bis auf Linux Mint/Ubuntu senden alle Geräte auch nach Randomisierung die SSID des gespeicherten Netzes, mit dem sie sich verbinden wollen. Damit eignet sich auch die SSID sehr gut für Fingerprinting. Problematisch am Versenden von SSIDs ist zudem, dass diese in globalen Datenbanken gespeichert sind, um WLAN-basierte Standortbestimmung zu ermöglichen. Probes mit SSIDs legen daher Aufenthaltsorte des Geräts und seines Besitzers offen. Die weiteren Eigenschaften der Probe-Requests sind plattformabhängig:
3.1. PCs
Überraschend ist, dass alle drei Notebooks unter aktuellem Windows 11 ihre MAC-Adresse nicht randomisieren, wenn der Schalter dazu in den Windows-Einstellungen aktiviert wird. Beim HP-Notebook setzt die Randomisierung immerhin ein, wenn das verbundene Netz in den WLAN-Einstellungen aus "Bekannte Netzwerke verwalten" gelöscht und neu angelegt wird. Die DELL- und MSI-Notebooks senden auch nach Neuanlegen des WLAN-Netzes und selbst nach einem Reboot immer noch die Geräte MAC-Adresse in ihren Probe-Requests. Das HP-Notebook lässt sich dennoch auch mit Randomisierung leicht wiedererkennen. Length und SSID der Probe-Requests identifizieren es eindeutig.
Abb. 3: Diese Windows-Einstellung für WLAN bewirkt bei zwei der drei beobachteten Win 11 Notebooks - NICHTS! Beim dritten wird sie erst nach Löschen und Neuanlegen des aktuellen WLAN-Netzes wirksam.
In gnulinux.ch sollte Gnulinux nicht unerwähnt bleiben. Nach den enttäuschenden Ergebnissen mit Win 11 wurde auf dem DELL-Notebook Linux Mint/Ubuntu gestartet. Die Geräte MAC-Adresse bleibt unter Linux dieselbe, wie unter Windows, da sie hardwareabhängig ist.
Netzwerkmanager von Linuxdistributionen bieten im allgemeinen keine Einstellungen für die Randomisierung von MAC-Adressen. In gängigen Distros lässt sich aber das Tool "macchanger" installieren. Damit lässt sich auf dem DELL-Notebook die MAC-Adresse der Probe-Requests tatsächlich randomisieren. Das bedeutet, dass die nicht erfolgte Randomisierung unter Win 11 nicht an der Hardware, sondern eher an den Programmierkompetenzen in Redmond liegt! Ein weiterer positiver Unterschied zu allen anderen Plattformen ist, dass Linux Mint keine Probes mit Klartext-SSIDs versendet, sondern nur Wildcards. SSIDs können somit nicht zur Identifizierung von Netz und Gerät verwendet werden. Die Length der Probes verkürzt sich im Vergleich zu Win 11, es sind also weniger Metadaten enthalten. Die randomisierten Probes von Linux Mint lassen sich daher mit den hier verwendeten IDs, Metadaten nicht identifizieren, sondern nur durch Zugriff aufs Gerät und Auslesen der randomisierten MAC-Adresse oder durch aufwendigeres Fingerprinting als hier angewandt.
3.2. Android
Die zwei Androidgeräte wurden mit Standardrandomisierung gemessen, nicht mit der "nicht persistenten", stärkeren Randomisierung, die in den Entwickleroptionen aktiviert werden kann. Das Verhalten ist bei beiden Geräten vergleichbar. Die Geräte-MAC wird durch eine randomisierte Adresse ersetzt, die aber über längere Zeiträume bzw. solange das WLAN-Netz nicht gewechselt wird, statisch bleibt. Ein Gerät bleibt damit über begrenzte Zeiträume, z.B. die Dauer des Besuches in einem Einkaufszentrum auch über die randomisierte MAC-Adresse trackbar. Über Fingerprinting mit den drei Parametern Length, SSID sowie jeweils einem Parameter aus dem Payload lassen sich beide Geräte nach Randomisierung, ohne MAC-Adresse leicht identifizieren. Für diesen dritten Parameter aus dem Payload kann beim Samsung "Supported Rates", beim Pixel "Extended Supported Rates" verwendet werden.
3.3. Apple
Für das iPad ist die Randomisierung der MAC-Adresse in den Einstellungen auf "statisch" gesetzt. Das iPad wechselt damit, anders als Android mit nahezu jedem Probe-Request die MAC-Adresse. Zusätzlich wird die SN nicht linear hochgezählt, sondern gescrambled. Dieser positive Ansatz wird aber in mehrfacher Hinsicht wieder zunichte gemacht. Das Scrambling führt dazu, dass das iPad 4-stellige SN-Nummern bis in den 3000er Bereich hat, die bei wenigen anderen Geräten zu finden sind. Trotz der im Vergleich zu PCs und Android einheitlichen Hard- und Software, hat jedes Applegerät, das ich beobachten konnte, eine andere Length der Probe-Requests, womit Applegeräte untereinander unterscheidbar werden. Vor allem "signiert" Apple Probe-Requests seiner Geräte generell, soweit ich sehen konnte, mit dem Vendor Tag "Apple, Inc." (Abb. 2), auch bei Randomisierung. Die Probe-Requests von Apple-Geräten stechen daher hervor wie ein bunter Hund. Das untersuchte iPad lässt sich auch mit Randomisierung leicht über SSID, Length und das Vendor Tag wiedererkennen. Die Kompetenz in Sachen Anonymisierung scheint daher in Cupertino nicht besser zu sein als in Redmond. Apple erweckt hier nicht zum ersten Mal den Eindruck, als ob im Konzern hinter jedem Ingenieur für Datensicherheit eine Person vom Marketing hinterherliefe, die gerne hier ein Firmenlogo platzierte, dort einen zusätzlichen Dienst, ein zusätzliches Nutzererlebnis verkaufte und damit die Arbeit für Sicherheit und Datenschutz wieder zunichte machte. Siehe dazu auch meinen hier erschienenen Artikel zur iPhone-Sicherheit [3].
Zusammenfassend bietet von den untersuchten Betriebssystemen nur Linux mit dem Tool "macchanger" eine gute Randomisierung der WLAN Probe-Requests. In Abb. 4 ist eine Übersicht der Ergebnisse.
Abb. 4: Vergleich der Eigenschaften von WLAN Probe-Requests mit und ohne Randomisierung der MAC-Adresse, für verschiedene Geräte und Betriebssysteme, sowie die Parameter, mit denen ein Gerät bei Randomisierung, ohne MAC-Adresse eindeutig identifiziert werden kann.
4. Tracking fremder Geräte und Netze
Mit den an bekannten Geräten gewonnenen Erkenntnissen zu Probe-Requests ist im zweiten Schritt nun das Ziel herauszufinden, was Probe-Requests unbekannter Geräte verraten, die in der Nachbarschaft, in Reichweite der Fritzbox senden und deren Probes daher von der Fritzbox erfasst werden. In Abb. 5 ist eine Auswahl solcher Geräte aufgelistet. Um die Privatsphäre meiner Nachbarn zu schützen, sind eindeutige Kennungen, wie SSIDs, MAC-Adressen geändert oder verkürzt.
Abb. 5: Auswahl an Geräten, die sich über WLAN Probe-Requests in Reichweite einer Fritzbox eindeutig identifizieren lassen. Neben den Geräten werden die Netze offengelegt, mit denen sie verbunden sind. SSIDs, MAC-Adressen zum Schutz der Privatsphäre verändert, gekürzt.
Zur Identifikation der Geräte in Abb. 5 werden nur SSID, Length und im Fall von Applegeräten der Vendor Tag im Payload der Probe-Requests verwendet, also nur ein kleiner Teil der zum Fingerprinting zur Verfügung stehenden Metadaten der Probe-Requests. Die Herstellerkennung gibt Hinweise, um welchen Gerätetyp es sich handelt, da die meisten Hersteller nur wenige Produkttypen anbieten. Die Herstellerkennung "Sonos" z.B. deutet mit einiger Sicherheit auf einen vernetzten Lautsprecher.
Ein bunter Strauß an Geräten kann identifiziert werden, von Smartphones, PCs, Routern, TV-Boxen/Dongles, Servern bis hin zu Smart-Homegeräten und Beifang, wie vorbeifahrenden oder geparkten PKWs. Auffällig ist, dass alle diese Geräte, bis auf ein einziges Applegerät keine randomisierte MAC-Adresse verwenden. Tatsächlich scheinen randomisierte MAC-Adressen nur bei Smartphones, Tablets unter Android und iOS Verbreitung gefunden zu haben, da dieser Gerätetyp im Vergleich zu seiner Verbreitung in der Liste unterrepräsentiert ist. Die Defizite von Windows-PCs bei der Randomisierung wurden bereits gezeigt, der ganze Rest an "smarten" Geräten scheint mehrheitlich überhaupt keinen Versuch der Randomisierung zu unternehmen. Über die gesendeten SSIDs lassen sich die WLAN-Netze rekonstruieren, mit denen sich die Geräte verbinden. Bei drei Netzen können jeweils zwischen 4 und 6 zugehörige Geräte erkannt werden, die untereinander vernetzt sind.
Mit diesen Informationen, die auf einfache Weise in einem Router, wie einer Fritzbox anfallen, könnten weitergehende Cyberangriffe vorbereitet werden:
- In einem derart offen gelegten Netz könnte ein Angriff auf das unsicherste Gerät gestartet werden, z.B. ein Smart-Home Gerät, das schon lange ohne Sicherheitsupdates ist. Von dort könnte ein Angreifer von besser geschützten Geräten, wie PCs, NAS-Servern im Heimnetz freigegebene Dateien abgreifen oder Schadcode auf diese aufspielen.
- Die Anwesenheit von Personen im Bereich eines Netzes kann über ihre mobilen Geräte verfolgt werden, solange der WLAN-Empfang ihrer Geräte aktiviert ist. Wie gezeigt, ist dies durch Fingerprinting selbst bei randomisierten MAC-Adressen leicht möglich. Eifersüchtige Partner oder neugierige Arbeitgeber müssen keine Detektive anheuern um den Aufenthaltsort von Partnern, Arbeitnehmern zu überwachen. Es reicht, in der Nähe vermuteter Aufenthaltsorte einen laufenden Router aufzustellen, z.B. in einem geparkten Wagen oder abgestellten E-Bike. Einen Router zu betreiben ist nicht einmal illegal, im Gegensatz zu einem IMSI-Catcher ohne Lizenz dafür.
5. Die Schwierigkeit, Probe-Requests abzuschalten
Das wirksamste Mittel, dieser Überwachung zu entgehen ist, WLAN Probe-Requests abzuschalten. Wie bereits einleitend beschrieben, ist aber gar nicht so klar, in welchen Betriebszuständen eines Geräts diese tatsächlich abgeschaltet sind, da sie auch zur WLAN-basierten Standortbestimmung genutzt werden. Für iPhones wurde z.B. nachgewiesen, dass der WLAN-Knopf in den Schnelleinstellungen Probe-Requests nicht abschaltet, wenn er auf "Aus" gesetzt wird [2]. Dies geschah zum Zeitpunkt dieser Studie 2018 erst, wenn das WLAN in den Einstellungen abgeschaltet wurde. Jeder Hersteller kann seine Geräte zudem etwas anders programmieren. Anwender, die sicher gehen wollen, sollten daher selbst überprüfen, in welchen Betriebszuständen Probe-Requests gesendet werden. Das kann wieder mit einem Paketmitschnitt auf der Fritzbox erfolgen, indem die Probe-Requests von Clients mit unterschiedlichen "WLAN aus" Einstellungen aufgezeichnet werden. Dazu sollte das WLAN-Netz der Fritzbox im zu untersuchenden Client gespeichert sein und zur eindeutigen Identifizierung sollte die MAC-Randomisierung für dieses Netz abgeschaltet sein. Ich habe diese Aufzeichnung für zwei der genannten, eigenen Geräte beispielhaft durchgeführt, für das iPad und das Android-Tablet von Samsung. Um Probes zu provozieren wurde bei beiden Geräten die Standortbestimmung eingeschaltet. Bei Android wurden unter Einstellungen / Standortdienste die WLAN- und Bluetooth-Scans aber abgeschaltet. Durch diese würden trotz abgeschaltetem WLAN ausdrücklich Probe-Requests abgesetzt [2]. Im Router waren Haupt- und Gästenetz aktiv und jedes Gerät war mit je einem dieser Netze verbunden. Nach Start des Paketmitschnitts in beiden Netzen wurden die Geräte in verschiedene Betriebsmodi versetzt:
1. Flugmodus an, bei eingeschaltetem WLAN für ca. 25min (iPad), 70min (Android)
2. Nur iPAD: Flugmodus aus, WLAN aus über Schnelleinstellungen für ca. 45min
3. WLAN aus in den Einstellungen für ca. 7,5h
Beim Wechsel zwischen diesen Zuständen wurden WLAN und Flugmodus kurz mehrfach ein- und ausgeschaltet, um im Mitschnitt zu diesen Zeitpunkten Probes zu provozieren. Abb. 6 zeigt ein Ergebnis für das iPad als Beispiel.
Abb. 6: Aufgezeichnete Probe-Requests des iPad im verbundenen Netz, 5GHz in den Zuständen "Flugmodus" (1680s-3140s), "WLAN aus Schnelleinstellungen" (3200s-5800s), "WLAN aus Einstellungen" (6000s-30120s). Im Flugmodus werden bei 2186s und 2195s Probes gesendet, bei WLAN aus nicht. Das iPad randomisiert teilweise auch bei abgeschalteter Randomisierung (Probes No. 148-324)
Die Ergebnisse sind für das iPad und Samsung-Tablet vergleichbar, über beide WLAN-Netze und Frequenzbänder. Beide senden trotz aktiviertem Flugmodus, bei eingeschaltetem WLAN Probe-Requests. Sobald das WLAN ausgeschaltet ist, werden keine Probe-Requests gesendet. Dies gilt beim iPad auch, wenn das WLAN nur über die Schnelleinstellungen abgeschaltet wird. Apple hat in diesem Punkt seit 2018 offensichtlich nachgebessert. Falls unter Android aber die Standortbestimmung über WLAN- (und Bluetooth-) Scans eingeschaltet ist, sind trotz abgeschaltetem WLAN Probe-Requests zu erwarten.
6. Fazit
Seit nach 2010 der Smartphoneboom begann, ist bekannt, dass sich mobile Geräte und damit ihre Besitzer über WLAN Probe-Requests tracken lassen. Die einzige größere Maßnahme der Gerätehersteller dagegen, die Einführung randomisierter MAC-Adressen, hat sich in den hier durchgeführten Messungen als Placebo herausgestellt. Neben der MAC-Adresse enthalten Probe-Requests andere Daten, die über Fingerprinting die eindeutige Erkennung eines Gerätes erlauben. Hier im Artikel konnte mit 2 bis 3 Parametern eine eindeutige Identifizierung unter einer zweistelligen Anzahl an Geräten mit einem einfachen Heimrouter durchgeführt werden. In den ca. 100 Byte an Daten eines Probe Requests lassen sich aber weit mehr als 2 bis 3 Parameter für Fingerprinting finden. Mit mächtigeren Routern als einer Fritzbox lassen sich zusätzliche, gerätespezifische Charakteristika erheben, z.B. auf der zeitlichen Ebene die Burstlänge und Frequenz von Probe-Requests [4]. Damit ist weiterhin ein Szenario denkbar, wie das zitierte Beispiel der "smarten" Mülleimer in der Londoner Innenstadt, bei dem auch sehr viel mehr Geräte als in meiner direkten Nachbarschaft individuell getrackt werden können. Ein weiteres Armutszeugnis der Industrie ist, dass 10 Jahre nach Einführung der MAC-Randomisierung diese im wesentlichen immer noch auf Smartphone-Betriebssysteme beschränkt ist. Eine positive Ausnahme ist Linux mit dem "macchanger", das die geringste Menge an verwertbaren Daten für Fingerprinting versendet.
Grundsätzliche Verbesserungen für eine bessere Privatsphäre bei Probe Requests kann nur die Industrie umsetzen, beispielsweise durch
- Verzicht auf das Versenden von SSIDs gespeicherter Netze.
- Durchgehende Einführung einer funktionierenden MAC-Randomisierung über alle WLAN-fähigen Geräte.
- Standardisierung der Probe-Requests über alle Hersteller, Geräte um sie ununterscheidbar zu machen und Verzicht auf herstellerspezifische Tags.
Die Hoffnung, dass eine Industrie, die ihr Geld mit Tracking verdient, derartige Maßnahmen umsetzt, könnte aber vergeblich sein. Nutzer haben bis dahin nur begrenzte Möglichkeiten, sich Tracking durch WLAN Probe-Requests zu entziehen:
- Der einfachste Schutz ist, WLAN abzuschalten, insbesondere unterwegs. Wie gezeigt reicht der Flugmodus dafür nicht aus. Das Abschalten von WLAN-Scans zur Standortbestimmung kann zusätzlich notwendig sein.
- Zu Hause mehrere getrennte WLAN-Netze aufspannen, die untereinander keinen Datenaustausch erlauben, z.B. eines für unsichere Smart-Home Geräte, ein zweites für Geräte, die nur Internetzugriff benötigen wie Gaming- oder Streamingboxen und ein drittes, mit höchster Sicherheitsstufe für Geräte, die untereinander Daten austauschen, wie PCs und NAS-Server. Umsetzen lässt sich diese Aufteilung der Netze durch Verwenden des Gästenetzes und zweiten, dritten Routern.
- Wenn möglich Geräte ohne WLAN vernetzen, über LAN, Powerline, ...
- Auf Client-Geräten möglichst wenig WLAN-Netze dauerhaft speichern. SSIDs gespeicherter Netze werden versendet.
- SSID-Namen der eigenen WLAN-Netze regelmäßig ändern.
Das Unterdrücken der SSID im Router ist dagegen kontraproduktiv. Clients MÜSSEN in dem Fall die SSID aussenden, um sich mit dem Router zu verbinden. Clients werden also einfacher trackbar. Wer sich mit einem "kostenlosen" WLAN verbindet, muss sicher davon ausgehen, über die Dauer der Verbindung getrackt und bei jedem erneuten Login wiedererkannt zu werden.
Zuletzt sei noch Bluetooth erwähnt, dessen Protokoll zum WLAN-Protokoll sehr ähnlich ist und das daher vergleichbare Schwächen in Bezug auf Tracking hat. Auch Bluetooth benutzt MAC-Adressen als IDs. Deren Randomisierung ist noch weniger weit fortgeschritten und die Bluetooth- und WLAN MAC-Adressen eines Gerätes unterscheiden sich häufig nur in einer Stelle, wie geneigte Leser in den Einstellungen ihrer Geräte überprüfen können. Somit besteht die Möglichkeit des Cross-Trackings über WLAN- und Bluetooth-Signale desselben Gerätes. Auch für Bluetooth gilt daher, dass Verfolgung nur sicher durch Abschalten vermieden werden kann.
Soviel zu den Defiziten des WLAN-Protokolls in Bezug auf Privatsphäre und Sicherheit. Eine gewöhnliche Fritzbox und ein PC mit Wireshark ist alles was für diese Analyse der WLAN Probe-Requests und die vorausgehende zum DNS-Protokoll notwendig war. Die hier vorgestellten Ergebnisse sollten nicht als allgemeingültig verstanden werden, sondern vielmehr als Ermutigung, einmal selbst zu überprüfen, was und wohin eigene Geräte funken. Wie gezeigt, kann das von Plattform zu Plattform sehr unterschiedlich sein. Das Internet verwendet hunderte von weiteren Protokollen. Interessierten Besitzern einer Fritzbox bleibt also ein weites Gebiet für Analysen und Entdeckungen!
Quellen
[1] https://arstechnica.com/information-technology/2013/08/no-this-isnt-a-scene-from-minority-report-this-trash-can-is-stalking-you/
[2] C Matte, 2018, https://inria.hal.science/hal-01575519/file/Update_Wi_Fi_off_and_yet_probing%20(1).pdf
[3] https://gnulinux.ch/iphone-sicherheit-ein-haus-aus-stein-oder-stroh-ist-grapheneos-besser
[4] R. Rusca et al, 2025, https://iris.polito.it/retrieve/handle/11583/2972106/0f3c5710-af86-452d-be14-a01fe2d97319/What_WiFi_Probe_Requests_can_tell_you.pdf
