- Det er flere tilfeller der jeg ikke har innsett potensielle problemer med egne løsninger, før jeg har klart å finne problemet i andres oppsett, sier Jon Are Rakvåg, dusørjeger og utvikler i SpareBank 1, til kode24.
Til daglig jobber Rakvåg for at SpareBank 1 skal unngå sårbarheter, oppdage og håndtere problemer.
- Det er givende, men kan bli litt teoretisk og abstrakt. Det er også så mye som kan gå galt, så hvordan kan man vite hva man bør fokusere på? Da er det veldig nyttig å kunne ta på seg "red team-drakta", og gå å gjøre sitt beste for å herje med andres løsninger.
- Med litt erfaring fra den siden av bordet, får man raskt et bedre bilde på hva som fungerer og ikke.
Dusørjegeren Roy: - Vi er fullstendig bakpå når det gjelder å sikre IT-systemer
Slik vant han sin første dusør
Rakvåg startet med bug bounties i 2019. Det første han hadde noe særlig suksess med, var da han satt seg ned og leste James Kettles forskning på HTTP Request Smuggling.
- Det er en artig teknikk, der man kan forvirre en kjede med HTTP-servere eller proxyer om hvor en request slutter, og den neste begynner.
Han brukte en uke på å forstå det skikkelig ved å lese whitepaper, "gjøre labs" og eksperimentere. Etter dette testet han akkurat den problemstillingen i en rekke programmer.
- Jeg husker fortsatt hvor overrasket jeg var da nesten den første angrepskjeden jeg prøvde bare virket. Plutselig satt jeg der med en annen brukers HTTP-request lagret til min profil, med autentiserings-cookies og alt. Og mine første 1.500 dollar i bounty, sier Rakvåg.
«Det starter alltid med den automatiserte jobben, men så går det ned i funksjonell testing med Burp Suite.»
Morsomste feilen
Det artigste funnet til Rakvåg skjedde i år, med et angrep han skrev i 2021.
- For å rydde diskplass gikk jeg gjennom gamle Burp Suite-prosjekter, for å se hva som kunne slettes. Da kom jeg over en request jeg hadde lagd med en ugyldig kombinasjon HTTP-headere.
Han ble nysgjerrig på om han ville få en feilmelding, så han trykket på "Send".
- Angrepet hadde ikke virket i 2021, men siden den gang må de ha gjort endringer, for i 2022 gikk det rett gjennom som SSRF. Det ga i sin tur admin-tilgang til en rekke baksystemer, samt Remote Code Execution (RCE). Det betyr at jeg som angriper kunne kjøre min egen kode på deres server, og regnes gjerne som gullstandarden for "nå har det gått skikkelig galt".
Starter med automatisert jobb
Det er to hovedretninger i måten Rakvåg jakter på.
- Jeg gjør marginal, delvis automatisert testing i mange av de private programmene jeg blir invitert til. Da bruker jeg subfinder for å finne aktuelle subdomener, httpx for å besøke alle potensielle webservere, og noen bash-script for å hjelpe meg se etter interessante patterns. Jeg lagrer også alle responses, så om det plutselig skjer noe interessant med spesifikke produkter eller servere, så kan jeg grep'e etter dem på lokalt filsystem.
Den andre og viktigere hovedretningen er testing i dybden, forteller Rakvåg. Han sier at det er et fåtall programmer som har systemer han etter hvert har blitt veldig godt kjent med.
- Det starter alltid med den automatiserte jobben, men så går det ned i funksjonell testing med Burp Suite. Det kan gå av og på over lang tid, og jeg bruker dem gjerne som mål for tema jeg konsentrerer meg om. Eksempler er path traversal i en periode, så Server Side Reqest Forgery (SSRF), og så kryptoanalyse, gjerne i flere iterasjoner. Nå tenker jeg at jeg bør bli bedre i automatisert testing etter SQL injections, og discovery i "IP-ranges", sier Rakvåg.
«Både utviklerne og dem som styrer utviklernes tid og ressurser må faktisk mene at sikkerhet er en vesentlig egenskap i løsningene man bygger, og reelt sett prioritere det høyt nok»
Har fagdag hver uke
Ifølge Rakvåg bruker han alt fra ingenting til seks eller syv timen i uken på å jakte feil. Fortjenesten kan variere fra noen måneder med ingenting, til å plutselig finne et kjempeproblem og få tusenvis av dollar.
- Jeg har barn og analoge hobbyer, så dette begrenser seg selv. Redningen er i stor grad at SpareBank 1 Utvikling har fagdag hver uke, sier han.
På fagdagen kan utviklere sette seg ned å bruke tid på å utforske verktøy eller skrive sine egne, teste teorier, lære nye teknikker, se foredrag og grave i egne og andres sikkerhetstiltak.
- Det at vi nå driver vårt eget bug bounty-program, er også et direkte resultat av denne fagtiden. Før COVID stengte ned alt, hadde vi også noen forsøk med felles bug bounty-testing, der interesserte utviklere satt sammen og jaktet andres sårbarheter på storskjerm. Det må vi prøve igjen! sier Rakvåg.
Dusørjegeren Thomas jakter feil 10 timer i uka: - Viktig med klare retningslinjer
Rakvågs viktigste verktøy
- Hva er de viktigste verktøyene dine?
- Hovedverktøyet er Portswigger Burp Suite. Det er en http-proxy som sitter mellom nettleseren og webtjenesten, så man får full kontroll på trafikken mellom klienten og serveren, der man kan lese og manipulere alt. Og selvsagt bug bounty-plattformene. Jeg er registrert hos Intigriti, HackerOne og Bugcrowd, sier Rakvåg.
Den feilen Rakvåg har hatt mest suksess med er Server Side Request Forgery (SSRF). Det skjer når man kan få en server eller proxy til å gjøre uventede requester til andre servere eller endepunkt på innsiden av nettverket.
- Siden det ikke er meningen at de skal kunne nås fra internett, er de ofte mindre herdet enn det som lever eksponert. Noen ganger har de ingen sikkerhet i det hele tatt. Når en eksponert tjeneste kan lures slik, så bryter hele skallsikringen sammen, sier han.
De vanligste utviklerfeilene
- Hva er de vanligste feilene utviklere gjør?
- Hva utviklerne gjør mest feil svarer vel OWASP Top 10 greit på, men jeg syns det er minst like interessant hva utviklingsorganisasjonene gjør feil.
Rakvåg mener at en absolutt forutsetning for å lykkes med å håndtere sikkerheten riktig, er at sikkerhetskulturen sitter i veggene.
- Både utviklerne og dem som styrer utviklernes tid og ressurser må faktisk mene at sikkerhet er en vesentlig egenskap i løsningene man bygger, og reelt sett prioritere det høyt nok. Syretesten er kanskje hvor enkelt det er å få fikset en sårbarhet man faktisk vet om.
«Tenk litt over hva som sannsynligvis er grundig testet allerede. Det kan være mer fruktbart å teste utenfor dette»
Her bør du starte
Dersom du ønsker å starte med bug bounties har Rakvåg følgende råd:
- - Installer og gjør deg kjent med Burp Suite, eller en annen http proxy.
- - Hands-on øvelser! Portswigger Web Security Academy er veldig bra!
- - Apper som er sårbare med vilje er nyttige å øve mer på. OWASP Juice Shop eller NATAS er eksempler.
- - Det er enklest å teste i private programmer. For å få bli med der må man ofte bevise at man har noe å komme med ved å score noen poeng med funn i public programmer. Det kan kanskje være enklest der konkurransen er litt lavere, som i programmer uten pengepremier. Det samme kan gjelde mindre plattformer, som Intigriti. Eller du kan prøve å ta kontakt med de norske programmene direkte. Flere av dem er mulig å få tak i på Norsec discord, eller rekrutterer åpent.
- - Hack yourself first-kurset til Troy Hunt og Scott Helme kan også være en god intro til denne typen testing, om utgangspunktet er at du er utvikler. Vi har arrangert det tre ganger internt i SpareBank 1 Utvikling, men det pleier også å settes opp hos f. eks NDC Security-konferansen i Oslo.
- Det er følelsen man får når man finner en kritisk sårbarhet som driver meg
Finn inspirasjon i rapporter
- Hva er ditt beste tips?
- Tenk litt over hva som sannsynligvis er grundig testet allerede. Det kan være mer fruktbart å teste utenfor dette, sier Rakvåg.
Han legger til at mindre bruk funksjonalitet, som profilinnstillinger eller andre mindre populære områder, kan være mer interessant enn kjernefunksjonaliteten i løsningen.
- Eller om tilgangskontrollen fungerer som den skal når du prøver å lese en annen brukers dataobjekt, er det sikkert at det fungerer like bra når du skal endre eller slette det? Ellers har gammel kode ofte flere rariteter enn ny. Det kan også være veldig fin inspirasjon å hente i publiserte sårbarhetsrapporter i Hacktivity hos Hackerone.
