La variante ARC du malware Satori

Satori, l’héritier présomptif du sinistre malware IoT Mirai, a été découvert par des chercheurs en décembre 2017. Si le mot « satori » signifie « éclaircissement » ou « compréhension » en japonais, l’évolution du malware du même nom a apporté tout sauf de la clarté. Chaque nouvelle version présente une combinaison inédite de plates-formes ciblées, de techniques de propagation et de types d’attaques. Contrairement aux logiciels classiques, où des fonctionnalités viennent s’ajouter graduellement, Satori paraît à la fois progresser et régresser. Un examen de son historique va nous éclairer sur cette menace en évolution constante.

Un bref rappel sur les malwares IoT

Les attaques DDoS massives qui ont fait la une de l’actualité ont commencé à attirer l’attention du public sur la sécurité de l’Internet des objets (IoT) vers la fin 2016. Les responsables du malware concerné, Mirai, ne ciblaient pas les machines Windows comme la plupart des menaces mais des failles dans les équipements IoT et d’autres systèmes embarqués. Ces objets constituent d’excellents zombies pour les assauts DDoS car ils emploient souvent une version allégée de Linux, sont connectés directement à Internet et ne disposent que de fonctions limitées en matière de sécurité.

Mirai et ses nombreux imitateurs opèrent selon des principes similaires :

Propagation: les équipements infectés tentent d’en contaminer d’autres, choisis au hasard. Au départ, Mirai se servait de paires courantes nom d’utilisateur+mot de passe, au moyen du protocole ancien telnet. Pour se répandre, les versions ultérieures exploitaient des vulnérabilités spécifiques à chaque plate-forme, par exemple des bugs d’injection de commandes dans l’interface Web des routeurs domestiques.
Commande et contrôle (C&C) : une fois infecté, le zombie – en dehors de ses tentatives de propagation – contacte périodiquement un serveur C&C afin d’obtenir des mises à jour et des commandes d’attaque.
Attaque : suivant les instructions du site C&C, les zombies lancent un flux coordonné de trafic d’attaque dirigé vers la victime. Il peut s’agir de paquets TCP dont certains drapeaux sont positionnés, de paquets UDP, de requêtes HTTP ou d’autres attaques plus complexes.

Les auteurs de Mirai ont fini par publier le code source du malware. Grâce à celui-ci, quiconque sachant se servir d’un compilateur pouvait configurer son propre site C&C et se constituer rapidement un botnet Mirai. Un peu plus de savoir-faire technique permettait d’ajouter des fonctionnalités, telles que de nouveaux modes de propagation, protocoles C&C et types d’attaque.

Satori

Les chercheurs ont découvert Satori pour la première fois en décembre 2017 et identifié d’autres versions par la suite. La version initiale de Satori se distinguait de Mirai du fait que son mode de propagation exploitait deux vulnérabilités dans des équipements IoT : une faille « Zero Day » dans la passerelle domestique de Huawei et une vulnérabilité déjà connue touchant l’exécution de commandes dans l’interface UPnP SOAP de Realtek. Les cibles étaient clairement deux types d’équipements très spécifiques, à la différence de Mirai qui infectait tout système présentant une faille ou utilisant un identifiant et un mot de passe telnet faciles à deviner. Bien que des indices montrent la réutilisation par Satori d’au moins une partie du code Mirai rendu public, la précision de son ciblage a retenu l’attention des chercheurs.

Sans doute afin de brouiller davantage encore les pistes, d’autres versions de Satori utilisaient telnet pour se propager mais via une liste plus élaborée d’identifiants et de mots de passe.

Chaque malware IoT, y compris Satori, est transmis à une victime sous une forme compilée et prête à s’exécuter, en l’occurrence un exécutable Linux spécialement compilé pour l’architecture ciblée. Par exemple, un équipement ARM ne peut pas exécuter du code compilé pour les processeurs x86. Avant de délivrer leur charge malveillante, Mirai et Satori testent la victime pour déterminer quelle version précompilée du fichier binaire Mirai télécharger et exécuter. Satori a placé la barre encore plus haut en introduisant de nouvelles architectures, superh et ARC. Il est difficile de dire si les auteurs de Satori ont procédé de la sorte car ils connaissaient l’existence d’un parc d’équipements vulnérables ou simplement l’espéraient.

Le tableau ci-dessous recense les similitudes et les différences, d’après l’analyse ASERT, entre les trois variantes les plus récentes de Satori. Des informations complémentaires, en particulier d’autres indicateurs d’infection (IoC), sont fournies par les références ^[1] à ^[5]. La variante n°1 n’est pas incluse en raison de son manque de fonctionnalités (voir ^[1]).

Nous distinguons la variante n°4 de Satori, en partie parce qu’elle paraît constituer le premier malware connu ciblant les processeurs ARC. La capacité nouvelle de s’exécuter sur cette plate-forme élargit considérablement le contingent potentiel du botnet. Selon l’article référencé ^[6], datant de 2014, « les cœurs de processeur ARC sont utilisés sous licence par au moins 190 entreprises, dans plus de 1,5 milliard de produits chaque année. » En outre, l’implantation sur cette architecture ouvre la voie à d’autres malwares ciblant celle-ci.

Neutralisation des attaques DDoS

Etant donné que les variantes de Satori font toutes appel à différents sous-ensembles de la base de code d’attaque DDoS Mirai, les conseils prodigués de longue date pour la neutralisation des assauts de Mirai restent valables.

En outre, l’expansion constante de malwares capables de lancer des attaques DDoS sur différentes architectures de processeur souligne davantage encore la nécessité pour les opérateurs d’adopter sur leurs réseaux les meilleures pratiques en usage. Tandis que Mirai affichait une prédilection pour les caméras IPTV et les enregistreurs DVR dotés de mots de passe faibles, les auteurs de menaces ont tout intérêt à cibler des équipements originaux. En se tournant vers la plate-forme ARC et d’autres processeurs embarqués, les malwares DDoS peuvent asservir un éventail plus large d’appareils connectés à Internet (téléphones, consoles de jeu, etc.). Les opérateurs réseau doivent repenser leur stratégie de défense afin de se prémunir également contre le piratage d’équipements internes, notamment ceux qu’il n’est pas possible de pister en suivant un câble. Les dommages collatéraux en raison de la scrutation des identifiants et des attaques DDoS sortantes peuvent à eux seuls être handicapants faute d’une application proactive des meilleures pratiques en matière d’architecture et d’exploitation du réseau. Voir à ce sujet les références ^[7] et ^[8].

En conclusion

Alors que l’impact des malwares IoT est évident, le paysage des menaces ne cesse d’évoluer. Le maillon le plus faible – les identifiants et mots de passe par défaut – ayant déjà été largement exploité, les auteurs des attaques se tournent vers des solutions plus fructueuses, c’est-à-dire les vulnérabilités présentes dans les équipements eux-mêmes. Cela confirme le signe annonciateur apparu avec Mirai en 2016 : les équipements IoT ne sont pas sécurisés et seront piratés. Nous pensons que les trois principes des malwares IoT – propagation, C&C, attaques – demeureront inchangés mais gagneront en complexité et évolueront dans le temps.