Zero Trust Soldier

17. desember 2024 ble det oppdaget mistenkelig aktivtet i nettverket til Gran kommune. Etter det skjedde ting raskt, og tiltak ble innført.

Denne artikkelen handler IKKE om å kaste Gran kommune under bussen, da dette kunne skjedd mange, men målet er å dele relevant informasjon mer komprimert slik at tiltak forhåpentligvis blir innført for enda flere, slik at man reduserer sannsynligheten betraktelig for at slikt kan skje andre.

Dette handler heller ikke om å være etterpåklok, da dette er gamle grunnleggende anbefalinger, som allikevel mangler hos veldig mange, dessverre.

Jeg anbefaler alle å se disse to webinarene med relevant informasjon, og det er disse to jeg har brukt som utgangspunkt for denne artikkelen:

17. januar 2025 presenterer Norsk helsenett “Tilbakeblikk og tertialbrief”. I dette webinaret kom det frem tekniske detaljer som ikke er med den 24. januar 2025, noe som bidro til at jeg skrev denne artikkelen.

Her tar man for seg Gran kommune hendelser fra 06:00. Fra 09:10 presenteres det tekniske detaljer som jeg ikke var klar over, og som har stor betydning for hendelsen:

• En sårbarhet ble misbrukt på en tjeneste (webinaret 17. januar 09:10), som i webinaret den 24. januar 07:36 (link til nedenfor) forklares at skjer på en Unified Access Gateway, som igjen gir tilgang til en VMware Horizon view server. Om selve sårbarheten eksisterte på UAG eller Horizon sies det ikke noe om, men jeg velger å gjette på View serveren.
• Denne tjenesten var opprinnelig satt opp for en tredjepart leverandør, og var opprinnelig bare tilgjengelig fra en eneste IP. Grunnet ønske om å kunne nå dette også fra hjemmekontor, ble det åpnet for hele internett, da geofencing ikke var supportert på brannmuren.
• Den store åpningen gjorde Gran kommune meget eksponert, som da viste seg å bli inngangen for de uvedkommende.

Her forklares angrepet fra 05:23:

• 24. januar 24:45:
  • Kl 00:10 den 10. desember 2024 fikk aktørene fotfeste på server og installerte VNC.
  • Kl 00:18 dumpes passordhasher (Lsass)
  • Kl 00:25 beveger de seg til en filserver, men det sies ikke noe om hvordan dette ble gjort, om det var RDP eller SMB, ei heller om disse serverne var i samme nett.
  • Fra 00:25 når det ble etablert fotfeste på filserveren ble det lastet ned en haug med verktøy.

• 15. desember ble det opprettet fotfeste på domenekontroller. Det sies ikke noe om graden av segmentering eller protokoll.

27/2-2025. Her er en reklameartikkel fra Defendable som forklarer enda mer:

• https://www.digi.no/tumstudio/dataangrep/annonse-dette-var-grepene-som-reddet-gran-kommune-fra-en-potensiell-katastrofe/556063
• Nesten nøyaktig tre år før den ansatte hos Gran oppdaget at uvedkommende hadde tilgang til systemet deres, satte en sårbarhet kalt Log4Shell IT-verdenen på hodet.
• Serveren hos Gran kommune, som tidligere kun var tilgjengelig fra det interne nettverket og fra nettverket til noen få andre aktører, var ikke patchet.
• Det tar ikke lang tid før det blir avklart at Log4Shell-sårbarheten var den initielle angrepsvektoren.

Konklusjon

Var angrepet målrettet eller tilfeldig? Det sies det ikke noe om, men jeg velger å anta at det var tilfeldig, som det veldig ofte er, og det har stor påvirkning mtp effekt av noen tiltak nevnt nedenfor.

Vi ser at utnyttelse av kjente sårbarheter i internetteksponerte tjenester er en veldig vanlig inngangsvektor for trusselaktører. De scanner jevnlig alt de finner av tilkoblede enheter for å lete etter noe de kan utnytte (Defendable)

Man kan komme med mange reaktive anbefalinger, som bl.a innholder å patche, som naturligvis er viktig, men det kan være for sent.

Så la oss se på “engangsjobbene” som bygger en solid proaktiv sikkerhet:

• Begrens inngående kommunikasjon med Least Privilege for å redusere angrepsflate.
  • Dette var bra hos Gran kommune ved at de kun tillot én IP adresse, men ble det sårbart ved utvidelse av tilgang grunnet manglende geofence funksjonalitet på brannmuren og mangel på alternative tiltak. Hadde tilgang vært begrenset til kun Norge, ville denne hendelsen kanskje vært unngått, men det sies ikke noe om fra hvor angrepet skjedde fra. Uansett er dette et meget viktig tiltak som er enkelt å innføre.
  • I tillegg anbefales det å kjøre Least Privilege med URL match, slik at angripere ikke kan nå tjenesten kun med IP, men de må vite navnet på tjenesten. URL tiltaket har vist seg å være meget effektivt for mange kunder dette er innført på. Om vi antar at angrepet mot Gran kommune var tilfeldig, gikk nok kommunikasjonen mest sannsynlig med IP som host, og ikke korrekt hostnavn.
• Om brannmuren i det hele tatt hadde IPS funksjonalitet sier webinarene ingenting om, og om den hadde det, sies det heller ikke noe om den hadde signaturen for den sårbarheten som ble misbrukt.
  • Uansett vil det være anbefalt å ha SSL dekryptering for all inngående trafikk slik at IPS modulen kan gjøre sitt beste, og kanskje i dette tilfellet ha avverget hendelsen. Alle dagens moderne brannmuren, som “alle” har, har støtte for dekryptering. Alle disse brannmurene har også IPS funksjonalitet, noe så og si alle har tilgjengelig.
• Aktivering av dekryptering er for inngående trafikk mot tjenester meget enkelt å aktivere, men er det allikevel ikke så veldig ofte, noe som er veldig synd og gjør store deler av investeringen i en moderne brannmur bortkastet da den ikke kan se hva som skjer, og da heller ikke bruke sine funksjonaliteter. Denne delen av trafikken har som regel ingen verdens ting med GDPR å gjøre og burde bare aktiveres med en eneste gang.
  • Det har tidligere vært flere misbruk av Microsoft Exchange servere, lenge etter at sårbarheter har blitt kjent, og de kunne vært stoppet om dekryptering hadde vært aktivert.

Til nå har vi kun snakket om inngående sikkerhet, og dette ville med høy sannsynlighet avverget hendelsen. Men la oss anta at det ikke gjør det, hva da?

• Begrens utgående kommunikasjon fra servere med Least Privilege. Dette er VG testen område. Dette nevnes også som den første anbefalingen for nettverkssikkerhet i webinaret den 24. januar 24:45.
  • I webinaret den 24. januar 05:25 forklares hendelsen, og kl 00:10 den 10. desember 2024 fikk aktørene fotfeste på server og installerte VNC. Dette burde ikke vært mulig ved å begrense utgående kommunikasjon (VG testen).
  • Kl 00:18 dumpes passordhasher (Lsass), noe som også burde vært stoppet med kontroll på utgående kommunikasjon (VG testen).
  • Kl 00:25 beveger de seg til en filserver, men det sies ikke noe om hvordan dette ble gjort, om det var RDP eller SMB, ei heller om disse serverne var i samme nett.
    • Segmentering. Da det ikke nevnes om de er i samme nett er det vanskelig å konkludere, men de burde ikke være det, da den første serveren skulle være tilgjengelig fra internett, og derfor burde eksistere en en DMZ, mens filserveren helt klart burde være i en annen sone. Det oppleves ofte meget svak segmentering ute i markedet, så her eksisterer det mange sårbarheter.
  • Fra 00:25 når det ble etablert fotfeste på filserveren ble det lastet ned en haug med verktøy. Dette burde vært stoppet ved å begrense utgående kommunikasjon fra servere med Least Privilege (VG testen).

• 15. desember ble det opprettet fotfeste på domenekontroller. Det sies ikke noe om graden av segmentering rundt denne, ei heller hvilken protokoll som ble benyttet. Om dette foregikk på RDP, kan man spørre seg “trenger en filserver RDP tilgang til domenekontroller?”, og har man mulighet til å begrense det?

Kort oppsummering

• Begrens inngående kommunikasjon med Least Privilege, inkludert URL match.
  • Ville mest sannsynlig avverget Gran kommune hendelsen fullstendig.
• Aktiver SSL dekryptering for inngående kommunikasjon for å utnytte IPS best mulig.
  • Kunne kanskje avverget hendelsen fullstendig.
• Begrens utgående kommunikasjon for servere med Least Privilege inkludert URL match. Kjør VG testen “kan dere surfe på VG fra servere eller OT maskiner er sikkerheten for dårlig!”
  • Ville mest sannsynlig avverget hendelsen.
• Sikre tilstrekkelig segmentering mellom ressurser og innfør Least Privilege mellom segmentene.
  • Kunne kanskje avverget deler av hendelsen.
• Sikre Multi Faktor Autentisering alle steder, for administratorer OG brukere, også internt.
  • RDP benyttes ofte av uvedkommende for å bevege seg rundt, og mangler som regel MFA. Fiks det, fiks det nå.
  • RDP ble benyttet fra internett og inn, som administrator, mest sannsynlig uten krav om MFA. MFA ville mest sannsynlig vanskeligjort ting slik at det måtte benyttes andre teknikker. Kanskje MFA hadde avverget hendelsen.

Alle tingene på denne listen er proaktive og preventive tiltak som i all hovedsak er engangsjobber og vil har langtidsvirkende effekt, og burde vært høyt på todo listen alle steder. Kjør en revisjon, og gjør det nå.

Tusen takk til Gran kommune og Helse/Kommune CERT som har gjort den meget viktige jobben med å dele, slik at vi kan lære.