ING maakt creditcardoverzicht in de app weer beschikbaar na kleinschalig datalek

Het creditcardoverzicht van de ING-app was tijdelijk niet beschikbaar nadat gebruikers een deel van de creditcardgegevens van twee individuele klanten konden inzien. Ondertussen is het probleem opgelost en is het betreffende overzicht weer beschikbaar.

Het creditcardgedeelte van de ING Bankieren-app werd tijdelijk uitgeschakeld om de verdere onterechte verspreiding van klantengegevens te voorkomen. In eerste instantie kreeg een onbekend aantal ING-klanten de creditcardgegevens van één individuele klant te zien, zo schreef de NOS eerder vandaag. Het ging daarbij om de naam en de eerste en laatste vier cijfers van het betreffende creditcardnummer. Daaropvolgend doken vergelijkbare gegevens van een andere klant in andermans app op.

Ondertussen is er een systeemupdate doorgevoerd en moeten er volgens een woordvoerder van de bank geen creditcardgegevens van anderen meer in de apps van klanten verschijnen. De ING benadrukt dat er in de app verder niets met de gegevens gedaan kon worden, maar heeft wel contact opgenomen met de klanten van wie de gegevens onterecht verspreid werden. "We blijven het monitoren, en bieden onze excuses aan," aldus een woordvoerder van de ING.

Reacties (51)

[casberrypi]

Mijn inschatting: Typisch geval van een caching reverse proxy waarbij persoonlijke gegevens op een URL teruggegeven worden terwijl er no-caching headers ontbreken.

Dat is mij ook eens overkomen. Om dit te voorkomen personaliseer ik dit soort urls graag. Dus de client stuurt een userId mee in de url, ook al zou die userId af te leiden zijn uit de sessie.

[Anoniem: 454358]

User id meesturen in de URL lijkt mij op vele vlakken erg not done.

[casberrypi]

Waarom niet? Welke vlakken?

[lenwar]

Omdat je nooit gebruikersgegevens moet gebruiken als je iets opstuurt in een URL. Stel dat om welke reden dan ook het verzoek wordt omgeleid door een stuk malware of een proxy of iets in die strekking, dan is er één deel van de authenticatie gelekt. (Wat in het slechtste geval 50% is)

Als je al iets met de URL meestuurt doe dan iets tijdelijks en niet aan een account te koppelen iets (voor een derde). Iets van een sessie-id ofzo. Ook niet ideaal maar al een stuk handiger om te doen.

[Flashtoo]

Over HTTPS is die URL niet in te zien. Als je op het punt bent dat een aanvaller je onversleutelde requests kan zien dan heb je grotere problemen dan een gelekte user ID (die je dan sowieso wel zou kunnen zien). Er zijn misschien wel andere redenen te bedenken om de user ID niet in de URL te stoppen (zoals server logs of referrer headers), maar een MITM attack lijkt me er geen.

[rvt1]

al hoewel andere de userid dan niet kunnen zien wil je nog steeds niet dat deze gegevens in een URL staan omdat deze request headers vaak gelogged kunenn worden in proxy's, uiteraard in dit geval dan bij ING zelf.. Alhoewel dat minder gevaarlijk is, wil je deze data nog steeds in niet in een een of andere vage log hebben staan als deze toevallig verkeerd staat geconfigureerd.. en dat kan helaas op meerdere nivo's.

[mobrockers]

Bij de ING zal veruit alles mTLS zijn en zijn het op z'n hoogst de application servers zelf die het kunnen loggen.

[mgizmo]

Never mind

[Reactie gewijzigd door mgizmo op 24 juli 2024 05:44]

[Dorank]

Op het moment dat ik het NOS artikel zag, ik had het idee dat het eerder was van de 15:53 die het artikel nu laat zien., checkte ik mij creditcard en zag ik gewoon mijn eigen gegevens. Wellicht dat er meerdere proxies zijn, mar wellicht is het probleem ook gewoon anders.

[casberrypi]

Dit soort fouten komt vaak kort na een release of change. Wellicht een andere API versie bijvoorbeeld. Het kan goed zijn dat een specifieke client een specifieke API versie forceert.

Meerdere proxies lijkt me ook niet onmogelijk. Een enkele proxyserver kan echt enorme hoeveelheden requests aan, maar liever een setup met twee actieve proxies dan een 'primary' en 'fail-over' server.

[TheekAzzaBreek]

Om dit te voorkomen personaliseer ik dit soort urls graag. Dus de client stuurt een userId mee in de url, ook al zou die userId af te leiden zijn uit de sessie.

Sessie-afhankelijke gegevens (zichtbaar) in een url?
Daar ga je bij een bank niet mee wegkomen.

[casberrypi]

Waarom niet? Overigens was het in mijn geval geen userId maar een per-session random identifier.

'Zichtbaar' is trouwens wel een vreemde woordkeuze. Dit komt gewoon uit een API. Het is geen webpagina.

Verder is het wat veiligheid irrelevant of iets in de URL staat, in een cookie header of een oauth authorization header. We gaan dit verder natuurlijk ook alleen tls encrypted versturen.

Heb je een referentie naar een PCI standards specificatie waar dit in staat of iets dergelijks?

Overigens was dit in een API voor een financiële instelling. Ik kan niet zeggen dat ik onder de indruk was van de inhoudelijke kennis van de mensen die zich daar met veiligheid bezig houden. Wél EV certificering vereisen maar vervolgens gewoon private keys rond mailen. Encrypted, dat nog wel, maar eenvoudig met een dictionary attack te cracken password.

[Anoniem: 370778]

Sessions?????

[TheekAzzaBreek]

Of het op een standaard gebaseerd was weet ik niet, maar het was een probleem dat per se opgelost moest worden in een strikt intern informatiesysteem dat ook niets met betalingen te maken had.
Het werd een 'vermijdbare attack vector' genoemd.

Ik ben de discussie niet aangegaan, als huurling heeft dat geen zin.

[Ventieldopje]

Daar hebben we een Vary header voor?

[casberrypi]

Jazeker, maar dat is een response header. Door de URL uniek te maken per gebruiker neem je dus een extra voorzorgsmaatregel om een caching accident als deze te voorkomen. Vary is overigens gek als je in de headers ook schrijft dat er geen caching zou moeten zijn. Maar again, dat zou ook een extra maatregel kunnen zijn.

[smeerbartje]

Vraag is wel waarom je creditcard gegevens zou willen cachen.

[casberrypi]

Je begrijpt dat dit dus een ongeluk is, en dat je een extra voorzorgsmaatregel neemt om in het geval van een bug een datalek als deze te voorkomen.

[rvt1]

uit uitzettend van een app zou dan het probleem niet oplossen. ING cached niet op de proxy denk ik omdat je dan andere problemen zou zien, en niet alleen bij deze app.

[gunghir]

Ik kon iemand anders zijn CC gegevens inzien.. Op de ING app. heb er een screenshot van gemaakt ook.
best slordig

[MatthiasL]

Knap dat je dat lukt. Meestal als ik screenshot wil maken in de bank app dan blokkeert het systeem dit.

[gunghir]

Ja dat dacht ik ook! Op android sws niet..
IOS liet het gewoon toe

[bierkwadraat]

Dit is enkel in de Android versie geblokkeerd, dat klopt.

[mvrhrln]

Ligt dat aan IOS/Android of aan de implementatie?

[batjes]

iOS heeft geen mogelijkheid om het capturen van het scherm tegen te gaan. De app kan alleen zien wanneer dat gebeurd zviw.

Op Android is het met root te omzeilen.

[svane]

Bij Netflix lukt het me niet om een screenshot te maken van een video (heel irritant) op iOS. Ergens moet er dus wel een manier zitten om dit te blokkeren.

Het screenshieldkit heeft schijnbaar een manier gevonden, en verkoopt deze.

[mvrhrln]

ah, ok, da's dan wel een missertje van Apple.
maar goed, aan de andere kant kan je nog altijd een gewone foto van het scherm maken, dus 100% bescherming brengt het ook weer niet.

[batjes]

De beveiliging tegen screenshots is er voornamelijk zodat andere apps niet kunnen meekijken, is wat minder een probleem op iOS.

[moonlander]

Waarom is er dan niet een optie om tijdelijk de screenshot toe te staan? Bijvoorbeeld screenshot toestaan met de beveiligingscode.

[batjes]

Geen idee, ik gebruik al jaren geen ING meer. Het blokkeren van screenshots werd destijds om die reden geïntroduceerd.

[Finger]

Heel slordig.. het kan altijd nog erger, iemand kon bij de sns inloggen in mijn account omdat ze mijn digi kastje kregen opgestuurd. Gelukkig goed afgelopen omdat het familie van mij was.

[hoi1234]

Maar waarom is het überhaupt mogelijk om met alleen dat kastje in te loggen? Dat moet toch minimaal gebruikersnaam + wachtwoord + kastje zijn?

[Finger]

Bij de sns niet. Je krijgt een code typt het antwoord in en je bent binnen.

[hoi1234]

Maar da's toch geen 2FA? Als iemand je kastje heeft, kan die in je rekening? Of heb je ook de betaalkaart nodig?

[Finger]

Nee niks, dat kastje heeft een pincode maar die stel je bij eerste keer gebruik in. Dus als ze die zoals in dit geval sturen naar iemand met de zelfde voorletter en achternaam kan die hem instellen.

[hoi1234]

En daar vertrouw jij je geld aan toe?

[Finger]

Je moet wat, je moet je geld een beetje spreiden he met die negatieve rentes.

[hoi1234]

Leaseplanbank. Het enige nadeel is dat je je geld daar vast moet zetten, hoewel je ook nog 0,1% rente krijgt op de spaarrekening.

Het schijnt ook dat ik heel goed voor bank kan spelen. Ik geef alleen geen rente. Maar het voordeel daaraan, is dat de rente dan ook niet negatief is.

[Reactie gewijzigd door hoi1234 op 24 juli 2024 05:44]

[BeosBeing]

Het enige nadeel is dat je je geld daar vast moet zetten, hoewel je ook nog 0,1% rente krijgt op de spaarrekening.

Wat bij een inflatie van 2,9% nog nauwelijks zinvol is, behalve als je een groot bedrag op de spaarrekening hebt, maar dan kun je beter in deposito's gaan (als dat nog wat oplevert, Dela* 2%, Finse bank 1,1% overigen minder sommige ook 0.00%) of beleggen, ofwel in een fonds, ofwel zelf)
(*NB Dela valt niet onder het depositogarantiestelsel)

[hoi1234]

Nou ja, bij de SNS krijg je ook niet heel veel meer. Bij leaseplan is je geld in ieder geval veilig.

[BeosBeing]

Nou ja, bij de SNS krijg je ook niet heel veel meer.

Eigenlijk nergens. Banken moeten van de ECB leningen uitgeven, maar stallen het geld van hun spaarders liever bij de ECB. Die is daarom voor dat stallen rente gaan rekenen, maar dat helpt niet want de banken hebben in plaats daarvan hun vergoedingen voor spaargeld dus geminimaliseerd. Ik dacht dat het Bunk-bank was die naar buiten bracht dat de grootste kostenpost die ze als bank hebben, de kosten zijn van het stallen van hun geld bij de ECB.

Bij leaseplan is je geld in ieder geval veilig.

Ook bij die Finse banken (althans ik neem aan dat ze Fins zijn, Rietumu bank e.d.klinken voor mij Fins).

[Zynth]

-dubbel-

[Reactie gewijzigd door Zynth op 24 juli 2024 05:44]

[Joolee]

Dat klinkt mij als een caching-server die niet over de juiste uitzonderingen beschikte. Eerste klant haalt zijn gegevens op, de server cached het resultaat. Tweede klant wil zijn gegevens benaderen en krijgt de gecachte resultaten van de eerste klant terug. Als je meerdere caching servers hebt die de data enkele minuten (of langer) vast houden kun je op deze manier hele vreemde resultaten krijgen.
Je hoort op de caching-server te configureren welke URL's er wel en niet gecached mogen worden, daar is waarschijnlijk een foutje in geslopen.

Ik kan mij herinneren dat Steam deze fout ook ooit gemaakt heeft, het gebeurt vast vaker.

[_Eend_]

Dat probleem was 'iets' groter dan dit: https://www.bleepingcompu...ds-to-account-disclosure/

En dat was in 2015 alweer.. Ik herinner me nog de paniekerige berichten van mijn Steam-vrienden die ineens op het profiel van een compleet andere steam-gebruiker terecht kwamen.

[MatthiasL]

Lag niet aan Steam maar de caching provider for the record.

[Antonio di]

Ik vind het moeilijk vast te stellen wat er nu aan de hand was bij de ING App m.b.t. de creditcard.
Wat ik wel frapant vind:
Volgens het NOS bericht meldt de woordvoerder van de ING dat er een App update is gedaan en dat hiermee het probleem is opgelost. De oorzaak is niet bekend maar het heeft niets te maken met aanval van buitenaf. Tevens weet die woordvoerder te melden dat maar een klein deel van de ING klanten getroffen is , maar een schatting kan die nog niet geven.

Als de NOS journalist het goed verwoordt heeft dan gebeuren er bij de ING wonderen .
Een probleem verhelpen zonder dat je weet wat de oorzaak is en en dat ook nog roepen dat maar een klein deel van de klanten getroffen is, echt fantastisch.

[Reactie gewijzigd door Antonio di op 24 juli 2024 05:44]

[Edgarz]

Goed lezen: Ze weten wat het probleem is en hoe op te lossen.
De oorzaak (dus waarom dook het probleem opeens op) weten ze niet.

[Antonio di]

Zoals gezegd ik kan het niet geheel beoordelen omdat ik er niet de details van weet.
Het kan ook moeilijk zijn de oorzaak te achterhalen. Meestal is een verandering van de App of de omgeving waaronder die draait de oorzaak en is dat soms moeilijk te achterhalen.

Voor mij is een oplossing dat je de "oorzaak" verhelpt.
Het kan zijn dat ze met een 'work-around" aanpassing (de update van de App) een van of de gevolgen van het probleem verholpen hebt. Nadeel daarvan is dat er straks een anders "gevolg" kan optreden.
Het is natuurlijk een beetje hoe je het "probleem" definieert en je het dus ook zo kun lezen als jij doet.
Voor bank zaken ben ik nogal streng .

[Edgarz]

Ik ook. Want het is mijn vak

[metalpro2021]

Zelf meegemaakt in applicatie server: session state server had een race-condititie onder specifieke high-load scenario's. Geen zelfgemaakte software, maar van een grote leverancier. Bleek in 0.005% van alle requests voor te komen.

Symptoom:
Een login resulteerde in een sessie van een andere gebruiker ; dus andere data.

[mphilipp]

Nou...ik zie mijn eigen cc nog steeds niet. Ik merkte dat voor het eerst een paar dagen geleden toen een internet transactie fout ging en ik wilde checken in de app of er iets geks aan de hand was (de kaart was ivm vermissing tijdelijk geblokkeerd geweest). En toen was ie ineens verdwenen in de app. ING gebeld en die snapte het ook niet. Even daarvoor werkte het nog, ook met een internet transactie. Daarna werkte het toch weer, en bleek het (denk ik) gewoon een connectivity issue te zijn (autorisatie via de app duurde te lang oid), maar mijn kaart zie ik nog steeds niet in de app.
Toen ik dit bericht zag, dacht ik meteen aan mijn issue. Er wordt op een of andere manier flink gegoocheld met de cc in de app denk ik. Zal wel een update zijn die niet helemaal goed is gegaan, maar ook niet helemaal goed is teruggedraaid. Kijken wanneer ie weer terugkomt, anders moeten we er nog maar eens een telefoontje aan wagen.