Les attaquants ont transformé le canal de mise à jour fiable d’OpsShield en une attaque de chaîne d’approvisionnement

Les failles de la chaîne d’approvisionnement logicielle sont une fois de plus révélées, les attaquants ciblant désormais le processus de mise à jour d’OpsShield.

Cette semaine, les acteurs malveillants ont utilisé des informations d’identification compromises pour diffuser des mises à jour malveillantes aux clients de cPGuard. Ils ont ensuite accédé aux données stockées sur les serveurs du fournisseur et dans ses comptes de portail de facturation, et ont fait des copies d’au moins trois des serveurs cloud d’OpsShield.

La société a déclaré dans un avis qu’elle avait « exclu l’attaquant de tous les systèmes que nous savons qu’il avait atteint, et… qu’elle reconstruisait ceux en qui nous ne pouvons pas entièrement faire confiance ». Il a également publié des mises à jour et invite les clients à mettre à jour vers la dernière version de cPGuard, à modifier les mots de passe et à générer de nouvelles clés SSH.

En fin de compte, l’ampleur de cet accès non autorisé souligne la fragilité persistante de la chaîne d’approvisionnement en logiciels, ainsi que la vulnérabilité des outils de sécurité eux-mêmes.

« Le véritable danger ici est que les attaquants soient capables de transformer un mécanisme de mise à jour de sécurité fiable en un vecteur pour s’introduire dans les serveurs », a déclaré Erik Avakian, conseiller technique chez Infotech. « Le logiciel censé protéger ces serveurs est devenu la source qui les a compromis. »

L’anatomie de l’attaque

OpsShield est spécialisé dans les logiciels de protection des serveurs et de sécurité Web. Son produit cPGuard est une suite de sécurité, un scanner de logiciels malveillants et un pare-feu conçus pour les serveurs d’hébergement Web Linux.

La société a révélé qu’entre le 1er et le 2 novembre, des attaquants ont pu obtenir un accès non autorisé à l’infrastructure de distribution des mises à jour d’OpsShield et, pendant environ 70 minutes, ont diffusé une mise à jour malveillante.

Les auteurs de la menace ont commencé par sonder le portail de facturation d’OpsShield, en enregistrant un compte client sous une fausse identité et en commandant un essai gratuit de cPGuard. Ils ont ensuite envoyé des requêtes spécialement conçues qui leur ont permis d’exécuter des commandes sur le serveur pour collecter des données. Ils ont utilisé des clés d’accès volées pour publier de fausses mises à jour exécutées en tant que root (le niveau de privilège d’administrateur le plus élevé), ainsi que pour copier des fichiers sensibles et faire des copies de trois serveurs cloud OpsShield.

Environ 2 950 serveurs clients ont exécuté la fausse mise à jour, exposant les hachages de mots de passe, les clés racine SSH, les mots de passe racine MySQL et l’historique du shell, a rapporté OpsShield. Les attaquants ont également accédé à environ 7 900 comptes de portail de facturation contenant des noms, adresses, e-mails et mots de passe hachés de clients.

OpsShield indique qu’il est toujours en train d’examiner la demande exacte qui a fourni l’accès, et qu’il a corrigé deux points d’entrée possibles et vérifié les composants du fournisseur associés « ligne par ligne ». Il a fermé le compte de l’attaquant, révoqué la clé de stockage de mise à jour volée ainsi que « chaque jeton API cloud et clé d’accès sur notre compte ».

L’entreprise a également supprimé le shell sécurisé (SSH) de l’attaquant ; supprimé les clones de ses serveurs créés par l’attaquant ainsi que tous les instantanés ; activé une protection de connexion plus renforcée et remplacé chaque clé et mot de passe SSH ; réinitialiser toutes les sessions de connexion au portail de facturation et faire pivoter toutes les clés ; et a commencé à reconstruire ses serveurs de facturation, de licences et de gestion interne avec des paramètres PHP et de pare-feu plus stricts.

La société a également publié des mises à jour propres : v5.88.26, qui supprime le shell racine caché ; plus un suivi qui supprime la tâche planifiée laissée par l’attaquant. En outre, il a commencé à réémettre toutes les clés privées et publiques de la licence cPGuard, de sorte que les copies auxquelles l’attaquant avait accès ont cessé de fonctionner.

L’entreprise a conseillé aux administrateurs de :

• Mettez à jour cPGuard vers la dernière version, puis confirmez-le et c’est parti ; supprimez-les sinon ;
• Modifiez les mots de passe root et chaque mot de passe d’utilisateur local sur le serveur ;
• Générez de nouvelles clés SSH racine et supprimez les anciennes de chaque serveur qui leur a fait confiance ; jusqu’à ce que les clés soient modifiées, considérez les serveurs comme compromis ;
• Modifiez les mots de passe racine MySQL et tous les mots de passe de base de données et faites pivoter tout mot de passe, clé API ou jeton existant dans les historiques du shell racine ;
• Réinitialisez les mots de passe du portail de facturation OpsShield et activez l’authentification à deux facteurs.
• Enfin, il est indiqué : « si nous vous informons que l’attaquant s’est connecté manuellement à votre serveur, reconstruisez-le à partir d’une sauvegarde propre effectuée avant le 1er novembre ».

OpsShield est transparent, mais les impacts sont toujours réels

« Franchement, peu de fournisseurs rédigent une déclaration de violation aussi franche », a déclaré Frank Dickson de Dickson Research. « OpsShield mérite beaucoup de mérite pour cela. »

Cependant, a-t-il souligné, le pire type de violation est celui provoqué par un outil de sécurité. Les canaux de mise à jour sont volontairement déverrouillés et les outils de sécurité s’exécutent en tant que root car ils doivent tout voir, « donc la fausse mise à jour s’est également exécutée en tant que root ».

Pour un fournisseur d’hébergement, un serveur peut contenir des centaines de sites Web et de bases de données clients. Un mot de passe root MySQL les ouvre tous et une clé SSH racine donne accès à tous les autres serveurs qui lui font confiance. L’historique du shell contient également souvent des mots de passe et des jetons saisis.

Le client en aval peut être le plus durement touché alors qu’il en sait le moins, a souligné Dickson, car la plupart des propriétaires de sites Web n’ont aucune idée de l’agent de sécurité utilisé par leur fournisseur d’hébergement. Chaque serveur qui se met à jour fait confiance au pipeline du fournisseur.

OpsShield se décrit comme une petite équipe vendant à des hôtes plus petits à bas prix, ce qui est la vérité inconfortable de la chaîne d’approvisionnement, a déclaré Dickson. « Votre exposition est définie par le plus petit fournisseur détenant la racine sur vos serveurs, et non par le plus grand. »

Avakian convient que cela rappelle que la chaîne d’approvisionnement en logiciels d’une entreprise est aussi sécurisée que les systèmes, les identités et les processus qui la sous-tendent. « Vous pouvez faire tout ce que vous pouvez pour sécuriser votre propre infrastructure tout en étant compromis par l’intermédiaire d’un fournisseur tiers en qui vous avez confiance. »

Ce qui est particulièrement préoccupant ici, c’est que les attaquants n’ont pas eu à s’en prendre à des milliers de clients un par un ; il leur suffisait de compromettre un mécanisme de distribution unique pour retourner l’infrastructure de confiance du fournisseur contre ses clients, a-t-il noté.

Les tiers augmentent les risques, un fait que les organisations sous-estiment encore, a-t-il déclaré. « Les entreprises doivent accorder beaucoup plus d’attention à la gestion des risques liés aux tiers et à la chaîne d’approvisionnement. »

Le Zero Trust, un incontournable

Avakian a également souligné que l’impact sur les clients en aval pourrait aller bien au-delà de la compromission initiale, dans la mesure où les informations d’identification volées peuvent être utilisées pour mener d’autres attaques. Les entreprises doivent adopter une approche de confiance zéro qui inclut leurs fournisseurs de logiciels et les mises à jour sur lesquelles ils comptent.

« Ce n’est pas parce qu’une mise à jour provient d’une source fiable que vous pouvez supposer qu’elle est sûre », a-t-il déclaré. Les entreprises doivent examiner de plus près les risques liés aux fournisseurs, protéger les informations d’identification privilégiées et examiner l’intégrité des logiciels. Surveillez également en permanence tout comportement inattendu après une mise à jour et soyez prêt à isoler rapidement les systèmes en cas de problème.

« Il faut prévoir la possibilité que même un fournisseur de confiance puisse être compromis », a-t-il souligné. « Et vous devez pratiquer ces types de scénarios dans le cadre d’un programme régulier d’exercices sur table. »

Dickson a conseillé de commencer par un inventaire et de connaître chaque agent fournisseur fonctionnant avec les privilèges root ou administrateur, car chacun est un canal de mise à jour. Les clients doivent demander aux fournisseurs où se trouvent les clés de publication de mise à jour et ce qui les sépare des systèmes destinés aux clients, surveiller le trafic sortant des serveurs, garder les secrets hors de l’historique du shell et traiter les clés SSH comme des informations d’identification avec une date d’expiration. Les clients en aval doivent demander directement à leur hébergeur s’il exécute cPGuard, puis modifier leurs propres mots de passe.

« Le logiciel le plus dangereux sur votre serveur est peut-être celui auquel vous faites confiance pour se mettre à jour », a-t-il déclaré. « Choisissez ces fournisseurs comme s’ils détenaient Root, car c’est le cas. »