Sikkerhet på agendaenFagdag sikkerhet 22.10.22

Lørdag 22. oktober samlet vi store deler av selskapet og busset opp til Scandic Park Holmenkollen for en fagdag fullstappet med læring, kos og hygge. Vi hadde for anledningen hyret inn selskapet Binary Security – et selskap som spesialiserer seg på penetrasjonstesting og applikasjonssikkerhet, til å kjøre det faglige opplegget. Og det til stor bravur.

I høst slo vi oss sammen med det svenske selskapet OmegaPoint – som spesialiserer seg på cybersikkerhet og sikker utvikling. Dette ble vårt første, men langt fra siste, faglige samarbeid med våre nye svenske kolleger. Nesten 20 av våre nye kollegaer hadde tatt turen til Oslo, og sammen med over 60 ITverkere, utgjorde vi majoriteten av klientellet på Scandic Park Holmenkollen denne lørdagen.

Selv om vi kanskje var de flinkeste på data der, var vi langt fra de sprekeste. Norges Skiforbund - med dame og herrelandslaget i langrenn hadde også samme base denne helgen. Det ble derfor første gang, og kanskje siste gang, at vi spiste samme buffet som flere olympiske mestre. Det var litt artig, for en mann som er over gjennomsnittet opptatt av snø og folk i trikot.

Det var en digresjon, så nå skal vi rette snuten tilbake mot det dere har klikket dere inn for å lese om.

Vi møttes alle sammen grytidlig lørdag 22.10, kl 0830 på Thon Hotel Opera. Det har liksom blitt vårt faste møtepunkt for ekskursjoner som involverer bussing. Derfra ble vi busset opp til Scandic Park Holmenkollen – og rammene var helt perfekte. Det var fint og kaldt høstvær, klar himmel og nydelig utsikt. Selv om det var en del trøtte tryner (undertegnede inkludert), så ble posene under øynene raskt strammet opp da vi fikk servert redbull, kaffe og diverse andre sukkerholdige godbiter til "frokost".

Klokka hadde bikka 0930, og vi var klare for å starte med det faglige, og hengi oss til Binary Security sitt opplegg, denne dagen representert ved Torjus Bryne Retterstøl, Haakon Holm Guldbrandsrud og Christian Håland.

Første faglige bulk ble delt opp i to områder:

OpSec og AppSec.

Hva dette betyr skal dere få vite om noen få strakser.

Utviklere er ofte enkle og yndede mål for hackere, fordi vi ofte har rettigheter andre brukere ikke har. Det kan være administratorrettigheter, sudoer, rettigheter på servere, tilgang til kildekode, bygg og deploy pipelines, eller høye rettigheter i AD eller skytjenester. I tillegg installerer vi mange dependencies som kan fungere som angrepsflater for folk som ikke vil oss godt. Det kan for eksempel være sløvhet i hva man legger inn, det kan være utdaterte dependencies, eller det kan være at det har gjort ondsinnede pull requests mot dependencies som brukes, som ikke har blitt fanget opp. De som vedlikeholder eksterne pakker vi bruker trenger heller ikke ha rent mel i posen, og kan også introdusere sårbarheter. Vi ble introdusert for et angrep som kalles "dependency conflusion" – som dere kan lese mer om her: https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610

Og når vi først har blitt bevisstgjort hvilke sårbarheter vi som utviklere kan ha, så vil vi jo gjerne prøve å gjøre noe med det. Neste punkt på agendaen handlet derfor om hvilke tiltak vi selv kan gjøre for å minske sannsynligheten for å bli hacket samt redusere angrepsflaten.

• Beskytt maskinen din ved å kryptere disk, patche når det trengs, og ha brannmurinnstillinger på.
• Sterk autentisering og gode passord.
• Vær skeptisk til andres kode når det kommer til for eksempel dependencies. Ikke stol på folk, er vel egentlig moralen her.

• Eksponer så lite som mulig. Konseptet "Least priviledge" handler om å gi absolutt minimum av hva som trengs av tilganger for å gjøre det som trengs. Er du usikker på om noen trenger en rettighet? Ikke gi den.
• Beskytt alle miljøer. Ikke bare prod, men dev og staging også.
• Sikre alt som eksponeres: Både ting som eksponeres på internett og andre nettverk som andre har tilgang til. Det kan for eksempel være et intranett. Dersom noen på jobben har tilgang til noe de ikke trenger, og har blitt kompromittert av en ondsinnet hacker, kan det få konsekvenser dersom denne brukeren har tilgang til ting som burde vært beskyttet. Å si at "ja, men det er jo bare folk jeg stoler på som har tilgang til dette", holder ikke nødvendigvis fra et sikkerhetsperspektiv.

I denne konteksten handlet AppSec om prosessen å finne, fikse og forhindre sikkerhetssårbarheter på applikasjonsnivå. Vi så på hvordan statisk og dynamisk analyse kan brukes for å avdekke sårbarheter i applikasjonene våre.

Statisk analyse (SAST – static application security testing) handler om å passivt søke gjennom kode, uten å kjøre den. Det er et tiltak som brukes for å kvalitetssikre det man skal levere, og når man kvalitetssikrer, så har man gjerne også et ønske om å forbedre det man avdekker. Statisk analyse er et steg i den retningen. Til statisk analyse kan man jobbe manuelt, men det er ofte også innebygde verktøy for å analysere kode i ulike IDE'er. Ved bruk av SAST har man tilgang til kildekoden. Dette kalles ofte white box testing, og kan for eksempel være en måte å avdekke svakheter i koden som kan lede til SQL-injections og andre angrepsflater.

Dynamisk analyse (DAST – dynamic application security testing) handler om å teste applikasjonen når den kjører, uten tilgang på kildekoden. Det blir ofte kalt black box testing. I tillegg til at man ikke vet noe om kildekoden, er også rammeverk og teknologi uvisst. Man kjører applikasjonen fra utsiden, så når man tester ser man det samme som en mulig angriper ser. Det gjør at man kan avdekke svakheter man ikke gjør ved SAST, som har blitt introdusert etter at utviklingsprosessen er ferdig. Det kan være run-time problemer, eller noe med environment relaterte problemer. Dette er mest brukt på webapplikasjoner og webtjenester.

Til slutt fikk vi med oss et godt tips:

• Bruk verktøy for SAST og DAST, men ikke tro at det er løsningen på alt. Alt har begrensninger, det gjelder også denne type verktøy

Neste område på agendaen var sårbarhetsklasser. Dette var også en liten pekepinn på hva som skulle komme på CTF-konkurransen vi skulle begi oss ut på etter lunsj. Et par av klassene vi gikk gjennom var:

• HTTP Request Smugling: Det kan dere lese om her https://portswigger.net/web-security/request-smuggling
• Server Side Request Forgery (SSRF): Det kan dere lese om her https://portswigger.net/web-security/ssrf

Veldig mange av oss sitter på prosjekter som benytter seg av skyteknologi på et eller annet nivå. Her har vi noen angrepsflater som er ekstra interessante for angripere:

• Storage accounts
• Key vaults
• Databaser

I Azure har man for eksempel ganske angriper vennlige innstillinger som default. Blant annet vil en storage account ha en "Network access" satt til "Enable public access from all networks" som standard – selv om de spesifiserer at det ikke er så lurt. Et tips er derfor: Sjekk network access når du oppretter en storage account, og begrens tilgang til kun de som absolutt trenger tilgangen. Minner her om prinsippet om "least privilidge".

Key vaults holder ofte på nøkler som det er kritisk at andre ikke får tak i. Det kan være nøkler til databaser, API'er, krypteringsnøkler eller storage accounts. I tillegg har databasene ofte det angriperne har aller mest lyst på. Det kan være alt mulig – litt avhengig av slags applikasjon, men dreier seg ofte om brukernavn, passord og persondata som ingen andre skal ha tilgang til. Vær derfor veldig bevisst på hvordan man lagrer og beskytter sensitive hemmeligheter i skyen.

Med mye ny kunnskap i bagasjen, og litt mat i magen, var det tid for CTF. Her ble vi delt inn team på 4-6 personer, og det var et variert sett med oppgaver som fikk de fleste av oss til å klø oss ganske hardt i hodet. Noen av oppgavene var overkommelige, men andre var av det mer severdige slaget. Det hjalp litt da vi fant ut at temaet for noen av oppgavene var relatert til noen av angrepene vi hadde gjennomgått.

CTF'en varte resten av dagen og kl 17 kåret vi vinnerlaget og gikk gjennom løsningene på en del av oppgavene. En del av oss innså at noen av løsningene vi hadde prøvd var helt på jordet, mens andre sukket oppgitt ut over at de ikke hadde fått det til enda de var innmari nærme.

Vinnerlaget bestod av vår egen fagsjef Anders Kofoed, Vilde Johanne Leinonen, Amar Trebinjac, Håkon Anders Strømsodd og vår nye svenske kollega Lucas Åstrøm. De var helt overlegne, og stakk av med gavekort på henholdsvis Power og Löplabbet.

Dessverre var vinnerne så sultne og tørste at de rushet rett til bar og middag før vi rakk å ta bilde av de. Øyeblikket er derfor ikke fanget for evigheten, så dere blir nødt til å ta meg på ordet her.

Da CTF’en var unnagjort og vinnerne kåret spankulerte vi bort til loungen, mette på kunnskap, og tørste etter noe godt i glasset. Der satt vi og jazzet frem til middagen, og etter middagen ble vi busset ned igjen til kontorene våre hvor vi fortsatte til sola stod opp igjen. Det ble etter hvert en slags norsk-svensk landskamp der det var om å gjøre å holde lengst - og på et tidspunkt var det faktisk flere svensker på kontoret. Til vår store forargelse, og deres store glede.

Alt i alt en fin dag - stappet med god mat, bra fag, godt drikke og veldig hyggelig samvær!