Log4J-exploitdetectie (CVE-2021-44228)

Als je dit leest, dan neem ik aan dat je al hebt gehoord over CVE-2021-44228, de Remote Code Execution (RCE) kwetsbaarheid die Apache Log4j treft, de Java logging library die een groot deel van het internet gebruikt op hun webservers. Hoewel veel blogs en commentaren methoden hebben gepost om te bepalen of je webservers/websites kwetsbaar zijn, is er weinig informatie over hoe je eenvoudig kunt detecteren of je webserver inderdaad is uitgebuit en geïnfecteerd. Maar eerst een korte samenvatting:

CVE-2021-44228 Apache Log4J RCE

• Ten eerste, zoals de meeste twitteraars en beveiligingsexperts zeggen: deze kwetsbaarheid is slecht. Echt slecht. Veel prominente websites draaien deze logger.

• RCE = Executie van code op afstand. De aanvaller kan welke code (bijv. malware) dan ook uitvoeren op je webserver door een webverzoek naar je website te sturen met niets meer dan een "magische" string + een link naar de code die ze willen uitvoeren.

• Betrof Apache webserver met kwetsbare versies van de log4j logger (de populairste java logging module voor websites met java).

• Kwetsbare versies: 2.0 - 2.14.1 (We raden aan om te updaten naar versie 2.17.0)

Heeft iemand geprobeerd mijn webserver te misbruiken?

Typisch gedrag dat je kunt verwachten als je server wordt misbruikt door een aanvaller is de installatie van een nieuwe webshell (website-malware die beheerderstoegang geeft tot de server via een verborgen beheerdersinterface). Apache zou curl of wget commando's uitvoeren om de webshell of andere malware die ze wilden installeren naar beneden te halen.

Gelukkig zijn er een paar manieren om exploit-pogingen te detecteren terwijl je de server bewaakt om eerdere exploit-pogingen te ontdekken:

1. Controleer de Apache-logbestanden op jndi:ldap, jndi:rmi of jndi:dns. Dit zijn de magische tekenreeksen die ervoor zorgen dat de logger in de war raakt en de daaropvolgende URL volgt of uitvoert.
2. Scannen /var/log waarbij de kenmerken van Yara overeenkomen met enkele van deze indicatoren.
3. Scan de webserver op generieke webshells.
4. Als u EDR op de webserver hebt, controleer dan op verdachte curl-, wget- of verwante commando's. Waarschijnlijk heeft de code die ze als eerste proberen uit te voeren na uitbuiting, als doel dat het systeem uitreikt naar de opdracht- en besturingsserver met behulp van ingebouwde hulpprogramma's zoals deze.

OPMERKING: Als de server wordt misbruikt door geautomatiseerde scanners (de goede jongens gebruiken deze), is het mogelijk dat je een indicator van uitbuiting krijgt zonder vervolgmalware of webshells. Sommige onderzoeksscanners maken gebruik van de kwetsbaarheid en laten het systeem een enkele ping of dns verzoek uitsturen om de onderzoeker te informeren wie er kwetsbaar was.

Datto-partners: RMM-component

Datto heeft zowel een ‘ Datto RMM ’-component voor zijn partners uitgebracht als een community-script voor alle MSP’s, waarmee u de kracht en het bereik van uw RMM – ongeacht de leverancier – kunt benutten om systemen in kaart te brengen die zowel potentieel kwetsbaar zijn als mogelijk zijn aangevallen. De tool kan ook proberen bescherming te bieden tegen volgende aanvallen door een bekende tijdelijke oplossing toe te passen.

Aarzel niet om contact op te nemen met ons team van experts voor hulp.

UPDATE 12/22:

In de afgelopen week hebben we veel scanactiviteit gezien van beveiligingsscanners, grootschalige exploitactiviteit van Russische en Oekraïense IP-ruimte en veel exploits van systemen variërend van Elastic-servers tot aangepaste webservices.

We hebben onze log4shells-scanner bijgewerkt met een betere dekking van verduisteringsmethoden en we hebben ook de inmiddels ter ziele gegane mitigatieopties die apache eerder aanraadde, afgeschreven. De omgevingsvariabele LOG4J_FORMAT_MSG_NO_LOOKUPS of log4j2.formatMsgNoLookups=True cli argument zal veel aanvalsvectoren niet tegenhouden.

Daarnaast hebben we de scanner uitgebreid om naar alle schijven te kijken (niet alleen systeemschijven of waar log4j is geïnstalleerd) en we raden aan om de scanner opnieuw uit te voeren als je dat recent nog niet hebt gedaan.

1. Zoekt alle .jar-bestanden met het problematische JndiLookup.class-
2. Scant het systeem op gecomprimeerde en ongecomprimeerde .log-bestanden met aanwijzingen voor misbruik die verband houden met de log4shells-exploit.
— Het primaire pad op Linux en macOS is: /var/log
— Primaire paden op Windows zijn onder meer $env:SystemDrive\logs\, $env:SystemDrive\inetpub\, evenals alle mappen die de termen java, log4j of apache bevatten.
3. Maakt ook gebruik van open-source Yara-signaturen voor de logbestanden.

Door de vele implementaties van log4j in verschillende producten, is het niet altijd eenvoudig om de versie van de log4j-extensie te vinden. De eenvoudigste manier is om te kijken naar de bestands- of mapnaam van het .jar-bestand dat wordt gevonden met de JndiLookup.class, maar deze is niet altijd aanwezig. Sommige producten vereisen specifieke instructies van de leverancier.

UPDATE 12/14:

Er worden nog steeds aanvallen uitgevoerd op kwetsbare Apache-servers, maar deze keer met meer en meer verduistering. Aanvallers lijken gepubliceerde aanbevelingen voor informatie te bekijken en hun aanvallen daarop te testen. We hebben onze log4shells/log4j exploit-detectie-extensie aanzienlijk bijgewerkt om vooruit te kunnen manoeuvreren.

Regex matching in logs kan lastig zijn om goed te krijgen wanneer actoren obfusceren, maar het is nog steeds een van de efficiëntere host-gebaseerde methoden om exploit-activiteit zoals deze te vinden. Het bovenstaande toont verschillende verduisteringen die we hebben gezien en onze matching-logica dekt ze allemaal. Onze aanpak met regels als deze is om een zeer afgestemde en specifieke regel te hebben met lage fout-positieven en een andere meer generieke regel die streeft naar het minimaliseren van fout-negatieven ten koste van fout-positieven. Onze jagers handelen over het algemeen de algemene resultaten af namens onze klanten.

Daarnaast blijft generieke gedragsmonitoring een primaire mogelijkheid die geen updates vereist. Als Apache nieuwe curl- of wget-commando's begint uit te voeren (standaard 2e fase activiteit), zal dit worden herzien.

We blijven de situatie volgen en we raden aan om de log4j-extensie toe te voegen aan je geplande scans.

UPDATE 12/12:

Gisteravond laat hebben we samengewerkt met een paar van onze partners en onze extensie ook bijgewerkt voor Windows-gebaseerde Apache-servers:

Een probleem bij het scannen van logbestanden op Windows Apache-servers is dat de map met logbestanden niet standaard is. Onze extensie zal daarom zoeken in <em>[DriveLetter]</em>:\logs\ (ook bekend als C:\logs\) eerst, aangezien dit een standaardmap is, maar als Apache/httpd actief zijn en het bestand daar niet staat, wordt de rest van de schijf doorzocht.

Er wordt ook nagegaan of er .jar-bestanden zijn die de kwetsbare code importeren. Suggesties van partners in het veld die willen zoeken naar een omgevingsvariabele met de naam log4j2.formatMsgNoLookups Ik begrijp ook wel dat er veel implementaties zijn waarbij deze waarde hard gecodeerd zou kunnen zijn en niet in een omgevingsvariabele staat.

BELANGRIJK: Veel van de activiteit die we hebben waargenomen, is afkomstig van geautomatiseerde scanners (van onderzoekers of anderen) die geen verdere actie ondernemen, zoals het verspreiden van webshells of malware, of het vaststellen van de gevolgen. Aangezien deze kwetsbaarheid zeer eenvoudig kan worden misbruikt, kan dit een proces met veel valse meldingen opleveren. We raden iedereen die op zoek is naar misbruik dan ook aan om eerst te zoeken naar andere indicatoren van inbreuk, voordat er op basis van een positieve match in de logbestanden een incident wordt gemeld. Neem contact met ons op als je bij deze stap problemen ondervindt.

Bent u nog geen Datto-partner? Neem dan vandaag nog contact op voor een demo.