L’une des plus grandes plateformes vietnamiennes de crypto trading, l’ONUS, a récemment subi une cyberattaque sur son système de paiement exécutant une version vulnérable de Log4j.
Assez rapidement, les acteurs de la menace ont approché l’ONUS pour extorquer une somme de 5 millions de dollars et ont menacé de publier les données des clients si l’ONUS refusait de se conformer.
Après le refus de l’entreprise de payer la rançon, les acteurs malveillants ont mis en vente les données de près de 2 millions de clients de l’ONUS sur des forums.
Le logiciel de paiement a exécuté une version vulnérable de log4j
Le 9 décembre, le Exploiter le PoC pour la fameuse vulnérabilité Log4Shell (CVE-2021-44228) divulguée sur GitHub. Et cela a attiré l’attention d’attaquants opportunistes qui ont commencé balayage de masse Internet pour les serveurs vulnérables.
Entre le 11 et le 13 décembre, des acteurs malveillants ont exploité avec succès la vulnérabilité Log4Shell sur un serveur Cyclos de l’ONUS et ont implanté des portes dérobées pour un accès durable.
Cyclos propose une gamme de solutions logicielles de point de vente (POS) et de paiement et, comme la plupart des fournisseurs, utilisait une version vulnérable de log4j dans son logiciel.
Bien que Cyclos ait émis un consultatif le 13 et aurait informé l’ONUS de patcher leurs systèmes, il était trop tard.
Bien que l’ONUS ait corrigé son instance Cyclos, la fenêtre d’exposition a laissé suffisamment de temps aux acteurs malveillants pour exfiltrer les bases de données sensibles.
Ces bases de données contenaient près de 2 millions d’enregistrements de clients, y compris des données E-KYC (Know Your Customer), des informations personnelles et des mots de passe hachés.
Les flux de travail E-KYC utilisés par les banques et les sociétés FinTech impliquent généralement l’obtention d’une forme de documents d’identification et de preuves auprès des clients, ainsi qu’un « selfie vidéo » pour une vérification automatisée.
Fait intéressant, la vulnérabilité Log4Shell existait sur un serveur sandbox utilisé « à des fins de programmation uniquement », mais permettait aux attaquants d’accéder davantage à des emplacements de stockage de données sensibles (seaux Amazon S3) avec des données de production, en raison d’une mauvaise configuration du système.
L’ONUS aurait ensuite été giflé avec une demande d’extorsion de 5 millions de dollars qu’ils ont refusé de satisfaire. Au lieu de cela, l’entreprise a choisi de divulguer l’attaque à ses clients via un groupe Facebook privé.
« En tant qu’entreprise qui accorde la priorité à la sécurité, nous nous engageons à fournir à nos clients transparence et intégrité dans leurs opérations commerciales », a déclaré le PDG de l’ONUS, Chien Tran.
« C’est pourquoi, après un examen attentif, la bonne chose que nous devons faire maintenant est d’informer l’ensemble de la communauté ONUS de cet incident. »
Une copie de la divulgation a été obtenue par EZpublish-france.fr, avec une traduction anglaise approximative en annexe :
Compartiments Amazon S3 mal configurés
Le hack lui-même est un peu plus qu’un simple problème Log4j. L’exploit Log4j a peut-être été le point d’entrée des attaquants, mais un contrôle d’accès inapproprié sur les compartiments Amazon S3 de l’ONUS a permis aux attaquants un accès indu.
« Le pirate a profité d’une vulnérabilité dans un ensemble de bibliothèques du système ONUS pour entrer dans le serveur sandbox (à des fins de programmation uniquement) », explique l’ONUS.
« Cependant, en raison d’un problème de configuration, ce serveur contient des informations qui ont permis à des malfaiteurs d’accéder à notre système de stockage de données (Amazon S3) et ont volé des données essentielles. Cela entraîne un risque de fuite des informations personnelles d’un grand nombre d’utilisateurs. «
Les informations client récupérées par les acteurs de la menace comprennent :
- Nom
- Courriel et numéro de téléphone
- Adresse
- Informations KYC
- Mot de passe crypté
- Historique des transactions
- Et quelques autres informations cryptées
La société de cybersécurité CyStack, qui a fourni des services à l’ONUS, a mené une enquête approfondie et ont publié leurs conclusions sur les mécanismes d’attaque et la porte dérobée plantée par les attaquants.
Près de 2 millions de fiches clients mises en vente
Le 25 décembre, après avoir échoué à obtenir le montant de l’extorsion de l’ONUS, les acteurs de la menace ont mis en vente les données des clients sur un marché de violation de données, comme l’a vu EZpublish-france.fr :
Les acteurs de la menace prétendent avoir des copies de 395 tables de base de données ONUS avec les informations personnelles des clients et les mots de passe hachés en leur possession.
Des échantillons de ces données ont été publiés par l’acteur de la menace dans le message du forum vu par EZpublish-france.fr.
Les échantillons comprenaient également des images des cartes d’identité, des passeports et des selfies vidéo soumis par les clients et obtenus au cours du processus KYC.
« Nous nous excusons sincèrement et espérons votre compréhension », États FARDEAU.
« C’est aussi l’occasion pour nous de nous revoir, de mettre à niveau et de perfectionner davantage le système pour assurer la sécurité de nos utilisateurs, en particulier lors de la transition de VNDC à ONUS. »
Les recommandations de CyStack à l’ONUS comprenaient la correction de la vulnérabilité Log4Shell dans Cyclos, comme indiqué par le fournisseur, la désactivation des informations d’identification AWS divulguées, la configuration correcte des autorisations d’accès AWS, le blocage de l’accès public à tous les compartiments S3 sensibles et l’imposition de restrictions supplémentaires.
À l’heure actuelle, les vulnérabilités de log4j ont été exploitées par toutes sortes d’acteurs de la menace, des pirates informatiques soutenus par l’État aux gangs de ransomware et quelques autres pour injecter des mineurs de crypto sur les systèmes vulnérables.
Le gang de ransomware Conti a également été vu en train de surveiller des serveurs VMWare vCenter vulnérables à des fins d’exploitation.
Les utilisateurs de Log4j doivent immédiatement passer à la dernière version 2.17.1 (pour Java 8) publiée hier. Les versions rétroportées 2.12.4 (Java 7) et 2.3.2 (Java 6) contenant le correctif devraient être publiées sous peu.