malware interplanetary storm

Focus sur les menaces : la nouvelle variante du malware InterPlanetary Storm cible les appareils IoT

Version imprimable, PDF et e-mail

L'organisation cybercriminelle à l'origine du malware InterPlanetary Storm a lâché dans la nature une nouvelle variante du malware, ciblant désormais les appareils Mac et Android en plus des machines sous Windows et Linux. Selon les chercheurs de Barracuda, ce malware construit un botnet qui comprend actuellement environ 13 500 machines infectées situées dans 84 pays à travers le monde, et ce chiffre ne cesse d'augmenter.

La majorité des machines infectées par ce malware sont situées en Asie :

  • 59 % des machines infectées se trouvent à Hong Kong, en Corée du Sud et à Taiwan ;
  • 8 % se trouvent en Russie et en Ukraine ;
  • 6 % se trouvent au Brésil ;
  • 5 % se trouvent aux États-Unis et au Canada ;
  • 3 % se trouvent en Suède ;
  • 3 % se trouvent en Chine ; et
  • tous les autres pays représentent 1 % ou moins.

Intéressons-nous plus en détail à l'évolution et à la propagation de cette menace, et découvrons les solutions qui vous aideront à la détecter, à la bloquer et à réparer ses éventuels dégâts.

InterPlanetary Storm

Menaces particulièrement importantes

Nouvelle variante du malware InterPlanetary Storm. Cette nouvelle variante du malware accède aux machines en lançant une attaque par dictionnaire contre les serveurs SSH, à l'instar de FritzFrog, un autre malware basé sur un botnet en peer-to-peer (p2p). Il peut également pénétrer les machines via les serveurs ADB (Android Debug Bridge) ouverts. Le malware détecte l'architecture du processeur et le système d'exploitation de ses victimes, et peut s'exécuter sur des machines ARM, architecture assez courante pour les routeurs et autres appareils IoT.

Ce malware est baptisé InterPlanetary Storm, car il utilise le protocole p2p IPFS (Système de fichier inter-planétaire) et son implémentation libp2p sous-jacente. Les nœuds infectés peuvent ainsi communiquer directement entre eux ou par l'intermédiaire d'autres nœuds (c'est-à-dire par des relais).

La première variante de Interplanetary Storm, qui ciblait les machines Windows, a été découverte par les chercheurs d'Anomali en mai 2019. La variante capable d'attaquer les machines Linux a été signalée en juin 2020. Cette toute nouvelle variante, que les chercheurs de Barracuda ont détectée pour la première fois fin août 2020, cible les appareils IoT, tels que les téléviseurs fonctionnant sur les systèmes d'exploitation Android, et les machines fonctionnant sous Linux, comme les routeurs avec un SSH mal configuré.

Bien que le botnet mis en place par ce malware n'ait pas encore de fonctionnalité claire, il offre aux instigateurs de la campagne une porte dérobée vers les appareils infectés qui peuvent ensuite être utilisés pour du cryptominage, des attaques DDoS ou d'autres attaques à grande échelle.

Les détails

Cette variante de InterPlanetary Storm est écrite en Go, utilise l'implémentation Go de libp2p et est compressée avec UPX. Elle se propage à l'aide d'attaques par force brute des services SSH et via les ports ADB ouverts, et distribue des fichiers du malware à d'autres nœuds du réseau. Le malware permet également de faire un shell inversé et d'exécuter un shell Bash.

Les chercheurs de Barracuda ont découvert plusieurs fonctionnalités spécialement conçues pour aider le malware à perdurer et pour le protéger une fois qu'il a infecté une machine.

  • Il détecte les honeypots. Le malware recherche la chaîne « svr04 » dans l'invite par défaut du shell (PS1), qui était utilisée auparavant par le honeypot Cowrie.
  • Il se met à jour automatiquement. Le malware compare la version de l'instance en cours d'exécution avec la dernière version disponible et se met à jour en conséquence.
  • Il tentera de perdurer en installant un service (system/systemv) à l'aide d'un paquet Go Daemon.
  • Il tue d'autres processus sur la machine qui constituent une menace pour lui, tels que des débogueurs ou des malwares concurrents. Il le fait en recherchant les chaînes de caractères suivantes dans la ligne de commande du processus :
    • “/data/local/tmp”
    • “rig”
    • “xig”
    • “debug”
    • “trinity”
    • “xchecker”
    • “zypinstall”
    • “startio”
    • “startapp”
    • “synctool”
    • “ioservice”
    • “start_”
    • “com.ufo.miner”
    • “com.google.android.nfcguard”
    • “com.example.test”
    • “com.example.test2”
    • “saoas”
    • “skhqwensw”

Les clés connues de InterPlanetary Storm

L'infrastructure backend du malware affiche les clés suivantes dans la table de hachage distribuée (DHT) de l'IPFS. Les nœuds infectés tenteront alors de trouver des pairs qui peuvent fournir les services nécessaires :

Clé Objectif
requeBOHCHIY2XRMYXI0HCSZA C2
proxybackendH0DHVADBCIKQ4S7YOX4X Proxy back‑end
web-api:kYVhV8KQ0mA0rs9pHXoWpD Distribution de fichiers back‑end

Chaque nœud infecté affichera la clé « fmi4kYtTp9789G3sCRgMZVG7D3uKalwtCuWw1j8LSPHQEGVBU5hfbNdnHvt3kyR1fYUlGNAO0zactmIMIZodsOha9tnfe25Xef1 » afin d'indiquer qu'il fait partie du botnet. L'identifiant de chaque machine infectée sera généré une fois, lors de l'infection initiale, et sera réutilisé si la machine redémarre ou si le malware se met à jour.

Les nœuds infectés afficheront également des clés sous la forme « stfadv:<checksum> » afin de signaler que le nœud peut fournir un fichier avec cette somme de contrôle.

Protocoles de communication

Les applications libp2p gèrent les connexions entrantes (les flux) sur la base d'une adresse logique (c'est-à-dire inconnue de la couche de transport) appelée ID de protocole. Par convention, les ID de protocole disposent d'une structure en forme de chemin, avec un numéro de version comme élément final.

Le malware utilise les ID de protocole suivants :

ID de protocole Objectif Notes
/sbst/1.0.0 Utilisé pour générer un shell inversé Hébergé sur des nœuds
/sfst/1.0.0 Utilisé pour transférer les fichiers Hébergé sur des nœuds, la somme de contrôle des fichiers sert à l'intégrité du fichier accédé
/sbpcp/1.0.0 Utilisé pour le proxy, pour se connecter au serveur back‑end Hébergé sur des serveurs back‑end
/sbptp/1.0.0 Utilisé pour le proxy. Chaîne de proxy de transfert Hébergé sur des nœuds
/sreque/1.0.0 Utilisé pour la file d'attente du scanner Hébergé sur des nœuds, les commandes du c2 contiennent la signature.

Les messages de cette chaîne sont sérialisés à l'aide d'objets JSON. Les messages du c2 seront soit pour « brute-ssh » soit pour « tcp-scan », indiquant au nœud de rechercher les machines vulnérables. Le nœud enverra les résultats de ces scans.

Les messages « brute-ssh » du c2 incluront une liste d'IP à attaquer ainsi que les identifiants à utiliser.

Distribution de fichiers back‑end

Les serveurs de distribution de fichiers peuvent être découverts en utilisant la clé « web-api:kYVhV8KQ0mA0rs9pHXoWpD ». Les pairs concernés implémentent HTTP sur le protocole libp2p et fournissent les URL suivantes :

Chemin Méthode Description
/version GET Obtient la version pair
/files/checksum?f=<file name> GET Obtient la somme de contrôle actuelle du fichier <nom du fichier>
/files/seedrs-http?c=<checksum> GET Obtient une liste de nœuds capables d'accéder au fichier
POST /files/seedrs-http article, Ajoute des informations sur les nœuds
/nodes/ article, Ajoute des informations sur les nœuds

Inversion de contrôle (IOC)

Le malware pourrait déposer certains des fichiers suivants :

storm_android-amd64 d4e3102b859ebfda5a276b2ce6f226e27fdcdef5e693ee7742be863236e2374a 
storm_android-386 9dab7f5ff2873389a4b0e68cb84978fc5907cd2579bd15a1d39e277f5d2fdc27
storm_android-arm64 16bcb323bfb464f7b1fcfb7530ecb06948305d8de658868d9c3c3c31f63146d4
storm_android-arm7 56c08693fdf92648bf203f5ff11b10b9dcfedb7c0513b55b8e2c0f03b209ec98 
storm_linux-amd64 ab462d9d2a9a659489957f80d08ccb8a97bbc3c2744beab9574fda0f74bd1fe2 
Storm_linux-386 ba1e8d25cc380fdbbf4b5878a31e5ed692cfd2523f00ca41022e61f76654dd4f
storm_linux-arm64 50406ec7fa22c78e9b14da4ccc127a899db21f7a23b1916ba432900716e0db3d
storm_linux-arm7 a2f4c9f8841d5c02ffd4573c5c91f7711c7f56717ddb981f719256163be986e8 
storm_darwin-amd64 4cd7c5ee322e55b1c1ae49f152629bfbdc2f395e9d8c57ce65dbb5d901f61ac1 

Se protéger contre ces attaques

Certaines des mesures que nous allons vous présenter sont importantes et pourront vous aider à vous protéger contre cette nouvelle variante.

  • Configurez correctement l'accès SSH sur tous les appareils. Utilisez donc des clés plutôt que des mots de passe, l'accès sera ainsi plus sécurisé. Lorsque la connexion par mot de passe est activée et que le service lui-même est accessible, le malware peut exploiter la surface d'exposition mal configurée. C'est un problème courant pour les routeurs et les appareils IoT, qui constituent donc des cibles faciles pour ce malware.
  • Utilisez un outil de gestion de la stratégie de sécurité cloud pour surveiller le contrôle d'accès SSH afin d'éliminer toute erreur de configuration, erreur pouvant se révéler catastrophique. Fournissez un accès sécurisé aux shells si nécessaire ; plutôt que d'exposer la ressource sur Internet, déployez une connexion VPN compatible MFA et segmentez vos réseaux pour les besoins spécifiques au lieu d'accorder l'accès à l'ensemble des réseaux IP.

Analyse de sécurité du cloud

Leave a Reply

Your email address will not be published. Required fields are marked *

Remonter en haut de page
Tweeter
Partager
Partager