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

Door , , 58 reacties
Submitter: Pjotr

Beveiligingsonderzoeker Wouter van Dongen heeft opnieuw onderzoek uitgevoerd naar de beveiliging van websites van Nederlandse banken. Daarbij bleek dat drie banken kwetsbaar blijken te zijn voor xss-aanvallen, iets wat voorkomen kan worden door gebruik van csp.

In het uitgevoerde onderzoek stelt Wouter van Dongen verder dat csp slechts door vier van de veertig onderzochte bankdomeinen wordt toegepast. Tegenover Nu.nl meldt de onderzoeker dat hij xss-lekken heeft vastgesteld bij Triodos, SNS Bank en ABN Amro. Daardoor was hij in staat om scripts in de sites te injecteren, waardoor het bijvoorbeeld voor de bezoeker leek alsof inloggen met DigiD mogelijk zou zijn. Door vervolgens ook daadwerkelijk gegevens in te vullen, stuurt de bezoeker deze gegevens door naar de aanvaller. De aanval is te zien in een video. Van Dongen laat aan Tweakers weten dat de onderzoeken handmatig zijn uitgevoerd en dat van de veertig onderzochte domeinen de drie banken nader zijn onderzocht en op de hoogte zijn gesteld.

Triodos loste het probleem meteen op. ABN Amro liet een maand op zich wachten met een reactie en kwam alleen in actie na navraag door Nu.nl, zo schrijft de site. Daarna stapte de bank ook af van het standpunt dat het de verantwoordelijkheid van een leverancier was om het lek te verhelpen. SNS Bank besloot de onderzoeker niet te belonen voor zijn melding toen bleek dat hij met de gevonden lekken naar buiten zou treden. Een woordvoerder van SNS legt aan Tweakers uit dat deze beslissing is genomen omdat Van Dongen voordat het lek was opgelost al contact zou hebben gezocht met een journalist. Dit zou tegen de regels van de meldingsprocedure van SNS ingaan. "Uiteraard hebben wij hem bedankt voor zijn werk", voegt de woordvoerder daaraan toe.

Een woordvoerder van ABN zegt dat de melding van Van Dongen in eerste instantie niet op de juiste manier is opgepakt. Er wordt nog uitgezocht op welke manier dit heeft kunnen gebeuren. De bank meldt verder dat veilig bankieren voorop staat en dan dit soort meldingen dan ook zeer gewaardeerd worden. De eerdere melding over de verantwoordelijkheid van leveranciers was inderdaad niet correct, zo vertelt de woordvoerder. De verantwoordelijkheid zou volledig bij ABN liggen.

Van Dongen vertelt verder aan Tweakers: "Veel mensen doen vrij luchtig over xss-lekken, maar juist bij banken kunnen deze een grote impact hebben. Daarnaast zouden banken eigenlijk over websites met de beste beveiliging moeten beschikken." Voor het verschijnsel dat banken het eenvoudig in te voeren content security policy dan niet massaal gebruiken, heeft hij niet direct een verklaring: "Vaak wordt gezegd dat er geen misbruik van wordt gemaakt en dat het daarom geen probleem is. Maar in het verleden is aangetoond dat bankenwebsites wel degelijk doelwit zijn van dit soort aanvallen. Dus om te zeggen dat het niet gebeurt, is geen argument."

Xss, of cross-site scripting, bestaat al vrij lang maar blijft een probleem voor websites. Het probleem is aan te pakken via csp, dat ervoor zorgt dat alleen content van vertrouwde locaties op een website ingeladen kan worden. De standaard is niet nieuw, deze stamt uit 2004.

Van Dongen heeft in 2015 eenzelfde soort onderzoek uitgevoerd, toen stelde hij xss-kwetsbaarheden vast bij tien Nederlandse en Belgische banken. Ook de huidige drie banken waren toen kwetsbaar. De domeinen die in het huidige onderzoek wel gebruikmaken van csp zijn het bankieren-domein van de Rabobank, het login-domein van Van Lanschot en alle twee domeinen van Knab.

Videodemonstratie van de lekken

Moderatie-faq Wijzig weergave

Reacties (58)

Bij de ABN moet je ook zogenaamd je account activeren om met een pincode in te kunnen loggen zoals op mobiel. Als je het venster dan weghaalt en terug gaat naar het abnamro domein blijk je gewoon ingelogd te zijn. Lekkere beveiliging ook...
ABN is gewoon een lakse bank en denkt alleen aan de centjes. Zijn eigen centjes wel te verstaan.

Bij Internet bankieren hebben ze ook al jaren scripts mee draaien welke verbinding maken met servers in America.
Doodnormaal volgens ABN, want dit zijn "vertrouwde bedrijven, waar ABN diensten af neemt".

Blokkeer je die scripts, dmv bv Noscript, dan werkt gewoon je hele internet bankieren niet meer.

Je bent dus verplicht die scripts mee te laten draaien en deze daarmee data te laten versturen naar servers in de VS, waar er hele andere (privacy) regels gelden.
En "niemand" weet wat voor data er verstuurd word.

Dus het verbaasd me niks dat de ABN hier pas na een maand op reageert, en ook pas alleen als de "media" vragen gaat stellen.
En dan durven ze in eerste instantie ook nog als antwoord te geven dat het niet HUN probleem is, maar van leveranciers!

Ik heb nog nooit zo'n arrogante bank gezien die privacy en veiligheid gewoon niet belangrijk vind.

[Reactie gewijzigd door Thasaidon op 27 augustus 2016 09:00]

Hoezo draaien ze die vage, maar kennelijk cruciale, scripts in de browser?

Alle data komt toch ook aan de kant van ABN binnen, waarna ze het door kunnen sluizen?
Geen idee waarom ze het op deze manier doen...
Zal wel weer luiheid zijn van DE bank, of de ontwikkelaars...

Ik weet alleen dat als ik internetbankier, mijn browser dankzij de scripts, verkeer verstuurd naar de servers in America.

Zoals gezegd, de scripts zelf blokkeren kan niet, dan werkt de website niet meer.
Dus ik bankier nu in een aparte browser en heb in mijn (niet Windows) firewall ingesteld dat deze browser enkel toegang heeft tot de IP range van de ABN (en nog wat andere cruciale IP's).
De rest, en dus ook het verkeer naar de servers in America, word geblokkeerd.
De site blijft dan iig wel werken.

[Reactie gewijzigd door Thasaidon op 29 augustus 2016 08:20]

Ik ben ook helemaal klaar met ABN-AMRO en hun houding en met hun matige implementatie van internetbankieren. Vooral de mobiel bankieren app kan zo veel beter, ook bij de andere grote banken. Maar mij zijn ze kwijt als klant.

Ik neem even als voorbeeld Westpac in AustraliŽ, daar kan ik zo veel meer dingen regelen in de app. Ik kan eigenlijk alles wat ik op de website kan doen via de app doen en dan nog meer. In Nederland lopen we jaren achter. Er zijn genoeg andere dingen mis met de banken in AustraliŽ, maar hun apps en digitale diensten zijn dikke prima.
Die filmpjes zijn grappig maar bewijzen echt niks.
Je injecteerd hoe?
Ik kan in chrome of dergelijke andere browser, gewoon code erbij typen. En soort gelijke grapjes invoegen en dan zeggen dat het geÔnjecteerd is.
Ik snap wel dat ze werkelijk onderzoek hebben gedaan. Maar dit lijkt gewoon vreemd.
In het begin van het filmpje (van de link in 2e alinea) is gewoon te zien hoe het werkt. In de locatiebalk zie je dat een aantal parameters in de url van een hypotheek tool is vervangen door door de aanvaller gekozen waarden, die zo zijn code laat uitvoeren. Dat is ook een van de populaire voorbeelden bij XSS en reden voor CSP.

Eenmaal gevonden, kan je bijvoorbeeld uiterst behulpzaam deze url delen in 1 van de mooie topics over hypotheken op gathering of tweakers. Je link ziet er redelijk vertrouwd uit, linkt keurig naar de echte banksite en sluit aan op de context van het gesprek, dus het is niet al te vergezocht dat er dan mensen in kunnen trappen en tijdens hun berekeningen jouw code uitvoeren en hun gegevens lekken.

[Reactie gewijzigd door Voutloos op 26 augustus 2016 19:53]

Het lijkt inderdaad om self-xss te gaan. Maar dat wordt me uit het artikel en het 'onderzoek' niet helemaal duidelijk. Overigens vormt het wel degelijk een risico, denk aan social engineering.

Het doet zich alleen nu in de media voor als een enorm ernstige beveiligingslek; wat natuurlijk gewoon onzin is.

[Reactie gewijzigd door eM. op 26 augustus 2016 19:07]

Het is toch vrij duidelijk te zien in het filmpje dat de link voor de ABN website een Reflected XSS is, kwestie van linkje naar de gebruiker mailen en de payload word uitgevoerd als deze op de link klikt
Niks geen self-xss bij dus

Het lijkt te gaan om een flash file die vaak over het hoofd worden gezien door bedrijven bij het beveiligen tegen XSS bugs.
Ik zit zelf dit jaar rond de 100 XSS meldingen naar bedrijven toe (via Hackerone of Bugcrowd) en zeker 25% daarvan is Reflected via swf bestanden
Ms via een malafide extensie/add on?
In het "onderzoeksverslag" staat op het eind kort iets waaruit lijkt dat xss bij AbnAmro daadwerkelijk gelukt is. Maar verhaal is wel erg magertjes.
Punt over csp blijft natuurlijk staan en is hardstikke valide. En zoals hier al gezegd ook ideaal om je marketing of content beheerders in de hand te houden ;)
Ik kan in chrome of dergelijke andere browser, gewoon code erbij typen. En soort gelijke grapjes invoegen en dan zeggen dat het geÔnjecteerd is.
Dat is natuurlijk iets heel anders. Als jij via de DOM-editor in je browser een script injecteert, dan zie alleen jij dat.

XSS is een aanval waar je een script kun injecteren in een andere website, via een URL of een post bijvoorbeeld, wat andere mensen ook kunnen zien.

Als ik hier op Tweakers een script zou kunnen injecten via een forumpost, waardoor andere bezoekers dat script ook te zien krijgen, dan zou dan XSS zijn.
Waarom is CSSStyleSheet.insertRule() "verboden" met CSP?
Op een aantal manier kan dit "verboden" zijn:
- de stylesheet komt van een ander (sub)domein en daardoor niet bewerkbaar vanuit script (sandbox zegt nee, heeft niets met CSP te maken)
- de CSP staat geen 'unsafe-inline' toe voor 'style-src' (en er is geen nonce en/of hash gezet ter validatie) - dit komt er op neer dat de hele style-tag verboden is.

Simpel gezegd, met CSP heb je extra voorzorgsmaatregelen om ervoor te zorgen dat je enkel de bronnen kan toestaan waar je als site-bouwer/eigenaar/beheerder hebt bepaald dat deze te vertrouwen zijn.
Ongelofelijk dat dit gewoon niet serieus genomen wordt door de diverse it managers....
DNB zou het eigenlijk moeten af dwingen...
Je weet dus biet of de info wel bij de IT-manager terechtkomt. Als je de bank belt krijg je de IT-manager echt niet zomaar aan de lijn. Als je een of andere bobo aan de lijn krijgt van techsupport plakt die hooguit een post-it bij haar leidinggevende op het bureau.
Ik mag hopen dat ze bij banken een fatsoenlijk ticketsysteem hebben, en binnen dat ticketsysteem een aparte categorie voor security gerelateerde incidenten. Waar een ICT manager dan melding van krijgt en actie op kan ondernemen. Tenminste, zo zou het moeten zijn. Bedrijfsleven werkt meestal wel zo.. Kan mij niet voorstellen dat dit bij banken anders is.

Aan de andere kant, het is wel vakantieperiode.. Banken zullen ook geen heel leger developers 24x7 paraat hebben staan om zulke zaken te fixen. Leermomentje in ieder geval. Heeft schijnbaar niet de prio gehad die het had moeten krijgen.
Je weet dus biet of de info wel bij de IT-manager terechtkomt.
Ik denk dat het grootste probleem is dat het bij de juiste IT manager terecht komt, bij de ABNAMRO hebben ze iets van 4000 man IT in dienst, slechts een klein deel bemoeit zich met de website, de rest zorgt voor interne IT support en transacties. Als ik me goed herinner was zelfs de cc site uitbesteed, zou me niets verbazen als dat ook het geval zou zijn met de huidige abnamro website (aangezien de ABN het ook heeft over de leverancier). Dan heb je nog eens het stukje politiek waarbij bepaalde afdelingenhoofden helemaal niet gemotiveerd zijn om een andere afdeling te 'helpen' door dergelijke info door te geven, die zien de 'collega' liever op het muiltje gaan...

Nee, een post-it doe je niet bij een dergelijk groot bedrijf, je kan namelijk nooit bewijzen dat je dat gedaan heb. Als je al wat langer werkt bij een dergelijk bedrijf stuur je een mailtje, dat is altijd terug te halen...
Of nog beter schiet een ticket in het systeem en hang de originele mail eraan :)
ow xxxneoxxx in 'nieuws: Onderzoeker vindt opnieuw xss-kwetsbaarheden bij drie N... had het al gezegd

[Reactie gewijzigd door Damic op 26 augustus 2016 23:50]

Ik denk dat het grootste probleem is dat het bij de juiste IT manager terecht komt, bij de ABNAMRO hebben ze iets van 4000 man IT in dienst, slechts een klein deel bemoeit zich met de website, de rest zorgt voor interne IT support en transacties.
Als IT manager competent is en bang is voor zijn eigen positie zal hij ook wel inzien dat zijn eigen security team steken laat vallen.

Echter probleem is dat die IT managers en IT'ers niet afgerekend worden.

Men zou zich op zijn minst schamen als blijkt dat je ondanks miljoenen in IT security te hebben gestoken een buitstaander dit soort lullige zaken kan vinden.

Verder zit er kennelijk niemand naar SIEM te kijken.
Ik kan me nog herinneren dat m'n adresboek (notabene) het niet deed als ik ingelogd was op abnamro bankieren met een script dat omniture blokkeerde. Let wel, de rest deed het nog wel gewoon, maar alleen m'n adresboek niet. En dan wetende dat omniture je data deelde met 3rd parties...
Hier een hele discussie hierover.
Ik heb er destijds bij de bank (uiteraard zonder gevolg) over geklaagd, maar ook bij het CBP.
Tegenwoordig 'bankier' ik uitsluitend met een bepaalde browser in een speciaal daarvoor geinstalleerde VM waarvan de firewall alles blokkeert (ook uitgaande verbindingen) naar/van een IP dat niet van een bank of credit card bedrijf is waar ik zaken mee doe.
Je weet dus biet of de info wel bij de IT-manager terechtkomt.
Of juist wel en is dat het probleem. Dat de IT manager vooral manager is en maar heel weinig IT. Het is een bank, manieren vinden om geld te kunnen verdienen (bij een stafafdeling als IT doe je dat door te besparen) en het stropdas kunnen strikken zijn daar veel belangrijker dan techniek.
Of it-managers die het op de backlog zetten, maar dat de business voorrang geeft aan campages.

CSP blokkeerd ook marketing pixels als je het niet goed inregeld. En tagmanagers werken dan niet direct voor nieuwe pixel-domeinen (is eigenlijk iets goeds).

[Reactie gewijzigd door djwice op 26 augustus 2016 19:21]

Niet alle Cloud hosting partijen ondersteunen CSP headers.

AWS bijvoorbeeld niet op CloudFront.

De vraag er om staat al lang uit. Maar wordt tot nu toe niet opgepakt.
Voor veel websites is dit een valide punt, maar voor een bank niet. Die mag gewoon zorgen dat z'n spul ergens gehost wordt waar je volledige controle hebt over elk aspect ervan (oftewel, zelf hosten).
Ik zou verwachten dat grote hosting bedrijven dit gewoon ondersteunen, net zoals http/2 voor webservices en voor authenticatie servers.

Maar wat opvalt is dat grote IT software vendors deze essentiŽle dingen vaak niet eens kent, laat staan van plan is te implementeren.

Je wil niet weten hoeveel leveranciers ik uit moet leggen wat cipher suites zijn, fs is etc.

Dus zelfs intern gehost aangekocht bij de grootste it leveranciers kom je niet altijd tot ondersteuning van csp. Raar maar helaas absurd. Moeten er extra Apache bakken tussen voor een paar headers, en daar gaat je p2p.

[Reactie gewijzigd door djwice op 26 augustus 2016 21:44]

Leuk verhaal, maar hoe ga je dit in de praktijk benutten en er geld mee verdienen?

Ik kan in Chrome via F12 ook wel wat zooi injecteren maar daar heb ik natuurlijk niets aan.
Het gaat erom dat je eigen pc is geÔnfecteerd door malware. De malware zorgt ervoor dat er extra invulvelden zijn vanwege 'aanvullende beveiliging'. Hierop wordt daarna door de malware deze gegevens doorgestuurd naar andere server.
Denk hierbij om:
- Credit card
- ID
- Tan code (ing)
- inlog van de bank zelf door aanpassing van de bestaande velden.

:X
zie onderstaande reacties

[Reactie gewijzigd door houtig op 27 augustus 2016 11:18]

Als een pc al malware uit voert is elke activiteit op die pc niet veilig meer. Malware is iets anders dan XSS.

Zie mijn andere reactie ( Voutloos in 'nieuws: Onderzoeker vindt opnieuw xss-kwetsbaarheden bij drie Ne... ) voor wat deze aanval wel is.
in dit geval een extra digi-d laag, en laat je daar nou net zaken mee kunnen doen met de (r)overheid, gemeente-website, en andere zoals Belastingdienst.
echt die digi-d brrr, als ze dat hebben in combinatie met je persoonsNR,
dan kunnen hackers toch vervelende dingen gaan doen, zoals je huurtoeslag wijzigen, en zorgtoeslag aanvragen op eigen rekeningnr.

dus wel degelijk eng dat digi-d inlog portal kan worden gekloond
Nee, daar gaat het niet om. XSS is iets heel anders en heeft niets met malware te maken.
Je zou toch verwachten dat dit soort dingen door alle securityteams moeten worden geimplementeerd. Zelfs ik heb hier al meerdere keren van gehoord en over gelezen. Maar er worden ook nog vrij veel emails met redelijk wat gevoelige info zonder SSL/TLS verstuurd, terwijl ook dat al wel even bestaat.

En dan DigID:
Nog steeds geen EV certificate!
Nou kun je zeggen dat dat niets toevoegt, maar het is in ieder geval wel een stuk duidelijker dan een of ander grijs slotje.
Hiep hoera! Weer een beveiligingsonderzoeker die een artikel schrijft wat klakkeloos wordt overgenomen door de media.
Ja, dit zijn security lekken, maar een 'ernstig risico' is nogal uit context geschrokken.

Sta erachter dat deze man niet betaald heeft gekregen. Iets te enthousiast om te samenwerken met de media, flink te weinig kritisch inzicht of enige bescheidenheid over zijn werk en gewoon een headline willen scoren. Beveiligingsonderzoekers die dit soort artikelen uitbrengen mogen van mij op een zwarte lijst.
Ik vond er al enkele bij Belgische banken, helaas blijft het in BelgiŽ een illegale praktijk om ethisch te hacken en moeten de banken je hier eigenlijk voor vervolgen..
Er werd me dan ook afgeraden nog verder te zoeken.
In Nederland is dit totaal anders, daar is men veel opener naar ethisch hacken. :)
Dat komt omdat de meeste banken in Nederland werken onder een Responsible Disclosure policy waarbij er regels zijn gemaakt die gewoon te vinden zijn op de website van de bank zelf.

Er zijn ook veel meer bedrijven die werken onder dit principe denk aan: RDW, Overheid, universiteiten ga zo maar door.
Hoezo, ethisch hacken bestaat niet?
Daar volg ik je niet.

Er zijn wel degelijk mensen die bedrijven helpen hun security game naar het volgende level te tillen, kijk eens op https://hackerone.com/ .
Daar bieden bedrijven, onder zeer strikte voorwaarden whitehat hackers een kans om hun skills, op een verantwoorde manier los te laten op de systemen van het bedrijf.
Dit is een win-win situatie voor alle betrokken partijen.
Het bedrijf kan zich veel veiliger voelen voor blackhat hackers, klantgegevens zijn veiliger, en de hacker verdient er een centje mee bij, zonder de gevonden kwetsbaarheden te gaan misbruiken.
Misbruik je ze toch?
Dan volgt de normale procedure die bij een poging tot hacken wordt opgestart.
Heel simpel. Hacken is het ongevraagd binnendringen van een computer systeem. Dat is ten allen tijden verboden. Wat men etisch hacken noemt en dus niet bestaat is het ongevraagd binnendringen, en dan een briefje achterlaten met "ik was binnen". Maar dat is dus net zo illegaal en kan daarom helemaal niet etisch zijn.
Wat jij beschrijft is het in opdracht vinden van veiligheidslekken. Dat is iets heel anders. Deze mensen doen hetzelfde als hackers maar worden (totaal niet stoer) beveiligingsexperts genoemd.
Hacken is in de mainstream wereld al sinds de jaren 70 een naam voor een criminele bezigheid. Er zijn groeperingen die die term hacken willen hijacken als geuzennaam (de figuren die de gekleurde hoedjes toevoegingen gebruiken) maar dat slaat niet echt aan in de rest van de wereld (net als de kibi's de kolbytes niet verdringen) en zulk gebruik van het woord hacker zouden we dan om wille van de helderheid beter kunnen vermijden.
Hacken is ongevraagd ťn gevraagd binnendringen.
Er zijn wel degelijk verschillende vormen van hacken.

Niet ethisch hacken, is een computersysteem binnendringen, gegeven stelen, deze misbruiken en het systeem verder backdooren.

Ethisch hacken is hacken met goede bedoelingen, al dan niet in opdracht,
Beveiligingsexperts, die werken voor bedrijven, zij zijn niet de ethische hackers waar ik op doel.

De mensen die ik ethische hackers noem, zijn mensen die zich bezig houden met de responsible disclosure programma's van bedrijven, bijvoorbeeld Facebook, Google, Microsoft, en ja, zelfs tweakers!

Zij werken niet persť in opdracht van deze bedrijven, maar gaan vrijwillig op zoek naar kwetsbaarheden, zij gaan net als de kwaadwillige hackers opzoek naar lekken in het systeem, en net als beveiligingsexperts zullen zij net zo ver gaan dat het lek werkelijk aantoonbaar is, maar ze zullen dit niet misbruiken.

Het is goed dat de naam Hacken een minder zwarte betekenis krijgt, hacken is in vele gevallen simpel, outside the box denken.
Wanneer je de naam hacken steeds die donkere atmosfeer toekent zullen bedrijven hiervoor blijven terugdringen.

Responsible disclosure is vaak een goedkope en enorm effectieve manier om je security game naar het volgende niveau te brengen, en de mensen die zich ermee bezig houden noemen zichzelf vanalles, gaande van security researcher tot ethisch hacker, en daar voeg ik mezelf ook bij.

Je kan twijfelachtig en sceptisch staan tegenover deze vorm van hacken, maar het heeft enkel nog maar goede dingen opgeleverd.
De lijn tussen kwaadwillig en goedbedoeld hacken is voor dit soort mensen heel duidelijk. Wanneer een bedrijf deze mensen toelaat te testen, is het aan hen om te monitoren of zij ook werkelijk ethisch bezig zijn, wat vaak of gewoon bijna altijd, zo is.

https://www.google.com/about/appsecurity/reward-program/
https://www.facebook.com/whitehat
https://technet.microsoft.com/en-us/library/dn425036.aspx
Het is goed dat de naam Hacken een minder zwarte betekenis krijgt
Dat is het omwille van de beveiliging juist niet. Je kunt niet iets goed en iets fouts dezelfde naam geven. Dat maakt de scheidslijn veel te dun.
De lijn tussen kwaadwillig en goedbedoeld hacken is voor dit soort mensen heel duidelijk
Voor de mensen die dat doen is dat duidelijk. Voor de mensen die de opdrachten geven is dat al wat minder duidelijk. Voor het grote publiek is dat niet duidelijk. En juist het grote publiek moet zich meer met beveiliging gaan bijhouden, al was het maar om het balng er van in te zien en daarmee bereidheidn te kweken het werk van beveiligingsexperts te gaan financieren. De "etisch hacker" die ongevraagd in een systeem in breekt daarvan melding doet en dan een bedankje verwacht is verkeerd bezig.
SNS je mag die man best wel bedanken, op zijn minst wel zo netjes lijkt me.
"Uiteraard hebben wij hem bedankt voor zijn werk", voegt de woordvoerder daaraan toe.

Verder heeft SNS wel ten dele gelijk. Als je eerst een journalist wil gaan vertellen wat er mis is ipv. de bank.
En dat zegt de partij die "betrapt" is en dus NIET het voordeel van de twijfel hoort te krijgen.
Beetje gaan mieren over moraal terwijl ze bij herhaling de zaken niet op orde hebben.

Even een refresher over deze bank:
https://youtu.be/IhSWj1PRh8w
Dus omdat de SNS niet een woordenboek voorbeeld van 'moraal' is maakt het niet uit wat een onderzoeker doet? ;)
Grens tussen onderzoeker en cracker is namelijk ook maar net zo groot dat het eerst publiceren/verspreiden van een lek voordat je het meldt veel meer in het straatje 'cracker' valt namelijk...
Niet gek dat ze hiermee dan een voorbeeld maken, zou mooi zijn als ik nu een lek vind, zou ik het van jou mogen verkopen aan een crackers groep en dan nog zou ik de 'good guy' zijn...

[Reactie gewijzigd door RGAT op 27 augustus 2016 00:50]

Begrijp je punt hoor, maar wie zegt dat de SNS hier de waarheid spreekt? Ik zie in ieder geval geen reactie daarop van de hacker zelf, dus het is op z'n minst eenzijdig.
Overigens best wonderlijk eigenlijk: de hacker is blijkbaar zelf geÔnterviewd maar hij is niet naar deze uitspraak/actie van SNS gevraagd? Alleen de SNS-woordvoerder mag er wat over zeggen? :?

Als je dan toch meteen een (ondanks de ' ') negatieve draai aan het woord hacker wilt geven, dan zou hij in jouw voorbeeld het lek misbruikt hebben om wat buit te kunnen maken. Dat is blijkbaar niet het geval (en een andere discussie) maar laten we voorkomen dat hackers negatieve associaties oproepen (waar al hard genoeg aan gewerkt wordt door de media).
Hacker idd aangepast :)
Maar wie zegt dat de SNS hier niet de waarheid spreekt, onderzoeker heeft zelf blijkbaar er geen punt van gemaakt, of omdat hij zijn werk graag gratis doet of omdat hij zelf ook wel weet dat de SNS een punt heeft.
Dat banken liegen is een leuk onderwerp in het cafe ;) maar de werkelijkheid ligt een stuk genuanceerder...
toen bleek dat ie naar buiten ging treden, oftewel het onderzoeksartikel was nog niet naar buiten gebracht. of heb jij het al eerder gelezen, dat een andere bank al een maand de tijd had en weer andere bank de zaken al op orde had gebracht binnen die 4 weken en 3 dagen,,, ja dan ben je als bank NIET goed bezig geweest.
en dat staat er ook.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True