Attaque de la chaîne d’approvisionnement 3CX : leçons apprises

Les malfaiteurs ont d'abord compromis un progiciel, X_TRADER, d'une société nommée Technologies de négociation dont le siège est à Chicago, Illinois. Le logiciel contenait un malware ( SIGNAL VOILE porte dérobée) injectée. Le programme d'installation a été signé numériquement avec un certificat de signature de code valide. De mauvais acteurs ont peut-être fait irruption dans la construction pipeline d'ici 2021 et modifié le logiciel avant qu'il ne soit empaqueté et signé. Il s’agissait du premier saut dans l’attaque en chaîne de la chaîne d’approvisionnement. En mars 2022, c'était rapporté dans le cadre d'opérations DreamJob alias BLINDINGCAN et PommeJeus, ciblant les organisations basées aux États-Unis dans les secteurs des médias d’information, de l’informatique, de la crypto-monnaie et de la technologie financière.

Ce logiciel a été retiré du service en 2020 (!), mais il était disponible en téléchargement à partir de 2022. Un employé de 3CX l'a installé sur un ordinateur personnel. Les méchants ont volé les informations d'identification de l'employé sur l'ordinateur compromis. Chose intéressante, le SIGNAL VOILE utilisé une URL sur le site Web de Trading Technologies pour le commandement et le contrôle (une tactique souvent utilisée pour éviter la détection).

Deux jours plus tard, après la compromission initiale, les malfaiteurs ont utilisé le VPN d'entreprise pour accéder aux systèmes internes de 3CX. Ils ont utilisé le proxy inverse FRP, un outil public qui pouvait être utilisé pour le meilleur et pour le pire, pour se déplacer latéralement. Ils savaient quoi faire de leur présence : ils ont compromis les systèmes de build Windows et macOS. Chaque environnement avec des outils différents. Par exemple, ils ont utilisé l'outil SigFlip pour injecter le shellcode crypté RC4 dans l'annexe de signature du d3dcompiler_47.dll.

Les mises à jour logicielles de l’application 3CX Desktop pour Windows et macOS ont été infectées. Il s’agissait du deuxième saut dans cette (première ?) attaque en plusieurs étapes de la chaîne d’approvisionnement. La mise à jour du logiciel pour Windows, également correctement signée avec un certificat de signature de code 3CX, supprime deux fichiers malveillants, ffmpeg.dll et d3dcompiler_47.dll (avec équivalent .dylib bibliothèques pour macOS), qui ont été chargées et exécutées par le bénin 3CXDesktopApp exécutable (via la technique de chargement side-DLL). Le shellcode chiffré dans la deuxième DLL charge une autre DLL qui se télécharge depuis IcônesStockages Dépôt GitHub un fichier .ico contenant le serveur Command and Control (C2) chiffré.

Plus de 20 domaines étaient prévus à cet effet, ce qui nous montre comment l'attaque de la chaîne d'approvisionnement en logiciels a été soigneusement planifiée.

Les connexions des PC des victimes vers les domaines C2 ont commencé le 06 mars 2023 et se sont terminées le 29 mars.

Veuillez noter que (1) aucun code source dans un référentiel de code n'a été modifié mais qu'à la place, la charge utile du malware a été injectée pendant la construction, (2) un code légitime ffmpeg DDL a été remplacé par un logiciel malveillant et chargé via un chargement latéral de DLL, et (3) une application VoIP populaire a été transformée en une arme avec des logiciels malveillants à plusieurs niveaux.

Comment l'incident a été géré

Il semble que le 29 mars, 3CX ait reçu des rapports de tiers faisant état d'un acteur malveillant « exploitant une vulnérabilité de son produit ». Les plateformes anti-malware ont fait (partiellement) leur travail.

Le 30 mars 2023, le 3CX CISO, Pierre Jourdan, a publié un alerte de sécurité informer les clients et les partenaires que leur application Electron (client de bureau) a été expédiée après une mise à jour avec un logiciel malveillant. L'article répertorie les versions concernées (pour Windows et Mac), une brève déclaration sur les mesures de confinement initiales prises et une recommandation rapide pour continuer à travailler avec le client Web au lieu du client de bureau corrompu.

OMI, la communication initiale, bien qu'un peu laconique, était pertinente. Il n’est pas facile pour un fournisseur de reconnaître qu’il existe un grave problème de sécurité susceptible d’affecter de nombreux clients. L’entreprise a reconnu le problème et a immédiatement identifié un coupable potentiel :

"Il convient de le mentionner : il semble qu'il s'agisse d'une attaque ciblée d'une menace persistante avancée, peut-être même sponsorisée par un État, qui a lancé une attaque complexe sur la chaîne d'approvisionnement et choisi qui téléchargerait les prochaines étapes de son malware."

L'entreprise a proposé une alternative pour que le produit continue de fonctionner : utiliser le Web App progressive ou PWA, au lieu de l'application de bureau, basée sur le Électron cadre.

« Nous vous suggérons fortement d'utiliser plutôt notre application PWA. L'application PWA est entièrement basée sur le Web et fait 95 % de ce que fait l'application électronique. L’avantage est qu’il ne nécessite aucune installation ni mise à jour et que la sécurité Web de Chrome s’applique automatiquement.

La raison pour laquelle nous avons deux applications est que lorsque nous avons démarré l'application Electron, la technologie PWA n'était pas encore disponible. Maintenant, il est mature et fonctionne très bien.

Eh bien, l'application Web pourrait également être infectée et une PWA, par définition, peut exécuter du code dans les service Workers (code JavaScript) avec un accès (restreint) aux ressources locales. Le message affirmait que la PWA n’était pas infectée à ce moment-là. Nous pouvons comprendre pourquoi, dans bon nombre des 277+ commentaires sur la publication, certains ont demandé si l'alternative PWA mentionnée ou le logiciel du serveur PBX lui-même était compromis.

Le même jour, 3CX nommé Mandiant pour enquête, avec plus d'instructions. Fondamentalement, il installe la mise à jour pour

Application de bureau Win/Mac lors de l'installation sur site, désinstallez l'application électronique pour les versions concernées, puis accédez à l'alternative PWA. Cela ne suffit pas nécessairement, car le logiciel malveillant peut avoir accès aux systèmes affectés, persister ou même se déplacer latéralement. La suppression complète des logiciels malveillants n’est pas si simple. On peut comprendre que face à l’urgence, la meilleure façon de faire face à un incident ne soit pas toujours trouvée… à moins que le scénario ait été imaginé au préalable et que les mesures de remédiation adéquates aient été identifiées.

Le post suivant, désormais par le PDG de l'entreprise, tente de rassurer les clients avec l'annonce d'une mise à jour uniquement de sécurité pour DesktopApp. Certaines techniques de protection de base, comme le hachage de mot de passe, ont été mises en œuvre (« Mieux que jamais, il est tard ; ne jamais réussir serait une période trop longue. », Chaucer dixit en 1386.) Mieux vaut des protections spécifiques et mises en œuvre que de bonnes intentions et des projets projetés… Mais comment étaient stockés les mots de passe auparavant ?

Quoi qu’il en soit, Google a invalidé le certificat de signature de code 3CX existant et les fournisseurs d’antivirus ont également bloqué tout logiciel signé avec ce certificat. Les installateurs MSI pour la mise à jour DesktopApp devaient être régénérés avec un nouveau certificat de signature de code, ce qui a pris quelques heures. On pouvait s'y attendre !

3CX a déployé préventivement un nouveau serveur de build. C’est raisonnable : sans analyse, la manière dont le malware a été injecté était inconnue.

Le même 1er avril, le PDG a publié un Mise à jour des incidents de sécurité. Le message raconte ce que faisait l'entreprise (mener une enquête complète et valider l'intégralité du code source du logiciel côté client.) La sécurité ne peut pas attendre, même le samedi.

Une fois l'incident analysé et l'infrastructure de l'attaquant connue, le dépôt GitHub et les domaines des serveurs C2 utilisés par l'APT ont été supprimés, supprimant ainsi le malware.

Le 12 avril, le CISO a posté le premiers résultats de l’analyse des incidents. L’APT UNC4736 lié à la Corée du Nord a été cité pour la première fois.

Le vendredi 20 avril, Mandiant a posté le première analyse de l'incident. Les règles de détection YARA et Snort ont été publiées.

Le même jour, le PDG de 3CX a publié un nouveau message, au nom évocateur « Des actions, pas des mots – Notre plan d'action de sécurité en 7 étapes ! ». Le sous-titre est assez intéressant : «Assurer l’avenir de 3CX grâce à une mise en cascade inédite attaque de la chaîne d'approvisionnement logiciel dans le logiciel.» Les étapes de la charte de sécurité rédigée sont :

• Renforcement de plusieurs couches de sécurité réseau.

• La refonte renforce la sécurité.

• Examen continu de la sécurité des produits.

• Amélioration des fonctionnalités de sécurité du produit.

• Effectuer des tests d'intrusion continus.

• Affiner le plan de gestion de crise et de traitement des alertes.

• Création d'un nouveau département pour les opérations et la sécurité des réseaux.

Les analystes auront en effet l’œil sur ce programme louable…

Conséquences : comment l'industrie a réagi

Quelques semaines seulement se sont écoulées depuis la publication de l'incident. Mais l'industrie réagit.

CVE-2023-29059 a été attribué. À ce jour, il a un score de risque CVSSv7.8 de 3 (ÉLEVÉ). Les produits 3CX n'ont que 16 CVE répertoriés, ce qui semble bien par rapport aux fournisseurs avec des niveaux d'implémentation similaires. Mais cet incident n'est pas la vulnérabilité habituelle en effet. Il s'agit d'une attaque ciblée active par une menace persistante active (APT), comme le CISO's le plus reconnu.

Le CWE-506 Le « code malveillant intégré » qui caractérise cet incident ne nous aide pas beaucoup à comprendre comment prévenir de telles attaques de la chaîne d’approvisionnement de logiciels. Malheureusement, les malfaiteurs disposent de nombreux moyens pour diffuser des logiciels malveillants, les attaques de la chaîne d’approvisionnement étant le nouveau joyau de leur arsenal. La norme CWE-506 devrait être améliorée pour refléter les scénarios actuels, y compris ceux basés sur la violation du système de build.

L'APT, nommé UNC4736 par Mandiant, utilise des tactiques et des techniques similaires à celles du groupe Lazarus (APT38), largement connu, élaboré par l'État nord-coréen et les auteurs de la campagne de ransomware WannaCry de 2017. De tels liens entre de mauvais acteurs dans les États staliniens ayant des horaires de travail réguliers sont difficiles à établir, mais des chercheurs de CrowdStrike et ESET a constaté que les tactiques, techniques et procédures (TTP) utilisées ressemblent à celles couramment utilisées par Lazarus APT38. Comprendre leur fonctionnement est essentiel pour la détection, la prévention et l’éradication.

Connaître leurs objectifs, entourés de mystère, est encore plus difficile.

Cette attaque est suffisamment importante pour que CISA, l'Agence américaine de cybersécurité, a émis un consultatif avec les publications des fournisseurs et les liens vers plusieurs analyses sur les attaques de la chaîne d'approvisionnement. Leur lecture est pertinente pour les praticiens de la cybersécurité.

L’incident nous rappelle l’attaque de SolarWinds. Compte tenu de l’énorme impact, de nombreux fournisseurs se sont empressés d’analyser les installateurs de produits de bureau VoIP infectés. Mais c'est la dernière étape. Des détails supplémentaires sont nécessaires pour comprendre ce qui a échoué dans la sécurité des systèmes de build des deux organisations concernées, et quelles mesures les acteurs malveillants ont prises pour affecter ces systèmes de build et ont réussi à insérer le malware pendant la build. Sinon, cet incident se répétera encore et encore.

Et maintenant, les leçons apprises !

Pratiquer un sport d'équipe et écouter un membre de votre équipe expliquer chaque minute de jeu par la suite brise l'esprit le plus tempéré. Mais ici en Espagne, tout le monde est entraîneur national de football ! Alors laissez-moi jouer le rôle de Pep Guardiola, José Mourinho, Alex Ferguson et Arrigo Sacchi tous ensemble.

Agissez comme si votre système de construction était sous un feu nourri d'artillerie. Peut-être ne pouvez-vous pas empêcher un employé d’installer des logiciels non autorisés sur des ordinateurs de travail. Les équipes d’ingénierie peuvent probablement exiger des politiques plus strictes. Mais soyez vigilant sur le build & le déploiement pipeline. Si vous fournissez des logiciels à des clients, la sécurité de la manière dont vous créez le logiciel doit être aussi importante que la sécurité du produit logiciel.

Préparation aux incidentsIl est difficile, voire stérile, d'anticiper les scénarios les plus probables d'incidents de sécurité. Dois-je apprendre à utiliser un défibrillateur ? Non, sauf si j'ai une propension à utiliser une carte.iac Arrestation. Mais pour l'amour du ciel ! Préparez-vous à reconstruire votre système à partir de zéro, avec révocation et renouvellement des clés, jetons d'accès, paires de clés publiques et certificats.

Les systèmes de construction doivent avoir certaines caractéristiques: La tendance actuelle vers des builds dans des environnements éphémères, et avec des environnements isolés/sans paramètres/hermétiques et même reproductibles pourrait être le cadre pour empêcher des attaques comme celle sur 3CX Supply Chain Attack lorsqu'elles sont complétées par des exigences supplémentaires sur d'autres systèmes dans la construction et le déploiement pipeline. Voir Exigences de construction de Google SLSA pour référence.

Une bonne communication est la clé. La transparence est obligatoire. Minimiser le problème ou le cacher sous le tapis est la pire chose qu’une organisation puisse faire. Les incidents de sécurité affectent souvent plus durement la réputation que les autres actifs, et une mauvaise communication après une violation peut être catastrophique.

Transformez les problèmes en opportunités. Un bon incident peut déclencher des améliorations des contrôles de sécurité qui n’ont jamais été intégrées au plan produit strict. Même des choses essentielles comme un hachage approprié des mots de passe et une documentation de configuration/renforcement de la sécurité pourraient être programmées à court terme. Mais pour les attaques de la chaîne d'approvisionnement, il faut renforcer les systèmes de construction et ajouter des attestations et des contrôles d'intégrité à chaque étape de la construction et du déploiement. pipelines sont essentiels. Il ne devrait pas être si simple pour un attaquant d’implanter de tels changements dans le système de build.

Soyez préparé. Dans le cas contraire, votre organisation pourrait être confrontée à une menace existentielle, comme l'attaque de la chaîne d'approvisionnement de logiciels 3cx.