Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Tien banken hadden xss-kwetsbaarheid - update

Een beveiligingsonderzoeker heeft in websites van tien banken, waaronder ING, de Rabobank en ABN Amro, een xss-kwetsbaarheid gevonden. Daardoor konden kwaadwillenden eigen formulieren in de websites van de banken injecteren. Het probleem is inmiddels opgelost.

Naast ING, de Rabobank en ABN Amro hadden ook de websites van Binck, Alex, ASN, Knab, SNS, Triodos en de Belgische Van Lanschot-site last van het cross site scripting-probleem, zegt onderzoeker Wouter van Dongen van DongIT tegenover Nu.nl. "Die zaten voor het overgrote deel in Flash-bestanden", zegt hij tegenover Tweakers.

De xss-kwetsbaarheden bevonden zich in de voorpagina's van de bankensites. Een aanvaller had het probleem kunnen misbruiken door eigen code te injecteren in de website, maar hij moest zijn potentiële slachtoffers er dan wel toe verleiden om op zijn link te klikken. De techniek zou onder meer kunnen worden gebruikt in phishing-mails. Gebruikers worden vaak opgeroepen om de url van de site te controleren. Die zou dan kloppen, terwijl de aanvaller zijn eigen code kan injecteren.

Van Dongen heeft een proof of concept gemaakt waarbij de html-elementen op de bankensites beginnen te schudden. "Ik heb expres geen eigen formulieren op de bankensites gezet", aldus Van Dongen. Inmiddels hebben de banken het beveiligingsprobleem opgelost.

Woordvoerder Ronald van Buuren van ING bevestigt de bevindingen van Van Dongen. "We zijn in november benaderd, en daarna is het beveiligingsprobleem vrij snel opgelost", aldus Van Buuren. Hoe snel het probleem is opgelost, is niet bekend. Van Buuren zegt blij te zijn met hulp van onderzoekers als Van Dongen. Ook woordvoerder Margo van Wijgerden van de Rabobank bevestigt het lek. Volgens haar ging het om een relatief klein probleem.

Update, 20:57: Reactie Rabobank toegevoegd.

Door Joost Schellevis

Redacteur

12-01-2015 • 16:08

65 Linkedin Google+

Reacties (65)

Wijzig sortering
Dit is nou een voorbeeld van hoe het wel moet. White-hat hacker doet bevinding, meldt dit netjes. Het probleem wordt opgelost, en zodra het probleem is opgelost stapt de onderzoeker naar de media. Geen aangiftes en toch weer een veiligere wereld.
Let wel, hier is er met (zeg iets in de trant van) 45 dagen iets aan gedaan, bij de lek in Windows duurde het meer dan 90 dagen, geloof maar dat deze beveiligings-onderzoeker na 90 dagen ook publiek was gegaan, dat is heel normaal.

Dat Microsoft zicht nu gedraagt als "geslagen hond" betekend niet dat ze gelijk hebben.
Maar laten we die discussie lekker in het betreffende artikel voeren ;)
Datzelfde google laat oude android gebruikers qua veiligheid nu barsten, oude android versie en browser, zoek het maar uit. Wat zegt dat over google.

45, 90 dagen het gaat er om hoe je er mee omgaat. De ene vindt 90 dagen genoeg de ander 30. Het hangt allemaal samen de de aart van de bug, hoe kritsich is deze hoe snel op te lossen, wat voor extra problemen kan een patch geven.

In dit geval is het netjes gedaan zoals het hoort.
Oude versie van Windows/IE zoek het maar uit, wat zegt dat over Microsoft?

Het is ook een drukmiddel om mensen te doen overstappen naar iets nieuwers en dus te consumeren.
Dat doen heel veel bedrijven, en soms zijn de motivatie's misschien minder netjes maar het werkt vaak wel.
oudere versies, 10 jaar oud tegen 2 jaar oud google.
Denk dat je heel goed weet dat MS heel lang ondersteuning geeft engoogle tja 2 jar spreekt voor zich
Uit persoonlijke ervaring kan ik zeggen dat een 'belofte om het te fixen' bij lange na geen garantie is dat er ook daadwerkelijk een patch volgt. Het is dan ook geheel redelijk om 90 dagen als harde deadline te hanteren; ik vind het persoonlijk zelfs nog wat te ruim.
Let op: Microsoft vroeg Google om 2 dagen uitstel, maar ze bedoelde hierbij 2 weken. Dat is best een flinke fout.

Overigens, als er schade zou ontstaan, is dit de schuld van diegene die het lek misbruikt, en daarna Microsoft. Google is niet verantwoordelijk voor het lek. Iedereen met kennis van dit lek had het meteen kunnen publiceren.
voor zover bekent is het toch een zero day lek?
Dat zegt niets over het al dan niet gebruikt zijn van het lek, enkel over de status van publicatie (al dan niet bedoeld).
Dat gebeurde vroeger ook. Het probleem is alleen dat bugfixes eerst goed getest moeten worden op een bedrijfssysteem om te controleren of geen programma's niet omvallen. Omdat dit veel tijd kost, werden bugfixes opgespaard om een hoeveelheid in één keer te testen. Dit is op zich geen probleem, behalve dat de bugfix ook een publieke bekendmaking is van de kwetsbaarheid en derhalve zal deze vlak daarna ook (vaker) misbruikt gaan worden. Via patch tuesday wordt een goede balans gezocht tussen theoretische veiligheid en de praktijk. 0-days die al misbruikt worden, worden nog steeds zo snel mogelijk out-of-band uitgebracht.
Ik vind het filmpje niet echt duidelijk het probleem in beeld brengen. Er bestaan algemene harlemshake-scriptlets die je als URL/bookmark kan invoeren die de elementen laten bewegen op de maat van de muziek. Is er ook wat meer bekend over de werkwijze hoe hij deze hack uitvoert?

Als de werking van de hack meer iets meer uit de doeken werdt gedaan, tot op zeker hoogte, dan zouden anderen ook zich tegen deze hack kunnen wapenen. Denk eens aan webwinkels of andere sites met transactiemogelijkheden.

[Reactie gewijzigd door AW_Bos op 12 januari 2015 16:24]

Van de eerste drie banken kan je de URL nog vaag zien in het filmpje. Voor wat betreft Knab.nl #2 was JW Player de oorzaak, en Rabobank #3 had blijkbaar nog ergens AnyChart.swf staan in hun CSS folder. Van beide zijn er XSS exploits bekend in oudere versies.

Waar het dus op neer komt is dat je altijd op je hoede moet zijn bij het gebruik en / of installatie van 3rd party tools op je website. Up to date houden is één zaak, volledig verwijderen van je website zelfs als ze niet actief in gebruik zijn is ander. ;)

[Reactie gewijzigd door Ravefiend op 12 januari 2015 17:31]

heb het maar even opgezocht: ING Woordvoerder Ronald van Buuren
Hadden de andere banken nog wat te melden?

[Reactie gewijzigd door Peter R op 12 januari 2015 16:15]

Kennelijk niet O-)

Overigens wil dat niet zeggen dat andere banken stil zitten. Zo was ABN-AMRO bijvoorbeeld vatbaar voor de TLS variant van POODLE. Op 9 december was er een fix klaar, maar pas begin januari had ABN-AMRO die fix uitgerold. Geen sneer, want juist het uitrollen en testen van zo'n fix duurt erg lang en dan waren er ook nog de feestdagen.

Dus men werkt gewoon vaak ook in stilte aan problemen die niet in de media komen.
Hmmm, ING had 'TLS Poodle' anders binnen 24 uur opgelost. En die XSS was bij de meeste banken in een 'promotioneel' onderdeel; niet het internet-bankieren gedeelte.

Maar goed, daar de ABN-AMRO tot 2.5x zo duur is als de goedkoopste NL bank (voor 'particulier internetbankieren'), ben ik daar als klant best wel verbolgen over ... de goedkopere concurrentie kan het blijkbaar beter :(
ING zit achter Akamai, ABN-AMRO heeft eigen load balancers dus ik denk dat het daar in zat. Maw ING was waarschijnlijk nooit kwetsbaar voor POODLE TLS anders dan hun caching servers. Bij ABN-AMRO waren de eigen servers kwetsbaar.

Grote banken zoals Bank of America en Chase hebben het ook pas begin januari gefixt. Waarschijnlijk was toen bepaalde USA certifciatie pas klaar.
Jawel; het ging bij ING om Mijn ING (die staat niet achter Akamai lijkt het), niet om www.ing.nl. Blijkbaar was ING wel in staat om haar eigen servers/loadbalancers te patchen. Certificering staat daar helemaal los van lijkt me, juist ING doet wel zaken in USA en Canada, waar ABN-AMRO dat volgens mij (stukken) minder / niet doet ...

[Reactie gewijzigd door SKiLLa op 12 januari 2015 23:15]

Ik kan mij zo voorstellen, dat als je het toen al opgelost had, je het niet direct wilde melden, omdat je collega's wellicht nog wel kwetsbaar zijn. Pas als alle banken het opgelost hebben, is het aan een bank/de banken om het te melden. De enige bank waarvoor dit 'probleem' actueel is en die het tegelijkertijd mag melden, is dan de hekkensluiter.
Dank voor de extra info, ik vroeg me al af welke woordvoerder de moeite had gedaan te antwoorden. Pluspuntje voor de ING dus, netjes dat ze hier goed en (op aanvraag) openlijk mee omgaan.
"Die zaten voor het overgrote deel in Flash-bestanden", zegt hij tegenover Tweakers.
Eigenlijk weer een argument waarom Flash z.s.m. uitgebannen moet worden.
Toevallig heeft dit artikel ook een Flash element (de video), waarom is dat geen HTML5?
Het is embedded YouTube, ik denk dat je dan daar HTML5 moet inschakelen. Hier heb ik geeneens flash aanstaan en de video speelt gewoon af.
Ik heb de youtube HMTL5 player anders, die heeft inderdaad een flash fall back.
Werkt dit trouwens nog wel bij de Rabobank? Al enige tijd moet ik het bedrag voor de komma invoeren in de random reader. Als ik dus een code genereer voor een CD van 20 euro en moet opeens 5000 invullen als tweede controle getal dan moet dat doorgaans een belletje doen rinkelen.

Maar goed, dit zal net zo goed bij de kleine minderheid er door heen glippen..
Ja, ze zouden dan het rekeningnummer kunnen wijzigen, terwijl hij op jouw scherm netjes het rekeningnummer weergeeft van diegene waarvan je de CD koopt.
Athans, dat verwacht ik dat ze ermee kunnen, uit het verhaal is het niet geheel op te maken. Wel tricky dat de browser gewoon aangeeft dat se site veilig/echt is.
De vraag is of deze kwetsbaarheid ook daadwerkelijk direct van invloed was op het gedeelte van de sites waar je transacties uitvoert. Het artikel heeft het over de voorpagina van de sites. Dan denk ik eerder dat je hoogstens richting vissen naar inlog codes moet denken door een fake inlogformulier in een pagina te smokkelen. Nog steeds erg link natuurlijk.
Het wijst op een structureel probleem.
De meeste XSS-problemen kun je voorkomen door de juiste programmeertools te gebruiken. Sterker nog, het is haast niet te doen om een moderne, veilige website helemaal met de hand te schrijven. Er kan zo ontzettend veel mis gaan dat je wel gespecialiseerde tools moet gebruiken.

Als je dit soort gaten in je front-page hebt dan heb je niet de juiste tools gebruikt en zitten er waarschijnlijk ook vergelijkbare fouten in andere pagina's.
Voor zover ik begreep waren het hier juist externe tools/plug-ins waar de kwetsbaarheden in zaten, doordat die niet up to date waren. Ik kan me zo voorstellen dat er voor de daadwerkelijke bankierpaginas strengere interne eisen en controles gelden en daar niet van dergelijke externe componenten worden gebruikt.

Hoe dan ook een kwalijk verhaal.
Maar dan nog, als ik lees dat het probleem bij de Rabobank in AnyChart.swf zat, en ik me bedenk dat, als ik bij de Rabo inlog er grafiekjes van mijn in- en uitgaven gegenereerd wordt, dan kan ik me voorstellen dat hier mogelijk een verband tussen zit, en daarmee het dus mogelijk is geweest ook binnen het gedeelte waar transacties worden uitgevoerd code te te injecteren.
Tsja wat verwacht je van een browser dan he?
Ik bedoel de webserver zal gewoon nog het ingestelde certificaat blijven leveren. De content komt van de "echte" webserver van de bank en vervolgens word er met XSS andere zooi geïnjecteerd.

Een browser kan moeilijk snapshots gaan nemen van HTML van elke mogelijke website ofzo en dat vergelijken met wat een gebruiker binnen trekt. Of eigenlijk niet binnen trekt, want dat is in dit geval correct, maar wat er uiteindelijk allemaal met de DOM gebeurt.
Dit kan je de browsers niet kwalijk nemen en zullen hier ook nooit je voor tegen beveiligen. Dat is aan de programmeurs van de site in kwestie, browsers doen al erg veel om slordigheidjes van die programmeurs aan te pakken.

[Reactie gewijzigd door jozuf op 12 januari 2015 16:49]

correctie: "zeer slordig van de tct-afdeling" Of de persoon in kwestie. Het komt maar al te vaak voor dat de ICT-man het afraffelt, en wel 5000¤ in de maand verdiend met zijn onkunde en of blufpokeralwetendheid.
Het zijn er dan wel een heleboel. Ik neem aan dat dezelfde man niet werkt voor alle genoemde getroffen partijen ;)
Hm interessante vraag!

Ik neem het niet zomaar 'aan' dat dat 'niet' zo is, het kan natuurlijk zo zijn dat ze de zelfde 'school' hebben, of er is idd 1 bedrijf die het overgrote deel van de ict bij banken faciliteert . (er zijn voorbeelden van nog stommer(e) acties dan deze die ik nu noem)

[Reactie gewijzigd door Mel33 op 12 januari 2015 16:58]

Ik vind het eerder slordig van de banken. Zij hebben zelf ict personeel in dienst. Je mag van de banken verwachten dat ze de verantwoordelijkheid nemen om hun personeel goed trainen op het gebied van security. En stel dat een externe partij deze steek heeft laten vallen, dan nog is de bank verantwoordelijk. Het lijkt mij logisch dat je dit soort software tot in detail moet testen.
Wederom zeer slordig van de banken!
Het blijft mensenwerk en mensen maken nu eenmaal fouten. Niet wenselijk, maar wel de realiteit.

Gelukkig is deze fout nu opgelost en kunnen we door naar het volgende probleem....
Dat het een veel voorkomende fout is (XSS staat inderdaad hoog in de OWASP top 10) wil niet zeggen dat het daarom een makkelijk te voorkomen fout is. Integendeel. Zelfs wanneer je rekening houdt met security tijdens de ontwikkeling en een pentest uit laat voeren kunnen dit soort fouten erin blijven zitten.

Dus als jij een goede suggestie hebt om dit soort problemen te voorkomen hoor ik het graag van je :)
Dit is niet zo slordig, fouten maken zijn menselijk er snel op springen en de ontdekker danken, dat is hoe het moet.
Het viel mij op dat je op de publieke terminals van de Rabobank kan je elke willekeurige website kan bezoeken. Ik durf die dingen niet te gebruiken, wie garandeert dat de virus-scanner op die computers up to date is?

De mevrouw achter de balie vertelde mij dat ze alles heel goed in de gaten hield, en dat als er iemand 'verdacht' lang bezig was dat ze polshoogte ging nemen. Weinig besef van security.
Ik moest onwillekeurig toch even gniffelen bij de bedrijfsnaam; ik dacht die levert normaal aan xhamster ofzo.

Enfin, goed werk en op een heel nette manier opgelost :)
Het toont wel weer aan dat je goed moet oppassen met banken. De laatste tijd ontstaat er toch weer het idee dat banken de veiligheid op orde hebben omdat ze iedereen aan het waarschuwen zijn over zaken als phising, maar zelf hebben ze de zaken ook lang niet altijd op orde; en het zijn altijd de basis dingetjes (zoals een XSS) waar ze niet zo goed op letten... Beginnersfout, eigenlijk. De kleine en basale fouten zijn juist degene die mogelijk de zwaarste impact hebben.
Ook in de apps kunnen nog wel eens beveiligingsproblemen zitten.

Met andere woorden: blijf altijd op je hoede, en vertrouw ook de sites van de banken gewoon niet.
Wel zijn er plugins beschikbaar om je wat extra veiligheid te geven... Maarja, dan moet je de devs daarvan weer vertrouwen. ;) You're never safe! :P
Hij krijgt er zeker wat voor terug, naamsbekendheid, mogelijke klanten, 15 minutes of internet fame...
Altijd dat gedoe dat een beloning een soort verplichting is teegnwoordig...
Een beetje beveiligingsexpert kan prima anoniem een kwetsbaarheid bij banken verkopen voor een bovenmodaal bruto maand salaris. Dat is het punt niet.

Het punt is dat banken dit eigenlijk zelf hadden moeten checken!

Op dit item kan niet meer gereageerd worden.


Apple iPhone XS Red Dead Redemption 2 LG W7 Google Pixel 3 XL OnePlus 6T (6GB ram) FIFA 19 Samsung Galaxy S10 Google Pixel 3

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank en Intermediair de Persgroep Online Services B.V.
Alle rechten voorbehouden © 1998 - 2018 Hosting door True