MySchoolApp Junior lekt privacygevoelige gegevens basisschoolkinderen

Het zoontje van een goede vriend gaat naar basisschool De Grote Reis (onder bestuur van de RVKO) in de regio Rotterdam. Begin 2016 werd ik door deze vriend gebeld met de vraag om eens door een beveiligingsbril naar de app MySchoolApp Junior (iOS, Android) te kijken. Sinds een aantal maanden werd deze, door Orange in a box BV ontwikkelde app, door de school ingezet om te kunnen communiceren met de ouders/verzorgers van het schoolgaande kroost. Zo kunnen ouders/verzorgers hun contactgegevens up-to-date houden, maar bijvoorbeeld ook aangeven of hun zoon of dochter zonder begeleiding naar huis mag, bepaalde allergieën heeft, of een bepaalde geloofsovertuiging heeft. Los van het feit of dergelijke bijzondere persoonsgegevens vastgelegd mogen worden, begrijp ik prima dat ouders/verzorgers en onderwijsinstellingen een communicatiebehoefte hebben. De uitvoering laat echter te wensen over, en de opvolging naar aanleiding van een responsible disclosure melding op 2 februari 2016 ook.

Verschillende kwetsbaarheden

Nadat ik van de vriend in kwestie een geldige gebruikersnaam en wachtwoord kreeg, startte ik vanuit een man-in-the-middle positie (op basis van een WiFi Pineapple en Burp Suite Professional) met een analyse van het verkeer tussen de iOS app en de server op het internet. Eerst maar eens kijken of ik de SSL verbinding kan kapen door een eigen SSL certificaat te injecteren. In de iOS versie lukte dat niet, maar leverde dit wel een foutmelding met veel details op, waaronder de URL van de API waar de app verbinding mee maakt (zie screenshot). Handig, want dan kan ik mijn onderzoek voortzetten op de PC en heb ik de app eigenlijk niet meer nodig. Het injecteren van een eigen SSL certificaat heb ik overigens ook geprobeerd met de Android versie van de app, en toen lukte het wél om een man-in-the-middle aanval over SSL uit te voeren. Dit maakt het mogelijk om ondanks het gebruik een beveiligde SSL-verbinding de gebruikersnaam en het wachtwoord te onderscheppen van de persoon die in probeert loggen (zie screenshot).

Terug naar de API. Met Firefox in combinatie met de RESTClient plugin begon ik met willekeurige data tegen de API te praten. Dat gaf foutmeldingen met nóg meer details (zie screenshot) waaruit ik afleidde dat het StrongLoop API Platform wordt gebruikt. StrongLoop is open-source en goed gedocumenteerd, dus dat gaf me de gelegenheid om te leren hoe deze API werkt, en zo ontdekte ik dat de Loopback API Explorer actief is (zie screenshot). Deze explorer is bedoeld voor ontwikkeldoeleinden en op de website van Strongloop wordt geadviseerd deze op productieomgevingen uit te schakelen. Dat was (en is) niet gebeurd en daar maakte ik dankbaar gebruik van. De explorer gaf me in één klap veel informatie over de gerealiseerde datastructuur, waardoor ik veel gerichter met de API kon communiceren. Veel URLs (API functies) werken alleen met een geauthentiseerde gebruiker, dus wederom beroepte ik me op de documentatie van StrongLoop om een geldig access token te genereren. Daarna had ik alle tijd om de API te bevragen en door de data te spitten. Het access token kent namelijk standaard een geldigheid van 30(!) jaar.

Eenmaal rechtstreeks verbonden met de API had ik vrij snel door dat de autorisaties op dataniveau slecht geregeld zijn. Waar ik verwachtte alleen gegevens van het zoontje van de vriend in kwestie aan te treffen, trof ik in werkelijkheid gegevens van veel meer kinderen en ouders/verzorgers aan. Behalve de eerder genoemde gegevens zoals namen, medische gegevens (allergiën, hartruis, etc) en geloofsovertuiging, trof ik bijvoorbeeld ook adresgegevens, e-mailadressen en telefoonnummers aan. Maar ook onderlinge berichten tussen het onderwijspersoneel en berichten tussen ouders/verzorgers en het onderwijspersoneel kon ik inzien; zo las ik een bericht van een moeder die aan een leerkracht mededeelt dat haar zoontje op een specifieke dag afwezig is vanwege een ziekenhuisbezoek. Foto’s van kinderen zijn zelfs opvraagbaar zonder autorisaties en staan feitelijk open voor het hele internet. Ook trof ik nog oude testberichten aan.

Kortom, de basis voor een datalek is gelegd. De autorisaties binnen de API zijn slecht geregeld, en het is eigenlijk de app die aan ‘de voorkant’ een soort schijn-autorisaties creëert door alleen bepaalde info weer te geven. Hierdoor kan bij ouders/verzorgers onterecht de indruk ontstaat dat er op verstandige wijze wordt omgegaan met gevoelige gegevens, terwijl dat niet het geval is. In de app viel overigens nog op dat NAW gegevens standaard worden gedeeld met andere ouders/verzorgers van kinderen uit dezelfde klas, en dat hier geen opt-out voor is. Ik kan me zomaar voorstellen dat ouders/verzorgers gegevens wel willen delen met school, maar niet met andere ouders/verzorgers.

Opvolging ondermaats

Op 2 februari 2016 meldde ik verschillende aangetroffen kwetsbaarheden onder de noemer responsible disclosure aan de leverancier van de app én de directeur van de desbetreffende school. In eerste instantie werd hier door de leverancier veelbelovend per e-mail op gereageerd; informatiebeveiliging is een belangrijk aandachtsgebied, de ontwikkelaar is meteen aan het werk gezet, en ze waren al in gesprek met een partij om de security van hun platform te laten controleren. De directeur van de school reageerde ook positief en nodigde me uit voor een kennismaking. Hij gaf aan blij te zijn dat ik dit meldde en vond het belangrijk de lekken snel te dichten. Hij introduceerde me bij een ICT beleidsmedewerker van de overkoepelende vereniging en ook daar lichtte ik mijn bevindingen toe.

Daarna was het over met de vermeende proactiviteit. Van de school en de vereniging hoorde ik niets meer, en toen ik twee maanden later geen verbetering constateerde en bij de leverancier informeerde naar de voortgang, werd er uitsluitend verdedigend gereageerd op een wat minder interessant detail (geldigheid van het access token) en werd er geen woord gerept over structurele verbetering of voortgang op dit vlak. Vanaf dat moment besloot ik om het een tijdje te laten rusten. Gedurende de rest van het jaar informeerde de vriend in kwestie ook nog regelmatig naar de voortgang bij de school, maar telkens zonder resultaat.

Een paar weken geleden (ongeveer een jaar na de initiële responsible disclosure) besluit ik een aantal zaken opnieuw te controleren. Tijdens deze hercontrole ontdek ik dat er weinig is gedaan aan het oplossen van de kwetsbaarheden. Op gelijke wijze krijg ik opnieuw toegang tot gevoelige gegevens van derden. Tegelijkertijd valt op dat men in de tussentijd door is gegaan met het gebruiken van de app. Aan de inhoud van een aantal belangrijke ’tabellen’ is duidelijk te zien dat er het afgelopen jaar sprake was een flinke toename in gebruik (zie tabel). Ik tref verschillende logo’s aan van basisscholen in onder andere Rijswijk, Barendrecht, Amsterdam, Nieuwerkerk aan den IJssel, Gouda en Enschede.

Kortom, geen noemenswaardige verbetering van de beveiliging, maar wel een toename in het gebruik. Dát is het moment waarop ik besluit om over te gaan tot publicatie van mijn bevindingen, in de hoop dat hiermee het gebruik van het huidige MySchoolApp Junior platform stopt, en het pas weer in gebruik wordt genomen wanneer de privacy van de schoolkinderen en hun ouders/verzorgers gewaarborgd is. Op 19 januari 2017 informeer ik de leverancier én de (inmiddels gewijzigde) schooldirectie over het feit dat er nog steeds onacceptabele kwetsbaarheden in het platform aanwezig zijn, en dat ik binnen een periode van 4 weken mijn bevindingen publiceer.

Omgang met responsible disclosure moeilijk

Die mededeling deed toch wel een klein stofwolkje opwaaien. Eerst kreeg ik een e-mail van de schooldirectie met de mededeling dat de mensen achter de app contact met mij gaan opnemen en dat de app tot nader order niet meer in gebruik is. Of dit voor alle scholen geldt kan ik niet controleren, maar de login van de vriend in kwestie werkte in ieder geval niet meer. Ook gaf de school aan dat de manier van communiceren als onprettig werd ervaren. Later bleek dat dit gevoel werd veroorzaakt doordat mijn mededeling uit de lucht kwam vallen. Mogelijk heeft er tussen de vorige directie en de huidige een slechte overdracht plaatsgevonden, want ze wisten natuurlijk al lang dat dit speelde. Niet alleen bij de school, maar ook bij het bestuur van de vereniging.

Ook de leverancier gaf aan dat er wat hem betreft eerst een gesprek plaatsvindt zodat in gezamenlijkheid bepaald kan worden welke vervolgacties hierbij horen. Hij zou me bellen voor een afspraak, maar heeft dat vervolgens nooit gedaan. Wel ben ik nog gebeld door een security consultant die naar eigen zeggen was ingehuurd door de school om te helpen met het verbeteren van de informatiebeveiliging, en nog even wilde horen welke kwetsbaarheden ik nu had ontdekt. Aan de directie van de school liet ik overigens nog weten dat er wat mij betreft geen sprake is van overleg, maar dat ik hooguit nogmaals een toelichting kan geven op mijn bevindingen. Ik heb hierbij duidelijk aangegeven dat de situatie uitzichtloos voelde, en dat ik daarom heb besloten om mijn bevindingen te publiceren: “Omdat er het afgelopen jaar geen gebruik is gemaakt van de gelegenheid om de situatie te verbeteren, het er ook niet naar uitzag dat dit ging gebeuren, en ik ook niet proactief ben geïnformeerd over voornemens op dit vlak, bereik ik een punt waarop ik middelen aangrijp om een onveilige situatie een halt toe te roepen. En dat is in dit geval publicatie. Het voelt misschien niet zo, maar dit is in het belang van de school, en het belang van de kinderen.”

Toch weer bijzonder om te zien dat deze organisaties in mijn ogen eigenlijk niet goed begrijpen wat een responsible disclosure inhoudt, en dus ook niet weten hoe ze hiermee om moeten gaan. Een jaar niets gedaan om de situatie te verbeteren, totdat de digitale schandpaal ineens in zicht komt en dan ineens in gesprek willen gaan en reken op schappelijkheid. Ik wil me graag schappelijk opstellen, maar wanneer er gedurende een jaar ondanks herhaalde verzoeken geen sprake is van (intentie tot) verbetering, dan is de schappelijkheid een keer op. En dan moet je wat mij betreft ook de consequenties durven aanvaarden, en met de billen bloot. Ik hoop dat de problemen snel worden opgelost zodat ouders/verzorgers en onderwijsinstellingen met deze app veilig kunnen communiceren. Ook hoop ik dat de school kan uitsluiten dat persoonsgegevens (als gevolg van de aangetroffen beveiligingslekken) zijn blootgesteld aan verlies of onrechtmatige verwerking, want die deadline van 72 uur (meldplicht datalekken) is inmiddels verstreken.

Screenshots

Update 11 februari 2017

De afgelopen dagen kreeg ik regelmatig de vraag waarom ik ‘slechts’ 57 records in de tabel kids heb aangetroffen, terwijl de tabellen guardian en people aanzienlijk groter zijn en dit niet in verhouding lijkt te staan tot het relatieve kleine aantal kids. Aangezien er nooit fatsoenlijk contact is geweest met de leverancier, en er dus ook nooit een toelichting is geweest op het onderliggende datamodel en de implementatie ervan, kan ik hier alleen een educated guess doen.

De records uit de tabel kids horen waarschijnlijk bij kinderen die naar dezelfde school gaan dan het zoontje van de vriend wiens accountgegevens ik heb gebruikt. Er lijkt hier dus sprake te zijn van een soort begrenzing in de inzage mogelijkheden. De tabellen guardian en people kennen deze inzagebegrenzing niet, en zijn waarschijnlijk school-overstijgend. Als deze aanname klopt en ik op basis hiervan aan het extrapoleren sla, dan betekent dit dat er op dit moment gegevens van ongeveer 400 kinderen (7 scholen x 57 kinderen per school) in het platform MySchoolApp Junior zijn opgeslagen. Aangezien er waarschijnlijk sprake is van pilot fases (dit was bij de school in kwestie ook zo), is mijn verwachting dat de aantallen per school nog gaan toenemen. Omdat het bedrijf achter de app een commerciële organisatie is, en het verdienmodel is gebaseerd op het verkopen van de app aan scholen, is het aannemelijk dat het aantal scholen ook zal toenemen.