Alarm: Telnyx Python SDK verpflichtet PyPI von TeamPCP stiehlt Geheimnisse und Punkte zu Kubernetes

Heute wurde ein Angriff auf die Python-Versorgungskette festgestellt, dass das offizielle Telnyx-Paket im PyPI-Repository betroffen: bösartige Versionen wurden veröffentlicht und verteilt, als wären sie legitime Updates des SDK. Moderne Anwendungssicherheitsforscher gaben die Alarm-Stimme und gaben den Einbruch der Gruppe namens TeamPCP, basierend auf Exfiltrationsmustern und RSA-Schlüsseln, die bereits in früheren Kampagnen beobachtet wurden. Sie können die technischen Berichte lesen, die den Vorfall beschreiben Aikido, Sockel und Endor Labs.

Das betroffene Paket ist das offizielle Telnyx SDK für Python, die Bibliothek, die viele Entwickler nutzen, um Kommunikationsdienste - wie Stimme, SMS, WhatsApp und IoT-Konnektivität - in ihre Anwendungen zu integrieren. Es ist eine sehr gebrauchte Einheit: in PyPI mehr als Hunderttausende von monatlichen Downloads, so dass die potenziellen Auswirkungen hoch sind. Der Verdacht der Forscher ist, dass die Angreifer Zugang zu dem Konto mit Veröffentlichungsgenehmigungen in PyPI bekamen, und von dort kamen zwei kompromittierte Versionen.

Die erste veröffentlichte schädliche Version konnte ihre Nutzlast nicht aktivieren, aber die zweite, kurz darauf, rannte feindseligen Code zu dem Zeitpunkt, als das Paket in eine Anwendung importiert wurde. Der schädliche Code wurde innerhalb der Datei versteckt telnyx / _ kunden. Hefe für die Bibliothek scheint normal zu funktionieren, so dass der Vektor unbemerkt übergeben, während das SDK weiterhin mit seiner öffentlichen API.

Das Bedrohungsverhalten variiert je nach System: In Linux und macOS startet der Installer / Loader einen separaten Prozess, der eine zweite Stufe von einem Remoteserver herunterlädt. Diese zweite Stufe wird als WAV-Audio-Datei mit Namen wie ringtone.wav geliefert; aber innerhalb der Audio-Rahmen böswilligen Code wurde durch Steganographie Techniken eingebettet. Der Angreifer zieht diese Daten, defiguriert sie mit einer einfachen XOR-basierten Routine und führt sie direkt im Speicher. Ziel ist es, Geheimnisse zu sammeln: SSH-Tasten, Anmeldeinformationen in Konfigurationsdateien, Cloud-Token, Kryptomoneda-Münzen, Umgebungsvariablen und andere Geheimnisse, die im Host gefunden werden können.

In Hosts mit Kubernetes ist die Bedrohung nicht darauf beschränkt, lokale Geheimnisse zu stehlen: Malware versucht, Cluster-Geheimnisse aufzulisten und Pods mit hohen Privilegien auf verschiedenen Knoten zu erstellen, mit der Absicht, dem Host-System zu entkommen und den Umfang der Intrusion zu erweitern. Unter Windows ändert sich die Strategie leicht: Die Nutzlast lädt einen anderen WAV (z.B. Hangup.wav) herunter, der ein ausführbares msbuild.ex aufdeckt. Diese Binärdatei wird im Startordner des Benutzers installiert, um an jedem Login zu bestehen, und eine Sperrdatei verhindert wiederholte Ausführung in 12-Stunden-Fenstern.

Die von den Teams veröffentlichten technischen Analysen, die sowohl die Platzierung des Schadcodes als auch die verdeckte und exfiltrationstaktik untersuchten. Diese Beschreibungen sind nützlich für die Erkennung und Vermittlung; Sie können sie direkt in den Berichten von Endor Labs, Aikido und Sockel.

Wenn Ihre Umgebung die kompromittierten Versionen installiert hat, warnen Experten, dass davon ausgegangen werden sollte, dass diese Maschinen bereits kompromittiert sind: Der Code wird in der Importzeit ausgeführt und kann sofort ausgefilterte Geheimnisse haben. Die unmittelbare technische Empfehlung ist die Rückkehr in die bisherige Reinversion des Pakets, die in diesem Fall der in PyPI verfügbaren Release 4.87.0 entspricht ( Paketseite in PyPI), und entfernen Sie jede Spur der Versionen 4.87.1 und 4.87.2, wo sie installiert sind.

Während die engagierte Einheit entfernt wird, ist es angebracht, Eindämmungs- und Antwortmaßnahmen zu ergreifen: drehen potenziell exponierte Schlüssel und Token, regenerieren Anmeldeinformationen in Cloud-Services und Geldbeutel, Audit-Nutzer und Pods in Kubernetes Cluster und überprüfen Sie die Persistenzeinträge in Windows-Maschinen (z.B. Suche nach msbuild.exe im Startup). Es ist auch eine Priorität, Paket-Publishing-Systeme zu auditieren: Passwörter ändern, Multifaktor-Authentifizierung im beteiligten PyPI-Konto aktivieren und Publikationsprotokolle überprüfen, um unberechtigten Zugriff zu erkennen.

Über die Antwort auf einen bestimmten Vorfall hinaus unterstreicht dieser Fall erneut einen Punkt, an dem Entwicklungs- und Sicherheitsteams immer im Auge behalten sollten: externe Abhängigkeiten sind ein kritischer Angriffsweg. Gute Praktiken, die den Risikobereich reduzieren, sollten angewendet werden, wie z.B. die Festlegung (pin) spezifischer Versionen in Produktionsumgebungen, die Verwendung von privaten Repositorien oder kontrollierten Caches für Einheiten, die Validierung der Integrität, soweit möglich und die Sicherheitskontrollen auf Konten mit Veröffentlichungsgenehmigungen erforderlich. Organisationen und Initiativen wie OpenSSF und SLSA veröffentlichen Anleitungen und Arbeitsrahmen, um die Widerstandsfähigkeit der Software-Versorgungskette zu verbessern; OpenSSF und SLSA kann helfen, Maßnahmen zu priorisieren.

Für Manager und Entwickler, die konkrete Schritte benötigen: bestätigen Sie, ob eine ihrer Bilder, Container oder virtuelle Umgebungen Versionen 4.87.1 oder 4.87.2 enthalten; ersetzen Sie diese Einrichtungen durch 4.87.0; erwägen Sie den Umbau von Artefakten und Containern aus sauberen Quellen; runden Sie alle Anmeldeinformationen, die ausgesetzt wurden; und Bereitstellung von Erkennungen für außerraumverkehr anomale unbekannte Infrastruktur. Darüber hinaus überprüfen Sie die Veröffentlichungskonten in PyPI und aktivieren Sie 2FA auf allen kritischen Konten (siehe die Sicherheitsoptionen in PyPI für Entwickler in PyPI: Zweistufige Authentifizierung)

Dieser Vorfall ist nicht der erste und wird nicht der letzte auf dem Gebiet der Open Source-Paket-Intrusionen sein: Der von den Forschern erwähnte Schauspieler akkumuliert bereits mehrere Operationen gegen populäre Projekte, von Risikoanalyse-Diensten bis zu allgemein genutzten Buchhandlungen. Die Lektion für Produktausrüstung und Plattformen ist klar: Vertrauen in externe Komponenten muss durch technische und organisatorische Kontrollen begleitet werden, die schnell erkennen, begrenzen und reagieren, wenn dieses Vertrauen gebrochen ist.

Wenn Sie in die technischen Details gehen oder den Empfehlungen der Analysten folgen möchten, sehen Sie die Originalberichte der Teams, die die Kampagne untersuchten: Aikido, Sockel und Endor Labs und so schnell wie möglich handeln, wenn Ihre Organisation betroffen sein könnte.