Kritieke kwetsbaarheid Log4j v2

Update 20 december 2021

Apache heeft bekend gemaakt dat er een Denial-of-Service-kwetsbaarheid zit in versie 2.16.0 van Log4j. Voor deze nieuwe kwetsbaarheid (CVE-2021-45105) heeft het NCSC een update uitgebracht van het eerdere beveiligingsadvies [1]. De ernst van deze kwetsbaarheid is ingeschaald met een CVSS score van 7.5 [2]. De kwetsbaarheid moet dan ook worden gezien als minder ernstig dan de willekeurige code kwetsbaarheden in eerdere versies van Log4j 2.0-beta9 t/m 2.12.1 en 2.13.0 t/m 2.15.0. Deze worden nog steeds door versie 2.12.2 en 2.16.0 verholpen. 

CSIRT-DSP raadt aan door te gaan met patchen en hierbij gebruik te maken van de laatste versies die beschikbaar zijn gesteld. Geef voorrang aan systemen die nog kwetsbaar zijn voor willigkeurige code kwetsbaarheid (versies 2.0-beta9 t/m 2.12.1 en 2.13.0 t/m 2.15.0). Voor een overzicht van overige maatregelen die u kunt nemen, verwijzen wij u graag naar het meest actuele handelingsperspectief op [3].

Het ligt in de lijn der verwachting dat er nog meer kwetsbaarheden in (nieuwe) Log4j versies gevonden zullen worden, gezien de ongekende aandacht die het programma wereldwijd krijgt vanwege de ernst van de eerder genoemde kwetsbaarheden en het feit dat Log4j in een zeer grote hoeveelheid applicaties is verwerkt. CSIRT-DSP houdt nieuwe ontwikkelingen nauwgezet bij en zal u hier over blijven informeren. 

[1] https://www.ncsc.nl/actueel/advisory?id=NCSC-2021-1052

[2] https://logging.apache.org/log4j/2.x/security.html

[3] https://www.ncsc.nl/log4j

------------------------------------------------------------------------------------------------------------------------

Update 17 december 2021

Apache heeft aangegeven dat in versie 2.15.0 log4j kwetsbaar is voor CVE-kenmerk CVE-2021-45046. Deze kwetsbaarheid kan onder andere misbruikt worden voor remote code execution. Het CSIRT-DSP past daarom het handelingsperspectief aan naar:

  • Heeft u versie 2.15? Dan adviseert het CSIRT-DSP zo spoedig mogelijk te updaten naar versie 2.16. Dit advies geldt voor Log4j-versie (Java 8);
  • Voor Log4j-versie (Java 7) adviseert het CSIRT-DSP om log4j te updaten naar versie 2.12.2.

Omdat alleen versies 2.12.2 en 2.16.0 geüpdatet zijn om elk van de genoemde kwetsbaarheden (CVE-2021-44228 [1], CVE-2021-45046 [2]) te verhelpen, is het advies om naar een van deze twee versies te updaten. Het kan zijn dat u mogelijk afhankelijk bent van updates vanuit uw leverancier.

Daarnaast bleken enkele mitigatiemaatregelen mogelijk niet afdoende. De volgende mitigatie maatregelen kunnen worden genomen indien updaten niet mogelijk is [3]. Houdt er rekening mee dat het toepassen van deze mitigaties mogelijk invloed heeft op de werking van de bovenliggende applicatie:

  • CVE-2021-44228 en CVE-2021-45046: Verwijder de JndiLookup-class met het commando "zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class".
  • CVE-2021-4104 [4] (Alleen versie 1.2 kwetsbaar met specifieke configuratie. Deze versie is reeds End of Life. Apache raadt aan te upgraden naar een Log4j v2 versie): Verwijder de JMSAppender-class met het commando "zip -q -d log4j-*.jar org/apache/log4j/net/JMSAppender.class".

In de GitHub-repository van het NCSC wordt een overzicht bijgehouden van kwetsbare software. In deze repository zijn tevens tools, IoC's en Yara-rules te vinden. Wij raden aan om de repository periodiek te controleren op informatie relevant voor uw organisatie. De repository is beschikbaar via de volgende URL [5].

Daarnaast vragen wij uw aandacht voor het bericht van het NCSC om als organisatie voorbereid te zijn op misbruik. Het CSIRT-DSP ondersteunt het belang van deze berichtgeving en neemt dit advies over voor digitale dienstverleners.

  1. Zorg dat incident response draaiboeken klaarliggen. Weet wie u moet contacteren in het geval van een incident. Zorg dat u een team paraat heeft. Overweeg het tijdelijk instellen van piketdiensten. Houd de NCSC GitHub in de gaten voor de laatste informatie over indicatoren uit forensisch onderzoek.
  2. Bereid u voor op misbruik. Controleer of bestaande incident response plannen berekend zijn op een incident als Log4j en vul anders aan. Denk bijvoorbeeld aan het isoleren van getroffen systemen en het wijzigen van credentials waar de gecompromitteerde server toegang tot heeft. Stel vast hoe schijf en geheugen artefacten (disk image, memory image) worden veiliggesteld voor verder onderzoek, bijvoorbeeld om te onderzoeken of aangrenzende systemen zijn gecompromitteerd.
  3. Schakel waar mogelijk detectiemaatregelen in. Verschillende organisaties hebben detectieregels voor hun firewallproducten beschikbaar gesteld. Ook voor het inschakelen van deze maatregelen geldt dat dit geen garantie biedt dat elke vorm van misbruik wordt tegengehouden. Breng in kaart wat u niet monitort en vul dat waar mogelijk aan met detectiemaatregelen.
  4. Test uw bestaande back-ups. Maak een offline back-up, ook als u dat normaal niet doet.
  5. Vraag medewerkers u op de hoogte te stellen van verdachte activiteiten. Denk aan verhoogde processoractiviteit of ander afwijkend gedrag.
  6. Zorg dat de gevolgen van een geslaagde aanval beperkt blijven, door verkeer tussen uw systemen te beperken. Segmenteer bijvoorbeeld uw netwerken, of blokkeer niet-noodzakelijk uitgaand netwerkverkeer op uw servers. Breng de afhankelijkheden tussen uw systemen in kaart. Overweeg of u deze afhankelijkheden op korte termijn kunt verminderen.
  7. Log4j is breed gebruikt; het kan gebruikt worden in producten waarbij u het niet verwacht. Kunt u incidenten in de nabije toekomst niet duiden?  Houd dan rekening met een eventuele compromittatie als gevolg van de kwetsbaarheid in Log4j.
  8. De gevonden kwetsbaarheid kan gebruikt worden om een ransomware-aanval uit te voeren. Het NCSC adviseert om de juiste voorbereidingen te treffen. Meer informatie is te vinden in de factsheet Ransomware van het NCSC [6].
  9. Bepaal of uw leveranciers gebruik maken van Log4j. Scantools detecteren in sommige gevallen geen gebruik van Log4j in producten van leveranciers. Veel leveranciers communiceren proactief over de impact van Log4j op hun producten. Indien dit niet zo is: Vraag uw leverancier naar de kwetsbaarheid en de acties die u kunt ondernemen. Op GitHub verzamelt het NCSC een overzicht van de status van producten.

[1] https://nvd.nist.gov/vuln/detail/CVE-2021-44228

[2] https://nvd.nist.gov/vuln/detail/CVE-2021-45046

[3] https://logging.apache.org/log4j/2.x/security.html

[4] https://nvd.nist.gov/vuln/detail/CVE-2021-4104

[5] https://github.com/NCSC-NL/log4shell

[6] https://www.ncsc.nl/documenten/factsheets/2020/juni/30/factsheet-ransomware  

------------------------------------------------------------------------------------------------------------------------

Update 16 december 2021

Let Op: Onderstaande berichtgeving is niet de meest recent beschikbare informatie.

De (remote) code execution kwetsbaarheid in lo4gj, waarover het NCSC in beveiligingsadvies NCSC-2021-1052 heeft geadviseerd, is volgens Apache in zowel versie 2.15 als versie 2.16 van Log4j verholpen. Apache geeft wel aan dat Log4j versie 2.15 een Denial-of-Service (DoS) kwetsbaarheid bevat (CVE-2021-45046). Het NCSC en CSIRT-DSP beschikken op dit moment niet over informatie die de berichtgeving van Apache hierover in twijfel trekt.

Het NCSC en CSIRT-DSP adviseert organisaties dringend te updaten naar een recente versie van Log4j.

  • Heeft u versie 2.14 of ouder? Dan adviseert het CSIRT-DSP zo snel mogelijk te updaten naar versie 2.16.
  •  Heeft u versie 2.15 al? Dan adviseert het CSIRT-DSP om indien mogelijk te updaten naar versie 2.16.

Het beveiligingsadvies (NCSC-2021-1052) is geüpdatet met de meest recente informatie en adviezen.

------------------------------------------------------------------------------------------------------------------------

Handelingsperspectief om kans op misbruik te beperken

Het NCSC heeft op Github een lijst geplaatst met applicaties die kwetsbaar zijn als gevolg van de recent gepubliceerde kwetsbaarheid in Log4j v2 (CVE-2021-44228). Deze pagina gaat ook gebruikt worden om scan- en detectiemogelijkheden en IoC’s bekend te maken.

Het is goed mogelijk dat voor u onvoldoende duidelijk is hoe te handelen in deze situatie. Daarom adviseren wij digitale dienstverleners de onderstaande stappen te doorlopen:

  • Inventariseer of log4j-2 in uw netwerk wordt gebruikt;
  • Controleer voor kwetsbare systemen of uw softwareleverancier reeds een update beschikbaar heeft gesteld en voer deze zo spoedig mogelijk uit;
    • Indien het systeem informatie verwerkt wat afkomstig is van het internet en er is geen update beschikbaar neem dan mitigerende maatregelen waar mogelijk.
      • Apache adviseert de volgende mitigatie maatregelen indien updaten niet mogelijk is:
  • CVE-2021-44228 en CVE-2021-45046: Verwijder de JndiLookup-class met het commando "zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class".
  • CVE-2021-4104 [4] (Alleen versie 1.2 kwetsbaar met specifieke configuratie. Deze versie is reeds End of Life. Apache raadt aan te upgraden naar een Log4j v2 versie): Verwijder de JMSAppender-class met het commando "zip -q -d log4j-*.jar org/apache/log4j/net/JMSAppender.class".
    • Waar dit niet mogelijk is adviseren wij om te overwegen het systeem uit te schakelen totdat er een update beschikbaar is.
    • De Github repository die wordt bijgehouden door het NCSC kan u van informatie voorzien over nieuw uitgebrachte updates, maar wij raden ook aan zelf leverancierspagina’s te monitoren en neem eventueel contact op met uw leverancier.
  • Er zijn verschillende scripts voor Linux en Windows beschikbaar om te controleren of er kwetsbare systemen in uw netwerk aanwezig zijn. Ook verschillende kwetsbaarheidsscanners hebben updates of plugins uitgebracht om te controleren of systemen kwetsbaar zijn.

    Let op: Deze scans bieden geen 100% garantie dat u geen kwetsbare systemen draait;
  • Controleer zowel systemen die al zijn geüpdatet als ook kwetsbare systemen op misbruik, wij adviseren te kijken naar misbruik in de laatste weken. Zover bekend is er kleinschalig misbruik gemaakt vanaf ten minste 1 december, vanaf 10 december is er grootschalig misbruik bekend;
  • Verschillende organisaties hebben voor hun Firewall-producten detectiemaatregelen beschikbaar gesteld. U kunt verschillende referenties naar configuratie-regels ook terugvinden op de Github-pagina. Wij adviseren u om detectiemaatregelen in te schakelen. Ook hiervoor geldt dat dit geen garantie biedt dat elke vorm van misbruik wordt tegengehouden. Dergelijke regels zijn vaak gericht op specifieke aanvalsvectoren.