RIVM: beveiligingslek Infectieradar ondanks controles niet ontdekt
Het beveiligingslek in de Infectieradar van het Rijksinstituut voor Volksgezondheid en Milieu (RIVM) waardoor het zeer eenvoudig was om medische gegevens van deelnemers in te zien is ondanks verschillende veiligheidschecks niet ontdekt. Dat laat het RIVM in een nieuwe verklaring weten. De Autoriteit Persoonsgegevens is inmiddels over het datalek geïnformeerd.
Het RIVM houdt op verschillende manieren de verspreiding van infectieziekten in de gaten, wat ook geldt voor het coronavirus. Hiervoor wordt onder andere de website Infectieradar gebruikt. Deelnemers kunnen één keer per week doorgeven of zij in de afgelopen week koorts of andere klachten hebben gehad. Bij het aanmelden voor Infectieradar moet een formulier met medische gegevens worden ingevoerd. Het gaat dan om het gebruik van medicijnen en waarvoor dit is, of deelnemers roken of allergieën hebben en of men zwanger is. Deze invulde formulieren waren voor derden toegankelijk, zo werd dit weekend duidelijk.
Deelnemers aan Infectieradar krijgen een uniek nummer van acht cijfers, dat bij het invullen van de vragenlijst zichtbaar in de adresbalk van de browser was. Door het wijzigen van dit cijfer in de adresbalk was het mogelijk om het formulier van iemand anders te bekijken. Een kwetsbaarheid die ook bekend staat als Insecure Direct Object Reference (IDOR). Via een script zou het zo eenvoudig mogelijk zijn om gegevens van allerlei andere gebruikers te verzamelen. Nadat het datalek was gemeld besloot het RIVM de database offline te halen.
"De gegevens van deelnemers aan Infectieradar zijn door niemand anders ingezien dan door de journalist en de aan hen meldende beveiligingsexpert", zo stelt het RIVM. Het ging om 49 aanmeldformulieren, waarvan de journalist en de beveiligingsonderzoeker hebben laten weten de gegevens zo snel mogelijk te zullen vernietigen.
Het RIVM heeft een melding gedaan bij de Autoriteit Persoonsgegevens van het datalek en alle deelnemers ingelicht waarvan de gegevens zijn ingezien. Volgens het Rijksinstituut waren er verschillende veiligheidschecks op de gebruikte software uitgevoerd, maar was het beveiligingslek niet aan het licht gekomen. We hebben het RIVM gevraagd om wat voor soort checks het precies ging en zullen het artikel bijwerken zodra we een reactie krijgen.
Afsluitend meldt het Rijksinstituut dat de softwareleverancier inmiddels een oplossing heeft doorgevoerd die zowel door het RIVM als een externe partij wordt getest. "Zodra we zeker weten dat de vragenlijsten veilig worden opgeslagen, gaan we verder met Infectieradar." Het is al wel mogelijk voor mensen om zich aan te melden voor Infectieradar. Deze gegevens worden in een ander systeem opgeslagen.
Met fouten als IDOR ligt het voor de hand dat de ontwikkelaars geen verstand hebben van security en het om een gatenkaas gaat. Als mijn vermoeden klopt en er vakkundige securitytesters op gezet zijn, kan het nog wel even duren voordat deze site weer online is...
Bedenk RIVM is maar één van de vele klanten.
De problematiek wordt nu helderder.
- een login bij het RIVM (enquete formulier invullen) is zeer moeilijk veilig te propageren naar formdesk.
- een verwerkingsprobleem in formdesk is via een CVD (voorheen responsible disclosure).https://www.ncsc.nl/documenten/publicaties/2019/mei/01/cvd-leidraad lastig door de vele niet zichtbare partijen.
+ Het Rivm doet enkel de analyses houdt zich verre van de techniek.
+ SSC-campus doet de meeste techniek voor het rivm maar niet wat via SAAS bij andere partijen loopt
+ Al deze partijen zijn niet direct zichtbaar voor iemand aan de buitenkant
Het laagdrempelig zijn van meldingen is niet op orde.Het advies om voor het melden een formulier te gebruiken heeft in dit geval iets van kafka. Het is de externe dienstverlener voor formulieren war het mis gegaan is.
Link uni leiden:
https://www.medewerkers.universiteitleiden.nl/ict/ict-werkplek/software-en-samenwerkingstools/webformulieren-maken
"Met Formdesk kun je online formulieren maken. De tool gebruik je voor inschrijvingen voor evenementen en het opvragen van feedback. Je vraagt een account aan via de ISSC Helpdesk.
Inloggen
Log in op Formdesk met je Formdesk-account."
Link uni Utrecht
https://www.formdesk.nl/universiteitutrecht
Als de mensen van de universiteiten nooit iets van het datalek gemerkt hebben, dan moet het wel een erg bijzonder iets zijn. Die situatie draagt niet bij in het accepteren van kunnen melden van softwarefouten.
Het is gelukkig geen dienstverlener die een dominante positie in de markt heeft.. Het zal snel opgepakt worden.
@Erik je vraag is hierbij beantwoord, ik werkte aan deze tekst voordat je post zichtbaar was. … vooruitzien ….
IK ben me nog aan het verbazen over wie er nog meer gebruik van maakt.
De voorbeeldformulieren geven een aardige indruk van de klanten en het soort gebruik.
Deze ligt er bij het RIVM nu ook uit:
https://magazines.rivm.nl/2018/07/magazine-omgevingsveiligheid/nieuwe-versie-handboek-omgevingsveiligheid
Je moet een formulier invullen om dat handboek te krijgen.
Een Karma4 onwaardige bijdrage, deze is leesbaar, nagenoeg geen taalfouten, geen directe FOSS bashing.
Niet gewend van je, ga zo door. :-)
Een "capabele partij" die niet test op IDOR is als een viroloog die beweert dat bronwater het middel is tegen Covid-19.
Je kan je ook nadrukkelijk afvragen wat de informatiebeveiliging waard is als RIVM diverse beveiligingschecks claimt te hebben uitgevoerd, en geen enkele daarvan kijkt blijkbaar naar het archief van de meest geaccepteerde top 10 van beveiligingslekken ter wereld...
Wat erger is: Zo moeilijk is het niet om een web pagina als geheel te downloaden met een commando of script. Combineer dit met een IDOR fout en een oplopend volgnummer en presto, je hebt de hele administratie in minder dan een kwartiertje en kan op je luie stoel in Verweggistan op je gemak gaan uitzoeken wat er van je gading bij zit...
iets nooit goed en veilig krijgen.
(in het algemeen kun je al stellen dat je met testen wel kunt aantonen dat iets niet deugt, maar niet dat het OK is)
te vertrouwen zijn, en zelfs dan nog zijn ze eigenlijk niet geschikt voor gevoelige data (of dat nou persoonsgegevens zijn
of andere zaken die geheim moeten blijven)
We hebben op het werk een ander pakket, maar dat slaat formulierdata op in een Sharepoint lijst. Iedereen die toegang
heeft, heeft toegang tot de hele lijst (geen row-level authenticatie) en dus kun je altijd bij de gegevens die anderen hebben
ingevuld in hetzelfde formulier, op zijn minst tot die "verwerkt en weer verwijderd" zijn.
Voor veel toepassingen helemaal niet erg, maar je loopt snel tegen problemen aan en helaas verwatert de routine van
"eerst checken of dit tool wel ingezet kan worden in dit geval" natuurlijk al snel.
Met fouten als IDOR ligt het voor de hand dat de ontwikkelaars geen verstand hebben van security en het om een gatenkaas gaat. Als mijn vermoeden klopt en er vakkundige securitytesters op gezet zijn, kan het nog wel even duren voordat deze site weer online is...
Er zijn twee mogelijkheden:
1) De veiligheidschecks zijn uitgevoerd door niet-capabele mensen
2) De checks zijn slecht, verkeerd, niet, of maar gedeeltelijk uitgevoerd.
Het is nu maar wachten op het antwoord.
iets nooit goed en veilig krijgen.
(in het algemeen kun je al stellen dat je met testen wel kunt aantonen dat iets niet deugt, maar niet dat het OK is)
Overigens garandeert geen enkele methode dat je alle kwetsbaarheden vindt. Maar kwetsbaarheden van het type IDOR zijn dusdanig goed gedocumenteerd dat ze bij elke webapptest op de checklist horen te staan, en dus ontdekt hadden moeten worden.
iets nooit goed en veilig krijgen.
(in het algemeen kun je al stellen dat je met testen wel kunt aantonen dat iets niet deugt, maar niet dat het OK is)
Ook met audits kun je dat niet.
Ik ken een bedrijf die kapitale fouten maakt en dan ligt het hier op security.nl altijd aan de beheerders.
Ik ken een bedrijf die kapitale fouten maakt en dan ligt het hier op security.nl altijd aan de beheerders.
Dit moet In het framework (de applicatie) gedaan worden, html en het os bieden niets.
Ik hoor het riedeltje van argumenten waarom er niet gekeken mag worden. Toch verbazend het brede gebruik zelfs bij universiteiten en dat tot nu toe niemand wat opgevallen is.
Met fouten als IDOR ligt het voor de hand dat de ontwikkelaars geen verstand hebben van security en het om een gatenkaas gaat. Als mijn vermoeden klopt en er vakkundige securitytesters op gezet zijn, kan het nog wel even duren voordat deze site weer online is...
https://www.rijksoverheid.nl/onderwerpen/rijksoverheid/auditbeleid/auditdiensten
Ik ken een bedrijf die kapitale fouten maakt en dan ligt het hier op security.nl altijd aan de beheerders.
Dit moet In het framework (de applicatie) gedaan worden, html en het os bieden niets.
Ik hoor het riedeltje van argumenten waarom er niet gekeken mag worden. Toch verbazend het brede gebruik zelfs bij universiteiten en dat tot nu toe niemand wat opgevallen is.
ik kan je vertellen dat een std IT dienst van een universiteit niet de top-notch computer savy tech IT dienst is. de echte goede ITers op een uni zitten eerder bij wetenschappelijke groepen en hebben 'dr' voor hun naam staan. de centrale ITers zijn vaak gesjeede studenten of oude uitvallers of spul dat het in de commerciele IT wereld niet meer trekt / redt. ook is menig IT dienst bij een uNi opgezet met std (voornamelijk windows) beheerders en wordt voor elk moeilijk appart iets een smak geldt uitgezet naar extrene consultants. van die laatst groep heb je ook van alles tussen het vlugge-neefje tot aan een clubje juniors van een grotere gerenomeerde toko die seniors beloofd heeft, maarja, krijg je in de praktijk dan niet. soms zit er een enkele capable zzper zo maar per ongeluk tussen die dan na een maand of twee weer hard weg rent omdat er vooral veel politiek door management gedaan wordt in de uitgeholde dienst zelf. ik weet dat dit bij bedrijven vaak niet anders is.
Dat is de standaard en je had het daarbij kunnen laten.
Windows beheer kost geld uni's zijn bolwerken van goedkoop en dat anderen het wel doen. Beheer tja was dat niet iets vervelends wasr je niet in opleid en liever niets aan doet.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Information Security Officer (2fte)
Een uitdagende rol waarbij jij, op basis van security, de vertaalslag maakt tussen business en IT en direct bijdraagt aan de veiligheid van informatie binnen de gemeente Almere. Dat is in een notendop waar jij als Information Security Officer mee bezig bent. Interesse gewekt? Door groei van de organisatie zijn we op zoek naar twee nieuwe collega’s.
Specialiseer je in Forensisch ICT
Online informatieavond 19 november
Wil jij je specialiseren in digitaal forensisch onderzoek? Je kennis verbreden en tech-nische vaardigheden ontwikkelen? Ontdek de cursus- en opleidingsmogelijkheden van Hogeschool Leiden:
- Bachelor Informatica Forensisch ICT (deeltijd)
- Master Digital Forensics (vol- en deeltijd)
- Module Mobile Forensics
- Module Data Analytics
Interesse? Meld je aan!
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
