Désanonymisation du jeu de données MAWI

MISC n° 099 | septembre 2018 | Stefano Secci - Agathe Blaise - Mathieu Bouet - Vania Conan
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 !
Dans le monde de la recherche, le fait de pouvoir travailler sur des données réelles est très important. Pourtant, les jeux de données de ce genre sont très rares, car des informations confidentielles peuvent être extraites. Dans cet article, on se penchera sur le cas des jeux de données de trafic réseau, utilisés notamment pour évaluer des systèmes de détection d’anomalies et autres systèmes de détection d’intrusion. Les adresses IP des paquets sont anonymisées pour préserver l’identité et la vie privée des utilisateurs. Nous avons découvert une technique pour retrouver les sous-réseaux originaux d’un jeu de données de ce type, à partir de l’attaque Mirai survenue début août 2016. Nous avons appliqué cette méthode sur MAWI, l’un des jeux de données les plus utilisés dans ce domaine.

 

1. Les jeux de données

La conception d’un bon système de détection d’intrusion (aussi connu sous le nom de NIDS pour Network Intrusion Detection System en anglais) repose sur sa capacité à détecter le plus d’attaques possible tout en maintenant un faible taux de fausses alertes. Une fausse alerte correspond à du trafic identifié comme anormal par le détecteur alors qu’il est normal. Pour mettre au point et évaluer un tel système, plusieurs jeux de données sont mis à disposition sur Internet.

À partir d’un jeu de données contenant des attaques et du trafic normal, le but du détecteur est de détecter les attaques et d’identifier le trafic dénué d’attaques. Pour cela, une matrice de confusion contient ce qui a été classifié comme trafic normal ou anormal par rapport à la vraie nature du trafic. Un exemple d’une telle matrice est proposé dans le tableau ci-dessous.

  Classifié : trafic anormal Classifié : trafic normal
Réel : trafic anormal Vrai positif Faux négatif
Réel : trafic normal Faux positif Vrai négatif

Cette matrice permet de calculer des métriques d’évaluation du système de détection. Par exemple, le taux d’erreur correspond au pourcentage de mauvaises détections par rapport au nombre d’éléments total, le taux de faux positifs correspond au pourcentage de mauvaises détections par rapport à tous les éléments de trafic normal ou encore le taux de vrais positifs correspond au pourcentage de trafic classifié comme anormal sur tout le trafic vraiment anormal.

1.1 Types de jeux de données

En fonction du type d’anomalies que l’on souhaite détecter, ces jeux de données contiennent un type de trafic spécifique. On peut classifier les jeux de données en deux grands groupes : ceux qui contiennent des attaques spécifiques et ceux qui contiennent du trafic réel dont du trafic normal et des anomalies de différentes natures.

Parmi tous ces jeux de données, il en existe aussi des labellisés et d’autres qui ne le sont pas.

1.1.1 Type de trafic

Les jeux de données du premier type contiennent des types d’attaques spécifiques et identifiés. Ils sont conçus pour évaluer des systèmes de détection d’attaques précises. Par exemple, le Center for Applied Internet Data Analysis (CAIDA) met à disposition les traces d’une attaque par déni de service distribué [1], communément appelée DDoS, qui a eu lieu le 4 août 2017. Il permet d’évaluer les performances d’un système de détection d’attaque DDoS. Un autre exemple est le « CTU-13 dataset » [2] qui contient du trafic provenant d’un botnet, qui contient à la fois des paquets normaux et des paquets malveillants. Cette fois, ce jeu de données est utilisé pour prouver l’efficacité d’un système de détection de botnets.

D’autres jeux de données ne sont pas spécifiques à une attaque en particulier, mais contiennent du trafic réel, le plus souvent provenant d’universités ou de centres de recherche. Ils sont destinés à détecter des anomalies en général et non un certain type d’attaques. Les anomalies peuvent être :

  • de nature non malveillante, comme des pannes de réseau, des problèmes de performance, un pic de trafic inhabituel, etc. ;
  • de nature malveillante, comme des intrusions ou des attaques dans le réseau, par exemple des attaques par déni de service (DoS et DDoS), des vers réseau, etc.

Ce deuxième type de jeux de données permet d’évaluer un système de détection d’anomalies, ou bien de l’utiliser comme trafic de fond (background traffic) pour y injecter des attaques précises et ainsi labellisées dans le but de les détecter.

Le projet WIDE met à disposition le jeu de données MAWI [3] d’échanges de trafic entre des universités japonaises et américaines. Les paquets sont capturés entre leur réseau et le FAI le plus proche vers l’extérieur. Un fichier du trafic entre 14h et 14h15 est mis en ligne chaque jour après anonymisation des paquets. CAIDA propose un autre jeu de données contenant le trafic réel anonymisé échangé entre les liaisons principales de leur réseau, nommé le « CAIDA Anonymized Internet Traces Dataset » [4]. Il s’agit de fichiers représentant une heure de trafic capturée de temps en temps en 2008, 2015 et 2016.

1.1.2 Labellisation

Certains de ces jeux de données sont labellisés, c’est-à-dire qu’à chaque paquet est assigné un label le caractérisant. Il peut s’agir du nom de l’attaque ou bien de « normal » si le paquet ne correspond à aucune attaque.

Un jeu de données très utilisé, le KDD Cup 99 Dataset [5], possède de nombreux labels d’attaques comme « neptune » ou « smurf » qui correspondent à deux vecteurs d’attaques provoquant des dénis de service distribués.

D’autres jeux de données ne possèdent pas de labels, comme CAIDA et MAWI, car ils contiennent du trafic réel, à la fois composé de trafic normal et d’anomalies. Toutefois, MAWILab [6], un autre projet de WIDE, identifie les anomalies dans les fichiers de MAWI et propose une labellisation du trafic.

1.2 Méthodes d’anonymisation

La cybersécurité est le fait de prendre des mesures de sécurité de sorte à fournir la confidentialité, l’intégrité et la disponibilité des données dans les systèmes numériques. Ce modèle porte le nom de triade CIA, pour Confidentiality, Integrity, Availability. La confidentialité assure que les données sont accessibles seulement par les personnes autorisées, l’intégrité assure que les données n’ont pas été altérées et la disponibilité assure que seules les personnes autorisées bénéficient d’un accès fiable aux données.

Dans le contexte de mise à disposition des jeux de données, la confidentialité est un principe clé, car des données sensibles ne doivent pas être communiquées. C’est pourquoi les jeux de données réseau sont anonymisés afin de ne pas pouvoir identifier les adresses IP des paquets.

Note

 En France, plusieurs lois du Code pénal [7] protègent les données personnelles.

- Article 226-22 du Code pénal :

« Le fait par toute personne qui a recueilli (…) des données à caractères personnel (…), de porter, sans autorisation de l’intéressé, ces données à la connaissance d’un tiers qui n’a pas qualité pour les recevoir est puni de cinq ans d’emprisonnement et de 300 000 euros d’amende. »

Tout récemment, la nouvelle règlementation européenne de Règlement Général à la Protection des Données (RGPD) [8] remplace la directive sur la protection des données personnelles adoptée en 1995. Elle renforce le contrôle des personnes sur l’utilisation de leurs données personnelles.

Plusieurs méthodes ont été proposées pour retirer les données sensibles des paquets. Tout d’abord, les données applicatives sont supprimées et seule l’entête de couche 4 est conservée. De plus, les adresses IP des paquets sont anonymisées. tcpdpriv [9], l’une des solutions les plus répandues, implémente cela et propose des options supplémentaires en fonction du niveau de sécurité choisi. MAWI en utilise une version légèrement modifiée. CAIDA utilise la solution Crypto-Pan [10] et propose plusieurs recommandations à propos de l’anonymisation des paquets IPv4 [11].

L’anonymisation des adresses IPv4 repose sur quelques principes fondateurs :

  • elle est dite sans collision, c’est-à-dire que deux adresses IP différentes le seront également après anonymisation ;
  • elle respecte le principe de conservation des préfixes, c’est-à-dire que les relations entre les préfixes des adresses IP sont les mêmes avant et après anonymisation. Cela permet de pouvoir identifier des adresses IP appartenant au même sous-réseau après anonymisation. La conservation des préfixes est telle que, si deux adresses IP partagent un préfixe de k bits, les deux adresses IP anonymisées partagent également un préfixe de k bits.

2. L’attaque Mirai

2.1 Description de l’attaque

En septembre et octobre 2016, des attaques DDoS d’une ampleur jamais vue auparavant secouent l’Internet en touchant à quelques jours d’intervalle le blog de Brian Krebs, l’hébergeur OVH, puis la société Dyn. En s’attaquant à eux, le but véritable était de bloquer le fonctionnement des serveurs DNS chargés de renseigner les adresses IP des sites par rapport à leurs noms de domaine. Ainsi, l’accès à des sites massivement utilisés tels que Twitter, Spotify, GitHub, Reddit a été bloqué pendant plusieurs heures.

Cette attaque est la conséquence de milliers d’objets connectés à travers le monde infectés par le botnet Mirai.

L’infection se déroule en plusieurs phases :

- 1ère étape : phase de scan.

Tout d’abord, les hôtes infectés par Mirai envoient des paquets TCP SYN à des adresses IPv4 aléatoires à travers le monde sur le port Telnet. Seules certaines adresses IP sont sur liste noire et ne sont pas touchées par les scans. Il s’agit d’organisations gouvernementales, de Hewlett-Packward et de General Electric entre autres. Les ports Telnet TCP/23 et TCP/2323 sont scannés par les hôtes infectés. Dans des versions plus récentes détournées de Mirai, on trouve aussi les ports TCP/7547, TCP/5555 ou encore TCP/23231. À l’issue de ce scan, il se peut que des hôtes répondent par un paquet TCP SYN/ACK au paquet initialement envoyé. Cela signifie que leur port Telnet est ouvert et pas protégé par un pare-feu (auquel cas ils répondraient par un paquet ICMP ou parfois ne répondent pas du tout). En général, il s’agit d’objets connectés dont la sécurité n’est pas renforcée.

- 2ème étape : phase de brute forcing.

Une fois les victimes identifiées, l’hôte tente d’établir une connexion Telnet avec la victime en essayant de nombreux identifiants (login et mot de passe) parmi une liste préétablie. Dès qu’une connexion est fructueuse, l’adresse IP de la victime et ses identifiants sont transmis à un serveur spécifique.

- 3ème étape : phase d’enrôlement et de propagation.

Finalement, ces hôtes sont infectés par un autre programme qui détermine l’environnement et exécute un malware spécifique à celui-ci. La victime écoute alors les commandes d’attaques provenant du serveur de commande et de contrôle (C&C) et infecte à son tour de nouveaux hôtes selon les mêmes étapes préalablement citées.

Dû à son mode de fonctionnement, l’infection se répand extrêmement vite parmi les hôtes. Les chercheurs ont observé plus tard que près de 65 000 hôtes ont été infectés après 20 heures, et que ce chiffre doublait toutes les 76 minutes. Le nombre de machines infectées était de 600 000 juste avant la première attaque DDoS. À ce moment, les hôtes infectés ont reçu simultanément des commandes du serveur C&C et ont attaqué massivement les serveurs DNS.

2.2 Son intérêt

Le code source du botnet a été publié sur GitHub par ses créateurs. Depuis, il a été repris dans des variations de Mirai. Voici ci-après un extrait du programme du bot qui scanne d’autres victimes potentielles comme décrit dans l’étape 1 de la sous-section précédente.

# Code provenant de https://github.com/jgamblin/Mirai-Source-Code/blob/master/mirai/bot/scanner.c

# iph = ip header ; entête du paquet IP

iph->id = rand_next();

iph->saddr = LOCAL_ADDR;

iph->daddr = get_random_ip();

if (i % 10 == 0)

{

     tcph->dest = htons(2323);

}

else

{

     tcph->dest = htons(23);

}

tcph->seq = iph->daddr;

Les paquets envoyés par les bots Mirai possèdent quelques propriétés intéressantes. En particulier, le numéro de séquence TCP des paquets est égal à l’adresse IP destination comme inscrite à la dernière ligne de l’extrait de code ci-dessus.

Ainsi, on peut retrouver l’adresse IP destination d’un paquet en récupérant le numéro de séquence. Il suffit de convertir le nombre décimal en un format binaire pour pouvoir retrouver l’adresse IP sous la forme que l’on connaît.

3. Désanonymisation des paquets de MAWI

3.1 Astuce via Mirai

On applique maintenant la méthode sur le jeu de données MAWI. Ce jeu de données est intéressant, car il possède un fichier de trafic par jour depuis 2008 jusqu’à maintenant, ainsi on peut récupérer les dates que l’on veut. L’attaque Mirai a débuté en août 2016, et on en trouve toujours des traces aujourd’hui. L’idéal est donc de récupérer le fichier d’une date de cette période.

Dans un premier temps, les paquets envoyés par les botnets Mirai sont récupérés et analysés. Les paquets Mirai sont reconnaissables, car envoyés sur les ports TCP/23 et TCP/2323 Telnet.

Ensuite, on récupère le numéro de séquence, on le transcrit de nombre décimal à binaire afin de pouvoir retrouver l’adresse IP. La figure 1 ci-après illustre ce processus.

Fig. 1 : Récupération des sous-réseaux de MAWI grâce à une astuce dans les paquets de l’attaque Mirai.

Prenons l’adresse IP destination anonymisée de la première ligne de la capture ci-dessus. Le numéro de séquence est 2520010332.

On convertit d’abord ce nombre en binaire : 2520010332 = 10010110 00110100 01001110 01011100.

Puis on traduit chaque octet (groupe de 8 bits) en nombre décimal : 150 52 78 92.

L’adresse IP est donc 150.52.78.92. C’est l’adresse IP réelle correspondant à l’adresse IP anonymisée 150.200.64.92. On observe ici que le premier octet est le même avant et après anonymisation. Cela n’est pas un hasard, mais c’est le cas pour toutes les adresses IP.

Cette astuce est applicable seulement sur les paquets de l’attaque Mirai. Toutefois, elle permet de retrouver tous les sous-réseaux désanonymisés du réseau WIDE.

3.2 AS et sous-réseaux couverts

En utilisant des outils bien connus pour déterminer l’Autonomous System (AS) d’une adresse IP [12, 13, 14], il est facile d’extraire la liste d’AS correspondant aux adresses IP anonymisées. Sur un total de 16 sous-réseaux retrouvés à l’étape précédente, on obtient 6 AS différents.

Ensuite, une recherche sur l’AS telle que [15] nous permet d'obtenir le sous-réseau correspondant à l'adresse IP désanonymisée avec son masque. On répète alors cette opération pour chaque adresse IP retrouvée appartenant à un sous-réseau différent

On remarque d’une part que le premier octet est le même avant et après anonymisation, ce qui rend facile la reconnaissance entre deux sous-réseaux. D’autre part, la clé d’anonymisation change d’un jour à l’autre, ce qui signifie que l’on doit répéter l’opération de désanonymisation avec MAWI tous les jours.

Note

Qu’en est-il des paquets pré-attaque Mirai ?

Si cette méthode est efficace pour retrouver les sous-réseaux originaux grâce aux paquets envoyés par les bots Mirai, on ne peut pas l’appliquer sur les jours précédant l’attaque. Il faut alors construire une vue du réseau, c’est-à-dire les différents sous-réseaux, ou plages d’adresses IP, durant un jour où a eu lieu l’attaque Mirai. Ensuite, on peut utiliser plusieurs astuces pour retrouver les sous-réseaux d’un jour qui n’a pas été touché par Mirai. La méthode d’anonymisation utilisée par MAWI conserve le premier octet de l’adresse IP originale, ce qui est utile pour retrouver un sous-réseau si son premier octet est unique.

Sinon, on peut utiliser d’autres signes distinctifs du sous-réseau, comme son masque, qui définit la plage d’adresses IP dans un sous-réseau.

Conclusion

Les jeux de données contenant du trafic réseau réel sont essentiels pour la conception des systèmes de détection d’intrusion. Toutefois, ils nécessitent d’être anonymisés pour des raisons de confidentialité et sont donc assez rares. L’anonymisation repose essentiellement sur la suppression de la partie données du datagramme et sur l’anonymisation des adresses IP. Il est aussi nécessaire de conserver le maximum d’informations provenant des paquets pour que l’utilisabilité du jeu de données soit assurée. Cependant, d’autres attributs des paquets peuvent être utilisés par les attaquants pour cacher des informations dedans. Ici en particulier, on exploite le numéro de séquence TCP qui contient l’adresse IP destination exacte dans les paquets provenant de botnets Mirai.

On utilise cette technique sur le jeu de données MAWI. Grâce à cela, on peut identifier exactement les adresses IP réelles de leur réseau qui ont reçu du trafic Mirai. Cela nous permet aussi d’identifier les sous-réseaux réels du jeu de données.

Références

[1] https://www.caida.org/data/passive/ddos-20070804_dataset.xml

[2] https://www.stratosphereips.org/datasets-ctu13/

[3] http://mawi.wide.ad.jp/mawi/

[4] http://www.caida.org/data/passive/passive_dataset.xml

[5] http://kdd.ics.uci.edu/databases/kddcup99/kddcup99.html

[6] http://www.fukuda-lab.org/mawilab/index.html

[7] https://www.cnil.fr/fr/les-sanctions-penales

[8] https://www.cnil.fr/fr/reglement-europeen-protection-donnees

[9] http://ita.ee.lbl.gov/html/contrib/tcpdpriv.html

[10] « Prefix-Preserving IP Address Anonymization », Computer Networks, Volume 46, Issue 2, 7 octobre 2004, Pages 253-272, Elsevier

[11] https://www.caida.org/projects/predict/anonymization/

[12] https://asn.cymru.com

[13] http://thyme.apnic.net/

[14] https://quaxio.com/bgp

[15] https://ipinfo.io/AS2500