De log4j exploit

De log4j exploit is groot nieuws. Maar wat heeft het voor impact op jou als Mendix ontwikkelaar? Wij helpen je!

Wat is er aan de hand?

Afgelopen donderdag (9 december) werd een nieuwe exploit bekend gemaakt in de veelgebruikte Java logging library log4j. Zie o.a. dit nieuwsbericht.

Deze exploit kan er voor zorgen dat kwaadwillenden code op afstand kunnen uitvoeren door een specifiek bericht te laten loggen. Een server kan dan zelfs volledig worden overgenomen.

Aangezien de log4j library door Mendix en heel veel andere systemen wordt gebruikt heeft deze exploit een grote impact.

Wie hebben er last van?

Vrijwel iedereen die de log4j library gebruikt. Hier vallen naast Mendix ook partijen zoals Apple en Netflix onder.

Een (lange) lijst van bedrijven die kwetsbaar waren/zijn is hier te vinden.

Om precies te zijn gaat het om specifieke versies van Log4j die de kwetsbaarheid bevatten:

log4j v2

Bijna alle versies van versie 2 zijn kwetsbaar. Aanbevolen wordt om te updaten naar 2.16.0.

log4j v1

Alle versies van versie 1 zijn kwetsbaar waardoor je moet updaten naar versie 2.16.0.

Welke versie heeft mijn Mendix applicatie?

Als je de log4j library gebruikt zal deze in de userlib folder van het Mendix project staan.

Mocht je enkele projecten hebben, is dit gemakkelijk handmatig te checken, maar als je veel projecten hebt kan dit erg veel tijd kosten. Tijd voor een script!

Onderstaande is gebaseerd op OSX:

In het script maken we gebruik van jq en subversion:

brew install jq
brew install subversion

Sla onderstaand script op in een bestand met .sh extensie. let op: Vervang de xxxx door je eigen credentials.

#!/bin/bash
set -u
set -e

workingDir=/tmp/mendix
mendixApiKey="xxxxx-xxxxx-xxxxx-xxxxx"
mendixUsername="xxxx@xxx.xx"
mendixPassword="xxxxxxx"

mkdir -p $workingDir

projects=$(curl -s -H "Mendix-Username: $mendixUsername" -H "Mendix-ApiKey: $mendixApiKey" https://deploy.mendix.com/api/1/apps -X GET)
echo "projects=${projects}"

for row in $(echo "${projects}" | jq -r '.[] | @base64'); do
        projectId=$(echo ${row} | base64 --decode | jq -r '.ProjectId')
        echo "projectId=${projectId}"
        projectName=$(echo ${row} | base64 --decode | jq -r '.AppId')
        echo "projectName=${projectName}"

        svn checkout --username $mendixUsername --password $mendixPassword --non-interactive "https://teamserver.sprintr.com/${projectId}/trunk/userlib/" $workingDir/${projectName}-main/userlib/
done

find ${workingDir} -name "*.jar" -exec sh -c 'echo "{}" | grep -i --color=always log4j-core-.*.jar' \; -print

Voer het script uit met ./bestandsnaam.sh of sh bestandsnaam.sh

Het resultaat ziet er uit als volgt:

In de userlib van je project zie je vervolgens het bestand staan:

Wat moet ik doen als ik een kwetsbare versie heb?

Mocht je een kwetsbare versie van log4j gebruiken dan zijn er twee opties:

De .jar verwijderen waarbij de kans bestaat dat er iets kapot gaat.

Log4j updaten naar minimaal versie 2.16.0. Dat kan via deze link.

Hoe bescherm ik me voor toekomstige exploits?

De log4j kwetsbaarheid is een van de vele kwetsbaarheden die java libraries kunnen bevatten. Met het oplossen van deze exploit ben je dus nog niet meteen veilig.

Bij JAM-IT geloven wij in het slim automatiseren van taken zoals security, deployen en kwaliteitscontroles. Daarom bevat JamOps een java library kwetsbaarheids-scan die je project continue op bekende exploits controleert. Hierdoor ben je niet alleen nu, maar ook in de toekomst een stuk beter beveiligd.