Linux caché Persistance: Velvet Ant modifie PAM et OpenSSH pour capturer les identifiants

Un acteur lié à la Chine connu sous le nom de Velvet Ant a conduit la persistance à un nouveau niveau: au lieu de se cacher dans de nouveaux logiciels ou des outils propres, il a modifié les programmes eux-mêmes qui décident qui entre dans les systèmes Linux. Selon l'analyse publique et la trajectoire du groupe, l'adversaire est venu remplacer les composants critiques du système d'authentification - PAM et Ouvrir- avec des versions malveillantes qui ont enregistré des identifiants et des commandes, ou qui ont accepté des mots de passe cachés; travail furtif qui peut passer par l'administration légitime pendant des années.

La technique est doublement dangereuse: d'abord parce qu'elle attaque le point le plus fiable de l'hôte - celui qui valide les identités - et ensuite parce que le but était, dans de nombreux cas, des réseaux isolés sans accès direct à Internet. Pour y arriver, les attaquants ont utilisé des systèmes exposés comme des ponts et des outils déguisés qui ont retransmis des ordres sur le segment "gagé par l'air". Cette approche patiente et modulaire est similaire aux campagnes précédentes du même acteur, qui ont utilisé des dispositifs d'infrastructure tels que F5 BIG-IP o Les commutateurs NX-OS de Cisco en tant que plates-formes de commande et de contrôle internes.

Les implications opérationnelles sont claires : les procédures standard de confinement, comme les séances de clôture ou le changement de mot de passe, peuvent être inefficaces si la pièce qui valide ces références s'avère compromise. Réinitialiser les clés sans vérifier et nettoyer la chaîne d'authentification laisse une porte ouverte pour que de nouvelles lettres d'identité soient capturées et exfiltrées.

D'un point de vue défensif, la première leçon est de déplacer la surveillance vers des endroits où elle n'est traditionnellement pas considérée. Surveillance de l'intégrité des fichiers pour les binaires de connexion (p. ex. / usr / sbin / sshd et les modules PAM dans / lib / security ou / lib64 / security en fonction de la distribution) doit être sur la liste des priorités. En plus des alertes en temps réel, il convient de mettre en œuvre la chasse active : comparer les hachages exécutables avec des copies connues et signées par le fournisseur, et vérifier l'intégrité du paquet à l'aide des outils propres au gestionnaire de paquet (rpm-V, debsums ou autres alternatives selon le disque).

Les mesures correctives doivent être prudentes. Ne pas remplacer ou redémarrer aveugle un binaire d'authentification de production; une copie incorrecte peut bloquer les administrateurs et compliquer la récupération. Le flux raisonnable est d'isoler l'équipement, de commencer à partir d'un support de sauvetage (CD en direct / USB) pour obtenir un environnement de confiance, de vérifier et de remplacer les binaires par des artefacts signés ou construits dans un environnement CI sécurisé, et seulement ensuite faire pivoter les identifiants et les clés. La mise à l'essai de tout remplacement dans des laboratoires reproductibles avant d'appliquer en production réduit le risque d'erreurs mortelles.

L'hygiène complémentaire qui réduit la fenêtre d'abus comprend la réduction des services et des comptes avec des privilèges administratifs, forçant l'authentification multifacteurs pour un accès critique et préférant l'authentification par clé et les agents protégés du matériel lorsque possible. Il est également nécessaire d'auditer et de bloquer les canaux de transmission inhabituels : examiner les serveurs Web exposés qui peuvent servir de passerelle et surveiller les connexions sortantes inattendues des applications réseau et l'équilibre.

Dans le cas particulier des vulnérabilités précédemment utilisées par cet acteur, l'équipement doit s'assurer que les correctifs et les mesures d'atténuation recommandées par les fabricants et les autorités de sécurité sont appliqués. Les organisations peuvent consulter des avis officiels et des guides pour confirmer l'exposition de leur infrastructure; des ressources publiques telles que CISA ou rapports d'entreprises ayant répondu à des incidents tels que Sygnia offrir un contexte technique utile et des mesures d'atténuation. Pour mieux comprendre les composants attaqués et comment les protéger, il est également nécessaire de revoir les sources originales du logiciel comme Ouvrir et Linux-PAM.

Enfin, la leçon stratégique est que la confiance par défaut dans les infrastructures doit être remplacée par vérification continue. Les composants qui étaient traditionnellement considérés stables et "toujours corrects" - les nageurs, les commutateurs, et surtout la connexion elle-même - sont maintenant des objectifs de persistance. Une défense efficace exige l'intégration des contrôles de l'intégrité dans la surveillance quotidienne, les politiques de rétablissement qui prévoient l'instauration d'un climat de confiance et les exercices de recherche de menaces qui vérifient les changements d'appareil critiques avant de supposer qu'un rétablissement des pouvoirs ferme l'incident.