Bent u een systeembeheerder die uw Log4Shell-beperkingen op tijd gedaan voor de cyberbeveiligingsdeadline van de Amerikaanse regering van 24 december 2021?

Als dat zo is, heb je misschien samen met een groot deel van de rest van de wereld genoten van een mini-kerstvakantie...

...om deze week terug te keren naar de strijd en te ontdekken dat het Apache Log2j-team net uit is de vierde patch in wat je zou kunnen noemen de Log4Shell Kwetsbaarheid Saga.

De nieuw ontdekte bug is CVE-2021-44832, gepatcht in Log4j 2.17.1, aangekondigd op 2021-12-28 (gisteren op het moment van schrijven).

"Nog een keer," beste vrienden, in de beroemde woorden gegeven aan Koning Hendrik V Door de Bard van Avon.

Gelukkig, ondanks alle begrijpelijke publiciteit die deze vierde fout heeft gekregen, en ondanks alles dat we je dringend verzoeken om het toch snel te patchen, wordt deze bug momenteel alleen genoemd Matig.

Deze lijkt niet direct en gemakkelijk te exploiteren zoals het originele CVE-2021-44228-gat dat aanleiding gaf tot de naam Log4Shell in de eerste plaats.

De saga tot nu toe

Om de . samen te vatten verhaal tot nu toe, vanaf ongeveer 09 december 2021:

• Nieuws breekt van een gemakkelijk te misbruiken "functie" in de Apache Log4j-logcode. Wat de meeste programmeurs afschudden als eenvoudige vervanging van variabelen in het loggen van gegevens (bijv ${java:version} in een tekststring die de Java-versie beschrijft) bleek dat aanvallers verberg gevaarlijke commando's in gegevens van buitenaf, zoals het injecteren van instructies voor het lekken van geheime gegevens of het downloaden van kwaadaardige code.
• Organisaties over de hele wereld realiseren zich dat de buggy-code zeer wijdverbreid is. Zelfs bedrijven die zichzelf niet als Java-winkels beschouwden, vonden Java-apps verspreid over hun netwerken. Log4j bleek onverwachts te zijn begraven in velen van deze apps.
• Het bericht dringt door dat deze bug zelfs diep in een netwerk kan worden misbruikt. Niet-Java-servers draaien aan de rand van het netwerk neemt het risico niet weg. Elke interne server waarnaar niet-vertrouwde gegevens (bijvoorbeeld een telefoonnummer of een postcode) worden verzonden voor verwerking, kan gevaar lopen als deze gegevens worden geregistreerd. En veel business-logic-apps creëren uitgebreide logboeken, vaak met een goede reden, zoals voor audit- of nalevingsdoeleinden.
• Apache publiceert snel Log4j 2.15.0, het repareren van primair veiligheidsgat. Voor die servers waar wijzigingsbeheer het toepassen van de patch in de weg stond (blijkbaar zonder ironie gezien het feit dat hetzelfde wijzigingsbeheerproces vermoedelijk vele jaren geleden door de kwetsbare code zwaaide), bood Apache handige runtime-beperkingen om het gevaarlijke gedrag te onderdrukken.
• Het aantal aanvallen neemt toe, waaronder veel van zelfbenoemde onderzoekers die 'proberen te helpen'. Omdat deze bug oorspronkelijk een functie was, zou het kunnen: met gemak uitgebuit, dus iedereen die mee wilde doen kon het proberen. Duizenden, misschien zelfs miljoenen, deden dat, vaak zonder openlijke kwade bedoelingen. Maar te midden van de cyberbeveiligingsrook van nutteloos "onderzoek" waren er talloze echte branden die zijn begonnen door cybercriminelen die gegevens stelen of malware implanteren zoals cryptominers en ransomware.
• Apache graaft dieper in de code en vindt nog een fout. Log4j krijgt snel een tweede update om 2.16.0.
• Apache vindt een derde fout die ons versie 2.17.0 brengt. We adviseerden systeembeheerders die halverwege de upgrade naar 2.16.0 of 2.15.0 waren, gewoon door te gaan met patchen, maar met 2.17.0 voor hun nog niet gepatchte systemen. Het is beter om al uw systemen zo snel mogelijk op 2.15.0 of hoger te hebben, en dan later terug te gaan en de 2.15.0- en 2.16.0-servers te "opwaarderen", dan het risico te lopen dat sommige servers langer volledig ongepatcht blijven.
• De Amerikaanse regering stelt 24 december 2021 vast als deadline voor de patch. Nu eerste kerstdag en tweede kerstdag 2021 respectievelijk op zaterdag en zondag landen en in een groot deel van de wereld een dubbelspel voor weekend-plus-familievakanties creëren, besluit CISA om de spreekwoordelijke Nacht voor Kerstmis as de deadline voor de Amerikaanse publieke sector om zijn patches uit te rollen.

Fout de vierde

Deze nieuwe, vierde fout was gemeld net na het kerstweekend 2021, op 2021-12-28.

Gelukkig, in de woorden van Apache:

Apache Log4j2 versies 2.0-beta7 tot en met 2.17.0 (exclusief beveiligingsfix releases 2.3.2 en 2.12.4) zijn kwetsbaar voor een externe code-uitvoering (RCE)-aanval waarbij een aanvaller met toestemming om het logboekconfiguratiebestand te wijzigen een kwaadaardige configuratie kan maken met behulp van een JDBC Appender met een gegevensbron die verwijst naar een JNDI URI die externe code kan uitvoeren. Dit probleem is verholpen door de namen van JNDI-gegevensbronnen te beperken tot het Java-protocol in Log4j2-versies 2.17.1, 2.12.4 en 2.3.2.

RCE is natuurlijk zo'n beetje het ergste soort cyberbeveiligingslek dat je ooit zult ervaren, omdat het meestal betekent dat een buitenstaander een onverwacht programma in je computer kan steken zonder dat je er ook maar afscheid van hoeft te nemen.

Een RCE-aanval kan een niet-vertrouwde app injecteren, een binair fragment van machinecode in het geheugen porren of stiekem een ​​ongewenst scriptbestand aanbieden...

...en als de aanvaller slaagt, voer je hun code onbewust uit, zonder enige ambtenaar Are you sure (Y/N)? prompt of This could harm your computer dialoog om u een tip te geven.

Maar ondanks alles wat deze bug RCE noemt, is het niet echt wat het jargon een . noemt geverifieerde uitvoering op afstand, waarbij iedereen die met uw netwerk kan communiceren zonder eerst in te loggen (bijvoorbeeld door een openbare website te bezoeken), de bug kan activeren.

Zoals Apache vermeldt, moet een aanvaller, om uitvoering op afstand mogelijk te maken, eerst voldoende toegang nodig hebben om te knoeien met de configuratie-instellingen van de kwetsbare server of bedrijfslogica-toepassing.

We vermoeden dat aanvallers met voldoende toegang om de configuratie-instellingen aan de serverzijde te wijzigen, een aantal extra manieren hebben om uw interne apps, systemen of netwerk te compromitteren.

Met andere woorden, als u op dit moment direct risico loopt op CVE-2021-44832, dan is het updaten van Log4j 2.17.0 naar 2.17.1 waarschijnlijk noch een noodzakelijke noch een afdoende oplossing voor uw beveiligingsproblemen.

Simpel gezegd, patch niet alleen naar 2.17.1 en denk, "Geweldig. Nu kan ik ontspannen tot het nieuwe jaar.”

Wat te doen?

• Patch naar Log4j 2.17.1 wanneer u kunt. Het heeft geen zin om deze update helemaal over te slaan, simpelweg omdat deze alleen wordt beoordeeld Matig.
• Als u denkt dat CVE-2021-44832 een duidelijk en aanwezig gevaar vormt voor uw netwerk, alleen patchen is niet voldoende. Een systeem dat vanwege deze bug echt kwetsbaar is voor kwaadwillende buitenstaanders, loopt vrijwel zeker ook het risico van tal van andere aanvallen.
• Controleer uw Log4j-configuratie-instellingen. Zoek naar ongeoorloofde of ongewenste instellingen waar je misschien nog niet eerder aan hebt gedacht.

In een eerder artikel, hebben we voorgesteld om in de nabije toekomst uw eigen gebruik van Log4j opnieuw te bekijken en uit te zoeken of u het echt nodig hebt in uw eigen software.

Als je Log4j hebt geërfd zonder het zelfs maar te beseffen, als onderdeel van de Java "supply chain", en het gemakkelijk zou kunnen vervangen door iets dat veel eenvoudiger en minder rijk is aan functies, denken we dat dat een verstandige keuze zou zijn.

Sommige commentatoren zeiden dat we onrealistisch waren of over de top gaan door dit te zeggen, bewerend dat we de complexe logging-behoeften van de gemiddelde zakelijke app onderschatten.

Maar we gaan nogmaals voorstellen dat als je Log4j onlangs in je ecosysteem hebt gevonden, vooral op servers waarvan je niet eens wist dat het er was, je jezelf de vraag zou moeten stellen, "Heb ik echt een multi-megabyte logging-toolkit nodig die bestaat uit bijna een half miljoen regels broncode, of zou iets dat veel bescheidener en gemakkelijker te beoordelen is minstens net zo goed kunnen?"

Dat is geen kritiek op Apache; het is slechts een herinnering dat overgeërfde beveiligingsproblemen zoals Log4Shell vaak het onverwachte neveneffect zijn van een cyberbeveiligingsbeslissing die jaren geleden is genomen door iemand van buiten uw bedrijf die u nog nooit hebt ontmoet en nooit zult ontmoeten.

Ondanks dat de oorspronkelijke beslissing misschien niet jouw schuld is, is het nu jouw verantwoordelijkheid, dus het herzien ervan kan nauwelijks als controversieel of ondoordacht worden beschouwd!

LEER HOE DE LOG4SHELL KWETSBAARHEID WERKT

(Als je de tekst hier niet duidelijk kunt lezen, probeer dan de modus Volledig scherm, of direct kijken op Youtube. Klik op het tandwiel in de videospeler om het afspelen te versnellen of om ondertitels in te schakelen.)