Nu pas begint het Log4j-securitydrama

De kritieke kwetsbaarheid in Log4j is een week geleden openbaar gemaakt en daarmee is de beheernachtmerrie van het Log4Shell-gat begonnen. In de loop van de week zijn er nog wat scheppen bovenop de ramp gedaan. Zo is de initieel uitgebrachte patch niet afdoende geweest, waardoor een tweede spoedpatch nodig is. Verder is gebleken, schrijft AG Connect, dat al zeker vanaf 1 december misbruik van dat wijdverbreide gat is gemaakt. En een officieel beveiligingsbulletin blijkt onjuiste - en gevaarlijke - informatie te geven.

Gevonden gat
Log4j is een loggingtool geschreven in Java die verwerkt is in heel veel softwarepakketten en hardware-appliciances van veel verschillende leveranciers. Het gevonden gat maakt het voor aanvallers mogelijk om op afstand en zonder authenticatie eigen code uit te voeren (remote code execution, RCE) op kwetsbare systemen.

 

Geen soepel proces
Week één van dit securitydrama zit er nu op. Maar daarmee is die verse beveiligingsaffaire nog niet voorbij. Volgens kenners is het zelfs nog lang niet voorbij. Want net zoals met eerdere grote rampen op ICT-beveiligingsgebied is lang niet iedereen gepatched. Ook nu misschien nog niet. Of ze zijn slechts deels gepatched en dus slecht gepatched. Dat patchen is namelijk geen soepel proces geweest. (Net zoals bij eerdere grote securityrampen.)

Drie complicaties bij patchen
In het huidige geval van Log4j is de standaardcomplexiteit van patchen nog wat verder verhoogd door drie factoren. De eerste is het feit dat Log4j niet altijd bekend is bij gebruikende bedrijven en organisaties. De Java-tool zit namelijk ook verwerkt in vele verschillende producten van diverse leveranciers. Techbedrijven die zelf ook niet altijd weten óf ze Log4j gebruiken en als ze dat doen met welke versie dan.

 

Haastig updaten
De tweede complicerende factor is de kwestie van versies. De oudere 1.x-reeks van Log4j is níet vatbaar voor de kritieke kwetsbaarheid die vorige week is geopenbaard. De nieuwere 2.x-reeks is dat wel. De derde complicerende factor in het patchen van Log4j is dat de initieel uitgebrachte patch niet helemaal afdoende is gebleken. Haastig updaten naar Log4j-versie 2.15 heeft het securityprobleem van Log4Shell dus niet helemaal weggenomen. Net zomin als het uitvoeren van de initieel aangedragen beperkingsmaatregelen (mitigations). Sommige configuraties zijn ook met die patch nog vatbaar voor Log4Shell.

 

Patch brengt nieuw probleem

Erger nog: halverwege afgelopen week is gebleken dat de 2.15-patch zelf ook een kwetsbaarheid bevat. Een nieuwe, andere kwetsbaarheid. Deze is gelukkig iets minder ernstig dan Log4Shell. In plaats van de mogelijkheid voor aanvallers om eigen code uit te voeren op kwetsbare systemen, geeft 2.15 de mogelijkheid om met een DDoS-aanval systemen plat te leggen. Minder ernstig, maar nog steeds ernstig.

 

Exfiltratie van data
Maar dat is nog niet alles. De 2.15-patch blijkt óók nog een ernstigere kwetsbaarheid met zich mee te brengen. Namelijk een fout waardoor kwaadwillenden data kunnen downloaden van kwetsbare servers. Exfiltratie van data is onder bepaalde omstandigheden mogelijk, zo wisten security-onderzoekers woensdag te melden.

Ontdoen van functionaliteit
Dus wordt er dringend geadviseerd om te updaten - voor sommigen dus nogmaals te updaten - naar de gauw uitgebrachte nieuwe patch: versie 2.16. Die lost de Log4Shell-kwetsbaarheid wel degelijk op, door de softwarecode geheel te ontdoen van de functionaliteit die op afstand valt te misbruiken. Een drastische maatregel? Misschien, maar het is dan ook een zeer ernstige securityzaak.

 

Aanvallen ondernomen
Ondertussen zijn er sinds vorige week vrijdag scans uitgevoerd, exploitcodes ingezet, aanvallen ondernomen en penetraties geslaagd. Deze offensieve processen zijn nu nog gaande en kunnen naar verwachting nog wel een tijd aanhouden. Mogelijk zijn kwaadwillenden al binnengekomen, en houden ze zich nu even koest.

Erg aantrekkelijk
Log4Shell is namelijk erg aantrekkelijk voor kwaadwillenden van alle soorten en maten. Het gevaar dat in Log4j schuilt heeft wel wat gemeen met het wijdverbreide gebruik van die software zelf. Net zoals de loggingtool in vele verschillende ICT-systemen zit, zo valt het gat daarin op vele verschillende manier te misbruiken. Doordat het om loggingsoftware gaat, vallen zogeheten payloads op uiteenlopende manieren ‘af te vuren’.

 

Detectie van payloads
Alle input die binnenkomt op een systeem en daar door Log4j gelogd wordt, kan dus ‘een kogel’ zijn. Een GET-verzoek, een User-Agent voor een browser, enzovoorts. Detectie van payloads wordt nog wat bemoeilijkt doordat ze ‘genesteld’ kunnen zijn. De creativiteit van cybercriminelen zou je als indrukwekkend kunnen beschouwen.

 

'In the wild'
Hetzelfde geldt voor de snelheid waarmee misbruik op gang is gekomen. Dat is gebeurd na de publieke onthulling van de kritieke kwetsbaarheid vorige week vrijdg. Dat betekent echter niet dat misbruik toen pas is gepleegd. Nee, de CEO van Cloudflare wist vorige week zaterdag al te melden dat terugblikkend met Log4Shell-kennis van nu het eerste geval van een Log4j-exploit ‘in the wild’ op 1 december was.

Wacht blijven houden
Securityprofessionals en -leveranciers maken zich zorgen over eventuele kwaadwillenden die al binnen zijn en zich nu koest houden. Ze zijn bang dat bedrijven en organisaties die niet supersnel en waakzaam waren nu aan patchen toekomen en denken dat ze de dans ontsprongen zijn. Een interne scan kan het sein groen geven wat betreft actieve malware of verdachte gedragingen, maar ‘slapende’ backdoors kunnen onder de radar blijven.

 

Niet sluitend
Bovendien worstelen zowel ict-gebruikende bedrijven en organisaties als ook ICT-leverende bedrijven nog met de inventaris. Waar draait Log4j, en in welke versie? Het simpelweg controleren of je organisatie Java gebruikt, is geen sluitende controle. Het nalopen en patchen van een eventuele Apache-webserver geeft ook geen afsluiting. Want Log4j zit ‘verscholen’ in vele, vele verschillende techproducten; zowel software als hardware. En dat dan van vele, vele verschillende leveranciers.

 

Monitoringsoftware
Zoals bijvoorbeeld in netwerkapparatuur, WebEx-servers en voice-systemen van Cisco. En in opslagsystemen en monitoringsoftware van NetApp. En in producten van onder meer Atlassian, APC, Broadcom, Check Point, Citrix, Commvault, Dell/EMC, Fortinet, Huawei, IBM, Ivanti, Jamf Nation, JetBrains, Kaseya, McAfee, Microsoft, MongoDB, Nutanix, Okta, Oracle, Palo Alto Networks, Pulse Secure, QlikTech International, Red Hat, RSA, SonicWall, Sophos, Splunk, Trend Micro, Veaam, VMware.

NCSC oogst lof
De lijst is lang en wordt langer. Het Nationaal Cyber Security Centrum (NCSC) van de Nederlandse overheid houdt deze lijst letterlijk bij. Het cybersecurity-orgaan van ons land heeft internationaal lof geoogst met het begin deze week openbaar publiceren van de lijst met hackbare software door het grote gat in Log4j. Het NSCS heeft toen gelijk al aangegeven dat de lijst "nog lang niet volledig" is. En daarbij beloofd het overzicht aan te vullen, bij te werken én te voorzien van aanvullende informatie over mitigations.

 

Cynische reactie
Eenzelfde Herculestaak ondernemen de diverse leveranciers, maar dan dus intern voor hun eigen producten. Zie bijvoorbeeld IBM, die vrij snel na ‘D-Day’ voor Log4j meldde dat het inventaris opmaakt van zijn producten en systemen die mogelijk geraakt worden door Log4j. Waarop de cynische reactie van een security-expert komt dat de ict-leverancier een software-inventarisatieproduct zou moeten maken.

 

Eerste security-bulletin
Vier dagen na de openbaarmaking van het Log4Shell-gat weet IBM zijn eerste kwetsbare product aan te wijzen, klaagt diezelfde expert nog. IBM’s eerste security-bulletin over Log4Shell vindbaar op zijn publieke PSIRT-blogsite (Product Security Incident Response Team) stamt inderdaad van 13 december. In de loop van de week is een ware stortvloed aan bulletins van IBM losgekomen: over meerdere en uiteenlopende producten met Log4j, die patches of mitigations krijgen.

Nieuw, oud en onveilig
Overigens heeft IBM op 29 november al een waarschuwing afgegeven voor een product met een Log4j-kwetsbaarheid van kritieke ernst. Dat betreft echter een Log4j-gat dat stamt uit 2019. Datzelfde gat (CVE-2019-17571) heeft in maart dit jaar nog exploitcode gekregen, die sommige mensen nu heeft doen denken dat Log4Shell minstens negen maanden oud is. Dat is echter niet het geval.

 

Soortgelijke timing
Bovenstaande korte schets van inventaris, ontdekking en publicatie door IBM is geenszins uniek voor die techleverancier. Vele andere ict-bedrijven, inclusief aanbieders van securityproducten, doorlopen een soortgelijk proces met ook soortgelijke timing. Deze moeizame onderneming van asset management, wat bij ICT-gebruikende organisaties vaak ook onderbelicht is, moet een brede blik hebben. En kan dan onaangename verrassingen opleveren.

 

ColdFusion
Zo bevat de 2021-versie van Adobe webapp-ontwikkelplatform ColdFusion een kwetsbare versie van Log4j; de oudere 2.13.3-release. Maar dat is nog niet alles. Deze ColdFusion-versie die in november vorig jaar is uitgebracht, draagt nóg een Log4j-versie in zich: de antieke 1.2.17-release. Adobe zelf geeft dit ook aan in zijn securitybulletin over de kwetsbaarheid in Log4j. De 2.13.3-versie wordt geraakt door Log4Shell, terwijl de 1.2-versie niet wordt geraakt, merkt de softwareleverancier daar op. Technisch gezien is dat correct. De ontwikkelaars van de nu gevaarlijk gebleken loggingtool merken dit zelf ook op in hun bulletin over het grote beveiligingsgat.

 

Minder grote ernst
Net zoals de hierboven genoemde ontdekkingstocht van IBM niet uniek is, geldt dat ook voor het ‘retrogebruik’ van Adobe. De CI/CD-software (continuous integration / continuous development) TeamCity van JetBrains blijkt ook nog Log4j 1.2 te gebruiken. Die dus niet kwetsbaar is voor Log4Shell. Maar, zo geeft leverancier JetBrains aan, die versie bevat wel een bekende oude kwetsbaarheid, die van 'minder grote ernst' is.

Oud, antiek en support

Puntje van aandacht hierbij is dat de 1.x-reeks van Log4j sinds 2012 geen nieuwe release meer heeft gehad. De software krijgt al jaren geen support meer. Wat ook wordt aangestipt door de ontwikkelaars zelf in hun bulletin over Log4Shell. “Merk aub op dat Log4j 1.x zijn end-of-life heeft bereikt en niet langer wordt ondersteund. Kwetsbaarheden die zijn gemeld na augustus 2015 in Log4j 1.x zijn niet bekeken en zullen niet worden gefixed. Gebruikers moeten upgraden naar Log4j 2 om securityfixes te verkrijgen.” AG Connect heeft vragen uitgezet bij de ontwikkelaars hoe ze dan weten dat 1.x niet ook een gevaar vormt, zeker nu vele ogen gericht zijn op die wijdverbreide loggingtool.

Waarschuwing
Ongeacht of kwaadwillenden nu ook antieke Log4j-versies doorspitten, is het gevaar groot en voorlopig niet voorbij. Het NCSC en het Digital Trust Center van de Nederlandse overheid hebben - net zoals evenknieën in andere landen - begin deze week al gewaarschuwd dat bedrijven, organisaties en overheden zich moeten voorbereiden op actief misbruik. Diverse security- en cloudbedrijven hebben in de loop van de week weten te rapporteren dat massale aanvallen door cybercriminelen en ook gerichte aanvallen door statelijke actoren op gang zijn gekomen.

 

Opportunistische cybercriminelen
Bij laatstgenoemde worden ‘bekende verdachten’ genoemd: China, Noord-Korea, Iran, Rusland, Turkije. Mogelijk dat het niet in al die gevallen gaat om hacks uitgevoerd door overheidsinstanties of legeronderdelen van die landen. Het kunnen ook simpelweg opportunistische cybercriminelen zijn die vanuit of via die landen hun werkzaamheden uitvoeren.

Desinformatie over JRE
Bovenop de stortvloed aan informatie over de kwetsbaarheid, de eerste patch, nieuwe misbruikmogelijkheden, aanvallers, types aanvallen, enzovoorts is er nog het gevaar van desinformatie gekomen. Het gaat hierbij nu niet om misleidende of onjuiste informatie die met opzet is gecommuniceerd. Maar het gaat wel om verkeerde informatie, die daardoor gevaarlijk kan zijn.

 

Foute Apache-mededeling
Het officiële CVE-bulletin (Common Vulnerabilities and Exposures) van de Amerikaanse National Vulnerability Database, bijgehouden door non-profit The Mitre Corporation, heeft een tijdje vermeld dat up-to-date zijn met de huidige versie van de Java Runtime Environment (JRE) beschermt tegen Log4Shell. Dat is echter niet zo. Deze onjuiste informatie is schijnbaar afkomstig van een foute Apache-mededeling, die later wel is gecorrigeerd. Alleen is die broninformatie toch enige tijd als de ‘canonieke waarheid’ gezien? Ironisch wel, dit blind overnemen en afhankelijkheden van informatie over blind overgenomen software en dependancies.

 

Dit bericht komt van AG Connect.