Blog | Vers van de pers, laatste ontwikkelingen

Log4j 2 exploit: wat is het, hoe kwetsbaar ben je en wat kun je doen?

Geschreven door Ruben Duller | 14 december 2021 12:20:06 Z

Afgelopen vrijdag 10 december meldde het Nationaal Cyber Security Centrum (NCSC) van het Ministerie van Justitie en Veiligheid dat er een ernstige kwetsbaarheid is gevonden en verholpen in het product Log4j van Apache. Deze java logtool wordt door heel veel applicaties en diensten gebruikt, waaronder clouddiensten en enterprise-apps. De Duitse overheid heeft inmiddels code rood afgegeven voor het CVE-2021-44228 beveiligingslek en voor alle Amerikaanse federale overheidsinstanties is een patch-deadline afgekondigd.

Wat is de log4j kwetsbaarheid?

De kwetsbaarheid in de opensourcetool Apache Log4j 2 maakt het mogelijk voor ongeauthenticeerde kwaadwillenden om op afstand willekeurige code uit te voeren met de rechten van de bovenliggende applicatie. Omdat niet in te schatten is welke rechten de bovenliggende applicatie heeft en doordat de aanvaller willekeurig code op afstand kan injecteren en uitvoeren is de mogelijke gevolgschade niet in te schatten. Daarom heeft het NCSC de impact van deze kwetsbaarheid ingeschat op HIGH/HIGH (resp. Kans/Schade). 

Als er een kwetsbare versie van log4j wordt gebruikt kunnen alle binnenkomende gegevens die worden gelogd leiden tot een remote code execution (RCE; het op afstand uitvoeren van code, scripts en applicaties). Wordt JNDI (Java Naming and Directory Interface) gebruikt om bijvoorbeeld verbinding te maken met een LDAP-URL en deze te loggen, dan is het mogelijk om een kwaadaardige payload (inhoud/lading) te retourneren met een code-injectie. Zo'n payload kan functies bevatten om malware te starten, wachtwoorden buit te maken of een back-door te installeren waarmee criminelen later je systemen kunnen binnendringen.

Wat doet Solimas?

Afgelopen weekend heeft ons Cybersecurity team al onze diensten en applicaties gecheckt op het gebruik van Log4j en waar nodig mitigerende maatregelen genomen. Onze managed diensten, zoals managed wifi, managed antivirus en managed firewall, zijn veilig. 

Welke applicaties zijn kwetsbaar?

Log4j wordt in ontzettend veel Java-based applicaties gebruikt. Het is daarom nog onduidelijk welke software exact deze tooling gebruikt, maar Java is een dusdanig populaire programmeertaal dat het aanvalsoppervlak potentieel enorm is en met de minuut groeit. Naast het feit dat de exploit inmiddels algemeen bekend is (zowel bij ons als bij cybercriminelen), zijn de barriers to entry ontzettend laag. Het misbruiken van deze exploit is kinderlijk eenvoudig - in principe kan iedereen er misbruik van maken.

We hebben onze mensen geïnstrueerd om, als zij zich bewust zijn van een softwarepakket bij klanten dat Log4j gebruikt, te checken of er een mitigerende update beschikbaar is en deze te installeren.

Het Nationaal Cyber Security Centrum houdt op Github een lijst bij met applicaties en de status van de kwetsbaarheden. Die lijst is verre van compleet maar bevat wel de meest gebruikte kwetsbare software.

Neem DIRECT zelf contact op met je applicatieleveranciers om te checken of je applicaties veilig zijn of niet.

 

Wat kun je zelf doen?

  1. Check eerst je hosted apps, vendorsystemen en andere company-level applicaties die aan het internet hangen. 
  2. Ga vervolgens verder met endpoint applicaties. WebEx, Filezilla FTP - het zijn allemaal Java-based apps. En dus zijn ze kwetsbaar.
  3. Na de endpoint apps is het tijd voor thuiswerkende collega's. Instrueer ze om hun persoonlijke apparaten en de router van hun thuisnetwerk te updaten. Ook die zijn vatbaar voor deze exploit. Houd er tegelijkertijd rekening mee dat niet iedereen zal doen wat je zegt. 
  4. Focus vervolgens op patchen en het beperken van outbound traffic. Dat is effectiever dan het instellen van gateway rules om de exploit string te blokkeren. Er zijn oneindig veel varianten op de string denkbaar, waardoor geen enkele blokkade kwaadwillenden tegen zal kunnen houden.
  5. Als je het LDAP/LDAPS-protocol volledig kunt blokkeren in je outbound traffic, doe dat dan. Is dat niet mogelijk, blokkeer dan op z'n minst de default LDAP/LDAPS poorten.