Indholdsfortegnelse[Skjule][At vise]
Log4Shell, en internetsårbarhed, påvirkede for nylig millioner af maskiner. Log4j, et obskurt, men næsten allestedsnærværende stykke software, forårsager det.
Log4j bruges til at logge alle de handlinger, der sker bag kulisserne i en række forskellige computersystemer.
Det er baseret på et open source-logningsbibliotek, der bruges af virksomheder og endda offentlige organisationer i de fleste applikationer.
Da det er et af de værste cybersikkerhedshuller, der nogensinde er blevet afsløret, er det afgørende at beskytte dine systemer mod denne sårbarhed. Men hvordan?
Lad os undersøge Log4j-sårbarheden i detaljer og alle mulige rettelsesløsninger til den.
Hvad er Log4j?
Log4j er en open source logningsramme, der gør det muligt for softwareudviklere at registrere forskellige data i deres applikationer. Det er en del af Apache Logging Services-projektet, som drives af Apache Software Foundation.
Hundredvis af websteder og apps bruger Log4j til at udføre kritiske operationer såsom logning af data til fejlretning og anden brug.
Når du indtaster eller klikker på et dårligt onlinelink og får en 404 fejlmeddelelse, er dette et hyppigt eksempel på Log4j på arbejde. Webserveren, der kører domænet for det weblink, du forsøgte at få adgang til, informerer dig om, at der ikke findes en sådan webside. Den logger også hændelsen i Log4j for serverens systemadministratorer.
Gennem softwareprogrammer anvendes lignende diagnostiske signaler. I onlinespillet Minecraft bruger serveren for eksempel Log4j til at logge aktivitet, såsom samlet brugt RAM og brugerinstruktioner sendt ind i konsollen.
Hvordan opstår sårbarheden?
Opslag er en ny funktion introduceret i Log4j 2.0, som hjælper med at inkorporere yderligere oplysninger i logposter. Et af disse opslag er JNDI (Java Naming and Directory Interface) opslag, som er en Java API til kommunikation med en adressebogstjeneste.
Ved at bruge denne tilgang kan interne bruger-id'er tilknyttes faktiske brugernavne. Denne forespørgsel afslører den nyligt opdagede RCE-sårbarhed, da en af de datatyper, der leveres af LDAP-serveren, er en URI, der peger på en Java-klasse, som derefter indlæses i hukommelsen og køres af Log4j-instansen.
På grund af en svaghed i Log4j-bibliotekets inputvalidering er det muligt at injicere en vilkårlig LDAP-server fra en ikke-pålidelig kilde. Fordi udviklere antager, at data sendt til logfiler vil blive håndteret som almindelig tekst, foretages der ingen ekstra inputvalidering, og farligt brugerinput kommer ind i logfilerne.
En logerklæring kan se sådan ud:
En ondsindet bruger vil nu indsætte et JNDI-opslag, der henviser til en slyngel LDAP-server i en URL-parameter. JNDI-opslaget ville være som følger:
Log4j-biblioteket taler derefter med denne LDAP-server på attacker.com for at få katalogoplysninger, inklusive værdier for Java Factory og Java Codebase.
Disse to værdier inkluderer angriberens Java-klasse, som derefter indlæses i hukommelsen og udføres af Log4j-forekomsten, hvilket fuldender kodeudførelsen.
Hvem er i fare?
Log4j-sårbarheden er utrolig bred og påvirker forretningsapplikationer, indlejrede enheder og deres undersystemer. Berørte apps inkluderer Cisco Webex, Minecraft og FileZilla FTP.
Dette er dog på ingen måde en hel liste. Fejlen påvirker endda Ingenuity Mars 2020 chopper-missionen, som bruger Apache Log4j til hændelsesoptagelse.
Sikkerhedsfællesskabet har udarbejdet en liste over sårbare systemer. Det er afgørende at bemærke, at disse lister løbende opdateres, så hvis et bestemt program eller system ikke er med, skal du ikke antage, at det ikke er påvirket.
Eksponering for denne sårbarhed er ret sandsynlig, og selvom en specifik teknisk stak ikke anvender Java, bør sikkerhedsledere forvente, at kritiske leverandørsystemer, SaaS-leverandører, cloud-hosting-udbydere og webserver-udbydere gør det.
Hvordan tjekker man for Log4j-sårbarhed?
Det første skridt er at afgøre, om et overfald allerede har fundet sted. Du kan gøre det ved at tjekke systemlogfilerne for RCE-nyttelastfragmenter.
Hvis en søgning efter termer som "jndi", "ldap" eller "$::" giver nogen logfiler, bør sikkerhedsforskere undersøge nærmere for at se, om det var et legitimt angreb eller blot fingeraftryk.
Mange overfald i naturen blev opdaget, som ikke leverede nogen skadelig nyttelast. Ikke desto mindre blev de udført af sikkerhedseksperter for at bestemme, hvor mange apps der var sårbare over for dette angreb.
Det næste trin er at bruge Log4j-biblioteket til at identificere alle projekter. Hvis versioner mellem 2.0-beta9 og 2.14.1 bruges, kan projektet være modtageligt.
I betragtning af vanskeligheden ved at afgøre, hvor denne sårbarhed findes, kan det være at foretrække at antage, at projektet er modtageligt, og at opdatering af biblioteket er den bedste fremgangsmåde til at fjerne faren for kodeudførelse.
Projektet er ikke sårbart, hvis den brugte version er mindre end 2.0-beta 9, selvom Log4j-biblioteket stadig bør opgraderes, fordi versioner i 1.x-området er gamle og ikke længere får opdateringer.
Hvorvidt et modtageligt projekt er opdaget, tilrådes det, at det kontrolleres for at se, om nogen information logget ved hjælp af Log4j indeholder information, som brugeren kan ændre. URL'er, anmodningsparametre, overskrifter og cookies er eksempler på disse data. Hvis en af disse er logget, er projektet i fare.
Denne viden kan hjælpe dig med at dykke yderligere ned i systemloggene og afgøre, om din webapplikation allerede er blevet angrebet.
Der er gratis onlineværktøjer, der kan registrere, om en webapplikation er sårbar. Et af disse programmer er Log4Shell jægerinde. Den er open source og tilgængelig på GitHub.
Hvis et sårbart kodeområde i onlineapplikationen opdages, kan nyttelasten fra det afslørede værktøj bruges til at indsprøjte det i webapplikationen. Testværktøjet ville afsløre forbindelserne mellem din webapplikation og deres LDAP-server, hvis sårbarheden blev udnyttet.
Løsninger til at rette log4j sårbarhed
Det første trin er at opdatere Log4j, hvilket du kan gøre ved at bruge de normale pakkeadministratorer eller ved at downloade det direkte fra denne side.
Det er også muligt at mindske sårbarhedens udnyttelsesevne ved at sætte miljøvariablen FORMAT MSG NO LOOKUPS til sand. Denne modforanstaltning er dog kun gældende for Log4j-versioner større end eller lig med 2.10.
Lad os nu overveje alternative muligheder.
1. Løsninger til Log4j version 2.17.0
Det anbefales bestemt kraftigt at bruge Log4j version 2.15.0 for at beskytte mod Log4Shell, men hvis dette ikke er muligt, er andre løsninger tilgængelige.
Version 2.7.0 og nyere af Log4j: Det er muligt at beskytte mod ethvert angreb ved at ændre formatet på de hændelser, der skal logges, ved at bruge procent m nolookups-syntaksen for de data, som brugeren har leveret. Denne opdatering kræver redigering af Log4j-konfigurationsfilen for at generere en ny version af programmet. Som følge heraf skal de tekniske og funktionelle valideringsfaser gentages, før denne nye version implementeres.
Log4j versioner 2.10.0 og nyere: Det er også muligt at beskytte mod ethvert angreb ved at indstille log4j2.formatMsgNoLookups konfigurationsparameter til sand, for eksempel når du starter den virtuelle Java-maskine med -Dlog4j2-indstillingen." formatMsgNoLookups = sand, En anden mulighed er at fjerne JndiLookup-klassen fra klassesti-argumentet, hvilket vil fjerne hovedangrebsvektoren (forskerne udelukker ikke muligheden for en anden angrebsvektor).
Amazon Web Services leverer en hotpatch, der "bør bruges på egen risiko." Andre "teknikker", såsom Logout4Shell, som "bruger denne sårbarhed mod sig selv," er blevet offentliggjort. Sikkerhedseksperten stiller spørgsmålstegn ved lovligheden af dette træk, som involverer "hacking af en maskine for at reparere det."
2. Problemet er løst i Log4j v2.17.0.
For versioner større end 2.10: Log4j2.formatMsgNoLookups skal indstilles til sand.
For version 2.0 til 2.10.0: Kør følgende kommando for at fjerne LDAP-klassen fra Log4j.
Log4j2.formatMsgNoLookups skal sættes til true i systemindstillingerne.
Afbødning i JVM
Afbødning med JVM-parametre er ikke længere en mulighed. Andre afbødende metoder er fortsat vellykkede. Opgrader til Log4j version 2.17.0, hvis det er muligt. Der er en migrationsvejledning tilgængelig for Log4j v1.
Hvis en opdatering ikke er mulig, skal du sikre dig, at komponenterne på klientsiden og serveren har egenskabssættet -Dlog4j2.formatMsgNoLookups = true system.
Bemærk venligst, at Log4j v1 har nået sin end of life (EOL) og vil ikke længere modtage fejlrettelser. Andre RCE-vektorer er også modtagelige for Log4j v1. Derfor opfordrer vi dig til at opgradere til Log4j 2.17.0 så hurtigt som muligt.
3. Afværgeforanstaltninger
Aktuelle udnyttelser kan ikke fungere, selvom Log4j er modtagelig i nogle tilfælde, såsom hvis værtsmaskinen kører en Java-version, der er højere end 6u212, 7u202, 8u192 eller 11.0.2.
Dette skyldes bedre Java Navngivning og Directory Interface (JNDI) fjernklasseindlæsningsbeskyttelse i nuværende versioner, hvilket er nødvendigt for at angrebet kan fungere.
Ydermere, med Log4j-versioner større end 2.10, kan problemet undgås ved at sætte formatMsgNoLookups-systemværdien til true, give JVM-argumentet -Dlog4j2.formatMsgNoLookups = true, eller ved at slette JndiLookup-klassen fra klassestien.
I mellemtiden, indtil de sårbare tilfælde er rettet, kan sårbarheden løses ved hjælp af nedenstående teknikker:
- Indstil systemegenskaben log4j2.formatMsgNoLookups til true for >=2.10.
- Indstil miljøindstillingen LOG4J FORMAT MSG NO LOOKUPS til sand for >=2.10.
- Fjern JndiLookup.class fra klassestien for 2.0-beta9 til 2.10.0: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
En anbefalet bedste praksis er at begrænse udgående trafik til internettet til kun de relevante porte.
Selvom de fleste angreb i feltet leveres over HTTP, kan sårbarheden blive udnyttet via enhver protokol, der logger brugerinputdata ved hjælp af Log4j.
Opdatering til log4j 2.17.0 er dog den bedste løsning, fordi nogen kan opdage en yderligere tilgang til problemet. Desuden har mange udgivere og producenter annonceret forbedringer af deres tjenester eller apps.
4. Log4Shell sårbarhed patch
Log4j er allestedsnærværende, især nu hvor sårbarheden bliver udnyttet. For at opsummere, alt hvad du skal gøre er at inkludere følgende tegn i logfilerne inspiceret af Log4j.
Og dette vil downloade og udføre Java-filen, der er placeret i slutningen af URL'en. Det er lige så ligetil, som det er dramatisk.
Som du ved, er det afgørende at opgradere log4j til version >= 2.17.0 for at afhjælpe denne Log4Shell-sårbarhed (CVE-2021-44228).
Hvis dette ikke er muligt:
For applikationer, der bruger Log4j-biblioteksversion 2.10.0 og nyere, er det også muligt at beskytte mod ethvert angreb ved at indstille konfigurationsparameteren log4j2.formatMsgNoLookups til f.eks. sand, mens den virtuelle Java-maskine startes med -Dlog4j2.formatMsgNoLookups = true mulighed.
En anden mulighed er at slette JndiLookup-klassen fra klassesti-argumentet, hvilket vil fjerne den primære angrebsvektor (forskerne udelukker ikke, at der findes en anden angrebsvektor).
Bemærk
Organisationer, der er tøvende eller uvillige til at foretage justeringer af modtagelige systemer (eller som ønsker at installere ekstra sikkerhedsforanstaltninger), bør overveje:
- Sørg for, at al trafik dirigeres gennem en iSensor/WAF/IPS. Dette kan forhindre overgrebet i at få adgang til systemet.
- Begrænsning af mængden af trafik, der kan nå det modtagelige system. Hvis systemet ikke behøver at være forbundet til internettet, skal du begrænse adgangen til kun essentielle og pålidelige IPS og områder.
- Reduktion af værtens autoriserede udgående trafik. Fordi dette angreb fungerer ved at oprette forbindelse til en useriøs server, bør alle overflødige IP-adresser og porte blokeres på en firewall.
- Hvis tjenesten ikke længere er påkrævet, bør den deaktiveres, indtil en rettelse er klar.
Konklusion
Log4j-fejlene chokerede vores samfund og mindede os alle om, hvor afhængige vi er af open source-software.
Log4j er unik. Det er hverken et operativsystem, det er heller ikke en browser, og det er heller ikke en software. Det er snarere, hvad programmører omtaler som et bibliotek, en pakke eller et kodemodul. Det tjener kun ét formål, det vil sige at holde styr på, hvad der sker på en server.
Folk, der skriver kode, foretrækker at koncentrere sig om det, der gør deres software karakteristisk. De er ikke interesserede i at genopfinde hjulet. Som et resultat er de afhængige af et væld af eksisterende kodebiblioteker, såsom Log4j.
Log4j-modulet er afledt af Apache, den mest udbredte webserversoftware. Det er derfor, det kan opdages på millioner af servere. Derfor øger sikkerhedstruslerne.
Jeg håber, at ovenstående løsninger hjælper dig med at holde dine enheder sikre.
Hold dig opdateret på HashDork for mere nyttig information fra teknologiverdenen.
Giv en kommentar