Wie LiveRamp Log4Shell mit Snyk behob

Wie jedes Unternehmen, das Web-Apps oder mit Java entwickelte Unternehmenssoftware nutzt, befürchtete das in San Francisco ansässige Unternehmen LiveRamp, von der Zero-Day-Schwachstelle Log4Shell in Log4j betroffen zu sein – der beliebten Open-Source-Logging-Bibliothek.

Als Log4Shell Mitte Dezember 2021 bekannt wurde, hatte LiveRamp – ein Unternehmen für Datenvernetzung, das unterschiedliche Kundendaten in die unternehmenseigenen Marketingplattformen integriert – gerade den POC-Test (Proof of Concept) mit Snyk abgeschlossen und befand sich in einer frühen Phase der Implementierung von Snyk Open Source und Snyk Container.

LiveRamp wollte mit Snyk vor allem seine CI/CD-Pipeline durch automatisierte Schwachstellen-Scans absichern. Die Entwicklungs- und Sicherheitsteams von LiveRamp rechneten nicht damit, dass Snyk einen schwerwiegenden Zero-Day-Exploit aufspüren und bei seiner Behebung helfen würde.

„Wir haben uns gefragt: ‚Wollen wir Snyk dafür einsetzen?‘“, erklärte John Jelinek, Staff DevOps Engineer bei LiveRamp. „Google hatte eigene Tools veröffentlicht, um nach Exploits wie Log4Shell zu suchen. Aber wir waren gerade dabei, Snyk zu integrieren, und das Tool war für solche Situationen konzipiert. Deshalb entschieden wir uns, mit dem Snyk-Tool nach Instanzen der Log4j-Bibliothek zu suchen.“

Log4j-Instanzen mit Snyk aufspüren

Als LiveRamp mit Snyk nach Log4j suchte, waren Jelinek und sein Team sich nicht sicher, wie viele Repositories sie scannen mussten und wem die einzelnen Repositories gehörten. Insgesamt waren 1.600 GitHub-Repositories im Einsatz. Jelinek filterte mit dem Snyk API-Importtool die GitHub-Repositories auf 400 Java-Projekte ein, die besonders anfällig für Log4Shell waren und in Snyk importiert und gescannt werden mussten. Innerhalb von zwei Stunden konnte er alle Java-Projekte in Snyk importieren.

Jelinek richtete intern eine Taskforce zur Eindämmung von Log4Shell ein und begann, Snyk-Berichte zu den Log4j-Instanzen in den Java-Projekten von LiveRamp zu erhalten. Anschließend sammelte er die Snyk-Berichte und leitete sie an das Sicherheitsteam weiter, das die Schwachstelle in allen betroffenen Log4j-Instanzen behob.

Jelinek und sein Team stellten fest, dass 23 % der 400 Java-Projekte die Log4Shell-Schwachstelle enthielten und behoben werden mussten.

Container auf Log4j scannen

Im nächsten Schritt scannte LiveRamp mit Snyk seine Container in GCR auf Log4j. Das erwies sich als aufwendig, da jeder Container zwischen 500 und 2.000 Projekte sowie Java-Binärdateien und mehrere Versionen enthielt. „Die Zahl der Container-Images mit Log4j war überhöht“, sagte Jelinek. „Viele dieser Images mussten archiviert werden, weil sie nicht mehr zu unserer Umgebung gehören.“

Dieser Aufwand war zwar arbeitsintensiv, aber auch wertvoll: Er half LiveRamp zu verstehen, welche Container priorisiert und welche gelöscht oder archiviert werden sollten.

Die Behebung von Log4Shell

LiveRamp legte eine Prioritätenfolge für die Behebung fest. Zuerst wurden kundenorientierte Anwendungen behoben, die für Kunden zugänglich waren. Danach folgten Anwendungen für Mitarbeitende, auf die nur intern zugegriffen werden konnte.

Mit Snyk konnte LiveRamp alle Log4Shell-Instanzen in externen und internen Anwendungen noch vor Jahresende beheben (Log4Shell wurde am 10. Dezember bekannt). „Bei kundenorientierten Apps dauerte die Behebung eine Woche“, sagte Jelinek, „bei internen Apps vielleicht zwei Wochen. Die Behebung aller anfälligen Log4j-Versionen (bis 2.17) dauerte bis Ende Januar.“

Erkenntnisse für die nächste Schwachstelle

Der Einsatz von Snyk zum Scannen und Beheben von Log4Shell machte deutlich, dass LiveRamp eine Software-Stückliste (SBOM) benötigt. Laut Jelinek bestand eine Herausforderung für LiveRamp beim Bekanntwerden von Log4Shell darin, zu wissen, welche Bibliotheken und Abhängigkeiten die einzelnen Microservices verwendeten. Die fehlende Transparenz darüber, wie die URLs, Microservices und Repositories von LiveRamp miteinander verbunden waren, erschwerte es, die Log4j-Bibliothek in der Infrastruktur zu lokalisieren und festzustellen, welche Services anfällig waren.

„Die Log4Shell-Schwachstelle hat uns vor Augen geführt, dass wir unseren Software-Footprint verstehen müssen“, sagte Jelinek. „Daran arbeiten wir jetzt kontinuierlich, um einen besseren Überblick zu gewinnen.“ Nachdem LiveRamp die Herausforderungen von Log4Shell bewältigt hat, sorgt Snyk weiterhin für mehr Transparenz über den Sicherheitsstatus der Open-Source-Abhängigkeiten und Container des Unternehmens.