Security-Experten zur Log4j-Sicherheitslücke
Log4Shell: Was jetzt zu tun ist
Durch Log4Shell, eine vom BSI als extrem kritisch eingestufte Schwachstelle in der verbreiteten Open-Source-Protokollierungsbibliothek Apache Log4j, können nicht authentifizierte entfernte Angreifer manipulierte Anfragen an einen Server senden und so beliebigen Schadcode ausführen (Remote Code Execution, RCE). Angreifer nutzen die Schwachstelle bereits aus. Die Experten der Bitdefender Labs zum Beispiel melden zahlreiche aktuelle Angriffe, darunter Einbetten von Kryptominern sowie versuchte Ransomware-Attacken. Nachfolgend erläutern Security-Fachleute die Lage und erklären, wie Unternehmen vorgehen sollten.
Laut Check Point wurden bereits 45 Prozent aller von Check Point überwachten Unternehmensnetze in Deutschland angegriffen. 72 Stunden nach der ersten Attacke habe man bereits rund 846.000 Angriffe registriert.
„Die Zero-Day-Lücke in Log4j ist hochgefährlich, da sie ohne explizites Nachladen von Schadcode direkt ausnutzbar ist“, erläutert Paul Smit, Director Professional Services bei dem Security-Anbieter ForeNova. Das BSI spricht deshalb sogar von einer „extrem kritischen Bedrohungslage“. Es stellt sich also die Frage, wie Unternehmen diese Schwachstelle in ihrer Umgebung erkennen können und welche Risiken drohen, wenn sie unbehoben bleibt.
„Die Schwierigkeit für viele Unternehmen besteht derzeit darin, zu identifizieren, ob sie Log4j im Einsatz haben und in welcher Konfiguration“, so Dr. Sebastian Schmerl, Director Security Services EMEA bei Arctic Wolf. „Das kann ohne aktives Monitoring, ein Software-Inventory oder ein Vulnerability-Scanning oftmals nicht einfach beantwortet werden.“
„Zuerst sollten Unternehmen prüfen, ob eine Version von Log4j vor 2.15.0 verwendet wird, auch in den Abhängigkeiten“, erklärt Jonathan Tanner, Senior Security Researcher bei Barracuda Networks. „Sowohl Maven als auch Gradle – beides auf Java basierende Build-Management-Tools – bieten die Möglichkeit, den gesamten Abhängigkeitsbaum für ein Projekt auszudrucken. So lässt sich feststellen, ob eine verwundbare Version von Log4j verwendet wird oder nicht.“
Auch mit Version 2.15.0 oder höher sollte man laut Tanner sicherstellen, dass die Systemeigenschaft formatMsgNoLookups nicht auf „false“ gesetzt ist. Denn diese Version sei nur deshalb nicht verwundbar, weil sie den Standardwert von true auf false gesetzt hat. In einigen Versionen von Log4j lasse sich diese Eigenschaft einfach manuell auf „true“ setzen, um die Sicherheitslücke zu entschärfen.
„Wenn die Anwendung LDAP nicht als Teil ihrer legitimen Nutzung benötigt, ist es auch möglich, den gesamten LDAP-Verkehr mit einer Firewall oder einem Web Application Filter zu blockieren“, so Tanner weiter. So könne man den Remote-Code stoppen, falls Angreifer die Schwachstelle ausnutzen.
Eine weitere Möglichkeit ist es laut Avi Shua, CEO von Orca Security, eine Mitigationsmaßnahme zu implementieren. Dies funktioniere auch dann, wenn der Anbieter keinen Fix bereitstellt. „Dabei gilt es, die Systemeigenschaft ,log4j2.formatMsgNoLookups’ auf ‚true‘ zu setzen, wodurch die Schwachstelle nicht ausgenutzt werden kann und keine Änderung durch den Hersteller erforderlich ist“, so Shua.
„Ob ein System wirklich anfällig für einen Angriff ist oder nicht, ist eine viel kompliziertere Angelegenheit ohne einen einzigen Test, wie ihn Schwachstellen wie HeartBleed hatten“, erläutert Barracuda-Mann Tanner. „Um diese Schwachstelle auszunutzen, müsste ein Angreifer einen Log-Injection-Angriff durchführen. Diese zu finden ist ein sehr viel komplexerer Prozess, aber im Grunde genommen kann jeder Ort, an dem Eingaben eines Benutzers oder eines potenziellen Angreifers protokolliert werden, für diesen Angriff anfällig sein. Um einen tatsächlichen RCE zu testen, müsste man also versuchen, einen Weg zu finden, eine JNDI-LDAP-Anfrage innerhalb der Protokolle aus dem Benutzerkontext selbst zu stellen, zum Beispiel über die Website oder die API, wenn die potenziell betroffene Anwendung eine Web-Anwendung ist.“
Eine weitere Frage steht im Raum: Welche Rolle spielte Open Source bei dieser Sicherheitslücke? „Da es sich bei Log4j um eine sehr beliebte Open-Source-Bibliothek handelt, war die Zahl der verwundbaren Anwendungen sicherlich höher“, meint Tanner. „Generell kann jede Software anfällig für Angriffe sein, und bei populärer Open-Source-Software gibt es oft ein großes Ökosystem, das nach Sicherheitsbedrohungen sucht und diese behebt.“
Er betont: „Auch wenn Open-Source-Software die meisten Schlagzeilen macht, wenn größere Sicherheitslücken gefunden werden, bedeutet dies nicht, dass sie verhältnismäßig weniger sicher ist.“ In der Tat sei Open Source wahrscheinlich viel sicherer als proprietärer Code oder weniger populäre Bibliotheken: „Die weite Verbreitung erhöht lediglich die Wahrscheinlichkeit, dass Schwachstellen gefunden werden, nicht unbedingt die Wahrscheinlichkeit, dass sie existieren.“
Bei der Suche nach Open-Source-Bibliotheken sollten Unternehmen laut Tanner große, seriöse und gut gewartete Projekte wie eben Log4j wählen: „Natürlich kann es immer noch Schwachstellen geben, aber es ist wahrscheinlicher, dass die Community diese Schwachstellen findet und ausbessert und auch überprüft, dass der Code frei von Fehlern ist, die überhaupt erst Schwachstellen verursachen könnten, als bei kleineren Projekten.“
„Selbst für diejenigen, deren Anwendungen nicht für CVE-2021-44228 (der offizielle Name der meist „Log4Shell“ genannten Schwachstelle, d.Red.) anfällig sind oder die Log4j gar nicht für die Protokollierung verwenden, ist diese Schwachstelle definitiv ein Weckruf, dahingehend, dass Log-Injection eine potenzielle Methode ist, die Angreifer nutzen könnten“, so Tanner weiter. Es lohne sich deshalb zu überprüfen, ob alle Benutzereingaben, die man protokolliert, in jeder Anwendung ordnungsgemäß bereinigt werden – unabhängig davon, welches Protokollierungssystem oder welche Programmiersprache zum Einsatz kommt.
„Auch wenn andere Formen der Injektion weitaus verbreiteter sind und im Mittelpunkt des Interesses stehen, handelt es sich bei der Log-Injection immer noch um eine Form des Injektionsangriffs“, so Tanner – also eine der OWASP-Top-10-Schwachstellen.
- Log4Shell: Was jetzt zu tun ist
- Kurzfristige Reaktion, langfristige Strategie
Lesen Sie mehr zum Thema
