Je reis delen met je familie, vrienden én met 23 miljoen onbekenden

Het hele bestaansrecht van Polarsteps zit in dat ene mechanisme: een reis bijhouden voor je eigen kring, met de garantie dat je zelf de grens trekt. Zet jij je account op privé, dan zien alleen jouw volgers waar je bent. Zo niet, dan is de informatie openbaar. Een simpel, begrijpelijk model. Dat is ook precies waarom mensen de app vertrouwen met gevoelige informatie, zoals je real-time locatie en je thuisadres.

Hoe de kwetsbaarheid technisch in elkaar stak

Wat er precies misging, blijft voorlopig een reconstructie op basis van het onderzoek van Follow the Money en berichtgeving van onder meer NOS en Security.NL, niet van een officieel forensisch rapport van Polarsteps zelf. Op basis van de genoemde publicaties is echter wel een helder beeld te schetsen van hoe de kwetsbaarheid werkte.

De Polarsteps-app en -server praten met elkaar via een technische koppeling, de API, waarbij op de achtergrond informatie wordt uitgewisseld. Daar zit ook de kwetsbaarheid. Polarsteps werkt met een REST API die de mobiele app gebruikt om reizen, gebruikersprofielen en foto's te synchroniseren met de server. Die API kent verschillende onderdelen voor onder meer reizen, gebruikersprofielen en volgersrelaties, en een mechanisme dat in bulk data ophaalt en wegschrijft tussen app en server. De authenticatie om deze data te kunnen uitwisselen verloopt via een token dat aan een account hangt, vergelijkbaar met een sessiecookie (lees meer over deze cookie in onze andere blog).

Het probleem zat niet in die authenticatie zelf. Een geldig token bewees wie je was, tot zover niks geks. Het probleem zat in het stuk erna: autorisatie. Oftewel wat een ingelogde gebruiker vervolgens mocht opvragen. Trip- en gebruikers-ID's waren op te vragen zonder dat de server controleerde of de aanvrager daadwerkelijk volger was en daarmee toegang mocht hebben, of dat een reis als privé stond aangemerkt. Met een geldig eigen account, en dus een geldig token, kon je in theorie het volgnummer van andermans reis of het klantnummer van een willekeurig ander account invullen (vergelijkbaar met een reisnummer of klantnummer) en gewoon antwoord krijgen. Geen foutmelding, geen check, gewoon data.

Een bekend patroon: Broken Object Level Authorization

Dat is het klassieke patroon van broken object level authorization (BOLA). Een kwetsbaarheid die al jarenlang bovenaan de OWASP API Security Top 10 staat. Het onderscheid tussen authenticatie (wie ben je) en autorisatie (wat mag jij zien) werd op het niveau van individuele objecten niet gemaakt. Volgens de reconstructie van FTM bleek er zo een verschil te bestaan tussen wat gebruikers op basis van de privacy-instelling in de interface mochten verwachten en welke gegevens technisch via de API beschikbaar waren.

Twee factoren maakten het volgens de FTM-reconstructie extra ernstig. Rate limiting zou hebben ontbroken of niet hebben gewerkt. Hierdoor bestond er geen drempel tussen één nieuwsgierige gebruiker en het maandenlang scrapen van 23 miljoen accounts vanaf één IP-adres. Ook zou het verwijderen van een ongewenste volger niets hebben veranderd aan de toegang via de API zelf, omdat die toegang nooit aan de volgersrelatie was gekoppeld. De noodrem was met andere woorden niet aangesloten op het systeem dat hij moest afremmen, althans volgens de lezing van FTM.

Polarsteps bestrijdt in een officiële reactie overigens dat er sprake is van een datalek: het bedrijf stelt dat FTM alleen toegang kreeg tot data van accounts die zelf hadden gekozen voor "Iedereen kan mij volgen" in plaats van "Alleen mensen die ik goedkeur", en dat geen wachtwoorden zijn buitgemaakt of accounts zijn binnengedrongen. Het bedrijf erkent wel dat de schaal waarop die data kon worden uitgelezen groter was dan bedoeld, en zegt de API-beveiliging inmiddels te hebben aangescherpt. De Autoriteit Persoonsgegevens staat in contact met het bedrijf en het onderzoek naar de precieze toedracht en omvang loopt op het moment van schrijven nog.

Waarom dit verder gaat dan een risico in een enkele reisapp

Het probleem bij Polarsteps was wat mij betreft geen abstract privacyprobleem. Volgens FTM waren tientallen militairen tot op hun kazerne en missielocatie te volgen. Mensen die bewust geen eigen naam gebruikten, waren via GPS-tracks en fotolocaties alsnog identificeerbaar en te volgen. Precies het scenario waarvoor de privacy-instelling bedoeld was, en precies het scenario waarover FTM en Polarsteps van mening verschillen.

Het makkelijke antwoord op deze casus is dat Polarsteps een klein team was dat een fout heeft gemaakt. Het ongemakkelijke antwoord is dat vrijwel elk bedrijf hetzelfde patroon in huis heeft, alleen dan in de vorm van een koppeling met een externe partij in plaats van een consumentenapp.

Zodra data worden gedeeld met een derde partij om een bedrijfsproces te faciliteren, ontstaat exact dezelfde vraag als bij Polarsteps: wordt op elk niveau gecontroleerd wie welk object mag opvragen? Of leunt de bescherming op het feit dat "normaal gesproken" alleen de juiste mensen die koppeling gebruiken? Een paar situaties waarin dit patroon in de praktijk terugkomt:

Een HR-afdeling deelt personeelsgegevens via een API-koppeling met een salarisverwerker, met als doel de maandelijkse loonadministratie af te handelen. Als die koppeling geen strikte, per-medewerker autorisatie kent, kan een fout in de configuratie ertoe leiden dat gegevens van medewerker A opvraagbaar zijn via een verzoek dat eigenlijk voor medewerker B bedoeld was.

Een klantenservice deelt klantdossiers met een extern CRM- of chatbotplatform, met als doel geautomatiseerde afhandeling van vragen. Ook hier geldt: als de koppeling werkt op basis van klant-ID's die simpelweg opeenvolgend of te raden zijn, en de externe partij niet valideert of de aanvragende sessie ook echt bij die klant hoort, ligt hetzelfde lek op de loer als bij Polarsteps.

Een logistiek bedrijf deelt planning- en locatiegegevens met een vervoerder of trackingpartij, met als doel klanten realtime inzicht te geven in hun zending. Precies zoals bij Polarsteps draait dit om het delen van locatiedata via een API voor een legitiem doel. Als de autorisatie daarbij op zendingsniveau niet is afgedwongen, kan een klant in theorie de trackingcode van een andere zending invullen en gewoon de locatie van een vreemde levering zien.

In alle drie de gevallen is de dataflow zelf niet het probleem. Het delen van gegevens voor een bedrijfsproces is vaak noodzakelijk en legitiem. Het probleem ontstaat op het moment dat niemand expliciet heeft getoetst of de koppeling met de externe partij per object controleert wie waar recht op heeft. In plaats van te vertrouwen op de aanname dat de koppeling toch alleen door de juiste partij wordt gebruikt.

Wat kunnen we hiervan leren?

Een product of koppeling communiceert een privacy- of vertrouwelijkheidsbelofte, terwijl de achterliggende architectuur die belofte niet afdwingt. Een paar concrete lessen:
Autorisatie hoort server-side en per object afgedwongen te worden, ook in koppelingen met leveranciers en ketenpartners. Vertrouw nooit op wat de client toont of verbergt, en ook niet op de aanname dat een externe partij zich netjes aan de bedoeling van een koppeling houdt.

De server moet bij elke request opnieuw checken of déze aanvrager dít object mag zien, niet alleen of de koppeling als geheel geautoriseerd is. Test je eigen koppelingen als aanvaller, niet als gebruiker. Probeer met een geldige eigen toegang bewust de ID van andermans object op te vragen.
Werkt de knop, of werkt alleen de interface?

Rate limiting zet een rem op geautomatiseerde data-extractie door het aantal aanvragen per minuut te beperken. Het is geen bijzaak, ook niet bij interne of ketenkoppelingen. Het verschil tussen een incident en een lek van 23 miljoen accounts zat voor een groot deel in het ontbreken van een simpele drempel.

Een verantwoord gemelde kwetsbaarheid vraagt om actie, niet stilte. Responsible disclosure is gebaseerd op een eenvoudige afspraak: onderzoekers melden beveiligingsproblemen eerst vertrouwelijk, zodat een organisatie de kans krijgt deze op te lossen voordat details openbaar worden. Dat proces werkt echter alleen als meldingen serieus worden genomen. Polarsteps liet weten dat het probleem al bekend was, maar ondernam geen actie. Dat een onderzoeker vervolgens naar de media stapt, is niet het probleem. Dat is het gevolg.

Tot slot

De ironie van het Polarsteps-incident is dat het lek niet zat in wát er werd gedeeld, maar in de belofte dát je zelf bepaalt met wie. Elke organisatie die gegevens deelt, met gebruikers, met leveranciers, met ketenpartners, draagt dezelfde verantwoordelijkheid. Die belofte moet standhouden op elke laag van het systeem, niet alleen op het scherm of in het contract.

Auteur: Bram Nijenhuis, incident responder bij Tesorion