Innehållsförteckning[Dölj][Visa]
Log4Shell, en internetsårbarhet, påverkade nyligen miljontals maskiner. Log4j, en obskyr men nästan allmänt förekommande mjukvara, orsakar det.
Log4j används för att logga alla åtgärder som sker bakom kulisserna i en mängd olika datorsystem.
Det är baserat på ett loggningsbibliotek med öppen källkod som används av företag och till och med statliga organisationer i de flesta applikationer.
Eftersom det är ett av de värsta cybersäkerhetshålen som någonsin upptäckts är det viktigt att skydda dina system från denna sårbarhet. Men hur?
Låt oss utforska Log4j-sårbarheten i detalj och alla möjliga fixlösningar för den.
Vad är Log4j?
Log4j är en öppen källkod loggningsramverk som gör det möjligt för mjukvaruutvecklare att registrera olika data i sina applikationer. Det är en komponent i Apache Logging Services-projektet, som drivs av Apache Software Foundation.
Hundratals webbplatser och appar använder Log4j för att utföra kritiska operationer som att logga data för felsökning och annan användning.
När du matar in eller klickar på en dålig onlinelänk och får ett 404-felmeddelande är detta ett vanligt exempel på Log4j på jobbet. Webbservern som kör domänen för webblänken du försökte komma åt informerar dig om att det inte finns någon sådan webbsida. Den loggar även händelsen i Log4j för serverns systemadministratörer.
Genomgående i mjukvaruprogram används liknande diagnostiska signaler. I onlinespelet Minecraft, till exempel, använder servern Log4j för att logga aktivitet som totalt använt RAM-minne och användarinstruktioner som skickas till konsolen.
Hur uppstår sårbarheten?
Uppslagningar är en ny funktion som introduceras i Log4j 2.0, som hjälper till att införliva ytterligare information i loggposter. En av dessa uppslagningar är JNDI (Java Naming and Directory Interface) lookup, som är ett Java API för att kommunicera med en katalogtjänst.
Med detta tillvägagångssätt kan interna användar-ID:n mappas till faktiska användarnamn. Den här frågan avslöjar den nyligen upptäckta RCE-sårbarheten, eftersom en av datatyperna som tillhandahålls av LDAP-servern är en URI som pekar på en Java-klass, som sedan laddas in i minnet och körs av Log4j-instansen.
På grund av en svaghet i Log4j-bibliotekets ingångsvalidering är det möjligt att injicera en godtycklig LDAP-server från en opålitlig källa. Eftersom utvecklare antar att data som skickas till loggar kommer att hanteras som vanlig text, görs ingen extra indatavalidering, och farlig användarinmatning kommer in i loggarna.
En loggsats kan se ut så här:
En illvillig användare skulle nu infoga en JNDI-sökning som hänvisar till en oseriös LDAP-server i en URL-parameter. JNDI-uppslagningen skulle se ut som följer:
Log4j-biblioteket pratar sedan med denna LDAP-server på attacker.com för att få kataloginformation, inklusive värden för Java Factory och Java Codebase.
Dessa två värden inkluderar angriparens Java-klass, som sedan laddas in i minnet och exekveras av Log4j-instansen, vilket slutför kodexekveringen.
Vem är i riskzonen?
Log4j-sårbarheten är otroligt bred och påverkar affärsapplikationer, inbäddade enheter och deras undersystem. Berörda appar inkluderar Cisco Webex, Minecraft och FileZilla FTP.
Detta är dock inte på något sätt en hel lista. Felet påverkar till och med chopperuppdraget Ingenuity Mars 2020, som använder Apache Log4j för händelseinspelning.
Säkerhetsgemenskapen har sammanställt en lista över sårbara system. Det är viktigt att notera att dessa listor kontinuerligt uppdateras, så om ett visst program eller system inte visas, anta inte att det inte påverkas.
Exponering för denna sårbarhet är ganska trolig, och även om en specifik teknisk stack inte tillämpar Java, bör säkerhetschefer förvänta sig att kritiska leverantörssystem, SaaS-leverantörer, molnvärdsleverantörer och webbserverleverantörer gör det.
Hur kontrollerar jag efter Log4j-sårbarhet?
Det första steget är att avgöra om en misshandel redan har inträffat. Du kan göra det genom att kontrollera systemloggarna för RCE-nyttolastfragment.
Om en sökning efter termer som "jndi", "ldap" eller "$::" ger några loggar, bör säkerhetsforskare utforska vidare för att se om det var en legitim attack eller bara fingeravtryck.
Många övergrepp i naturen upptäcktes som inte gav några skadliga nyttolaster. Icke desto mindre utfördes de av säkerhetsexperter för att fastställa hur många appar som var sårbara för denna attack.
Nästa steg är att använda Log4j-biblioteket för att identifiera alla projekt. Om versioner mellan 2.0-beta9 och 2.14.1 används kan projektet vara mottagligt.
Med tanke på svårigheten att avgöra var denna sårbarhet finns, kan det vara att föredra att anta att projektet är mottagligt och att uppdatering av biblioteket är det bästa tillvägagångssättet för att undanröja faran för kodexekvering.
Projektet är inte sårbart om den använda versionen är mindre än 2.0-beta 9, även om Log4j-biblioteket fortfarande bör uppgraderas eftersom versioner i 1.x-intervallet är gamla och inte längre får uppdateringar.
Oavsett om ett känsligt projekt upptäcks, rekommenderas det att det kontrolleras för att se om någon information som loggas med Log4j innehåller information som användaren kan ändra. Webbadresser, förfrågningsparametrar, rubriker och cookies är exempel på denna data. Om någon av dessa loggas är projektet i fara.
Denna kunskap kan hjälpa dig att fördjupa dig ytterligare i systemloggarna och avgöra om din webbapplikation redan har attackerats.
Det finns gratis onlineverktyg som kan upptäcka om en webbapplikation är sårbar. Ett av dessa program är Log4Shell jägare. Den är öppen källkod och tillgänglig på GitHub.
Om ett sårbart kodområde i onlineapplikationen upptäcks kan nyttolasten som tillhandahålls av det avslöjade verktyget användas för att injicera det i webbapplikationen. Testverktyget skulle avslöja kopplingarna mellan din webbapplikation och deras LDAP-server om sårbarheten utnyttjades.
Lösningar för att fixa log4j sårbarhet
Det första steget är att uppdatera Log4j, vilket du kan göra genom att använda de vanliga pakethanterarna eller genom att ladda ner det direkt från denna sida.
Det är också möjligt att minska sårbarhetens exploatering genom att ställa in miljövariabeln FORMAT MSG NO LOOKUPS till sant. Denna motåtgärd är dock endast tillämplig på Log4j-versioner större än eller lika med 2.10.
Låt oss nu överväga alternativa alternativ.
1. Lösningar för Log4j version 2.17.0
Det rekommenderas definitivt starkt att använda Log4j version 2.15.0 för att skydda mot Log4Shell, men om detta inte är möjligt finns andra lösningar tillgängliga.
Version 2.7.0 och senare av Log4j: Det är möjligt att skydda mot alla attacker genom att ändra formatet på händelserna som ska loggas med hjälp av syntaxen för procent m nolookups för data som tillhandahålls av användaren. Denna uppdatering kräver redigering av Log4j-konfigurationsfilen för att generera en ny version av programmet. Som ett resultat måste de tekniska och funktionella valideringsstegen upprepas innan den här nya versionen distribueras.
Log4j versioner 2.10.0 och senare: Det är också möjligt att skydda mot alla attacker genom att ställa in konfigurationsparametern log4j2.formatMsgNoLookups till true, till exempel när den virtuella Java-maskinen startas med alternativet -Dlog4j2." formatMsgNoLookups = true, Ett annat alternativ är att ta bort klassen JndiLookup från klassvägsargumentet, vilket kommer att ta bort huvudattackvektorn (forskarna utesluter inte möjligheten av en annan attackvektor).
Amazon Web Services tillhandahåller en hotpatch som "bör användas på egen risk." Andra "tekniker", som Logout4Shell, som "använder denna sårbarhet mot sig själv", har publicerats. Säkerhetsexperten ifrågasätter lagligheten av detta drag, som innebär att "hacka en maskin för att fixa det."
2. Problemet har lösts i Log4j v2.17.0.
För versioner högre än 2.10: Log4j2.formatMsgNoLookups ska ställas in på true.
För version 2.0 till 2.10.0: Kör följande kommando för att ta bort LDAP-klassen från Log4j.
Log4j2.formatMsgNoLookups ska ställas in på true i systeminställningarna.
Begränsning i JVM
Begränsning med JVM-parametrar är inte längre ett alternativ. Andra mildrande metoder fortsätter att vara framgångsrika. Uppgradera till Log4j version 2.17.0 om möjligt. Det finns en migreringsguide tillgänglig för Log4j v1.
Om en uppdatering inte är möjlig, se till att komponenterna på klientsidan och serversidan har egenskapen -Dlog4j2.formatMsgNoLookups = true system.
Observera att Log4j v1 har nått sin livslängd (EOL) och kommer inte längre att ta emot buggfixar. Andra RCE-vektorer är också känsliga för Log4j v1. Därför uppmanar vi dig att uppgradera till Log4j 2.17.0 så snart som möjligt.
3. Begränsande åtgärder
Aktuella exploateringar kan inte fungera även om Log4j är känsligt i vissa fall, till exempel om värddatorn kör en Java-version högre än 6u212, 7u202, 8u192 eller 11.0.2.
Detta beror på bättre Java Naming and Directory Interface (JNDI) fjärrklassladdningsskydd i nuvarande versioner, vilket är nödvändigt för att attacken ska fungera.
Dessutom, med Log4j-versioner större än 2.10, kan problemet undvikas genom att sätta formatMsgNoLookups systemvärde till true, tillhandahålla JVM-argumentet -Dlog4j2.formatMsgNoLookups = true, eller ta bort klassen JndiLookup från klasssökvägen.
Under tiden, tills de sårbara instanserna är åtgärdade, kan sårbarheten åtgärdas med hjälp av teknikerna nedan:
- Ställ in systemegenskapen log4j2.formatMsgNoLookups till true för >=2.10.
- Ställ in miljöalternativet LOG4J FORMAT MSG NO LOOKUPS till sant för >=2.10.
- Ta bort JndiLookup.class från klasssökvägen för 2.0-beta9 till 2.10.0: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
En rekommenderad bästa praxis är att begränsa utgående trafik till internet till endast lämpliga portar.
Även om de flesta attacker i fältet levereras över HTTP, kan sårbarheten utnyttjas via vilket protokoll som helst som loggar användarindata med Log4j.
Uppdatering till log4j 2.17.0 är dock den bästa lösningen eftersom någon kan upptäcka en ytterligare lösning på problemet. Dessutom har många utgivare och tillverkare aviserat förbättringar av sina tjänster eller appar.
4. Log4Shell sårbarhetskorrigering
Log4j är allestädes närvarande, speciellt nu när sårbarheten utnyttjas. För att sammanfatta, allt du behöver göra är att inkludera följande tecken i loggarna som inspekteras av Log4j.
Och detta kommer att ladda ner och köra Java-filen som finns i slutet av URL:en. Det är lika enkelt som det är dramatiskt.
Som du är medveten om är det viktigt att uppgradera log4j till version >= 2.17.0 för att åtgärda denna Log4Shell-sårbarhet (CVE-2021-44228).
Om detta inte är möjligt:
För applikationer som använder Log4j-biblioteksversionerna 2.10.0 och senare är det också möjligt att skydda mot alla attacker genom att ställa in konfigurationsparametern log4j2.formatMsgNoLookups till true, till exempel, medan den virtuella Java-maskinen startas med -Dlog4j2.formatMsgNoLookups = true alternativ.
Ett annat alternativ är att ta bort klassen JndiLookup från klassvägsargumentet, vilket tar bort den primära attackvektorn (forskarna utesluter inte att det finns en annan attackvektor).
Anmärkningar
Organisationer som är tveksamma eller ovilliga att göra justeringar av känsliga system (eller som bara vill installera extra skydd) bör tänka på:
- Se till att all trafik dirigeras genom en iSensor/WAF/IPS. Detta kan hindra överfallet från att få tillgång till systemet.
- Begränsa mängden trafik som kan nå det känsliga systemet Om systemet inte behöver vara anslutet till internet, begränsa åtkomsten till enbart väsentliga och pålitliga IPS och intervall.
- Minska värdens auktoriserade utgående trafik. Eftersom denna attack fungerar genom att ansluta till en oseriös server, bör alla överflödiga IP-adresser och portar blockeras på en brandvägg.
- Om tjänsten inte längre behövs bör den inaktiveras tills en fix är klar.
Slutsats
Log4j-bristerna chockade vårt samhälle och påminde oss alla om hur beroende vi är av programvara med öppen källkod.
Log4j är unik. Det är varken ett operativsystem, det är inte heller en webbläsare eller en programvara. Det är snarare vad programmerare refererar till som ett bibliotek, ett paket eller en kodmodul. Det tjänar bara ett syfte, det vill säga att hålla ett register över vad som händer på en server.
Människor som skriver kod föredrar att koncentrera sig på det som gör deras mjukvara utmärkande. De är inte intresserade av att uppfinna hjulet på nytt. Som ett resultat förlitar de sig på en uppsjö av befintliga kodbibliotek, som Log4j.
Log4j-modulen kommer från Apache, den mest använda webbservermjukvaran. Det är därför det kan upptäckas på miljontals servrar. Därför ökar säkerhetshoten.
Jag hoppas att ovanstående lösningar hjälper dig att hålla dina enheter säkra.
Håll ögonen öppna för HashDork för mer användbar information från teknikvärlden.
Kommentera uppropet