T-Mobile US onderzoekt verschijnen gegevens van andere gebruikers in app

T-Mobile US onderzoekt momenteel meldingen van gebruikers die zeggen dat ze de gegevens van andere gebruikers te zien krijgen in de app. Het is niet duidelijk hoeveel gebruikers getroffen zijn. Voor zover bekend zijn alleen Amerikaanse klanten betrokken bij het incident.

Verschillende gebruikers zeggen op X en Reddit dat zij persoonsgegevens en betalingsinformatie van anderen te zien krijgen in de T-Mobile-app. Volgens The Verge kunnen data zoals de aankoopgeschiedenis, creditcardinformatie en adressen in apps van andere gebruikers verschijnen. De provider zegt in een tweet dat er onderzocht wordt wat er aan de hand is. Het bedrijf staat los van het bedrijf dat in Nederland voortaan Odido heet. Een woordvoerder van Odido benadrukt dat er geen gezamenlijke appinfrastructuur is met T-Mobile US.

Reacties (13)

[Masvic]

Ik heb ooit voor een heeeeeeeeeel groot bedrijf een vergelijkbaar probleem opgelost. Het probleem kwam echter zeer zelden voor, maar het gebeurde wel. Weken heb ik gezocht (en het bedrijf zelf maanden). Eerst de logica van de applicatie doorgespitst, gekeken of het in de cache zat, kijken of er ergens een race condition zat... Uiteindelijk kwam ik erachter:

"Async reader may return wrong results on MacOS, Linux, WSL, Docker #659"
https://github.com/dotnet/SqlClient/issues/659

Er zat dus een extreem bizarre bug in de System.Data.SQLClient... Waardoor je soms na een query de verkeerde resultaten terugkreeg!

[Reactie gewijzigd door Masvic op 22 juli 2024 23:14]

[faim]

Mooie workaround ook:
Do not use this SQL client on linux/docker.
Always check the id of the returned result and retry or crash if it is wrong.

[joost00719]

Dat is echt het aller laatste wat ik zou vinden als bug. Holy shit.
Is dat de reden dat er nu twee SqlClient packages zijn voor .NET waarvan de 1ne depricated is? (Microsoft.Data.SqlClient & System.Data.SqlClient)

[Jonathan2011]

Dit heeft te maken met de overgang van .NET Framework (voor Windows) naar multiplatform. Ik denk juist dat de deprecated (Windows) geen bugs heeft.

[gorgi_19]

Ook Windows had die bug, maar de kans dat die daar voorkwam, was een stuk zeldzamer. Het was een timing issue, met connections die async niet goed gekilled worden onder bepaalde omstandigheden.

Die bug had nog een andere gekke eigenschap; als het mis ging, ging hte consistent mis (en schoof hij consistent gegevens op). Enorm lastig te debuggen.

Maar ik mag hopen dat deze bug niet de oorzaak is van de problemen. Die bug meer dan 2,5 jaar geleden opgelost. Nieuwe versies zijn gereleased waarbij deze fout niet meer zit. En het probleem wordt nu pas voor het eerst gesignaleerd.

[Cyb]

Waarom zou je uberhaupt een app van een provider willen gebruiken? Kan dat niet gewoon via een website ipv meteen een app met allerlei onnodige permissies?
Hier heb je hem: https://play.google.com/s...=com.tmobile.pr.mytmobile
Heeft toegang tot: microfoon, storage, foto's, files, camera, locatie, telefoon status, device gegevens etc.

Lijkt er verder op dat T-Mobile het probleem probeert te verbergen:
https://www.reddit.com/r/...6ngntb/is_tmobile_hacked/

Sorry, this post has been removed by the moderators of r/tmobile.

[le1337]

Waarom zou je uberhaupt een app van een provider willen gebruiken? Kan dat niet gewoon via een website ipv meteen een app met allerlei onnodige permissies?
Hier heb je hem: https://play.google.com/s...=com.tmobile.pr.mytmobile
Heeft toegang tot: microfoon, storage, foto's, files, camera, locatie, telefoon status, device gegevens etc.

Lijkt er verder op dat T-Mobile het probleem probeert te verbergen:
https://www.reddit.com/r/...6ngntb/is_tmobile_hacked/

[...]

Een een deel van die toegang word waarschijnlijk alleen gevraagd in de live-chat of zoiets.
En voor de rest is het gewoon gemak, ik heb zelf ook de app voor T-Mobile.
Op iOS kan ik zien dat deze app geen toegang heeft tot mijn foto's, microfoon, camera e.d. (Standaard, dit heb ik niet uitgezet of op nee geklikt iets).

[supersnathan94]

Ik ben altijd benieuwd naar hoe dit soort dingen kunnen gebeuren. Ergens een DB migratie verkeerd gegaan en IDs nu verkeerd gekoppeld?

Ben dit zelf nog niet tegengekomen in het veld, maar ik zal er ooit waarschijnlijk een keer aan moeten geloven dus dan is het wel handig te weten hoe het kan voorkomen.

[MrFax]

Meestal is het een probleem in de (sessie-)caching. Die raakt dan in de war door een bug en geeft opeens de verkeerde sessies aan willekeurige klanten. Met de database zelf heeft het bijna nooit te maken.

[Reactie gewijzigd door MrFax op 22 juli 2024 23:14]

[supersnathan94]

Ah door hergebruik van sessionID’s die al een keer zijn uitgegeven oid?

[R4gnax]

Of lomp door misconfiguratie en data die privé had moeten zijn gewoon niet als dusdanig markeren.

Komt wel vaker voor.

Één van de grootste en bekendste voorvallen van de afgelopen 10 jaar is het kerstuitverkoop-schandaal van Valve, omstreeks 2014-2015 dacht ik.

Als je je profiel geopend had om bijv. extra geld te storten; of hangende aankopen te annuleren omdat de systemen weer eens overbelast waren zoals elke uitverkoop (want het lijkt wel alsof Valve's infra op hamsterwieltjes draait) dan werd dit gewoon publiekelijk gecached door hun CDN, waardoor lukrake volgende bezoekers die toevallig contact legden met dezelfde edge server, jouw profiel kregen te zien.

Dit is wss. weer net zo iets.


(In Valve's geval een schandaal omdat ze meermalen ingelicht waren over de problemen, maar het hele systeem gewoon tijdens de uitverkoopperiode up-and-running hadden gelaten om geen inkomsten te missen, ipv bijv. de uitverkoop tijdeljik op te schorten.)

[Reactie gewijzigd door R4gnax op 22 juli 2024 23:14]

[laurens0619]

Als je volume draait zet je er vaak iets tussen als varnish

je moet dan heel specifiek (vaak obv url/cookies) bepalen wat je wel en niet cached met een cache key. Cache je bv /profile met de key “profile” dan gaat het stuk en krijgt ieder volgend request de cache van de eerste user te zien. Cash je /profile met de key “profile?cookie.userid” dan krijg je alleen eigen cache te zien.

Dat tweaken is soms best lastig want je wil een zo hoog mogelijke cach hitrate zonder dat je verkeerde data deelt

Doe je het goed dan kun je met weinig servers een mega snelle performance bieden. Iets uit cache halen is veel sneller dan een pagina opbouwen met bv db call erbij

[Reactie gewijzigd door laurens0619 op 22 juli 2024 23:14]

[Power2All]

Klinkt als caching die data van andere klanten had, en gekoppeld zat aan iets verkeerds.
Heb ook zoiets gezien bij andere bedrijven met soortgelijke problemen.