Log4j sårbarhet är bland de dödligaste säkerhetsproblemen i moderna system.
Loggning är en nyckelfunktion i moderna applikationer, och loggningsbiblioteket, Log4j, är ledande på detta område.
Detta bibliotek används i de flesta applikationer, tjänster och system. Därför påverkas alla de applikationer där Log4j används av denna Log4j-sårbarhet som hittades förra året.
Med ökande cybersäkerhetsproblem över hela världen, vidtar organisationer och individer åtgärder för att skydda sina applikationer, system och data.
Och när denna sårbarhet upptäcktes stressade den yrkesverksamma och företag ännu mer.
Därför är det viktigt att upptäcka Log4j-sårbarheten och åtgärda den om du vill skydda din data, ditt nätverk, ditt rykte och dina kunders förtroende.
I den här artikeln kommer jag att diskutera vad Log4j sårbarhet är, tillsammans med stegen för att upptäcka och åtgärda den.
Låt oss börja med att förstå Log4j och varför du behöver det.
Innehållsförteckning
Vad är Log4j?
Log4j är ett loggningsverktyg med öppen källkod skrivet i Java som huvudsakligen används för att lagra, formatera och publicera loggningsposter som genereras av applikationer och system och sedan kontrollera efter fel. Posterna kan vara av olika slag, från en webbsida och webbläsardata till ett systems tekniska detaljer där Log4j körs.
Istället för att skriva kod från början kan utvecklare använda Log4j-biblioteket genom att integrera dess kod i sina appar.
Med Log4j kan utvecklare spåra alla händelser som är associerade med deras applikationer med korrekt loggningsinformation. Det hjälper dem att övervaka applikationer, upptäcka problem i tid och fixa problem innan de kan förvandlas till ett större problem när det gäller prestanda och/eller säkerhet.
Detta Java-baserade bibliotek skrevs av Ceki Gülcü och släpptes 2001 under Apache License 2.0. Den använder Java-namn- och kataloggränssnittstjänster (JNDI) för att tillåta appar att interagera med andra appar som LDAP, DNS, CORBA, etc., och få en katalog och namngivningsfunktion för Java-baserade applikationer. Log4j har tre komponenter för att utföra sina uppgifter:
- Loggers för att fånga loggningsposter
- Layouter för att formatera loggningsposter i olika stilar
- Bilagor för att publicera loggningsposter till olika destinationer
Log4j är faktiskt ett av de mest kända loggningsbiblioteken på webben och används av organisationer från flera branscher och länder. De har integrerat detta loggningsbibliotek i många applikationer, inklusive toppmolntjänster från Google, Microsoft, Apple, Cloudflare, Twitter, etc.
Dess utvecklare, Apache Software Foundation, utvecklade Log4j 2, en uppgradering till Log4j för att lösa de problem som finns i de tidigare utgåvorna. Förra året hittades en sårbarhet i Log4j, som, när den lämnas oadresserad, kan tillåta angripare att bryta sig in i applikationer och system, stjäla data, infektera ett nätverk och utföra andra skadliga aktiviteter.
Låt oss förstå det mer.
Vad är Log4Shell – Log4j-sårbarheten?
Log4Shell är en kritisk cybersäkerhetssårbarhet i Log4j-biblioteket, som påverkar bibliotekets kärnfunktion. Det tillåter en angripare att kontrollera en internetansluten enhet eller applikation genom att utföra fjärrkörning av kod. När de lyckas med det kan de:
- Kör valfri kod på enheten eller systemet
- Få tillgång till alla nätverk och data
- Ändra eller kryptera alla filer på den berörda appen eller enheten
Denna sårbarhet rapporterades första gången den 24 november 2021 av Chen Zhaojun, en säkerhetsforskare på Alibaba (en kinesisk e-handelsjätte). Sårbarheten påverkade deras Minecraft-servrar, vilket Alibabas molnsäkerhetsteam upptäckte den 9 december.
Därefter publicerade NIST denna sårbarhet i National Vulnerability Database och gav den namnet CVE-2021-44228. Apache Software Foundation rankade sedan denna sårbarhet till 10 i CVSS-grad. Detta tilldelas sällan och är mycket allvarligt eftersom det har potential att utnyttjas brett och enkelt, vilket leder till enorm skada för organisationer och individer.
Apache, som svar, utfärdade en patch för denna sårbarhet, men ändå lämnades vissa delar oadresserade, vilket ledde till andra sårbarheter:
- CVE-2021-45046 som underlättade DoS-attacker (Denial of Service) genom JNDI-uppslagningar
- CVE-2021-45105 för att tillåta hackare att kontrollera trådkontextkartainformation och orsaka DoS-attacker genom att tolka en skapad sträng
- CVE-2021-44832 påverkar alla Log4j 2-versioner via Remote Code Injection (RCE)
Hur fungerar Log4Shell?
För att förstå dess svårighetsgrad och hur mycket skada Log4Shell kan göra, är det relevant att lära sig hur denna Log4j-sårbarhet fungerar.
Log4Shell sårbarhet låter en angripare på distans injicera godtycklig kod i ett nätverk och få fullständig kontroll över den.
Denna cyberattacksekvens börjar med att loggningsbiblioteket, som Log4j, samlar in och lagrar logginformation. Om det inte finns något loggningsbibliotek kommer all data från servern att arkiveras direkt efter att data har samlats in.
Men om du vill analysera denna data eller behöver vidta några åtgärder baserat på specifik logginformation, behöver du ett loggbibliotek för att analysera loggdata innan det arkiveras.
På grund av Log4j-sårbarheten blir alla system eller appar som använder Log4j sårbara för cyberattacker. Loggningsbiblioteket kör kod baserat på inmatningen. En hacker kan tvinga loggbiblioteket att exekvera skadlig kod eftersom sårbarheten gör att de kan manipulera inmatningen.
Samtidigt händer mycket saker i bakgrunden. När Log4j skickas med en specifikt utformad sträng kommer den att anropa en LDP-server och ladda ner den koden som finns i dess katalog för att exekvera koden. På så sätt kan angripare skapa en LDAP-server för att lagra skadlig kod som kan hjälpa dem att kontrollera vilken server som helst där koden exekveras. Den skickar sedan en sträng som dirigerar deras skadliga kod till en riktad app eller ett riktat system och tar full kontroll över den.
Så här är hur Log4j sårbarhet kan utnyttjas:
- En angripare hittar en server med en sårbar Log4j-version.
- De kommer att skicka en get-begäran till den riktade servern med sin skadliga LDAP-servers länk.
- Den inriktade servern kommer, istället för att verifiera begäran, att ansluta direkt till denna LDAP-server.
- Angriparna kommer nu att skicka målservern med ett LDAP-serversvar som innehåller skadlig kod. På grund av Log4js sårbarhet, som gör det möjligt att ta emot koden och exekvera den utan verifiering, kan hackaren utnyttja denna svaghet för att bryta sig in i målservern och utnyttja anslutna system, nätverk och enheter.
Hur kan log4j sårbarhet skada användare?
Log4j sårbarhet är oroande eftersom den används i ett brett utbud av mjukvaruapplikationer och system.
Eftersom loggning är en viktig funktion i de flesta programvaruappar och Log4j är en ledande lösning i rymden, hittar Log4j applikationer i en mängd olika programvarusystem.
Några av de populära tjänsterna och apparna som använder Log4j är Minecraft, AWS, iCloud, Microsoft, Twitter, internetroutrar, mjukvaruutvecklingsverktyg, säkerhetsverktyg och så vidare. Därför kan angripare rikta in sig på ett stort antal applikationer, tjänster och system från hemanvändare, kodutvecklare, tjänsteleverantörer och andra relaterade yrkesverksamma och individer.
Dessutom är Log4j-sårbarheten extremt lätt för en angripare att utnyttja. Den övergripande processen kräver färre färdigheter, inte expertnivå, för att utföra en attack. Det är därför antalet attacker som utnyttjar denna sårbarhet ökar.
Effekterna av Log4j sårbarhet är:
- DoS-attacker
- Supply chain attacker
- Myntbrytning
- Injektioner med skadlig programvara som ransomware och trojanska hästar
- Godtycklig kodinjektion
- Fjärrkörning av kod
Och mer.
Som ett resultat av dessa attacker kan du tappa greppet om dina applikationer, system och enheter, och dina data kan falla offer för angripare som kan sälja din data, manipulera den eller exponera den för omvärlden. Därför kan ditt företag skadas när det gäller kunddatasekretess, förtroende, organisationens hemligheter och till och med din försäljning och intäkter, än mindre riskerna för efterlevnad.
Enligt en rapportöver 40 % av globala företagsnätverk har upplevt attacker på grund av denna sårbarhet.
Så även om du inte använder några sårbara Log4j-versioner i dina applikationer, kan dina tredjepartsintegrationer använda den, vilket gör din app sårbar för attacker.
Observera att alla Log4j-versioner före Log4j 2.17.0. påverkas; därför måste du uppgradera loggern om du använder den. Även kända leverantörer som påverkas av denna Log4j-sårbarhet är Adobe, AWS, IBM, Cisco, VMware, Okta, Fortinet, etc. Om du använder någon av dem, övervaka dina appar kontinuerligt och använd säkerhetssystem för att åtgärda problem så snart det uppstår.
Hur man upptäcker program som påverkas av Log4j och åtgärdar problemen
Log4Shell-sårbarheten har 10 i CVSS-poängen. Därför är alla problem i Log4j inte korrigerade än. Men det är en chans att du eller din tredjepartsleverantör kanske använder Log4j, som du har använt i din applikation.
Därför, om du vill skydda dina data, system och nätverk, se till att du följer några åtgärdssteg.
#1. Uppdatera din Log4j-version
Att uppdatera din nuvarande Log4j-version till Log 4j 2.17.1 är den mest effektiva åtgärdstekniken om du vill skydda din enhet och appar från attacker som ett resultat av Log4j-sårbarheten.
Log4Shell är en typ av nolldagsattack som potentiellt kan påverka ditt mjukvaruekosystem. Apache har åtgärdat några av sårbarheterna i de senaste versionerna, men om ditt system komprometterades före uppgraderingen är du fortfarande i riskzonen.
Därför måste du, om du antar detta, inte bara uppgradera versionen utan också starta dina incidentresponsprocedurer omedelbart för att säkerställa att inga sårbarheter finns i dina system och appar och mildra attackerna. Du måste också granska alla dina serverloggar för att hitta Indicators of Compromise (IOC) och ständigt övervaka dina system och nätverk.
#2. Använd de senaste brandväggarna och säkerhetssystemen
Brandväggar som Web Application Firewall (WAF) och nästa generations brandväggar kan hjälpa till att säkra din nätverksperimeter från angripare genom att skanna inkommande och utgående datapaket och blockera misstänkta. Så använd de senaste brandväggarna i ditt nätverk och ställ in strikta utgående regler på dina servrar för att förhindra attacker associerade med Log4j-sårbarhet.
Även om angripare kan kringgå brandväggar, kommer du fortfarande att få en viss grad av säkerhet med brandväggar som kan blockera en angripares förfrågningar.
Uppdatera dessutom alla dina säkerhetssystem, såsom Intrusion Detection Systems (IDS), Intrusion Prevention Systems (IPS), etc., med de senaste signaturerna och reglerna. Dessa system hjälper till att blockera eller filtrera RMI- och LDAP-trafik från att ansluta till en skadlig LDAP-server.
#3. Implementera MFA
Att ställa in multi-factor authentication (MFA) i dina applikationer och system kommer att ge bättre säkerhet från angripare. Det kommer att ge ett andra lager av säkerhet även om en angripare lyckas bryta det första lagret. Du kan göra det genom biometri som fingeravtryck, irisskanning etc., ställa in en säkerhetsfråga eller aktivera en säkerhets-PIN.
Att använda MFA kommer att öka angriparnas svårighet och tid för att utföra en komplett attack. Under tiden kan den också informera dig om händelsen omedelbart så att du kan vidta nödvändiga saneringsåtgärder när du fortfarande har tid.
Dessutom måste du också tillämpa strikta VPN-policyer för att minska dataintrång. Detta kommer att göra det möjligt för användarna att komma åt dina system på ett säkert sätt var som helst utan rädsla för angripare.
#4. Ändra systemegenskaper
Om du inte kan uppgradera till den senaste versionen av Log4j-biblioteket, måste du ändra dina Java-systemegenskaper omedelbart om du använder en version som sträcker sig från Log4j 2.10 till Log4j 2.14.1.
Du måste ställa in den på ett sådant sätt att förhindra uppslagningar som angripare använder för att upptäcka sårbarheterna och sedan hitta sätt att utnyttja dem.
#5. Ta bort JNDI
Orsaken till denna kritiska säkerhetssårbarhet ligger i dess design. JNDI Lookup-plugin har ett designfel genom vilket angripare kan utföra en attack.
JNDI används för kodexekvering baserat på indata i dess logg, som vem som helst kan manipulera enkelt eftersom loggern accepterar vilken begäran som helst utan verifiering.
Säkerhetsforskare har funnit att denna plugin alltid har tillåtit oparsad data sedan den släpptes 2013 och skickar den till Log4j-biblioteket.
Därför är Log4j-sårbarheten benägen att utnyttjas med en enkel stränginjektion. När angriparen injicerar det, kommer loggern att acceptera operationen som begärs i strängen och utföra den direkt utan verifiering.
Så om du vill säkra dina system och applikationer måste du inaktivera klassen – JndiLookup. Detta förhindrar loggern från att vidta åtgärder baserat på loggdata.
Faktum är att JNDI-sökning redan är inaktiverad i Log4j 2.16.0 som standard i ett försök att säkra dina applikationer och system.
Så om du använder en Log4j-version lägre än 2.16.0, se till att du har inaktiverat JNDI Lookup.
#6. Prata med dina leverantörer
Om du har fått allt rätt, dina brandväggar och säkerhetssystem uppdaterade, Log4j-versionen uppdaterad, JNDI Lookup inaktiverad, etc., slappna inte av ännu.
Även om du inte använder en sårbar Log4j-version i dina applikationer, kanske dina tredjepartsleverantörer använder den. Så du kommer aldrig att veta hur din applikation eller ditt system blev hackat eftersom det verkliga problemet var din tredjepartsintegration.
Prata därför med dina leverantörer och se till att de också har uppgraderat Log4j till den senaste versionen och implementerat andra säkerhetsrutiner som diskuterats ovan.
#7. Använd en Log4j Vulnerability Scanner
Det finns många Log4j-sårbarhetsskanningsverktyg tillgängliga på marknaden för att göra det enkelt för dig att upptäcka Log4j-sårbarheter i dina system och applikationer.
Så när du letar efter dessa verktyg, kontrollera deras noggrannhet eftersom många av dem genererar falska positiva resultat. Hitta också ett verktyg som kan tillgodose dina behov eftersom de kan fokusera på att identifiera Log4j-sårbarhet, rapportera exponeringen och åtgärda sårbarheten.
Så om ditt fokus är upptäckt, hitta en Log4j sårbarhetsskanner som kan upptäcka problemet eller använd den som kan upptäcka och åtgärda problemet.
Några av de bästa Log4j skanningsverktygen är:
- Microsoft 365 Defender: Microsoft erbjuder en rad säkerhetslösningar och verktyg som hjälper dig att upptäcka och förhindra Log4j-missbruk i ditt nätverk. Du kommer att kunna upptäcka fjärrexekvering av kod och exploateringsförsök, vilket skyddar dig från Log4j-sårbarheter i Windows- och Linux-enheter.
- Amazon Inspector och AWS: Amazon har skapat ett skanningsverktyg för att hitta Log4j-sårbarhet i Amazon EC2-instanser och Amazon ECR.
- CloudStrike Archive Scan Tool (CAST): CloudStrike har också skapat ett utmärkt skanningsverktyg för att upptäcka Log4j-sårbarhet för att hjälpa dig att fixa problem i tid innan angripare kan utnyttja det.
- Google Cloud Logging-detektering: Googles molnloggningsdetekteringslösning låter dig upptäcka Log4j-exploater med Logs Explorer. Du kan skapa en loggfråga i det här verktyget och söka efter potentiella exploateringssträngar.
- Google har också skapat log4jscanner, en filsystemskanner med öppen källkod för att upptäcka sårbarhet i Log4j.
- BurpSuite Log4j Scanner: Detta är ett säkerhetsplugin för proffs och företag för att hjälpa dem att upptäcka Log4j-sårbarhet.
- Huntress Log4Shell Vulnerability Tester: Detta verktyg genererar en unik identifierare slumpmässigt som du kan använda när du testar dina inmatningsfält. När en sårbarhet hittas i applikationen eller inmatningsfältet kommer dess säkra LDAP-server att avsluta den skadliga anslutningen omedelbart och hålla dig säker.
- WhiteSource Log4j Detect: WhiteSource har skapat ett gratis CLI-verktyg, WhiteSource Log4j Detect, värd på GitHub för att hjälpa dig att upptäcka och fixa Log4j-sårbarheter – CVE-2021-445046 och CVE-2021-44228.
- JFrog Open-Source Scanning-verktyg för Log4j: JFrog har skapat olika open-source-lösningar och verktyg för att hitta Log4j-sårbarheter i dina binärfiler och källkod.
Slutsats
Log4j sårbarhet är en kritisk säkerhetsfråga. Eftersom detta loggningsbibliotek används flitigt i olika applikationer och system, har Log4j-sårbarheten blivit utbredd, vilket gör att angripare kan utnyttja ett brett utbud av system och appar.
Så om du vill skydda dina system och applikationer från denna sårbarhet, se till att du uppgraderar Log4j-biblioteket till den senaste versionen och implementerar de bästa säkerhetsrutinerna som diskuterats ovan.