Coder bestätigte, dass ein nicht identifizierter Angreifer die Infrastruktur für seine Modul-Registry kompromittiert und veränderte Terraform-Module bereitgestellt hatte, die darauf ausgelegt waren, Cloud-Zugangsdaten, SSH-Schlüssel, CI/CD-Geheimnisse und andere sensible Daten zu stehlen.
Die schadhaften Module wurden am 31. August etwa 14 Stunden lang bereitgestellt, von 07:35 bis 21:45 Uhr UTC. Coder zufolge gibt es keine Hinweise darauf, dass von Coder verwaltete Kundendaten betroffen waren. Allerdings lässt sich nicht zweifelsfrei feststellen, welche Bereitstellungen kompromittiert wurden.
Angreifer kaperten den vertrauenswürdigen Registry-Zugriffsweg von Coder
Laut Coder verschaffte sich ein nicht identifizierter Angreifer Zugriff auf die Cloudflare-Infrastruktur des Unternehmens und fügte dem Pool, der registry.coder.com.
Cloudflare leitete daraufhin einige legitime Registry-Anfragen an von den Angreifern kontrollierte Server weiter. Auf diesen Servern lagen veränderte Versionen von Coder-Terraform-Modulen mit Code zum Diebstahl von Zugangsdaten.
Der Angriff nutzte keine Schwachstelle in Terraform selbst aus. Stattdessen wurde ein vertrauenswürdiger Softwarebereitstellungsweg kompromittiert, sodass schadhafte Artefakte über den legitimen Registry-Hostnamen von Coder ausgeliefert werden konnten.
Wie der Angreifer ursprünglich Zugriff auf die Cloudflare-Umgebung von Coder erlangte, wurde nicht bekannt gegeben.
Nach der Bereitstellung durchsuchten die schadhaften Module Provisioner-Umgebungen nach API-Schlüsseln für Cloud- und KI-Tools, CI/CD-Zugangsdaten, Geheimnissen in Konfigurationsdateien, der Terminal-Historie, OIDC-Tokens, SSH-Schlüsseln, einmalig verwendbaren Authentifizierungstokens und anderen sensiblen Daten.
Wenn ein Provisioner innerhalb von coderd lief, konnte die Schadsoftware auch auf Coder-Datenbankpasswörter und andere Konfigurationsgeheimnisse zugreifen.
Die gestohlenen Informationen wurden an die ähnlich aussehende Domain coder-infra[.]com.
Terraform-Module konnten Code zum Diebstahl von Zugangsdaten ausführen
Coder fordert Kunden auf, die Provisioner-Logs nach data.external.telemetry zu durchsuchen. Dabei handelt es sich um eine von den schadhaften Modulen verwendete externe Terraform-Datenquelle.
Die externe Datenquelle von Terraform kann ein externes Programm ausführen und übergibt diesem untergeordneten Prozess die für Terraform sichtbaren Umgebungsvariablen. Die Dokumentation von HashiCorp beschreibt diese Funktion als „Hintertür“ für Fälle, in denen ein gewöhnlicher Provider nicht geeignet ist.
Das verschaffte dem schadhaften Modul eine wertvolle Position: Während der Infrastruktur-Bereitstellung ausgeführter Code konnte auf dieselben Cloud-Zugangsdaten, Tokens und Konfigurationsdaten zugreifen, die dem Bereitstellungsprozess zur Verfügung standen.
Der Vorfall offenbart außerdem eine Lücke zwischen den Schutzmechanismen von Terraform für Provider und Module.
In Terraform wird in der .terraform.lock.hcl-Datei die Auswahl der Provider und deren kryptografische Hashes festgehalten, doch HashiCorp zufolge werden Remote-Module derzeit nicht in der Lock-Datei erfasst.
Eine exakte Einschränkung der Modulversion kann sicherstellen, dass Terraform dieselbe Versionsnummer auswählt. Sie überprüft jedoch nicht unabhängig, ob eine kompromittierte Registry die ursprünglichen Inhalte bereitstellt, die dieser Version zugeordnet sind.
Dieser Unterschied ist hier besonders relevant, da der Bereitstellungsweg der Registry selbst kompromittiert wurde.
Der Vorfall reiht sich in weitere jüngste Angriffe auf die Software-Lieferkette mit dem Ziel von Entwicklerinfrastrukturen ein, bei denen vertrauenswürdige Pakete oder Entwicklungstools zu Wegen in Zugangsdaten und Cloud-Umgebungen wurden.
Coder empfiehlt die Suche nach Spuren und eine Rotation der Zugangsdaten
Coder empfiehlt, Firewall-, Proxy-, DNS- und VPC-Flow-Logs auf Verbindungen zu coder-infra[.]com zu prüfen, bevor potenziell nützliche Beweise gelöscht werden.
Unternehmen sollten außerdem die Provisioner-Logs nach data.external.telemetry durchsuchen, die während des Expositionszeitraums am 31. August heruntergeladenen Module ermitteln und die von Coder veröffentlichte SQL-Abfrage verwenden, um potenziell betroffene zwischengespeicherte Module und Template-Versionen zu identifizieren.
Potenziell betroffene Unternehmen sollten alle Zugangsdaten rotieren, auf die Provisioner während des Vorfalls zugreifen konnten, darunter:
- API-Schlüssel für Cloud- und KI-Tools
- CI/CD-Zugangsdaten
- OIDC- und einmalig verwendbare Authentifizierungstokens
- SSH-Schlüssel
- Datenbankpasswörter, sofern zutreffend
Die Rotation der Zugangsdaten ist besonders wichtig, da offengelegte Cloud-Zugriffsschlüssel weiterhin verwendet werden können – selbst nachdem die ursprüngliche Kompromittierung eingedämmt wurde.
Coder empfiehlt außerdem, betroffene zwischengespeicherte Pakete zu löschen und auf eine der korrigierten Versionen zu aktualisieren:
- 2.37.0
- 2.36.4
- 2.35.7
- 2.34.9
Laut Coder wurden Refresh-Tokens nicht an Provisioner weitergegeben.
Das Ausmaß der Kompromittierung bleibt unklar
Coder zufolge lässt sich nicht zweifelsfrei feststellen, welche Bereitstellungen betroffen waren, da wichtige Logs auf von den Angreifern kontrollierter Infrastruktur gespeichert sind.
Das Unternehmen hat nicht bekannt gegeben, wie der Angreifer ursprünglich Zugriff auf seine Cloudflare-Umgebung erlangte, und die Aktivitäten keinem bekannten Bedrohungsakteur zugeordnet.
Der Vorfall verstärkt die wachsende Besorgnis über Entwicklertools als Teil der Angriffsfläche der Software-Lieferkette. Registries, CI/CD-Systeme, Programmiertools und Automatisierung für die Infrastruktur können allesamt Zugangsdaten enthalten, die weit über den Entwicklerarbeitsplatz selbst hinausgehenden Zugriff ermöglichen.
Unternehmen, die Coder während des Expositionszeitraums am 31. August nutzten, sollten daher das Einspielen von Patches, die Untersuchung und die Rotation der Zugangsdaten als separate Maßnahmen zur Behebung behandeln. Eine Aktualisierung von Coder entfernt den kompromittierten Bereitstellungsweg, kann jedoch keine Geheimnisse ungültig machen, die möglicherweise bereits gestohlen wurden.
Außerdem lesenswert: Ein kompromittiertes GitHub-Konto trug dazu bei, den Shai-Hulud-Angriff auf die npm-Software-Lieferkette zu verbreiten, wodurch sich Schadsoftware zum Diebstahl von Zugangsdaten über Hunderte von Paketen verteilte.