Codecov Takeaways – Was wir bisher wissen

Nicht, dass irgendjemand so schnell daran erinnert werden müsste, aber der kürzlich bekannt gewordene Verstoß gegen das Toolset von Codecov, das Continuous Integration (CI)-Prozesse in vielen Unternehmen unterstützt, unterstreicht erneut die enorme Dichte an Abhängigkeiten, die heute bestehen, und die daraus resultierende Anfälligkeit für Angriffe auf die Lieferkette.

Darüber hinaus führt das oft implizite Vertrauen in Software, die von vertrauenswürdigen Anbietern bereitgestellt wird, dazu, dass Kunden nicht angemessen testen, was ein Update tut, sowohl in Bezug auf das, was es lokal auf dem Host tut, als auch in Bezug auf die Netzwerkkonnektivität und die Datenübertragung. Das bedeutet lediglich, dass die Software, die in Unternehmen läuft, in den meisten Fällen nicht vollständig verstanden wird.

Inwiefern ist das relevant für das, was mit Codecov passiert ist?

Codecov bietet Berichtsfunktionen, die in die CI-Pipelines der Kunden integriert werden können – insbesondere berichten die Tools über die Menge an Code, die im Rahmen von Tests ausgeführt wird, und helfen dabei, Lücken im Validierungsprozess zu identifizieren. Diese Metriken werden dann für Berichte und Analysen auf die SaaS-Plattform hochgeladen.

Das Hochladen von Daten wird durch Skripte erleichtert, die zusammen als "Bash-Uploader" bekannt sind und als Teil des CI-Prozesses ausgeführt werden. Sollten diese Uploader-Skripte manipuliert werden, bieten sie einem Angreifer die Möglichkeit, den Upload nicht nur auf einen Server seiner Wahl umzuleiten, sondern auch anzugeben, welche Daten einbezogen werden sollen, um alles, was dem CI-Prozess zur Verfügung steht, potenziell zugänglich zu machen.

Im Fall von Codecov bestand die erste Kompromittierung darin, dass Google Cloud Storage-Anmeldeinformationen durchgesickert waren, die über einen Fehler im Docker-Image-Erstellungsprozess von Codecov zur Verfügung gestellt wurden. Diese Anmeldeinformationen ermöglichten es dem Angreifer, eine modifizierte Version des Bash-Uploader-Skripts zu posten, die er so veränderte, dass er den Inhalt aller Umgebungsvariablen, die für den CI-Prozess, in dem es ausgeführt wurde, verfügbar waren, sammeln und auf seinen eigenen Server hochladen konnte.

Angesichts der Tatsache, dass dieses modifizierte Skript direkt von der Codecov-Website verfügbar war, wurde es vermutlich von den Kunden als vertrauenswürdig eingestuft und mit wenig Validierung heruntergeladen und integriert. Umgebungsvariablen im CI-Prozess werden in der Regel verwendet, um relevante Geheimnisse in den Code einzufügen, um auf die Ressourcen zuzugreifen, die zur Laufzeit benötigt werden. Das bösartige Uploader-Skript hätte somit Zugriff auf diese und wäre in der Lage, sie an den Angreifer zu übertragen, wodurch er eine gesunde Sammlung von Anmeldeinformationen und anderen sensiblen Informationen erhält.

Auch ohne weiteren persistenten Netzwerkzugriff – und es gibt noch keine Hinweise darauf, ob der Verstoß dies begründet – sind diese Geheimnisse eine Schatztruhe, da sie Zugang zu einer Reihe von über das Internet zugänglichen Ressourcen bieten, wie z. B. Speicher-Buckets, Datenbanken und andere Cloud-Dienste , die von den zugehörigen Anwendungen genutzt werden. Auch diese sind jetzt wahrscheinlich kompromittiert.

Als absolutes Minimum sollte jedes Unternehmen, das glaubt, die kompromittierten Bash-Uploader-Skripte in seine CI-Pipeline integriert zu haben, dringend alle Geheimnisse zurücksetzen, auf die es Zugriff hat. Dies erfordert mit ziemlicher Sicherheit eine erneute Bereitstellung der betroffenen Anwendungen, um sicherzustellen, dass sie über die empfangenen aktualisierten Geheimnisse verfügen, aber der Mehraufwand dieser Methode wird der Verlängerung der Offenlegung gestohlener Anmeldeinformationen vorgezogen.

Abgesehen von der Exfiltration von Geheimnissen ist der persistente privilegierte Zugriff, der auf die CI-Pipeline gewährt wird, reif für Missbrauch. Per Definition besteht die Aufgabe der Pipeline darin, neue Software-Builds zu generieren und diese in Repositories zu veröffentlichen. Die Kompromittierung der Pipeline-Infrastruktur selbst gibt dem Angreifer die Möglichkeit, den Inhalt zu ändern und möglicherweise Hintertüren für die spätere Verwendung auf nachgelagerten Systemen oder innerhalb generierter Artefakte einzufügen. Wie viel Wiederaufbau muss also durchgeführt werden, um sicher zu sein, dass alle Spuren des Angreifers und seiner Tentakel beseitigt sind?

Als nächstes lohnt es sich, einen Blick auf den Netzwerkzugriff zu werfen, der für die CI-Infrastruktur verfügbar ist. In der Regel haben diese direkten Zugriff auf andere wichtige Komponenten, einschließlich, aber nicht beschränkt auf das Versionskontrollsystem, die Überwachungsinfrastruktur, automatisierte Tests, den Build-Prozess, das Konfigurationsmanagement und die kontinuierliche Bereitstellung. Aufgrund der starken Nutzung von FOSS-Komponenten benötigt die CI-Pipeline außerdem häufig einen Internetzugang zu öffentlichen Repositorys, um relevante Abhängigkeiten abzurufen.

Kann die Segmentierung bei den hohen Konnektivitätsanforderungen, die die CI-Pipeline erfordert, immer noch als wertvolle Sicherheitskontrolle dienen?

Bei der Betrachtung des Wertes von Mikrosegmentierungkann es auf zwei Arten dargestellt werden:

1. Die Mikrosegmentierung ermöglicht die Abgrenzung hochwertiger Assets, um sicherzustellen, dass ihre Gefährdung mit und vom Rest des Netzwerks begrenzt ist, wodurch es für einen Angreifer schwieriger wird, sie zu erreichen und auszunutzen.
2. Die Mikrosegmentierung ermöglicht es, dass jeder Workload über einen eigenen auf den geringsten Rechten basierenden Mikroperimeter verfügt, der ihn umgibt. Dadurch wird sichergestellt, dass im Falle einer Kompromittierung die Angriffsfläche , der sie ausgesetzt ist, auf das beschränkt ist, wozu sie berechtigt ist, eine Verbindung herzustellen – was letztendlich die Möglichkeiten eines Angreifers als Nächstes einschränkt.

Ein Ansatz, um dies für die CI-Pipeline relevant zu machen, sieht in etwa wie folgt aus:

• Die CI-Pipeline ist definitiv ein wertvolles Asset, das abgegrenzt werden sollte.
• Auch wenn es aus Sicht der Konnektivität eine Reihe von internen und externen Abhängigkeiten geben kann, sollten diese gut verstanden und gut definiert sein.
• Anhand dieser Informationen könnte eine auf Zulassungslistenbasierende Mikrosegmentierungsrichtlinie erstellt werden, um sicherzustellen, dass die CI-Pipeline nur Zugriff auf und von diesen gut verstandenen Abhängigkeiten hat.
• Wenn ein Internetzugang erforderlich ist, sollte dieser nur für eine Liste genehmigter Repositories und nicht für einen uneingeschränkten Internetzugang zugelassen werden. Dies schränkt den Zugriff auf eine explizit definierte Liste von Zielwebsites ein und ist eine effektive und oft einfache Kontrolle, um C&C- und Datenexfiltrationsversuche zu verhindern.

Dies schützt vor dem Zugriff auf die CI-Pipeline durch nicht autorisierte Geräte oder über nicht autorisierte Ports und Protokolle. Es stellt auch sicher, dass im Falle einer Kompromittierung der CI-Pipeline die Gefährdung durch den Rest des Netzwerks begrenzt wird. Darüber hinaus gehen verbesserte Segmentierungskontrollen oft mit einer deutlich besseren Transparenz der Systeminteraktionen einher und liefern reichhaltigere Daten, mit denen die Teams zur Erkennung und Reaktion auf Vorfälle bei der Untersuchung potenzieller Verstöße arbeiten können.

Bei Illumio helfen wir unseren Kunden, die Mikrosegmentierung zu nutzen, um diese Eindämmung und Überwachung zu etablieren. Wenden Sie sich an Ihr Account-Team, um herauszufinden, wie wir Sie unterstützen können.