#Netzwerk & Sicherheit · 4 Min. Lesezeit · Tim Rinkel

HEIMLICH UMGELEITET! Dein Terraform-Modul stahl die Zugangsdaten — so prüfst du das JETZT

HEIMLICH UMGELEITET! Dein Terraform-Modul stahl die Zugangsdaten — so prüfst du das JETZT

Es ist der Albtraum jeder Lieferkette: Du lädst genau das Modul, das du immer lädst, von genau der Quelle, der du immer vertraust — und es ist nicht mehr dasselbe Modul. Genau das ist bei Coder passiert, dem Anbieter selbst gehosteter Entwicklungsumgebungen.

DER ANGRIFFSWEG

Angreifer haben laut den vorliegenden Berichten die Cloudflare-Infrastruktur von Coder kompromittiert. Dort trugen sie zusätzliche, nicht autorisierte Registry-Server ein. Ein Teil des Verkehrs, der eigentlich zur echten Registry gehen sollte, landete damit bei den Angreifern.

Und die lieferten aus, was jeder erwartet hatte: Terraform-Module. Nur eben präparierte. Im Code steckte eine Routine, die Zugangsdaten und Geheimnisse aus der Umgebung einsammelte — API-Schlüssel, Tokens, Anmeldedaten — und sie an die Domain coder-infra[.]com weiterschickte.

Der Domainname ist der eigentlich fiese Teil. Wer in einem Log „coder-infra“ liest, denkt an Infrastruktur von Coder. Genau darauf war er ausgelegt.

WARUM AUSGERECHNET TERRAFORM SO GEFÄHRLICH IST

Terraform-Code baut Infrastruktur. Damit er das kann, braucht er weitreichende Rechte: Cloud-Zugangsdaten, API-Schlüssel, Datenbank-Passwörter. All das liegt zur Laufzeit in Umgebungsvariablen und Zustandsdateien griffbereit.

Ein bösartiges npm-Paket in einer Web-App ist ärgerlich. Ein bösartiges Terraform-Modul in einer Deployment-Pipeline sitzt an der Stelle, an der die Schlüssel zum gesamten Rechenzentrum durchlaufen.

Erschwerend kommt hinzu: Diese Läufe passieren automatisiert. Niemand schaut zu. Ein Modul, das nebenbei Variablen einsammelt, fällt in einem CI-Log praktisch nicht auf.

SO PRÜFST DU, OB ES DICH GETROFFEN HAT

Der Reihe nach:

  • Netzwerk-Logs durchsuchen. Suchbegriff ist die Domain coder-infra[.]com. Prüfe Firewall-Logs, DNS-Auflösungen und Proxy-Protokolle deiner Build-Systeme.
  • CI-Historie ansehen. Welche Läufe haben in den letzten Wochen Module aus der Coder-Registry gezogen? Diese Läufe sind die Kandidaten.
  • Geheimnisse erneuern. Wenn es auch nur einen Treffer gibt: Cloud-Zugangsdaten, API-Tokens, Deploy-Keys und Datenbank-Passwörter, die in diesen Läufen erreichbar waren, gehören ausgetauscht. Nicht „irgendwann“, sondern jetzt.
  • Nach der Wirkung suchen. Gestohlene Zugangsdaten werden benutzt. Sieh in den Cloud-Audit-Logs nach Anmeldungen aus unbekannten Regionen und nach neu angelegten Nutzern oder Schlüsseln.

WAS DU DAUERHAFT BESSER MACHEN KANNST

Zwei Dinge helfen gegen genau diese Angriffsklasse. Erstens: Module und Versionen festnageln. Wer eine feste Version samt Prüfsumme verlangt, merkt es, wenn etwas anderes ankommt. Zweitens: Ausgehenden Verkehr aus Build-Systemen einschränken. Eine CI-Umgebung muss nicht das gesamte Internet erreichen können. Wenn nur bekannte Ziele erlaubt sind, kann ein Datendieb seine Beute nicht abliefern — selbst wenn er im Code sitzt.

Und ganz allgemein: Kurzlebige Zugangsdaten statt dauerhafter Schlüssel. Ein Token, das nach einer Stunde verfällt, ist für einen Angreifer deutlich weniger wert als einer, der seit zwei Jahren in der Pipeline liegt.

Häufige Fragen

Bin ich betroffen, wenn ich Coder gar nicht nutze?
Nein. Der Angriff betraf die Registry-Infrastruktur von Coder. Wer nie Module von dort bezogen hat, ist von diesem Vorfall nicht direkt betroffen. Die Angriffstechnik — Umleitung des Verkehrs einer vertrauenswürdigen Registry — ist allerdings übertragbar und ein guter Anlass, die eigenen Bezugsquellen durchzugehen.
Wie merke ich, dass ein präpariertes Modul gelaufen ist?
Der verlässlichste Hinweis ist Netzwerkverkehr zur Domain coder-infra[.]com. Durchsuche Firewall-, DNS- und Proxy-Logs deiner Build-Systeme nach diesem Namen. Ein Blick in den Modul-Code allein reicht oft nicht, weil der Schadanteil in gewöhnlich aussehenden Hilfsfunktionen versteckt sein kann.
Welche Geheimnisse muss ich erneuern?
Alles, was während eines betroffenen Laufs in der Umgebung erreichbar war: Cloud-Zugangsschlüssel, API-Tokens, Deploy-Keys, Datenbank-Zugangsdaten und Registry-Anmeldungen. Im Zweifel großzügig tauschen — der Aufwand ist deutlich kleiner als der Schaden bei einem übersehenen Schlüssel.
Wie verhindere ich so etwas künftig?
Modulversionen fest verankern und wenn möglich über Prüfsummen absichern, damit ein ausgetauschter Inhalt auffällt. Zusätzlich den ausgehenden Netzwerkverkehr der Build-Umgebung auf bekannte Ziele beschränken und mit kurzlebigen statt dauerhaften Zugangsdaten arbeiten.

Quellen

Kommentar hinterlassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert