Traçage Wi-Fi : applications et contre-mesures

GNU/Linux Magazine HS n° 084 | mai 2016 | Célestin Matte - Mathieu Cunche
Creative Commons
  • Actuellement 0 sur 5 étoiles
0
Merci d'avoir participé !
Vous avez déjà noté cette page, vous ne pouvez la noter qu'une fois !
Votre note a été changée, merci de votre participation !
Qu’est-ce que le traçage d’appareils (tracking) ? Pourquoi est-il aussi simple de nos jours ? Quelles en sont les applications utiles ? Quelles sont les contre-mesures applicables ? Cet article se propose de répondre à ces questions.

L’avènement des appareils communiquant induit un important transit d’informations sur les ondes radio. Si une partie de cette information est chiffrée par des mécanismes de sécurité (par exemple, WPA dans le Wi-Fi), il demeure une partie de ces informations qui n’est pas chiffrée et qui est disponible à qui veut bien tendre l’antenne. C’est en particulier le cas pour les en-têtes des trames Wi-Fi qui ne sont pas protégées par le chiffrement et qui contiennent un identifiant unique et permanent : l’adresse MAC.

Les appareils équipés d’une interface Wi-Fi ne se contentent pas de transmettre des paquets lorsqu’ils sont connectés : ils diffusent chaque minute plusieurs dizaines de trames contenant cette fameuse adresse MAC en clair. Cette particularité rend possible le traçage des appareils par des capteurs passifs collectant les informations transmises par nos appareils sur les canaux Wi-Fi. Nos smartphones, tablettes et ordinateurs portables se transforment alors en véritables balises portables qui permettent de nous suivre à la trace. Cette fuite d’information constitue un problème de vie privée indéniable [1] et le traçage Wi-Fi est d’ores et déjà à l’œuvre dans divers contextes.

Des entités commerciales collectent ces signaux pour mesurer, tracer et profiler des foules, tandis que les forces de l’ordre s’en servent pour retrouver des appareils volés. Les agences de renseignement ne sont pas en reste, puisque l’on sait depuis les révélations de Snowden que la NSA fait usage du traçage Wi-Fi et que l’adresse MAC fait partie des fameux selectors (éléments permettant d'identifier une personne comme un nom, une adresse e-mail ou encore une adresse IP) de son système PRISM.

Dans cet article, nous allons présenter les détails techniques à la source de cette menace, puis nous vous ferons réaliser l’ampleur de la menace en expliquant combien il est simple de collecter ces traces et de les exploiter. Finalement, nous présenterons plusieurs techniques permettant de réduire, voire empêcher le traçage de nos machines.

1. Contexte

1.1 Adresse MAC

L’adresse MAC est l’identifiant utilisé au niveau de la couche liaison pour identifier de manière unique une interface réseau. Cet identifiant est utilisé au sein du protocole MAC (Medium Access Control) qui assure le partage d’un médium (câble Ethernet ou medium radio) entre plusieurs machines. L’hypothèse d’une unicité globale des adresses MAC est primordiale dans le protocole MAC et l’apparition de collisions (plusieurs appareils avec le même identifiant) empêcherait le bon fonctionnement du réseau.

Pour assurer l’unicité globale des adresses MAC, une procédure d’attribution à deux niveaux a été mise en place à l’échelle mondiale. L’organisme IEEE (Institute of Electrical and Electronics Engineers) est en charge de son bon fonctionnement. Il attribue à chaque fabricant d’interface réseau un espace d’adressage et lui délègue la tâche d’assurer l’unicité des adresses au sein de ce dernier, ce que le fabricant fera en attribuant chaque adresse à une seule interface réseau. Cette adresse unique est généralement gravée en dur dans le chipset de cette dernière. La liste des plages d’adresses allouées ainsi que le nom du fabricant correspondant est publiée par l’IEEE sur son site [2].

Concrètement, l’adresse MAC est un identifiant de 48 bits issu des spécifications de l’IEEE. Comme on peut le voir sur la figure 1, cet identifiant est divisé en deux parties : l’OUI et le NIC. L’OUI (Organisation Unique Identifier) constitue la partie haute de l’adresse, et correspond à l’identifiant attribué par l’IEEE au fabricant de l’interface. Le NIC constitue la partie basse de l’adresse et correspond à l’identifiant spécifique de l’interface au sein de la plage de l’espace d’adressage correspondant à l’OUI. La partie OUI de l’adresse inclut 2 bits aux fonctionnalités particulières : le bit multicast et le bit Locally Administered (LA). Le premier est utilisé dans des contextes particuliers qui ne nous intéressent pas ici. Le second sert à indiquer si l’adresse correspond à celle attribuée par le fabricant de l’interface, ou si au contraire elle a été modifiée par l’administrateur de la machine (d'où son nom : Locally Administered).

Figure 1 : Structure d’une adresse MAC avec OUI et NIC ainsi que les bits Multicast et Locally Administered.

1.2 Découverte de service dans le Wi-Fi

S’il paraît évident qu’un terminal Wi-Fi émet des trames lorsqu’il est connecté à un réseau, il n’en n’est pas de même lorsqu’il ne l’est pas. Et pourtant, un appareil Wi-Fi non connecté émet des trames plusieurs fois par minute. La raison : les mécanismes de découverte de service actif.

Afin de pouvoir se connecter à un point d’accès, les terminaux Wi-Fi ont besoin de connaître les réseaux à portée. C’est là qu’entrent en jeu les mécanismes de découverte de service passif et actif. Le mode passif consiste pour la station à écouter les trames beacons émises par les points d’accès. À l’opposé, dans le mode actif, c’est la station qui émet des trames proberequests auxquelles les points d’accès répondent par des proberesponses. S’ils sont globalement équivalents d’un point de vue fonctionnalité, il n’en est pas de même pour la consommation en énergie. En minimisant le temps d’écoute sur les canaux, le mode actif est plus économe en énergie et est donc largement utilisé par nos terminaux portables et mobiles.

Ainsi, nos smartphones, tablettes et ordinateurs portables dont le Wi-Fi est activé, mais non connecté à un point d’accès émettent plusieurs fois par minutes des probe requests, dont l’en-tête contient l’adresse MAC en clair. Dans certains cas, les probe requests contiennent les noms des réseaux (SSIDs) recherchés par l’appareil.

2. Traçage Wi-Fi

Quoi de mieux pour se rendre compte de l’ampleur de la menace que de se mettre dans la peau de l’espion ? Nous allons voir quelques outils qui permettent d’observer les appareils Wi-Fi à portée. Mais avant d'aller plus loin, rappelons que la collecte d'adresses MAC (une donnée à caractère personnel) n'est pas autorisée, sauf si l'on dispose de l'autorisation de la personne concernée (cf. loi Informatique et Libertés).

Avant toute chose, la capture des trames Wi-Fi nécessite une interface Wi-Fi en mode monitor. Pour cela, on fait appel à l’outil iwconfig. Pour une interface Wi-Fi nommée wlan0, les commandes suivantes permettront de la mettre en mode monitor :

$ sudo ifconfig wlan0 down
$ sudo iwconfig wlan0 mode monitor
$ sudo ifconfig wlan0 up

Si la suite aircrack-ng est installée nous pouvons tout de suite utiliser l’outil airmon-ng afin d’observer l’ensemble des stations à portée :

$ sudo airmon-ng wlan0

Une fois le logiciel lancé avec la commande précédente, trois pressions sur la touche <a> permettront de mettre l’affichage en mode STA, c’est-à-dire que seules les stations seront affichées. Les informations affichées sont l’adresse MAC des stations, l’indicateur de réception (RSSI) ainsi que les SSIDs diffusés par ceux-ci.

Il peut également être utile de récupérer cette information sous un autre format en affichant le contenu de l’ensemble des trames avec des outils d’analyse réseau comme tshark/wireshark ou tcpdump.

L’outil tshark est la version ligne commande de l’incontournable wireshark. Les deux outils utilisent le même format de filtre et les même dénominations des champs et des protocoles. Avec tshark, nous allons d’abord filtrer les trames de type probe requests grâce au filtre suivant : wlan.fc.type_subtype == 4. Puis nous allons afficher les champs qui nous intéressent : l’adresse MAC source (wlan.sa), la puissance du signal (radiotap.dbm_antsignal), ainsi que le SSID, s’il est présent (wlan_mgt.ssid) :

$ tshark -i wlan0 -Y "wlan.fc.type_subtype == 4" -T fields -e wlan.sa -e radiotap.dbm_antsignal -e wlan_mgt.ssid

De la même manière, il est possible d’utiliser tcpdump pour capturer et afficher les probe requests. Cependant, il n’est pas possible de sélectionner les champs particuliers pour l’affichage.

$ sudo tcpdump -i wlan0 -e type mgt subtype subtype probe-req

2.1 Retrouver le fabricant de l’appareil à partir de l’adresse MAC

À partir des données collectées via les méthodes précédentes, il est possible d’identifier le type d’un appareil, ou plutôt son fabricant. En effet, comme les adresses MAC diffusées contiennent l’OUI de l’appareil, il est possible de connaître son fabricant. Pour cela, on peut effectuer une recherche manuelle dans l’annuaire d’OUIs publié par l’IEEE [2], voire faire appel à des outils automatisant cette recherche. Il existe un certain nombre d’outils en ligne comme sur le site de wireshark [3].

Pour faire une résolution d’OUI en ligne de commande, on peut utiliser un script effectuant une recherche dans le fichier oui.txt préalablement téléchargé. Pour cela, on crée un script nommé oui_resolver.sh contenant le code suivant [4] :

#!/bin/bash
OUI=$(echo ${1//[:.- ]/} | tr "[a-f]" "[A-F]" | egrep -o "^[0-9A-F]{6}")
grep $OUI oui.txt

Ce script prend en paramètre une adresse MAC et affiche les informations relatives à l’OUI, c’est-à-dire le nom du fabricant :

$ ./oui_resolver.sh 00:11:8b:02:73:8f
00118B     (base 16) Alcatel-Lucent, Enterprise Business Group

Il est ainsi possible de déterminer le fabricant d’un appareil visible sur les ondes Wi-Fi. Cette première source d’information peut nous servir à inférer le type d’appareil pour effectuer une identification visuelle de celui-ci (par exemple, les appareils de la marque à la pomme sont facilement reconnaissables). Cette information peut également nous renseigner sur une cible : le système d’exploitation utilisé et les vulnérabilités potentiellement exploitables.

2.2 Statistiques des fabricants et des SSIDs

Les informations collectées via le Wi-Fi peuvent nous donner une bonne estimation de la distribution des types d’appareils dans une zone (à partir de l’adresse MAC) mais également de la fréquence des SSIDs. Nous allons maintenant décrire une procédure permettant de produire un graphique indiquant la distribution des OUIs parmi un ensemble d’appareils détectés via le Wi-Fi.

Il nous faut dans un premier temps nous constituer une petite base de données contenant les informations relatives aux probe requests. La commande suivante permet de stocker dans un fichier les informations principales des probes requests (notez l’apparition du séparateur ';') :

$ tshark -i wlan0 -Y "wlan.fc.type_subtype == 4" -T fields -e wlan.sa -e wlan_mgt.ssid -E separator=";" > probe_capture.dat

Ensuite, un petit coup de cut, sort et uniq permet de nous donner la liste des adresses MAC observées :

$ cut -f1 -d’;’ probe_capture.dat | sort | uniq

Il suffit alors pour chacune de ces adresses de résoudre l’OUI et de compter le nombre d’appareils par fabricant (vendor). Un peu de kung-fu bash à base de grep, cut, sort et uniq permet d’effectuer cette tâche. Après avoir téléchargé le fichier oui.txt sur le site de l’IEEE [2], enregistrez le script suivant dans un fichier nommé distribution_vendor.sh :

#!/bin/bash
mac_list=$(cut -f1 -d’;’ "$1" | sort | uniq)
VENDORS=()
for m in "$mac_list"
do
    oui=$(echo ${m//[:.- ]/} | tr "[a-f]" "[A-F]" | egrep -o "^[0-9A-F]{6}")
    vendor=$(grep $oui oui.txt | cut -f3)
    vendor="${vendor//[^[:alnum:]]/}"
    VENDORS+=(‘echo -e "$vendor\n"‘)
done
printf ’%s\n’ "${VENDORS[@]}" | sort -k2 |uniq -c | sort -k1 -r -n > vendor_distrib.dat

Ce script prend en paramètre un fichier de capture de probe requests et génère un fichier contenant le nombre d’appareils par fabricant par ordre décroissant.

$ chmod +x distribution_vendor.sh
./distribution_vendor.sh probe_capture.dat

Maintenant, passons au script gnuplot qui va permettre de générer notre graphique. Dans un fichier nommé plot_distrib_vendor.dem :

set ylabel "Nb appareils"
set autoscale
set xrange [-1:20]
set output "vendor_distrib.eps"
set term postscript eps  color
set xtics nomirror rotate by -60
set style fill solid border -1
set boxwidth 0.85
plot "vendor_distrib.dat" using 0:1:xtic(2) notitle with boxes

La génération du graphique se fait ensuite par l’exécution de la commande suivante :

$ gnuplot plot_vendor_distrib.dem

Si tout se passe bien, le fichier vendor_distrib.eps devrait contenir un graphique similaire à celui présenté en figure 2.

Figure 2

De la même manière, le script précédent peut être adapté pour calculer et afficher la distribution des SSIDs. Ceci peut être très utiliser lors d'une attaque de type Rogue-AP, qui consiste à créer un faux point d’accès avec un SSID populaire de façon à déclencher des connexions automatiques des terminaux alentours, afin de se placer en position d’homme-du-milieu.

2.3 Détection de présence

Le traçage n’a pas que des désavantages. En connaissant l'adresse MAC d'un appareil que l'on possède toujours sur soi (comme un téléphone), on peut s’en servir pour détecter sa propre présence dans un lieu assez facilement. Cela peut par exemple servir à réaliser des actions automatiquement lorsque l’on rentre chez soi. Pour un attaquant, cela peut servir à lancer une attaque lorsqu’un individu se trouve dans un lieu donné. Voyons comment allumer automatiquement son ordinateur en rentrant chez soi. L’idée est de détecter la présence d’un téléphone, et d’effectuer une action si c’est la première fois qu’on le voit depuis au moins une heure. Pour cela, nous aurons besoin d’une carte à faible consommation disposant d’une interface Wi-Fi supportant le mode monitor, comme une Raspberry pi avec un dongle Wi-Fi.

La première étape consiste à s’assurer que la carte mère de la machine cible supporte le Wake-On-LAN, standard Ethernet permettant d’allumer l’ordinateur par le réseau. L’option étant souvent désactivée par défaut, il faut l’activer dans le BIOS de la machine.

Il faut ensuite activer le mode monitor sur notre Raspberry pi, comme détaillé dans la section 2.

Le script permettant de réveiller l’ordinateur est le suivant :

#!/usr/bin/perl
 
use warnings;
use strict;
 
# PARAMETERS
my $TIME_TO_WAIT_TO_SEND_WOL = 3600; # 1 hour
my $MAC_ADDRESS = "adresse_mac_a_detecter";
 
# VARIABLES
my $previous_time = time;
my $new_time;
 
select STDOUT; $| = 1; # disable buffering
 
while (<>) {
        $new_time = time;
        if ($new_time > $previous_time + $TIME_TO_WAIT_TO_SEND_WOL) {
                print localtime(time) . " : ";
                system("wakeonlan", $MAC_ADDRESS);
        }
        $previous_time = $new_time;
}

Il suffit ensuite d’appeler le script wol.pl précédent avec la commande suivante, dans une session screen ou tmux, ou encore avec nohup :

$ sudo tcpdump -l -e -i wlan0 | grep adresse_mac_a_detecter | ./wol.pl

L’option -l de tcpdump désactive le buffering, ce qui permet d’éviter de retarder la détection du téléphone. L’option -e affiche les informations du header de chaque trame, qui contient l’adresse MAC. Les pipes nous permettent de ne pas exécuter notre script avec les droits root.

On s’assurera que le paquet wakeonlan est bien installé (wol sous ArchLinux). Idem pour tcpdump.

Si notre carte ne dispose pas d’une interface réseau supportant le mode monitor, il est également possible de fonctionner en mode managed, à condition que le téléphone à détecter se connecte automatiquement au réseau. On ne détectera alors plus les probe requests, mais les trames échangées par le téléphone associé au réseau. En fonction de la fréquence de ces trames (qui dépendront des applications installées et configurées sur le téléphone), on pourra avoir une réactivité potentiellement meilleure qu’en mode monitor. Pour ce faire, il faut, au lieu de passer la carte en mode monitor, configurer la connexion au réseau dans le fichier /etc/wpa_supplicant/wpa_supplicant.conf. Par exemple, pour un réseau en WPA :

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
 
network={
        ssid="nom_du_réseau"
        psk="mot_de_passe"
}

Puis associer la carte au réseau avec la commande suivante :

$ sudo wpa_supplicant -B -iwlan0 -c/etc/wpa_supplicant/wpa_supplicant.conf

L’option -B lance le démon en arrière-plan, -i sert à indiquer l’interface à utiliser et -c le fichier de configuration.

On lance ensuite le script avec tcpdump comme précédemment

On peut imaginer d’autres applications intéressantes, comme lancer une musique personnalisée à l’individu détecté (faites croire à vos colocataires que votre ordinateur est devenu Skynet !), détecter un intrus dans la pièce (attention, il peut copier votre adresse MAC)... Notons cependant que cette méthode ne permet pas une réactivité extraordinaire, le script pouvant mettre plusieurs minutes à repérer un téléphone. Pour des applications ne nécessitant pas de repérer la présence d’une personne précise, un détecteur de mouvement sera plus adapté.

3. Protections contre le traçage

Le traçage n’est pas une fatalité. Voyons des techniques permettant de limiter le traçage de notre appareil. La première permet l’utilisation d’adresses MAC aléatoires et temporaires au sein des mécanismes de découverte de réseaux, tandis que la seconde consiste à modifier directement son adresse MAC (par exemple à chaque redémarrage).

3.1 Adresse MAC aléatoire pour la découverte de réseaux

Une méthode de plus en plus répandue pour éviter le tracking est de changer fréquemment l’adresse MAC lors du scan actif de la découverte de réseaux. iOS utilise cette méthode depuis sa version 8, avec des conditions encore trop strictes pour que ce soit réellement utilisable. Windows l’utilise depuis sa version 10, et Android à partir de la version 6.0.

Sous GNU/Linux, cette méthode a été implémentée dans le noyau 3.18 pour le driver iwlwifi, et dans le noyau 4.5 pour le driver brcmfmac. Cela permet au driver de changer l’adresse MAC, mais ce changement n’est pas automatique, Il faut qu’un logiciel le provoque. On peut par exemple utiliser wpa_supplicant.

Tout d’abord, il convient de vérifier que le driver utilisé est bien iwlwifi. La commande suivante devrait renvoyer un lien vers iwlwifi :

$ readlink /sys/class/net/wlan0/device/driver

Il faut aussi une version récente de wpa_supplicant (version 2.3, datée d’octobre 2014).

Il faut également s’assurer que l’interface de contrôle est correctement configurée dans le fichier wpa_supplicant.conf. La ligne suivante doit s’y trouver :

ctrl_interface=/var/run/wpa_supplicant

Cela permet à l’outil wpa_cli de communiquer avec wpa_supplicant, ce qui nous permettra de lancer la commande suivante :

$ sudo ./wpa_cli mac_rand_scan all enable=1

On peut aussi configurer ce comportement dans le fichier de configuration de wpa_supplicant. Pour cela, il faut mettre l’option preassoc_mac_addr à 1 ou 2 (1 utilise une adresse complètement aléatoire, 2 génère une nouvelle adresse à partir d’un même OUI aléatoire). L’option rand_addr_lifetime permet de changer la durée de chaque adresse MAC aléatoire (60 secondes par défaut).

Notons que cette méthode ne supprime pas les SSIDs des probe requests envoyés. wpa_supplicant ne diffuse de toute manière pas les noms des réseaux ajoutés dans son fichier de configuration. En revanche, NetworkManager le fait pour ceux qu’il gère, et ce même si le changement d’adresse MAC est activé.

On pourra alors vérifier avec un wireshark ou un tcpdump lancé sur une autre machine que nos proberequests utilisent bien une adresse MAC aléatoire changée fréquemment (voir figure 3).

Figure 3 : Probe requests envoyées par un appareil utilisant des adresses MAC aléatoires grâce à la technique précédemment décrite.

3.2 Autres techniques

D’autres techniques sont possibles, et même utilisées par certains systèmes d’exploitation. L’une consiste à changer d’adresse MAC dès le démarrage de la machine, l’autre à attribuer une adresse différente par réseau connu. Une dernière méthode potentielle consiste à complètement désactiver le scan actif.

3.2.1 Changement d’adresse MAC au démarrage

La distribution orientée protection de la vie privée Tails génère une nouvelle adresse MAC aléatoire à chaque démarrage. Cela empêche de détecter un appareil dont l’identifiant est connu, mais pas de tracer un appareil sur une courte période de temps. Pour réaliser cela, les développeurs de Tails ont patché NetworkManager. Nous présentons plus bas une méthode pour effectuer cela avec macchanger.

3.2.2 Une adresse MAC par réseau

Windows 10 ajoute une protection supplémentaire : pour chaque nouveau réseau auquel l’ordinateur se connecte, une nouvelle adresse MAC est utilisée. Celle-ci est générée à partir de la vraie adresse MAC, du nom du réseau, d’un identifiant aléatoire et d’un sel de 256 bits. La formule précise est la suivante :

adresse = SHA-256(SSID, adresse MAC réelle , connectionId, secret)[:6]

Ainsi, l’appareil possède une adresse MAC propre au réseau auquel il se connecte, ce qui empêche un attaquant de voir l’adresse MAC réelle de l’appareil dès lors qu’il est associé à un point d’accès.

3.2.3 Désactivation du scan actif ?

Si désactiver complètement le scan actif semble être une idée séduisante, il n’y a à notre connaissance aucune méthode implémentée dans NetworkManager (voire dans les drivers des cartes Wi-Fi) ou sur Android pour y parvenir simplement. Comme indiqué plus haut, le scan actif est plus économe en énergie que le passif et sa désactivation complète n’est par conséquent pas envisagée par les constructeurs. Enfin, c’est l’unique moyen de se connecter aux points d’accès cachés (hidden access points), qui ne révèlent jamais leur présence par l’envoi de beacons.

3.3 L’outil macchanger

Nous avons vu dans la section 4.1.1 comment configurer le changement d’adresse MAC avec wpa_supplicant. Si l’on ne possède pas de version récente de cet outil, il existe une méthode un peu plus simple pour effectuer cette action : l’outil macchanger permettant de changer manuellement l’adresse MAC d’un appareil. Il dispose de nombreuses options, permettant de choisir si l’on veut générer une adresse complètement aléatoire, conserver l’OUI, utiliser un OUI précis, s’assurer que le bit locally-administered est correctement utilisé, etc.

Si l’adresse MAC d’une interface peut être modifiée à la ligne de commandes via ifconfig, l’outil macchanger permet d’automatiser cette procédure et de choisir entre plusieurs types d’adresse MAC. Plus particulièrement, macchanger permet de générer une nouvelle adresse MAC pour une interface réseau via plusieurs méthodes :

- Adresse totalement aléatoire (-r) : la nouvelle adresse MAC est complètement aléatoire, c’est-à-dire que l’intégralité des 6 octets de l’adresse est choisie aléatoirement, à l’exception des bits multicast et locally administered du premier octet ;

- Adresse aléatoire valide (-A) : idem que l’option précédente, à la différence que la partie gauche de l’adresse appartiendra à la liste des OUI enregistrés (ceux présents dans le fichier OUI.list) ;

- Adresse aléatoire valide du même type (-a) : idem que l’option précédente, à la différence que l’OUI choisi conservera le type de l’adresse (sans-fil ou pas) ;

- Adresse aléatoire du même OUI (-e) : la nouvelle adresse aléatoire conserve le même OUI que l’adresse précédente ; seul le NIC (les trois octets de droite) est changé.

De plus, avec la méthode totalement aléatoire (-r), l’option -b permet de forcer le bit locally administered à   et donc d’indiquer qu’il s’agit d’une adresse gravée en dur dans l’interface et non pas d’une adresse assignée localement par l’administrateur de la machine.

Par exemple, la commande suivante permettra d’assigner une adresse complètement aléatoire avec le bit locally administered à   :

$ sudo ifconfig wlan0 down

$ sudo macchanger -r -b wlan0
$ sudo ifconfig wlan0 up

Les méthodes décrites précédemment ne sont pas toutes équivalentes du point de vue de la discrétion. Pour ce qui est de la méthode « totalement aléatoire », l’absence de l’option -b génèrera une adresse avec le bit locallyadministered à 1, ce qui indiquera directement qu’il s’agit d’une adresse manipulée. De plus, même lorsque le bit locally administered est à  , une adresse totalement aléatoire a de fortes chances de tomber sur un OUI non-enregistré (à l’heure actuelle, environ 1% de ces OUI ont été assignés). Une adresse MAC ayant un OUI non-enregistré apparaîtra comme vraisemblablement manipulée.

Les méthodes -a et -A permettent de remédier à ce problème en assignant une adresse appartenant à un OUI enregistré. Cependant, l’option -A va fournir une adresse pouvant correspondre à n’importe quel type d’interface (Ethernet, ATM, etc.). Dans le cas (probable) où l’adresse ne correspond pas au type Wi-Fi, un observateur pourra rapidement reconnaître qu’il s’agit d’une adresse usurpée. Heureusement, la méthode -a permet de conserver le type de l’adresse et en choisira une de type sans-fil si tel est le cas.

Finalement, la dernière méthode (-e), qui consiste à uniquement changer la fin de l’adresse et à en conserver la partie haute, est probablement la moins repérable puisque l’interface conserve ainsi un OUI cohérent avec le modèle. Cependant, si le modèle et donc l’OUI original de l’interface sont peu communs, celle-ci sera facilement repérable. En effet, un appareil sera plus facilement repéré s’il utilise un OUI d’un fabricant obscur plutôt que l’OUI d’un fabricant populaire comme Apple, Samsung, Linksys ou Intel.

Il est possible d’automatiser l’appel à macchanger afin par exemple de renouveler les adresses des interfaces réseaux à chaque démarrage à la manière de Tails. Cette automatisation peut se faire facilement avec par exemple un unit systemd (méthode trouvée sur l’excellent wiki Arch Linux [5]). Pour cela, on crée un fichier /etc/systemd/system/macspoof@.service contenant les instructions suivantes :

[Unit]
Description=macchanger on %I
Wants=network-pre.target
Before=network-pre.target
BindsTo=sys-subsystem-net-devices-%i.device
After=sys-subsystem-net-devices-%i.device
 
[Service]
ExecStart=/usr/bin/macchanger -e %I
Type=oneshot
 
[Install]
WantedBy=multi-user.target

Il suffit ensuite d’activer le service pour chaque interface concernée, en ajoutant le nom de l’interface après le p. Par exemple, pour wlan0 :

$ sudo systemctl enable macspoof@wlan0.service

Au prochain redémarrage, l’adresse MAC devrait avoir changé. On pourra vérifier le bon fonctionnement de la méthode avec ifconfig ou la commande de contrôle du bon fonctionnement du service, qui devrait indiquer le changement d’adresse MAC :

$ sudo systemctl status macspoof@wlan0.service

Notons que macchanger ne fonctionne pas sur une interface active, ce qui peut rendre compliqué son automatisation dans certains cas.

Le wiki d’Arch Linux contient une page présentant d’autres méthodes (utilisant systemd-networkd, systemd-udevd. etc.) [5].

3.4 Désactivation automatique de l’interface Wi-Fi par geofencing

Une autre technique pour diminuer les problèmes de traçage est de tout simplement empêcher l’appareil de diffuser des informations lorsque cela n’est pas nécessaire. Encore faut-il pouvoir avoir un moyen de déterminer quand la diffusion d’information est pertinente. L’un de ces moyens possibles est de se servir des informations de géolocalisation pour décider d’allumer ou non l’interface Wi-Fi. En effet, quel intérêt il y a-t-il à envoyer une trame indiquant à tous que l’on recherche son réseau domestique quand on se trouve à 200km de chez soi ?

Des solutions comme Wi-Fi Matic [6] (application Android) permettent d’activer son interface Wi-Fi uniquement lorsque l’appareil se trouve dans un certain périmètre géographique (domicile, lieu de travail, etc.).

Sous Android, la géolocalisation s'effectue de trois manières différentes :

1) via le module GPS ;

2) par le positionnement relatif par rapport aux points d'accès Wi-Fi visibles ;

3) par le positionnement relatif par rapport aux cellules GSM avoisinantes.

Comme l'objectif est ici de limiter l'utilisation du Wi-Fi, il ne reste que le GPS (consommateur en batterie) et la géolocalisation par le réseau cellulaire (peu précise). Cependant la modeste précision de la géolocalisation cellulaire (quelques centaines de mètres environ) est suffisante pour réduire significativement le traçage via Wi-Fi. En effet, notre interface Wi-Fi se coupera dès que l'on sort de notre rue, ce qui est amplement suffisant dans la plupart des cas. Cette technique n’est évidemment disponible que pour des appareils disposant d’un système de positionnement autre que le Wi-Fi (GPS ou positionnement cellulaire) ; elle ne sera donc pas possible sur la plupart des ordinateurs portables.

Conclusion

Nous avons vu ce qu’était le tracking, du point de vue offensif aussi bien que défensif.

Si l’industrie met en place des mesures pour protéger les utilisateurs, leur mise en application est lente, et ne corrige qu’une partie des problèmes. Un utilisateur consciencieux réalisera son opsec en appliquant les mesures décrites dans cet article.

Cependant, il faut savoir que ces protections ne constituent qu’une première ligne de défense face à un problème bien plus complexe : en effet, les probe requests contiennent d’autres informations que l’adresse MAC, qu’il faudrait supprimer pour diminuer toute possibilité d’identification d’un appareil. Sans parler des attaques actives ainsi que des problèmes de traçage liés aux autres interfaces telles que le Bluetooth ou le cellulaire (coucou les IMSI-catchers)... Mais ceci est une autre histoire !

Références

[1] « Smartphone, Wi-Fi et vie privée : comment votre smartphone peut se révéler être votre pire ennemi », Misc Mag HS 008.

[2] http://standards-_oui.ieee.org/oui.txt.

[3] https://www.wireshark.org/tools/oui-_lookup.html.

[4] https://www.linux.com/community/blogs/133-_general-_linux/289193

[5] MAC address spoofing - archlinux wiki : https://wiki.archlinux.org/index.php/MAC_address_spoofing, consulté le 23/03/2016.

[6] https://play.google.com/store/apps/details?id=org.cprados.wificellmanager