cPGuard : mise à jour piégée, 5.88.12 à 5.88.19

Ce qui se passe

Le 2 novembre à 02:06 UTC, un attaquant non identifié est entré, avec des identifiants compromis, dans le système de mise à jour de cPGuard, l'outil de sécurité pour serveurs Linux édité par OPSSHIELD. Il y a déposé un script qui est parti chez les clients dans les versions 5.88.12 à 5.88.19. L'éditeur dit avoir détecté l'attaque moins de 12 heures après la sortie de ces versions, avoir purgé les identifiants de son infrastructure et bloqué la diffusion du script. L'enquête sur l'origine du vol d'identifiants continue, et le nombre de serveurs qui ont installé une version piégée n'est pas connu : les serveurs interrogent le canal à intervalles, certains n'ont peut-être pas exécuté le script.

Ce que le script a pris

Il installe une porte dérobée, puis rassemble :

• /etc/shadow et /etc/passwd ;
• la configuration MariaDB ou MySQL de root (my.cnf) ;
• l'historique de commandes de root ;
• les fichiers SSH de root (clés autorisées et hôtes connus).

Tout part vers le serveur de licences d'OPSSHIELD, via un compte compromis, pour que l'attaquant le récupère plus tard. Il y a déjà puisé au moins 32 fichiers, chacun lié à un serveur client (estimation de la nuit du 2 novembre, susceptible d'évoluer). Les hachages de /etc/shadow se cassent hors ligne quand le mot de passe est faible, courant ou déjà fuité ; les secrets d'une configuration de base ou d'un historique de commandes n'ont, eux, aucune protection.

Comment vérifier

grep 'Successfully updated' /opt/cpguard/logs/install_log

Une ligne pour une version de 5.88.12 à 5.88.19 prouve que la version piégée a été installée, pas que le script a tourné ni que des données sont sorties. À l'inverse, un journal vide ou incomplet ne prouve pas l'innocence. Même un serveur déjà en 5.88.25 ou plus récent doit être considéré comme potentiellement compromis.

Traces laissées par le script (la mise à jour retire la porte dérobée et le dossier de collecte, leur absence ne prouve donc rien) :

• cpguard-v58812-i91511.sh : le script ;
• /var/tmp/.cpg91511_sh : la porte dérobée ;
• /var/tmp/.cpg91511 : le dossier de collecte ;
• /var/tmp/.cpg91511/loot.tgz : l'archive préparée.

Comment s'y prendre

1. Sur chaque serveur, cpgcli update --start, puis cpgcli --version : il faut 5.88.25 ou plus.
2. Pour tout serveur où le script a tourné ou a pu tourner, depuis un environnement de récupération de confiance : réinitialiser les mots de passe de root et de tous les comptes locaux à mot de passe, puis ceux qui servent aussi ailleurs.
3. Renouveler les mots de passe de base de données, les clés d'accès S3, les jetons DigitalOcean et tout secret lu dans l'historique de root.
4. Remplacer les clés privées SSH de /root/.ssh et retirer les anciennes clés publiques de chaque machine qui leur faisait confiance.

OPSSHIELD ne recommande pas de réinstallation systématique, avec la réserve que son avis peut changer ; en cas d'autres signes de compromission, il propose un examen au cas par cas. Une autre mise à jour retire, par précaution, ses clés d'accès support (une clé SSH d'OPSSHIELD ajoutée au fichier des clés autorisées de root quand un client active le support). L'éditeur n'a pas dit si la clé privée correspondante avait été exposée.

Source : The Hacker News, qui reprend l'avis d'OPSSHIELD. Source en anglais.