Log4j-Sicherheitslücken bleiben bestehen – sind Sie darauf vorbereitet?

Die weit verbreitete Schwachstelle, die erstmals 4 in Apache Log2021j auftauchte wird weiter ausgenutzt, möglicherweise sogar in schlechterer Weise, als wir bisher gesehen haben. Der besorgniserregendere Aspekt dieser Bedrohungen ist, dass sie wahrscheinlich noch Monate oder Jahre in die Zukunft ausgenutzt werden.

Das Cyber ​​Safety Review Board des Department of Homeland Security wurde 2021 gegründet und 2022 veröffentlicht Erster Sicherheitsbericht (PDF). Darin nannte das Board Log4j eine „endemische Schwachstelle“, hauptsächlich weil es keine umfassende „Kundenliste“ für Log4j gibt, was es zu einer nahezu unmöglichen Aufgabe macht, mit Schwachstellen Schritt zu halten. Eine Abteilung des Bundeskabinetts verbrachte sogar 33,000 Stunden mit ihrer Log4j-Antwort.

Und viele Organisationen und Sicherheitslösungen auf dem Markt erkennen nicht den Unterschied zwischen Ausnutzbarkeit und Schwachstelle – und geben Angreifern die Möglichkeit, böswillige Aktivitäten auszuführen.

Ausnutzbarkeit vs. Schwachstelle

Eines der wichtigsten Probleme bei der heutigen Cybersicherheit besteht darin, den Unterschied zwischen Schwachstellen und ihrem Schweregrad zu verstehen. Wenn es darum geht, Ausnutzbarkeit im Vergleich zu einer Schwachstelle zu messen, gibt es einen großen Unterschied, ob eine Sicherheitsbedrohung in Ihrem Unternehmen ausnutzbar ist oder ob sie nur „anfällig“ ist und das Unternehmen nicht behindern oder einen kritischen Vermögenswert erreichen kann. Sicherheitsteams verbringen zu viel Zeit damit, den Unterschied zwischen den beiden nicht zu verstehen und jede Schwachstelle sofort zu beheben, anstatt diejenigen zu priorisieren, die ausnutzbar sind.

Jedes Unternehmen hat tausende gemeinsame Schwachstellen und Gefährdungen (CVEs), von denen viele im Common Vulnerability Scoring System (CVSS) hoch abschneiden, sodass es unmöglich ist, sie alle zu beheben. Um dem entgegenzuwirken, besteht die Hoffnung, dass Tools für das risikobasierte Schwachstellenmanagement (RBVM) dies tun erleichtern die Priorisierung, indem klargestellt wird, was verwertbar ist.

Ansätze zur Sicherheitspriorisierung, die CVSS-Scores mit RBVM-Bedrohungsinformationen kombinieren, liefern jedoch keine optimalen Ergebnisse. Selbst nach dem Filtern und Betrachten dessen, was in freier Wildbahn ausgenutzt werden kann, haben Sicherheitsteams immer noch zu viel zu tun, da die Liste lang und unüberschaubar ist. Und nur weil ein CVE heute keinen Exploit hat, heißt das nicht, dass er nächste Woche keinen haben wird.

Als Reaktion darauf haben Unternehmen prädiktive Risiko-KI hinzugefügt, die den Benutzern helfen kann zu verstehen, ob ein CVE in Zukunft ausgenutzt werden könnte. Dies ist immer noch nicht genug und führt zu zu vielen Problemen, die behoben werden müssen. Tausende Schwachstellen werden immer noch einen Exploit aufweisen, aber viele werden andere Bedingungen aufweisen, die erfüllt sein müssen, um das Problem tatsächlich auszunutzen.

Beispielsweise müssen bei Log4j die folgenden Parameter identifiziert werden:

• Existiert die anfällige Log4j-Bibliothek?
• Wird es von einer laufenden Java-Anwendung geladen?
• Ist die JNDI-Suche aktiviert?
• Hört Java auf Remote-Verbindungen und besteht eine Verbindung zu anderen Computern?

Wenn die Bedingungen und Parameter nicht erfüllt sind, ist die Schwachstelle nicht kritisch und sollte nicht priorisiert werden. Und selbst wenn eine Schwachstelle auf einem Computer ausgenutzt werden könnte, na und? Ist diese Maschine extrem kritisch oder ist sie vielleicht nicht mit kritischen oder sensiblen Anlagen verbunden?

Es ist auch möglich, dass die Maschine nicht wichtig ist, aber es einem Angreifer ermöglichen kann, auf heimliche Weise auf kritische Assets zuzugreifen. Mit anderen Worten, der Kontext ist entscheidend – befindet sich diese Schwachstelle auf einem potenziellen Angriffspfad auf das kritische Asset? Reicht es aus, eine Schwachstelle an einem Chokepoint (einem Schnittpunkt mehrerer Angriffspfade) abzuschneiden, um zu verhindern, dass der Angriffspfad ein kritisches Asset erreicht?

Sicherheitsteams hassen Schwachstellenprozesse und ihre Lösungen, weil es immer mehr Schwachstellen gibt – niemand kann jemals alles komplett sauber machen. Aber wenn sie können Konzentriere dich auf das, was erschaffen kann Organschäden zu einem kritischen Gut, können sie besser verstehen, wo sie anfangen sollen.

Bekämpfung von Log4j-Schwachstellen

Die gute Nachricht ist, dass ein angemessenes Schwachstellenmanagement dazu beitragen kann, die Gefährdung durch Log4j-zentrierte Angriffe zu verringern und zu beheben, indem identifiziert wird, wo das Risiko einer potenziellen Ausnutzung besteht.

Vulnerability Management ist ein wichtiger Aspekt der Cybersicherheit und notwendig, um die Sicherheit und Integrität von Systemen und Daten zu gewährleisten. Es ist jedoch kein perfekter Prozess, und Schwachstellen können immer noch in Systemen vorhanden sein, obwohl alle Anstrengungen unternommen wurden, um sie zu identifizieren und zu mindern. Es ist wichtig, Schwachstellenmanagementprozesse und -strategien regelmäßig zu überprüfen und zu aktualisieren, um sicherzustellen, dass sie effektiv sind und Schwachstellen rechtzeitig behoben werden.

Der Fokus des Schwachstellenmanagements sollte nicht nur auf den Schwachstellen selbst liegen, sondern auch auf dem potenziellen Risiko der Ausnutzung. Es ist wichtig, die Punkte zu identifizieren, an denen sich ein Angreifer möglicherweise Zugang zum Netzwerk verschafft hat, sowie die Wege, die er möglicherweise einschlägt, um kritische Ressourcen zu kompromittieren. Der effizienteste und kostengünstigste Weg, die Risiken einer bestimmten Schwachstelle zu mindern, besteht darin, die Verbindungen zwischen Schwachstellen, Fehlkonfigurationen und Benutzerverhalten zu identifizieren, die von einem Angreifer ausgenutzt werden könnten, und diese Probleme proaktiv anzugehen, bevor die Schwachstelle ausgenutzt wird. Dies kann helfen, den Angriff zu unterbrechen und Schäden am System zu verhindern.

Sie sollten außerdem Folgendes tun:

• Patch: Identifizieren Sie alle Ihre Produkte, die für Log4j anfällig sind. Dies kann manuell oder mithilfe von Open-Source-Scannern erfolgen. Wenn ein relevanter Patch für eines Ihrer gefährdeten Produkte veröffentlicht wird, patchen Sie das System so schnell wie möglich.
• Workaround: Legen Sie in den Log4j-Versionen 2.10.0 und höher in der Java-CMD-Zeile Folgendes fest: log4j2.formatMsgNoLookups=true
• Block: Wenn möglich, fügen Sie Ihrer Webanwendungs-Firewall eine Regel hinzu, um Folgendes zu blockieren: „jndi:“

Perfekte Sicherheit ist eine unerreichbare Leistung, daher macht es keinen Sinn, den Feind des Guten perfekt zu machen. Konzentrieren Sie sich stattdessen auf die Priorisierung und Sperrung potenzieller Angriffspfade, die die Sicherheitslage kontinuierlich verbessern. Zu identifizieren und realistisch einzuschätzen, was tatsächlich angreifbar ist und was ausnutzbar ist, kann dabei helfen, da es die Fähigkeit ermöglicht, Ressourcen strategisch in die kritischen Bereiche zu lenken, die am wichtigsten sind.

• SEO-gestützte Content- und PR-Distribution. Holen Sie sich noch heute Verstärkung.
• Platoblockkette. Web3-Metaverse-Intelligenz. Wissen verstärkt. Hier zugreifen.
• Quelle: https://www.darkreading.com/attacks-breaches/log4j-vulnerabilities-are-here-to-stay-are-you-prepared-