Hoe je je organisatie het beste kunt beschermen tegen Log4j, een op Java-gebaseerd veiligheidslek

Nu de feestdagen voor de deur staan en organisaties het jaar afsluiten met eindejaarsfestiviteiten, worden beheerders wereldwijd afgestraft, terwijl kwaadwillenden die systemen willen misbruiken een cadeau in de vorm van het Log4j-veiligheidslek krijgen. Dit lek heeft invloed op een veelgebruikt onderdeel van veel softwaretoepassingen en -diensten. Het beperkt zich niet tot een of enkele bedrijven, maar treft honderden of duizenden producten. Verkopers zullen zich moeten haasten om kwetsbare software bij te werken en kwetsbaarheden te patchen die aan het licht zijn gekomen, van netwerkapparatuur tot software voor serverbeheer en consumenten- en bedrijfstoepassingen (om er maar een paar te noemen).

Om deze kwetsbaarheden te beperken, wil Jamf met deze blog gebruikers informeren die niet vertrouwd zijn met deze (en alle volgende) kritieke kwetsbaarheden en op basis van de beste beveiligingspraktijken degenen adviseren die er wel mee vertrouwd zijn.

• Wat is Log4j en waarom is het zo'n probleem?
• Welke Jamf-producten worden getroffen door de kwetsbaarheid en hoe beperkt Jamf deze?
• Hoe kunnen Jamf-producten jouw organisatie helpen deze bedreigingen te beperken?

Canto I: Wat is Log4j?

Je spreekt het uit als 'Log Forge' en het is een kritieke beveiligingsfout in het populaire Log4j, een Java-gebaseerde logboeklibrary die vatbaar is voor een Remote Code Execution-robot (RCE). Aanvankelijk toegewezen als CVE-ID, CVE-2021-44228, verwijst de kwetsbaarheid naar de fout in Apache-software Log4J, een library die tijdens de uitvoering van Java-applicaties door verschillende applicaties wordt gebruikt om informatie te vast te leggen. Het is een van de meest gebruikte, zo niet de meest gebruikte library voor ontwikkelaars van zowel opensource- als commerciële software.

Canto II: Waarom is het zo belangrijk?

Door het wijdverspreide gebruik door leveranciers en de toepassing ervan in verschillende devices, kan de werkelijke impact van deze ernstige bedreiging niet in cijfers worden uitgedrukt. Het is bekend dat kwetsbaarheden van het RCE-type een kritiek urgentieniveau hebben, omdat aanvallers door gebruik te maken van deze zwakke plek effectief op afstand code op de getroffen systemen kunnen uitvoeren zonder dat zij daartoe geautoriseerd zijn. Met dit soort aanvallen kunnen aanvallers feitelijk devices gebruiken en mogelijk ook de gegevens die deze bevatten. Met de eerste kwetsbaarheid kan een aanvaller de Log4j-library vragen willekeurige code van een door de aanvaller beheerde server te downloaden en deze uit te voeren alsof het onderdeel is van de applicatie zelf. Een aanvaller kan zelfs elke applicatie overnemen die gebruik maakt van log4j, zelfs als de aanvaller zich niet hoeft te authenticeren bij de dienst die de library gebruikt.

Overigens was het eerder genoemde woord 'kwetsbaarheden' geen typfout. Het meervoud verwijst naar een tweede kwetsbaarheid (CVE-2021-45046), die is ontdekt doordat de oplossing voor de aanvankelijk ontdekte kwetsbaarheid als gevolg van bepaalde niet-standaard configuraties niet compleet bleek. Positief is dat de extra kwetsbaarheid meer een Denial of Service (DoS)-aanval lijkt te zijn dan een overname-van-je-service-aanval.

Misschien vraag je je af wat dit betekent voor het oplossen van Log4j. Het is nog steeds slecht. Maar het wordt beter. In zulke gevallen is het niet ongebruikelijk dat meerdere updates nodig zijn om de bedreiging volledig te patchen. Wat het beter maakt, is dat deze tweede ontdekte kwetsbaarheid niet langer RCE-exploits mogelijk maakt, maar aanvallers nog wel in staat stelt om invoergegevens op een kwaadaardige manier te bewerken, wat leidt tot een DoS-aanval.

Canto III: Wat is het effect hiervan op Jamf?

Net als vele andere leveranciers, waaronder Apple, Google en Microsoft, werden helaas ook sommige Jamf-producten door het Log4j-lek getroffen. Jamf heeft gezien de aard van de kwetsbaarheden CVE-2021-44228 en CVE-2021-45046, hun kritieke ernst en hun potentieel om diensten te beïnvloeden, snel gehandeld. Jamf-CISO Aaron Kiemele schreef een speciale Jamf Nation-post om Jamf-gebruikers de meest recente informatie te geven over de impact van Log4j op Jamf-diensten, net als informatie over de strategieën die momenteel door Jamf worden uitgevoerd om deze bedreiging voor zijn diensten te beperken.

• Jamf Pro (op locatie): Gepatchte release beschikbaar
• Jamf Pro (cloudgebaseerd): Beperkt en gepatcht
• Jamf Connect: Niet beïnvloed
• Jamf Now: Niet beïnvloed
• Jamf Protect: Niet beïnvloed
• Jamf School: Niet beïnvloed
• Jamf Threat Defense: Niet beïnvloed
• Jamf Data Policy: Niet beïnvloed
• Jamf Private Access: Niet beïnvloed
• Health Care Listener: Niet kwetsbaar
• Jamf Infrastructure Manager: Niet kwetsbaar

Volgens Matthias Wollnik, Product Marketing Manager bij Jamf met een focus op beveiliging, "logt Jamf Infrastructure Manager (JIM) alleen interne operationele gegevens en logt het geen onvertrouwde informatie of informatie die door de klant is aangeleverd. Daardoor kan een aanvaller geen berichten aan Log4j leveren die hem in staat zou stellen de recente kwetsbaarheden uit te buiten".

…en welke beperkende strategieën heeft Jamf ingezet?

Voor Jamf Pro-omgevingen op locatie of die door je organisatie worden gehost, wordt het probleem volledig opgelost vanaf versie 10.34.2, die log4j 2.16 bevat. Eerder was een versie (10.34.1) uitgebracht met log4j 2.15. De meest recente informatie geeft aan dat log4j 2.15 extra configuratie vereist om tegen CVE-2021-45046 beveiligd te zijn. Jamf raadt beheerders op locatie aan om zo snel mogelijk een update te doen naar de 10.34.2-versie.

Als organisaties op dit moment niet kunnen upgraden naar deze nieuwste versie, kun je ervoor kiezen om als alternatief een omleiding te implementeren door de Log4j-instantie op getroffen systemen handmatig bij te werken en de bijbehorende configuratie in te stellen, zoals dat beschreven wordt in het technische document van Jamf. Het uitvoeren van de omleiding heeft geen negatieve invloed op updates in de toekomst.

In de cloud gehoste Jamf Pro-omgevingen zijn beschermd door passende beveiligingscontroles en zijn momenteel niet kwetsbaar. Uit overvloedige voorzichtigheid wordt Jamf Pro 10.34.2 echter ook aan deze klanten uitgerold.

Canto IV: Wat kunnen we doen om onszelf te beschermen?

Patching

De kwetsbaarheid van Log4j heeft wereldwijd zulke verstrekkende gevolgen dat de Cybersecurity & Infrastructure Security Agency (CISA) in de VS een website en GitHub repository hebben opgezet om de wijdverspreide uitbuiting van de Apache Log4j-library op te sporen en te bestrijden. Bovendien heeft de CISA een richtlijn voor kwetsbaarheden opgesteld in de vorm van een livedocument dat beheerders en beveiligingsteams van actuele informatie voorziet over het beschermen van getroffen systemen, met doorlopende bronnen voor detectieregels als hulp bij het opsporen van aanvallen, Log4Shell-hashes, mitigatiehandleidingen voor diverse softwareontwikkelaars en -leveranciers, en aanvullende bronnen voor wereldwijde instanties, zoals die in Noord-Amerika, Europa en Azië worden gevonden.

“Patch snel en patch vaak” – Jamf

Naast het patchen van de noodzakelijke Log4j-kwetsbaarheid met de patch(es) die je van de website van je softwareontwikkelaar hebt gehaald, of op zijn minst een omleiding die een manier biedt om de kwetsbare Log4j-libraries bij te werken die mogelijk zijn ingebed in componenten die deel uitmaken van de getroffen app of dienst die ervan afhankelijk is.

Door Jamf Pro te gebruken, kunnen IT-beheerders niet alleen snel vaststellen welke systemen oudere versies van de betrokken applicaties hebben, maar ook Smart Groups aanmaken om als dat nodig is met de software deployment-functie deze dynamisch te verzamelen en betrokken apps rechtstreeks bij te werken en/of patches op afstand uit te rollen.

Daarnaast zijn er een aantal fundamentele veiligheidsprocedures die beheerders kunnen (en zouden moeten) volgen om de blootstelling van de organisatie aan veiligheidsrisico's als gevolg van Log4j-kwetsbaarheden te beperken of mogelijk risico's te verminderen.

Risicobeoordeling

Hoe weet je wat kwetsbaar is tenzij je weet wat je hebt? Dat is de eerste stap: weten welke devices, apps en diensten deel uitmaken van de infrastructuur van je organisatie. Door een actuele voorraad bij te houden, weet je precies welke middelen je organisatie bezit, hoe ze worden gebruikt en waarvoor ze precies dienen. Gewapend met deze kennis kunnen beheerders gemakkelijk bepalen wat de risico's zijn en in welke mate, voordat ze strategieën inzetten om risico's te beperken.

Software Bill of Materials (lijst van software)

Afgekort als SBOM, fungeren deze als voorraden van softwarecomponenten die zowel organisaties als ontwikkelaars van nauwkeurige en gemakkelijk te begrijpen beschrijvingen van de fundamentele bouwstenen van componenten voorzien, die in softwareapplicaties en -diensten worden gebruikt. Het voordeel hiervan voor een onderneming is dat beveiligingsteams op een eenvoudige manier kunnen nagaan welke componenten aan specifieke kwetsbaarheden binnen de in gebruik zijnde apps van eerste en derde partijen blootstaan.

Defense in Depth (grondige verdediging)

Het is bewezen dat deze succesvolle methode middelen beschermt door meerdere beveiligingsmaatregelen in lagen op elkaar te stapelen en zo de ene op de andere oplossing te bouwen, zodat de algehele beveiliging van systemen, apps en diensten wordt versterkt. Hoewel defense-in-depth-strategieën de onderliggende kwetsbaarheid niet verhelpen, kunnen ze beschermen tegen de gevolgen van de kwetsbaarheid door het aanvalsoppervlak van een getroffen app te beperken en/of de blootstelling in te perken.

Een voorbeeld hiervan is het gebruik van Jamf Protect om aanvallers te identificeren die van de kwetsbaarheid gebruik maken. Sinds gisteren hebben klanten een nieuwe detectie in hun UI: SuspiciousJavaActivity. Deze detectie is op zoek naar een curl of bash-i die onder Java wordt uitgevoerd. Dit is gedrag dat veel aanvallers misbruiken als het om de Log4j-kwetsbaarheid gaat. Als dit wordt gedetecteerd, is mogelijk een Log4j-lek opgetreden. Sommige legitieme Java-applicaties kunnen deze acties echter ook uitvoeren (zelden, hopen we). Het is aan de beveiligingsanalist om te bepalen wat wel en niet normaal is voor de betreffende applicatie.

Eén belangrijk ding om te onthouden: persoonlijke macOS-systemen zullen waarschijnlijk weinig of geen actieve applicaties hebben die Log4j gebruiken en waarop een aanvaller op afstand kan reageren. Analisten kunnen hiermee rekening houden wanneer ze proberen vast te stellen of een melding de moeite waard is om na te trekken.

Least privilege (tot het strikte mininum beperkt)

Het least privilege-principe wordt algemeen beschouwd als een basiscomponent dat beheerders in hun beveiligingsprocessen inbouwen om de toegang van gebruikers te beperken tot wat nodig is om productief te zijn. Niet meer en niet minder. Het principe is van toepassing op host-, applicatie- en netwerkniveau, die allemaal kunnen worden versterkt om te voorkomen dat systemen die het slachtoffer zijn van een RCE-robot, Log4j-verbindingen opstarten als een vorm van stressbeheersing. Dankzij dit type beveiliging kunnen beheerders gecompromitteerde systemen afsluiten en in bedwang houden totdat de kwetsbaarheid is gepatcht.

Web Application Firewall

WAF's zijn bewezen geweldige beschermende software die effectief pogingen blokkeert om met diensten en apps te communiceren die door het Log4j-kwetsbaarheid getroffen zijn. Kortom, niet-verborgen strings, evenals die met eenvoudige ontwijkingstechnieken, moeten door een bekwame WAF gemakkelijk kunnen worden tegengehouden. Zoals onderzoekers echter hebben opgemerkt, passen bedreigers hun gebruik van de Log4j-taal steeds meer aan om sleutelreeksen op te nemen die zijn gecodeerd om detectie te omzeilen door gebruik te maken van complexere lookups om kritieke reeksen te verhullen. Beveiligingsteams moeten hun WAF-regels zorgvuldig ontwikkelen om deze versluierde strings te identificeren en te blokkeren, zodat pogingen om vitale systemen uit te buiten, worden voorkomen.

Monitoren en rapporteren

Verscheidene veiligheidsagentschappen hebben gemeld dat het aantal actieve scans voor kwetsbare Log4j-systemen nog nooit zo hoog is geweest. Wat de zaak nog erger maakt, zijn aanwijzingen dat bepaalde landen bedreigers steunen, aangezien de aanvallen blijven evolueren. Het actief monitoren van je infrastructuur om niet alleen kwetsbare systemen en apps te identificeren, maar ook om de gezondheid van devices te beoordelen, is van cruciaal belang om de beveiligingspositie van je organisatie te beschermen. Bovendien krijgen beheerders bij het beoordelen van rapporten over belangrijke indicatoren van compromittering, zoals hashes van de Log4Shell-robot, noodzakelijke informatie over bedreigingen om beveiligingen zoals WAF's aan te passen en aanhoudende risico's te beperken.