OVHcloud-CLI-Releases gekapert: Geheimnisse durch Kompromittierung eines GitHub-Kontos gestohlen

Am Montag, den 19. Oktober, kompromittierten Angreifer das GitHub-Konto eines Mitwirkenden und ersetzten die Download-Archive für fünf bestehende Releases der OVHcloud-Befehlszeilenschnittstelle (CLI). Die schädlichen Binärdateien, die darauf ausgelegt waren, Geheimnisse von lokalen Festplatten zu stehlen, waren 94 Minuten lang auf GitHub verfügbar, bevor der Cloud-Anbieter sie entfernte und ein sauberes, unveränderliches Release veröffentlichte.

Was passiert ist

Der Vorfall betraf die Versionen v0.11.0 bis v0.15.0 der OVHcloud CLI, die zwischen dem 14. April und dem 16. September veröffentlicht wurden. Zwischen 12:47 und 14:21 UTC löschte ein Angreifer mit Zugriff auf ein Mitwirkenden-Konto die ursprünglichen Archivdateien und lud neue Dateien hoch, die Malware enthielten. Der Angreifer ersetzte auch die Datei checksums.txt, um sicherzustellen, dass die veröffentlichten Hashes mit den schädlichen Binärdateien übereinstimmten. Damit wurden grundlegende Integritätsprüfungen umgangen, die sich ausschließlich auf diese bereitgestellten Prüfsummen verlassen.

Octave Klaba, Gründer von OVHcloud, bestätigte, dass der Quellcode, die Release-Tags und die internen Build-Pipelines unberührt blieben. Die schädlichen Dateien waren einfache Go-Builds eines späteren Commits, die direkt auf den GitHub-Release-Seiten hochgeladen wurden. Das Unternehmen reagierte, indem es die ausgetauschten Archive löschte und Version v0.16.0 als unveränderliches Release veröffentlichte – eine GitHub-Funktion, die weitere Änderungen an Release-Assets verhindert. Das kompromittierte Mitwirkenden-Konto hatte Arbeiten im Dokumentations-Repository zusammengeführt, war aber kein öffentliches Mitglied der Organisation.

Wie es funktioniert

Der Angriff nutzte die Möglichkeit von Benutzern mit Schreibzugriff, bestehende GitHub-Releases zu ändern, wenn die Unveränderlichkeit nicht aktiviert ist. Diese Einstellung, die seit Oktober 2025 allgemein verfügbar ist, sperrt Release-Dateien und Tags, schützt jedoch nur Releases, die nach der Aktivierung erstellt wurden. OVHcloud hatte diese Option für die betroffenen Releases nicht aktiviert, sodass der Angreifer die Binärdateien austauschen konnte, ohne dass CI/CD-Pipeline-Prüfungen oder Workflow-Läufe ausgelöst wurden.

Die Malware selbst war ein Secret-Stealer, der auf Credentials abzielt, die auf der Festplatte gespeichert sind, wie etwa solche in ~/.ovh.conf oder Umgebungsvariablen. Forscher von OpenSourceMalware verknüpften das kompromittierte Konto mit GlassWorm, einer Kampagne, die dafür bekannt ist, Code in unsichtbaren Unicode-Zeichen zu verstecken. Obwohl keine Kopie der Oktober-Binärdatei öffentlich analysiert wurde, zeigten vier persönliche Repositories, die mit dem Konto verbunden waren, Force-Pushes im März, die Loader enthielten, die mit GlassWorm-Taktiken konsistent waren.

Wichtige Details

• Kompromittierte Versionen: v0.11.0, v0.12.0, v0.13.0, v0.14.0 und v0.15.0 gelten als kompromittiert; v0.10.0 ist sauber.
• Betroffene Plattformen: macOS (x86_64, arm64), Linux (x86_64, arm64) und Windows (x86_64). Linux i386, Windows i386, Windows arm64 und WebAssembly-Builds waren nicht betroffen.
• Expositionszeitraum: 12:47 bis 14:21 UTC am 19. Oktober 2026.
• Erkennungsmethode: Schädliche Binärdateien zeigen eine Pseudo-Version wie v0.15.1-0.20261013083505-5ead8ef9b43d+dirty und enthalten -ldflags="-s -w", während echte Releases Tag-Nummern anzeigen und keine ldflags-Zeile enthalten.
• Sichere Installationspfade: Homebrew-Nutzer waren geschützt, da Casks die ursprünglichen SHA-256-Hashes festlegten (Pinning), was dazu führte, dass Downloads mit falschen Hashes fehlschlugen. Docker-Images und go install-Methoden waren ebenfalls nicht betroffen.
• Schädlicher Hash: Der SHA-256-Hash für das ausgetauschte v0.15.0 Linux arm64-Archiv lautet 3833daffcaaaab27e4e0e0833240ffcb1df8df648f4ec0bc4a75c176e28933cb.

Warum es wichtig ist

Dieser Vorfall unterstreicht die Fragilität der Lieferketten-Sicherheit, wenn die Unveränderlichkeit von Releases nicht durchgesetzt wird. Viele Entwickler verlassen sich auf Installationsskripte oder direkte Downloads von GitHub-Releases, ohne kryptografische Signaturen zu überprüfen oder Hashes festzulegen. Das offizielle OVHcloud-Installationsskript lädt beispielsweise das neueste Archiv herunter, ohne einen Hash zu prüfen, wodurch jeder Benutzer, der es während des 94-minütigen Zeitfensters ausführte, verwundbar war. Ebenso hätten CI-Jobs, die Archive ohne festgelegte Hashes abrufen, stillschweigend die schädliche Version installiert.

Für Engineering-Teams dient dies als kritische Erinnerung daran, dass Vertrauen in die Mitwirkenden eines Repositorys durch technische Schutzmaßnahmen ausgeglichen werden muss. Selbst wenn eine Build-Pipeline sicher ist, kann die direkte Manipulation von Release-Assets diese vollständig umgehen. Die Tatsache, dass Homebrew-Nutzer geschützt waren, zeigt den Wert von Paketmanagern, die Hash-Pinning durchsetzen, während Nutzer manueller Installationen oder eigener Skripte einem höheren Risiko ausgesetzt waren. Das Rotieren von Secrets ist nun für jeden obligatorisch, der möglicherweise die kompromittierte Binärdatei ausgeführt hat, da die Malware wahrscheinlich alle lesbaren Secrets vom Host-Maschine exfiltriert hat.

Was Sie tun können

• Rotieren Sie jedes Secret, das auf Maschinen gespeichert ist, auf denen die kompromittierte CLI möglicherweise ausgeführt wurde. Verwenden Sie dazu einen anderen, sauberen Rechner für die Rotation.
• Entfernen Sie die aktuelle OVHcloud-CLI-Binärdatei und installieren Sie Version v0.16.0, die als unveränderliches Release mit Attestation veröffentlicht wurde.
• Überprüfen Sie heruntergeladene Archive mit dem GitHub-CLI-Befehl gh release verify-asset v0.16.0 FILE, um die Integrität sicherzustellen.
• Aktivieren Sie die Unveränderlichkeit von Releases in Ihren eigenen GitHub-Repositories, um unbefugte Änderungen an bestehenden Release-Assets zu verhindern.
• Legen Sie SHA-256-Hashes in CI/CD-Pipelines und Installationsskripten fest, anstatt sich auf dynamische Latest-Tags oder ungeprüfte Downloads zu verlassen.
• Prüfen Sie die Zugriffsrechte der Mitwirkenden und erzwingen Sie Multi-Faktor-Authentifizierung, um das Risiko einer Kontokompromittierung zu reduzieren.