Et kig på full disclosure og sikkerhedsfejl

Publiceret: 1. december 2002

I de sidste 20 år har der i IT-sikkerhedsbranchen været meget debat omkring full disclosure, altså er det nødvendigt at fortælle offentligheden om sikkerhedsfejl. Nogen hævder, at full disclosure røber hemmelighederne således de onde kan udnytte fejlene, mens andre hævder, at full disclosure er et nødvendigt onde for at få rettet fejl hurtigt (eller overhovedet).

Snakeoil.dk har modtaget en henvendelse fra Søren Christensen som er sigtet i forbindelse med Valus sagen. Søren fandt en af fejlene hos Valus og er tiltalt for overtrædelse af straffelovens § 263, stk. 2 jv. § 23 og § +291, stk. 1, jf. § 23 -- Han skriver, at han fornyligt brugte 4 timer på Google med at lede efter andre danske websites med samme type fejl. Enhver kan gøre det:

Brug Google til at søge efter sider der indholder både ".asp?" og "=".

Han fandt 22 danske virksomheder som havde fejl der var identiske med fejlen hos Valus. Som et eksperiment delte han virksomhederne op i 2 grupper, gruppe A med 15 virksomheder og gruppe B med 7 virksomheder.

Virksomhederne i gruppe A blev kontaktet via email med en beskrivelse af den pågældende sikkerhedsfejl, samt en 'trussel' om, at hvis fejlen ikke var blevet rettet inden 14 dage, ville han offentligøre firmaets navn og fejlen.

Gruppe B fik kontaktet og gjort opmærksomme på fejlen, uden at der var nogen indikation af en trussel.

7 ud af de 15 virksomheder i gruppe A (med trussel) besvarede henvendelsen. 6 af virksomhederne har ikke rettet fejlen.

4 ud af de 7 virksomheder i gruppe B (uden trussel) besvarede henvendelsen. Een af virksomhederne i denne gruppe har rettet hullet.

Opsummering

Gruppe AGruppe B
AntalProcentAntalProcent
Afsendt15-7-
Besvarelser747%457%
Rettede hullet853%114%

Bilag fra Søren

Vi har fået udleveret en række bilag fra Søren som andre kan finde interessante. Vi har inkluderet den første direkte i vores kommentar, og resten findes som individuelle links. Sørens egen kommentar følger her:

Efter jeg blev sigtet for medvirken til hacking og hærværk ved at have formodet at Valus.dk kunne komprimeres ved bruge af simple URL - samt givet eksempler på disse - blev jeg spurgt; 'Hvorfor sendte du dem ikke bare en mail med informationerne og gav dem X tid til at rette det, før du offentligt stod frem?'. Blandt de personer der spurgte mig om dette var min advokat og den ene af de kriminalassistenter der konfiskerede mine computere.

Mit svar består af to dele:
  1. Jeg har ingen pligt til at angive noget som helst til noget firma. Men jeg føler mig forpligtet til at påpege åbne og store huller i systemer der indeholder personfølsomme data overfor folk der er interesseret i at vide sådan noget.
  2. De fleste virksomheder er som regel komplet ligeglad med sådanne henvendelser. Hvis ikke de er ligeglade, er de meget ofte truende.
Dette er min baggrund for at lave denne 'undersøgelse' - for at vise folk at:
  1. Kun få virksomheder tager en sådan henvendelse alvorlig.
  2. Ofte er de mere interesseret i at ingen skal have at vide at de har haft sikkerhedsproblemer.
  3. At næsten ingen virksomheder udviser en aktiv sikkerhedspolitik i håndteringen af sådanne henvendelser.
  4. At ingen virksomheder tager den ultimative konsekvens og tager deres system offline for at rette og undersøge systemet for eventuelle indbrud.
  5. Utrolig mange systemer og websteder er designet og programmeret af inkompetente folk / bureauer.

Konklusionen på min undersøgelse er basalt set at mine forventninger klart holdte stik.


Som punktsvar til min baggrund har jeg draget følgende:

  1. Responstiden, såfremt der var en respons, var meget stor. Ingen af de undersøgte virksomheder er aktive i weekenden. Under halvdelen af de kontaktede virksomheder valgte at rette deres huller.
  2. Flere virksomheder opfattede min henvendelse som meget provokerende. Fra flere af de virksomheder som vendte tilbage til mig, fremgår det tydeligt at de har haft en advokat på sagen - for at beskytte dem selv og eventuel sagsøge mig.
  3. Svarene fra virksomhederne var ofte - Vi har sendt henvendelsen videre. Fra intet svar fremgår det at en virksomhed besidder en aktiv sikkerhedspolitik og aktiv sikkerhedsrespons. Kun een ud af de adspurgte virksomheder tilkendegav at de faktisk undersøgte (eller ihvertfald fik CCU til at undersøge det) om de før havde været angrebet.
  4. Samtlige steder var åbne i de 14 dage overvågningen foregik.
  5. Der er så utrolig mange standard måder at helt undgå dette sikkerhedshul på:
    • Man koder ordentligt. De 'programmører' der har lavet de sårbare systemer besidder en dybt mangelfuld viden omkring almen programmeringsteknikker. Inputvalidering er hel basal.
    • Man anvender en korrekt arkitektur. Arkitekturen for de systemer der er sårbare er helt hen i vejret. ASP har aldrig været et sprog man lavede systemer i. ASP er kun den lim der binder ens forretningslogik sammen internet serveren
    • der skal ikke være noget logik, udover måske parameter validering, i ASP.
    • Man har i mange tilfælde valgt at bruge en administrativ konto for tilgang til databasen.
    • Man har ikke anvendt preemptive foranstaltninger til scanning af requests. Microsoft har længe haft et frit tilgængeligt (og ganske udmærket) URL scannings system til IIS. Flere andre producenter har ligende systemer. Såfremt et sådan var sat op, havde et givent websted været beskyttet.
    • Man har fra 'systemudviklernes' side ikke fulgt med i de sikkerhedsproblematikker der eksisterer på IIS platformen. Havde man dette ville man have kendt til dette hul.
    • Man viser systemfejlmeddelser til brugeren. Hvad skal brugeren med dem? De skal logges og brugeren skal have en almen fejlmeddelse at vide. Man skal heller ikke glemme at siden dette hul er i webapplikationen kan ingen firewall eller anden netværksikring beskytte en. Man skal heller ikke glemme at hvis ondsindede personer havde angrebet disse systemer, var deres muligheder for at skjule sig ekstremt store. Anonymiserede proxier, sletning af logfiler osv. er bare få af mulighederne.
Omkring offentliggørelse af disse sikkerhedshuller, mener jeg at det må være en basal ret siden;
  1. Jeg har ikke overtrådt nogen lovgivning ved undersøgelsen om et websted var sårbart, med mindre det er blevet ulovigt at ændre parametre på URLer.
  2. Jeg har ikke på anden vis omgået systemerne. Jeg har brugt den klient (HTTP browser) som systemet er beregnet til.
  3. Det er ikke ulovligt at stille spørgsmålstegn ved kvaliteten af en service der er offentligt tilbudt for alle. Derfor vil jeg mene at jeg er i min gode ret til at angive de virksomheder der har haft, eller stadig har , disse huller. Virksomhederne kan så selv finde ud af om de vil rette hullerne eller om de vil prøve at modbevise min påstand.

Men grundet den manglende politik på området samt det faktum at jeg pt. er sigtet for netop at vise dette sikkerhedshul gør at jeg har valgt ikke at offentliggøre nogen informationer.

Det er mit klare ønske at man fra politisk side gør noget ved dette. Man må kunne implementere et system som det er tilsvarende med smiley systemet fra restaurationsbranchen - offfentlig informationer om hvorledes en virksomhedssikkerhedspolitik er, samt en vurdering af hvorledes de følger denne.

Eneste sanktionsmulighed man pt. har overfor en virksomhed der sjusker så meget med sikkerheden er en anmeldelse til datatilsynet - såfremt virksomheden gemmer personfølsomme data. Datatilsynet har ingen kompentence til at gennemskue hvor meget sjusk en virksomhed har. Det eneste datatilsynet gør er, at udbede virksomheden om en redegørelse. Hvis virksomheden i sådan en redegørelse på tilfredstillende vis kan redegøre for sikkerheden sker der ikke mere.

Ved behandlingen af Valus sagen er det min klare overbevisning at datatilsynet kun baserede sin dom på redegørelsen fra Valus. Såfremt datatilsynet havde sat sig ind i de tekniske omstændigheder omkring sikkerhedshullet, havde de vidst at de oplysninger og det system Valus satte op var i klar brud med datatilsynets egen foreskrifter.

Hvem er det det går udover når et system angribes? Det er som regel den alemen borger og bruger. Det er meget trist, men hvis man ikke fra politisk side følger med i udviklingen, og laver et lovgivningsgrundlag der giver større muligheder for sanktioner overfor virksomheder der sjusker med sikkerheden i deres systemer, så giver man ondsindede personer næsten frit spillerum. Så længe de har frit spillerum vil de udnytte systemet og give endnu mere grobrund til udtagelser som: "Alle IT systemer er usikre og man kan ikke stole på dem" og "Det er for usikkert at handle via webbet".

Eksempel på en "trussel" email

Eksempel på en ikke-trussel email

Kommunikation fra firmaer i gruppe B

Søren har udleveret sin maskerede kommunikation med nogle af virksomhederne i gruppe A.

Kommunikation med firma 1.

Kommunikation med firma 2.

Kommunikation med firma 3.

Kommunikation med firma 4.

Kommunikation med firma 5.

Søren har også fremstillet en tidslinie over begivenhederne.

Tidslinie

Andre tilfælde

Snakeoil.dk sendte den 18. november 2002 en email til EcSoft:

/pages/showpublication.asp paa jeres website laver ikke input validation paa
variablen cId -- ved at tilfoeje et ' til artiklens Id kan jeg faa jeres
database til at fejle paa en maade der faar mig til at tro, at det vil vaere
muligt at manipulere med SQL kommandoer. Jeg har ikke forsoegt paa noget i den
stil, da jeg hurtigt ville ende paa den forkerte side af loven, og det har jeg
ikke lyst til.

Fejlen findes også for pId variablen, og på alle EcSoft's websites er sårbare: www.ecsoft.dk, www.ecsoft.se, www.ecsoft.no, www.ecsoft.nl, www.ecsoft.co.uk. Vi har aldrig fået feedback på vores henvendelse.

Den 6. september 2002 sendte vi en besked til www.proventum.net med besked om, at deres produkt, Ad Libitum, var sårbar overfor SQL injection.

Jeg er stoedt paa en meget basal sikkerhedsfejl i jeres produkt. Det drejer sig
om manglende input validering af indholdet af 'article_id' variablen inden dette
indsaettes i en SQL saetning. Fejlen goer det muligt at faa normal brugeradgang
til maskinen som Ad Libitum er installeret paa. Der er derefter rigelige
muligheder for at opnaa administratoradgang paa maskinen.
  
Det overrasker mig at saadan en simpel fejl slap forbi jeres QA afdeling, naar
nu det kan koste saa meget at rette hos jeres kunder. Jeg kan ikke undgaa at
spekulere paa hvad der mon ellers findes af lignende simple fejl i jers kode.
Ved jeres kunder det?

Vi har ikke modtaget noget svar.

Konklusion

Som det ses reagerer virksomheder og organisationer meget forskelligt på henvendelser.

Virksomheden som påpegede, at Søren med sin henvendelse, havde sat 15 mennesker i gang skyder ansvaret for kvalitetssikring over på Søren. Det var ikke hans skyld at fejlen var tilstede; fejlen ligger hos virksomheden.

Hvis virksomheden føler at det har kostet dem en urimelig mængde penge at reagere på Sørens henvendelse, vil vi tilråde dem til at undgå sikkerhedsproblemer til at starte med. Det kan være meget billigere.

ComputerWorld bragte en artikel om dette emne, og i den efterfølgende debat skriver en debattør, at han er træt af disse "selvbestaltede orakler" som finder pinlige sikkerhedsfejl i virksomheders websites. Vi er også trætte -- vi er trætte af at gentage os selv. Vi forstår ikke hvor ideen om orakler kommer fra: Fejlene som diskuteres er basale og har været kendt i årevis. Kun sjældent drejer det sig om fejl som en gruppe forskere har arbejdet koncenteret på i årevis.

Det skal siges, at Snakeoil.dk er meget uenig i Sørens beslutning om at skjule navnene på virksomhederne han var i kontakt med. Det er tydeligt at der er brug for mere offenligt pres. Vi forstår dog at Søren ikke har lyst til yderligere ballade for sig selv.