Fin mars 2023, des chercheurs en sécurité ont dévoilé les informations d'un acteur menaçant. attaque complexe de la chaîne d'approvisionnement logicielle sur les logiciels de communication d'entreprise de 3CX, principalement l'application de bureau d'appels vocaux et vidéo de l'entreprise. Les chercheurs ont averti que l’application était en quelque sorte un cheval de Troie et que son utilisation pourrait exposer l’organisation à un éventuel plan d’exfiltration par un acteur malveillant. L'attaque a été surnommée « Smooth Operator » et certaines preuves suggèrent qu'elle dure depuis des mois.
Alors, que s'est-il passé exactement, en quoi l'utilisation de cette version trojanisée vous met-elle en danger et comment cela aurait-il pu être évité en utilisant la signature et la vérification de logiciels ?
Tout d’abord : qu’est-ce que 3CX ?
3CX est un PBX IP (Private Branch Exchange) basé sur un logiciel et aux normes ouvertes, remplaçant un PBX matériel traditionnel. Il est conçu pour permettre aux entreprises de passer et de recevoir des appels en utilisant la technologie VoIP (Voice over Internet Protocol), qui transmet les communications vocales sur Internet. 3CX inclut également des fonctionnalités avancées telles que la vidéoconférence, la présence, la messagerie instantanée, etc., et peut être déployé sur site ou dans le cloud. Windows, macOS et Linux ne sont que quelques-uns des systèmes d'exploitation populaires sur lesquels l'application est disponible. De plus, le client est accessible via les navigateurs grâce à une extension Chrome et le client dispose même d'une version PWA, en plus d'être disponible en tant qu'application mobile pour les appareils Android et iOS.
Vous pouvez avoir une idée des effets potentiels d’une attaque sur la chaîne d’approvisionnement logicielle sur le site Web de 3CX, qui compte 600,000 12 entreprises utilisant son application et plus de XNUMX millions d’utilisateurs quotidiens.
Un aperçu de l’attaque : ce que vous devez savoir
C'est un peu complexe, nous allons donc le décomposer en étapes :
- Vous téléchargez un version trojanisée de l'application de bureau ou si vous l'avez déjà installée et mettez-la simplement à jour avec une version trojanisée.
- L'exécutable 3CXDesktopApp.exe charge une bibliothèque de liens dynamiques (DLL) malveillante appelée ffmpeg.dll.
- Le ffmpeg.dll est utilisé pour extraire une charge utile chiffrée de d3dcompiler_47.dll et l'exécuter.
- Le malware télécharge ensuite des fichiers d'icônes d'apparence innocente hébergés sur GitHub qui contiennent des chaînes codées en Base64 ajoutées à la fin des images.
- Ces données codées sont ensuite décodées et utilisées pour télécharger une autre étape, contenant le serveur C&C crypté auquel la porte dérobée se connecte afin de récupérer l'éventuelle charge utile finale.
- Dans la phase finale, la fonctionnalité de vol d'informations est mise en pratique, notamment la collecte de données système et de données de navigateur à partir des navigateurs Chrome, Edge, Brave et Firefox. Cela peut inclure l'interrogation de l'historique de navigation et des informations de la table Lieux, ainsi que l'interrogation potentielle de la table Historique.
Dans un premier temps, 3CX a minimisé l'attaque mais a admis plus tard qu'il s'agissait d'une menace réelle et a suggéré de désinstaller et de réinstaller l'application avec ses instructions spécifiques ainsi que d'utiliser la version PWA en attendant jusqu'à ce que l'entreprise parvienne à démêler l'incident et à l'atténuer.
Un autre facteur très important à garder à l’esprit est que le compromis inclut un certificat de signature de code utilisé pour signer les fichiers binaires du cheval de Troie. Eh bien, pas exactement – il utilise en fait une vulnérabilité connue appelée CVE-2013-3900 (initialement publié en 2013 mais mis à jour en 2022 et encore cette semaine) pour en faire apparaître légitimement signé.
Déjà Vu : cela s’est déjà produit
Si cette histoire d'un La version trojanisée de 3CX semble familière parce que cela s'est déjà produit.
Dans ce cas, c'est toiIl est impossible de savoir si une bibliothèque open source en amont utilisée par l'entreprise a été infectée ou si une véritable attaque a violé l'environnement de développement de l'entreprise.
Dans d'autres attaques célèbres, de « Kingslayer » (2016) à « CCleaner » (2017), « VestaCP » (2018), « WIZVERA VeraPort » (2020) et jusqu'à « SolarWinds » (2020), c'est un pratique courante des acteurs menaçants pour tenter de compromettre les serveurs d'une entreprise, son environnement de construction ou son exécutable téléchargeable réel. Après tout, déguiser quelque chose de mauvais et de dangereux en quelque chose auquel vous pouvez faire confiance est un excellent moyen d'amener les gens à faire confiance et à télécharger votre charge utile.
Cela fait partie de la définition d'un attaque de la chaîne d'approvisionnement logicielle – les attaquants ont compromis la chaîne d'approvisionnement en logiciels pour distribuer des logiciels malveillants à un grand nombre de victimes. Dans chacun de ces cas célèbres, les attaquants ont réussi à injecter du code malveillant dans des progiciels légitimes, qui ont ensuite été distribués aux utilisateurs. Les attaquants y parvenaient souvent en compromettant un fournisseur de logiciels de confiance, tel qu'un serveur de mise à jour logicielle ou un certificat de signature de code.
En incitant des clients peu méfiants à télécharger une version modifiée d'une application légitime, les attaquants peuvent pratiquement tout cacher à l'intérieur.
Et voici le principal problème – « sans méfiance ». Après tout, l'exécutable, le binaire ou l'image provient de l'entreprise créatrice, apparemment approuvé par celle-ci, et contient même un certificat signé. Que peut faire de plus un client ? Doivent-ils appeler l’entreprise pour vérifier chaque mise à jour ? Scanner le code (si disponible) pour détecter l'existence de portes dérobées ? C’est absurde et irréaliste. Mais là is quelque chose qui peut être fait.
Comment ajouter une couche de confiance au-delà d’un certificat ?
Le modèle proposé est assez simple et repose sur la même idée que celle des certificats de signature de code. Un certificat de signature de code est un certificat numérique émis par un tiers et utilisé pour signer numériquement un logiciel ou un code. Lorsque le logiciel est signé avec un certificat de signature de code, cela permet aux utilisateurs de vérifier l'authenticité et l'intégrité du logiciel avant de l'installer ou de l'exécuter.
Les certificats de signature sont émis par un tiers de confiance autorités de certification (AC), qui vérifient l'identité de l'éditeur du logiciel et l'intégrité du code du logiciel. L'autorité de certification utilise des algorithmes cryptographiques pour créer une signature numérique du logiciel, qui est ensuite incluse dans le code signé. Lorsqu'un utilisateur tente d'installer ou d'exécuter le logiciel, son système vérifie la signature numérique pour s'assurer qu'elle correspond à la signature générée par l'autorité de certification. Si les signatures correspondent, le logiciel est considéré comme authentique et n'a pas été altéré depuis sa signature.
Ce système est basé sur la cryptographie à clé publique, également connue sous le nom de cryptographie asymétrique, une méthode de cryptographie qui utilise deux clés différentes, une clé publique et une clé privée, pour chiffrer et déchiffrer les données. Dans le contexte de la signature de code, une paire de clés privée-publique est utilisée pour signer le logiciel et le code.
Dans ce processus, l'éditeur de logiciel génère une paire de clés privée-publique, où la clé privée est gardée secrète et la clé publique est mise à la disposition des autres. L'éditeur du logiciel utilise ensuite sa clé privée pour créer une signature numérique du logiciel ou du code qu'il souhaite signer. Cette signature numérique est une valeur de hachage générée en exécutant le logiciel ou le code via un algorithme mathématique, puis en chiffrant la valeur de hachage résultante avec la clé privée de l'éditeur.
Lorsqu'un utilisateur télécharge le logiciel ou le code signé, son système utilise la clé publique de l'éditeur du logiciel pour déchiffrer la signature numérique et vérifier qu'elle correspond à la valeur de hachage du logiciel ou du code téléchargé. Si la signature numérique est valide, l'utilisateur peut alors être sûr que le logiciel ou le code n'a pas été falsifié depuis sa signature par l'éditeur du logiciel.
Sur la base de ce concept simple, la correction proposée consiste à signer chaque nouvelle version, binaire et image directement avec la clé de l'entreprise ou la clé du pipeline de construction et à demander simplement à l'utilisateur de vérifier la signature lorsqu'il télécharge ou met à jour le logiciel.
Bien sûr, les choses ne sont pas toujours aussi simples. Si les mauvais acteurs ont infiltré le serveur de build, alors signer le build là-bas est déjà inutile. Si l’infrastructure clé a été compromise, l’ensemble de l’exercice est également inutile.
Mais demander aux utilisateurs de vérifier une signature, quelque chose de rapide et facile qui peut être fait automatiquement, est un petit prix à payer pour aider à prévenir la prochaine attaque de la chaîne d'approvisionnement logicielle.
Mais attendez, vous vous demandez peut-être : et si c'était en fait une bibliothèque open source en amont qui était à l'origine de la contamination ? Dans un tel cas, signer une version est, encore une fois, inutile puisque le code compromettant est « intégré ».
C’est là qu’il faut commencer à envisager un écosystème de confiance basé sur la signature et la vérification de ces signatures. Si ces packages open source étaient signés et que les signatures étaient vérifiées lors de leur intégration dans le code de l'entreprise, cela pourrait réduire le risque de violation.
Où Scribe entre en jeu
Scribe a mis en place un outil appelé Valent qui vous permet de signer et vérifier fichiers, dossiers et images. Sans avoir besoin de maintenir des systèmes PKI complexes, l'outil met en œuvre une nouvelle approche consistant à utiliser votre identité vérifiée déjà établie (comme votre identité Google, Microsoft, GitHub ou AWS par exemple) pour signer l'artefact souhaité. Vous pourrez ensuite utiliser le même outil pour vérifier que l'artefact a été signé et quelle était l'identité utilisée pour le signer.
Supposons que votre pipeline de build produise une image de conteneur comme artefact final. Juste après la création de cette image, vous devez la signer et télécharger cette version signée dans le référentiel où vos clients peuvent la télécharger. Une fois signée, cette image ne peut plus être modifiée – elle est verrouillée. Quiconque le souhaite peut vérifier à la fois qu'il est signé et que l'identité du signataire correspond à ce que l'entreprise a publié.
Cet outil n'est qu'une partie des capacités accordées par la mise en œuvre du Solution SaaS Scribe pour votre organisation. Dans le but d'améliorer à la fois la sécurité de votre chaîne d'approvisionnement logicielle et votre transparence globale, il y a toutes les raisons d'aller découvrir ce que Scribe peut vous proposer.
Ce contenu vous est proposé par Scribe Security, l'un des principaux fournisseurs de solutions de sécurité de bout en bout pour la chaîne d'approvisionnement logicielle, offrant une sécurité de pointe aux artefacts de code ainsi qu'aux processus de développement et de livraison de code tout au long des chaînes d'approvisionnement logicielles. En savoir plus.
articles similaires
