- Vi ønsker å være med på å øke bevisstheten om TLS-sårbarheter. Det er noe som snakkes mye om, men som ikke får nok oppmerksomhet. Vi ønsker å vise at det er et ekte problem, sier finske Joona Hoikkala, leder Vismas Red Team og mannen bak det kjente pentesterverktøyet FFuF, til kode24.
FreshService er en av de største programvareløsningene for lagerstyring globalt, og brukes av bedrifter over hele verden. Sammen med kollega Tomi Koski, avdekket Hoikkala en nulldagssårbarhet i programvaren.
Sårbarheten, som ble offentliggjort i dag, kunne fått alvorlige konsekvenser. Derfor ventet de i over 120 dager med å publisere for å sikre at de berørte partene har oppdatert programvaren, og at den i dag bare er en "sikker brikke programvare", som Hoikkala og Koski skriver i "writeupen" - hvor de viser og forklarer fremgangsmetoden.
Til kode24 forteller Hoikkala, som selv opprinnelig har bakgrunn som utvikler, om fremgangsmåten. Samt de etiske vurderingene knyttet til publisering av sårbarheten, og gir deg som utvikler tips til hvordan du kan gjøre arbeidshverdagen din sikrere.
- Pulsen øker og det er litt hektisk selv for de med erfaring
Startet ved en tilfeldighet
Hoikkala og Koski kom over sårbarheten ved en tilfeldighet. Som seg hør og bør for etiske hackere, var noe av det første det nyoppretta Read teamet til Visma gjorde, å kartlegge selskapets egne datamaskiner. De ba den lokale IT-ansvarlige om å få tilgang til den mest generiske laptopen overhodet mulig, med all programvare som vanlige ansatte i Visma hadde tilgang til.
- Vi så på nettverkstrafikken og kartla hva som var installert, hva de kommuniserte med, hvilke forsvar vi har og om det er noe som stikker seg ut, forteller han.
Blikket falt etter hvert på applikasjonen FreshService, som ingen av dem hadde særlig kjennskap til fra før av. I artikkelen forklarer Hoikkala og Koski at programvaren fungerer ved å nå og da "kontakte en sentral tjeneste over internett for å rapportere detaljer om enheten den er installert på. Dette hjelper IT-ansvarlig med å se hvilke enheter som brukes aktivt, hvilke programvare som er installert og så videre". Men etter en nærmere titt så de at noe ikke stemte: Nemlig en "live log"-fil fra FreshService Agent Software med linjen:
Brukte Raspberry Pi
For å avlytte kommunikasjonen mellom klienten og serveren, lagde Hoikkala og Koski et fiendtlig nettverk med offentlig tilgjengelige verktøy som Raspberry Pi og små hjemmerutere.
- For testrigget satt jeg opp en hjemmeruter til å sende all trafikk med destinasjonsporten 443, som er en HTTPS-port, til en "TLS interception proxy", forteller han.
Hoikkala og Koski oppdaget at TLS-valideringen var skrudd av. Og allerede på den første forespørselen sendte applikasjonen tilbake ukryptert informasjon om maskinen.
- Vi tenkte: "Shit, den sender oss alt dette, ikke bra". Det ga oss mer motivasjon til å fortsette, sier Hoikkala.
«Selv om du jobber i offensiv sikkerhet er målet det samme som for dem som jobber med defensiv sikkerhet: Å være der for å hjelpe»
Må "eie" nettverkstilkoblingen
Hoikkala legger til at i den virkelige verden er det en viktig faktor som spiller ned alvorlighetsgraden til sårbarheten: Angriperen trenger kontroll over nettverkstilkoblingen til datamaskinen.
- Dette er mulig ettersom at FreshService-agenten kommuniserer via det offentlige nettet, ikke gjennom en VPN - som ville ha lagt et ekstra sikkerhetslag over, sier han.
Ettersom FreshService typisk blir brukt av store selskaper, tilrettelegger dette for at angriperen kan utføre målrettede angrep mot et spesifikt selskap.
- Angriperen vet for eksempel hvor kontoret ligger og kan sette opp en operasjon på en av kaffene rundt.
Et typisk angrepsscenario ville derfor kunne sett slik ut: En ansatt tar med seg jobbdataen til en internettkafé og logger seg på nettverket. Datamaskinen husker navnet på nettverket. Neste gang den ansatte er på kafeen vil den derfor logge seg på - med mindre automatisk tilkobling er skrudd av.
- Hvis angriperen vet, eller gjetter, at offeret på et tidspunkt har blitt koblet til en spesifikk offentlig WiFi, kan angriperen sette ut et ondsinnet som forkles som en som datamaskiner stoler på, sier Hoikkala.
Den ondsinnede WiFi-en kan for eksempel utgi seg for å være nettverket til kafeen og lokke offerets datamaskin til å automatisk koble seg til det.
Daemon hadde root-tilgang
FreshService er skrevet i .NET, noe som gjorde at Hoikkala og Koski enkelt kunne dekompilere og inspisere applikasjonen. I tillegg inneholdt programmet en selv-oppdaterende Daemon.
- Vi hadde ikke direkte tilgang til kildekoden, men fikk til en gjennomgang av koden med god hjelp fra en logg som registrerte "debug level messages" som var lagt igjen i Builden, sier Hoikkala.
I loggen kunne de etiske hackerne se de eksakte modulene og funksjonene hvor "debug"-meldingene kom fra.
Deretter vendte blikket seg mot den selv-oppdaterende Daemonen, skriver Hoikkala og Koski. Som oftest har vanlige brukere begrensede privilegier på jobb, bortsett fra det administratoren har gitt tilgang til. Daemonen hadde derimot root-tilgang på både macOS og Linux-systemer, samt systemprivilegier på Windows.
- Når man utnytter denne kan man derfor få mye høyere privilegert tilgang enn den vanlige brukeren, sier Hoikkala.
«Angriperen kan både se og endre alt som skjer på maskinen, og etterhvert flytte seg til selskapets interne nettverk for å fortsette angrepet»
Genererte ondsinnede arkivfiler
Ifølge Hoikkala var det det største problemet å trigge installasjonen. Applikasjonen spurte nemlig bare om oppdateringer hver syvende dag. Men Hoikkala og Koski fant en løsning på problemet, skriver de.
Så sto de overfor enda en utfordring: FreshService agenten har en ekstra integritetssjekk for oppdateringspakker som blir lastet ned fra nettet. Derimot var checksum-verdien synlig over den fangende TLS-koblingen, noe som gjorde den mulig å modifisere. Hoikkala og Koski dekonstruerte algoritmen og bygde en CLI-applikasjon som kalkulerte valide checksums for de ondsinnede oppdateringspakkene.
Ved å genere ondsinnede arkivfiler, inkludert payloadsene, kalkulere en SHA-256 chechsum for arkivfilene, kjøre en egen CSharp-applikasjon, og få en FS Agent-gyldig checksum til å bli distribuert globalt, gjorde det mulig å pushe legitime pakker til alle klientene.
"Her har vi vår andre sårbarhet, ved å bruke hardkodede "secrets" (statisk SECRET_KEY og _salt), som enkelt kan hentes fra reversert CSharp-kildekode", skriver Hoikkala og Koski.
Dette gjorde det mulig for de etiske hackerne å pushe ondsinnede oppdateringspakker til datamaskiner over hele verden.
- Angriperen kan både se og endre alt som skjer på maskinen, og etterhvert flytte seg til selskapets interne nettverk for å fortsette angrepet. Å kompromittere en brukers maskin er sjeldent det ultimate målet. Det ekte målet er ofte inne i det interne nettverket, sier Hoikkala.
Viktig å ha et etisk kompass
- Dere ventet lenge med å publisere sårbarheten der andre gjerne ville kjøpt på og fått stor mediedekning. Hvorfor har dere valgt denne tilnærmingen?
- Når du jobber med offensiv sikkerhet er det å ha et etisk kompass enda viktigere enn tekniske ferdigheter. Alle som jobber i dette feltet må finne ut hva som er den beste måten å minske sårbarheten på, sier Hoikkala.
Han legger til at den allment aksepterte tiden å vente før du publiserer funnene dine er 90 dager. Vismas Red Team ventet i over 120 dager for å være sikker på at alt var ok.
- Dette skyldtes blant annet at selv om auto-oppdateringen er hver syvende dag, kan det i flere tilfeller hende at folk ikke har åpnet laptopen og fått datamaskinen "patchet".
Hoikkala viser også til at den politiske situasjonen var alvorlig da de gjorde funnet.
- Vi ønsket å holde det sikkert og hemmelig. Selskapet og kundene er utsatt for å bli angrepet av ulike grupper og statlige aktører. Den negative konsekvensen kunne ha blitt stor, sier og legger til:
- Vi ønsker å være med på å styrke de etiske retningslinjene for rapportering. Selv om du jobber i offensiv sikkerhet er målet det samme som for dem som jobber med defensiv sikkerhet: Å være der for å hjelpe, sier han.
Fuzzing: - Kanskje alle utviklere burde teste egne applikasjoner for alle bytes?
Tenk nøye gjennom valgene dine
- Er det noen viktige lærdommer fra denne prosessen som du vil dele med norske utviklere?
- Det er viktig å kunne de grunnleggende byggeblokkene til en programvare. Du må tenke nøye gjennom alle de mulige snarveiene og undersøke hvilke konsekvenser de har, sier Hoikkala.
Hoikkala er en forkjemper for trusselmodelering, og anser dette som en viktig nøkkel for å forhindre sårbarheter. Han legger til at det er ingen som ha oversikt over alt.
- Alle programvarer har en bug eller en sårbarhet. I tilfellet med denne sårbarheten er det enkelt å se for seg at TLS-valideringen har blitt slått av som en bekvemmelighetsfunksjon. Det andre som er viktig er at folk som jobber med offensiv sikkerhet ikke er fienden, men er her for å hjelpe, sier han.
