image

Verzuimapplicatie lekt 300.000 medische dossiers

vrijdag 20 april 2012, 09:22 door Redactie, 14 reacties

De medische en persoonlijke gegevens van meer dan 300.000 Nederlandse werknemers waren door een lek in een verzuimapplicatie maanden lang toegankelijk voor onbevoegden. Dat laat televisieprogramma Zembla vanavond zien. Het gaat om het computerprogramma Humannet van IT-bedrijf VCD, dat kwetsbaar voor SQL Injection was. Volgens professor Bart Jacobs van de Radboud Universiteit Nijmegen is dit het grootste lek van persoonlijke en medische data in de Nederlandse geschiedenis.

Medische dossiers
De applicatie werd door honderden bedrijven en arbodiensten gebruikt, waaronder FC Twente, Gemeente Deventer, Praxis, Bijenkorf, V&D, Hornbach, Beter Bed en Action. De applicatie bevat adresgegevens, verzuim, herstel en re-integratie van werknemers, alsmede medische dossiers van bedrijfsartsen en burgerservice-nummers.

Zembla meldde het lek bij VCD, maar in eerste instantie ontkende de directeur dat zijn applicatie gehackt was. Later gaf de directeur toch toe dat hij niet kan uitsluiten dat er SQL-Injectie heeft plaatsgevonden.

Wachtwoord
Gisteren werd bekend dat de medische gegevens van duizenden Brabanders op straat lagen. Met een voor de hand liggend wachtwoord was het mogelijk om toegang tot de webapplicatie Cyberlab te krijgen.

Daarin worden laboratoriumuitslagen en uitslagen voor functieonderzoeken ingevoerd. Deze website werd uit de lucht gehaald, waardoor een aantal patiënten op testuitslagen moet wachten.

Reacties (14)
20-04-2012, 09:43 door MrBil
Gelijk de programmeur ontslaan. Hoe kun je nou software schrijven waarbij je vergeet op SQL Injecties of bekende vulns te testen? Afschuwelijk..
20-04-2012, 09:48 door Anoniem
Maar het EPD is veilig hoor. Echt waar!
20-04-2012, 09:52 door Anoniem
@MrBil: Natuurlijk hebben de programmeurs grote technische fouten gemaakt, maar de verantwoordelijken zitten toch echt hoger in de organisatie. Blijkbaar waren er geen procedures voor het veilig ontwikkelen van een applicatie, is er niet voor gekozen om programmeurs met specifieke kennis van beveiliging in te zetten en hebben zowel de leverancier als de opdrachtgever het nagelaten om de applicatie te laten testen. Dat klinkt vooral als een ordinaire kostenbesparing.
20-04-2012, 09:59 door Anoniem
Het lijkt de overheid wel.
En natuurlijk komen de verantwoordelijken / directie er mee weg en blijft het bedrijf gewoon bestaan .
Misschien een salarisverhoging voor de directeur ?
1 ding is zeker ; de komende decenia gaan we dit soort berichten dagelijks horen, even wat geschreeuw van het publiek en even later een extra bonus voor het bedrijf.
20-04-2012, 10:17 door Anoniem
die programmeer moeten ze 't recht ontnemen om nog een systeem te ontwikkelen dat belangrijke gegevens verwerkt tot dat hij/zij bewezen heeft dat hij/zij het wel kan.

Dit is echt grove nalatigheid.
Iedereen die nu nog applicaties ontwikkeld of beheerd met SQL injectie lekken kan grove nalatigheid worden verweten.
ik vind dat ze hier niet zonder straf mee weg moeten kunnen komen
20-04-2012, 10:49 door Anoniem
Als de garage een auto aflevert en de chauffeur verongelukt omdat er een paar bouten niet waren aangedraaid, dan kun je dat de leiding wel kwalijk gaan nemen (waarom waren er geen procedures om dit te controleren?) maar ik vind toch dat de monteur dan niet vrij uit gaat.

Evenzo de programmeur in dit geval. Steeds bij alles naar het management wijzen is wel aardig, maar verdorie, een beetje programmeur heeft toch ook zijn trots en moet gewoon goed werk afleveren!

We klagen dat tegenwoordig alle werk verziekt wordt door procedures, protocollen en rapportages maar zodra iemand stomme fouten maakt dan wordt gelijk naar zijn management gewezen want dat is dan verantwoordelijk. Zo'n programmeur zou toch verstand van zijn vak moeten hebben?! Het is toch geen domme aap.

Dat je programmatuur goed moet testen en dat een A&P test nooit een overbodige luxe is voor een applicatie die contact met de buitenwereld heeft, dat is een ander punt. En dat mag je zo'n bedrijf wel aanrekenen.
20-04-2012, 12:51 door Anoniem
Het gaat om twee gevallen.

In het eerste geval is het slordig om de applicatie niet te testen op SQLi. Deze kwetsbaarheid bestaat toch zeker al iets van 12 jaar. Misschien aardig om de site eens met nikto of w3af te analyseren (liefst door de leverancier voordat de site online gaat!).

In het tweede geval draait het om het gebruik van een zwak wachtwoord. Misschien wel gelezen van zo'n geel briefje. Hiervoor zijn ook verschillende programma's om dat te beoordelen.
20-04-2012, 13:35 door Anoniem
Aan alle onwetenden die programmeurs lopen af te kraken, security is vaak een (management)keuze. Het is niet zo dat programmeurs naar eigen inzien lekker aan een applicatie programmeren. Wij krijgen continu opdrachten welke uitgevoerd moeten worden, en die opdrachten zijn meestal wensen van de klant waar dik geld aan verdiend wordt. Zaken als veiligheid, mooie code, kwaliteit, etc etc waar niet direct geld aan verdiend wordt, worden door het management op de lange baan geschoven of zelfs nooit belangrijk gevonden.
20-04-2012, 14:05 door RichieB
Natuurlijk horen programmeurs van online applicaties code te schrijven die niet kwetsbaar is voor SQL injectie. Sterker nog, als je als programmeur de OWASP top 10 niet kent, mag je wat mij betreft nooit meer aan webbased code komen. Maar wat doe je als je een klus inschat op 100 uur werk, maar de klant wil maar voor 40 betalen? En als je hamert op het onafhankelijk laten testen van de applicatie maar de klant heeft daar geen geld voor over? Zonder alle details te weten is het niet te zeggen waar de schuld ligt. Het management blijft echter altijd eind verantwoordelijk.
20-04-2012, 15:38 door Goeroeboeroe
Volgens mij is het eigenlijk vrij simpel met elektronische opslag van dit soort gegevens. Zolang er ergens mensen werken, worden er fouten gemaakt. Dat wordt nog tig keer versterkt omdat heel veel bedrijven alleen in de winst zijn geïnteresseerd. Dit soort gegevens hoort gewoon niet van buitenaf toegankelijk te zijn, hoe makkelijk dat misschien ook is.
Wat ik trouwens mis is het vaste argument dat papieren dossiers ook ontvreemd/gekopieerd kunnen worden. Is er nou echt helemaal niemand meer die durft te zeggen dat je 300.000 papieren dossiers ook kunt bekijken/meenemen/kopiëren, en dat elektronische opslag dus even (on)veilig is als papieren? Flauw hoor!
20-04-2012, 17:05 door Anoniem
Dat SQLi al zo lang bestaat zonder dat er een oplossing voor bedacht is, is droef in het kwadraat.
Dit zou toch wel eens een keer structureel aangepast kunnen zijn?
Waarom pakt de security-industrie dit probleem niet fundamenteel aan.
Als er experts zijn die weten hoe het moet, waarom het dan niet doen?
Of zijn er bepaalde 'belangen' om het zo maar te laten?

Het wachten is dus weer op de volgende website die met SQLi te hacken is....
20-04-2012, 21:19 door RichieB
Er is een fundamentele oplossing voor SQLi: input validatie. Helaas moet dit door de programmeurs van de web app worden gedaan. Het is net als het vragen om een fundamentele oplossing voor bufferoverflows: die is er ook (bounds checking), maar ligt ook in handen van de programeurs.
21-04-2012, 10:55 door Anoniem
Weet iemand welke database gebruikt wordt (bij VCD)? Mysql?
Input validatie is trouwens niet zaligmakend. Databases worden meestal door een gebruikersapplicatie benaderd en die applicatie moet idd zo veilig mogelijk zijn (input validatie, strong authentication,etc). Maar wat te denken van tools zoals Excell, ms-access, toad, mysql,etc?
Die worden weliswaar (hopelijk!) alleen binnen de organisatie gebruikt maar vaak is dan de hele database te benaderen.
Een goede beveiliging in je database is dan erg belangrijk. Denk aan een goede rollen structuur, VPD (virtual private databases), encryptie,etc. Gebruikers moeten alleen dat kunnen zien waar ze voor geautoriseerd zijn.
Mensen die zich blind staren op alleen de applicatie zijn verkeerd bezig. In depth security is volgens mij het toverwoord,

Auditing binnen een database is trouwens ook erg belangrijk en vaak zie je dat dat niet aanstaat. In elke database zou FGA (fain grained auditing) aan moeten staan. Maar iemand moet natuurlijk de audit informatie controleren en beoordelen.

Ivan
21-04-2012, 11:20 door Anoniem
Is er een structurele oplossing voor Sql injection? Nee, nog niet. Maar er wordt aan gewerkt. Zie http://www.petefinnigan.com/weblog/archives/00000513.htm

Sql Injection is trouwens niet alleen mogelijk in de interactie tussen applicatie en database. Ook binnen een database is sql injection mogelijk en daarom zouden interne medewerkers nooit toestemming moeten krijgen om mbv adhoc tools een database te benaderen.

Ivan
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.