Et kig på full disclosure og sikkerhedsfejl

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

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".

/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.

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?