FagdagAppSec og OpSec for utviklere

16.november var det duket for en fagkveld med fokus på applikasjonssikkerhet og operasjonssikkerhet for utviklere. DevOps-tankegangen med korte iterasjoner har ført til at utviklere i større grad har ansvar for å sikre løsningene de er med på å utvikle, og det holder i mange tilfeller ikke kun å belage seg på kunden sine sikkerhetstiltak. To (av to mulige) sikkerhetstestere fra BinarySecurity ga oss tips til gode tiltak, forklarte typiske angrep og vi fikk prøvd oss på litt hacking. I trygge omgivelser, selvsagt.

Selv om det var lørdag og jobbfri stoppet det ikke 43 ivrige ITverkere fra å lære noe nytt og tilbringe fridagen med gode kollegaer. Tidlig på morgenen ble vi fraktet med buss opp til eventyrlige Scandic Holmenkollen Park hotell. Her stod Christian August Holm Hansen og Christian Håland fra BinarySecurity klare. Vi erfarte at de ikke bare er flinke til å finne bugs, men de er ganske rå til å holde kurs også.

Vi fikk innblikk i hvordan Christian 1 og Christian 2 (Slapp av, det er helt tilfeldig hvem av dere som fikk nr 1. Dere var like flinke, altså) går frem når de skal finne sikkerhetshull hos kundene sine - og hvordan de kan hacke utviklere. De starter de med å scanne nettverket for å finne svakheter og inngangsporten kan ofte være en sårbar applikasjon.

Tidlig i presentasjonen fikk noen trøtte tryner presentert følgende utsagn; “Utviklere er perfekte mål for hackere”. Om noen ITverkere enda ikke hadde våknet helt gjorde de det hvertfall nå. Bakgrunnen for dette utsagnet er at utviklere i det fleste tilfeller har admin-rettigheter og tilgang til blant annet utviklings- og produksjonsservere, kildekode og bygg-pipeline. I tillegg er systemene og løsningene ofte sårbare siden de er under utvikling. Når et system først har blitt hacket kan dette resultere i at man får tilgang til flere systemer. Grunnen til dette er at det i noen tilfeller kan være et diffust skille mellom prod- og testmiljøer. Et eksempel på dette er at man kan man få tak i et passord i dev-miljøet som gir tilgang til prod-miljøet, eller herfra få tilgang til andre interne systemer. I slike tilfeller er det bare å ønske lykke til.

Kunden, som mange andre, klarer ikke tenke på alt. Man kan derfor ikke kun belage seg på kundens egne sikkerhetstiltak, men må også iverksette tiltak selv. Vi ble gjort oppmerksomme på vanlige DevOps-feil og fikk tips om hvordan sikre egen maskin og utviklingsprosessen. En av flere svakheter som ble presentert var at staging-miljø på nett gjør det enkelt for en tredjepart å aksessere det. Det ble også vist et eksempel der Christian 1 fikk tilgang til en Jenkins-server, et verktøy brukt for kontinuerlig integrasjon, med credentials. Det viser seg at Jenkins har mange sårbarheter og at sikkerhetsinnstillingene ikke er slått på som default. Christian 1 utførte et “Pass the hash”-angrep i et slikt miljø. Han autentiserte seg til serveren ved bruk av verktøyet Mimikatz og en NTML-hash. Her trengte man altså ikke passordet i klartekst for å få tilgang til systemet, kun hashen til et passord.

Det ble også poengtert at det er viktig å ha et forhold til bruken av 127.0.0.1 vs. 0.0.0.0. Man bør alltid kjøre applikasjonen på localhost (127.0.0.1) under utvikling. Bruk av 0.0.0.0 vil si å kjøre på alle interfaces på en maskin, noe som resulterer i at alle maskiner som er på samme nett kan aksessere applikasjonen. I slike situasjoner er det lett å hacke. Alle tjenester bør derfor kjøre på localhost når man tester. Da er applikasjonen kun tilgjengelig for den datamaskinen, og man bør sjekke med jevne mellomrom at dette er satt. Men man er ikke helt sikret med 127.0.0.0. Dersom tjenesten som kjører her har sårbarheter, for eksempel tar imot kommandoer, kan man fortsatt være utsatt for angrep (f.eks. DNS rebinding og Privilege escalation). Det anbefales å bruke en lokal brannmur, og ikke tillate nettverkstrafikk inn på maskinen, som et ekstra sikkerhetslag dersom annen nettverksbeskyttelse feiler.

Det var klart at svært mange laster ned kildekode ukritisk til bruk i utvikling. Man tenker det sparer tid og at det som oftest går fint, men også her er det viktig å være oppmerksom. En annen ting man må ha i bakhodet som utvikler er at kildekode kan inneholde hemmeligheter og at det kan være enkelt for tredjeparter å finne testfunksjonalitet eller sårbarheter i kildekode. Det er derfor nødvendig å fjerne hemmelig data i binærfiler som skal publiseres eller sørge for at kunden ikke publiserer binærfilene. Det ble også anbefalt å bruke krypteringsnøkler, som for eksempel Microsoft Azure Key Vaults, for å sikkert lagre data og kontrollere tilgang til sertifikater, passord og tokens.

Med teorien på plass var det endelig klart for “Capture The Flag”-konkurranse (CTF). Vi fikk bryne oss på oppgaver hvor vi fikk testet angrep som SQL-injection, Domain Hijacking og SSRF. Ved bruk av BurpSuite, et verktøy for sikkerhetstesting, og Firefox-nettleser pluginen FoxyProxy for å gjøre det mulig å lese og manipulere nettverkstrafikk. Noen oppgaver var vanskeligere enn andre. Å velge lagnavn var definitivt den letteste. Det er ingen tvil om at konkurranseinstinktet er høyt hos samtlige ITverkere, og man kan trygt si at konkurranse og spennende oppgaver er svært viktige faktorer for læring.

Alt i alt var fagdagen en stor suksess og vi sitter igjen med ny kunnskap som vi absolutt vil dra nytte av som utviklere i en tid der datasikkerhet må prioriteres høyt. Dobbel takk til dobbel Christian for en utrolig lærerik og morsom dag!

Til slutt var det tid for påfyll av helt andre ting. Ta det med ro, tørsten ble slukket...