- Le package Lotusbail est un fork de la bibliothèque WhatsApp Web API légitime Baileys et constitue un package contenant du code malveillant qui a été téléchargé plus de 56 000 fois sur npm en six mois
- Tout en fournissant des fonctions API qui marchent normalement, il vole les identifiants WhatsApp, les messages, les contacts et les fichiers médias puis les envoie vers le serveur des attaquants
- Les données sont transmises après plusieurs couches de chiffrement et d’obfuscation, notamment RSA, AES, Base-91 et LZString, ce qui permet d’échapper à la surveillance de sécurité
- Le package installe une porte dérobée qui relie de façon permanente l’appareil de l’attaquant au compte WhatsApp de l’utilisateur via un code d’appairage codé en dur
- Ce cas montre la sophistication croissante des attaques de la chaîne d’approvisionnement et souligne la nécessité d’une surveillance de sécurité fondée sur le comportement, impossible à remplacer par la seule analyse statique
Vue d’ensemble du package Lotusbail
lotusbailest un fork du package légitime@whiskeysockets/baileyset fournit à l’identique les fonctions de WhatsApp Web API- L’envoi et la réception de messages fonctionnent normalement, ce qui augmente la probabilité que des développeurs l’installent sans soupçon
- Il est resté publié sur npm pendant six mois et, au moment de la rédaction, il était toujours téléchargeable
- Derrière ces fonctions réelles se cachent des comportements malveillants comme le vol d’identifiants WhatsApp, l’interception de messages, la collecte de contacts et l’installation d’une porte dérobée
Informations dérobées
- Cela inclut les jetons d’authentification et clés de session, l’historique complet des messages, la liste de contacts avec numéros de téléphone, les fichiers médias et documents, ainsi qu’un accès persistant via porte dérobée
- Toutes les données sont chiffrées avant d’être envoyées au serveur des attaquants
Mode de fonctionnement
Une fonction de camouflage qui marche réellement
- La plupart des packages npm malveillants sont faciles à repérer parce qu’ils dysfonctionnent ou contiennent du code suspect, mais Lotusbail se déguise en API fonctionnelle
- Il repose sur la bibliothèque Baileys légitime et implémente complètement les fonctions d’envoi et de réception de messages
- Cela relève d’une technique d’ingénierie sociale qui amène les développeurs à ne pas soupçonner d’activité malveillante dans un « code qui fonctionne normalement »
Vol et transmission des données
- Le package fonctionne comme une enveloppe autour du client WebSocket qui communique avec WhatsApp
- Lors de l’authentification, il capture les identifiants, et lors de la réception comme de l’envoi de messages, il duplique l’intégralité du contenu
- Les fonctions normales restent intactes, mais toutes les données sont simplement transmises en double aux attaquants
- Les données volées sont chiffrées avant transmission au moyen d’une implémentation RSA personnalisée
- Elle existe séparément du chiffrement de bout en bout de WhatsApp et sert de chiffrement destiné à contourner la surveillance réseau
- L’adresse du serveur n’apparaît pas directement dans le code, mais est cachée dans une chaîne de configuration chiffrée
- Une obfuscation en quatre étapes est appliquée : manipulation de variables Unicode, compression LZString, encodage Base-91 et chiffrement AES
Installation de la porte dérobée
- Le package abuse de la fonction de code d’appairage d’appareil de WhatsApp pour connecter l’appareil de l’attaquant au compte de l’utilisateur
- Il contient un code d’appairage codé en dur chiffré avec AES
- Quand l’utilisateur s’authentifie, l’appareil de l’attaquant est aussi connecté simultanément, ce qui lui donne un accès persistant au compte
- L’attaquant peut alors contrôler l’ensemble du compte : lecture et envoi de messages, téléchargement de médias, accès aux contacts, etc.
- Même si le package npm est supprimé, l’appareil de l’attaquant reste connecté ; pour le bloquer, il faut déconnecter manuellement tous les appareils dans les paramètres de WhatsApp
Techniques d’évasion de l’analyse
- Le code contient 27 pièges en boucle infinie qui interrompent l’exécution lorsqu’un outil de débogage est détecté
- Il détecte le débogueur, les arguments de processus, les environnements sandbox, etc., afin de gêner l’analyse dynamique
- Des commentaires sont présents dans les sections malveillantes du code, signe de traces d’une gestion de développement structurée
Conclusion et implications de sécurité
- La sophistication des attaques de la chaîne d’approvisionnement progresse, avec une hausse des cas déguisés en code fonctionnel
- La détection est difficile avec la seule analyse statique et la validation fondée sur la réputation ; une analyse comportementale à l’exécution (behavioral analysis) est nécessaire
- Le cas Lotusbail exploite une faille de sécurité fondée sur l’idée que « si le code fonctionne, alors il est sûr », et montre l’importance de mettre en place des systèmes de surveillance du comportement à l’exécution
- L’équipe de recherche de Koi Security a identifié ce type de menace, capable de contourner les procédures de vérification existantes, grâce à ces techniques de détection fondées sur l’exécution
1 commentaires
Réactions sur Hacker News
C’est frustrant de voir qu’à chaque incident de malware, les équipes sécurité répondent en verrouillant excessivement les données
La fuite de messages WhatsApp a servi de déclencheur, mais les attaquants auraient fini par voler autre chose
Si on bloque la lecture d’une app à certaines signatures seulement, on empêche aussi les sauvegardes légitimes et l’accès normal aux données
Renforcer la sécurité, c’est bien, mais tout verrouiller de manière excessivement défensive crée aussi d’autres problèmes
L’utilisateur s’y connecte comme il connecterait un autre client à son compte WhatsApp, ce qui donne ensuite accès à l’ensemble des données
Si WhatsApp proposait une vraie API officielle, ce genre de situation serait moins fréquent
Documentation associée : Baileys Wiki
Il y avait plus de malwares avant, mais aussi davantage de liberté et d’interopérabilité
Ce type d’attaque me semble désormais être une conséquence prévisible
Les gestionnaires de paquets comme NPM sont fondamentalement vulnérables, puisqu’ils récupèrent les dépendances juste avant le build
Le problème, c’est une culture qui contourne le contrôle de version tout en acceptant sans vérification d’innombrables dépendances
Ce n’est pas propre à NPM : Cargo, Docker, CI/CD et tout le reste ont des problèmes similaires
Le modèle du « on installe par nom et c’est tout » repose sur une confiance bien trop forte
Il n’y a pas de solution évidente — on ne peut pas renoncer à collaborer, mais une sécurité parfaite est tout aussi impossible
Au final, le monstre est déjà dans la maison
On obtiendrait le même résultat en pointant directement vers une URL git
Au fond, c’est un problème structurel de gestion des dépendances
On aurait besoin d’un gestionnaire de paquets standardisé et indépendant du langage
La vérification des signatures, la garantie de provenance et la standardisation des API seraient indispensables
Comme l’a montré l’affaire xz, des paquets compromis peuvent être distribués tels quels
En plus, les gestionnaires système prennent du retard sur les versions récentes et sont mal adaptés au développement
C’est justement pour cela qu’on a besoin d’outils comme npm, cargo ou pip
Le problème ne vient pas du gestionnaire de paquets en soi, mais du fait que le code n’était pas digne de confiance dès le départ
Le fait que l’auteur du malware ait utilisé un nom de fonction aussi explicite que exfiltrateCredentials est assez drôle
C’est ironique d’avoir ajouté de la détection de débogueur sans même obfusquer le code
Même le test de malware est désormais devenu une forme de développement
L’expression « une dépendance qu’un développeur installe sans réfléchir » fait froid dans le dos
Sauf dans les organisations aux politiques de sécurité strictes, c’est difficile à empêcher en pratique
La seule solution est peut-être, au fond, d’utiliser moins npm
Si on les référence par tag, on s’expose à tout moment à une attaque de la chaîne d’approvisionnement
L’industrie fonctionne sur bien plus de confiance aveugle qu’on ne l’imagine
Les systèmes de déploiement automatisé n’ont même pas le temps de « réfléchir à deux fois »
Ce serait bien que JavaScript ait aussi une grande bibliothèque fiable du type Apache Commons
Présentation d’Apache Commons
Le package lotusbail est un package npm malveillant se faisant passer pour l’API WhatsApp Web
Il a été distribué pendant six mois et a mené diverses attaques, notamment le vol d’identifiants, l’interception de messages et l’installation de backdoors
Les développeurs dépendants de l’écosystème JS ont, de façon réaliste, besoin de stratégies d’atténuation du risque
L’usage de Docker ou de VM a notamment été évoqué
Nous avions conteneurisé tous les environnements de développement et verrouillé les dépendances sur des versions fixes
Installations globales interdites, mises à jour automatiques interdites, validation manuelle obligatoire
Pour les projets sensibles, nous fournissions des stations de travail dédiées régulièrement réinitialisées
C’est contraignant, mais c’est une sécurité réaliste
Sinon, quitter l’écosystème JS est aussi une option
Il faudrait pouvoir vérifier au niveau de l’OS ou de Docker si une connexion réseau doit être autorisée ou non
Le noyau est partagé, mais c’est suffisant pour se protéger des attaques venant de l’écosystème JS
Si une attaque d’évasion de conteneur apparaît un jour sur npm, je passerai alors à une VM
Au départ, je trouvais cette sécurité excessive, mais aujourd’hui je la trouve rapide et stable
Cela laisse le temps de voir s’ils se révèlent malveillants
Ce package représentait dès le départ un échec de sécurité
Il ne s’appuyait pas sur une API officielle, mais sur une réimplémentation de l’authentification client, et des secrets utilisateur étaient traités par un tiers
L’utilisateur aurait dû être plus prudent, mais il est difficile de lui en faire porter toute la responsabilité
Il faut s’inscrire à la WhatsApp Business Platform pour avoir accès à l’API
S’il existait une véritable API, cela ne se serait probablement pas produit
En revanche, confier des secrets d’authentification à un tiers est risqué
En général, on installe ce type de package pour automatiser son propre compte
On voit aujourd’hui proliférer les billets de blog générés par des LLM
Leur qualité est faible, mais comme leur coût est quasi nul, c’est très efficace du point de vue marketing
L’écriture traditionnelle est désormais presque devenue un legacy
On a l’impression que les attaques de la chaîne d’approvisionnement se multiplient. Comment les développeurs doivent-ils réagir ?
Il faut détecter automatiquement ce type de schéma et renforcer les procédures de vérification
La conteneurisation, le verrouillage des dépendances, les scans de sécurité et les mises à jour différées sont indispensables
Les installations globales npm sont le pire choix possible
Des conteneurs comme rootless podman ou des VM permettent de réduire le risque au minimum