Gps-trackingapp iSharing lekt locatiegegevens van miljoenen gebruikers

De locatiegegevens en persoonsgegevens van de ruim 35 miljoen gebruikers van gps-trackingdienst iSharing waren tijdelijk voor alle gebruikers inzichtelijk. De fout waarmee dit mogelijk werd, is afgelopen weekend verholpen.

Via de app iSharing kunnen gebruikers hun locatie realtime met elkaar delen. Ook kunnen ze berichten sturen, bijvoorbeeld in geval van nood. De bedoeling is dat de locatiegegevens van gebruikers alleen inzichtelijk zijn voor de gebruiker zelf en degene naar wie ze gestuurd worden. Maar door kwetsbaarheden in de app waren locatiegegevens inzichtelijk voor alle gebruikers van de app, zelfs als deze niet actief met een ander gedeeld werden, schrijft TechCrunch. Daarnaast waren namen van gebruikers, profielfoto's en de e-mailadressen en telefoonnummers waarmee wordt ingelogd inzichtelijk.

Het probleem ontstond doordat de servers van iSharing niet goed controleerden of een gebruiker wel toegang had tot de opgevraagde gegevens. De data werd inzichtelijk door een gebruikers-ID op te geven, die opeenvolgend bleken te zijn. ISharing zelf wijt de problemen aan een feature genaamd 'groups', waarmee gebruikers hun locatie met een groep van andere gebruikers kunnen delen. De servers zouden niet goed gecontroleerd hebben of gebruikers wel toegevoegd mochten worden aan een groep van andere gebruikers.

Het probleem werd ontdekt door Eric Daigle, een student aan de University of British Columbia in Vancouver. Hij deelde zijn bevindingen met iSharing, maar hoorde niets terug. Na twee weken besloot hij TechCrunch om hulp te vragen bij het benaderen van de appmakers. Afgelopen weekend werden de problemen verholpen. Yongjae Chuh, medeoprichter van iSharing, zegt tegenover TechCrunch dankbaar te zijn dat de problemen gemeld zijn. Chuh stelt verder dat er geen aanwijzingen zijn dat de bugs zijn gevonden voor Daigle ze ontdekte.

Reacties (25)

[watercoolertje]

Maar door kwetsbaarheden in de app waren locatiegegevens inzichtelijk voor alle gebruikers van de app

En daarna wordt gezegd dat het juist in de backend zit (imo ook de enige logische plek):

Het probleem ontstond doordat de servers van iSharing niet goed controleerden of een gebruiker wel toegang had tot de opgevraagde gegevens.

Lijkt mij dus dat de eerste opmerking niet correct is, de kwetsbaarheid zit hem niet in de app zelf.

[Reactie gewijzigd door watercoolertje op 24 juli 2024 13:04]

[sys64738]

Het kan best zijn dat ze het allebei controleren (of hadden moeten controleren, in dit geval). Maar uiteindelijk is je backend eind verantwoordelijk. Die had dit gewoon tegen moeten houden.

[watercoolertje]

De frontend zou het kunnen controleren maar op basis van een call naar de backend want die moet in de database kijken naar bepaalde relaties en daarmee de toegang bepalen.

Dat je in de frontend netjes een melding krijgt hoort daar inderdaad ook bij, dat is meer vanuit UX dan beveiliging natuurlijk want het frontend is bijna niet dicht/veilig te krijgen.

[Reactie gewijzigd door watercoolertje op 24 juli 2024 13:04]

[Zebby]

Is het ondertussen niet standaard dat je bij ALLE extern toegankelijke punten een check toevoegt voor de correcte rechten?
Backend lijkt mij ook de logische plek, maar man wat knullig.

[Zoop]

Doorgaans doe je daar praktisch niets mee aan de frontend, die heeft doorgaans geen weet van de rechten, nog zou je moeten willen dat de clientside over dat soort informatie beschikt. Hooguit wat roles waar de client zelf beperkt van kan bepalen "je hebt x-rol, dus content dat niet van y-user (jij) is, is sowieso error" maar das best knullig. Je client doet een request, server zegt mag niet, client laat bericht zien. En klaar ben je. Meestal heb je niet meer dan dat nodig en zit je dus niet met clientside checks te hannesen.

In dit geval kan je als gebruiker je locatiegegevens met een ander delen. Dus dat is iets wat je naar hun server stuurt "geef x toegang aan y", server controleert dat, en nu heeft x rechten en krijgt een linkje om dat in te zien. Dus hoe kan dit de app zijn fout zijn als iedereen het ineens in kan zien? Het zou wel erg zwak zijn als de app kan zeggen "geef * toegang aan y", wat mij ook niet het geval lijkt.

Dus dit ging gewoon fout aan de serverkant, die controleerde niet goed of iets rechten had voordat de content geserveerd werd. Heeft app dus niks mee te maken. Raar nieuwsbericht.

[Argantonis]

Een app is niet alleen wat er op je telefoontje draait. Het staat gewoon voor applicatie. Dat is bij een groot soort applicaties alleen maar een grafische laag op je telefoon en verder alle slimme logica in de backend.

[Zoop]

En waar draait die backend? Doorgaans op een server. De app is dan client / frontend. Dus de app is wel alleen wat er op je telefoontje draait, ook al is dat maar een progressive web app ofzo.

Je zegt niet dat de app een probleem heeft wanneer het de server betreft. Althans, dat lijkt mij de volksmond.

[Argantonis]

Mja, voor mij is dat een onzinnige definitie want die grafische laag is maar weinig interessant in een applicatie als deze. Als je een of andere lokale game of videobewerkingsapplicatie hebt ofzo is het wat anders. Maar deze applicatie doet helemaal niks zonder het backend-stuk, alle belangrijke logica zal in de backend zitten.

[sys64738]

Wat knullig en erg nalatig. In 2003 gebeurde dit zo nu een dan. Maar anno 2024 zou iedereen toch beter moeten weten.

Ook altijd mooi dat bedrijven die zulke enorme fouten begaan, wel altijd heel snel uit kunnen sluiten dat er misbruik is gemaakt van dit lek. Als je al niet controleert of die gegevens bij de ingelogde gebruiker horen, hoe weet je dan dat er niemand die eerder gedaan heeft?

En ook nog eens de arrogantie om iemand die dit ernstige lek meldt, doodleuk te negeren. Ik zou schrikken en het toch even controleren voor de zekerheid.

[Reactie gewijzigd door sys64738 op 24 juli 2024 13:04]

[watercoolertje]

Ook altijd mooi dat bedrijven die zulke enorme fouten begaan, wel altijd heel snel uit kunnen sluiten dat er misbruik is gemaakt van dit lek. Als je al niet controleert of die gegevens bij de ingelogde gebruiker horen, hoe weet je dan dat er niemand die eerder gedaan heeft?

Er is helemaal niks uitgesloten, iig niet volgens de tekst in het artikel. Hun uitleg sluit het namelijk niet uit, ze zeggen enkel geen aanwijzingen te hebben gevonden:

Chuh stelt verder dat er geen aanwijzingen zijn dat de bugs zijn gevonden voor Daigle ze ontdekte.

[Reactie gewijzigd door watercoolertje op 24 juli 2024 13:04]

[sys64738]

Je hebt gelijk. Ze hebben het heel mooi ontwijkend geformuleerd.

Bij elke serieuze partij, kun je dit interpreteren als: het is zo goed als zeker niet gebeurd. Maar bij deze tent, komt het eigenlijk gewoon neer op: we hebben geen flauw idee.

Ignorance is bliss.

[watercoolertje]

Je hebt gelijk. Ze hebben het heel mooi ontwijkend geformuleerd.

Dat hebben ze zeker slim gedaan, ze hoeven het niet eens iets gecontroleerd te hebben om dat te kunnen zeggen. Dus het zegt eigenlijk niks, maar het komt wel over alsof er niks aan de hand is...

[kodak]

Het is te makkelijk om als bedrijf het probleem bij een feature te leggen. Als een feature namelijk zoveel invloed op de basisfunctionaliteiten heeft dan is er eerder iets behoorlijk mis met de basis.

Dat mag ook wel opgemaakt worden uit de te 'raden' unieke gebruiker-ids om gegevens ol te kunnen vragen en een gebrek aan reactie bij een enorm security probleem.

[5pë©ïàál_Tèkén]

Dat is het bijna logische gevolg van features-first denken bij het bouwen van een applicatie. Het moet het allemaal doen, en zo snel & goedkoop mogelijk. 'Later' kijken we wel of de applicatie ook niet doet wat het niet hoort te doen, maar ja - dát is geen feature. Opeenvolgende IDs is een doodzonde, maar ja -snel, makkelijk en geen idee van de mogelijke gevolgen. Met het ontwerpen van de applicatie had op een makkelijke manier voorkomen kunnen worden dat 'vergeefelijke' kwestbaarheid uitgebuit kan worden tot een database rooftocht.

[comatoast]

We are grateful to the researcher for discovering this issue so we could get ahead of it, our team is currently planning on working with security professionals to add any necessary security measures to make sure every user’s data is protected.

wow , iedere zichzelf respecterende app-store zou na zo'n uitlating dat developer-account toch moeten verwijderen??

[CAPSLOCK2000]

Wow , iedere zichzelf respecterende app-store zou na zo'n uitlating dat developer-account toch moeten verwijderen??

Deze applicatie zit niet in F-Droid. Veel andere zichzelf respecterende appstores ken ik niet.

Zonder gekkigheid, het zou met verbazen als meer dan 10% van de applicaties is bekeken door een security professional.

[Heaget]

Dit is toch wel schering en inslag tegenwoordig, en wederom lijkt een bedrijf er heel laconiek over te doen. Ligt het dan echt aan mij, maar ik zou toch wel graag zien dat een bedrijf hier iets meer het boetekleed aan trekt. En daarnaast, als iemand een ernstig lekt meld, dan zou je daar op zijn minst naar moeten kijken...

Het is echt precies dit wat me enorm stoort. Overal zie je dit gebeuren, gebruikersgegevens komen op straat te liggen, maar bedrijven maken zich er makkelijk vanaf.

[CAPSLOCK2000]

Er zullen consequenties moeten komen. Nu zijn die er eigenlijk niet. Klanten vertrekken niet wat ze voelen heel goed aan dat het overal een puinhoop is en ze kunnen zelf onmogelijk beoordelen wie het een beetje beter dan de rest doet.

Ik heb van dichtbij gezien hoe er wordt geprofiteerd van de aandacht die een security lek oplevert. Het levert even een hoop aandacht op en drie dagen later is iedereen al weer vergeten waarom dat bedrijf in het nieuws was maar is wel de naam bliven hangen. Zelfs bij een privacyspecialist heb ik gezien hoe een beschamend securityprobleem netto een enorme instroom van nieuwe aandacht en inkomsten opleverde.

Ondertussen is het downplayen van security ook een groot ding. Ergens is het een coping mechanisme. Als je het niet snapt dan kun je wanhopen en jezelf dom vinden, of besluiten dat het eigenlijk niet zo belangrijk is. Als je geen idee hebt wat je zou moeten doen maar wel beseft dat het veel geld zou kunnen gaan kosten is het aantrekkelijk om het probleem maar gewoon te ontkennen, onwaarschijnlijk te achten of proberen de verantwoordelijkheid te verplaatsen.

Als slachtoffer kun je niks. Als je naar de rechter zou gaan dan moet je bewijzen dat je schade hebt. Dat gaat haast niet omdat dit soort data niet rechtstreeks gebruikt wordt om mensen te beroven. Het gaat allemaal veel subtieler. Indirect komt er informatie in vage databases terecht die beslissen over welke advertenties je te zien krijgt, welke kortingen je worden aangeboden, hoeveel je betaalt voor verzekeringen, of je klant-is-koning-behandeling krijgt of wordt afgescheept als domme sloeber, en die in het algemeen gebruikt wordt om mensen te modelleren, te profileren en te manipuleren.
Het is haast niet te bewijzen dat het gebeurt in de meeste gevallen gaat het per keer om hooguit een paar cent schade. Maar het zijn wel honderden keren per gebruiker per dag (iedere advertentie die je ziet is een potentieel geval). Dan moet je honderden rechtzaken beginnen voor een paar cent schade per zaak, dat kan niet werken.
Dan kun je gaan proberen aan te tonen hoeveel schade je hebt geleden omdat je een andere advertentie hebt gezien, maar bewijs maar eens dat je (bv) door reclame een paar duizend euro meer hebt betaalt voor een auto dan zonder.

Voor de bedrijven die onze data voor ons bewaren zijn er eigenlijk geen negatieve consequenties bij security problemen. Ik denk dat we veel strengere regels nodig hebben voor het opslaan van data inclusief verplichte onafhankelijke controles vooraf. Niet, zoals nu, pas een security specialist inschakelen nadat het fout is gegaan.

[Reactie gewijzigd door CAPSLOCK2000 op 24 juli 2024 13:04]

[Thijs Iedema]

@EvelineM er staat een typo in de titel bij gebruikers

[Drag0nizer]

forumtopic: Spel- en tikfoutjes - en dus *geen* andere foutjes - deel 43

[Chloverdose]

Geachte redactie

[Mark_88]

breezertaal lijkt het wel

[Sangre]

ow in mijn tijd noemde we het 1337-speak, tijden veranderen :-)
overal z's en 0rz achter plakken

[Reactie gewijzigd door Sangre op 24 juli 2024 13:04]

[Mark_88]

Wiki NL noemt breezertaal ook wel een Nederlandse aftakking daarvan idd. Praktisch hetzelfde zou ik zeggen!