Inhoudsopgave[Zich verstoppen][Laten zien]
Log4Shell, een internetkwetsbaarheid, heeft onlangs miljoenen machines getroffen. Log4j, een obscuur maar bijna alomtegenwoordig stuk software, veroorzaakt dit.
Log4j wordt gebruikt om alle acties die achter de schermen plaatsvinden in verschillende computersystemen te loggen.
Het is gebaseerd op een open-source logboekbibliotheek die in de meeste toepassingen door bedrijven en zelfs overheidsorganisaties wordt gebruikt.
Omdat het een van de ergste cyberbeveiligingslekken is die ooit zijn ontdekt, is het van cruciaal belang om uw systemen tegen deze kwetsbaarheid te beschermen. Maar hoe?
Laten we de kwetsbaarheid van Log4j in detail bekijken en alle mogelijke oplossingen hiervoor.
Wat is Log4j?
Log4j is een open source logging-framework waarmee softwareontwikkelaars verschillende gegevens binnen hun applicaties kunnen vastleggen. Het is een onderdeel van het Apache Logging Services-project, dat wordt uitgevoerd door de Apache Software Foundation.
Honderden websites en apps gebruiken Log4j om kritieke bewerkingen uit te voeren, zoals het loggen van gegevens voor foutopsporing en ander gebruik.
Wanneer u een slechte online link invoert of erop klikt en een 404-foutmelding krijgt, is dit een veelvoorkomend voorbeeld van Log4j aan het werk. De webserver die het domein beheert van de weblink waartoe u toegang probeerde te krijgen, informeert u dat een dergelijke webpagina niet bestaat. Het registreert ook de gebeurtenis in Log4j voor de systeembeheerders van de server.
In softwareprogramma's worden vergelijkbare diagnostische signalen gebruikt. In de online game Minecraft gebruikt de server bijvoorbeeld Log4j om activiteiten te loggen, zoals het totale gebruikte RAM-geheugen en gebruikersinstructies die naar de console zijn verzonden.
Hoe ontstaat de kwetsbaarheid?
Lookups is een nieuwe functie die is geïntroduceerd in Log4j 2.0, die helpt om aanvullende informatie op te nemen in logboekvermeldingen. Een van deze zoekopdrachten is de JNDI-zoekopdracht (Java Naming and Directory Interface), een Java API voor communicatie met een directoryservice.
Met deze aanpak kunnen interne gebruikers-ID's worden toegewezen aan daadwerkelijke gebruikersnamen. Deze query legt de nieuw ontdekte RCE-kwetsbaarheid bloot, aangezien een van de gegevenstypen die door de LDAP-server worden geleverd, een URI is die verwijst naar een Java-klasse, die vervolgens in het geheugen wordt geladen en wordt uitgevoerd door de Log4j-instantie.
Vanwege een zwak punt in de invoervalidatie van de Log4j-bibliotheek, is het mogelijk om een willekeurige LDAP-server van een niet-vertrouwde bron te injecteren. Omdat ontwikkelaars ervan uitgaan dat gegevens die naar logboeken worden verzonden, als platte tekst worden behandeld, wordt er geen extra invoervalidatie uitgevoerd en komt er gevaarlijke gebruikersinvoer in de logboeken.
Een log statement kan er als volgt uitzien:
Een kwaadwillende gebruiker zou nu een JNDI-lookup invoegen die verwijst naar een malafide LDAP-server in een URL-parameter. De JNDI-lookup zou als volgt zijn:
De Log4j-bibliotheek praat vervolgens met deze LDAP-server op attacker.com om directory-informatie op te halen, inclusief waarden voor de Java Factory en Java Codebase.
Deze twee waarden omvatten de Java-klasse van de aanvaller, die vervolgens in het geheugen wordt geladen en wordt uitgevoerd door de Log4j-instantie, waarmee de uitvoering van de code wordt voltooid.
Wie loopt er risico?
De Log4j-kwetsbaarheid is ongelooflijk breed en treft zakelijke applicaties, embedded apparaten en hun subsystemen. Betrokken apps zijn onder meer Cisco Webex, Minecraft en FileZilla FTP.
Dit is echter geenszins een volledige lijst. De fout heeft zelfs invloed op de Ingenuity Mars 2020-choppermissie, die Apache Log4j gebruikt voor het opnemen van gebeurtenissen.
De beveiligingscommunity heeft een lijst van kwetsbare systemen. Het is van cruciaal belang op te merken dat deze lijsten voortdurend worden bijgewerkt, dus als een bepaald programma of systeem niet wordt weergegeven, ga er dan niet vanuit dat het niet wordt beïnvloed.
Blootstelling aan dit beveiligingslek is vrij waarschijnlijk, en zelfs als het specifiek is technische stapel Java niet toepast, mogen beveiligingsmanagers verwachten dat kritieke leverancierssystemen, SaaS-leveranciers, cloudhostingproviders en webserverproviders dit wel doen.
Hoe te controleren op Log4j-kwetsbaarheid?
De eerste stap is om te bepalen of er al een aanval heeft plaatsgevonden. U kunt dit doen door de systeemlogboeken te controleren op RCE-payloadfragmenten.
Als een zoekopdracht naar termen als "jndi", "ldap" of "$::" logboeken oplevert, moeten beveiligingsonderzoekers verder onderzoeken om te zien of het een legitieme aanval was of alleen vingerafdrukken.
Er werden veel aanvallen in het wild ontdekt die geen schadelijke ladingen opleverden. Desalniettemin werden ze uitgevoerd door beveiligingsexperts om te bepalen hoeveel apps kwetsbaar waren voor deze aanval.
De volgende stap is om de Log4j-bibliotheek te gebruiken om alle projecten te identificeren. Als versies tussen 2.0-beta9 en 2.14.1 worden gebruikt, kan het project kwetsbaar zijn.
Gezien de moeilijkheid om te bepalen waar dit beveiligingslek zich bevindt, kan het de voorkeur verdienen om aan te nemen dat het project vatbaar is en dat het updaten van de bibliotheek de beste manier is om het gevaar van code-uitvoering weg te nemen.
Het project is niet kwetsbaar als de gebruikte versie lager is dan 2.0-beta 9, hoewel de Log4j-bibliotheek nog steeds moet worden geüpgraded omdat versies in de 1.x-reeks oud zijn en geen updates meer krijgen.
Of er nu een vatbaar project wordt ontdekt, het wordt aangeraden om te controleren of de informatie die is vastgelegd met Log4j informatie bevat die de gebruiker kan wijzigen. URL's, aanvraagparameters, headers en cookies zijn voorbeelden van deze gegevens. Als een van deze wordt geregistreerd, is het project in gevaar.
Deze kennis kan je helpen om verder in de systeemlogboeken te duiken en te bepalen of je webapplicatie al is aangevallen.
Er zijn gratis online tools die kunnen detecteren of een webapplicatie kwetsbaar is. Een van deze programma's is Log4Shell-jageres. Het is open-source en beschikbaar op GitHub.
Als een kwetsbaar stukje code in de online applicatie wordt ontdekt, kan de payload van de onthulde tool worden gebruikt om deze in de webapplicatie te injecteren. De testtool zou de verbindingen tussen uw webtoepassing en hun LDAP-server onthullen als de kwetsbaarheid werd misbruikt.
Oplossingen om de kwetsbaarheid van Log4j op te lossen
De eerste stap is om Log4j bij te werken, wat u kunt doen door de normale pakketbeheerders te gebruiken of door het hier rechtstreeks van te downloaden pagina.
Het is ook mogelijk de kwetsbaarheid te verkleinen door de omgevingsvariabele FORMAT MSG NO LOOKUPS in te stellen op true. Deze tegenmaatregel is echter alleen van toepassing op Log4j-versies groter dan of gelijk aan 2.10.
Laten we nu alternatieve opties overwegen.
1. Tijdelijke oplossingen voor Log4j versie 2.17.0
Het wordt zeker sterk aangeraden om Log4j versie 2.15.0 te gebruiken om te beschermen tegen Log4Shell, maar als dit niet mogelijk is, zijn er andere oplossingen beschikbaar.
Versies 2.7.0 en later van Log4j: Het is mogelijk om u tegen elke aanval te beschermen door het formaat van de te loggen gebeurtenissen te wijzigen met behulp van de syntaxis voor procent m nolookups voor de door de gebruiker verstrekte gegevens. Deze update vereist het bewerken van het Log4j-configuratiebestand om een nieuwe versie van het programma te genereren. Als gevolg hiervan moeten de technische en functionele validatiefasen worden herhaald voordat deze nieuwe versie wordt geïmplementeerd.
Log4j-versies 2.10.0 en hoger: Het is ook mogelijk om je tegen elke aanval te beschermen door de configuratieparameter log4j2.formatMsgNoLookups in te stellen op true, bijvoorbeeld bij het starten van de virtuele Java-machine met de optie -Dlog4j2.” formatMsgNoLookups = true, Een andere optie is om de klasse JndiLookup te verwijderen uit het classpath-argument, waardoor de hoofdaanvalsvector wordt verwijderd (de onderzoekers sluiten de mogelijkheid van een andere aanvalsvector niet uit).
Amazon Web Services biedt een hotpatch die "op eigen risico moet worden gebruikt". Andere "technieken", zoals Logout4Shell, die "deze kwetsbaarheid tegen zichzelf gebruikt", zijn gepubliceerd. De beveiligingsexpert zet vraagtekens bij de wettigheid van deze stap, waarbij "een machine wordt gehackt om deze te repareren".
2. Het probleem is opgelost in Log4j v2.17.0.
Voor versies groter dan 2.10: Log4j2.formatMsgNoLookups moet worden ingesteld op true.
Voor versies 2.0 tot en met 2.10.0: Voer de volgende opdracht uit om de LDAP-klasse uit Log4j te verwijderen.
Log4j2.formatMsgNoLookups moet worden ingesteld op true in de systeeminstellingen.
Mitigatie in JVM
Mitigatie met JVM-parameters is geen optie meer. Andere mitigerende methoden blijven succesvol. Upgrade indien mogelijk naar Log4j versie 2.17.0. Er is een migratiegids beschikbaar voor Log4j v1.
Als een update niet mogelijk is, zorg er dan voor dat de client-side en server-side componenten de -Dlog4j2.formatMsgNoLookups = true systeemeigenschap hebben ingesteld.
Houd er rekening mee dat Log4j v1 het einde van de levensduur (EOL) heeft bereikt en geen bugfixes meer zal ontvangen. Andere RCE-vectoren zijn ook gevoelig voor Log4j v1. Daarom raden we u aan zo snel mogelijk te upgraden naar Log4j 2.17.0.
3. Mitigerende maatregelen
Huidige exploits kunnen niet werken, zelfs niet als Log4j in sommige gevallen vatbaar is, bijvoorbeeld als de hostmachine een Java-versie draait die hoger is dan 6u212, 7u202, 8u192 of 11.0.2.
Dit komt door betere Java Naming en Directory Interface (JNDI) bescherming tegen het laden van externe klassen in de huidige versies, wat nodig is om de aanval te laten werken.
Bovendien kan het probleem bij Log4j-versies groter dan 2.10 worden vermeden door de systeemwaarde formatMsgNoLookups in te stellen op true, het JVM-argument -Dlog4j2.formatMsgNoLookups = true op te geven of de klasse JndiLookup uit het klassenpad te verwijderen.
In de tussentijd, totdat de kwetsbare instanties zijn verholpen, kan de kwetsbaarheid worden aangepakt met behulp van de onderstaande technieken:
- Stel de systeemeigenschap log4j2.formatMsgNoLookups in op true voor >=2.10.
- Stel de omgevingsoptie LOG4J FORMAT MSG NO ZOEKEN in op waar voor >=2.10.
- Verwijder JndiLookup.class uit het klassenpad voor 2.0-beta9 tot 2.10.0: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Een aanbevolen best practice is om uitgaand verkeer naar internet te beperken tot alleen de juiste poorten.
Hoewel de meeste aanvallen in het veld via HTTP worden uitgevoerd, kan de kwetsbaarheid worden misbruikt via elk protocol dat gebruikersinvoergegevens logt met behulp van Log4j.
Updaten naar log4j 2.17.0 is echter de beste oplossing, omdat iemand een aanvullende benadering van het probleem kan ontdekken. Verder hebben veel uitgevers en fabrikanten verbeteringen aan hun diensten of apps aangekondigd.
4. Log4Shell-kwetsbaarheidspatch
Log4j is alomtegenwoordig, zeker nu de kwetsbaarheid misbruikt wordt. Om samen te vatten, het enige dat u hoeft te doen, is de volgende tekens opnemen in de logboeken die door Log4j zijn geïnspecteerd.
En dit zal het Java-bestand aan het einde van de URL downloaden en uitvoeren. Het is even eenvoudig als dramatisch.
Zoals u weet, is het essentieel om log4j te upgraden naar versie >= 2.17.0 om deze Log4Shell-kwetsbaarheid te verhelpen (CVE-2021-44228).
Als dit niet mogelijk is:
Voor toepassingen die Log4j-bibliotheekversies 2.10.0 en hoger gebruiken, is het ook mogelijk om tegen elke aanval te beschermen door de configuratieparameter log4j2.formatMsgNoLookups in te stellen op true, bijvoorbeeld tijdens het starten van de virtuele Java-machine met de -Dlog4j2.formatMsgNoLookups = true keuze.
Een andere optie is om de klasse JndiLookup te verwijderen uit het argument classpath, waardoor de primaire aanvalsvector wordt verwijderd (de onderzoekers sluiten het bestaan van een andere aanvalsvector niet uit).
Note
Organisaties die aarzelen of niet bereid zijn om aanpassingen aan gevoelige systemen door te voeren (of die wel extra beveiligingen willen installeren) moeten nadenken over:
- Zorg ervoor dat al het verkeer via een iSensor/WAF/IPS. Dit kan voorkomen dat de aanvaller toegang krijgt tot het systeem.
- De hoeveelheid verkeer beperken die het gevoelige systeem kan bereiken Als het systeem niet verbonden hoeft te zijn met internet, beperk dan de toegang tot alleen essentiële en betrouwbare IPS en bereiken.
- Het geautoriseerde uitgaande verkeer van de host verminderen. Omdat deze aanval werkt door verbinding te maken met een malafide server, moeten alle overbodige IP-adressen en poorten worden geblokkeerd op een firewall.
- Als de service niet langer nodig is, moet deze worden uitgeschakeld totdat er een oplossing beschikbaar is.
Conclusie
De fouten in Log4j schokten onze gemeenschap en herinnerden ons er allemaal aan hoe afhankelijk we zijn van open-source software.
Log4j is uniek. Het is geen besturingssysteem, geen browser en ook geen software. Het is eerder wat programmeurs een bibliotheek, een pakket of een codemodule noemen. Het dient slechts één doel, namelijk bijhouden wat er op een server gebeurt.
Mensen die code schrijven concentreren zich liever op wat hun software onderscheidend maakt. Ze zijn niet geïnteresseerd in het opnieuw uitvinden van het wiel. Als gevolg hiervan vertrouwen ze op een overvloed aan bestaande codebibliotheken, zoals Log4j.
De Log4j-module is afgeleid van Apache, de meest gebruikte webserversoftware. Daarom kan het op miljoenen servers worden ontdekt. Vandaar dat de beveiligingsbedreigingen toenemen.
Ik hoop dat de bovenstaande oplossingen u helpen uw apparaten veilig te houden.
Blijf op de hoogte van HashDork voor meer nuttige informatie uit de technische wereld.
Laat een reactie achter