Codecov Takeaways — Was wir bisher wissen

Nicht, dass irgendjemand so schnell daran erinnert werden müsste, aber der kürzlich angekündigte Verstoß gegen das Toolset von Codecov, das Continuous Integration (CI) -Prozesse in vielen Unternehmen unterstützt, unterstreicht erneut die enorme Dichte an Interdependenzen, die heute bestehen, und die daraus resultierende Gefahr von Angriffen 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 bewirkt, sowohl in Bezug auf die lokalen Funktionen auf dem Host als auch in Bezug auf Netzwerkkonnektivität und Datenübertragung. All dies bedeutet, 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 ihre Tools über die Menge an Code, der im Rahmen von Tests ausgeführt wird, und helfen so, Lücken im Validierungsprozess zu identifizieren. Diese Metriken werden dann zur Berichterstattung und Analyse auf ihre SaaS-Plattform hochgeladen.

Der Datenupload wird durch Skripte erleichtert, die zusammen als „Bash Uploaders“ bekannt sind und als Teil des CI-Prozesses ausgeführt werden. Diese Uploader-Skripte bieten, falls sie manipuliert werden, einem Angreifer die Möglichkeit, den Upload nicht nur auf einen Server seiner Wahl umzuleiten, sondern auch anzugeben, welche Daten aufgenommen werden sollen, sodass alles, was dem CI-Prozess zur Verfügung steht, potenziell zugänglich ist.

Im Fall von Codecov bestand der ursprüngliche Kompromiss darin, dass Google Cloud Storage-Anmeldeinformationen durchsickerten, die aufgrund eines Fehlers bei der Erstellung von Docker-Images 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 änderte, dass er den Inhalt aller Umgebungsvariablen, die für den CI-Prozess, in dem es ausgeführt wurde, verfügbar waren, abrufen und auf seinen eigenen Server hochladen konnte.

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

Selbst ohne weiteren dauerhaften Netzwerkzugriff — und es gibt noch keinen Hinweis darauf, ob die Sicherheitsverletzung dies bestätigt — sind diese Geheimnisse eine Schatztruhe, da sie den Zugriff auf eine Reihe von über das Internet zugänglichen Ressourcen wie Speicher-Buckets, Datenbanken und andere ermöglichen Cloud-Dienste dass die zugehörigen Anwendungen verwendet wurden. Auch diese sind jetzt wahrscheinlich kompromittiert.

Zumindest sollte jede Organisation, die glaubt, die kompromittierten Bash-Uploader-Skripte in ihre CI-Pipeline aufgenommen zu haben, dringend alle Geheimnisse, auf die sie Zugriff hat, zurücksetzen. Dies erfordert mit ziemlicher Sicherheit eine erneute Bereitstellung der betroffenen Anwendungen, um sicherzustellen, dass sie die aktualisierten Geheimnisse erhalten haben, aber der Aufwand dieser Methode wird der Verlängerung der Offenlegung gestohlener Zugangsdaten vorgezogen.

Abgesehen von der Exfiltration von Geheimnissen ist der persistente privilegierte Zugriff, der der CI-Pipeline gewährt wird, anfällig für Missbrauch. Definitionsgemäß besteht die Verantwortung der Pipeline darin, neue Software-Builds zu generieren und diese in Repositorys zu veröffentlichen. Die Kompromittierung der Pipeline-Infrastruktur selbst bietet dem Angreifer die Möglichkeit, den Inhalt zu ändern und möglicherweise Hintertüren einzufügen, die später entweder auf nachgelagerten Systemen oder innerhalb generierter Artefakte verwendet werden können. Wie viel Wiederaufbau muss also durchgeführt werden, um sicher zu sein, dass alle Spuren des Angreifers und seiner Tentakel entfernt sind?

Als Nächstes lohnt es sich, sich den Netzwerkzugriff anzusehen, 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, das automatisierte Testen, den Build-Prozess, das Konfigurationsmanagement und die kontinuierliche Bereitstellung. Außerdem benötigt die CI-Pipeline aufgrund der starken Nutzung von FOSS-Komponenten häufig einen Internetzugang zu öffentlichen Repositorys, um relevante Abhängigkeiten abzurufen.

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

Bei der Betrachtung des Werts von Mikrosegmentierung, es kann auf zwei Arten präsentiert werden:

1. Durch die Mikrosegmentierung können hochwertige Ressourcen eingezäunt werden, um sicherzustellen, dass ihre Exposition gegenüber und vom Rest des Netzwerks begrenzt ist, was es für Angreifer schwieriger macht, sie zu erreichen und auszunutzen.
2. Die Mikrosegmentierung ermöglicht es, dass jeder Workload von einem eigenen Mikroperimeter umgeben ist, der auf Regeln für den Zugriff mit den geringsten Rechten basiert. Dadurch wird sichergestellt, dass, falls es kompromittiert wird, Angriffsfläche Der Zugriff darauf ist nur auf das beschränkt, zu dem es autorisiert ist, eine Verbindung herzustellen — was letztendlich begrenzt, was ein Angreifer als Nächstes tun könnte.

Ein Ansatz, um dies für die CI-Pipeline relevant zu machen, sieht ungefähr so aus:

• Die CI-Pipeline ist definitiv ein wertvolles Gut und eines, das abgesichert werden sollte.
• Aus Sicht der Konnektivität kann es zwar eine Reihe interner und externer Abhängigkeiten geben, diese sollten jedoch gut verstanden und klar definiert sein.
• Unter Verwendung dieser Informationen wird ein ZulassungslisteEine basierte Mikrosegmentierungsrichtlinie könnte entwickelt werden, um sicherzustellen, dass die CI-Pipeline nur Zugriff auf und von diesen gut verstandenen Abhängigkeiten hat.
• Wenn ein Internetzugang erforderlich ist, sollte er nur für eine Liste zugelassener Repositorien und nicht für einen ungehinderten Internetzugang erlaubt sein. Dadurch wird der Zugriff nur auf eine explizit definierte Liste von Zielseiten beschränkt und es handelt sich um eine effektive und oft einfache Maßnahme zur Abwehr von C&C- und Datenexfiltrationsversuchen.

Dies schützt die CI-Pipeline vor dem Zugriff durch unbefugte Geräte oder über nicht autorisierte Ports und Protokolle. Es stellt auch sicher, dass im Falle einer Beeinträchtigung der CI-Pipeline die Exposition gegenüber dem Rest des Netzwerks begrenzt ist. Außerdem verbessert Segmentierung Kontrollen gehen oft mit einem deutlich besseren Einblick in die Systeminteraktionen einher und liefern umfassendere 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 Kunden dabei, die Vorteile zu nutzen Mikrosegmentierung um diese Eindämmung und Überwachung einzurichten. Wenden Sie sich an Ihr Account-Team, um herauszufinden, wie wir Sie unterstützen können.