Beveiligingstest ING liet bezoekers denken dat site was geïnfecteerd

De site van ING leek even ten prooi te zijn gevallen aan cybercriminelen. Op mijn.ing.nl werd javascript-code gevonden die op het eerste gezicht gemaakt leek om inlogsessies af te luisteren. De bank zegt dat het een beveiligingstest betreft.

Klanten van de bank ontdekten dat er op de site van ING een bestand werd geladen vanaf het domein primebyte.net. Dit ogenschijnlijk ongebruikte domein is in april van dit jaar geregistreerd, maar de server bevat een javascript-bestand dat weer een url op het in mei vastgelegde domein vsonicw.com aanroept. Beide domeinen worden in de Verenigde Staten gehost.

Op ons forum vond donderdagmiddag dan ook een verwoede discussie over de gebruikte javascript-code plaats. Een nadere analyse van de code leek erop te wijzen dat deze bedoeld is om een soort man-in-the-middle-aanval mogelijk te maken, waarbij de sessie van een nietsvermoedende gebruiker wordt gekaapt. Hoewel het daarmee nog niet meteen mogelijk is om transacties uit te voeren, is het in theorie wel mogelijk om gegevens aan te passen of bijvoorbeeld een Paypal-account aan de rekening te koppelen.

ING zegt in een reactie tegenover Tweakers.net dat er inderdaad javascript-code van een extern domein werd opgevraagd, maar ontkent dat de site is gehackt. "We testen software die ons in staat stelt bepaalde vormen van fraude en phishing op te sporen", aldus een zegsman van de bank.

Meer informatie, zoals waarom de bank hiervoor schimmige domeinnamen en zijn productieomgeving gebruikt, wil de zegsman uit veiligheidsoverwegingen niet geven. Ook wil de bank niet bevestigen of zij de methode achter de testsoftware zelf hebben ontwikkeld of dat deze in handen is van een ander bedrijf. "Verder doen wij hier geen uitspraken over. We willen criminelen niet wijzer maken dan ze al zijn."

Naar het zich laat aanzien heeft ING hiervoor echter wel een externe partij ingeschakeld. Het bewuste papi.js-bestand is eerder ook door klanten van de Alliance-Leicester-bank ontdekt. A&L bevestigde later dat het daarbij gebruikte externe domein eigendom van die bank was.

Reacties (142)

[CodeCaster]

Zoals ik ook al in het topic zei: de enige manier om het verhaal van de ING te kunnen staven is bijvoorbeeld door een virtuele machine in te richten en die te infecteren met malware die erom bekend staat (onder andere) iets met de site van de ING te kunnen doen, en te kijken of er iets gebeurt.

Als de html van het inlogform door dit script naar een extern script wordt gestuurd, dat bijvoorbeeld kijkt of de post-url van het inlogform niet is aangepast door malware, zou het verhaal best kunnen kloppen. Maar echt netjes is het niet, gezien de obfuscated JS en de vage url's.

Hierbij ga ik er dus van uit dat het bewuste script bedoeld is om aanvallen aan de clientkant te detecteren en de gebruiker te kunnen waarschuwen (bijvoorbeeld door het inlogform te verbergen wanneer dit aangepast is, en een waarschuwing te tonen). Wanneer dit waar is zou het natuurlijk ook kunnen dat het enkel gelogd wordt bij ING, en niet aan de gebruiker gemeld, om malwarebouwers niet slimmer te maken dan nodig is.

Als het script echter is bedoeld om een hack-aanval op de site te simuleren om hun "serversidehackdetectiesoftware" hierop te testen zijn ze behoorlijk achterlijk bezig, daar heb je een testomgeving voor.

[Reactie gewijzigd door CodeCaster op 23 juli 2024 23:32]

[Caelestis]

Een test omgeving gebruik je om software, updates en infrastructuur te testen
Als je alleen maar uit gaat van je beveiliging concept in een test omgeving ben je juist achterlijk.

Uit praktijk blijkt dat in een live omgeving vaak dingen naar voren komen waar men niet aan gedacht heeft of menselijk fouten.
Wat je doet met beveiliging is je maakt een concept past die toe op je test omgeving en als alles goed lijkt te gaan gooi je het live en huur je een hacker groep/beveiliging experts in om je concept te testen.
Het is nogal logisch om dit te doen en wordt al jaren toepast door bedrijven die werkelijk na denken over de veiligheid.
Bedrijven die dat laatste stap niet nemen zijn bezig met het fantaseren over het bonus die ze aan het eind van het jaar krijgen omdat ze gebakken lucht hebben kunnen verkopen.
Schijnveiligheid is een hele nare eigenschap.

[CodeCaster]

Want je kunt een hackersgroep niet inhuren om te opereren op een testomgeving natuurlijk.

[stefanass]

Zoals ik hierboven ook al zei, dan doe je dit dus niet op de site die je klanten gebruiken, maar op een clone-site die je gebruikt om dingen in je live-omgeving te testen.

[Accesteam]

Maar, phishing attacks worden toch meestal uitgevoerd door de HOST-file aan te passen en je naar een andere site door te sturen als je naar de website van ING gaat? En ik neem aan dat deze phishing sites niet dit script overnemen. Of is er daadwerkelijk malware wat de HTML in een website aanpast zodat de ingevulde gegevens naar een derde partij worden gestuurd?

[Patriot]

Als er opeens vreemde javascriptbestanden geladen worden dan moet je meer denken aan een server side hack. Het is wel mogelijk hoor, om malware te schrijven die de HTML die je ontvangt aanpast, maar het is voor zover ik weet niet erg gebruikelijk.

[Accesteam]

Klopt, maar als reactie op CodeCaster gingen we er al vanuit dat het scriptje van ING zelf was.

CodeCaster legt dus uit dat het gebruikt zou kunnen worden om te checken of het wel de echte ING website is die je bezoekt. Maar ik zet daar mijn vraagtekens bij omdat, zoals jij al zegt, je natuurlijk niet naar de échte website gaat als je het slachtoffer bent van een Phishing Attack/Malware. Dus dan kom je ook niet op de officiële website en wordt dus niet dit mysterieuze scriptje van de ING geladen.

[CodeCaster]

Precies, logisch is anders, want als malware je html kan aanpassen dan halen ze net zo makkelijk de url naar dat script eruit. Het blijft IMHO een vaag verhaal.

[Cruz]

Mwah, op zich klinkt het plausibel.

Een bank wil niet dat zijn primaire proces (van telebankieren) in gevaar wordt gebracht, dus een simpel stukje javascript-code toevoegen, wat alle fraude/phishing analyse extern uitvoert, is dan een logische maatregel. Je wil bijv geen software gaan draaien op de webserver want als er iets fout gaat ligt de ING website eruit en dansen de poppetjes.

[Mektheb]

Lekker is dat
Heb het op de been gevolgt maar ik krijg zo geen vertrouwen in me eigenbank.
Rabobank ziet er voor mij op het moment rooskleuriger uit !

[Yezpahr]

Geloof me, rabobank is niet veel beter.
Hun inlogsysteem is misschien fail-proof naar hun eigen zeggen, maar alleen het feit al dat mijn 8-cijferige code *altijd* met een 5 begint en de tweede digit altijd tussen de 2-6 liggen doen mij al vermoedens geven dat je met een paar duizend testcases en wat denk-en-potlood-werk de hashing al kunt klonen.

ABN Amro heeft een onveilige site, aangezien je ingelogd kunt zijn, naar een ander draadloos netwerk kunt overstappen en alsnog ingelogd blijven en je transacties maken.
Dit kan ook bij Rabobank, SNS, Postbank, noem maar op.
(Als je dus de gegevens kopieert die op de schijf staan en in het geheugen staan kun je op ELK IP-adres de transactie afmaken.)

Dus als je echt veilig met geld wilt omgaan moet je de staat aanklagen dat ze ons verplichten geld 'veilig' te zetten bij banken.

*edit*
On-topic trouwens ook nog wat te melden

De ING gebruikt dit hoogstwaarschijnlijk als test-case om te kijken hoe malware werkt. Daarmee bedoel ik dus dat dit een home-made malware is, die net zo werkt, zodat ze beveiliging kunnen ontwerpen. Als je letterlijk naar hun verklaring kijkt, is dit heel plausibel.
*edit4 inmiddels:

"We testen software die ons in staat stelt bepaalde vormen van fraude en phishing op te sporen"

[Reactie gewijzigd door Yezpahr op 23 juli 2024 23:32]

[jmzeeman]

ABN Amro heeft een onveilige site, aangezien je ingelogd kunt zijn, naar een ander draadloos netwerk kunt overstappen en alsnog ingelogd blijven en je transacties maken.
Dit kan ook bij Rabobank, SNS, Postbank, noem maar op.
(Als je dus de gegevens kopieert die op de schijf staan en in het geheugen staan kun je op ELK IP-adres de transactie afmaken.)

Dit kan bij de rabobank iig niet omdat je bij het verzenden van de transacties opnieuw je random reader moet gebruiken om een nieuwe code te genereren met afhankelijk van de hoogte van het totaal van de transacties: een code, het totaal bedrag en een doel rekeningnummer als input. In het ergste geval kan je als je mijn ingelogde sessie kaapt dus zien hoeveel geld ik op mijn rekening heb staan. Bij de andere banken heb ik geen ervaring maar ik neem aan dat ook die om een nieuwe code vragen bij het verzenden van een opdracht.

Hun inlogsysteem is misschien fail-proof naar hun eigen zeggen, maar alleen het feit al dat mijn 8-cijferige code *altijd* met een 5 begint en de tweede digit altijd tussen de 2-6 liggen doen mij al vermoedens geven dat je met een paar duizend testcases en wat denk-en-potlood-werk de hashing al kunt klonen.

De exacte details van het algoritme van de random reader ken ik ook niet maar ik kan je je wel met vrij grote zekerheid zeggen dat het op basis van de gegenereerde keys even met potlood en papier (of met super computer voor mijn part) uitwerken van een algoritme om de volgende OTP te berekenen je niet gaat lukken. Tenzij je bedoelt dat je even een inverse voor het hash algoritme gaat uitschrijven iets wat wiskundig gezien onmogelijk is (de inverse is wat anders als de het te snel optreden van collisions wat bijvoorbeeld MD5 kwetsbaar maakt). De Random reader gebruikt een OTP algoritme dat in ieder geval gebruik maakt van de tijd en een resultaat dat uit de chip van je bankpas komt na het geven van een correcte pin. Alleen als je al deze waardes weet kan je er een nieuw OTP uit genereren, en vanuit de gegenereerde codes kan je deze waarden alleen halen als je de (wiskundig gezien onmogelijke) inverse voor de hash functie hebt.

@pasnummer disussie hieronder:
Het toevoegen van het pasnummer maakt de kans dat je een code goed gokt een stuk kleiner bij rekeningen met meerdere passen. Bijvoorbeeld bij zakelijke rekeningen waar er een wat groter aantal passen in omloop is, is het zonder het pasnummer dus zo dat er meerdere codes goed zijn en dat de veiligheid een stuk kleiner wordt als bij rekeningen met één pas. Zelfs bij een standaard en/of rekening maak je het met het toevoegen van een pasnummer het al twee keer zo moeilijk om goed te gokken.

[Reactie gewijzigd door jmzeeman op 23 juli 2024 23:32]

[findftp]

Het zal allemaal wel waar wezen wat je zegt, maar leg mij dan eens uit waarom bij die superultiemgoede versleuteling onlangs opeens ook het pasnummer nodig was om in te loggen?
Geeft mij in ieder geval het gevoel dat ze toch nog iets over het hoofd gezien hadden.

[Gizmo_mokum]

Omdat je bij het skimmen de pincode en magneetstrip hebt, maar het pasnummer staat niet electronisch op de kaart, en is met skimmen niet te krijgen.

[findftp]

Aha, het enige juiste antwoord.
Dit klinkt wel erg plausibel.
Jammer dat ik niet hoger kan modden. Ach waarschijnlijk leest niemand dit comment toch nog na 10 dagen...

[bolluserectus]

Heeft met en/of rekeningen te maken.. Zo kan je je verschillende rekeningen zichtbaar of juist niet zichtbaar maken als je rekeningen koppelt met je partner.. Je hebt namelijk dezelfde bankrekeningnummer maar ander pasnummer..

[Foamy]

Voor die wijzigingen had ik ook al een en/of rekening. Guess what; ik krijg iets anders te zien na inloggen dan mijn partner ..

[MSalters]

Een andere hypothese is dat nieuwere passen iets andere chips hebben, en daarom een andere verificatiecode produceren. Met een en/of rekening zou je dan twee passen hebben en twee verschillende inlogcodes genereren; dankzij het pasnummer kan de Rabo die twee dan uit elkaar houden.

[Eli3l]

Bij de ABN-AMRO moet je ook bij het versturen van je opdracht nogmaals de random-reader gebruiken en dan een code invoeren en he bedrag en dan spuugt de random-reader een code uit die je op de site moet invullen. Dus een session hijack heeft daar ook geen nut

Ik gebruik internet bankieren pas een jaar of 6 en ik heb altijd (bij de Fortis en bij de ABN-AMRO) bij het versturen van de opdracht nogmaals een code moeten invoeren.

[CodeCaster]

[op iedere site waarbij] je ingelogd kunt zijn, [kun je] naar een ander draadloos netwerk overstappen en alsnog ingelogd blijven en je transacties maken.

Dat kan omdat je externe IP niet wijzigt. Of bedoel je een draadloos netwerk dat op een ander modem is aangesloten?

[Reactie gewijzigd door CodeCaster op 23 juli 2024 23:32]

[Chesta]

Hij bedoelt een ander modem, dus een ander WAN IP-adres.

Dit kan je beveiligen door het IP-adres aan de sessie te koppelen, dit voorkomt session-hijacking. Alleen sommige proxyservers wisselen soms van WAN-IP, daarom wordt dit over het algemeen niet gedaan.

[Sorcerer8472]

Wat eventueel zou kunnen is het koppelen aan een IP-range. Echter ook dit is voor sommige gebruikers lastig, bijv. bij het gebruiken van één interne proxy/router icm meerdere ISP's. Dan zou continu je verbinding verbroken worden in die situaties.

De mogelijkheid om aan IP te koppelen bij het inloggen (zoals bij Tweakers.net) zou evt. wel gegeven kunnen worden. Echter 95% van de gebruikers van banken zouden dat niet begrijpen.

[Yezpahr]

@CodeCaster
Ik bedoel natuurlijk het veranderen van het WAN-IP, door over te stappen naar een andere verbinding.
Ikzelf zit met een USB wifi stickje internet uit de buurt te plukken en wissel wel eens omdat draadloze routers wel eens het probleem hebben dat ze HTTP niet willen verwerken.

Hackers zullen misschien weinig kunnen met het kopieren van al die gegevens, want die gegevens omvatten de transactie die je al maakt.
Een andere transactie maken daar zou je pincode/pas voor nodig zijn.

Een groot beveiliging issue word het pas wanneer je systeem al door een hacker is overgenomen die een RAT weet te installeren.
Met zo'n tool kun je ongelooflijk veel dingen doen, zoals de cam/mic/muis/keyboard/monitor 'afluisteren' en zelfs input geven waar mogelijk.
En het proces staat niet in de lijst van processen of staat er in als een svchost vanaf de locatie "C:\windows\system32" (of ieder gewenste Naam+PadNaarImage)

Naja, zoals ik al zei, als we beveiliging zoeken moeten we de staat aanklagen voor het dwingen van het gebruik van gefaalde en inherent onveilige manieren van geldbezit/transport.

*edit: erg off-topic:*
Serieus, het HEBBEN van geld kost je al geld.
Want om geld te hebben moet je al een bankrekening hebben tegenwoordig, want geen enkele werkgever betaald nog contant.

[Reactie gewijzigd door Yezpahr op 23 juli 2024 23:32]

[bolluserectus]

"Echter ook dit is voor sommige gebruikers lastig, bijv. bij het gebruiken van één interne proxy/router icm meerdere ISP"
Als je dat thuis hebt, kan je ook makkelijk ffies je router configgen om bepaalde IP-adressen middels 1 WAN-IP te benaderen..

[Mentalist]

De mogelijkheid om aan IP te koppelen bij het inloggen (zoals bij Tweakers.net) zou evt. wel gegeven kunnen worden. Echter 95% van de gebruikers van banken zouden dat niet begrijpen.

Dit los je natuurlijk makkelijk op. Maak er een checkbox van die standaard aan staat en met een cookie onthouden kan worden. Eventueel zelfs standaard hidden en pas zichtbaar als je op een uitschuiflinkje drukt.

Hoeft niemand zich aan te storen. Levert het problemen op, dan is de checkbox zo uitgezet. (al dan niet m.b.v. de helpdesk)

Op Tweakers gebruik ik dit niet omdat ik hier lange sessies heb, maar een gemiddelde internetbankiersessie is <10 minuten. Daarvoor zou ik het dan ook graag inzetten.

Het verhaal van ING is wat mij betreft zo lek als een mandje. Iemand heeft ergens een fuckup mee gemaakt, of ze nu zijn gehackt of dat ze dingen testen op een productieomgeving. Maar als je het mij zou vragen is hier ècht iets niet pluis.

[Reactie gewijzigd door Mentalist op 23 juli 2024 23:32]

[Verwijderd]

Houden jullie ook rekening met mobiele apparaten (mensen die internetbankieren met hun telefoon/tablet)? Die wisselen regelmatig van ip adres tussen een sessie door dus het eenvoudig koppelen van de sessie aan het IP/IP range is in deze gevallen waarschijnlijk niet mogelijk.

Zoals heel vaak is beveiliging in strijd met de usability.

[Gamebytes]

Als het via een app zou gaan, dan zou je iig het internet bankieren aan een device-id kunnen hangen.

Alleen via internet zou je ook wel truukjes kunnen uithalen met de gegevens die de mobiele browser meegeeft en daarvan een aantal te hashen.

[EtHeO18]

Hoe verschilt een device-id van een session id in deze?

[hackerhater]

Een device-ID is doorsnee het serie-nummer van het apparaat en uniek

[IceBlackz]

Mwah, dat is een beetje hetzelfde idee als een MAC adres, wat dus ook gespoofed kan worden. Zeker met een niet al te sterke beveiliging ( ik weet niet hoe goed die van bv android is) kunnen ze deze vast wel achterhalen met wat moeite.

[Bonez0r]

Als het echt een test was, waarom hebben ze het dan niet van tevoren even aangekondigd? Dan hadden ze niet achteraf de schijn tegen zich gehad, wat dus nu wel het geval is.

Ik geloof zelf geen donder van dat hele test verhaal. Stel dat er wel een echte hack is geweest, als dat bekend werd zouden klanten massaal naar een andere bank kunnen overstappen. Om dat te voorkomen zou de ING heel wat middelen inzetten en ik denk niet dat ze op een leugentje meer of minder zouden kijken.

[Reactie gewijzigd door Bonez0r op 23 juli 2024 23:32]

[Shamalamadindon]

Vertrouw jij nog email die "ogenschijnlijk" van je bank af komt?

[TD-er]

Ja tuurlijk, van de week nog weer een mail gehad van het 'ABN-AMRO klantpanelonderzoek'
Ziet er harstikke legitiem uit

_{en ja dat is ook weer een phishing-mail, bevestigd door de ABN-AMRO zelf.}

[HeepH]

Wat apart dat je dat zegt! Ik ben geen beveiligings expert, maar heb wel een goed gevoel voor cijfers, en kreeg ook het gevoel dat mijn codes voorspel werden, en altijd in een bepaald soort tantrum vielen. Bijvoorbeeld (fictieve codes)

8525 3243
9636 4242

van die cijfers die lekker klinken, en vaak inderdaad ook nog eens met dezelfde getallen begonnen of dezelfde cyclus volgde...

[still_the_same]

Dat ligt niet aan het algoritme, maar aan het menselijk brein die heel goed is mooie verbanden te ontdekken.

[tweaktubbie]

Precies, net zoals je ergens ver weg in het buitenland op vakantie toch zo 'vaak' een bekende tegenkomt. Je herinnert je alleen die bekenden, terwijl je miljoenen anderen tegenkomt.

[chielsen]

Plus iedereen gaat naar dezelfde trekpleisters

[Essence]

> ABN Amro heeft een onveilige site, aangezien je ingelogd kunt zijn, naar een ander
> draadloos netwerk kunt overstappen en alsnog ingelogd blijven en je transacties maken.
> Dit kan ook bij Rabobank, SNS, Postbank, noem maar op. (Als je dus de gegevens
> kopieert die op de schijf staan en in het geheugen staan kun je op ELK IP-adres de transactie afmaken.)

Het zou niet best zijn als je niet op een ander IP adres zou kunnen doorsurfen en ingelogd blijven. Je IP kan soms tijdens een sessie veranderen: proxyservers kunnen wat dat betreft doen wat ze willen. Als een aanvaller bij de fysieke PC kan, is alles sowieso verloren!

[BèR]

Nou, zó vaak verandert een client echt niet van IP tijdens een sessie, zeker niet op een thuisaansluiting. Dan heb ik liever dat ik onterecht uitgelogd ben omdat de verbinding niet vertrouwd wordt eerlijk gezegd Nette foutmelding en klaar
Als je dan toch je eigen internetbankieren doet op je werk waar je bijv op een wereldwijd geloadbalancede internetlijn zit, tja, dan neem je dat risico.

[Joost344]

Dat dacht ik dus eerst ook, maar mijn eerste cijfer is laatste een cijfer hoger geweest geworden. Dat vond ik wel apart.

[gfgw]

mijn eerste cijfer is laatste een cijfer hoger geweest geworden

Dat vind ik pas apart. Wat bedoel je met deze reeks woorden (want een zin kan ik het niet noemen)?

[daft_dutch]

ABN Amro heeft een onveilige site, aangezien je ingelogd kunt zijn, naar een ander draadloos netwerk kunt overstappen en alsnog ingelogd blijven en je transacties maken.

Alleen het stelen van een sessie is nutteloos. Ik ben bij dat ze zich richten op echte security en IP adressen buiten beschouwing laten.
En als je op IP vastbind en het eerste IP wat hoi zegt als legitiem beschouwt. doe je dat met of zonder x-forwarded-for? en indien ja gebruik je dan een whitelist of heb je blacklists.

[Reactie gewijzigd door daft_dutch op 23 juli 2024 23:32]

[LemonC200]

Leuke bronnen gebruik jij toevallig gebruikt mijn rabobank niet dezelfde eerste twee cijfers die jij noet hoewel het vaak met een bepaald cijfer begint en dan nog is 10 tot de macht 6 nog altijd 1 miljoen en over dat tweede punt dan moet je wel al die data hebben binnen 15 min want anders verloopt je sessie.

[Bartjezz]

Dan moet je niet via internet bankieren, probleem opgelost. Dan moet je voortaan alles via acceptgiro's doen en handtekeningen zetten, geen probleem...

[Zoop]

Zolang dat mogelijk blijft ...

[Verwijderd]

Ik wens je succes nog iets met mijn sessie id te kunnen doen na 5 minuten inactiviteit op de website van Rabobank.

[defixje]

Die code die je terug krijg is een soort timestamp met een scramble van nog meer variablen erbij zoals nummers van je pasnummer en je rekeningnummer.

Vraag met je rabo-identifier maar is snel een inlogcode op. Loopt altijd op en is gelijk aan het aantal secondes tussen je aanvragen (op je rabo-identifier).

Zo kan de bank verifiëren of je bijvoorbeeld wel de code binnen 5 min. heb ingevuld waardoor hij een error geeft als het langer is dan 5 min.

[Verwijderd]

"Vraag met je rabo-identifier maar EENS snel een inlogcode op."

[Cubic X]

Niet handig om zo'n domein te gebruiken en ook nog gehost is in de VS, dit wekt argwaan.

Gelukkig is er verder niks aan de hand

[TimMer]

Dat vraag ik mij toch ten zeerste af, zeker als klant van ING.

Dat ING zegt dat dit een test was bewijst nog niet dat het daadwerkelijk een test was; ING heeft er namelijk alle belang bij om een eventuele infectie uit de media te houden. Naar alle waarschijnlijkheid irriteert het ze al dat bovenstaand verhaal in de media terecht is gekomen...

[scsirob]

Was het niet zo dat Amerikaanse sites verplicht konden worden om hun data aan de Amerikaanse overheid en inlichtingendiensten aan te leveren? Als dit script jouw bankgegevens omleidde via die Amerikaanse site dan kunnen ze dus nu daar 'onderzocht' worden.

[Verwijderd]

In Nederland kunnen banken ook verplicht worden om gegevens af te staan aan overheidsdiensten. Het moet echter wel via de rechter, dat zal in de VS wel wat 'gemakkelijker' gaan dan hier.

[Accesteam]

Lijkt me niet dat ze zoiets verzwijgen en vervolgens het ook doodleuk erop laten staan. Zeker omdat andere banken hier ook mee aan lijken te werken.

Dat het een 'beveiligingstest' is lijkt me ook stug. Zal wel wat anders aan de hand zijn wat ze niet willen publiceren.

offtopic:
Een projectje van de FBI/AIVD/CIA/Interpol anyone?

[Xubby]

Gelukkig is er verder niks aan de hand

Er lijkt niks aan de hand te zijn:
http://gathering.tweakers...message/36518816#36518816

Waar staat dat het onderdeel is van een beveiligingstest van de ING.
Dat is wel mooi dat ze dat doen. Misschien niet zo handig eventueel "overbodige" zaken op mijn.ing achter te laten.

[apokalypse]

Wel een erg verdachte test dan, zoals meerdere met mij eens zijn:

Brons schreef op donderdag 04 augustus 2011 @ 18:11
Aparte manier om je beveiliging te testen. Het is blijkbaar zo geheim dat het bedrijf dat het doet anoniem moet blijven in de whois gegevens en op een kleinschalige VPS host moet draaien?

forumlink

fonsoy schreef op donderdag 04 augustus 2011 @ 18:14
[...]

Het is dan ook mij niet helemaal duidelijk of de indruk die ING probeert te wekken juist is. Een mogelijke hack in de inlogsystemen kost natuurlijk enorm veel geld aan imagoschade. Het kan zijn dat er op het moment hard gewerkt wordt om een veilige versie weer te plaatsen.

Dit zijn natuurlijk speculaties, maar het is op z'n zachtst gezegd vreemd. De ING had van tevoren kunnen zien dat mensen vragen gingen stellen bij het laden van dergelijke domeinnamen. De actie is dan niet goed doordacht.

forumlink

ik222 schreef op donderdag 04 augustus 2011 @ 18:17:
Die verklaring rammelt inderdaad op twee niet onbelangrijke punten:

- Er wordt gebruik gemaakt van vage domeinen in de US die pas kort geleden geregistreerd zijn
- Het draait op de productieomgeving, je zou verwachten dat ze testen in een testomgeving. Zeker wanneer het om dit soort dingen gaat die imagoschade op kunnen leveren.

Zoals ik zeg ik hoop dat het de waarheid is maar ik blijf het een beetje raar vinden...

forumlink

samsam538 schreef op donderdag 04 augustus 2011 @ 18:23:
Toen ik net http://www.ing.nl/ bezocht, leidt mijn Chrome-extensie van McAfee mij naar siteadvisor.com die mij nu waarschuwt voor een mogelijke phisingsite.

forumlink

Testen doe je niet op productie omgevingen, en vage domeinen en bankzaken lijkt mij ook een rare combinatie.

Ook vraag ik me af of zulk soort check wel in de client moeten en dat ze niet server-side opgelost moeten worden.

In ieder geval wat het ook is, het is enorm slordig. Hier heb ik dus mijn geld aan vertrouwd, 'goed' gevoel geeft dat.

[Reactie gewijzigd door apokalypse op 23 juli 2024 23:32]

[TDeK]

Precies, ik heb er al een hekel aan als deze inlogpagina's voorzien zijn van (vaak Amerikaanse) tracker scripts, laat staan scripts die actief je sessie loggen (!!). Juist een inlogpagina moet zo min mogelijk externe content bevatten. Stel dat dier externe partij wordt gehacked, dan zouden criminelen openstaande sessies over kunnen nemen (in het ergste geval).

[Xubby]

Ik ben het met mensen eens dat "productie" geen geweldige plek is om de beveiliging te testen. Maar de alternatieve theorie is toch dat de website van ING is gehackt en "derden" er code hebben geplaatst? En ING het er vervolgens laat staan nadat ze er op attent zijn gemaakt? Dit lijkt me moeilijk te geloven.

Hoewel het mij ook vreemd overkwam, ga ik dan toch voor de theorie dat het de beveiliging testen op productie is, i.p.v. op (of ook na?) de test omgeving.
http://gathering.tweakers...message/36518816#36518816

[defixje]

uhhhh wat dacht je van helemaal niet handig om in een live omgeving te testen?

Je kan toch een complete testomgeving maken met in je host-file mijn.ing.nl (als je zo nodig wilt testen wat er gebeurd met mijn.ing.nl.

In vind het maar verdacht.

[Ed_Capone]

Kan natuurlijk zijn dat dit al geruime tijd getest is in een testopstelling, uiteindelijk zal het ook in een live omgeving getest en geimplementeerd moeten worden.
Ik zeg niet dat het daadwerkelijk ook zo is, de waarheid kom je toch nooit te weten.

[_sTIMpie_]

zeggen ze bij ING.....

[DaanozZ]

dat hoop ik ook ja, dat er niks aan de hand is
Beetje rare manier van "testen". zo wek je weinig vertrouwen.

[Reactie gewijzigd door DaanozZ op 23 juli 2024 23:32]

[Verwijderd]

Dat is inderdaad wat ze zeggen ja.
Vind het behoorlijk vreemd dat dit de daadwerkelijke productie omgeving wordt getest.
Klanten met enige kennis van zaken zullen zich hier niet prettig bij voelen.

[Martijn13]

Het script is zojuist spontaan van de pagina verdwenen.

[Puch-Maxi]

Niet spontaan, maar geheel volgens de planning.
http://twitter.com/#!/INGnl_webcare/status/99479386549522432

[Brons]

Ik vind het maar bizar. De domeinnamen hebben anonieme whois gegevens en staan gehost bij een shared hosting bedrijf. Noem mij gek maar dit doe je toch niet in de productieomgeving van een bank? Hoe dan ook is de beveilingafdeling van de ING incompetent.

[polopolo150]

Maar het valt wel zo min mogelijk op voor hackers of kapers. Misschien doen ze dit om een zo realistisch mogelijk omgeving te maken om ING hack-proof te maken. Of een klein budget wat de medewerker binnen ING mag gebruiken, dat kan ook.

[jjkewl]

Beetje vreemd inderdaad, meeste RL tests doe je op een schaduw omgeving, dat een kopie van de live (of test) omgeving is en middels clustering dezelfde requests krijgt te verwerken als de live server maar dan dus op de achtergrond. Resultaat van de schaduw server wordt steekproefgewijs vergeleken met die van de live omgeving om de juiste werking te valideren.

Als er überhaupt test code in de live omgeving gedraaid moet worden dan wordt deze code alleen geinclude bij bezoeken uit een bepaalde private IP range. Daarmee kan je tests draaien op een live omgeving zonder iemand tot last te zijn (zolang de tests de live omgeving niet plat leggen)

[humbug]

Natuurlijk doe je de meeste testen in een testomgeving. Echter, de mensen die productie systemen beheren hebben meestal weinig met die testen te maken. Om de daadwerkelijke reactie in een productieomgeving te testen zul je ook testen moeten doen op die productieomgeving.

Je kan niet blind vertrouwen op het feit dat iets goed gaat in een testomgeving. Wel is het slordig te noemen dat dit ook onrust bij klanten veroorzaakt.

[stefanass]

Dan nog was het niet nodig geweest om dit op de site van de productie-omgeving te doen die alle klanten gebruiken. Dat zou je bv. ook op een site kunnen doen die speciaal voor die testdoeleinden is opgezet, die verder identiek is aan de site die je klanten gebruiken.

[MichielioZ]

Persoonlijk geloof ik het verhaal van ING niet.
Een "publieke test" gaat, zeker als het om zoiets gevoeligs als een bank gaat, vooraf aan eindeloze testen in een gesloten testomgeving (zoals ook hierboven al gezegd wordt).
Als een test dan eindelijk goed genoeg wordt bevonden voor een "publieke test", dan ga je toch niet zulke dubieuze domeinen gebruiken ?

[_ferry_]

Zo dacht ik ook. Ze kunnen immers net zo makkelijk even beta.ing.nl ofzo maken waarop ze vrolijk nieuwe dingen kunnen testen zonder dat normale gebruikers daar iets van hoeven te merken. En waarom zou je een script langere tijd moeten laten werken? Als je weet dat het wel of niet werkt, dan heb je het resultaat en ben je klaar toch?

Nouja, het zijn alleen maar theorieën. Of ING ook daadwerkelijk de waarheid spreekt, dat weten ze alleen daar.

[gnu]

Het probleem van zomaar even een andere subdomein aanmaken is dat je certificaat ook anders zal zijn, waardoor requests weer net iets anders zullen lopen. Daarom is het best waarschijnlijk dat ze het dan ook even in de live omgeving moeten testen met "onschuldige" code, zodat ze weten dat het ook werkt.

[Gizmo_mokum]

Alternatief is je site even dicht zetten voor al het publiek, en alleen de testers binnenlaten. Kun je later aangeven dat er een storing was. Nu heeft de bank een erg slecht verhaal. Wat als er straks klanten zijn die een echte hack voor een nieuwe test aanzien. Gaat ing die klanten dan schadeloos stellen of zeggen ze " u had kunnen zien dat er iets vreemds aan de hand was, u heeft onvoorzichtig gehandeld"

[Durandal]

Inderdaad. Als er bij een bank werkelijk iets aan de hand is zijn ze wel de laatste die het zullen toegeven. Poging tot beperken van imago schade, aangezien dat het bestaan van een bank raakt.

Ergo, vertrouw ze niet op hun mooie ogen.

[Henk007]

Een andere theorie die op het forum wordt voorgesteld is dat die vage VPS een honingpot is.

[Ghostface9000]

Wat word er bedoeld met een honingpot ?...

[darkfader]

Aanvallers uitlokken en hun IP adressen bijhouden/traceren.
Maar dat lijkt me sterk eerlijk gezegt.

[CAPSLOCK2000]

Met een pot honing van je wespen voordat ze jou kunnen steken.

Het idee is dat je computer hebt die je op een of andere manier aantrekkelijk maakt voor krakers, bijvoorbeeld door (opzettelijk) een gat in de beveiliging te maken. Als de machine dan gekraakt wordt kun je met de krakers meekijken om er zo van te leren.

De kunst is het om zo'n machine zo in te richten dat het op een echte productie-machine lijkt zonder dat een kraker schade kan aanrichten.

[findftp]

Haha, nou, dan zijn die medetweakers hierboven dan meteen verdacht.
Ik las al dat er een paar die server hebben gescand op exploits, dan maak je je dus meteen verdacht.

[robbinonline]

Wat ik eigenlijk nog erger vindt is dat het wachtwoord dat je gebruikt voor mijn ING niet hoofdletter gevoelig is.

[jp]

Maar je inlognaam is dan weer wel hoofdlettergevoelig

[Game_overrr]

Wachtwoord bij mij ook hoor

[JorritJ]

Ik mag er dus vanaf nu vanuit gaan dat als er een script van een externe site wordt ingeladen op de inlogpagina van mijn.ing.nl dit de bedoeling van de ING is? Ik vind dit nogal een enge gedachte.

[Verwijderd]

En wat betreft die externe site

TeGek schreef op donderdag 04 augustus 2011 @ 19:01
net toch voor alle zekerheid een test scan gedaan met Metasploit, 12 exploits possible on 178.79.150.4.

lekker veilige VPS dus, outdated software waar 1 van de exploits zelfs een remote file inclusion is ,scriptje is dus mogelijk door een beetje slimme jongen zo te vervangen voor iets dat ECHTE schade kan aanrichten...

Ach,als ze zeggen dat het tijdelijk is dan is er toch weinig gevaar dat de VPSen gehackt worden.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 23:32]

[defixje]

haha jij publiceer wat ik stiekem al gedaan had :x

[Robtimus]

Ik denk niet dat de ING een dergelijke hack nog steeds online zou laten staan als zij hier geen weet van zouden hebben. Als gegevens van klanten gestolen / misbruikt worden hebben ze hier zelf nadeel bij. Als dit dus niet door de ING zelf geinitieerd zou zijn dan was de site waarschijnlijk offline gehaald zijn, of op zijn minst opgeschoond met een recente backup.

[Verwijderd]

Dit dus. Als het daadwerkelijk een hack is, laten ze het niet op de website staan (ja, de code wordt nog steeds geladen). Of ze willen zover gaan om de hack uit de media te houden door zo net te doen alsof er niks aan de hand is, maar dat gaat mij weer een stapje te ver.

Conclusie: Het is wel degelijk door ING zelf opgezet.