Hvordan bør vi nærme oss Log4j-sårbarheten?
1. Lag en liste over eiendeler; Hvilke systemer er tilgjengelige fra Internett eller andre usikre soner som gjestenettverk og lignende. Spør deg selv – hvordan kan sårbarhet komme inn i virksomheten min?
2. Er det allerede en patch tilgjengelig for dine eiendeler? Få den installert så snart som mulig.
Se lenker til våre produsenter nedenfor. Disse listene inneholder løpende oppdateringer av systemer og produkter som enten er sårbare, ikke-sårbare eller under ytterligere etterforskning.
3. Hvis du ikke allerede gjør det, slå på full logging på brannmuren, nettverket, serverne, applikasjonene og tjenestene. Da kan vi se hva som har skjedd, dersom du skulle være så uheldig at sårbarheten har blitt utnyttet.
4. Gå aktivt gjennom loggene dine for sårbarhet. Loggstyringssystemer er enkle å søke i, og sårbarheten er sett helt tilbake til 2. desember.
Hva gjør jeg hvis en oppdatering ennå ikke er tilgjengelig for systemene mine?
Begrens Internett-tilgang fra dine servere til nødvendige ressurser som lisensiering, DNS og lignende. Du bør spesifisere både kilde og mål i brannmurreglene.
Dessverre finnes det en rekke muligheter for å utnytte sårbarheten, noe som avhenger mye av det sårbare systemet. Hvis sårbarheten eksisterer i en underliggende loggserver, for eksempel en SIEM, kan den underliggende serveren potensielt gi tilgang til virksomheten din, selv om den ikke er direkte eksponert for Internett. Derfor er det ikke nok å bare se på alle eiendelene som er eksponert direkte mot internett.
Husk å sjekke om din NGFW og proxy er oppdatert med de nyeste reglene, og at reglene er i kraft. Se tidligere innlegg: https://conscia.com/no/nyheter/sarbarhet-apache-log4j/
Dra nytte av alle våpnene i arsenalet ditt
Husk å bruke alle våpen i arsenalet ditt – Har du Stealthwatch, SIEM og Endpoint Protection som kan brukes til å spore og blokkere all bruk av Log4j? I så fall, bruk den.
Hvordan finner vi ut om utstyret vårt er sårbart?
1. Sjekk Conscias CNS. Hvis du har tilgang til Conscia Best Practice, kan systemet fortelle deg om du er potensielt sårbar. Manuell verifisering og analyse vil imidlertid fortsatt være nødvendig.
2. Følg med her:
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
Hva har skjedd siden sist?
Det begynner å bli en rekke ulike teknikker for å skjule angrepene, blant annet ved å omgå mønsterbaserte deteksjonsmekanismer (mønsterbaserte deteksjonsmekanismer), som IPS-regler. Produsenter jobber kontinuerlig med å håndtere disse endringene.
Vi begynner å se sårbarheten forsøkt utnyttet ved hjelp av SMTP. Tidligere har vi sett sårbarheten utnyttet på LDAP (S), RMI, DNS, NIS, IIOP, CORBAL, NDS, HTTP.
Log4j er utgitt i versjon 2.16.0. Du bør nok forvente mange oppdateringer i tiden som kommer, så alle kan dessverre risikere å måtte patche/oppdatere flere ganger.
Hvordan utnyttes Log4j-sårbarheten?
Dessverre er det mange angrepsvektorer på denne sårbarheten, inkludert noen få enkle eksempler:
En forespørsel sendes til en sårbar ressurs med (for eksempel) en tilpasset brukeragent, som inneholder følgende bane $ {jndi: [protokoll]: // [ekstern server og kjørbar kode]}
Den sårbare enheten oppretter en loggoppføring gjennom Log4j-rammeverket med den tilpassede User-Agenten
Log4j leser den tilpassede brukeragenten og sender et svar til den eksterne serveren.
Nedenfor er et enkelt eksempel.
Herunder et eksempel fra SMTP:
Kilde: https://blog.talosintelligence.com/2021/12/apache-log4j-rce-vulnerability.html
Øvrige kilder:
https://blog.talosintelligence.com/2021/12/apache-log4j-rce-vulnerability.html#more
https://conscia.com/dk/nyheder/kritisk-saarbarhed-i-apache-log4j/