Wie Atlassian Log4Shell mit Snyk in den Griff bekam

Snyk hat kürzlich gemeinsam mit AWS eine mehrtägige Live-Hacking-Reihe gestartet. Dabei demonstrierten Experten Exploits in Echtzeit und erklärten, wie Sie sich gegen diese Schwachstellen schützen können. Die Reihe zeigte den Zuschauern neue Möglichkeiten, die Sicherheit im gesamten Application-Stack für AWS-Workloads zu verbessern.

Im Rahmen der Reihe sprachen Micah Silverman (Director of Developer Relations bei Snyk) und Chris Walz (Senior Security Engineer bei Atlassian) über Log4Shell. Für alle, die Log4Shell noch nicht kennen: Dabei handelte es sich um eine weitverbreitete Zero-Day-Schwachstelle in der allgegenwärtigen Java-Bibliothek Log4j. Wenn Sie mehr über die Schwachstelle erfahren möchten, finden Sie bei Snyk eine umfangreiche Log4j-Ressourcensammlung.

In diesem Beitrag blicken wir auf Walz’ Erfahrungen mit Snyk bei der Erkennung und Behebung von Log4Shell bei Atlassian zurück und fassen Silvermans ausführlicheren Vortrag über die Auswirkungen von Log4Shell zusammen.

Wie Atlassian mit Snyk die Sicherheit skalierbar macht

Atlassian verfügt im gesamten Unternehmen über Tausende von Repositories und Services. Jedes einzelne zu scannen, wäre daher nicht praktikabel. Deshalb entwickelte das Sicherheitsteam von Atlassian eine Automatisierung, die bei Codeänderungen in einem beliebigen Repository Scans mit Snyk Open Source ausführt.

Darüber hinaus verarbeitet die Automatisierung die Scanergebnisse von Snyk und erstellt für alle Sicherheitsprobleme Jira-Tickets. Diese Tickets werden dem Entwickler zugewiesen, der die Codeänderung vorgenommen hat, und enthalten einen Link zum Repository sowie konkrete Hinweise zur Behebung des Problems. Sobald das Problem behoben ist, wird das Ticket automatisch geschlossen.

„Wir haben ein Jira-Projekt, das unternehmensweit für alle Sicherheitslücken genutzt wird. Das sorgt für bessere Transparenz, ermöglicht Automatisierung und stellt sicher, dass die SLOs eingehalten werden.“

Log4Shell bei Atlassian beheben

Im Dezember 2021 gab die Apache Software Foundation eine kritische Schwachstelle in der Bibliothek Log4j bekannt, die später den Namen Log4Shell erhielt. Atlassian leitete umgehend eine Sicherheitsuntersuchung ein, um festzustellen, ob das Unternehmen verwundbare Log4j-Versionen verwendete, wie schwerwiegend die Auswirkungen auf die betroffenen Produkte waren und wie Log4Shell behoben werden konnte.

„Was Bibliotheksabhängigkeitsprobleme angeht, war das so ziemlich der schlimmste Fall. Bei Atlassian verwenden wir viel Java, daher war das ein ernstes Problem, und wir haben sofort eine Sicherheitsuntersuchung eingeleitet.“

Walz’ Team wusste, dass Snyk dabei helfen konnte, die Projekte zu identifizieren, in denen Log4j verwendet wurde. Die Automatisierung lief jedoch nur bei Codeänderungen. Das Team musste sicherstellen, dass die Informationen aktuell waren. Da die Log4Shell-Schwachstelle gerade erst in die Snyk Vulnerability Database aufgenommen worden war, schrieb Atlassian ein Skript, um alle Projekte schnell erneut zu scannen und verwundbare Log4j-Instanzen zu erkennen.

Nachdem sich das Sicherheitsteam vergewissert hatte, dass alle Schwachstellendaten aktualisiert waren, startete es den zweiten Teil der Automatisierung manuell – die Jira-Synchronisierung. Dadurch wurden automatisch 1.426 Jira-Tickets zu Log4j-Schwachstellen an alle zuständigen Entwickler gesendet, damit sie diese schnell beheben konnten.

„Diese Jira-Tickets wurden automatisch erstellt, ohne dass das Sicherheitsteam etwas tun musste. Innerhalb von 12 Stunden nach der ursprünglichen Bekanntgabe hatte jede Person, die eine verwundbare Version von Log4j verwendete, ein Ticket mit der Aufforderung, sie zu aktualisieren.“

Die Auswirkungen von Log4Shell

Da Log4Shell im Java-Ökosystem so weit verbreitet war, bestand der entscheidende Schritt zur Behebung darin, herauszufinden, wo verwundbare Log4j-Instanzen verwendet wurden. Dabei reicht es jedoch nicht aus, nur die Projektabhängigkeiten zu prüfen. Snyk hat festgestellt, dass die meisten Schwachstellen auf transitive Abhängigkeiten zurückzuführen sind.

Dank zeitnaher und präziser Sicherheitsinformationen von Snyk konnten viele Unternehmen Log4j in ihren Codebasen erkennen, obwohl es sich bei über 60 % der Instanzen um indirekte Abhängigkeiten handelte. Tatsächlich veröffentlichte Snyk rasch ein Update für die Snyk CLI, das speziell dafür entwickelt wurde, Log4j in Java-Binärdateien oder JAR-Dateien aufzuspüren.

„Aufgrund der Art dieses Problems mussten wir alles hinterfragen. Das ist die Kehrseite von Open Source. Das Gute daran ist, dass wir sehr schnell auf Probleme reagieren können. Doch oft dauert es ein paar Tage, bis sich die Lage stabilisiert.“

Nach einer Analyse der branchenweiten Auswirkungen stellte Snyk fest, dass über 17.000 Java-Pakete betroffen waren und allein in den ersten 72 Stunden mehr als 800.000 Angriffsversuche unternommen wurden. Viele Angreifer nehmen jedoch Unternehmen ins Visier, die Schwachstellen nach diesem ersten Zeitraum nie beheben. Deshalb ist es wichtig, auch lange nach der Veröffentlichung eines Patches kontinuierlich nach Schwachstellen wie Log4Shell zu suchen.

„Manchmal tappen wir in die Falle des Schwachstellenzyklus und sind erleichtert, sobald es eine Möglichkeit gibt, die Schwachstelle zu beheben. Doch das ist eigentlich erst die Mitte des Zeitraums, denn ein Teil der Unternehmen wird die Schwachstelle nicht rechtzeitig beheben – und genau dann werden Angreifer aktiv.“

Weitere Sessions der Reihe:

• Exploits für Ihre anfälligsten Codezeilen mit StackHawk

• Schwachstellen in Ihren Container-Workloads mit AWS ausnutzen

• Fehlkonfigurierte Kubernetes-Umgebungen mit HashiCorp hacken

Sehen Sie sich hier die vollständige AWS-Live-Hacking-Session mit Snyk und Atlassian an.

Play Video: Exploiting Risks in Your Open Source Dependencies with Atlassian