Responsible Disclosure: CodeCov-CEO und CTO teilen Erkenntnisse aus dem Sicherheitsvorfall

Im Januar 2021 wurde CodeCov Opfer eines Supply-Chain-Angriffs, bei dem Umgebungsvariablen von Kunden offengelegt wurden. In den darauffolgenden Monaten hat die Application-Security-Community die Details des Vorfalls und seine technischen Auswirkungen eingehend untersucht, um herauszufinden, was schiefgelaufen ist und wie sich ähnliche Angriffe künftig verhindern lassen. Eine weitere interessante Folge des Vorfalls waren jedoch Erkenntnisse zu einem etwas weniger glamourösen Thema: Responsible Disclosure.

Im Oktober 2021 waren CodeCov-CEO Jerrod Engelberg und CTO Eli Hooten zu Gast im Podcast The Secure Developer podcast, um Einblicke aus erster Hand in die Ereignisse zu geben. Ihr Gespräch mit Guy beleuchtete, wie es ist, im Zentrum eines Sicherheitsvorfalls zu stehen, und warf interessante Fragen dazu auf, wie sich ähnliche Vorfälle am besten bewältigen lassen.

Hören Sie sich jetzt die vollständige Folge an

Der CodeCov-Sicherheitsvorfall

Bevor wir uns mit den Auswirkungen dieser Folge beschäftigen, hier eine kurze Zusammenfassung. CodeCov ist ein Code-Coverage-Tool, das maschinenlesbare Berichte erstellt, während Entwicklerinnen und Entwickler Tests ausführen. Diese Berichte werden vom Uploader von CodeCov verarbeitet, der die relevanten Coverage-Daten bereitstellt. Über einen Continuous-Integration-Anbieter wie GitHub, GitLab oder Bitbucket gelangen die maschinenlesbaren Berichte zum Uploader von CodeCov. Damit befindet sich CodeCov mitten in der Software-Supply-Chain.

Zum Zeitpunkt des Vorfalls verwendete CodeCov ein curl|bash-Skript (auch „curl pipe bash“, „curl bash piping“ usw. genannt), um Berichte auf den eigenen Server hochzuladen. Dieser wurde in einem CDN-Bucket mit den Berechtigungen `private write, public read` gehostet. Der Angreifer konnte ein Zugangstoken aus einer komprimierten Ebene des Enterprise-Docker-Images von CodeCov extrahieren und auf den CDN-Bucket zugreifen. Dort manipulierte er das Bash-Skript. Das veränderte Skript wurde in die CI-Pipeline jedes Kunden eingebunden, der zwischen dem Angriff und dem Widerruf der Zugangsdaten einen Pull- oder Merge-Request erstellte. Dadurch konnten die Angreifer in die Kundenumgebungen eindringen, in denen die CI ausgeführt wurde, die Umgebungsvariablen ausgeben und zur späteren Verwendung an einen Drittanbieter-Server weiterleiten.

Die Auswirkungen dieses Angriffs waren von Kunde zu Kunde unterschiedlich. Verwaltete ein Kunde seine CI in einem öffentlichen Repository, waren in seinen Umgebungsvariablen wahrscheinlich keine relevanten Informationen gespeichert. Nutze ein Kunde hingegen ein geschlossenes Repository, in dem die CI intensiv mit dem Tech-Stack interagierte und vertrauliche Informationen enthielt, gab der Vorfall Anlass zu ernsthafter Sorge.

Wie bei jedem Supply-Chain-Angriff stand nur eines fest: Informationen waren abgeflossen. Es ließ sich nicht wissen, was die Angreifer mit den gestohlenen Umgebungsvariablen vorhatten. Das Team musste deshalb schnell und entschlossen handeln.

Die Reaktion von CodeCov

Engelberg fasste CodeCovs Grundsatz für die Offenlegung so zusammen: „Wenn auch nur ein Kunde nichts von uns erfährt und nicht die nötigen Maßnahmen ergreift, ist das ein Kunde zu viel.“ In der Praxis stellte sich die Umsetzung dieses Grundsatzes jedoch als Herausforderung heraus. Wer sich bei CodeCov anmeldet, kann dafür eine E-Mail-Adresse oder einen Social-Login wie OAuth, GitHub oder Bitbucket verwenden und so die eigenen Kontaktdaten privat halten. Eine praktische Wahl, die später zu einem entscheidenden Faktor im Offenlegungsprozess wurde.

Für Kunden, die direkt bei CodeCov ein Konto erstellt oder ihre Kontaktdaten angegeben hatten, war die Lösung einfach. An jede verfügbare Adresse wurden E-Mail-Benachrichtigungen versandt, die über den Vorfall informierten und zu Maßnahmen aufforderten. Leider gehörte die Mehrheit der CodeCov-Nutzer nicht zu dieser Gruppe. Daher setzte das CodeCov-Team alles daran, alle übrigen Kunden zu erreichen.

Nach der Meldung des Vorfalls an die Bundesbehörden wurde er öffentlich offengelegt. Tech-Medien verbreiteten und verstärkten Ankündigungen mit Details zum Vorfall, und CodeCov verschickte in der Anwendung zahlreiche Benachrichtigungen. Das Team ergriff alle angemessenen Maßnahmen, um die Nutzerbasis zu informieren. Die Umstände, die zu dieser umfassenden Reaktion führten, sind jedoch eine genauere Betrachtung wert.

Hätte CodeCov von allen Nutzern verlangt, persönliche Informationen wie eine E-Mail-Adresse anzugeben, wäre es nach dem Sicherheitsvorfall einfach gewesen, alle zu erreichen. Durch die Möglichkeit, sich über einen Social-Login anzumelden, konnten Kunden ihre persönlichen Daten besser schützen. Das brachte jedoch auch erhebliche Hürden mit sich, wenn dringende Mitteilungen nötig waren. Wäre der Offenlegungsprozess von CodeCov anders verlaufen, wenn sich Nutzer so einfach wie mit einer Rundmail benachrichtigen ließen? Wahrscheinlich nicht. Hooten sagte: „Ich denke, Sie wissen, dass Sie das Richtige tun, wenn die Antwort auf der Hand liegt – auch wenn der weitere Weg schmerzhaft oder schwierig ist.“ Die Werte, auf denen CodeCov aufbaut, hätten das Team ohnehin zu Transparenz bewegt.

Geschäftliche Auswirkungen durch Transparenz begrenzen

Kein Unternehmen kann einen Sicherheitsvorfall völlig unbeschadet überstehen. CodeCov gelang es jedoch, die negativen Auswirkungen durch anhaltende, transparente Kommunikation zu begrenzen. Trotz des schnellen Handelns kam es zu einigen Kundenabwanderungen. Wie Engelberg erklärte, gab es „Kunden, die sagten: ‚Hey, wir können euch derzeit nicht nutzen.‘ Oder Befürworter unseres Produkts, die sagten: ‚Hey, ich nutze euer Produkt sehr gern, aber es wurde ein Moratorium verhängt und ich darf es [nicht mehr] verwenden.‘“ Ohne die transparente Offenlegung des Teams wäre der Kundenverlust jedoch deutlich größer gewesen. Schwachstellen lassen sich viel leichter beheben als verlorenes Vertrauen.

Wie Snyk ist CodeCov eine entwicklerorientierte Anwendung – und Entwicklerinnen und Entwickler brauchen Daten statt Beschönigungen. Indem CodeCov bei den Fakten blieb und die größere Security-Community um Hilfe bat, bewahrte das Unternehmen auch mitten in der Krise seine Glaubwürdigkeit und sein Engagement für Entwicklerinnen und Entwickler.

Über den Sicherheitsvorfall hinaus

Der CodeCov-Sicherheitsvorfall brachte Erkenntnisse ans Licht, die weit über einen einzelnen Vorfall hinausgehen. Die Art des Angriffs macht mögliche Fallstricke deutlich, die die gesamte Branche betreffen. Der größte davon ist ein grundlegendes Problem bei der Verteilung. Open-Source-Software wird für den Entwicklungszyklus immer wichtiger, doch ihre Abhängigkeiten werden dabei oft unbedacht mit übernommen. Die Vorteile von Open Source sind unbestreitbar. Entscheidend ist, herauszufinden, wie wir sie sicher nutzen können.

Um die Sicherheit nach dem Vorfall zu erhöhen, führte CodeCov Maßnahmen wie SHA-Prüfsummen und Signaturverifizierung ein. Nutzer wurden dazu ermutigt, diese Prüfungen zu nutzen und sicherzustellen, dass die Skripte, die sie abriefen, tatsächlich direkt von CodeCov stammten. Die Verwendung dieser Verifizierungen lässt sich jedoch nicht vorschreiben. Wie Engelberg erklärte: „Solange wir nicht bei Zero Trust sind, [...] gibt es immer diesen Handschlag, oder? Wir können den Handschlag immer ausgefeilter gestalten. Aber darüber denke ich viel nach, wenn es darum geht, wie es weitergeht und was als Nächstes kommen kann.“

Wir können Nutzer über mögliche Risiken aufklären und ihnen Tools zur Codeprüfung an die Hand geben, aber wir können niemanden zu zusätzlichen Schritten zwingen. Die Vertrauensvereinbarung zwischen Unternehmen und Kunden ist tief in der Entwicklungskultur verwurzelt. Unsere Aufgabe als Branche ist es, den besten Plan zur Risikominderung zu finden.

Möchten Sie mehr über den CodeCov-Sicherheitsvorfall und seine Erkenntnisse für die Branche erfahren? Hören Sie sich die vollständige Podcast-Folge bei The Secure Developer an. Engelberg und Hooten gewährten Einblicke in CodeCov und sprachen über die Vorbereitung auf Sicherheitsvorfälle im Unternehmen, Ratschläge für CEOs und CTOs, den Einfluss von Empathie auf den Krisenverlauf und vieles mehr.