Sårbarheter har eksistert så lenge det har eksistert kode. Men kan de rekke å bli misbrukt før du rekker å patche? Å ja.
Den nye Log4J sårbarheten, CVE-2021-44228, ble annonsert fredag 10. desember, og ble misbrukt allerede 12 timer etter annonseringen. I videoen SANS presenterte mandag 13. desember sies det at et foretak i England ble utsatt for ransomware som følge av denne sårbarheten allerede lørdag den 11. desember.
NCSC sier: Det er meldt om observasjoner av utnyttelse så tidlig som 1. desember 2021. Det er derfor et potensial for at trusselaktører kan ha utnyttet sårbarheten på et tidligere tidspunkt enn offentliggjøringen. Virksomheter bør derfor undersøke om berørte applikasjoner har tegn på kompromittering tilbake i tid, i hvert fall til 1. desember .
Zero day vulnerability og patching
En ukjent sårbarhet er som regel ufarlig så lenge ingen kjenner til den. Men så fort «noen» får kjennskap til den, begynner det å bli farlig (ref informasjonen fra NCSC). Om denne/disse «noen» ikke er produsenten, snakker vi om en 0-dagssårbarhet, som vil gå under radaren for de aller fleste. Den er ikke kjent av produsent eller sikkerhetsleverandører. Det finnes ingen patch, og heller ingen signaturer for gjenkjennelse eller beskyttelse.
Så fort en sårbarhet blir gjort kjent for en produsent, er det en uskreven regel som gir dem 90 dager på å komme med en fiks. I denne 90 dagers perioden skal melder ikke si noe om dette ut i markedet. Den dagen produsent melder om sårbarheten til markedet, sammen med en fiks, vil sårbarheten være kjent for allmennheten, inkludert de kriminelle. Og da kan det i en del tilfeller haste med å agere. Det å nå klokka starter. Tiden fra sårbarheten blir kjent til de kriminelle finner måter å misbruke dette på er kritisk. For CVE-2021-44228, Log4Shell sårbarheten, tok dette 12 timer. Kanskje enda mindre, som i at den ble misbrukt allerede før dette ble annonsert.
Og så patcher du. Hvor lenge etter at sårbarheten ble gjort kjent? Og, i dette vinduet, har de kriminelle rukket å gjøre noe? Har du merket det? Du patcher, sårbarheten er borte, men det kan allerede være for sent. Hvordan vet du det? Når vet du det? Har de kanskje allerede etablert en bakdør, som de om noen måneder vil misbruke for f.eks ransomware? Det opplever vi i markedet, kanskje 6 måneder etter vinduet fra en sårbarhet ble kjent til den ble patchet 4 dager senere.
Tenk at du var for sen, hele tiden
Tenk at du er for sent ute hele tiden, og at de kriminelle allerede har misbrukt sårbarheten og er på innsiden. De har etablert fotfeste, men ikke nødvendigvis gjort noen skade enda, eller har de det? Har de startet å utnytte deg for cryptomining, noe du kanskje aldri oppdager. Kanskje de har startet å hente ut informasjon, som del av spionasje, eller forberedelse før en dobbelt utpressingssak. Denne prosessen kan ta uker eller måneder. Vi har sett tilfeller der det kan gå over 6 måneder fra misbruk av sårbarhet, med etablering av bakdør, til ransomware, som endte i en dobbelt utpressingssak. Uten tilstrekkelig logging, overvåking og alarmering, er det vanskelig å være helt sikker.
Helhetlig sikkerhet, som om du var for sen
Se NSM Grunnprinsipper for IKT-sikkerhet og Zero Trust (Assume Breach) for mer informasjon om dette emnet.
Patching er viktig. Veldig rask patching er noen ganger veldig viktig. Det er vinduet fra kjennskap —> patching som er veldig viktig. Viktig å vite hva man har, for å vite hva man skal patche. Helhetlig sikkerhet er viktig, alltid. Mindset er viktig i denne sammenheng. For om man antar at noen allerede er på innsiden, vil man automatisk begynne å tenke annerledes. Hva kan de få tilgang til? Hva har de allerede gjort? Har de beveget seg? Er de ferdig med å misbruke sårbarheten (uavhengig av software sårbarhet eller manglende MFA)
- Kan de nå andre servere?
- Er det tilstrekkelig segmentering i datasenteret for god tilgangskontroll mellom DMZ og domenekontroller?
- Er servere unødvendig tilgjengelig på RDP?
- Er det MFA for RDP tilgang, også for interne servere? For er de på innsiden, er MFA viktig. Det viser seg stadig vekk.
- Hvordan er sikkerheten på backupserveren? Har backupserveren internettilgang? Hva trenger den mot internett?
- Er det etablert offline backup? Kommer de seg på innsiden, og sletter backupen din, er dette et viktig punkt.
- Er det etablert offline/ekstern logging? Skjer en hendelse, er logger meget sentralt, derfor viktig å sikre at disse er tilgjengelige.
- Kan de etablere en bakdør mot internett? Hva er tillatt fra serverne mot internett?
- Hvilke brukere har hvilke rettigheter? Har en vanlig bruker administrator rettigheter?
- Hva sier loggingen? Har vi en analyseløsning på plass?
Listen er lang, og lengre enn nevnt. Det viktige er tankesettet rundt trusselbildet, og ha respekt for det. Det kan være en ny sårbarhet, ref Log4J, eller det kan være en fjernaksessløsning uten MFA, ref Østre Toten kommune. Uansett sårbarhet er det liten tvil om at de kriminelle kommer seg på innsiden, og at man på bakgrunn av det må ta høyde for nettopp det. Gjør man det, vil en sårbarhet som Log4Shell plutselig bli mye mindre alvorlig. Uten dette tankesettet, de nevnte tiltak, og flere, blir det gjerne katt og mus, armer og bein, stress og høy puls.
Hvitelist utgående servertrafikk
Et eksempel på et regelsett som hvitelister trafikk fra en Ubuntu server mot internett. Dette regelsettet ville hindret misbruk i forbindelse med Log4J for denne serveren:
Tilsvarende regelsett benyttes mellom servere i datasenteret for på den måten å redusere angrepsflaten. Det er opp til oss.
