Si vous avez un NAS QNAP, vous devez le mettre à jour vers la dernière version dès que possible ! Voilà, ce qu'il faut conclure des dernières déclarations de QNAP, suite aux attaques en cours effectuées par les pirates derrière le ransomware DeadBolt.
Alors que les pirates évoquaient une faille de sécurité zero-day non corrigée par QNAP et qu'ils essayaient de faire pression sur le fabricant de NAS pour obtenir une somme d'argent conséquente, la faille semble déjà connue. En effet, l'équipe de réponse à incident de QNAP a effectué différentes analyses suite aux dernières attaques, et visiblement c'est une vulnérabilité déjà corrigée qui est exploitée par les pirates.
En fonction de la configuration de la fonctionnalité de mise à jour automatique sur votre NAS QNAP, peut-être que cette mise à jour est déjà installée sur votre matériel. En tout cas, si vous avez configuré le NAS pour utiliser la version du firmware recommandée, votre appareil va faire l'installation puisque depuis le 27 janvier 2022, cette version a été définie comme étant la version recommandée.
Pour vous protéger contre cette vulnérabilité et les attaques du ransomware DeadBolt, voici les versions à viser (en fonction des systèmes) :
QTS 5.0.0.1891 build 20211221 (et supérieur)
QTS 4.5.4.1892 build 20211223 (et supérieur)
QuTS hero h5.0.0.1892 build 20211222 (et supérieur)
QuTS hero h4.5.4.1892 build 20211223 (et supérieur)
QuTScloud c5.0.0.1919 build 20220119 (et supérieur)
Néanmoins, il faut rester méfiant puisqu'un utilisateur du forum QNAP affirme que son NAS a été chiffré par DeadBolt alors qu'il utilise la dernière version de QTS. Forcément, cela sème le doute. En complément de la mise à jour, je vous recommande vivement de ne pas exposer votre NAS QNAP sur Internet le temps que la situation soit plus claire (à minima).
DeadBolt est particulièrement actif ces derniers jours, avec déjà plusieurs milliers de NAS compromis et chiffrés. Pour récupérer ses données, la victime est invitée à payer une rançon estimée à 0,03 bitcoin, ce qui représente près de 1 000 euros. Ces derniers mois, les NAS QNAP exposés sur Internet sont régulièrement la cible de cyberattaques notamment par des ransomwares tels que Qlocker, eCh0raix et AgeLocker.
Dans ce tutoriel, nous allons découvrir une commande indispensable en informatique : ping. Cette commande s'appuie sur le protocole ICMP et permet de réaliser quelques tests sur un réseau.
Après une courte introduction au protocole ICMP, je vais vous expliquer à quoi sert la commande "ping" puis il sera temps de passer à la démonstration. Pour cela, je vais effectuer l'analyse d'un ping entre deux machines à partir du logiciel Wireshark.
II. Le protocole ICMP
Le protocole ICMP, pour Internet Control Message Protocol, est très utile sur les réseaux IP puisqu'en cas de problème d'émission d'un paquet, il va être capable d'informer l'émetteur du paquet qu'il y a eu une erreur dans la transmission du paquet. En cas d'incident pour joindre un service, un hôte ou un routeur, le protocole ICMP peut informer l'adresse IP source de ce dysfonctionnement.
Même s'il n'est pas utilisé régulièrement au sein des applications, le protocole ICMP est très utile au sein d'outils de diagnostics pour le réseau tels que le ping que nous allons voir aujourd'hui, mais aussi traceroute.
Chaque paquet ICMP est encapsulé dans un datagramme IP. Contrairement aux protocoles TCP ou UDP, le protocole ICMP n'est pas un protocole de transport.
III. À quoi sert la commande ping ?
Dans une très grande majorité des cas, la commande ping sert à tester la communication entre deux équipements connectés à un réseau IP, mais la commande ping peut servir à d'autres choses. Voici une liste de trois cas courants de l'utilisation du ping :
Tester la communication entre deux équipements connectés à un réseau
Lorsque l'on effectue un ping d'une machine A vers une machine B, et que l'on obtient une réponse positive, cela signifie que d'un point de vue du réseau, la machine A peut atteindre la machine B (route aller) et que la machine B peut atteindre la machine A (route retour). Je vais revenir sur cette notion de "réponse positive" par la suite.
Mesurer la fiabilité d'un réseau à un instant t
Si l'on émet des requêtes "ping" entre une machine A et une machine B en boucle, pendant plusieurs minutes, et que l'on obtient que des réponses positives, on peut considérer que le chemin réseau entre les deux machines est fiable et stable (en tout cas à cet instant). Par contre, si l'on envoie 20 requêtes "ping" et que l'on a un taux de réponse négative de 20%, c'est qu'il y a un problème sur le réseau !
Mesurer la latence d'un réseau à un instant t
Nous le verrons dans la suite de ce tutoriel, que quand un ping est envoyé d'une machine A vers une machine B, la machine A (qui est la machine source) va mesurer le temps de réponse. Ce temps de réponse correspond laps au temps qui s'est écoulé entre le moment où la machine A a envoyé le paquet et où elle a reçue la réponse de la machine B. Si le temps de réponse est trop élevé, c'est le signe d'une perturbation sur le réseau, d'une congestion sur le réseau ou d'un problème de performance sur l'hôte distant.
IV. Comment fonctionne le ping ?
Lorsque l'on utilise la commande "ping", c'est la couche IP de notre machine qui va s'appuyer sur le protocole ICMP pour émettre un message ICMP "Echo Request" à destination de l'hôte distant.
Effectuée à partir d'une machine, la commande "ping" envoie un paquet ICMP vers l'hôte cible et ce paquet ICMP des informations, dont le type et le code. Grâce à eux, nous allons pouvoir en savoir plus sur le message envoyé via le protocole ICMP. Lorsqu'un ping se passe bien, l'hôte source utilise le message "echo request" et l'hôte destination lui répond avec le message "echo reply".
Ainsi, le type et le code peuvent prendre plusieurs valeurs avec à chaque fois une signification différente (données du tableau obtenues sur Wikipédia) :
Dans le tableau ci-dessus, nous retrouvons bien les types et les codes présents sur mon premier schéma. Nous verrons par la suite que l'on retrouve ces codes aussi dans la pratique, lors d'une analyse d'un ping avec Wireshark.
Quand on utilise la commande ping, que ce soit sur Windows, Linux, macOS, ou depuis la ligne de commande de son routeur, ou son switch, on obtiendra différentes informations à l'écran. Les informations affichées ne sont pas toujours les mêmes, cela dépend de la méthode d'implémentation de l'outil ping.
Faisons quelques essais...
Sur une machine Windows, on peut réaliser un ping à partir d'une Invite de commandes, d'une console Windows PowerShell ou PowerShell : c'est pris en charge dans toutes les consoles et cet outil est intégré à Windows. Il suffit de préciser l'adresse IP (ou le nom d'hôte, le nom de domaine) que l'on souhaite pinger :
ping 1.1.1.1
Par défaut, Windows va réaliser 4 ping et s'arrêter. Si l'on veut effectuer un ping continue qui s'arrête seulement lorsque l'on décide de l'arrêter, il faut ajouter une option :
ping 1.1.1.1 -t
Exemple d'un ping sous Windows
Sur l'image ci-dessus, on peut voir cette ligne pour chaque ping, ce qui correspond au résultat du ping :
Réponse de 1.1.1.1 : octets=32 temps=9 ms TTL=56
Cela signifie que l'hôte distant a répondu, c'est pour cette raison que l'on a l'information "Réponse de 1.1.1.1". On remarque d'autres informations sur cette ligne :
octets=32
Le paquet correspondant au ping est d'une taille de 32 octets. La taille du paquet peut être modifiée, par exemple sous Linux c'est 64 octets, soit 64 bytes en anglais (voir ci-dessous). Sous Windows, l'option "-l" permet de modifier la taille du paquet, par exemple pour 1024 octets : ping 192.168.100.11 -l 1024
temps=9 ms
Le temps nécessaire pour que le paquet puisse atteindre l'hôte distant (1.1.1.1) et faire le chemin retour pour revenir à notre machine. Ce temps est toujours exprimé en millisecondes.
TTL=56
TTL signifie Time To Live, ce qui correspond à la durée de vie du paquet avant qu'il ne soit détruit. En fait, lorsqu'un ping est émit il y a une valeur initiale pour le TTL qui est généralement fixée à 64 (ou 128). A chaque fois que le paquet va passer au travers d'un routeur, le TTL sera réduit de 1. Lorsque l'on voit un TTL=56, on peut en déduire que le paquet a traversé 8 routeurs avant d'atteindre sa cible : ce n'est pas étonnant puisque 1.1.1.1 correspond à l'adresse IP du DNS CloudFlare, sur Internet.
Note : lorsque l'on ping un hôte qui est sur le même segment réseau, par exemple connecté au même réseau WiFi à la maison, et bien, le TTL reste à 64 (ou à sa valeur initiale), car on ne traverse pas de routeur.
Pour lire les résultats d'une série de ping, on peut s'appuyer sur les statistiques affichées à la fin de la commande. On peut voir que j'ai envoyé 4 paquets, que j'en ai reçu 4, donc j'en ai perdu 0, ce qui signifie que la perte est de 0%. Tout va bien. On a également le temps de réponse moyen qui est calculé, ainsi que les temps de réponse max et min.
Statistiques du ping
Si l'on regarde l'aide de la commande ping (ping --help), on peut voir qu'il existe d'autres options. Par exemple, pour forcer l'utilisation d'IPv4 ou d'IPv6 :
ping www.domaine.fr -4
ping www.domaine.fr -6
Si l'on effectue un ping depuis une machine sous Linux, par exemple avec la distribution Kali Linux, on peut utiliser une syntaxe similaire pour effectuer un simple ping. La différence c'est que le ping va s'exécuter en continu et qu'il faudra l'arrêter manuellement.
ping 1.1.1.1
Exemple d'un ping sous Linux
Dans le cas où l'hôte distant ne répond pas au ping, cela peut s'expliquer par de nombreuses raisons :
L'hôte distant est injoignable à cause d'un problème de routage (acheminement du paquet sur le réseau)
Un pare-feu entre les deux machines bloque les pings
Le pare-feu local de l'hôte distant est configuré pour ne pas répondre au ping
Le ping est effectué sur un nom de domaine est le DNS ne parvient pas à résoudre ce nom
Etc.
Maintenant, passons à l'analyse d'un ping avec Wireshark.
V. Analyse d'un ping avec Wireshark
Pour capturer le trafic réseau généré par notre ping, il faut que l'on démarre une capture avec Wireshark. Enfin, on pourrait aussi utiliser un autre logiciel tel que tcpdump. Pour ma part, je vais émettre le ping depuis la machine avec l'adresse IP "192.168.100.101" vers le serveur avec l'adresse IP "192.168.100.11".
Une fois Wireshark lancé sur votre machine, cliquez sur "Capture" dans le menu puis "Options". Cela nous permet de sélectionner l'interface Ethernet et d'appliquer un filtre pour capture uniquement les échanges entre ma machine locale et le serveur avec l'adresse IP "192.168.100.11".
ip src 192.168.100.11 or ip dst 192.168.100.11
Vous pouvez aussi utiliser le filtre suivant basé sur le protocole :
icmp
On clique sur "Démarrer" pour lancer la capture, puis dans le même temps je lance le ping :
ping 192.168.100.11
En appliquant un filtre supplémentaire sur le protocole ICMP (on saisit "icmp" dans la barre des filtres et on valide), on obtient 8 paquets. C'est normal puisque sous Windows, 4 requêtes ping sont émises puis la commande s'arrête. Comme nous avons obtenu une réponse à chaque fois : 4 x 2 = 8 paquets.
Capture d'un ping (ICMP) avec Wireshark
Si l'on se réfère à la colonne "Info", on remarque deux informations importantes :
Echo (ping) request
Echo (ping) reply
La première correspond à la requête ping de ma machine locale, et la seconde à la réponse de l'hôte distant.
Si l'on sélectionne le paquet n°1 et que l'on regarde le contenu de l'en-tête ICMP, on peut voir des informations importantes :
Type: 8 (echo (ping) request)
Code: 0
Nous retrouvons le type et le code, comme je l'évoquais précédemment lors des explications théoriques. Avec cette analyse Wireshark, où l'on voit les paquets, on retrouve bien ces informations.
Analyse d'un ping avec Wireshark : ICMP Request
Dans le même esprit, si l'on prend le paquet n°2, on peut voir qu'il correspond à la réponse au ping reçue de la part du serveur distant (192.168.100.11).
Type: 0 (echo (ping) reply)
Code: 0
Analyse d'un ping avec Wireshark : ICMP Reply
Cet enchaînement de requêtes et de réponses est présent 4 fois, ce qui est logique. Au sein des paquets, on peut remarquer deux autres valeurs :
Identifier
Sequence Number
Ces numéros permettent d'ajouter un suivi au sein des paquets ICMP. De cette façon, quand notre hôte local reçoit une réponse de la part de l'hôte distant, il sait à quel paquet ICMP "Echo request" cette réponse correspond. Autrement dit, ces identifiants permettent de faire la correspondance entre les requêtes ping et les réponses ping entre deux hôtes.
Dans le cas où l'hôte distant ne réponse pas, la commande ping affiche "Délai d’attente de la demande dépassé.", tandis qu'au niveau de Wireshark, on peut "No response seen" et "No response found!". Au niveau des paquets, on peut voir les requêtes "echo request", mais les réponses ne sont pas là.
Dans cet exemple, nous venons d'émettre 4 requêtes ping "echo request" à destination du serveur. On peut dire que cela a permis de vérifier que les deux machines pouvaient communiquer ensemble.
Il faut savoir que le "ping" peut être utilisé dans le cadre d'attaques informatiques, notamment les attaques "ping flood" de type déni de service. L'objectif étant de surcharger l'ordinateur cible en lui envoyant tellement d'echo request qu'il n'arrive plus à suivre. À l'aide d'outils ping plus évolué (permettant de faciliter les attaques), l'attaquant va pouvoir s'en prendre à une machine, un routeur, un serveur, etc... Soit à partir d'une seule machine (Déni de service - DoS) ou d'un ensemble de machines (Déni de service distribué - DDoS) : tout dépend de la cible. En fait, on peut dire qu'il faut être plus fort que la cible pour réussir à la faire tomber.
VI. Conclusion
Bien que très simple d'utilisation, la commande ping est indispensable, car c'est un outil basique, mais qui est pertinent pour effectuer un premier diagnostique sur un réseau informatique. Au-delà de savoir l'utiliser au sein d'une console, que ce soit sous Windows ou Linux, vous en savez également un peu plus sur son fonctionnement grâce à l'analyse Wireshark effectuée !
Essential Addons for Elementor est un plugin populaire pour les sites WordPress, notamment parce qu'il compte plus d'un million d'installations actives. Le problème, c'est qu'il contient une faille critique de type "exécution de code à distance" (RCE). Faisons le point.
En exploitant cette faille de sécurité, un attaquant peut réussir à charger un fichier sur votre site, par exemple un fichier PHP, afin d'exécuter du code malveillant. Cette vulnérabilité est particulièrement dangereuse, car elle peut être exploitée à distance et sans être authentifié sur le site. D'après les chercheurs en sécurité de PatchStack, à l'origine de cette découverte, la vulnérabilité se situe au sein des fonctions "ajax_load_more" et "ajax_eael_product_gallery".
Si vous utilisez le plugin Essential Addons for Elementor en version 5.0.4 ou inférieur, votre site est peut-être vulnérable ! Je dis "peut-être", car il faut que les widgets "dynamic gallery" et "product gallery" soient actifs sur le site, en plus d'utiliser une version vulnérable.
Ce qui est surprenant, c'est qu'il y a déjà eu deux tentatives pour patcher cette vulnérabilité, et c'est pour ça qu'il y a eu les versions 5.0.3 puis 5.0.4 du plugin. Sauf que le correctif apporté n'était pas suffisant puisque les chercheurs de PatchStack sont parvenus à le contourner : d'où la sortie d'une nouvelle version, en l'occurrence la 5.0.5 pour corriger définitivement ce problème de sécurité.
Cette version est disponible depuis le 28 janvier 2022 et elle est progressivement installée sur les sites WordPress par les webmasters. Même s'il y a plus d'un million d'installations actives de ce plugin, certains sites sont déjà patchés. Malgré tout, d'après les statistiques de téléchargements WordPress, il en resterait encore environ 600 000 à patcher.
Si vous utilisez ce plugin WordPress, vous devez effectuer la mise à jour dès que possible afin de passer du bon côté, c'est-à-dire du côté des sites protégés contre cette faille de sécurité !
Une faille de sécurité critique touche Samba puisqu'elle permet à un attaquant d'exécuter du code à distance sur le serveur en bénéficiant des droits "root". De nouvelles versions de Samba sont disponibles.
Pour rappel, Samba est une solution open source pour Linux qui permet de partager des fichiers et des imprimantes grâce à l'intégration du protocole SMB, très populaire sur les systèmes Windows. Une fois en place, des machines sous Windows, Linux ou macOS peuvent s'appuyer sur le serveur Samba pour accéder aux données accessibles via les partages.
Samba et la vulnérabilité CVE-2021-44142
Parlons maintenant de la vulnérabilité. Découverte par Orange Tsai de Devcore, elle est associée à la référence CVE-2021-44142. Il s'agit d'une vulnérabilité out-of-bounds en lecture/écriture présente dans le module VFS "vfs_fruit", ce dernier étant utilisé lors de l'analyse des métadonnées au moment où smbd ouvre les fichiers. Le fait que ce soit une vulnérabilité out-of-bounds, signifie que le logiciel va lire ou écrire les données après la fin, ou avant le début, du tampon prévu. Quant au module vfs_fruit il permet d'améliorer la compatibilité avec les clients SMB Apple et les serveurs Netatalk 3.
Au sein du bulletin de sécurité publié sur le site de Samba, c'est précisé que la faille de sécurité est "activée" par défaut compte tenu de la configuration d'origine du module "vfs_fruit" : fruit:metadata=netatalk ou fruit:resource=file. Si ces deux options sont configurées différemment, le système n'est pas vulnérable.
Un accès en tant qu'utilisateur non authentifié disposant d'un accès en écriture sur les attributs étendus d'un fichier est nécessaire pour exploiter cette vulnérabilité. Si cette condition est remplie, l'attaquant peut exécuter du code malveillant à distance sur le serveur Samba.
CVE-2021-44142 : quels sont les systèmes affectés ?
Les serveurs Samba avec une configuration par défaut du module vfs_fruit et surtout une version vulnérable, seront considérés comme vulnérables. Sur le site du CERT/CC, il y a une page très intéressante qui recense les systèmes vulnérables, et même si la liste contient de nombreux systèmes avec l'état "Inconnu" (pour le moment), il y a quelques systèmes populaires qui sont affectés :
Red Hat
SUSE Linux
Ubuntu
Cette liste devrait très fortement s'allonger.
Samba étant implémenté au sein du système de nombreux NAS, notamment pour les fonctions liées au partage de fichiers via le protocole SMB, il y a des chances pour que des mises à jour sortent prochainement chez les différents constructeurs. En tout cas, c'est qu'il faut espérer.
Comment se protéger de la vulnérabilité CVE-2021-44142 ?
De nouvelles versions de Samba sont disponibles pour les différentes versions encore supportées. Afin de vous protéger, vous devez installer l'une des versions suivantes :
Samba 4.13.17
Samba 4.14.12
Samba 4.15.5
Si vous avez une version inférieure à la version 4.13.17, de toute façon votre serveur est vulnérable. Pour les utilisateurs qui ne sont pas en mesure d'appliquer la mise à jour de Samba dans l'immédiat, il existe une solution temporaire. Cette solution consiste à éditer le fichier de configuration smb.conf pour retirer les appels "fruit" des lignes associées au module VFS, mais attention, cela peut avoir des effets de bord notamment si vous utilisez des clients Apple.
Google a pris la décision d'abandonner la formule gratuite de G-Suite, alors les utilisateurs qui en profitaient jusqu'ici vont devoir passer à la caisse pour continuer à utiliser cette solution.
Ce changement majeur au sein de G-Suite qui touche la version gratuite a été annoncé aux utilisateurs par l'intermédiaire d'un e-mail envoyé par Google. Grâce à cette version, il était possible d'accéder à certaines applications sans payer, et surtout il était possible d'utiliser un nom de domaine personnalisé et différent de gmail.com. Pour les petites entreprises, c'était une opportunité intéressante.
Source : 9to5google.com
Abandonné depuis 2012 par Google, G-Suite était toujours disponible pour les utilisateurs, mais désormais il va falloir prendre un abonnement Google Workspace pour continuer à profiter des applications. Au sein de l'e-mail envoyé par Google, c'est précisé que les utilisateurs ont jusqu'au 1er mai 2022 pour choisir une offre payante, à moins de changer de solution et quitter Google.
Si vous ne faites rien d'ici là, cela ne signifie pas que votre compte sera fermé ! Non, Google a une autre idée en tête ! En effet, la firme de Mountain View procédera automatiquement à la transition des abonnements en choisissant pour vous l'offre qui convient le mieux à vos usages, selon les fonctionnalités que vous utilisez. Si vous n'avez pas ajouté de moyen de paiement à votre compte, cette transition sera compromise alors le compte sera suspendu par Google à partir du 1er mai. Après 60 jours, si rien n'est fait, l'accès aux différentes applications sera révoqué, notamment Gmail, Google Meet et l'Agenda. Compte tenu de ce délai de 60 jours, on peut considérer que l'offre gratuite de G-Suite sera définitivement arrêtée le 1er juillet 2022.
Suite au mécontentement des utilisateurs notamment les particuliers qui n'utilisent pas cette solution à des fins commerciales, Google pourrait revoir sa copie. Une enquête est en ligne et il est recommandé de la compléter si vous êtes concerné afin de recevoir des informations et alternatives complémentaires de la part de Google.
Au niveau des tarifs Google Workspace, l'offre la moins chère est proposée à 4,68 euros par mois et par utilisateur. Même si dans un premier temps, les utilisateurs vont bénéficier d'une remise commerciale de Google pendant 12 mois, cela va changer la donne malgré tout.
Microsoft et les autres commencent déjà à se frotter les mains, car voilà une opportunité de récupérer des clients supplémentaires...
En complément, voici la page d'assistance sur le sujet afin de suivre les éventuels changements à venir.
