Alerte : Telnyx Python SDK s'engage à PyPI par TeamPC vole des secrets et des points à Kubernetes

Aujourd'hui, une attaque sur la chaîne d'approvisionnement Python a été détectée qui a affecté le paquet officiel Telnyx dans le dépôt PyPI : des versions malveillantes ont été publiées et distribuées comme si elles étaient des mises à jour légitimes du SDK. Les chercheurs modernes de la sécurité des applications ont donné la voix d'alarme et attribué l'intrusion au groupe appelé TeamPCP, basé sur les modèles d'exfiltration et les clés RSA déjà observées dans les campagnes précédentes. Vous pouvez lire les rapports techniques qui décrivent l'incident dans Aïkido, Socket et Endor Labs.

Le paquet touché est le SDK officiel Telnyx pour Python, la bibliothèque que de nombreux développeurs utilisent pour intégrer des services de communication - tels que la voix, SMS, WhatsApp et la connectivité IoT - dans leurs applications. C'est une unité très utilisée: en PyPI plus de centaines de milliers de téléchargements mensuels, donc l'impact potentiel est élevé. Les chercheurs soupçonnent que les attaquants ont accès au compte avec des permis de publication en PyPI, et de là deux versions compromises sont apparues.

La première version malveillante publiée n'a pas activé sa charge utile, mais la seconde, peu après, a lancé un code hostile au moment où le paquet a été importé dans une application. Le code malveillant était caché dans le fichier telnyx / _ client. py pour que la bibliothèque semble fonctionner normalement, permettant au vecteur de passer inaperçu pendant que le SDK continue à se conformer à son API publique.

Le comportement de la menace varie selon le système : dans Linux et macOS, l'installateur/chargeur démarre un processus séparé qui télécharge une deuxième étape depuis un serveur distant. Cette deuxième étape est livrée sous forme de fichier audio WAV, avec des noms comme ringtone.wav; cependant, dans les cadres audio, le code malveillant a été intégré au moyen de techniques de stéganographie. L'attaquant dessine ces données, les défigure avec une simple routine basée sur XOR et les exécute directement en mémoire. L'objectif est de recueillir des secrets: clés SSH, identifiants dans les fichiers de configuration, jetons de nuage, pièces de cryptomoneda, variables d'environnement et autres secrets qui peuvent être trouvés dans l'hôte.

Dans les hôtes avec Kubernetes, la menace ne se limite pas à voler des secrets locaux : les logiciels malveillants tentent de lister des secrets de cluster et de créer des pods avec des privilèges élevés sur différents nœuds, avec l'intention de s'échapper au système hôte et d'élargir la portée de l'intrusion. Sous Windows la stratégie change légèrement: la charge utile télécharge un autre WAV (par exemple hangup.wav) qui découvre un exécutable appelé msbuild.ex. Ce binaire est installé dans le dossier de démarrage de l'utilisateur pour obtenir la persistance à chaque connexion, et un fichier de verrouillage empêche l'exécution répétée dans les fenêtres de 12 heures.

Les analyses techniques publiées par les équipes qui ont examiné les détails de l'incident à la fois le placement du code malveillant et les tactiques de dissimulation et d'exfiltration. Ces descriptions sont utiles pour la détection et la médiation; vous pouvez les consulter directement dans les rapports de Endor Labs, Aïkido et Socket.

Si votre environnement a installé les versions compromises, les experts avertissent qu'il faut supposer que ces machines sont déjà compromises: le code est exécuté dans le temps d'importation et peut avoir des secrets exfiltrés immédiatement. La recommandation technique immédiate est de retourner à la précédente version propre du paquet, qui dans ce cas correspond à la version 4.87.0 disponible dans PyPI ( page de paquetage dans PyPI) et supprimer toute trace des versions 4.87.1 et 4.87.2 où elles sont installées.

Bien que l'unité engagée soit supprimée, il convient de prendre des mesures de confinement et de réponse : faire pivoter les clés et les jetons potentiellement exposés, régénérer les références dans les services et la bourse en nuage, vérifier les utilisateurs et les pods dans les grappes Kubernetes et examiner les entrées de persistance dans les machines Windows (par exemple, rechercher msbuild.exe dans le Startup). Il s'agit également d'une priorité pour les systèmes de publication de paquets de vérification : modifier les mots de passe, permettre l'authentification multifactorielle dans le compte PyPI concerné et examiner les journaux de publication pour détecter les accès non autorisés.

Au-delà de la réponse à un incident particulier, cette affaire souligne à nouveau un point que les équipes de développement et de sécurité doivent toujours garder à l'esprit : les dépendances externes sont une voie d'attaque critique. De bonnes pratiques qui réduisent la zone de risque devraient être appliquées, comme la mise en place de versions spécifiques dans les environnements de production, l'utilisation de dépôts privés ou de caches contrôlés pour les unités, la validation de l'intégrité dans la mesure du possible et l'exigence de contrôles de sécurité sur les comptes avec permis de publication. Les organisations et initiatives comme OpenSSF et SLSA publient des guides et des cadres de travail pour améliorer la résilience de la chaîne d'approvisionnement des logiciels; OuvrirSSF et SLSA peut aider à hiérarchiser les mesures.

Pour les gestionnaires et les développeurs qui ont besoin d'étapes concrètes : confirmer si l'une de leurs images, contenants ou environnements virtuels comprenait les versions 4.87.1 ou 4.87.2; remplacer ces installations par 4.87.0; envisager de reconstruire des artefacts et des contenants à partir de sources propres; arrondir tout titre de compétence qui aurait pu être exposé; et déployer des détections pour les anomalies de circulation hors de la salle à des infrastructures inconnues. En outre, examiner les comptes de publication dans PyPI et activer 2FA sur tous les comptes critiques (voir les options de sécurité dans PyPI pour les développeurs dans PyPI: authentification en deux étapes).

Cet incident n'est pas le premier et ne sera pas le dernier dans le domaine des intrusions de paquets open source: l'acteur souligné par les chercheurs accumule déjà plusieurs opérations contre des projets populaires, des utilitaires d'analyse des risques aux librairies à usage général. La leçon pour l'équipement de produit et les plates-formes est claire: la confiance dans les composants externes doit s'accompagner de contrôles techniques et organisationnels qui détectent, limitent et réagissent rapidement lorsque cette confiance est rompue.

Si vous voulez entrer dans les détails techniques ou suivre les recommandations des analystes, consultez les rapports originaux des équipes qui ont étudié la campagne : Aïkido, Socket et Endor Labs et agir dès que possible si votre organisation pourrait être touchée.