Betaler for 40 sårbarheder årligt i eget system: Det ville være katastrofalt, hvis nogen får hacket sig ind

Illustration: Virrage Images/Bigstock
Mens der ikke er tradition for at betale folk for at finde sårbarheder i offentlige it-systemer herhjemme, så betaler danske Queue-It for sårbarheder årligt.

Det ville umiddelbart være en god idé, hvis der blev udbetalt en findeløn til folk, der finder huller i offentlige it-systemer. Det mener administrerende direktør i danske Queue-It Niels Henrik Sodemann, der flere gange årligt selv honorerer fund af sårbarheder i virksomhedens systemer.

Udmeldingen fra direktøren kommer i kølvandet på sagen fra sidste uge med Esben Warming Pedersen, der havde fundet et sikkerhedshul i et offentligt it-system. Han blev som bekendt politianmeldt og ikke honoreret for fundet.

»Vi handler med nogle rigtigt store enterprise-virksomheder, hvor vi har det her virtuelle kø-system. Og det kan blive ekstremt katastrofalt for os, hvis nogen får hacket sig ind og misbruger en af vores kunders konti,« siger Niels Henrik Sodemann.

Derfor anvender Queue-It en crowdsourcet bug bounty-tjeneste, hvor it-sikkerhedsforskere får kontant betaling for at finde sikkerhedshuller i Queue-Its system. Virksomheden står bag et system til håndtering af online-kø og har blandt andet højtalerproducenten Sonos, legetøjskæden ToysRus og mobilselskabet T-Mobile på kundelisten.

De seneste tre-fire år har den danske virksomhed anvendt en tjeneste fra cobalt.io, hvor whitehat-hackere sikkerhedstester forskellige virksomheders systemer, og hvor bliver udbetalt penge til finderen af et relevant sikkerhedshul.

»Det er Airbnb for penetration-testing på én eller anden led. Vi signer som virksomhed op på platformen og siger, vi gerne vil have testet et system i en periode. Og så forpligter vi os til at betale for de fejl, der bliver fundet,« siger Niels Henrik Sodemann.

Er det ikke lidt urovækkende, at der sidder en hel masse mennesker og prøver at finde huller i jeres system?

»Det er jo rigtigt. Problemet er jo bare stadigvæk, at hvis hullet er der, så skal det bare lukkes på en eller anden led,« siger han.

Niels Henrik Sodemann vurderer, at Queue-It nu har i omegnen af 40 bug bounty-udbetalinger om året til sikkerhedsforskere, der har fundet huller i virksomhedens it-system.

»Det er ærgerlige penge, men hvis der er 40 huller, hvor de fem af dem er kritiske, så er der jo ikke noget at diskutere,« siger han.

Niels Henrik Sodemann påpeger, at Queue-It naturligvis også selv har testet og lukket eventuelle huller i systemet, inden whitehat-hackerne tager over.

»Når vi sætter dem til at skulle lave disse test, så gør vi det jo selvfølgelig på et tidspunkt, hvor vi - med de dygtige udviklere, vi har - er overbeviste om, at der ikke er huller,« siger han.

En kasse champagne

Niels Henrik Sodemann har i et debatindlæg her på Version2 kommenteret det sikkerhedshul, som Esben Warming Pedersen fandt i et pladsanvisningssystem, som KMD står bag. Hullet gjorde det muligt at tilgå personoplysninger via CPR-opslag. I stedet for en findeløn blev han mødt med en politianmeldelse fra it-leverandøren.

I debatindlægget vurderer Niels Henrik Sodemann, at det pågældende sikkerhedshul ville have udløst mindst 1.500 dollars (ca. 10.000 kroner) i regi af cobalt.io.

»Jeg vædder gerne en kasse champagne på, at uanset hvilket it-system man tager fat i af denne type i det offentlige, så er der minimum en håndfuld fejl i,« siger Niels Henrik Sodemann.

I det lys mener han, at det generelt ville være en god idé med dusør-programmer, som det Queue-It selv anvender, til offentlige it-systemer. Altså hvor rigtige hackere tester løs på systemet. Her er det nemlig ikke nok med standardkonsulenter, vurderer Niels Henrik Sodemann.

»Hvis man går så meget op i, at det skal have den grad af sikkerhed, så skal det jo testes på en måde, der står mål med det, der rent faktisk findes af fejl - ikke på et eller andet højt, abstrakt niveau,« siger Niels Henrik Sodemann og fortsætter:

»Og det nytter det ikke noget, man har en test en gang om året, og at man har en eller anden konsulent, der sidder ved et skrivebord og spørger, om der er en proces for at låse døren og sådan noget. Der bliver man nødt til at teste hårdt på systemerne og se, om der findes huller.«

Der er niveaumæssig forskel på, hvad en almindelig konsulent og så en masse whitehat-hackere rundt om i verden kan finde af huller i et it-system, mener Niels Henrik Sodemann. For at illustrere den pointe har han sendt en rapport om et muligt sikkerhedshul, Queue-It er blevet gjort opmærksom på via cobalt.io, og som direktøren tvivler på, at en konsulent fra et af de gængse konsulenthuse var faldet over.

Rapporten kan ses her og handler om et muligt man-the-middle-scenarie, der dog ender som 'declined'.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (17)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Michael Cederberg

Jeg har intet imod at man betaler folk for at rapportere fejl.

Men det er for sent og dyrt at finde dem på den måde. Alt software bør gennemgå et sikkerhedsreview inden det kommer i rigtig produktion. Det er simpelthen meget billigere og sikrere at finde sikkerhedsfejl hvis man forstår hvordan software er opbygget og har mulighed for at stille spørgsmål til designere og udviklere.

  • 3
  • 14
Simon Mikkelsen

Man finder aldrig det hele. I det lys vil jeg kalde denne form for testing en gratis omgang, selvom man faktisk betaler folk for deres arbejde. Der sidder nogle folk derude som måske har specialiseret sig i nogle få typer fejl, og støvsuger diverse apps for dem, mens andre bare får en god idé eller har fingeren på en anden puls. Men finder de ikke noget - fordi man faktisk har fundet det hele selv - er det gratis.

  • 22
  • 0
Jakub Nørløv Iwanczuk

Jeg synes at det virker som et fint måde at finde fejl i, men jeg tror ikke at det samme værktøj/fremgangsmåde kan anvendes i forbindelse med off. systemer i DK.
Til at starte med skal man sandsynligvis have et NemID. Ofte er der tale om personfølsomme data for adre borgere som jeg ikke burde tilgå (altså systemet burde som minimum være sikret mod fejl som den fundet af Espen).

  • 0
  • 2
Jakob Dahl

Det er rigtigt at for at få dem testet fra a-z skal man være logget ind. Men det ville være et godt sted at starte at give dusør for at finde fejl for dem der er logget ind af legitime årsager. Og man kan få testet de dele af systemet der ikke kræver login, det er efter min mening næsten mere vigtigt at sikre at man ikke kan komme i kontakt med personfølsomme oplysninger uden at logge ind
/Jakob

  • 4
  • 0
Anders Jensen

For at få tilladelse til at behandle personfølsomme oplysninger for danskere burde det simpelthen være et krav, at man stiller et testsystem til rådighed hvor uafhængige kan udføre penetrationstests, og der burde være statsligt fastsatte minimumstakster for bounties, så de uafhængige testere kan få en rimelig betaling hvis de finder noget.

Kravet burde gælde både offentlige og private systemer som behandler personfølsomme oplysninger.

  • 8
  • 0
Peter Christiansen

Ja ved at skulle stille systemer til rådighed + evt. udgift til bounties og administration af bugbounty programmer, stiller man en hel underskov at små it udbydere i en situation, hvor det ikke kan betale sig at drive virksomhed, selv hvis man har styr på sikkerheden.

Er ikke lun på ideen.

  • 1
  • 0
Peter Christiansen

Jeg har intet imod at man betaler folk for at rapportere fejl.

Men det er for sent og dyrt at finde dem på den måde. Alt software bør gennemgå et sikkerhedsreview inden det kommer i rigtig produktion. Det er simpelthen meget billigere og sikrere at finde sikkerhedsfejl hvis man forstår hvordan software er opbygget og har mulighed for at stille spørgsmål til designere og udviklere.

Wow shit det var mange thumbs down på noget der er fundamentalt for god software.

Altså at revidere koden internt og følge nogle guidelines så man får lukket fejl der måtte være opstået. Hvis man har hang til XSS, sql injections og andre fejl der opstår pga. dårlig sanitering af input, skulle man måske overveje at søge kvalificerede programmører.

Det er alt andet lige meget lettere at finde fejl når man har kildekoden ved hånden, end at nogle udefra skal forsøge at finde fejl "black box" style. Og nogle fejl bliver ikke fundet ved denne metode.

  • 1
  • 1
Mike Mikjær Blogger

Nu her om lidt når vi alligevel begynder at uddele bøder til typer som KMD, så syntes jeg dels vi udvider den sådan at KDM's opførsel her sidst, med politiameldelse og public shaming skulle medføre en bøde, ligesom selve fejlen skal medføre en bøde, begge skal være i procent af omsætningen.

En del af bøden kan så passende bruges til findeløn.

Alternativt skal virksomhederne opfordres til at håndtere henvendelsen ansvarligt og få lukket hullet, og således kunne slippe for bøden. (Selvfølgelig kun den del der omhandler opførsel overfor finderen)

Men ja ... folk burde tvinges til at sikre deres lort inden de releaser, jeg sider tit som udvikler på projekter hvor vi anbefaler at der sættes så-og-så-meget af tid security-audit ... og oftest ender kunden med at decimere vores anbefalinger hvis de endelig lytter i første omgang, primært fordi det er omkostningsfrit for dem at gøre det.

  • 2
  • 1
Claus Bobjerg Juul

Kan du uddybe, for hvis koden der afvikles er den samme men data bare er et mockup datasæt, så er der vel ikke nogen forskel.

Hvad angår NemID/login så er det en særskilt test og hvis du tænker på at der kunne være implementeret en fejl i grænsefladen mellem NemID og den bagvedliggende applikation, så skrev jeg at NemID måske kunne simuleres (jeg er ikke udvikler), så der foretages et login der har samme virkemåde som NemID.

  • 0
  • 0
Jesper Frimann

Wow shit det var mange thumbs down på noget der er fundamentalt for god software.

Enig.

Altså at revidere koden internt og følge nogle guidelines så man får lukket fejl der måtte være opstået. Hvis man har hang til XSS, sql injections og andre fejl der opstår pga. dårlig sanitering af input, skulle man måske overveje at søge kvalificerede programmører.

Det er alt andet lige meget lettere at finde fejl når man har kildekoden ved hånden, end at nogle udefra skal forsøge at finde fejl "black box" style. Og nogle fejl bliver ikke fundet ved denne metode.

Jup, men det ene udelukker ikke det andet. Jeg synes det er fint, at gøre begge dele.

// Jesper

  • 2
  • 0
Michael Cederberg

For en god ordens skyld har jeg opdateret artiklen med en pointe fra Niels Henrik Sodemann om, at virksomheden naturligvis også selv har testet og lukket eventuelle huller i koden. Jakob - V2

Og jeg vil gerne pointere at mine kommentar ikke gik på Niels Henriks setup (jeg kender det ikke). Min kommentar gik på at jeg mange gange har oplevet at sikkerhed er noget man overvejer når løsningen er lavet og i produktion. Måske først når nogen ringer og fortæller om et hul. Man tror man kan sikre systemet ved at hyre firma X, som så laver penetration testing o.lign. Det er for sent når først systemet er i produktion. Ligesom QA så er sikkerhed typisk ikke en magisk sovs man kan hælde ud over systemet når skaden først er sket.

Man bør lave et egentligt sikkerhedsreview. Hvis man vil have mest ud af sin indsats, så finder man nogle kritiske folk som forstår sig på sikkerhed. Hvis man har dem internt i firmaet så er det fint, ellers kan man finde dem eksternt. Man giver dem en overordnet introduktion til systemet, fx hvor data kommer fra, hvilket data der er sensitivt, etc. Herefter går man hele systemets flade ud mod verden igennem og diskuterer hvordan det kan angribes. Det være sig brugerens input data, men også de services som systemet selv måtte bruge. Dette gøres tidligt i udviklingsfasen og lige inden det ryger i produktion.

I tilfældet KMDs pladstilmeldingssystem, så ville følgende spørgsmål blive stillet: ”Er det et problem at man kan slå tilfældige menneskers navn op ud fra CPR?”

Man finder aldrig det hele. I det lys vil jeg kalde denne form for testing en gratis omgang, selvom man faktisk betaler folk for deres arbejde.

Når nu systemet er i produktion så er det fint hvis nogen rapporterer fejl de har fundet. At give dem penge er også fint. Men omkostningen ved at finde fejl når noget først er gået i produktion – specielt de mere hard core sikkerheds problemer – er meget større end når det sker i udviklingsfasen. Hvis man formår at undgå at der går bureaukrati i opgaven, så koster det typisk noget mindre end 1% af udviklingsomkostningerne.

  • 1
  • 4
Jakub Nørløv Iwanczuk

Kan du uddybe, for hvis koden der afvikles er den samme men data bare er et mockup datasæt, så er der vel ikke nogen forskel

Min erfaring er at det ikke altid er tilstrækkeligt at teste med mockup data for at finde fejl i et system. Det er bl.a. derfor man i visse tilfælde har et staging miljø, hvor de kan verificeres at software sammen med produktionsdata ikke indeholder fejl.

Min generelle betragtning omkring det emne som artiklen omhandler er, at det her værktøj/tilgang til at finde fejl ikke nødvendigvis kan anvendes i alle situationer. Der findes ikke en gylden løsning på det omtalte problem.

  • 0
  • 0
Christian Hansen

Disclaimer: Jeg er co-founder i Cobalt.io.

De fleste uenigheder opstår når gammeldags IT-tankegang møder script-kiddy-beg-bounty-hunteren. Heldigvis vil vi det samme, bedre sikkerhed.

Cobalt har crowdsourcet sikkerhedstestere de sidste 4 år med hundredevis af virksomheder, inklusiv os selv. Vi har testet startups og Fortune 100-virksomheder. God IT-sikkerhed kræver indsats flere steder i en organisation: I kildekoden, i konfiguration, i uddannelse af personale, etc. og en erkendelse af at IT-sikkerhed aldrig bliver perfekt. Med den erkendelse er det ingen skam at nogen finder et sikkerhedshul – det er ganske naturligt. Organisationen bør dog garantere en vis SLA, e.g. kritiske huller fikset inden 48 timer, mellem-risiko inden for 1 måned, etc. Over tid viser prioriteringen et fokus på sikkerhed, og vil naturligt gå upstream til udviklerne så de lærer af deres fejl.

Hurtig/automatiseret patching er også et element i en organisations sikkerhedsmodning. Hvis en større organisation er blevet opmærksom på kritiske sikkerhedshuller i deres produktionsmiljø som de simpelt hen ikke kan opdatere hurtigt, så skal selve deploymentprocessen revideres, så eksponering (tid X antal mulige ofrer X kritikalitet) bliver minimeret.

Alt kan testes/hackes. Hvis det kræver login, kan e.g. NEM ID lave test-konti eller køres på et test/staging miljø.

  • 0
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize