Sårbarhed i Log4j: Opsamling

En kritisk sårbarhed i en open source-komponent kan udnyttes til at kompromittere systemer og netværk. Ifølge flere kilder, er der observeret forsøg på at udnytte sårbarheden. CFCS har også konstateret forsøg på scanninger mod systemer efter sårbarheden.

 

CFCS' Situationscenter udsendte lørdag d. 11 december et varsel om sårbarheden.

 

Sårbarheden findes i open source-komponenten Apache Log4j. Det er en komponent til at logge i Java-applikationer. Sårbarheden findes specifikt i Log4j version 2. Bemærk, at udviklerne bag komponenten lukkede sårbarheden fra version 2.15, men der er efterfølgende fundet flere sårbarheder.

 

Det britiske cybersikkerhedscenter NCSC har udgivet et blogindlæg om Log4j henvendt til ledelsen og bestyrelsen. Indlægget indeholder blandt andet forslag til de overvejelser, ledelsen kan drøfte med it-afdelingen i store og mellemstore virksomheder.

 

For at lukke sårbarhederne, bør man derfor opdatere Log4j til version 2.17.1 eller nyere. Se release notes fra Apache Log4j Security. 

 

Den mest alvorlige af de sårbarheder, der er fundet i Log4j, har CVE-2021-44228.

 

Bemærk, at der er fundet nye sårbarheder i version 2.15, hvor sårbarheden først blev adresseret, og efterfølgende også i version 2.16. Hvis man har opdateret til version 2.15 eller 2.16, bør man derfor opdatere til version 2.17.

 

Fra version 2.16 har udviklerne ændret Log4j, så JNDI lookups er slået fra som standard. Dette skadesbegrænsende tiltag er altså standardindstillingen fra version 2.16. Se changelog for Log4j2. Hvis man har behov for at bevare funktionaliteten, skal det fra version 2.16 aktiveres.

 

For dem, der benytter Java 7, var det ikke muligt at opgradere til 2.16, men der er nu frigivet version 2.12.2, som adresserer sårbarheden, men ikke forudsætter Java 8. Bemærk, at Java 7 ikke længere opdateres (End of life).

 

Log4j-Komponenten indgår i en række applikationer. Man bør derfor være opmærksom på, at der kan være tredjepartsapplikationer, som er sårbare.

 

Man bør opdatere tredjepartsapplikationer, når opdateringer, der adresserer sårbarheden, bliver tilgængelige.

 

Det hollandske nationale center for cybersikkerhed har samlet en liste over påvirkede tredjepartsapplikationer, som kan hjælpe med at identificere, hvorvidt man har produkter, der er ramt. Den amerikanske cybersikkerhedsmyndighed CISA har frigivet en tilsvarende liste.

 

Bemærk, at disse lister ikke er udtømmende. Der er sandsynligvis en række systemer, der er påvirket, ud over dem, der er anført på listerne.

 

Da komponenten kan indgå i et system med flere indbyrdes afhængigheder, bør man være opmærksom på, at en opdatering af Log4j kan forudsætte opdatering af en række andre komponenter. Det kan blandt andet gælde den version af Java, der anvendes i applikationen.

 

Bemærk, at hvis man på nuværende tidspunkt opdager internetvendte systemer, der bruger én af de sårbare versioner (nyere end 2.0, men ældre end 2.15), kan der være en betydelig risiko for, at systemet er kompromitteret.

 

Søg eventuelt hjælp til afklaring af omfang i organisationen

Det vigtigt at bemærke, at ikke al software, der bruger Java, er sårbar over for denne Log4j sårbarhed. En afklaring af, hvorvidt organisations software er sårbar, ikke er en opgave, som alle kan gennemføre. Derfor anbefaler Center for CyberSikkerhed, at organisationen så hurtigt som muligt tager kontakt til deres softwareleverandører med henblik på afklaring.

 

Bemærk, at afdækningen bør ikke kun ske for internetvendte systemer, da angreb på disse potentielt kan brede sig til interne systemer gennem denne sårbarhed.

 

Det må forudses, at ikke alle software-løsninger kan opdateres inden for en kort tidshorisont. Derfor bør organisationen overveje om der kan iværksættes supplerende tiltag, der kan begrænse risikoen for kompromittering.

 

På nuværende tidspunkt er der publiceret en række tekniske tiltag, som kan være svære at indarbejde for en ikke teknisk kyndig. Det anbefales derfor organisationer, at de om nødvendig entrerer med virksomheder, der råder over de relevante kompetencer eller ressourcer.

 

Øvrige tiltag til begrænsning af sårbarheden

Derudover kan der være en række tiltag, man kan iværksætte for at reducere risikoen, hvis man har systemer, der muligvis kan være sårbare, eller systemer, hvor det ikke er muligt at opdatere Log4j inden for en kort tidshorisont.

 

Potentielt sårbare systemer kan isoleres fra de øvrige systemer. Det gælder også systemer, der har internetadgang og er placeret i en DMZ. For at reducere risikoen for, at en kompromittering kan udnyttes til at få adgang til andre systemer, bør de potentielt sårbare systemer placeres på særskilte segmenter eller VLAN.

 

Udgående trafik kan monitoreres og begrænses. Sårbarheden kan udnyttes ved få serveren til at hente og afvikle et ondsindet script. Ved at blokere eller som minimum monitorere den udgående trafik (egress), kan denne vektor begrænses eller overvåges. Det gælder særligt udgående trafik, som initieres fra en server i DMZ.

 

Eksempelvis kan man monitorere efter udgående trafik mod IP-adresser, hvorfra der er set forsøg på at udnytte sårbarheden i brede scanninger. Se for eksempel denne liste fra Grey Noise.

 

LDAP-forespørgsler saniteres, filtreres eller monitoreres. Sårbarheden findes i en funktion i Log4j, der kan sende en forespørgsel til en LDAP-server. Forsøg på misbrug kan potentielt opdages og begrænses ved at opstille regler for monitorering eller filtrering af LDAP-forespørgsler.

 

Begrænsning af opslag for Log4j version 2.10 til 2.14. Hvis man ikke kan opgradere Log4j til version 2.17 eller 2.12.2, men anvender en anden version mellem 2.10 og 2.14, kan man sætte en parameter ved opstart af Java Virtual Machine (JVM):

 

-Dlog4j2.formatMsgNoLookups=true

 

Alternativt kan man sætte en variabel i afviklingsmiljøet (environment variable):

 

LOG4J_FORMAT_MSG_NO_LOOKUPS="true"

 

Specifikt kan man for versioner fra 2.7 og op til 2.14.1 ændre PatternLayout patterns fra blot at konvertere beskeder som %m til i stedet %m{nolookups}.

 

For versioner fra og med 2.0-beta9 til og med 2.10.0 kan man fjerne klassen JndiLookup fra classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.

 

Dette varsel vil blive opdateret, hvis der kommer nye oplysninger.