Beheer

Security
vuurwerk

Waarom Log4j nog een eindejaarspatch heeft gekregen

Geclaimd gat in Log4j valt ook langs andere weg te misbruiken.

© CC0 - Unsplash.com Jingda Chen
5 januari 2022

Geclaimd gat in Log4j valt ook langs andere weg te misbruiken.

Vlak voor oudjaar heeft de geplaagde loggingtool Log4j nog een update gekregen. Ditmaal voor een geclaimde kwetsbaarheid waarlangs aanvallers eigen code kunnen uitvoeren. De ernst van dit gat wordt echter betwist, omdat het alleen valt te misbruiken als er al sprake is van een hack. Toch is deze kwestie een CVE-nummer en 'oudejaarspatch' waard, oordelen de Log4j-ontwikkelaars. Misbruik is namelijk ook langs indirecte weg te plegen. AG Connect krijgt uitleg vanuit het verantwoordelijke Apache-projectteam.

De roerige patchtijden voor loggingtool Log4j zijn tussen kerst en de jaarwisseling nog wat extra onrustig geworden door de plotse claim van wéér een kritiek beveiligingsgat. Een security-onderzoeker claimde een gat waarlangs op afstand kwaadaardige code kon worden uitgevoerd. En dat niet in een van de oudere releases van Log4j of in één van de haastig uitgebrachte recente patches, maar in de meest actuele 2.17.0-versie.

Wel/niet serieus gat

De soep werd gelukkig niet zo heet gegeten: het geclaimde nieuwe beveiligingsgat had namelijk een behoorlijke beperking. Kwaadwillenden die misbruik willen maken van deze nieuwste kwetsbaarheid in Log4j, moeten dat doen door een configuratiebestand voor de loggingtool te wijzigen. Daarvoor hebben aanvallers dus al bepaalde permissies, rechten, toegang nodig op het aan te vallen systeem. En dat suggereert dat er dus al succesvol gehackt is.

Terwijl de discussie onder security-experts losbarstte over wel/geen serieuze aard van het geclaimde gat vond het Apache-projectteam voor Log4j het wel serieus. De opensource-organisatie heeft zowel een CVE-nummer gereserveerd voor de kwetsbaarheid als ook een patch ontwikkeld. Wéér een patch, en dat niet alleen voor de meest actuele 2.17.0-release. Ook de nieuwste versies in de twee voorgaande reeksen (2.12.x en 2.3.x) kregen updates voor het geclaimde gat waarlangs op afstand eigen code valt uit te voeren (remote code execution, RCE).

Toch geen RCE?

Het aanvragen van een CVE-nummer door Apache is aan AG Connect bevestigd door zowel die opensourcestichting zelf als ook door IT-beveiligingsleverancier Checkmarx. Dat bedrijf is de werkgever van de security-onderzoeker die in een tweet zijn vondst van een RCE-gat heeft aangekondigd. Alleen is die claim later bijgesteld: het is toch geen RCE. "Het onderzoeksteam heeft dit geclassificeerd als een 'arbitrary code execution' kwetsbaarheid in de blogpost, in plaats van een RCE", antwoordt een woordvoerster op vragen van AG Connect.

Zij laat weten dat deze nuancering ook is aangebracht in de titel van blogpost die Checkmarx heeft gepubliceerd nadat Apache een 'eindejaarsupdate' voor Log4j heeft uitgebracht. Die blogpost is live gegaan na het proces van ontdekking, melding bij Apache, vooraankondiging middels een tweet en openbaarmaking. Ondertussen spreekt Apache zelf nog wel van een RCE, in CVE-2021-44832.

Langs LDAP

Op vragen over de mate van misbruikbaarheid - en de tegenstelling van gehackt moeten zijn om gehackt te kunnen worden - heeft AG Connect nog antwoorden ontvangen vanuit het projectteam dat Log4j bestiert. Het wijzigen van een configuratiebestand voor die loggingtool is namelijk niet de enige manier om de kwetsbaarheid van code-uitvoering te benutten. De andere manier vereist weliswaar ook enige mate van compromitteren bij het doelwit, maar dan niet direct op hetzelfde systeem waar Log4j op draait.

Als een aanvaller controle krijgt over een LDAP-server (Lightweight Directory Access Protocol) die al is ingesteld als bron voor configuratiedata voor Log4j dan kan dáárlangs ook dit nieuwste gat worden benut. De ingang is de "onverwacht enorme feature set van JNDI [Java Naming and Directory Interface - red.] die is ontdekt in CVE-2021-44228", legt een lid van het projectteam uit aan AG Connect. Het daarbij genoemde CVE-nummer is voor de oorspronkelijke kritieke kwetsbaarheid in Log4j waarlangs op afstand eigen code valt uit te voeren.

Startschot voor de sprint

Dat gat is begin december geopenbaard en heeft de naam Log4Shell gekregen. Deze ernstige, echte RCE-kwetsbaarheid heeft het startschot gegeven voor de hele beveiligingsaffaire rond Log4j. Aan de eerste sprint - met inventariseren, patchen, scannen, opnieuw patchen - lijkt nu een einde gekomen met de 'oudejaarspatch' 2.17.1 (plus 2.12.3 en 2.3.1, voor respectievelijk Java 7 en 6).

Die meest recente updates zijn dus voor een minder ernstige kwetsbaarheid, maar deze kan via een gecompromitteerde LDAP-server wel leiden tot verdere hackwerk. Als die directory-server ingesteld is als bron voor Log4j-configuratiedata via JNDI-lookups vormt dat een mogelijke ingang.

Niet zo bedoeld

De in Log4j opgenomen support voor JNDI en JDBC Appender (Java Database Connectivity) was bedoeld om een DataSource-object te verkrijgen van een JavaEE-server, laat het teamlid van Apache Logging Services weten aan AG Connect. Het is echter ook mogelijk om een LDAP JNDI URI (uniform resource identifier) te gebruiken om de JDBC Appender te configureren. Dit is een legitieme opstelling, aldus de expert.

Alleen is het dus wel een opstellingen die kan worden misbruikt om willekeurige code te laden en uit te voeren vanaf de LDAP-server. Terwijl dit plaatsvindt, wordt er wel de gepaste data teruggevoerd aan de configuratie. Ogenschijnlijk functioneert deze opstelling normaal. En dat is dus het kernprobleem in CVE-2021-44832.

Meer details komen

Een veel eenvoudigere manier om deze kwetsbaarheid te misbruiken, is natuurlijk het direct beroeren van het configuratiebestand, stipt het Log4j-projectlid nog aan. "Maar we zien dat op zichzelf niet als een security-issue vanwege het feit dat configureren van een loggingsysteem om te beginnen al beveiligingsgevoelig is". Het projectteam publiceert nog meer details op de securitypagina en de CVE-aanduiding, zegt hij toe.

Reactie toevoegen
De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.