MIRAI - Analyse d'une attaque sophistiquée
+ de 5 minutes 
Didier M.
L’attaque date de septembre 2016. Elle est intéressante à analyser, car d’une part, elle est toujours d’actualité en 2022, des souches de MIRAI existent toujours. D’autre part, elle est élégante et sophistiquée par les mécanismes mis en œuvre.

MIRAI - Analyse d'une attaque sophistiquée

Contexte de cette attaque

Vers 2014-2016, les objets connectés se répandent dans le grand public, car des applications comme les caméras connectées, les lampes programmables, les thermostats réglables depuis un smartphone ont un intérêt pratique reconnu, mais les utilisateurs et aussi les fabricants sont plus ou moins ignorants des problèmes de sécurité qu’ils posent.

La plus simple des vulnérabilités bien connues des pirates et l’attaque sur le mot de passe par défaut du device souvent « 0000 », « password1 », « admin. », …. Les utilisateurs croient aussi naïvement que les box fournies par les opérateurs Télécoms offrent un niveau de protection suffisant sur leurs réseaux domestiques. Malheureusement ce n’est pas le cas, les opérateurs vendent avant tout du service multimédia. Il y a bien un firewall inclus dans les box, mais les règles sont bien connues des hackers. D’autres habitudes, telles qu’ouvrir des ports en NAT pour jouer avec ses amis et ne pas supprimer les règles par la suite.  

Dans le cas de Mirai, les pirates ont exploité ces failles, non pour s’introduire sur les réseaux et voler des données sensibles, mais pour créer une attaque par "Déni de Service Distribué" DDoS ( Distributed Denial of Service) en utilisant des caméras connectées comme un vecteur d’attaque vers les victimes, tel qu’un serveur DNS.

En terme plus technique, ils ont créé un réseau de botnet pour monter une attaque DDoS. L’attaque date de septembre 2016, elle est intéressante à analyser, car d’une part, elle est toujours d’actualité en 2022, des souches de MIRAI existent toujours. D’autre part, elle est élégante et sophistiquée par les mécanismes mis en œuvre.

Les auteurs de l’attaque étaient tellement fiers de leur travail qu’ils n’ont pas pu s’empêcher de publier une partie du code. Ils ont quand même été identifiés et arrêtés par la justice U.S, il s’agissait de trois étudiants en informatique de l’université Rutgers. Ils ont collaboré avec la justice et plaidés coupables. Le codeur de Mirai a été condamné à 2500 heures de travaux d’intérêt général, et à une amende de 8.6 millions de $.

Il a toute sa vie pour la payer, car le tribunal a considéré qu’il faut laisser une personne aussi douée contribuer au bien commun. On suppose qu’il est devenu expert en cybersécurité défensive.

Avoir été condamné comme cyber hacker est-elle la meilleure des certifications ? On est en droit de se poser la question.

Contexte des DDoS

   

Historiquement, la première grosse attaque par DDoS date du 26 avril 2007. Elle visait le système d’information de l’Estonie.

L’attaque est motivée par le déboulonnage d’une statue représentant un soldat russe « libérant » l’Estonie en 1944. Les sites web du Président, du Parlement, du premier ministre et de la quasi-totalité des ministères sont les premières victimes. L’Estonie se vantant d’être à la pointe de l’informatique. Les services bancaires sont aussi rapidement mis hors d’état de fonctionner. Le pays est paralysé pendant plusieurs jours, les retraits d’argent aux automates bancaires étant impossibles. C’est seulement le 19 mai que l’attaque cesse.

Cette première attaque par rapport à MIRAI donne l’idée générale des DDoS. Elle est brutale et non sophistiquée, les nombreux attaquants ont simplement saturé les serveurs, victimes avec une commande IP bien connue, le « ping ». Mais alors que la charge utile d’un ping ipv4 usuel fait 32 octets, ils ont augmenté la taille à 10 000 octets et l’ont répété en boucle. Les servers et les routeurs estoniens sont vite débordés, les routeurs en particulier doivent fragmenter les 10 000 octets en plusieurs fragments de 1500 octets ; la taille maximum usuelle à cette époque ; ce qui les ralentit énormément. Plus aucune requête utile ne peut être traitée ou alors avec des retards inacceptables.

L’attaque, une simple commande Microsoft DOS « C:\ ping -n 5000 -l 10000 <@ipviktim> » était donnée sur des sites russes, ce qui a permis de « démocratiser » l’attaque. Coté estonien, la parade a consisté à isoler les routeurs et à ne plus répondre aux pings. L’attaque est attribuée à des groupes nationalistes russes. La question reste ouverte de savoir si elle était à l’initiative du Kremlin.

Le 20 septembre 2016 aux U.S.A

Le site https://krebsonsecurity.com se dit victime d’une attaque DDOS de 620 Gigabit par seconde.

C’est énorme, l’attaquant utilise le protocole GRE (Generic Routing Encapsulation), GRE établit un tunnel IP entre la victime et la machine attaquante, cela dénote une grande maîtrise des techniques réseaux.  

Début octobre 2016, en France

OVH se dit victime d’une variante de MIRAI.

21 Octobre 2016

Attaque du site Dyn un fournisseur de service DNS américain. Des milliers d’internautes ne peuvent plus accéder à Netflix.

       

Novembre 2016, en Allemagne

Une variante de MIRAI infecte les box/routeurs de Deutsche Telekom (D.T) bloquant le Traffic de 900 000 internautes. Petit plus rajouté dans cette variante de MIRAI : le malware bloque le canal utilisé par D.T pour faire les mises à jour du firmware des routeurs ce qui rend la mitigation encore plus difficile.

Février 2022

MIRAI est impliquée dans le malware Spring4Shell, qui concerne une exploitation du framework Java Spring Core par une Remote Code Exécution chargé par des botnets de type MIRAI   CVE-2022-22965  [Ref 5]

Analyse de l’attaque de 2016

L’attaque est bien menée, comparable à une opération militaire, d’abord une phase de reconnaissance ou plutôt de recrutement, dont le but est de constituer un réseau zombie d’objets connectés malveillants, ce que l’on appelle un botnet. La phase de reconnaissance peut s’étaler sur plusieurs semaines, le temps nécessaire pour réunir suffisamment d’objets connectés.

Schématiquement, MIRAI se compose d’un centre de Command and Control appelé « C2 » qui dirige et synchronise les opérations.

Centre command and control de l'attaque MIRAI

Analyse de scanner.c

Ce code le scanner.c écrit en « C » est activé durant la phase de reconnaissance.  On le trouve sur github [Ref 1]. On ne va pas commenter ici tout le code, mais seulement quelques extraits significatifs.

Remarquons d’emblée que pour un code malveillant les règles à respecter ne sont pas celles que l’on enseigne aujourd’hui pour avoir un code propre tel que : lisibilité, maintenabilité, modularité, programmation orientée objet, etc .

Un malware se doit d’avoir le code le plus discret et le plus compact possible, il doit aussi limiter la consommation des ressources, CPU, RAM, Stack, Heap pour ne pas se faire repérer par son comportement.  

 

Scanner.c initialise un socket TCP pour communiquer vers l’extérieur puis il se construit une petite base de données de user/password d’une soixantaine d’entrées seulement, ce qui en soi est déjà notable sur le faible nombre de couple user/password les plus probables à essayer en 2016 sur les objets connectés.

Subtilité à apprécier, le codage de la petite base de données ne se fait pas avec du code ASCII comme un lecteur superficiel pourrait le croire, en fait les user password sont obfusqués. Une technique utilisée pour obscurcir le code en rajoutant de la confusion, ils sont dé-obfusqués dans la procédure add_auth_entry à la ligne.

       auth_table[auth_table_len].username = deobf(enc_user, &tmp);

L’idée sous-jacente est d’éviter de se faire repérer au chargement du malware par des antivirus qui trouveraient suspect, par analyse du flux entrant, la présence de ces mots de passe en ASCII .  

   

                   // Set up passwords

                  add_auth_entry("\x50\x4D\x4D\x56", "\x54\x4B\x58\x5A\x54", 9);       // root      vizxv

                  add_auth_entry("\x50\x4D\x4D\x56", "\x43\x46\x4F\x4B\x4C", 8);       // root      admin

                  add_auth_entry("\x43\x46\x4F\x4B\x4C", "\x43\x46\x4F\x4B\x4C", 7);   // admin    admin

                   ....................

                   ......

                   ....

                   ……………………..

                  add_auth_entry("\x43\x46\x4F\x4B\x4C", "\x13\x10\x11\x16", 1);      // admin    1234

                  add_auth_entry("\x43\x46\x4F\x4B\x4C", "\x13\x10\x11\x16\x17", 1);  // admin    12345

                  add_auth_entry("\x43\x46\x4F\x4B\x4C", "\x17\x16\x11\x10\x13", 1);  // admin    54321

                  add_auth_entry("\x43\x46\x4F\x4B\x4C", "\x13\x10\x11\x16\x17\x14", 1); // admin    123456

   .

     

Dans le programme principal, on voit une boucle sans fin qui, à des intervalles de temps aléatoires, génère une connexion TCP vers une adresse IPv4 aléatoire en respectant les règles d’adressages IP des classes A ,B ,C, mais n’exploite pas les autres machines du réseau « host » en 192.168.x.y afin de rester discret.

Il s’abstient aussi d’attaquer des grandes organisations comme Hewlett Packard ou General Electric. L’attaquant a réalisé qu’il risquait d’être repéré par les I.D.S (Intrusion Detection System) sophistiqués de ces organisations.

Ensuite, il lui faut trouver un port Telnet (23) ouvert et si la connexion TCP est réussie, il faut mémoriser le couple user/password. .

static ipv4_t get_random_ip(void)

{

  uint32_t tmp;

   uint8_t o1, o2, o3, o4;

  do

  {

      tmp = rand_next();

      o1 = tmp & 0xff;

        o2 = (tmp >> 8) & 0xff;

        o3 = (tmp >> 16) & 0xff;

        o4 = (tmp >> 24) & 0xff;

      }

  while (o1 == 127 ||                             // 127.0.0.0/8          - Loopback

          (o1 == 0) ||                              // 0.0.0.0/8            - Invalid address space

          (o1 == 3) ||                              // 3.0.0.0/8            - General Electric Company

          (o1 == 15 || o1 == 16) ||                 // 15.0.0.0/7           - Hewlett-Packard Company

          (o1 == 56) ||                             // 56.0.0.0/8           - US Postal Service

          (o1 == 10) ||                             // 10.0.0.0/8           - Internal network

          (o1 == 192 && o2 == 168) ||               // 192.168.0.0/16   - Internal network

        (o1 == 172 && o2 >= 16 && o2 < 32) ||     // 172.16.0.0/14   - Internal network

          (o1 == 100 && o2 >= 64 && o2 < 127) ||    // 100.64.0.0/10   - IANA NAT reserved

          (o1 == 169 && o2 > 254) ||                // 169.254.0.0/16    - IANA NAT reserved

          (o1 == 198 && o2 >= 18 && o2 < 20) ||     // 198.18.0.0/15   - IANA Special use

          (o1 >= 224) ||                            // 224.*.*.*+       - Multicast

(o1 == 6 || o1 == 7 || o1 == 11 || o1 == 21 || o1 == 22 || o1 == 26 || o1 == 28 || o1 == 29 || o1 == 30 || o1 == 33 || o1 == 55 || o1 == 214 || o1 == 215)                  // Department of Defense  

              );

    return INET_ADDR(o1,o2,o3,o4);

}

Dans le cas d’une connexion réussie :

Les informations sont remontées en utilisant une ruse, en l’occurrence, des requêtes DNS banalisés, mais qui vont aboutir vers un DNS exploité par le Centre C2, ainsi le C2 collecte le travail de son armée d’objets connectés zombies.

 Le Centre de commandement et Contrôle doit encore passer un obstacle, les cibles IoT sont très diverses aussi bien en hardware qu’en software. Il lui faut encore identifier chaque nouvelle cible. En effet, il a les informations pour se connecter, mais il ne sait pas quel est le processeur x86 , armv41 ,armv51 , cortex , powerpc ….  ni l’Operating System de la cible. En fait, ce n’est pas très compliqué de le savoir, une requête nmap avec l’option -O est capable de donner les caractéristiques de la cible. Les systèmes se dévoilent aussi par la façon dont ils réagissent à la première requête des services usuels : telnet, ssh ,snmp, http ,rdp … 

Une fois une nouvelle « recrue zombie » caractérisée, on lui télécharge le malware de reconnaissance adapté à sa configuration matérielle et logicielle. Un nouveau cycle de reconnaissance est actif, de cette façon, le nombre d’objets zombies faisant de la reconnaissance malveillante à leur insu, croît rapidement.

Quand un nombre suffisant de devices zombies a été contaminé et que la communication avec le C2 est fiabilisée, les attaquants passent à la phase offensive proprement dite avec une charge utile qui peut prendre différentes formes. En octobre 2016, la victime a été le DNS de Dyn. À l’heure prévue pour l’attaque, le C2 télécharge le malware offensif dans les zombies. Des centaines d’objets connectés saturent la victime, le DNS de Dyn s’écroule, des sites tels que Twitter, Netflix, Paypal sont inaccessibles pour les clients qui ont programmé le DNS de Dyn dans leurs routeurs.

Rappelons que la principale fonction d’un DNS est d’assurer la traduction dynamique d’un nom mnémotechnique comme www.facebook.com vers son adresse IP compréhensible par le réseau. Un DNS est donc un gros point de vulnérabilité d’autant plus que les DNS sont chainés de façon hiérarchique, les experts en cybersécurité pronostiquent qu’une attaque d’ampleur sur les DNS serait le meilleur moyen d’écrouler Internet.

Leçons à tirer de cette attaque 

Les leçons à tirer sont multiples, l’attaque étant multiforme.

La plus élémentaire des mesures de sécurité est de changer immédiatement le mot de passe par défaut des équipements accédant aux réseaux IP : objets connectés, box, routeurs, etc. Le mot de passe par défaut programmé en usine se trouve en quelques minutes de recherche sur internet. Telnet était déjà connu en 2016 comme un service trop peu sécurisé.

 

Pour un réseau domestique, il est acceptable de coller une étiquette avec le mot de passe sur l’appareil pour être sûr de ne pas le perdre, le risque est faible qu’un pirate s’introduise physiquement chez vous pour ensuite vous espionner. Cependant en entreprise ce risque est non négligeable et il existe. C’est bien la responsabilité de l’administrateur réseaux de le gérer.

 

Les attaques par DDoS sous la forme de ping sont maintenant filtrées par les Firewall. Les ping restent à présent sans réponse sur la plupart des serveurs, ce qui a grandement compliqué le travail des administrateurs réseaux. Le ping étant jusqu’à cette époque l’outil de base pour vérifier la connectivité entre machines. Maintenant, on est obligé d’utiliser des outils plus sophistiqués comme « nmap  <@ip> ». Un peu comme si on interdisait aux garagistes d’utiliser leur tournevis.

 

Peut-on identifier une menace dès la phase de reconnaissance ?

Un pare-feu peut limiter les flux sortants à une liste de ports autorisés, typiquement 80,443,8080. Ce qui dans le cas de MIRAI aurait bloqué la reconnaissance. Aujourd’hui, il existe des IDS plus performant comme SNORT, SURICATA qui peuvent analyser un comportement anormal, ils sont OPEN SOURCE, mais demandent une expertise certaine en Unix et en IP.

   

 Les DNS représentent une vulnérabilité importante, en bloquant un DNS l’impact est indirect toutes les requêtes vers les sites internet passent par un DNS, Les DNS sont reliés entre eux de façon hiérarchisée. Bloquer un DNS va bloquer tous les DNS de niveau inférieur.

 

Pour un réseau domestique, il est judicieux de limiter le risque en déclarant en DNS secondaire, un DNS différent du DNS primaire, par exemple ORANGE en primaire (80.10.246.2) et Google (8.8.8.8) en secondaire.

Références :

1)      https://github.com/

2)      https://www.cisa.gov/

3)      https://krebsonsecurity.com/

4)      https://krebsonsecurity.com/

5)      https://www.trendmicro.com/

Retour à la page d'accueil
Sécurité applicative : pourquoi passer au DevSecOps ?

MIRAI - Analyse d'une attaque sophistiquée

S'informer
Auteur.e :
Didier M.

Contexte de cette attaque

Vers 2014-2016, les objets connectés se répandent dans le grand public, car des applications comme les caméras connectées, les lampes programmables, les thermostats réglables depuis un smartphone ont un intérêt pratique reconnu, mais les utilisateurs et aussi les fabricants sont plus ou moins ignorants des problèmes de sécurité qu’ils posent.

La plus simple des vulnérabilités bien connues des pirates et l’attaque sur le mot de passe par défaut du device souvent « 0000 », « password1 », « admin. », …. Les utilisateurs croient aussi naïvement que les box fournies par les opérateurs Télécoms offrent un niveau de protection suffisant sur leurs réseaux domestiques. Malheureusement ce n’est pas le cas, les opérateurs vendent avant tout du service multimédia. Il y a bien un firewall inclus dans les box, mais les règles sont bien connues des hackers. D’autres habitudes, telles qu’ouvrir des ports en NAT pour jouer avec ses amis et ne pas supprimer les règles par la suite.  

Dans le cas de Mirai, les pirates ont exploité ces failles, non pour s’introduire sur les réseaux et voler des données sensibles, mais pour créer une attaque par "Déni de Service Distribué" DDoS ( Distributed Denial of Service) en utilisant des caméras connectées comme un vecteur d’attaque vers les victimes, tel qu’un serveur DNS.

En terme plus technique, ils ont créé un réseau de botnet pour monter une attaque DDoS. L’attaque date de septembre 2016, elle est intéressante à analyser, car d’une part, elle est toujours d’actualité en 2022, des souches de MIRAI existent toujours. D’autre part, elle est élégante et sophistiquée par les mécanismes mis en œuvre.

Les auteurs de l’attaque étaient tellement fiers de leur travail qu’ils n’ont pas pu s’empêcher de publier une partie du code. Ils ont quand même été identifiés et arrêtés par la justice U.S, il s’agissait de trois étudiants en informatique de l’université Rutgers. Ils ont collaboré avec la justice et plaidés coupables. Le codeur de Mirai a été condamné à 2500 heures de travaux d’intérêt général, et à une amende de 8.6 millions de $.

Il a toute sa vie pour la payer, car le tribunal a considéré qu’il faut laisser une personne aussi douée contribuer au bien commun. On suppose qu’il est devenu expert en cybersécurité défensive.

Avoir été condamné comme cyber hacker est-elle la meilleure des certifications ? On est en droit de se poser la question.

Contexte des DDoS

   

Historiquement, la première grosse attaque par DDoS date du 26 avril 2007. Elle visait le système d’information de l’Estonie.

L’attaque est motivée par le déboulonnage d’une statue représentant un soldat russe « libérant » l’Estonie en 1944. Les sites web du Président, du Parlement, du premier ministre et de la quasi-totalité des ministères sont les premières victimes. L’Estonie se vantant d’être à la pointe de l’informatique. Les services bancaires sont aussi rapidement mis hors d’état de fonctionner. Le pays est paralysé pendant plusieurs jours, les retraits d’argent aux automates bancaires étant impossibles. C’est seulement le 19 mai que l’attaque cesse.

Cette première attaque par rapport à MIRAI donne l’idée générale des DDoS. Elle est brutale et non sophistiquée, les nombreux attaquants ont simplement saturé les serveurs, victimes avec une commande IP bien connue, le « ping ». Mais alors que la charge utile d’un ping ipv4 usuel fait 32 octets, ils ont augmenté la taille à 10 000 octets et l’ont répété en boucle. Les servers et les routeurs estoniens sont vite débordés, les routeurs en particulier doivent fragmenter les 10 000 octets en plusieurs fragments de 1500 octets ; la taille maximum usuelle à cette époque ; ce qui les ralentit énormément. Plus aucune requête utile ne peut être traitée ou alors avec des retards inacceptables.

L’attaque, une simple commande Microsoft DOS « C:\ ping -n 5000 -l 10000 <@ipviktim> » était donnée sur des sites russes, ce qui a permis de « démocratiser » l’attaque. Coté estonien, la parade a consisté à isoler les routeurs et à ne plus répondre aux pings. L’attaque est attribuée à des groupes nationalistes russes. La question reste ouverte de savoir si elle était à l’initiative du Kremlin.

Le 20 septembre 2016 aux U.S.A

Le site https://krebsonsecurity.com se dit victime d’une attaque DDOS de 620 Gigabit par seconde.

C’est énorme, l’attaquant utilise le protocole GRE (Generic Routing Encapsulation), GRE établit un tunnel IP entre la victime et la machine attaquante, cela dénote une grande maîtrise des techniques réseaux.  

Début octobre 2016, en France

OVH se dit victime d’une variante de MIRAI.

21 Octobre 2016

Attaque du site Dyn un fournisseur de service DNS américain. Des milliers d’internautes ne peuvent plus accéder à Netflix.

       

Novembre 2016, en Allemagne

Une variante de MIRAI infecte les box/routeurs de Deutsche Telekom (D.T) bloquant le Traffic de 900 000 internautes. Petit plus rajouté dans cette variante de MIRAI : le malware bloque le canal utilisé par D.T pour faire les mises à jour du firmware des routeurs ce qui rend la mitigation encore plus difficile.

Février 2022

MIRAI est impliquée dans le malware Spring4Shell, qui concerne une exploitation du framework Java Spring Core par une Remote Code Exécution chargé par des botnets de type MIRAI   CVE-2022-22965  [Ref 5]

Analyse de l’attaque de 2016

L’attaque est bien menée, comparable à une opération militaire, d’abord une phase de reconnaissance ou plutôt de recrutement, dont le but est de constituer un réseau zombie d’objets connectés malveillants, ce que l’on appelle un botnet. La phase de reconnaissance peut s’étaler sur plusieurs semaines, le temps nécessaire pour réunir suffisamment d’objets connectés.

Schématiquement, MIRAI se compose d’un centre de Command and Control appelé « C2 » qui dirige et synchronise les opérations.

Centre command and control de l'attaque MIRAI

Analyse de scanner.c

Ce code le scanner.c écrit en « C » est activé durant la phase de reconnaissance.  On le trouve sur github [Ref 1]. On ne va pas commenter ici tout le code, mais seulement quelques extraits significatifs.

Remarquons d’emblée que pour un code malveillant les règles à respecter ne sont pas celles que l’on enseigne aujourd’hui pour avoir un code propre tel que : lisibilité, maintenabilité, modularité, programmation orientée objet, etc .

Un malware se doit d’avoir le code le plus discret et le plus compact possible, il doit aussi limiter la consommation des ressources, CPU, RAM, Stack, Heap pour ne pas se faire repérer par son comportement.  

 

Scanner.c initialise un socket TCP pour communiquer vers l’extérieur puis il se construit une petite base de données de user/password d’une soixantaine d’entrées seulement, ce qui en soi est déjà notable sur le faible nombre de couple user/password les plus probables à essayer en 2016 sur les objets connectés.

Subtilité à apprécier, le codage de la petite base de données ne se fait pas avec du code ASCII comme un lecteur superficiel pourrait le croire, en fait les user password sont obfusqués. Une technique utilisée pour obscurcir le code en rajoutant de la confusion, ils sont dé-obfusqués dans la procédure add_auth_entry à la ligne.

       auth_table[auth_table_len].username = deobf(enc_user, &tmp);

L’idée sous-jacente est d’éviter de se faire repérer au chargement du malware par des antivirus qui trouveraient suspect, par analyse du flux entrant, la présence de ces mots de passe en ASCII .  

   

                   // Set up passwords

                  add_auth_entry("\x50\x4D\x4D\x56", "\x54\x4B\x58\x5A\x54", 9);       // root      vizxv

                  add_auth_entry("\x50\x4D\x4D\x56", "\x43\x46\x4F\x4B\x4C", 8);       // root      admin

                  add_auth_entry("\x43\x46\x4F\x4B\x4C", "\x43\x46\x4F\x4B\x4C", 7);   // admin    admin

                   ....................

                   ......

                   ....

                   ……………………..

                  add_auth_entry("\x43\x46\x4F\x4B\x4C", "\x13\x10\x11\x16", 1);      // admin    1234

                  add_auth_entry("\x43\x46\x4F\x4B\x4C", "\x13\x10\x11\x16\x17", 1);  // admin    12345

                  add_auth_entry("\x43\x46\x4F\x4B\x4C", "\x17\x16\x11\x10\x13", 1);  // admin    54321

                  add_auth_entry("\x43\x46\x4F\x4B\x4C", "\x13\x10\x11\x16\x17\x14", 1); // admin    123456

   .

     

Dans le programme principal, on voit une boucle sans fin qui, à des intervalles de temps aléatoires, génère une connexion TCP vers une adresse IPv4 aléatoire en respectant les règles d’adressages IP des classes A ,B ,C, mais n’exploite pas les autres machines du réseau « host » en 192.168.x.y afin de rester discret.

Il s’abstient aussi d’attaquer des grandes organisations comme Hewlett Packard ou General Electric. L’attaquant a réalisé qu’il risquait d’être repéré par les I.D.S (Intrusion Detection System) sophistiqués de ces organisations.

Ensuite, il lui faut trouver un port Telnet (23) ouvert et si la connexion TCP est réussie, il faut mémoriser le couple user/password. .

static ipv4_t get_random_ip(void)

{

  uint32_t tmp;

   uint8_t o1, o2, o3, o4;

  do

  {

      tmp = rand_next();

      o1 = tmp & 0xff;

        o2 = (tmp >> 8) & 0xff;

        o3 = (tmp >> 16) & 0xff;

        o4 = (tmp >> 24) & 0xff;

      }

  while (o1 == 127 ||                             // 127.0.0.0/8          - Loopback

          (o1 == 0) ||                              // 0.0.0.0/8            - Invalid address space

          (o1 == 3) ||                              // 3.0.0.0/8            - General Electric Company

          (o1 == 15 || o1 == 16) ||                 // 15.0.0.0/7           - Hewlett-Packard Company

          (o1 == 56) ||                             // 56.0.0.0/8           - US Postal Service

          (o1 == 10) ||                             // 10.0.0.0/8           - Internal network

          (o1 == 192 && o2 == 168) ||               // 192.168.0.0/16   - Internal network

        (o1 == 172 && o2 >= 16 && o2 < 32) ||     // 172.16.0.0/14   - Internal network

          (o1 == 100 && o2 >= 64 && o2 < 127) ||    // 100.64.0.0/10   - IANA NAT reserved

          (o1 == 169 && o2 > 254) ||                // 169.254.0.0/16    - IANA NAT reserved

          (o1 == 198 && o2 >= 18 && o2 < 20) ||     // 198.18.0.0/15   - IANA Special use

          (o1 >= 224) ||                            // 224.*.*.*+       - Multicast

(o1 == 6 || o1 == 7 || o1 == 11 || o1 == 21 || o1 == 22 || o1 == 26 || o1 == 28 || o1 == 29 || o1 == 30 || o1 == 33 || o1 == 55 || o1 == 214 || o1 == 215)                  // Department of Defense  

              );

    return INET_ADDR(o1,o2,o3,o4);

}

Dans le cas d’une connexion réussie :

Les informations sont remontées en utilisant une ruse, en l’occurrence, des requêtes DNS banalisés, mais qui vont aboutir vers un DNS exploité par le Centre C2, ainsi le C2 collecte le travail de son armée d’objets connectés zombies.

 Le Centre de commandement et Contrôle doit encore passer un obstacle, les cibles IoT sont très diverses aussi bien en hardware qu’en software. Il lui faut encore identifier chaque nouvelle cible. En effet, il a les informations pour se connecter, mais il ne sait pas quel est le processeur x86 , armv41 ,armv51 , cortex , powerpc ….  ni l’Operating System de la cible. En fait, ce n’est pas très compliqué de le savoir, une requête nmap avec l’option -O est capable de donner les caractéristiques de la cible. Les systèmes se dévoilent aussi par la façon dont ils réagissent à la première requête des services usuels : telnet, ssh ,snmp, http ,rdp … 

Une fois une nouvelle « recrue zombie » caractérisée, on lui télécharge le malware de reconnaissance adapté à sa configuration matérielle et logicielle. Un nouveau cycle de reconnaissance est actif, de cette façon, le nombre d’objets zombies faisant de la reconnaissance malveillante à leur insu, croît rapidement.

Quand un nombre suffisant de devices zombies a été contaminé et que la communication avec le C2 est fiabilisée, les attaquants passent à la phase offensive proprement dite avec une charge utile qui peut prendre différentes formes. En octobre 2016, la victime a été le DNS de Dyn. À l’heure prévue pour l’attaque, le C2 télécharge le malware offensif dans les zombies. Des centaines d’objets connectés saturent la victime, le DNS de Dyn s’écroule, des sites tels que Twitter, Netflix, Paypal sont inaccessibles pour les clients qui ont programmé le DNS de Dyn dans leurs routeurs.

Rappelons que la principale fonction d’un DNS est d’assurer la traduction dynamique d’un nom mnémotechnique comme www.facebook.com vers son adresse IP compréhensible par le réseau. Un DNS est donc un gros point de vulnérabilité d’autant plus que les DNS sont chainés de façon hiérarchique, les experts en cybersécurité pronostiquent qu’une attaque d’ampleur sur les DNS serait le meilleur moyen d’écrouler Internet.

Leçons à tirer de cette attaque 

Les leçons à tirer sont multiples, l’attaque étant multiforme.

La plus élémentaire des mesures de sécurité est de changer immédiatement le mot de passe par défaut des équipements accédant aux réseaux IP : objets connectés, box, routeurs, etc. Le mot de passe par défaut programmé en usine se trouve en quelques minutes de recherche sur internet. Telnet était déjà connu en 2016 comme un service trop peu sécurisé.

 

Pour un réseau domestique, il est acceptable de coller une étiquette avec le mot de passe sur l’appareil pour être sûr de ne pas le perdre, le risque est faible qu’un pirate s’introduise physiquement chez vous pour ensuite vous espionner. Cependant en entreprise ce risque est non négligeable et il existe. C’est bien la responsabilité de l’administrateur réseaux de le gérer.

 

Les attaques par DDoS sous la forme de ping sont maintenant filtrées par les Firewall. Les ping restent à présent sans réponse sur la plupart des serveurs, ce qui a grandement compliqué le travail des administrateurs réseaux. Le ping étant jusqu’à cette époque l’outil de base pour vérifier la connectivité entre machines. Maintenant, on est obligé d’utiliser des outils plus sophistiqués comme « nmap  <@ip> ». Un peu comme si on interdisait aux garagistes d’utiliser leur tournevis.

 

Peut-on identifier une menace dès la phase de reconnaissance ?

Un pare-feu peut limiter les flux sortants à une liste de ports autorisés, typiquement 80,443,8080. Ce qui dans le cas de MIRAI aurait bloqué la reconnaissance. Aujourd’hui, il existe des IDS plus performant comme SNORT, SURICATA qui peuvent analyser un comportement anormal, ils sont OPEN SOURCE, mais demandent une expertise certaine en Unix et en IP.

   

 Les DNS représentent une vulnérabilité importante, en bloquant un DNS l’impact est indirect toutes les requêtes vers les sites internet passent par un DNS, Les DNS sont reliés entre eux de façon hiérarchisée. Bloquer un DNS va bloquer tous les DNS de niveau inférieur.

 

Pour un réseau domestique, il est judicieux de limiter le risque en déclarant en DNS secondaire, un DNS différent du DNS primaire, par exemple ORANGE en primaire (80.10.246.2) et Google (8.8.8.8) en secondaire.

Références :

1)      https://github.com/

2)      https://www.cisa.gov/

3)      https://krebsonsecurity.com/

4)      https://krebsonsecurity.com/

5)      https://www.trendmicro.com/

Retour à l'acceuil
Nos derniers articles
Pourquoi passer au DevSecOps
S'informer
NMAP - Origines & Evolutions
Lire l'article
Pourquoi passer au DevSecOps
S'informer
MIRAI - Analyse d'une attaque sophistiquée
Lire l'article
Pourquoi passer au DevSecOps
Se Protéger
Les mots de passe et leur robustesse
Lire l'article
Accéder à tous les articles

Nos derniers articles

Active Directory - Son rôle & ses avantages

timer for read article
3 minutes
September 14, 2022
Active Directory peut être une solution extrêmement efficace de gestion de votre système d’information si elle est utilisée à bon escient. Quels sont son rôle et ses avantages en entreprise ?
Malek F.

NMAP - Origines & Evolutions

timer for read article
2 minutes
September 6, 2022
Initialement développé pour permettre une cartographie rapide de larges réseaux informatiques, en 25 ans, le créateur de NMAP, a repris ce qu'il se faisait de meilleur sur les autres outils pour aboutir à un outil open source très puissant.
Taha S.

Les mots de passe et leur robustesse

timer for read article
4 minutes 
August 9, 2022
Comme tout le monde, vous avez pu lire tout et son contraire sur un sujet qui est sur toutes les lèvres : les mots de passe et leur robustesse. Essayons ensemble de démystifier ce point, en combattant les idées reçues et en démontrant mathématiquement pourquoi.
Matthieu B.