Sårbarhet i Log4j, #log4shell

Potensielle trusler blir tatt på største alvor. Her kan dere bli med oss bak kulissene og finne ut hvordan vi har håndtert den verdensomspennende Log4j-sårbarheten internt i Tripletex.

Fikset alle servere i Tripletex

Allerede den 9. desember oppdaget vi på Twitter at folk begynte å skrive om dette. Klokken 23:52 på torsdagskvelden var det rapportert internt at denne sårbarheten eksisterte og at Tripletex benytter seg av log4j2.

Fredag morgen begynte vi å analysere problemet og klokken 11:13 var alle serverne i Tripletex fikset slik at vi ikke lenger var sårbare. Den første fiksen var å restarte serverene med parameteret formatMsgNoLookups satt. Dette gjør at log4j ikke lenger skal tolke teksten som vi logger for å gjøre oppslag mot eksterne sider. Våre to backend jobbservere ble, for ikke å hindre lønnsjobber og lignende, oppdatert natt til lørdag.

Det var og er bekreftet at Java-version 11.0.1 og oppover ikke var påvirket. Ettersom vi bruker Java 11.0.7 så var derfor ikke dette et problem for oss. Oppslag hadde blitt utført mot eksterne sider, men det ville uansett ikke blitt kjørt noen kode fra denne siden. Likevel tok vi dette på høyeste alvor og fulgte opp nøye videre. 

Den 16. desember oppgraderte vi til log4j 2.16.0. Ettersom vi allerede hadde fikset feilen i produksjonsmiljøet vårt, tok vi oss god tid for å verifisere at denne versjonen fungerte for oss og hvordan vi logger – noe den gjorde.

Vi planlegger også å oppdatere til 2.17.0 i dag, mandag 20. desember, da dette løser et såkalt DOS-problem (Denial of service), på den komponenten som vi ikke benytter oss av. Dette gjør vi for å være oppgradert til aller siste versjon.

Når det gjelder andre tjenester som benytter seg av log4j så har vi gjort følgende:

Elastic search. Her har vi et antall ulike instanser som håndterer ulik funksjonalitet

• search.tripletex.no. Denne tjenesten brukes av Tripletex for å søke i hjelpeteksten. Denne er direkte tilgjengelig fra internett, men ligger på egen server og eget nettverk, sånn at den har ikke tilgang til noe andre tjenester i Tripletex. Vi oppdatert denne med parameter formatMsgNoLookups den 10. og den 17. oppdaterte vi instansen med å fjerne den delen av log4j som har sårbarheten.

• Intern logghåndtering, alle logger vi har i Tripletex lagres i en intern elastic search som ikke er tilgjengelig fra Internett. Denne var og satt opp med parameteren formatMsgNoLookups den 10. Den versjonen av Elastic Search sammen med versjonen av Java som brukes for Elastic er ikke påvirket. Men vi kommer i nær framtid til å oppgradere disse instanser uansett til nyere versjoner av log4j.

Sonar Qube. Denne tjenesten benyttes ved bygging av Tripletex for å oppdage ulike varianter av feil i koden vår. Blant annet sikkerhetsfeil, vårt oppsett av Sonar Qube, er ikke tilgjengelig på internett. Og det kommer ikke inn noen brukergenerert data inn til den som kan logges, da den kun sjekker kildekoden vår. Derfor er den ikke utsatt siden ingen eksterne kan utnytte sårbarheten. Vi kommer uansett å oppdaterere vår Sonar Qube sånn at den ikke lenger har denne sårbarheten.

I tillegg til å oppgradere våre tjenester slik at de ikke er sårbare, så har vi også begynt å se på våre logger for å se om noen har forsøkt å utnytte sårbarheten i Tripletex. Dette arbeidet går ut på at vi starter fra “dagens” dato og arbeider oss bakover i tid. Dette er tidkrevende da dette problemet har vært tilstede noen år, men vi ser absolutt ingen tegn til utnyttelse per nå.