Gegevens 2385 patiënten AMC-ziekenhuis lagen op straat

Gegevens van 2385 patiënten van het Academisch Medisch Centrum in Amsterdam waren in te zien dankzij een kwetsbaarheid bij een pagina van een derde partij. Naast naw-gegevens ging het om onder andere burgerservicenunmmers, verzekeringsgegevens en afspraken.

Het lek betrof het online inschrijfformulier van de polikliniek Mondziekten, Kaak- en Aangezichtschirurgie van het AMC. De kwetsbaarheid kwam vorige week vrijdag aan het licht toen Nelson Berg van beveiligingsbedrijf BinaryIT online een afspraak bij het AMC moest maken om zijn verstandskies te laten trekken. "Ik ben nieuwsgierig en loop dan soms even de beveiliging na. Dankzij een waarschuwing op de site en met behulp van sqlmap kreeg ik via sql-injectie toegang tot een database met 3500 records", vertelt Berg aan Tweakers.

Het bleek een database van een derde partij te zijn, waarin tal van gegevens over patiënten stonden. Het ging om naam, adres, woonplaats, verjaardag, geslacht en e-mailadres, maar ook om bsn, verzekeraar, verzekeringsnummer, huis- en tandartsinformatie en afspraken. Berg nam na de ontdekking contact op met het AMC en stuurde zijn bevindingen naar het NCSC.

Volgens Berg was de informatie 'in strijd met de procedures' bij de derde partij gehost: "Iedere particuliere developer kon bij de gegevens." Volgens de beveiligingsexpert zijn er meer sites van het betreffende bedrijf vatbaar voor sql-injectie. Sql-injectie is een veelgebruikte aanvalsmethode door hackers, maar ook iets dat relatief eenvoudig is te voorkomen. Dat gebeurt ook steeds vaker omdat er veelvuldig incidenten aan het licht komen waarbij kwaadwillenden databases plunderen na sql-injectie.

Een woordvoerder van het AMC bevestigt tegen Tweakers dat de kwetsbaarheid heeft bestaan en dat het uiteindelijk 2385 personen betrof: "We hebben de pagina na de melding gelijk offline gehaald. Deze is zo'n 4 á 5 jaar geleden waarschijnlijk online gegaan. Op de website van het AMC stond een link naar de pagina."

Het AMC heeft een Information security & privacy protection officer maar het potentiële datalek bleef buiten zijn radar. "Die moet dan wel weten dat er een externe pagina ergens staat. We zijn zorgvuldig, maar het bleek toch niet zorgvuldig genoeg. We laten nu alle externe webpagina’s testen op kwetsbaarheden", aldus de woordvoerder.

Het AMC heeft patiënten om wie het ging ingelicht over het incident en heeft het lek gemeld bij de Autoriteit Persoonsgegevens.

Reacties (78)

Ik heb de volgende mail ontvangen.

Geachte heer/mevrouw,

In het verleden hebt u een afspraak gemaakt via het online-inschrijfformulier van de polikliniek Mondziekten, Kaak- en Aangezichtschirurgie van het AMC.
Op vrijdagavond 24 februari jl. werd het AMC er op geattendeerd dat deze webpagina was gehackt. Hierdoor kreeg de “hacker” toegang tot de inschrijfgegevens van degenen die via deze pagina een afspraak hebben gemaakt.

Dit had nooit mogen gebeuren. We vinden het zeer vervelend en bieden u er onze oprechte excuses voor aan.

De betreffende pagina is na de melding direct geblokkeerd (offline gehaald). Er is een onderzoek ingesteld naar de oorzaak van het probleem, en het AMC heeft melding gemaakt van dit incident bij de Autoriteit Persoonsgegevens.

De hacker heeft vrijwel onmiddellijk contact met ons gezocht. Hij is eigenaar van een website over hacken, en heeft een bedrijf dat zich specialiseert in de digitale beveiliging. Het is hem niet te doen om de gegevens zelf, maar om de kwetsbaarheid van websites aan te tonen.
Hij heeft aangegeven dat hij de gegevens op de inschrijfpagina niet heeft ingezien of gekopieerd, maar dat wel had gekúnd. Hij heeft tevens aangekondigd zijn bevindingen over de veiligheid van de inschrijfpagina aan het eind van deze week publiek te maken.
Hoewel uw gegevens dus niet door derden zijn ingezien, trekken wij ons dit zeer aan.

De betreffende pagina is een zogeheten externe pagina. Dat houdt in dat het geen onderdeel is van de amc-website maar wel direct gelinkt is via onze website. Wij laten nu alle externe webpagina’s testen op hun kwetsbaarheid. Zo nodig wordt de beveiliging daarvan aangescherpt, zodat wordt voldaan aan de hedendaagse veiligheidseisen.

Bij het inschrijven via het online formulier heeft u de volgende persoonlijke gegevens ingevuld: naam en initialen, patiëntnummer, BSN, geboortedatum, contactgegevens, inclusief email-adres en (mobiele) telefoonnummer, verzekeraar en verzekeringsnummer, adresgegevens van uw huisarts en tandarts, en een omschrijving van de klacht.
Voor de goede orde, het gaat dus niet om uw medisch dossier. De hacker heeft daar geen toegang toe gehad.

Wij hebben geen enkele aanwijzing dat anderen ooit toegang hadden tot deze pagina, behoudens uiteraard de medewerkers van de polikliniek zelf.

Wij bieden u nogmaals onze excuses aan. We hopen dat we u hiermee voldoende op de hoogte te hebben gesteld, maar mocht u vragen hebben, aarzelt u dan niet om contact met ons op te nemen. We staan u graag te woord. Wij verzoeken u dan vriendelijk om te bellen met onze afdeling Patiëntenvoorlichting via telefoonnr.

[...] Op vrijdagavond 24 februari jl. werd het AMC er op geattendeerd dat deze webpagina was gehackt. [...]

De webpagina is brak geschreven en slecht geprogrammeerd door degene die het AMC heeft ingehuurd. De pagina met een potentieel lek (lees: mogelijkheid tot SQL injectie) is eerder 'ontdekt' dan 'gehackt'.. Dit draagt alleen maar bij aan het 'hacken' stigma.

[...] Hoewel uw gegevens dus niet door derden zijn ingezien, trekken wij ons dit zeer aan. [...]

Hoe heeft het AMC dit zo snel met zekerheid kunnen concluderen? Want ze zeggen zelf:

De betreffende pagina is een zogeheten externe pagina. Dat houdt in dat het geen onderdeel is van de amc-website maar wel direct gelinkt is via onze website.

Het betreft om een externe pagina. Heeft de derde partij alle SQL logs en access logs doorgespit? En zelfs dan zijn SQL injecties niet altijd terug te vinden...

De webpagina is brak geschreven en slecht geprogrammeerd door degene die het AMC heeft ingehuurd. De pagina met een potentieel lek (lees: mogelijkheid tot SQL injectie) is eerder 'ontdekt' dan 'gehackt'.. Dit draagt alleen maar bij aan het 'hacken' stigma.

Computervredebreuk of hacken is het binnendringen ("inbreken") in een computersysteem of netwerk. zie:
http://www.iusmentis.com/...iteit/computervredebreuk/
Het gebruik maken van SQL injection techniek om toegang proberen te krijgen tot de achterliggende database als je geen ingehuurde pentester bent, is dus inderdaad hacken en daarmee strafbaar volgens de wet computercriminaliteit.

Het bericht lijkt het probleem af te schuiven op de hacker. Net alsof het niet hun fout is dat de hele zooi niet veilig is.

Er werd dan ook verstuurd:

[...] werd het AMC er op geattendeerd dat deze webpagina was gehackt.

En niet bijvoorbeeld:

[...] werd het AMC er op geattendeerd dat deze webpagina kwetsbaar is voor hacks.

De NOS rapporteert in dit geval ook (hoewel feitelijk waar) dat de man een "hacker" is terwijl hij een alinea later is hij in eens een "beveiligingstester".

Een hacker heeft door een beveiligingslek toegang gekregen tot de inschrijfgegevens van patiënten van het AMC in Amsterdam.

Het lek is ontdekt door een beveiligingstester.

Bron: http://nos.nl/artikel/216...patienten-amc-gelekt.html

[Reactie gewijzigd door JonKoops op 28 februari 2017 23:29]

Deze wet gaat wat mij betreft ook echt veel te ver zonder duidelijke inkadering voor responsible disclosure.

Uhm, nee niet perse.
Er dient sprake te zijn van opzet, wederrechtelijkheid en geen sprake van straf/schulduitsluitingsgronden.

Volgens de richtlijnen, heeft hij het keurig gedaan en mag het OM vervolgens geen vervolging instellen. (rechtszekerheid en vertrouwensbeginsel)

Maar een chronologie met inbraak is in dit geval wel op zijn plaats:
Zelfs als iemand een deur open laat staan, mag je niet naar binnen. Maar je mag wel tegen de deur duwen en naar binnen scheeuwen om te kijken of de deur daadwerkelijk ongewenst openstaat. In dat geval is er namelijk geen sprake van wederrechtelijk handelen.

In dit geval ligt er bij wijze van spreken een sleutel voor een voordeur opstraat. Puur die sleutel in het slot steken om te kijken of 'ie bij die woning hoort, schept niet direct een wederrechtelijke handeling.

In dit geval hebben mensen een sleutel zichbaar in de gang gehangen en heeft de "inbreker" de sleutel nagemaakt op zicht en door de deur te openen en naar binnen te scheeuwen gedemonstreerd dat de sleutel in het zicht een gevaar opleverd. Ook dat schept niet direct wederrechtelijk handelen.

Wederrechtelijk handelen betekend niet enkel dat je toestemming moet hebben, maar betekend dat je in essentie niet iemands rechten onnodig schaad.

Als ik dit lees en dan hoe ze er vervolgens mee omgaan en hoe er conclusies worden getrokken en dan zonder onderbouwing als waarheid wordt verspreid. Ook aannames worden zonder onderbouwing of voorafgaand onderzoek verstuurd naar de getroffen mensen. Het lijkt wel of het allemaal is om de boel te sussen. Maar mijn vertrouwen in al die systemen en vooral de mensen die er mee werken gaat alsmaar omlaag. De eerste de beste politicus die roept dat mijn gegevens veilig worden opgeslagen bij een nieuw project, krijgt mijn stem in ieder geval nooit. Ze weten totaal niet hoe het werkt.

Wat gaan ze er aan doen dat die mensen, waarvan de gegevens waren, later niet in de problemen komen? Al die informatie kan tegen je gebruikt worden. Gaan zij daar voor opdraaien? Een brief of email en het boetekleed aantrekken is niet voldoende. Ik wil in zo'n situatie garanties.

Hoewel uw gegevens dus niet door derden zijn ingezien, trekken wij ons dit zeer aan.

Volgens mij is die vrij nette mail wel door de afdeling "spindoctor" gegaan. Want er zou natuurlijk iets moeten staan als:

Omdat uw gegevens al die jaren door derden zijn kunnen ingezien, trekken wij ons dit zeer aan.

[Reactie gewijzigd door Redsandro op 28 februari 2017 21:26]

Die regel viel mij ook meteen op. Hoe weten ze zo zeker dat het niet door derde is ingezien?
Volgens mij weten ze alleen zeker dat deze specifieke derde (heeft aangegeven dat hij) het niet heeft ingezien.

Wij hebben geen enkele aanwijzing dat anderen ooit toegang hadden tot deze pagina, behoudens uiteraard de medewerkers van de polikliniek zelf.

Oh ja, dat zal men gerust stellen.
Ze hadden ook geen aanwijzing dat deze beste man toegang had, totdat hij het zelf meldde.

Dit beveiligingsbedrijf/ Nelson gaat wel zijn boekje te buiten en ik kan hier als ethical hacker van beroep niet echt tegen.
Waarom niet?

Het was ethisch geweest om aan te geven aan het ziekenhuis dat je een vermoeden hebt van een vulnerability, maar om deze ook zonder toestemming te gaan onderzoeken met tools, dat mag niet. Je mag niet eens een portscan doen en daar is de wetgeving redelijk strikt over.

Dit is wel een trend die ik de laatste tijd zie.
Lek aantonen zonder toestemming, credits en business claimen.

Fijn dat dit lek gedicht kon worden, maar dat had ook anders opgelost kunnen worden. Hoe?

Zoals ik aangaf: vermoeden van een vulnerability, intern of met behulp van extern pentesten en dichten. Dan hadden er geen brieven verstuurd hoeven te worden.

Waar ligt de lijn van black and white hat nu? Heeft Nelson niet een dump gemaakt?
Hoe kan dat gecontroleerd worden etc..

Ik reageer hier als collega ethical hacker om te onderstrepen wat je schrijft. Je hebt 100% gelijk en deze actie geeft mij de kriebels. Nu ben ik niet helemaal neutraal maar ik vind het ook het boekje te buiten gaan.

Op deze manier leren dit soort mensen het niet af. Er is een duidelijke streep. Ik ben er laatst bijna zelf de mist mee in gegaan. Ik had een enigszins kwetsbare situatie ontdekt bij de Belastingdienst. Niet een groot lek maar wel een problematische situatie die opgelost moest worden. Ik had daarvan een screenshot geplaatst op Twitter en had de gevoelige gedeelten weggestreept. Toch had ik daar later spijt van want het was pure sensatiezoekerij van mij waar niemand wat aan had behalve ik en mijn naamsbekendheid.

Onderdeel van de bronvermelding en het contact met Tweakers zal zijn geweest een link naar de website van het bedrijf. Hartstikke goed en daar heb ik geen problemen mee want dat zou ik ook graag willen in een soortgelijk geval maar ik geef Tweakers mee: vraag je af of je aan dit soort publicaties wil meewerken als het ethische randje is opgezocht en wellicht is overschreven. De NOS heeft besloten de naam van het bedrijf en de hacker niet te vermelden namelijk. Is dat omdat ze het ethische randje wel zagen? Ik weet het niet. Maar in andere publicaties vermeldt de NOS wel de persoon die het gevonden heeft en dit geval niet.

Ik snap de punten. Graag wil het volgende gedachte experiment met jullie uitvoeren.
Situatie A:
1,.
Je vindt zo'n error (Dan heb ik het over dit: https://binaryit.net/wp-content/uploads/2017/02/response.png)
2. Je maakt een melding in de ban van "Geachte heer/mevrouw, er is misschien iets mis ik zou er even naar kijken"
Eindstand:
Na een aantal weken komt dit bij iemand terecht die hier wat mee kan, en het hopelijk ook oplost, de getroffen gebruikers worden 100% niet ingelicht. Ook wordt er hoogstwaarschijnlijk niet naar de logbestanden gekeken.

Situatie B:
1. Je vindt de error.
2. Je verifierd dit, en je stelt vast wat de impact/consequenties zijn. In dit geval het lekken += 2300 zeer gevoelige gegevens.
3. Je stuurt een email naar het NCSC met de bevindingen.

Eindstand:
Het lek wordt binnen 6 uur gedicht en de gebruikers worden op de hoogte gesteld. Er wordt vastgesteld of het lek eerder is uitgebuit

Welke oplossing is het eerlijkst voor de gebruikers en verkleint het risico voor verdere uitbuiting?

Welke oplossing heeft de samenleving het meeste baat bij?

Maar je kan er natuurlijk ook voor kiezen om jezelf te verheerlijken als een super ethische hacker.

Ik heb overigens nooit Tweakers(of een andere media instantie) gevraagd mijn site te noemen in een artikel.

Groetjes,

Nelson

[Reactie gewijzigd door Nelzb op 1 maart 2017 02:35]

Ik wil niet de moraalridder uithangen zoals de ethische hackers waar je op reageert. Waar jij een punt hebt met je gedachte experiment hebben zij echter ook wel degelijk een punt door te zeggen dat dit ook anders opgelost had kunnen worden.

Ben het met je (en andere die op je gereageert hebben) eens dat in sommige gevallen het doel de middelen heiligt, maar dat vind ik in jouw gedachte experiment niet opgaan. Je kunt namelijk ook situatie C schetsen:

1. Je constateert een mogelijk probleem.
2. Je neemt contact op met het AMC en vraag of je doorverwezen kan worden naar de Security Officer/IT afdeling.
3. Die leg je kort uit wat je geconstateert hebt en ga samen in overleg voor de vervolgstappen (met afgewogen keuzes testen of het daadwerkelijk zo is. logs onderzoeken etc._

Indien het AMC in situatie C niet meewerkt of snel genoeg handelt, dan zijn er nog steeds andere wegen te bewandelen waarmee je het AMC enigzins kunt dwingen er aandacht aan te besteden.

In situatie B stap 2 vind ik namelijk dat je een risico neemt. Aangezien jij de code aan de andere kant van de pijp niet kent, moet je daar niet mee tamperen door dingen uit te proberen. Er is namelijk in zo'n geval ook een kans op grotere problemen zoals datacorruptie, en hoe brak het dan ook allemaal gemaakt mag zijn, dan vind ik in zo'n geval jou verantwoordelijk voor de schade die aangericht is. Daarom is het belangrijk om met de andere partij in overleg te treden zodat er weloverwogen keuzes gemaakt kunnen worden op welke manier getest gaat worden of het probleem daadwerkelijk een probleem is.

En ja, ook bij mij jeukt het als ergens bijzonder geprutst wordt en andere mensen daar de dupe van zijn. Ik zie liever ook dat de bedrijven die dergelijk prutswerk leveren aan de schandpaal genagelt worden of op z'n minst gedwongen worden om al hun geleverde werken bij al hun klanten verplicht te laten onderzoeken. Maar dat betekent niet dat we dergelijk prutswerk aan moeten tonen op een trial en error manier die mogelijk schade teweegbrengt waar zowel de klant van het prutsende bedrijf, als de indirecte slachtoffers (in dit geval de patienten) de dupe van kunnen worden.

Just my two cents

Sorry hoor, maar je hebt gewoon de wet overtreden

En dan een gedachten-experiment naar aanleiding waarvan je drie vragen stelt die je vervolgens niet eens beantwoort. En dan op de man gaan spelen...
Volges mijn kun jij nog veel leren over ethiek

Als jij vindt dat ik de wet heb overtreden, dan zou ik je adviseren om aangifte te doen bij de politie.

Ik kan sowieso nog vrij veel leren. Ik ben (relatief) namelijk nog vrij jong.

Maar goed. Ik zie dat je wederom niet inhoudelijk ingaat op wat ik zeg en kiest om mij persoonlijk aan te vallen, goed gesprek.

"De wet overtreden" is gewoon nodig om dingen aan het licht te brengen die anders niet zichtbaar worden. Je kunt lekker politiek gaan lopen doen en er maanden overheen praten OF je pakt de koe bij de horens en lost het op in een dag.

Prima actie zo. En Een rechter mag bepalen wat de straf wordt. Jij niet.

Aan jou vast niet besteed maar ik zeg het toch:"je kunt geen omelet maken zonder een ei te breken".

Hou toch op man. Heb je aandelen in het AMC ofzo? Als de patiënten er geen last van hebben, mag het AMC ( en de rest van de ziekenhuizen / ingehuurde bedrijven die elke keer in het nieuws komen betreft datalekken ) tot de grond toe afgebrand ( niet letterlijk uiteraard! ) worden! Het moet maar eens stoppen met dat datalekken elke keer en dat doe je door het zo groot mogelijk in het nieuws te krijgen. Verder neem je de leaseauto's in van iedereen die betrokken is en nog wat andere maatregelen.

Elke keer is de patient de dupe en het ziekenhuis zegt: Ow sorry, wat dom.

BTW:

En dan een gedachten-experiment naar aanleiding waarvan je drie vragen stelt die je vervolgens niet eens beantwoort.

Denk dat die vragen beantwoorden jou ook nog wel lukt, toch?

@Nelson Goed bezig kerel, ga zo door! Maar blijf wel rekening houden met je responsible disclosure!

Het is op het randje, omdat je data in hebt kunnen zien die niet voor jou ogen bestemd is.

Feit is wel dat datalekken vaak niet eens gefixt worden als het niet aan de grote klok wordt gehangen.. zelfs bij grote bedrijven als Microsoft .

Uiteindelijk vind ik de oplossing van Nelson een lastige. Je kunt er niet 100% zeker van zijn of er een vulnerability is zonder onderzoek te doen.

Ik vind er ook nog wel een verschil in zitten tussen iemand die 'voor de gein' allerlei websites afstruint en te pas en te onpas probeert in te breken in systemen (al dan niet op de juiste ethical hacker manier) of iemand die vanwege een prive aangelegenheid op een site komt en daar vanuit zijn professie ziet dat zaken niet goed geregeld zijn.

Ik ben zelf tester van beroep en ook ik heb de beroepsdeformatie om af en toe sites waar ik persoonlijk op zit, aan een nader onderzoek bloot te stellen en het bedrijf dan op de hoogte te brengen.
Dat gaat dan niet om datalekken, maar om funcies van websites die niet/nauwelijks werken.

Als ethical hacker krijg je volgens mij in de regel vanuit een bedrijf een opdracht om de sites van dat bedrijf te proberen te hacken. Prima en hard nodig, maar ik vind wel dat als je als particulier of op eigen titel, op wat voor manier dan ook, dit soort lekken tegen komt en dat direct aan het bedrijf/instelling meldt en verder niets met eventueel 'gevonden' data doet, je integer bezig bent met je eigen data-veiligheid en die van een ander.
Of het wettelijk allemaal mag wat ik zeg? geen idee...

Welke oplossing heeft de samenleving het meeste baat bij?

die waar iedereen zich netjes aan de wet houdt

Criminelen houden zich totaal niet aan de wet. Die kunnen dus alles doen en een securityonderzoeker kan niets want die moet zich netjes aan de wet houden.
In dit geval is het toch goed opgelost? De onderzoeker heeft nu waarschijnlijk afspraak kunnen maken zonder gegevens in een bij wijze van spreken publieke database toe te voegen. Het lek wordt gedicht en het AMC heeft gewoon zijn verantwoordelijkheid genomen.

Criminelen houden zich totaal niet aan de wet.

anders waren het geen criminelen natuurlijk, wat heeft dat trouwens met deze zaak te maken?

[Reactie gewijzigd door Anoniem: 167912 op 1 maart 2017 14:00]

De hacker heeft hier ethisch gezien in mijn ogen niks verkeerd gedaan. De kwestie is namelijk: wat is het grotere probleem, het AMC dat slordig met de privacygevoelige gegevens van duizenden mensen omgaat of een willekeurige passant die een tooltje gebruikt?

Het hele punt met tooltjes is dat je ze zou moeten mogen gebruiken omdat ze nooit zouden mogen werken.

En dit soort zaken moeten juist in de publiciteit komen. Het liefst nog met de naam van die externe partij erbij want ervaring leert dat zodra ze ermee weg blijven komen dat ze het blijven doen. In Nederland gaan we vaak met het vingertje wijzen naar diegene die wel verstand van zaken heeft (de hacker hier die ook gewoon niks had kunnen zeggen), terwijl de prutsers die incashen met de grootste bagger het hand boven het hoofd wordt gehouden.

Je kunt niet zo makkelijk stellen dat het AMC slordig met deze gegevens om is gegaan. Het is een extern bedrijf die een stuk software heeft geleverd wat niet goed gemaakt is. Je zou kunnen stellen dat de eindverantwoordelijkheid van dergelijke gegevens bij het AMC ligt, en dat is ook zo, maar het is niet hun core-business om software oplossingen te ontwikkelen. Dus het is doodnormaal dat een 3e partij dat voor ze doet en dat er in de overeenkomsten staat dat dit uiteraard allemaal goed en veilig gedaan moet worden. Gebeurd in de praktijk echter helaas te vaak dat dit niet zo goed en veilig gedaan wordt, maar ik vind niet dat je daar het AMC voor kunt aankijken.

Ik ben het absoluut met je eens.

Net zoals PCR ben ik een ethical hacker en als ik naar de disclosures kijkt van Nelson zijn bedrijf dan is het vrij duidelijk dat hij te ver gaat.

Stop als je vermoed dat er een kwetsbaarheid is, het is absoluut niet nodig om data te downloaden en/of te brute-forcen om aan te tonen dat het "inderdaad" kwetsbaar is. Vaak is een enkele POST/GET request voldoende om het aan te tonen.

Zijn Kamernet disclosure is een goede voorbeeld van hoe niet niet moet. ("I was curious how many messages I could hypothetically access. I wrote this quick python scraper which downloads every 10.000nd conversation.")

[Reactie gewijzigd door Stroopwafels op 28 februari 2017 22:32]

Ik persoonlijk vind dit een prima procedure. Met jouw werk methode zullen bedrijven dit soort zaken nooit serieus gaan nemen. We hebben het hier behoorlijk wat privacy gevoelige informatie. Ik persoonlijk word behoorlijk kwaad als ik lees dat het een sql injection mogelijkheid bestaat. Degene die deze software heeft gemaakt moet lekker op zijn zolder doorgaan met prutsen. Het is onvoorstelbaar dat de AMC dit heeft laten gebeuren. Laat mensen/bedrijven eens hun verantwoordelijkheid nemen. Dat externe bureau is ingehuurd door AMC, derhalve heeft AMC zelf onderzoeksplicht naar beveiliging. Ze hebben notabene een security officer, overduidelijk niet capabel.

"Dan hadden er geen brieven verstuurd hoeven te worden."

Hoezo niet? Het lek was er dus andere hebben er gebruik van kunnen maken.

Ik vraag me af of dit een nieuwe hype kan gaan worden, beveiligingsbedrijf hacked een bedrijf, gaat in contact met een 'dreigement' dat ze openbaar gaan, om vervolgens hun diensten aan te bieden tegen flinke bedragen?

Wie zegt dat het zo gaat? Het ziekenhuis moet toch het boetekleed dragen aangezien alle patiënten moeten aanschrijven. Het kan ook een manier zijn je competentie / expertise aan te tonen en je op die manier in de spotlight zetten voor advies /audit werk. Kan me niet voorstellen dat een beetje ziekenhuis geen ICT security afdeling heeft met een paar FTE maar die hebben het dus niet gezien.

't was blijkbaar een IFRAME, dan gaat de browser van de bezoeker direct naar die externe website en daar ziet het ziekenhuis niets meer van...

Net zoals het belachelijk grote vimeo filmpje op de frontpage van spaarnegasthuis.nl?

Ook een IFrame... Zucht... Leren ze het dan nooit?

En nog een slechte framerate ook!

Ik neem aan dat een groot "bedrijf" als het AMC voldoende kennis in huis heeft om te weten met welke whitehats ze in zee moeten gaan om hun websites plus extern gehoste pagina's te laten onderzoeken.

gezien de information security officer op de hoogte moet worden gebracht van externe links, denk ik niet dat ze weten hoe ze dat moeten doen.
Dat had die persoon in kwestie ook wel een keer een spider over de amc website gegooit om te onderzoeken waar allemaal naar toe gelinkt wordt. Dat is zijn *** werk.

Dat is ongeveer gelijk als een security bedrijf inschakelen voor een audit en dat ze binnen komen met "ik heb een verbinding nodig met jullie netwerk en een admin account". Doe jullie werk, zie maar hoe je verbind vanuit die hal en kijk maar of je een account kan vinden.

Het staat de eigenaar dan toch vrij om een ander in te huren of om de site offline te halen? Ik zie er niet direct een heel sterk chantagemiddel in. Zelfs het argument "huur me in of ik maak het openbaar" schiet niet op, want de eigenaar moet het lek hoe dan ook melden.

Vraag me af of deze hacker eerst toestemming vroeg om de website te pentesten.
Anders zou ik huizen, met een makkelijk te openen deurslot, zo binnen kunnen wandelen en het argument geven dat ik ze 'had' kunnen bestelen. Om daarna schaamteloos mijn anti-inbraak bedrijf te promoten.......

Zou een grappig gedachte zijn, even de beveiliging nalopen bij ieder gebouw waar je binnenkomt haha.

[Reactie gewijzigd door Jaïr.exe op 28 februari 2017 21:19]

Zoek even op 'ethisch hacken' - onder bepaalde voorwaarden is het niet strafbaar.

Je bedoelt waarschijnlijk https://www.ncsc.nl/actue...sponsible-disclosure.html Responsible Disclosure? Dan moet die instelling wel zo'n policy hebben en als de white hat hacker binnen die randvoorwaarden blijft zal de instelling geen aangifte doen.

''Hacken is slechts strafbaar indien dit wederrechtelijk gebeurt. In strikte zin wordt met wederrechtelijkheid bedoeld: 'zonder daartoe gerechtigd te zijn'. Het binnendringen in je eigen geautomatiseerde werk, of met toestemming binnendringen in het geautomatiseerde werk van een derde, is uiteraard niet strafbaar.''

''Vooropgesteld dient te worden dat elke inbreuk op een geautomatiseerd werk zonder toestemming van de rechthebbende strafbaar is, tenzij hogere belangen een dergelijke inbreuk rechtvaardigen. Bij de beoordeling van de vraag of in een concreet geval sprake is van dergelijke hogere belangen zijn drie factoren van belang. In de eerste plaats dient te worden beoordeeld of de hacker heeft gehandeld in het kader van een wezenlijk maatschappelijk belang. Indien deze vraag bevestigend wordt beantwoord dient de rechtbank te beoordelen of de hacker met zijn handelen heeft voldaan aan de eisen van proportionaliteit en subsidiariteit.''

Bron: http://kaarls-strafrechtadvocaten.nl/blog/ethisch-hacken/

---------------------------------------------------------------------------------------------------------------
Bedankt voor de tip.

Een SQL injectie. Ik zou die derde partij aansprakelijk stellen voor brak programmeerwerk.

Veel succes, software is waarschijnlijk voor accoord bevonden.

Ligt eraan hoe het contract is opgesteld. Heb zelf al diverse keren meegemaakt dat we software binnen een jaar na acceptatie alsnog hebben afgekeurd wegens slecht programmeerwerk, ondanks dat het functioneel in orde was. Uiteraard verdisconteert de leverancier dit gewoon in de contractprijs, maar voor software die een hoge beveiligingsgraad moet kennen, is dat niet ongebruikelijk.

In contract opnemen dat de partij kennis heeft van de OWASP top-10 https://www.owasp.org/index.php/OWASP_Top_Ten_Cheat_Sheet en code zal opleveren die robuust is tegen dit soort dreigingen.
In het onderhoudscontract opnemen dat regelmatig (minstens ...) getest zal worden of de dienst nog steeds veilig is voor de dreigingen uit de meest recente versie van de OWASP top-10 en dat code hierop aangepast zal worden indien noodzakelijk (uiteraard via ITIL Change proces)

Arme patiënten, verscheidene van de 2385 hebben eerst letterlijk op straat gelegen en nu hun gegevens...

Letterlijk op straat? 't Lijkt mij niet dat ze alle 2385 met hun gezicht op straat zijn gevallen en daardoor naar de mond- en kaakchirurgie moesten

Nee dat leek mij ook niet zo, vandaar dat ik zei verscheidene

Ik kan me de discussie betreffende 'white' en 'black' voorstellen maar om per definitie te zeggen dat Nelson 'regels' heeft overtreden kan ik zo niet begrijpen.

Graag zou ik willen weten wélke fout Nelson kreeg op de betreffende site en welke informatie hij heeft gestuurd naar het AMC en NCSC.

Er is een vage scheidingslijn tussen black en white die vanuit persoonlijk oogpunt/standpunt geïnterpreteerd kan worden. Maar om nu gelijk iemand tot aan de enkels af te branden omdat hij wederom een lek gevonden heeft gaat mij te ver.

Natuurlijk heeft Nelson computervrede breuk gepleegd.
Hij heeft ongevraagd gegevens uit een systeem waar hij geen toegang tot had gelepeld. Hij heeft daarna de juiste dingen gedaan waardoor hij er met een "foei, niet meer doen" vanaf mag komen.

Wat me steeds hier opvalt, is als een overheidsinstantie dit overkomt er steeds moord en brand wordt geschreeuwd en dat de markt het beter kan. Maar hier zie je weer als voorbeeld dat een organisatie zijn ICT zorgen aan de markt geeft en er nog een grotere puinbak van maakt en misbruik maakt van het vertrouwen.

Het is dus een probleem van ons allen. Waar laksheid optreedt gaat het mis...

Bij de overheid gaat het exact zo. Die huren ook externe bedrijven in om de software te maken. De faal bij software van de overheid zit hem meer in de voorbereidende fase (requirements, specificaties, functionele ontwerpen, etc.) dan in de code.

Het is NCSC, niet NSCS.

Het AMC heeft een Information security & privacy protection officer maar het potentiële datalek bleef buiten zijn radar. "Die moet dan wel weten dat er een externe pagina ergens staat."

Wat je hier dus even rechttoe-rechtaan vertaald zegt is dat je als ziekenhuis een CISO hebt die niet op de hoogte is van mogelijke externe risico's die via IT zijn gecreeerd?

Sorry, maar dat is wel een vergadering waard met alle stakeholders om in een stevig gesprek het een en ander door te spreken, want dit zou echt niet mogen gebeuren. En al helemaal niet bij een ziekenhuis.

[Reactie gewijzigd door mindcrash op 28 februari 2017 21:37]