CorpoNet informatiesessie kwetsbaarheid Log4j

KennisBite special | 16 december 2021
Apache Log4j kwetsbaarheid, we houden elkaar up to date!
Presentatie: SIG Security bijgestaan door Marc Both (Mostware) en alle deelnemers

Vanwege de recent geconstateerde kwetsbaarheid in Apache Log4j organiseerde CorpoNet op 16 december een KennisBite waarin we de kennis tot dan toe konden delen. Leens Spaans (Woonforte) en Albert van Heugten (Wonen Zuid) beide lid van SIG Security bijgestaan door Marc Both van Mostware en verder alle deelnemers, gaven invulling aan deze KennisBite. Hieronder lees je het verslag.

Marc Both start met het delen van zijn kennis over deze software, wat het doet en hoe we met de kwetsbaarheid moeten omgaan.

Wat doet Log4j eigenlijk?
Het logt gebeurtenissen. Handig bij het ontwikkelen van software, op het moment dat je wilt testen kun je met Log4j precies zien wat er gebeurt. Welke acties worden er uitgevoerd, welke gaan goed en welke fout en wat is daarop het vervolg.
Wat is er nou fout gegaan in deze software, waardoor we nu spreken van een ernstige kwetsbaarheid? Log4j zou normaliter alleen moet loggen, dus de actie(s) registreren en klaar, maar Log4j is de regels die geschreven zijn om te loggen gaan beschouwen als commando’s. Voorbeeld: op jouw website staat een chatbot voor klantcontacten. Om de kwaliteit van deze chatbot te volgen gebuikt je Log4j, die logt alle entries die gegeven worden en je ziet of het (goed) werkt. Maar wat gebeurt er nou als een gebruiker van de chatbot een stukje malafide code of link naar een malafide webserver in de chat plaatst? Log4j ziet dat als een opdracht en voert de code uit, waardoor er dus toegang verkregen kan worden tot jouw server waar bijvoorbeeld het ERP of intranet op draait. Dus, omdat Log4j niet alleen registreert maar ook opdrachten uitvoert is er nu sprake van die kwetsbaarheid. En de toevoeging serieus is vanwege het feit dat Java zo ongelofelijk veel gebruikt wordt.
Afgelopen weekend hebben heel veel grote providers zoals Citrix, Cisco, Linux, Microsoft, VMware, geïnventariseerd op het gebruik van Log4j, maar zelfs deze grote leveranciers waar veel kennis in huis is, weten nog steeds niet de volle omvang in te schatten. Het is een zo veelvuldig ingezette tool, die wellicht toch nog ergens diep weg in gebruik is. Dus zomaar zeggen, dit raakt ons niet lijkt vooralsnog naïef.

Hoe kon dit gebeuren?
Java en ook Log4j is een open source platform, iedereen kan er input op leveren en iedereen kan het gebruiken. Log4j is door een relatief klein team ontwikkeld en omdat het niet lang doorontwikkeld is (kwestie van geld) zijn er geen security-updates geweest en dat is de angel in deze kwestie. Waarbij de kans groot is dat deze kwetsbaarheid al jaren heeft bestaan. Het voordeel van een open platform is dat vanwege de hoeveelheid gebruikers, een eventueel lek snel opgemerkt wordt. Maar glipt er eentje doorheen, dan hebben dus heel veel gebruikers een probleem.
Afijn problemen zijn er om opgelost te worden en hoe pak je dat in dit geval aan?
We kunnen uit het voorgaande opmaken dat Log4j op vele plekken in het systeem kan zitten, focus is dus belangrijk. Die focus leg je in eerste instantie op die plekken waar je software extern toegankelijk is. Daar is kwetsbaarheid het meest gevaarlijk. Bijvoorbeeld het boekhoudpakket, een SaaS-applicatie waarbij je remote kunt inloggen. Je werknemers kunnen dat, maar hackers dus ook. Is het intranet volledig intern, dan heeft dat niet die eerste focus.
Woningcorporaties hebben veel IT uitbesteed en dus van hun leveranciers gehoord welke stappen zij hebben ondernomen. Er blijft echter altijd een eigen verantwoordelijkheid. Wees ook vooral alert op wat kleinere legacy software die niet meer actief beheerd wordt, maar die wel kwetsbaar kan zijn als daarin gebruik wordt gemaakt van Log4j. End of life software die toch nog ergens gebruikt wordt. Kennis hierop delen is zeer welkom.

Er wordt heel breed gewaarschuwd voor toekomstige cyber-aanvallen, waarbij ransomware ingezet wordt. Maar als we nu alles gecheckt hebben, alle patches en updates gedraaid hebben, dan zijn we toch veilig? Nou legt Marc uit, stel dat jij inderdaad op maandag alles ‘gedicht’ hebt, maar dat de hacker op zondagmiddag al een achterdeurtje heeft opengezet. Daar zit het risico!
Wat nu te doen? Behalve achter je softwareleverancier aanjagen en die op zijn verantwoordelijkheid wijzen. Defence in depth, een gelaagde security aanpak, is hierbij een goede strategie. Waarbij je naast het feit dat je zorgt dat mensen niet van buiten naar binnen kunnen komen (firewall), ook zorgt dat al je onderliggende componenten aan de binnenkant up to date zijn. Monitoring is ingesteld, gebruikers identiteiten zijn beschermd met multifactorauthenticatie en uiteraard een goede back-up en recovery strategie. Nu je er bijna wel vanuit kunt gaan dat je een keer aangevallen wordt, ligt de focus dus op een snel herstel, dat je zo snel mogelijk weer up and running bent.

Albert vult Marcs verhaal graag aan; op dit moment lijkt het qua aanvallen op woningcorporaties mee te vallen. Maar laten we niet te vroeg juichen het kan zomaar omslaan. VNG adviseert gemeenten te overwegen of een systeem al dan niet tijdelijk uitgezet kan worden. Albert kan zich dat bij woningcorporaties niet voorstellen. Stel dat je dat doet, we werken tegenwoordig vaak vanuit huis veelal met SaaS-applicaties, als je dan de boel uitzet, zet je als het ware een slot op je bedrijfsvoering. Dus naast het betoog van Marc, wil Albert benadrukken dat de deelnemers van deze KennisBite, veelal informatiemanager en/of security officer, ook zelf een verantwoordelijkheid hebben. Volgens Albert kunnen we niet op onze handen gaan zitten en het vervolgens aan onze leveranciers of infra-partner overlaten. Wij casu quo onze bestuurders dragen de verantwoordelijkheid. Hoe vul je dat goed in? Door, als je dat nog niet gedaan had is nu hét moment, je assets in beeld te brengen. Wat heb ik? Met welk doel heb ik dat? Denk niet alleen aan je productieomgeving – maar check ook de test- en acceptatie omgeving of sandboxing systemen.
Want het maakt niet uit hoe ze binnenkomen, binnen = binnen. Heb je nog ergens een servertje snorren met een verouderde applicatie die al jaren niet meer geüpdatet is, dan is dat een risicovolle plek.
Nadat je alles in beeld hebt gebracht volgt het proces van classificatie (van buiten naar binnen), wat heb ik openstaan naar het internet en wat staat er intern open? Welke diensten lever je via het internet? Vandaaruit kijk in hoeverre de genoemde kwetsbaarheid een rol speelt. De lijst zoals gepubliceerd op NCSC (https://www.ncsc.nl/onderwerpen/log4j) helpt hierbij, maar Albert doet namens CorpoNet ook een oproep om als woningcorporaties een eigen lijst bij te gaan houden, kennis delen dus.

Inventariseren – segmenteren – prioriteren -> van buiten naar binnen, informeer je omgeving, rapporteer ook aan de bestuurders, laat dit niet op je eigen schouders liggen en zorg dat je medestanders organiseert. Denk aan concern control, andere partijen in je eigen organisatie zoals communicatie. Zie het als een oorlog, is de conclusie van Albert. En misschien denk je als lezer nu ‘tja … oorlog..?’, maar als je leest hoe groot de invloed van cybercriminaliteit nu al is en hoe snel het toeneemt, kun je inderdaad spreken van oorlogsvoering. Weliswaar tegen een ‘onzichtbare’ vijand, maar toch een gevaarlijk en geducht tegenstander. Waarbij vooral menselijk vernuft het beste antidote lijkt te zijn. Nogmaals samenwerken en de kennis met elkaar delen, maakt ons weerbaarder. Dit doe je niet alleen.

Leen is het zeker eens met het verhaal van beide voorgangers en meldt zelf dat in zijn navraagronde bij leveranciers hem opviel dat niet iedereen er even alert in stond als hij had verwacht. Zeker een grotere leverancier in de corporatiesector stelde zich enigszins superieur op met een houding van ‘zo’n vaart loopt dit bij ons niet’. Via de schermen zien we veel instemmend geknik. Ook anderen delen deze ervaring. En als je nu in het team Apache Log4j kwetsbaarheid (zie onderaan meer info) kijkt bij de leveranciers verklaringen dan lijkt het inderdaad zo dat deze ernstige kwetsbaarheid de corporatiesector niet lijkt te raken. Is dit onwetendheid? Hoe dan ook in veel gevallen lijkt het op het vlak van communicatie in ieder geval beter te kunnen.
Leen vraagt nog even aan Marc hoe hij hier tegenaan kijkt. Kunnen de leveranciers gelijk hebben? Dat zou kunnen zegt Marc. Draait alles bij jou volledig in de Microsoft Cloud dan is je kwetsbaarheid behoorlijk beperkt. Heb je geen applicaties die op Java draaien ook dan neemt de kwetsbaarheid af. Dus het is mogelijk dat een leverancier terecht meent onkwetsbaar te zijn, als daar een hele duidelijke strategie van ontwikkelen onder ligt en waar ze dat in doen. Maar kritisch zijn en doorvragen, is beslist geen gek idee. We zien nog steeds dat leveranciers ontdekken dat ze alsnog kwetsbaar zijn. Dus vraag het regelmatig na!

Sander Beukers (Woonwaard) die vanaf het eerste moment dit CorpoNet initiatief welkom heette, beaamt dat zelf de regie pakken echt noodzakelijk is. Hij noemt een voorbeeld van Ricoh-printers die op Java draaien, waarvan niet zeker is dat zich daar een kwetsbaarheid voordoet, maar wat ook niet getest is en die door de leverancier niet aangemerkt werden als een mogelijk zwakke schakel. Ook in de keten kan een zwakke schakel zitten. Stel je ontvangt een reparatieverzoek-intake die doorschiet naar een systeem van een partner die kwetsbaar is dan ben jij op dat moment dus ook kwetsbaar.

In de chat deelt Sander nog deze twee tips:
• Wellicht nog nuttig om eventuele consequenties te benoemen als je wél geraakt wordt. Er wordt voornamelijk malware gedetecteerd die cryptominers installeren (te zien aan hoog CPU gebruik) en
ransomware. In het laatste geval moet je ook rekening houden met het risico op encryptie van live backup. Het NCSC adviseert daarom om je backups ook offline te bewaren!
• Hou ook rekening met het risico dat toeleveranciers geraakt worden wat tot leveringzekerheidsrisico’s leidt. Houd dus ook rekening met partners om je heen en wat het zou betekenen als zij niet meer kunnen leveren. Om die reden is ons crisisteam breder dan alleen IT, maar is ook inkoop, communicatie en concern control betrokken.

Vraag van een andere deelnemer: Er zijn leveranciers die menen niet kwetsbaar te zijn omdat ze versie 1.0 gebruiken. Hoe zit dat?
Marc Both: versie 1.0 is al een hele tijd end-of-life (sinds 2015) daar zitten ongetwijfeld kwetsbaarheden in maar die halen het nieuws niet meer. Net als de kwetsbaarheden van Windows XP niet meer in het nieuws komen. Kortom met versie 1.0 ben je ook kwetsbaar! Mogelijk anders dan nu bij versie 2, maar kwetsbaar.
Zie ook de afbeelding hieronder (bron: https://www.ncsc.nl/onderwerpen/log4j)

Een terechte vraag van een van de deelnemers: Hebben wij eigenlijk technische mogelijkheden om externen te controleren?
Marc: Ja er is wel tooling om te controleren, maar die is ontwikkeld en bedoeld voor beheerders, die aan de backend net wat meer kunnen zien zodat testen zin heeft. Voor de eindgebruiker, die hele beperkte toegang heeft is deze tooling weinig zinvol om te kunnen testen of je kwetsbaar bent. Met humor schetst Marc een eenvoudige mogelijkheid voor de eindgebruiker: maak gebruik van de kwetsbaarheid om de kwetsbaarheid aan te tonen. Later heeft Marc ons getipt met de Huntress Log4Shell Vulnerability Tester, zie hier.

Komen we tot de conclusie dat…
Je altijd zelf alert moet blijven, je kennis moet delen (inside – out) en je steeds maar weer moet updaten, updaten en updaten!
Vanaf 16 december is er bij CorpoNet een team gestart om hierin actief onze kennis met elkaar te delen. Uiteraard zijn vragen ook welkom. Via info@corponet.nl kunnen leden van CorpoNet toegang aanvragen tot dit team.

Op de hoogte blijven van de meest recente ontwikkelingen?
Informatie over te nemen maatregelen: NCSC Log4j
Informatie over beveiligingsupdates, betrokken applicaties en IoC’s: NCSC GitHub
Vragen en Antwoorden Log4j-Informatiesessie: Log4j webinar – Vragen en Antwoorden
Notificaties van Log4j-updates ontvangen en in gesprek met andere IT-professionals: DTC Community

Terugkijken van de NCSC IT-informatiesessie over de Log4j-kwetsbaarheid op woensdag 15 december kan hier: https://live.dutchwebinar.com/itinformatiesessielog4j

 

Zoeken

Meest recente verslagen

Meld je aan voor de Blik op de agenda

We sturen je maandelijks een overzicht van de nieuw ingeplande KennisBites. Zo mis je niks!