Selon un avis d’OPSSHIELD, l’éditeur de l’outil de sécurité, un attaquant a utilisé des identifiants compromis pour accéder au système de mise à jour de cPGuard à 02:06 UTC le 2 novembre. Le canal compromis a diffusé un script malveillant avec les versions 5.88.12 à 5.88.19 de cPGuard, pouvant affecter les serveurs Linux sur lesquels ces versions ont été installées.

Le script a installé une porte dérobée et récupéré des fichiers, notamment les empreintes de mots de passe de /etc/shadow, les informations de compte de /etc/passwd, la configuration MariaDB ou MySQL de root, l’historique du shell ainsi que les fichiers d’autorisation SSH et de clés d’hôtes connues. Il a envoyé les données récupérées à un serveur de licences d’OPSSHIELD en utilisant un compte compromis. L’entreprise indique que l’attaquant a ensuite récupéré 32 fichiers sur ce serveur, chacun associé à un serveur client. Ce chiffre correspond aux fichiers dont le vol est avéré et ne permet pas d’établir le nombre total de serveurs potentiellement affectés.

OPSSHIELD a détecté l’attaque dans les 12 heures suivant la mise à disposition des versions concernées, sécurisé les identifiants d’accès à son infrastructure et empêché toute nouvelle diffusion du script. L’entreprise n’a pas indiqué combien de serveurs avaient installé une version affectée et enquête toujours sur la manière dont l’attaquant a obtenu les identifiants et sur les données récupérées sur chaque serveur. Elle affirme n’avoir détecté aucune autre activité malveillante à ce stade, tout en précisant que son enquête se poursuit.

Les administrateurs doivent mettre à jour chaque serveur cPGuard en exécutant `cpgcli update --start`, puis vérifier avec `cpgcli --version` qu’il utilise la version 5.88.25 ou une version ultérieure. OPSSHIELD indique que ces versions suppriment la porte dérobée et les fichiers laissés par le script. Toutefois, une mise à jour ne prouve pas qu’un serveur n’a jamais été compromis, et les identifiants copiés peuvent toujours être utilisés.

Pour consulter les journaux de mise à jour, les administrateurs peuvent effectuer une recherche avec `grep 'Successfully updated' /opt/cpguard/logs/install_log`. Une entrée correspondant à une version comprise entre 5.88.12 et 5.88.19 signifie que le serveur a installé une mise à jour affectée, mais ne prouve pas que le script a été exécuté ni que des données ont été récupérées. Un journal manquant, incomplet ou vierge n’exclut pas nécessairement une exposition ; OPSSHIELD conseille de contacter son assistance si le statut du serveur n’est pas certain.

Pour les serveurs sur lesquels le script s’est exécuté ou a pu s’exécuter, l’entreprise recommande de réinitialiser les mots de passe de root et des autres comptes locaux protégés par mot de passe à partir d’un environnement de récupération de confiance. Les mots de passe réutilisés sur d’autres systèmes doivent également être modifiés depuis un appareil de confiance. Les administrateurs doivent renouveler les mots de passe des bases de données, les clés d’accès S3, les jetons DigitalOcean et les secrets consignés dans l’historique du shell de root, ainsi que remplacer les clés privées SSH stockées dans /root/.ssh et supprimer les anciennes clés publiques correspondantes des systèmes qui leur font confiance.

OPSSHIELD ne recommande pas actuellement une réinitialisation complète systématique ni la réinstallation du système d’exploitation, mais précise que ces recommandations pourraient évoluer au fil de l’enquête. L’entreprise préconise une analyse au cas par cas des systèmes présentant d’autres signes de compromission ou dont le statut ne peut être confirmé. Elle prépare également une mise à jour de précaution distincte afin de supprimer de ses serveurs ses clés SSH d’accès à l’assistance lorsque les clients avaient auparavant activé cette fonctionnalité. Elle n’a pas précisé si la clé privée correspondante avait été exposée.

Sources: The Hacker News.