Log4j-kwetsbaarheden blijven bestaan ​​— bent u voorbereid?

De wijdverbreide kwetsbaarheid die voor het eerst verscheen in Apache Log4j in 2021 zullen blijven worden uitgebuit, mogelijk zelfs op slechtere manieren dan we tot nu toe hebben gezien. Het zorgwekkendere aspect van deze bedreigingen is dat er een goede kans is dat ze maanden of jaren in de toekomst zullen blijven worden uitgebuit.

De Cyber ​​Safety Review-raad van het Department of Homeland Security debuteerde in 2021 en bracht in 2022 zijn eerste veiligheidsrapport (PDF). Daarin noemde het bestuur Log4j een "endemische kwetsbaarheid", voornamelijk omdat er geen uitgebreide "klantenlijst" voor Log4j is, waardoor het bijhouden van kwetsbaarheden een bijna onmogelijke taak is. Een federale kabinetsafdeling besteedde zelfs 33,000 uur aan zijn Log4j-reactie.

En veel organisaties en beveiligingsoplossingen op de markt slagen er niet in het verschil te identificeren tussen exploiteerbaarheid en kwetsbaarheid, waardoor aanvallers de kans krijgen om kwaadaardige activiteiten uit te voeren.

Exploitatie versus kwetsbaarheid

Een van de belangrijkste problemen met cyberbeveiliging vandaag is het begrijpen van het verschil tussen kwetsbaarheden en hun ernst. Als het gaat om het meten van exploitability versus een kwetsbaarheid, is er een groot verschil tussen of een beveiligingsdreiging binnen uw bedrijf kan worden misbruikt of dat het gewoon "kwetsbaar" is en het bedrijf niet kan hinderen of een kritieke asset kan bereiken. Beveiligingsteams besteden te veel tijd aan het niet begrijpen van het verschil tussen de twee en het oplossen van elke kwetsbaarheid zoals die zich voordoet, in plaats van prioriteit te geven aan de kwetsbaarheden.

Elk bedrijf heeft duizenden veelvoorkomende kwetsbaarheden en blootstellingen (CVE's), waarvan vele hoog scoren op het Common Vulnerability Scoring System (CVSS), dus het is onmogelijk om ze allemaal op te lossen. Om dit tegen te gaan, is de hoop dat tools voor risicogebaseerd kwetsbaarheidsbeheer (RBVM) dat zullen doen prioritering gemakkelijker maken door te verduidelijken wat exploiteerbaar is.

Benaderingen voor beveiligingsprioritering die CVSS-scores combineren met RBVM-dreigingsinformatie leveren echter geen optimale resultaten op. Zelfs na het filteren en kijken naar wat er in het wild kan worden misbruikt, hebben beveiligingsteams nog steeds te veel te doen omdat de lijst lang en onhandelbaar is. En alleen omdat een CVE vandaag geen exploit heeft, wil nog niet zeggen dat er volgende week geen exploit zal zijn.

Als reactie hierop hebben bedrijven voorspellende risico-AI toegevoegd, die gebruikers kan helpen te begrijpen of een CVE in de toekomst zou kunnen worden misbruikt. Dit is nog steeds niet genoeg en leidt tot te veel problemen om op te lossen. Duizenden kwetsbaarheden zullen nog steeds een exploit blijken te hebben, maar velen zullen andere voorwaarden hebben waaraan moet worden voldaan om het probleem daadwerkelijk te exploiteren.

Bij Log4j moeten bijvoorbeeld de volgende parameters worden geïdentificeerd:

• Bestaat de kwetsbare Log4j-bibliotheek?
• Wordt het geladen door een actieve Java-toepassing?
• Is de JNDI-zoekopdracht ingeschakeld?
• Luistert Java naar externe verbindingen en is er een verbinding voor andere machines?

Als niet aan de voorwaarden en parameters wordt voldaan, is de kwetsbaarheid niet kritiek en moet deze geen prioriteit krijgen. En zelfs als een kwetsbaarheid misbruikt zou kunnen worden op een machine, wat dan nog? Is die machine extreem kritiek of is deze misschien niet verbonden met kritieke of gevoelige bedrijfsmiddelen?

Het is ook mogelijk dat de machine niet belangrijk is, maar een aanvaller in staat stelt om op heimelijkere manieren door te gaan naar kritieke bedrijfsmiddelen. Met andere woorden, context is de sleutel: bevindt deze kwetsbaarheid zich op een potentieel aanvalspad naar de kritieke asset? Is het voldoende om een ​​kwetsbaarheid af te sluiten bij een knelpunt (een kruising van meerdere aanvalspaden) om te voorkomen dat het aanvalspad een kritieke asset bereikt?

Beveiligingsteams hebben een hekel aan kwetsbaarheidsprocessen en hun oplossingen, omdat er steeds meer kwetsbaarheden zijn - niemand kan ooit de lei volledig schoonvegen. Maar als ze kunnen focus op wat kan creëren schade tot een cruciaal bezit, kunnen ze beter begrijpen waar ze moeten beginnen.

Bestrijding van Log4j-kwetsbaarheden

Het goede nieuws is dat goed beheer van kwetsbaarheden kan helpen de blootstelling aan op Log4j gerichte aanvallen te verminderen en te herstellen door vast te stellen waar het risico van mogelijke uitbuiting bestaat.

Kwetsbaarheidsbeheer is een belangrijk aspect van cyberbeveiliging en is noodzakelijk om de veiligheid en integriteit van systemen en gegevens te waarborgen. Het is echter geen perfect proces en er kunnen nog steeds kwetsbaarheden in systemen aanwezig zijn, ondanks de inspanningen om ze te identificeren en te beperken. Het is belangrijk om processen en strategieën voor kwetsbaarheidsbeheer regelmatig te herzien en bij te werken om ervoor te zorgen dat ze effectief zijn en dat kwetsbaarheden tijdig worden aangepakt.

De focus van het beheer van kwetsbaarheden moet niet alleen op de kwetsbaarheden zelf liggen, maar ook op het potentiële risico van uitbuiting. Het is belangrijk om de punten te identificeren waar een aanvaller mogelijk toegang tot het netwerk heeft gekregen, evenals de paden die ze kunnen nemen om kritieke bedrijfsmiddelen te compromitteren. De meest efficiënte en kosteneffectieve manier om de risico's van een bepaalde kwetsbaarheid te beperken, is het identificeren van de verbanden tussen kwetsbaarheden, verkeerde configuraties en gebruikersgedrag dat door een aanvaller kan worden misbruikt, en deze problemen proactief aan te pakken voordat de kwetsbaarheid wordt misbruikt. Dit kan helpen om de aanval te verstoren en schade aan het systeem te voorkomen.

Je moet ook het volgende doen:

• patch: Identificeer al uw producten die kwetsbaar zijn voor Log4j. Dit kan handmatig of door gebruik te maken van open source scanners. Als er een relevante patch wordt uitgebracht voor een van uw kwetsbare producten, patch het systeem dan zo snel mogelijk.
• Oplossing: Stel op Log4j-versies 2.10.0 en hoger in de Java CMD-regel het volgende in: log4j2.formatMsgNoLookups=true
• Blok: Voeg indien mogelijk een regel toe aan uw webtoepassingsfirewall om te blokkeren: "jndi:"

Perfecte beveiliging is een onhaalbare prestatie, dus het heeft geen zin om perfectie de vijand van het goede te maken. Richt u in plaats daarvan op het prioriteren en blokkeren van potentiële aanvalspaden die de beveiligingsstatus voortdurend verbeteren. Identificeren en realistisch zijn over wat werkelijk kwetsbaar is versus wat exploiteerbaar is, kan hierbij helpen, omdat het de mogelijkheid biedt om middelen strategisch te sluizen naar kritieke gebieden die er het meest toe doen.

• Door SEO aangedreven content en PR-distributie. Word vandaag nog versterkt.
• Platoblockchain. Web3 Metaverse Intelligentie. Kennis versterkt. Toegang hier.
• Bron: https://www.darkreading.com/attacks-breaches/log4j-vulnerabilities-are-here-to-stay-are-you-prepared-