sydneysamantha/triage-cve-2021-44228-log4shell-log4j-Ziel ist es, bekannte Angriffe zu triagieren und zu lernen, wie Sicherheitsteams schnell reagieren.
In diesem Lab ging es darum, eine weitere bekannte reale Schwachstelle zu triagieren: Log4Shell, eine der am häufigsten ausgenutzten Schwachstellen der letzten Jahre, weil die betroffene Bibliothek in der Unternehmenssoftware weit verbreitet war.
Ich bin zur National Vulnerability Database gegangen und habe die CVE nachgeschlagen:
https://nvd.nist.gov/vuln/search#/nvd/home?resultType=records
Ich habe nach CVE-2021-44228 gesucht und die Ergebnisseite geöffnet.
Nachdem ich die Beschreibung gelesen hatte, habe ich ein paar grundlegende Fragen beantwortet, um zu verstehen, was tatsächlich gefährdet ist:
Ich habe den CVSS-Score und den Vector-String auf der Seite gefunden:
Ich bin den Vector-String Stück für Stück durchgegangen, um zu sehen, was jeder Teil tatsächlich bedeutet:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Das ist ungefähr so schlimm, wie ein Vector-String nur sein kann: keine Privilegien nötig, keine Benutzerinteraktion, über das Netzwerk erreichbar, und er kann sogar Systeme außerhalb der verwundbaren Komponente selbst beeinträchtigen (Scope: Geändert). Diese Kombination ist ein Grund dafür, dass Log4Shell bei ihrer Offenlegung als so dringendes und weitverbreitetes Problem behandelt wurde.
Ich habe den Abschnitt „Weakness Enumeration“ auf der NVD-Seite für diese CVE geprüft.
Die aufgeführte CWE ist CWE-917: Unzureichende Neutralisierung spezieller Elemente, die in einer Expression-Language-Anweisung verwendet werden. Einfach ausgedrückt bedeutet das: Die Software nimmt Eingaben entgegen und wertet sie als Teil eines Ausdrucks aus, ohne sie vorher ordnungsgemäß zu prüfen – genau das ermöglichte es Angreifern, bösartige JNDI-Lookups über normale Logmeldungen einzuschleusen.
Ich habe überlegt, ob ich dieses Risiko in zwei verschiedenen Szenarien als höher oder niedriger einstufen würde.
Szenario 1: Die verwundbare Software ist live und erreichbar. Höheres Risiko. Diese Schwachstelle ermöglicht es einem Angreifer, auf EL-Anweisungen (Expression Language) zuzugreifen und sie zu verändern, was sich direkt auf Vertraulichkeit und Integrität auswirkt.
Szenario 2: Die verwundbare Software ist auf einem Rechner installiert, der ausgeschaltet und nicht erreichbar ist. Niedrigeres Risiko. Wenn die verwundbare Software überhaupt nicht erreichbar ist, bleiben Vertraulichkeit und Integrität intakt, da es für einen Angreifer keine Möglichkeit gibt, mit ihr zu interagieren.
Von den CVEs, die ich bisher triagiert habe, stach dieser hervor, weil ein Angreifer so wenig benötigt, um ihn auszunutzen – keine Privilegien, keine Benutzerinteraktion, nur Netzwerkzugriff – und weil die Schwachstelle auch Systeme über die Komponente selbst hinaus beeinträchtigen konnte. Er ist ein gutes Beispiel dafür, warum Log4Shell in der gesamten Branche eine derartige Hektik auslöste, als sie bekannt wurde.