Ethical hacking: Må man dele en it-sårbarhed?

23. marts 2018 kl. 05:128
Ethical hacking: Må man dele en it-sårbarhed?
Illustration: Improsec.
Har man ret til at bringe andre folks system-integritet i fare, hvis det er for at forhindre et større angreb, eller er det endda en undladelsessynd, hvis man lader være? Version2 har snakket Responsible Disclosure Policy med Claus Vesthammer, COO i Improsec.
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

Et klassisk etisk dilemma handler om et løbsk tog.

Forestil dig, at du står på en bro, og ser et tog, der har kurs mod fem børn, der af uforklarlige og irrelevante årsager leger på sporet. Men der er en hjælp at hente.

Tæt på dig er der et sporskifte, og hvis du drejer det, vil det løbske tog slå ind på en anden kurs og kun ramme ét barn, der også leger på skinnerne den dag. Anvender du sporskiftet?

Claus Vesthammer, der er COO i sikkerhedrådgivningsfirmaet Improsec, argumenterer for, at man er nødt til at handle. Heldigvis er situationen hypotetisk, selvom dilemmaet ikke er.

Artiklen fortsætter efter annoncen

Penetrationstest

For at finde svaghederne i et system kan en white hat-hacker udføre en penetrationstest på en virksomheds it-systemer med det formål at opnå adgang til en eller flere definerede mål, som for eksempel systemrettigheder eller dokumenter.

White-hat hacking

White Hat-hackere er en fællesbetegnelse for individer, der anvender hacker-teknikker til hjælpe virksomheder og/eller samfundet med at beskytte sig selv.

I Improsecs arbejde med white hat-hacking og penetrationstest af it-systemer for store danske firmaer finder Improsec lejlighedsvis sårbarheder i deres klienters systemer.

I går offentliggjorde sikkerhedsfirmaet - som omtalt på Version2 - to nye sårbarheder i IBM Notes. Sårbarhederne gjorde det muligt at opnå fuld kontrol over maskinerne, der benyttede softwaren.

Vesthammer fortæller, at de har registreret mere end 15 sårbarheder det seneste år.

De sårbarheder er det løbske tog på sporet og årsagen til Improsecs dilemma. Før eller siden bliver nogen ramt af sårbarheden.

Artiklen fortsætter efter annoncen

Hvis Improsec handler, er det muligt minimere skaden, men de bliver selv en aktør i hele sagen og dermed etisk ansvarlig.

Når de vælger at offentliggøre en sårbarhed, kan det lige så vel være internettets gode som slemme elementer, der finder og henholdvis lukker eller udnytter sikkerhedshullerne.

Vælger de at holde sårbarheden for sig selv eller blot aflevere den til et firma, der ikke gør mere ved det, risikerer de at være implicit medvirkende i det kriminelle misbrug, der måtte være af sårbarheden.

Når man har den viden om en potentiel sårbarhed, er der ingen entydigt korrekt vej frem. Derfor har de hos Improsec formuleret en såkaldt Responsible Disclosure Policy.

Den giver en leverandør fem forretningsdage til at anerkende en sikkerhedsbrist. Selvsamme har derefter 60 dage til at rette fejlen - ellers forbeholder Improsec sig retten til at frigive oplysninger om sårbarheden, så alle kan se og udnytte sikkerhedshullerne.

Andre kan have opdaget fejlen allerede

Forestil dig, at en leverandør ikke har reageret på henvendelser fra Improsec, der derfor offentliggør sårbarhederne. Forestil dig også, at det straks bliver udnyttet af ukendte individer. Pilen peger vel tilbage på Improsec, der må tage deres del af ansvaret?

I starten af februar 2018 gik Improsec ud med sårbarheder i IBM Notes, selvom IBM ikke havde udgivet patches til deres systemer. Sårbarhederne var blevet opdaget i arbejdet for en kunde, men var så alvorlige, at de hos Improsec mente sig forpligtet til at handle.

»Da vi gik offentligt med vores seneste tre sårbarheder i IBM Notes, så var det jo faktisk, uden at IBM havde frigivet patches til dem. Vores formål er at gøre verden til et mere sikkert sted, og det kan man gøre på mange måder. En af måderne er at oplyse om sårbarheder, vi finder,« svarer Claus Vesthammer fra Improsec, der anerkender, at den sårbare softwareleverandør teknisk set ikke er deres kunde, og sårbarheden derfor heller ikke deres problem.

Artiklen fortsætter efter annoncen

»Men så ville jeg også fralægge mig ansvaret. Så siger vi: ‘Vi kender den her sårbarhed, men så gør vi bare ikke noget. Så håber vi, at der ikke er nogen andre, der finder den’,« forklarer Claus Vesthammer, der muligvis har en pointe.

I den virkelige verden kan en person, der forlader en ulykkesscene, straffes med op til to års fængsel, hvis de ikke griber ind. Man er forpligtet til at hjælpe, når der er liv på spil. Selvom indsatsen trods alt er lavere med digitale sårbarheder, burde logikken være det samme.

Spørger man Claus Vesthammer, om det er nok, hvis man blot underretter softwareleverandøren, får man et nej:

»Det må være i almen interesse at lægge sidste skud på stammen overfor producenten, for de gør jo som regel noget. IBM kom med updates, dagen efter vi offentliggjorde sårbarhederne,« fortæller Vesthammer. Han bliver suppleret af sin kollega, Jakob Heidelberg, der er CEO i Improsec:

»Eksempelvis havde en anden researcher, 6 måneder før og uafhængigt af os, fundet den samme sårbarhed i IBM Tivoli Storage Manager, som vi rapporterede til IBM i marts måned sidste år. IBM havde i den tid ikke gjort noget for at sikre deres kunder, men først da vi lagde pres på, blev de nødt til at rette ind.«

Vesthammer anerkender, at der kan være folk, der kommer i klemme, men forsætter:

»Vi gør det også under den tese, at vi jo ikke nødvendigvis er de første, der har fundet de her sårbarheder. Der kunne jo sidde skumle typer på nettet, som måske ikke er så velvillige til at fortælle producenterne om de sårbarheder de har fundet,« argumenterer Claus Vesthammer, der fortsætter med en historie fra virkeligheden.

»Vi havde fundet nogle uhensigtsmæssigheder i Windows kernel, som en af vores daværende medarbejdere var ovre og fortælle om på Black Hat og Def Con (hacker-, og sikkerhedskonferencer, red.) sidste år. Inden da blev vi kontaktet af en mellemøstlig efterretningstjeneste, som gerne ville købe de exploits under forudsætning af, at de så ikke blev publiceret.«

Med andre ord: Uanset om man blander sig eller ej, er sårbarhederne en realitet, og man kan ikke altid vide, hvad folk ønsker at bruge dem til.

»Vi vil gerne gå ud med dem for at sikre, at de rent faktisk bliver udbedret.«

Softwarehygiejnen er stadig akilleshælen

Efter blandt andet WannaCry-angrebet i maj 2017, der inficerede et meget stort antal computere og åbnede et meget stort antal øjne for problematikkerne i digitale sårbarheder, er der gang i forretningen, fortæller Vesthammer.

Det, der gør angrebet fra 2017 ekstra sørgeligt, er, at den sårbarhed, der blev udnyttet i angrebet, faktisk var blevet adresseret af Microsoft allerede i marts 2017 med update MS17-010.

Hvis nettoresultatet er, at Improsec får tvunget en leverandør til at udgive en patch, men den så alligevel ikke bliver installeret i organisationerne rundt omkring, selv efter at sårbarheden er offentliggjort, har man så ikke gjort mere skade end gavn?

»Det er ikke anderledes end alle mulige andre sårbarheder, der måtte eksistere, som enten er disclosed (offentliggjort, red.) af producenten selv eller lignende. Så der tænker jeg ikke, at der er nogen forskel. Et godt eksempel er ransomwaren WannaCry. Det var en stor historie, men et helt almindeligt problem, og i øvrigt noget, man med god softwarehygiejne selv kunne have imødekommet,« fortæller Vesthammer og runder af:

»Det er sådan lidt tilbage til de klassiske dyder indenfor it-sikkerhed. Desværre sidder vi stadig og snakker om de samme ting og probleme,r som vi gjorde for ti år siden. Opdater din software. Hav styr på dine brugere. Hav styr på din log. Det er stadig sådan nogle ting, vi bokser med.«

Uanset om man vurderer det rimeligt eller urimeligt at sætte kniven for struberne af softwareleverandørerne, så ændrer det ikke på, at væsentligheden i it-sikkerheden stiger, i takt med at it rykker længere og længere ind vores liv og kontrollerer alt fra identitet til insulinpumper. Heldigvis tager de fleste virksomheder godt imod, når de etiske hackere ringer.

Læs mere om de opdagede sårbarheder på Improsec.com.

8 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
8
31. marts 2018 kl. 09:55

Full Disclousure mailing listen har efterhånden opbygget en kultur omkring dette. Når man offentliggør en sårbarhed, så offentliggør man også en timeline, så alle kan se hvilken kommunikation der har været med producenten.

Den kultur ændrer sig med tiden, men kan være et godt fingerpeg at følge.

I øvrigt, man kan jo også nøjes med at offentliggøre en modforanstaltning i første omgang.

7
26. marts 2018 kl. 21:58

Af den kaliber af sårbarheder, der er offentliggjort af Claus Vesterhammer og Improsec, så må de gøre hvad de vil, De vil aldrig blive misbrugt alligevel. Det har de slet ikke potentiale til. Tager jeg fejl når jeg antager at de deltager i den kommende "infosecurity 2018" messe?

Jeg "bugger" mig.

6
23. marts 2018 kl. 20:19

opdager man en sårbarhed der ikke er kendt, eller i hvertfald ikke offentliggjort så har man 2 valg:

  1. man kan offentliggøre den med PoC, gerne et script eller lignende

  2. man kan udnytte den til hvad man nu har lyst til

det er mulighederne i min optik... og hvorfor? alt andet end 1. er forkert i mine øjne (sådan har jeg ikke altid tænkt ;).

5
23. marts 2018 kl. 14:56

Jeg har været med på sidelinien i responsible disclosure (RD) i mange år, så synes jeg kender mange argumenter. Tidligere holdt vi stærkt fast i RD, som at man informerer $vendor og giver dem en fair chance til at fixe.

Det baserer sig så på den forudsætning, som det også bemærkes her, at andre IKKE har fundet samme sårbarhed. Det holder så desværre ikke, og derfor bliver RD kun en hjælp for leverandøren, og til skade for forbrugeren/brugeren af produktet.

Specielt med IoT er jeg nu tilhænger af straks-publicering. Finder jeg en sårbarhed i et IoT-produkt, så vil jeg jeg ikke tøve med at sende det ud straks. Hvis JEG kan finde det, så er der formentlig allerede nogen som har fundet samme, eller arbejder på det.

Det er fair at vi ved hvilke sårbarheder der er i de produkter vi bruger, så vi kan fjerne dem eller på anden vis begrænse skaderne/risiko. #burn #motherfucker #burn

... skulle det så have den afledte effekt at nogle producenter gentagne gange viser sig at have mange dårlige produkter, så formoder jeg også kunderne kan hjælpe med det problem :-)

Faktisk handlede NGI keynote på TROOPERS18 om samme problem, https://insinuator.net/2018/03/tr18-next-generation-internet-ngi-summaries/

4
23. marts 2018 kl. 12:42

(som AMD havde ved CTS releasen)

Hvor man næsten skulle have administratorrettigheder for at ødelægge systemet, eller adgang til hardware med en loddekolbe.

Om ikke andet, et meget useriøst og umoralsk foretagende, som ikke har overholdt gængs praksis.

Om det var kursmanipulation eller betalt tilsvining fra Intels side, har jeg ikke helt forstået nu. Men kan da godt forstå at Intel virkeligt er bange, da de INTET har der kan slå AMD, anden end de selv køber Vega delen. Men hvis de virkelig skal lave noget der kan slå de meget billige flerkernede processor fra AMD, så begynder de at kannibaliseret deres eget top segment. Og på mobilsiden, så er AMD foran, for første gang i mange år. Tror vi igen ser et 50/50 fordeling af salg af CPU mellem dem. inden for et år eller to.

er der nogle som følger slagets gang og ved noget mere, både med hensyn til påstået fejl i Ryzen og salgstal ?

Har selv meget positive erfaringer med 2200G, og hvis man kan "klare" et 2-3 frames tab i spil, på lav opløsning i spil, så er Ryzen 1600 også et godt køb til gamer desktop, hvis man ikke har frie tøjler økonomisk. Den kan så alt andet bedre end Intel. Men venter stadig på at se hvordan 2700U klare sig i en mobil.*

https://www.pcgamesn.com/amd/amd-ryzen-5-1600x-review-benchmarks

  • Ja, er træt af Intels prispolitik og udvikling. Som har stået stille i mange år, på grund af også ulovligt konkurrenceforvridende tiltag fra Intel.
    Så når der Intel forsøger FUD, så kommer der lidt modspil.
3
23. marts 2018 kl. 12:20

Præcis. Men lige som med så meget andet så får du jo også et smæk hvis du glemmer at stille parkeringsskiven eller hvis du overser et brev fra kommunen.

Det er også rimeligt nok at hvis firmaet så svarer tilbage at de anerkender problemet og skal bruge mere tid at de så kan få det før man går public med det. Inden for rimelighedens grænser.

Men hvis de end ikke anerkender det eller ikke prioriterer det så mangler de jo selv rettidig omhu. Og så har jeg ikke ondt af dem.

2
23. marts 2018 kl. 09:00

Jeg tror desværre ikke man skal regne med at ret mange firmaer har en interresse i at bruge tid på at fixe security bugs, hvis der ikke svæver en trussel om det bliver exponeret til offentligheden at deres produkt er usikkert.

Om det så skal være 1 dag (som AMD havde ved CTS releasen), 60 eller 180 dage.. ja det ved jeg ikke.. "rimelig tid" er nok svært at definere.. der er måske en værdi i at holde sig inden for nogle "standard tider". som f.eks Googles project zero har (90 dage).

Og når man så lækker sin information bør man måske gøre det ud fra et synspunkt at eksempler måske ikke skal være direkte reproducerbare til exploits.

Men alt ialt er jeg rimeligt overbevist om at såfremt huller ikke bliver fixet af leverandøren efter rimelig tid, ja så skal det offentliggøres, også selvom det kommer til at gøre ondt.

1
23. marts 2018 kl. 07:20

H is improsec har givet en leverandør 60 dage hvilket må siges at være en rimelig tid eftersom de selv har source koden, og de så ikke reagerer er bolden vel også på leverandørerns halvdel.

Hvis de vælger at ignorerer en fejl i deres software og der kan dokumenteres at de fik mulighed for at rette fejlen så ville ingen have lidt skade hvis de havde rettet fejlen. Og dermed er det vel ikke improsec der skal stå på mål.