Apache publiceert beveiligingsupdate voor nieuwe kwetsbaarheid in log4j

Apache Software Foundation heeft een beveiligingsupdate uitgestuurd voor log4j en roept beheerders op te updaten. Een nieuwe kwetsbaarheid in de software maakt arbitrary code execution mogelijk. De kwetsbaarheid is minder ernstig dan eerdere kwetsbaarheden.

Om misbruik te maken van de kwetsbaarheid moet een aanvaller wel de mogelijkheid hebben tot het aanpassen van het logging-configuratiebestand. Volgens de ontdekker, beveiligingsonderzoeker Yaniv Nizry, is de kwetsbaarheid hierdoor complexer dan de oorspronkelijke kwetsbaarheid Log4Shell. Als de aanvaller het logging-configuratiebestand aangepast heeft, kan deze vervolgens een configuratie aanmaken. Daarbij maakt hij gebruik van JDBCAppender met een verwijzing naar een 'Java Naming and Directory Interface URI', die arbitrary code kan uitvoeren. Dat maakt een exploit mogelijk. Op die manier kan de aanvaller via een remote shell toegang krijgen tot de server van het slachtoffer.

De kwetsbaarheid is aangeduid als CVE-2021-44832 en heeft een kwetsbaarheidsscore van 6,6 op een schaal van 1 tot 10. Omdat de aanvaller al toegang moet hebben tot het logging-configuratiebestand, is de kwetsbaarheid in de praktijk minder makkelijk te misbruiken dan de ernstige kwetsbaarheid in de log4j-tool die begin december aan het licht kwam. Ook is deze minder erg dan de kwetsbaarheid die in de beveiligingsupdate die daarop verscheen ontdekt werd. Er werden de afgelopen weken vier kwetsbaarheden ontdekt in log4j.

In een blogpost legt Nizry uit hoe een aanvaller de exploit kan gebruiken. Hij vertelt dat sinds Log4Shell de software van Apache onder een vergrootglas ligt bij beveiligingsonderzoekers, waardoor het niet gek is dat ze meer kwetsbaarheden ontdekken in log4j. Hij benadrukt dat in versie 2.17.0 de belangrijkste aanvalsmethoden geblokkeerd zijn, maar dat het nog steeds mogelijk is om arbitrary code execution uit te voeren waarbij gebruik wordt gemaakt van de standaardconfiguratie van log4j.

Nizry meldde de kwetsbaarheid maandag 27 december aan Apache en ontving dezelfde dag nog een reactie. Een dag later heeft Apache een beveiligingsupdate, versie 2.17.1 van de software, beschikbaar gesteld die de kwetsbaarheid onschadelijk moet maken. Apache roept gebruikers op om te updaten naar log4j 2.3.2 voor Java 6, log4j 2.12.4 voor Java 7 of versie 2.17.1 voor Java 8 en nieuwer. De kwetsbaarheid zit in alle versies van de software tot en met versie 2.17.0. De update pakt ook een kwetsbaarheid aan die een denial of service-aanval mogelijk maakt.

Reacties (36)

[Bor]

Er is nog discussie of het gaat om Remote Code Execution (RCE) of Arbitrary Code Execution (ACE)

There has been confusion on Twitter as to whether this is actually a remote code execution (RCE) or arbitrary code execution (ACE) vulnerability. Researcher Yaniv Naziry (@YNizry) initially stated today that a new RCE vulnerability related to Log4j is to be announced, and later retracted their initial statement confirming that it is indeed arbitrary code execution and not remote code execution.

Compounding matters, Apache classifies CVE-2021-44832 as a remote code execution vulnerability. In the writeup for CVE-2021-44832, Apache states that the attacker needs permission to "modify the logging configuration file" to successfully exploit this vulnerability which is not indicative of an RCE. CVE-2021-44832 is fixed in Log4j 2.17.1 (Java , 2.12.4 (Java 7) and 2.3.2 (Java 6).

[BytePhantomX]

Dit is wat mij betreft wel FUD van de hoogste plank. De partij hier achter wil graag meeliften op de publiciteit rondom deze kwetsbaarheid en brengt dan dit naar buiten. In eerste instantie met een vage tweet van een nieuw account met een screenshot over Log4j en RCE. Dan ben je wat mij betreft vooral uit op aandacht.

Goed twitter draadje om het te volgen van begin tot eind: https://twitter.com/GossiTheDog/status/1475824475333668876

Quote:

To be absolutely clear that is a non-issue for 99.999% of situations - if somebody is modifying your Tomcat install, they already own your box.

It was discussed almost ten years ago.

I have big questions about how this one played out, it’s also unfair to the Log4j maintainers.

Maar het principe dat je al toegang moet hebben tot de server om misbruik te maken van het lek is wel van een compleet andere categorie dat de eerste kwetsbaarheid. Maar intussen is iedereen die half leest in paniek want Log4j en RCE worden genoemd.

Als iemand misbruik kan maken van dit lek, heb je grotere problemen dan deze kwetsbaarheid. Er zijn 1001 technieken om backdoors te creëren als je al toegang hebt, daar heb je deze niet voor nodig. Geen enkele reden om in paniek te raken.

[Reactie gewijzigd door BytePhantomX op 1 augustus 2024 06:41]

[SirRosencrantz]

Goede toevoeging inderdaad. Ik hoopte dat het duidelijk genoeg was in het artikel, maar die twitterdraad vat het goed samen.

[Bor]

Dat een account nieuw is is niet zo raar wanneer er lekken naar buiten worden gebracht. Dat gebeurt bijvoorbeeld ook wanneer men zo anoniem mogelijk wil blijven.

[SirRosencrantz]

Ik heb in deze maar de benaming van Nizry aangehouden, ace dus.

[Geekomatic]

Jeetje, zo blijven we bezig.
Kan er gaag ook een versie komen waar die hele JNDI feature *uitgehaald* is?
Dus gewoon tekst loggen zonder interpretatie / post-processing.

[Reactie gewijzigd door Geekomatic op 1 augustus 2024 06:41]

[satya]

Door de klasse er uit te halen als die toch niet gerbuikt wordt.

"zip -d lib/log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class"

[david-v]

Ik heb al medelijden met alle beheerders die weer aan de slag moeten om te voorkomen dat het hoofdmanagement besluit om alles uit te zetten, voor de zekerheid.

Ik zie ook third party producten die log4j er helemaal uitslopen. Het pakket heeft nu wel een slechte naam gekregen, of het nou terecht is of niet. Ik ben benieuwd wat voor acties de komende tijd gaan volgen. Dat pakket staat nu onder een enorme vergrootglas.

Edit:typo

[Reactie gewijzigd door david-v op 1 augustus 2024 06:41]

[MsG]

Je blijft toch houden dat het halve applicatie-landschap soms leunt op onderbetaalde packages. Dit zag je bij het OpenSSL-debacle eerder ook. Dan kan je het forken, en het LibreLog4J gaan noemen, maar dat verandert dan weinig. De welbekende XKCD hierover laat het leuk zien: https://imgs.xkcd.com/comics/dependency_2x.png

[Robtimus]

En de Log4J versie daarvan: https://dl.airtable.com/....c8815/20211213_141935.jpg

[Frame164]

Als hoofdmanagement dit soort beslissingen neemt wordt het hoog tijd dat de IT afdeling serieus naar hun management gaan kijken. Als de IT manager niet in staat is om een boodschap op hoofdmanagement niveau kan overbrengen is het niet fit for purpose.

[david-v]

Als ik naar de beslissing van de kamer van koophandel kijk....dan ja, dat lijkt mij een beslissing van het hoofdmanagement. Je moet ook niet vergeten dat veel (financiele) instellingen onder toezicht staan en dat ze behoorlijk onder druk gezet kunnen worden om alles in het werk te zetten om ramsonware aanvallen te voorkomen, indien nodig door de dienst volledig uit te zetten.

[Sograd]

Als hoofdmanagement dit soort beslissingen neemt wordt het hoog tijd dat de IT afdeling serieus naar hun management gaan kijken

Dat ligt eraan. Heb je dan daarvoor niet het issue dat het je als IT afdeling niet is gelukt om aan de manager uit te leggen dat je de boel al hebt gefixed, voordat hij dit aan het hoofdmanagement moet uitleggen?

Daarnaast zit een manager natuurlijk met een heel andere beleving. Een IT-er heeft op zo'n moment zijn best gedaan om alles te fixen. Maar als dan maandag blijkt dat in het kerst weekend (weinig personeel beschikbaar), dat er toch iets fout is gegaan, dan moet de betreffende manager de boodschap brengen, dat er iets is foutgegaan, en uitleggen hoe dat heeft kunnen gebeuren, en waarom ze de dienst niet hadden stil gelegd in een weekend waarbij er bijna geen standby beschikbaar is.

[Brahiewahiewa]

Euh: noem mij één bedrijf waarbij de IT-afdeling z'n eigen management kiest

[terror538]

Ik vermoed dat er na het eerste lek honderden al dan niet duizenden onderzoekers zijn gaan kijken, omdat het zo veel in het nieuws was en omdat het zo veel gebruikt wordt.

Het is niet onwaarschijnlijk dat andere software die net zo veel gebruikt wordt vergelijkbare kwetsbaarheden heeft die nog niet gevonden zijn door een gebrek aan aandacht

Je zou dus kunnen zeggen dat juist nu na alle aandacht en fixes Log4j een goede keuze is juist

[david-v]

Zo denken wij, techneuten, hoe meer ogen erop gericht zijn hoe beter het voor de veiligheid is. Maar dat neemt het gevoel bij veel IT managers niet weg...

[Transportman]

Helaas is dat bij managers wel de realiteit, ik heb bij een van onze klanten managers horen jubelen omdat ze onze software (al jaren) niet hadden geupdate naar een versie waar log4j2 in zit. Dat ze daardoor op een compleet niet ondersteunde versie van onze software zitten met daarin log4j die al jaren EOL is kwam niet bij ze op.

[terror538]

Yep...

[gimbal]

Bij mij heeft log4j, of de Java tak van Apache in het algemeen eigenlijk, ook wel een kleine deuk opgelopen qua vertrouwen. Puntje bij paaltje hadden de breekbare enterprisy features simpelweg niet met dit gemak toegevoegd moeten kunnen worden in de core API, ook al die vele jaren geleden niet. Het is een logging API die nu veel teveel doet en dus slecht is in dat vele gedoe in plaats van enkel heel goed te zijn in wat het adverteert te doen.

Je moet wel echt actief op zoek gaan wil je uberhaupt weten dat deze features erin zaten, ik was me nergens van bewust. Naar mijn idee was log4j2 gelijk aan log4j 1.x maar dan met een beter geoptimaliseerde code base... duidelijk had ik het flink mis.

[Ircghost]

Als iemand al toegang heeft tot het configuratie bestand kan die aanvaller waarschijnlijk al een stuk meer dat even zo, misschien wel erger is

Maakt het niet minder belangrijk om deze te patchen natuurlijk.

[david-v]

Ja, het is naar mijn mening wel een beetje overdreven inderdaad. Goed om dit te patchen hoor. Maar als ze al binnen zijn om het config bestand aan te passen, dan ben je de kieren van het raam aan het kitten terwijl de voorkeur openstaat.

[PageFault]

Als je al toegang tot het systeem hebt, zou het log bestand mijn laatste zorg zijn. Je kunt zoveel meer foute dingen doen dan....

[thijsjek]

Op zich zou je dat denken. Maar wat als, je in eerste instantie al root toegang had. Gegevens steelt, En dan deze gebruikt als backdoor, zodra ze je opmerken om een ransomware aanval af te ronden ofzo.

[PageFault]

Root toegang, ergens in 2018 kon je op macOS X inloggen met root zonder wachtwoord. Daar was toen aanzienlijk minder commotie over, terwijl het lek veel en veel serieuzer was

[zenlord]

Heel vaak zijn aanvallers weken of maanden lang aanwezig op een systeem alvorens ze hun echte aanval inzetten. Ze moeten zich dus heel lang kunnen verstoppen voor allerhande security sweeps - ik kan mij inbeelden dat een kwetsbaarheid als deze daar ideaal voor is...

Om maar te zeggen dat 'een beetje overdreven' niet echt op z'n plaats is. De CVE score is 6.6, en dus duidelijk lager dan de initiële kwetsbaarheid die een 10.0 kreeg.

[Blokker_1999]

Maar dat is natuurlijk waar het aaneenschakelen van ogenschijnlijk kleine kwetsbaarheden om de hoek komt kijken natuurlijk. Stel je voor dat je als aanvaller niet veel toegang hebt weten te verkrijgen in een netwerk en enkel slechts grotendeels betekenisloze bestanden kunt zien en beschrijven waaronder deze config file. Maar daardoor ben je ineens wel in staat om een andere payload uit te voeren met meer rechten... . Ja, het is een minder ernstige kwetsbaarheid net omdat deze als losstaand geheel niet veel schade kan aanrichten, maar dat betekend dus zeker niet zoals sommige hier doen overkomen dat dit een triviaal probleem is.

[SunnieNL]

Dat is ook een van de redenen waarom de CVSS score maar op 6.6 staat.
Echter binnenkomen staat nooit op zichzelf. Een andere (kleine) exploit van een andere service op het systeem kan ook veroorzaken dat je bij deze config kan komen. Gecombineerd wordt het probleem dan groter en groter en groter.

[Peetke]

"Een nieuwe kwetsbaarheid tot versie 2.17.0" Een nieuwe kwetsbaarheid tot EN MET versie 2.17.0.

We kunnen weer aan het updaten!

Bijvoorbeeld Ubiquiti heeft nog geen updates:
https://community.ui.com/releases
Dus daar moeten we nog even op wachten.

[psdata]

Als je je locale mngt applicatie gewoon binnen hebt draaien (niet toegankelijk via internet) heb je geen probleem . (of achter een goede firewall die dit verkeer herkent)

Voor de rest is het ook wel eens goed om eens een stof kam door al je draaide omgevingen te halen of je iedere library\applicatie op je apache omgeving wel nodige hebt. Er wordt zoveel vaak standaard mee geinstaleerd wat vaak niet nodig is.

[Cyb]

Als je je locale mngt applicatie gewoon binnen hebt draaien (niet toegankelijk via internet) heb je geen probleem . (of achter een goede firewall die dit verkeer herkent)

Dat is een fout die velen maken. Bij deze Log4j kwetsbaarheid zijn interne servers haast net zo kwetsbaar als servers die direct aan het Internet hangen.

[Frame164]

De firewall kan ook lek zijn. Of iets intern of extern is maakt vanuit security oogpunt niet veel uit. Bij mijn klanten worden de securitytests op iedere server uitgevoerd. De laptop wordt direct op een server of ander device aangesloten ongeacht waar die in het netwerk zit.

[amoi]

Misschien dat je wat aan het volgende hebt?
Gepost in: https://community.ui.com/...-9169-bf6dfbbcc209?page=8

UI-Marcus
Team Ubiquiti
7 days ago
@mokar1980 , I already shared this on the disclosure, but sharing here for visibility also.

our UniFi Network Application does not use Context lookups what makes us not vulnerable to the last 2 CVE’s . In short everyone should be safe with 6.5.54, but still we made 6.5.55 and now 7.0.15 on EA as security best practice to update libraries even when we are not vulnerable.

[xbeam]

De zoveelste Security face place van Markus.

The don’t use it but a hacker can use it for them.

Beter Patch je de controller gewoon zelf zoals beschreven op het Tweakers
https://gathering.tweaker...message/69939310#69939310

Je wil gewoon geen CVE’s op je server die wanneer bij inbraak makkelijk te vinden en te gebruiken zijn.

[Reactie gewijzigd door xbeam op 1 augustus 2024 06:41]

[Elidibus]

Respect aan alle mensen die mee hebben gewerkt aan het dichten van dit lek (en bij de verschillende bedrijven). Het zijn niet de feestdagen die ze gehoopt hadden, maar het moest even. Het einde is zo te zien in zicht.

[MRBooty]

@Peetke

In UniFi Network Application 7.0.15 BETA Bevat log4j 2.17.0. Zal niet lang duren dat ze hem patchen na 2.17.1

Bron https://community.ui.com/...96-4444-9362-b4d1acf3056f

[Anonymoussaurus]

Apache roept gebruikers op om te updaten naar updaten naar log4j 2.3.2 voor Java 6, log4j 2.12.4 voor Java 7 of versie 2.17.1 voor Java 8 en nieuwer. De update pakt ook een kwetsbaarheid aan die een denial of service-aanval mogelijk maakt aan.

Die update wordt alleen meegepakt als je nog niet had geüpdatet naar 2.17.0, niet 2.17.1. 2.17.0 bevat een fix voor CVE-2021-45105, en dus niet 2.17.0 (wat bovenstaande nu lijkt te impliceren).