probablysecure/triage-cve-2021-44228-log4shell-log4j-Ziel ist es, bekannte Angriffe zu triagieren und zu lernen, wie Sicherheitsteams schnell reagieren.
In diesem Labor bestand das Ziel darin, eine weitere bekannte reale Schwachstelle zu triagieren: Log4Shell, eine der am häufigsten ausgenutzten Schwachstellen der letzten Jahre, da die betroffene Bibliothek in Unternehmenssoftware weit verbreitet war.
Ich ging zur National Vulnerability Database und suchte nach der CVE:
https://nvd.nist.gov/vuln/search#/nvd/home?resultType=records
Ich suchte nach CVE-2021-44228 und öffnete die Ergebnisseite.
Nachdem ich die Beschreibung gelesen hatte, beantwortete ich ein paar grundlegende Fragen, um zu verstehen, was tatsächlich gefährdet ist:
Ich fand den CVSS-Score und den Vector-String auf der Seite:
Ich ging den Vector-String Stück für Stück durch, 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 erforderlich, keine Benutzerinteraktion, über das Netzwerk erreichbar, und er kann sogar Dinge außerhalb der verwundbaren Komponente selbst beeinflussen (Scope: Geändert). Diese Kombination ist ein Grund dafür, warum Log4Shell bei seiner Offenlegung als so dringliches und weit verbreitetes Problem behandelt wurde.
Ich habe den Abschnitt Weakness Enumeration auf der NVD-Seite für diese CVE überprüft.
Die aufgeführte CWE ist CWE-917: Improper Neutralization of Special Elements used in an Expression Language Statement. Einfach ausgedrückt bedeutet dies, dass die Software Eingaben entgegennimmt und sie als Teil eines Ausdrucks auswertet, ohne sie vorher ordnungsgemäß zu prüfen. Dadurch konnten Angreifer bösartige JNDI-Lookups über normale Protokollmeldungen einschleusen.
Ich habe überlegt, ob ich dies unter zwei verschiedenen Szenarien als höheres oder niedrigeres Risiko 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 diese 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 erreicht werden kann, bleiben Vertraulichkeit und Integrität gewahrt, da es für einen Angreifer keine Möglichkeit gibt, mit ihr zu interagieren.
Von den CVEs, die ich bisher untersucht habe, stach dieser besonders hervor, weil ein Angreifer nur wenig benötigt, um ihn auszunutzen: keine Privilegien, keine Benutzerinteraktion, nur Netzwerkzugriff, gepaart mit der Tatsache, dass die Schwachstelle Systeme außerhalb der Komponente selbst beeinträchtigen konnte. Es ist ein gutes Beispiel dafür, warum Log4Shell bei seinem Erscheinen in der Branche eine so große Hektik auslöste.