Hoofdcategorieën
Device Settings

Sites van Belgische banken ING en Dexia gehackt

Door Olaf van Miltenburg, maandag 7 september 2009 10:48
Submitter: Precision, views: 24.002

Een Roemeense hacker is erin geslaagd sites van de Belgische banken Dexia en ING binnen te dringen door middel van een sql-injectie. Ook sites van de bank HSBC France en de Italiaanse nationale postdienst bleken vatbaar voor sql-injecties.

Een Roemeense hacker die zichzelf 'Unu' noemt, heeft inmiddels al heel wat sites kunnen binnendringen met sql-injecties. Onder andere sites van het Britse parlement, Orange en Yahoo bleken kwetsbaar. Unu heeft nu Dexia, ING, HSBC France en Poste Italiana aan dit rijtje toegevoegd. Van de hacks is die van HSBC France het omvangrijkst: Unu claimt dat hij volledige toegang kreeg tot de Microsoft SQL-server van de bank en dat de wachtwoorden van de beheerders in platte tekst te vinden waren. Bovendien werd op mails naar de beheerder, naar abuse en naar security gereageerd met standaardmails die meldden dat de betreffende personen op vakantie waren. 

De hack van ING Belgie betreft de site van de Gift Shop. De url toont aan dat hiermee toegang is verkregen tot de ING-server, zij het beperkt. Volgens Unu moet verdere toegang niet moeilijk zijn en ook hier waren de wachtwoorden van de beheerder onversleuteld opgeslagen. Ook kon hij klantgegevens inzien, inclusief wachtwoorden. "Dit betekent dat er een gebrek aan veiligheid was", erkent Ilse De Muyer, woordvoerster van ING tegenover VTM Nieuws, die overigens beweert dat er geen link is met bankgegevens van klanten.

Niet alleen kreeg de Roemeen toegang tot de Dexia-database, ook kwam hij erachter dat load_file execution mogelijk was, waarmee hij nagenoeg volledig beheer kon verkrijgen over de Ubuntu-server van Dexia na het injecteren van kwaadaardige code in een beschrijfbare map. Volgens Dexia ging de oorspronkelijke hack om een site met koersinformatie die werd beheerd door een externe partij en zou deze site geen link hebben met de bankgegevens van klanten. De laatste hack die Unu op zijn site meldt, is die van de site van Poste Italiane, waarbij hij toegang verkreeg tot de Oracle-backend. De hacker zou geen gegevens buitgemaakt of gepubliceerd hebben en de banken enkel op de beveiligingsproblemen hebben willen wijzen.

Volgende 11:24 Google doet water bij de wijn voor Europese boekuitgevers
Vorige 10:22 Codemasters kondigt nieuwe content aan voor Lotro
Advertentie

Reacties

«  1  2  3  »

Toch wel slecht dat zoveel dingen kunnen worden " gehacked" door SQL injecties
Eerst fok en enkele andere websites
en nu 2 banken

Zeker voor een bank waar je verwacht dat het goed in orde is

Zit wel een verschil tussen "de bank" hacken of de website van een bank hacken. Dat je in het ene systeem van een bank komt betekent nog absoluut niet dat je bij de financiele systemen kunt komen. Vaak zijn het ook verschillende partijen die de verschillende systemen beheren. Leuk dat je dan een of andere cadeausite kunt kraken, maar dan ben je nog nergens.

Dit neemt niet weg dat een bank een hoger potentieel risico vormt. Wanneer je de controle hebt over diens website (het gezicht van de bank richting klant), dan kun je eenvoudig de klant valse informatie voorschotelen of bijvoorbeeld als man-in-the-middle transacties afvangen.

Als er wachtwoorden en gebruikersnamen van beheerders 'in platte tekst' op de server slingeren, wat slingert er dan nog meer?

Snap je wat ik bedoel? Het is op zijn minst de moeite waard om daar (intern) onderzoek naar te doen. Als Bank wil je echt niet te boek staan als 'die bank die toen gehackt is'.

Heel veel mensen vergeten dat security niet iets is wat je zomaar even doet. Sterker nog, het is niet iets wat je eenmalig doet en klaar. Het is een voortdurend process.

Sterker nog, het is een voortdurend process wat bakken vol met geld kost. Belangrijke instanties maken vaak goed overwogen keuzes over wat het kost om een systeem tot bepaalde mate te beveiligen en vergelijken dit met wat het zou kosten als iemand de security hole vindt en deze misbruikt. Daarbij wordt ook de kans meegenomen dat iemand uberhaupt zon fout vindt. (Zie ook ISO 27001, 27002 en de rest van de 27000 serie van iso).

Ik denk dat het dan ook aannemlijk is dat bij de risk anaylis van ing in dit geval is onderzocht is dat de webshop los staat van het financiele systeem en dat het dus niet de moeite waard is om zich daar goed tegen te beveiligen. Want vergeet niet, als de bank meer geld zou verliezen door een hack dan dat het zou kosten om het systeem te beveiligen dan zullen ze dat zeker weten doen.

Overigens wil ik het hiermee absoluut niet goedpraten wat er is gebeurd gezien, maar gezien het budget van banken ook niet oneindig is, moeten er keuzes gemaakt worden. Zolang een bank mij kan garanderen dat ik bij een hack, wat duidelijk hun schuld is, mijn schade wordt vergoed maak ik me geen zorgen.

ms-sql server draaien zonder encryptie op de passwoorden ... klinkt toch als een tekortkoming in de instellingen eerder dan een gat in de beveiliging... zoals je kan lezen ging het om een hack van de database van de website welke niet gekoppeld zijn aan klantendatabases. moe je mij eens uitleggen hoe ik zonder klantgegevens iets kan bestellen op die sites :)
loadfile execution aan laten staan is ook niet zo best plan doorgaans.. lol..

In MS SQL zit een security breach, waardoor de wachtwoorden van alle sql users in klare tekst in het GEHEUGEN staan. Zie verderop voor meer info hierover.

FOK wordt door een groep vrijwilligers gemaakt, website van banken door professionals. Dat lijkt me toch een belangrijk verschil, want van vrijwilligers kun je geen topkwaliteit verwachten terwijl je dat van een professional wel kunt.

Wat dat betreft is het 10x erger dat de website van een bank gehacked wordt dan die van FOK.

En hoewel de hacker heus niet zomaar rekeningen kan gaan plunderen is het hacken van de website natuurlijk wel de ultieme kans to phishing. Extra URL toevoegen "Ga direct naar internetbankieren" met een valse URL er onder en klaar ben je, weinig klanten die daar met argwaan naar kijken omdat de link op een voor hun vertrouwde omgeving staat.

Hoe makkelijk is het eigenlijk je te verdedigen tegen SQL injecties? Is het niet voldoende mysql_escape_chars() te gebruiken om nu maar een php-voorbeeld te geven?

SQL-injecties gaan er toch vanuit dat je de SQL server doet geloven dat je datastring ten einde is, en dat nu weer commando's komen doordat je ergens een dubbele of enkele quote gebruikt? Of heb ik dat helemaal fout?

Nee je hebt gelijk. Het is bizar hoe vaak je ziet dat zgn. ‘professionele’ programmeurs zoiets simpels als escaping van tekens (niet alleen in SQL maar bijv. ook in HTML wat weer tot XSS-kwetsbaarheden leidt) niet op orde hebben.

Hoe makkelijk is het eigenlijk je te verdedigen tegen SQL injecties? Is het niet voldoende mysql_escape_chars() te gebruiken om nu maar een php-voorbeeld te geven?
Dat is één optie, je kunt ook prepared queries gebruiken. Maar ja, het is (relatief) belachelijk eenvoudig om SQL injectie te voorkomen. Dit soort gevallen geeft aan dat de ontwikkelaar geen standaardmanier gebruikt om queries uit te voeren, en/of dat hij het overzicht verloren heeft over waar wel escaping in gebruikt wordt en niet. Maar meestal is het het eerste - zelfs als je een eenvoudige php programmeur bent, kun je redelijk eenvoudig een wrapper functie om mysql_query() schrijven die de bijgevoegde parameters escapet.

dus dan bedoel je zoiets als:
mysql_query("select * from users where id=".mysql_escape_string($_REQUEST['id']));
dan zeg ik:
pagina?id=1 union select * from users

Je hoeft maar 1 gat te vergeten en er is een ingang.

zo ga je ook niet met mysql om.

mysql_query("select * from users where id='".mysql_escape_string($_REQUEST['id'])."'");

levert dat probleem niet op.

Ik weet niet of jouw code een fout oplevert of niet, maar je moet inderdaad niet alleen escapen, je moet ook je aanhalingstekens zetten. Maar ook dat zou een professionele programmeur toch allang niet meer mogen fout doen?

Je kan ook eerst controleren of $_REQUEST['id'] wel een getal is. Dan hoef je heel niet te escapen.

Of je gebruikt gewoon prepared statements:

[code]
$stmt = $mysqli->prepare("SELECT * FROM users WHERE id=?");
$stmt->bind_param("i", $id);
$stmt->execute();
[/code]

voor ints werkt dit beter :
mysql_query("SELECT * FROM users WHERE id=".intval($_REQUEST['id'])." ");

Slimme hacker als ie daar langs komt

of ctype_digit gebruiken toch?

Volgens Unu moet verdere toegang niet moeilijk
Volgens Unu was toegang niet mogelijk, ... toch is de harcker daarin succesvol geweest [..]

@RefriedNoodle; Daarmee doe ik op 't verleden, 'vroeger' zei men dat de huidige setup veilig is. Echter is het tegendeel gebleken.

[picture] <-- lelijk

[Reactie gewijzigd door himlims_ op maandag 7 september 2009 11:08]


Hij zegt dat het niet moeilijk moet zijn, niet dat het niet mogelijk is, toch?

niet moeilijk, wel mogelijk...

Controle - Controle.
Da's wel heel slecht.
Je kan gewoon een aantal mensen zien die user+pwd hetzelfde hebben.

Plain text wachtwoorden... da's wel heel erg slecht. Zelfs voor een simpel forumpje dat ik zelf in elkaar prog neem ik de moeite (2 minuutjes extra werk) om met (salted) hashes van de wachtwoorden te werken. Onbegrijpelijk dat dit op dergelijke niveaus nog verkeerd kan gaan.

Dat zie je bij wel meer multinationals fout gaan, o.a. T-Mobile <klik>

Nou, wat dacht je van de mentaliteit van bijvoorbeeld Microsoft over de mogelijkheid tot het verkrijgen van alle SQL users/beheerders' wachtwoorden wanneer je administrator rechten hebt in SQL server?
Microsoft zegt dat dit geen vulnerability is. Meer hierover kun je hier vinden.

De wachtwoorden stonden gewoon unencrypted in het geheugen...

Dit probleem geldt dus voor SQL server 2000, 2005 en 2008 die mixed authentication SQL auth en windows auth) gebruiken, omdat je zo dankzij de SQL wachtwoorden van gebruikers ook gelijk hun AD wachtwoord hebt. En ik denk zelfs dat je bij omgevingen waar die situatie er niet is, ook gevaar loopt omdat mensen vaak op elkaar gelijkende wachtwoorden gebruiken. Te denken valt aan opvolgnummers, of wachtwoorden met vergelijkbare patronen.

[Reactie gewijzigd door musiman op maandag 7 september 2009 11:26]


3x raden wat al sinds SQL2005 uit is sterk afgeraden wordt:
Juist ja, Mixed mode.

Neemt niet weg dat mijn laatste opmerking nog geldt. Mensen hebben de neiging dezelfde of op elkaar gelijkende wachtwoorden te gebruiken.

Eigenlijk moeten er toch wel koppen gaan rollen als er overal daadwerkelijk plain-text wachtwoorden opgeslagen worden. Zeker bij beheerders van grote sites! Het feit dat er ook nog eens in klantgegevens gekeken kan worden valt natuurlijk al helemaal niet goed te praten.

Maargoed, dit zal met het EPD en vergelijkbare dossiers ook nog wel gebeuren.

ms beheerders moeten ook uitkijken want er is een exploit voor windows servers t/m 2008 in omloop: http://webwereld.nl/nieuw...t-groter-dan-gedacht.html

las het bericht ook, erg verontwaardigd, maar ik heb zo'n vermoede dat de aankomende peride nog wel meer 'grote' pagina's/bedrijven slachtoffer vallen aan deze 'hack

SQL injections kunnen doen en dan ook nog wachtwoorden onversleuteld opslaan.
Welk dom bedrijf heeft deze sites gemaakt?

De ING en andere banken betalen tonnen voor zo'n site en dan heeft het van zulke domme fouten. Ik begin nu zelf te twijfelen of mijn ING wachtwoord wel versleuteld opgeslagen is...

Volgens mij niet, want als een vergeten wachtwoord wil opvragen krijg je deze via post thuis. (was met postbank iig zo dat is nu ook ING)

Was/is dat niet een nieuw wachtwoord die je dan krijgt?

Op de website van De Redactie staat dat het de goede kant uit gaat met de beveiliging van het internetbankieren, en dat het aantal inbraken, en ook het ontvreemde bedragd gedaald is tegenover de twee voorgaande jaren.

[Reactie gewijzigd door Natrium op maandag 7 september 2009 10:58]


Leuk voor De Redactie, maar dit heeft (vrijwel) niets te maken met het onderwerp. Internetbankieren != de website van een bank.

inderdaad.

Ik wilde enkel aantonen dat internetbankieren zeker en vast ok is qua beveiliging.

Hoewel dat geen excuus mag zijn om de rest zo lek als een mandje te laten zijn uiteraard.

Als u voor internetbankieren een andere website gebruikt dan degene van uw bank ben ik wel geinterresseerd wat voor een website dat is, het is dus bepaalt niet iets anders.

Als iemand via de website van uw bank malware kan installeren dan verloopt het internet bankieren ook niet zo veilig meer als de bedoeling is.

Goed dat deze hacker er is: hij is slimmer dan andere, kwaadwillende hackers (sneller althans).
En hiermee is hij ze voor, de bedrijven kunnen alle lekken patchen voordat kwaadwillende hackers ermee aan de haal kunnen gaan :Y)
Respect voor deze hacker dus.

Je weet niet of hij slimmer is. Hij publiceert het als eerst, maar misschien zijn er al 100 voor hem geweest, die alles stilletjes hebben verkocht...

Waar rook is, is vuur...

Er is toch ook ooit eens iemand geweest (jaren geleden) die de bankgirocentrale had gehackt en voor iedere transactie 1 cent genereerde en naar zijn rekening stortte. Dat liep ook best lekker, totdat hij bij toeval werd ontdekt. Had hij na 1 of 2 maanden zich opnieuw toegang verschaft en zijn aanpassing weer verwijderd, dan was het nooit ontdekt.

Sja, dat was een gok dus - ga je nu stoppen of speel je nog een ronde door met het risico om alles te verliezen.

Maar om te zeggen dat het nooit ontdekt werd gaat wat ver - d'r worden wel uitgebreide logs van transacties bijgehouden, neem ik aan.

Dat was Superman III (http://en.wikipedia.org/wiki/Superman_III#Plot) :)

Maar daarna heeft iemand het ook eens in het echt gedaan vziw.

Op de wiki pagina hierboven vind ik dat de techniek 'salami-slicing' heet, dus waarschijnlijk wordt/werd dit wel meer gedaan.

http://en.wikipedia.org/wiki/Salami_slicing

Ach ja ...
Zo zie je maar , banken gaan net zo met login gegevens om als met "geld" .. slordig.
(Behalve als het om eigen knip gaat)

Ik zie dit niet als extreem ernstig ofzo , maar als je login gegevens "plain" in een database hebt staan dan ben je wel heel fout bezig /// ongeacht of het nou belangrijke gegevens zijn of niet..

Zelfs een gemiddelde amateur site heeft zoiets nog gehashed in de DB staan..

[Reactie gewijzigd door Donster op maandag 7 september 2009 11:01]


Zelfs een gemiddelde amateur site heeft zoiets nog gehashed in de DB staan..
Met het verschil dat de gemiddelde amateur nog wel eens zijn best doet om dit soort zaken te voorkomen. Ik heb zo'n idee dat die gehackte sites gebouwd zijn door een duizend-in-een-dozijn webbedrijfje die goedkope krachten snel een website in elkaar laat prutsen.

Wat een slechte zaak dat wachtwoorden ongecodeerd worden opgeslagen. Waarom zou dit überhaupt nog gedaan worden?

Ik neem aan dat de wachtwoorde wel vergrendeld waren met een sleutel maar wellicht niet ook nog eens opgeslagen werden met encryptie in een bestand.

Ik vindt de keuze van Ubuntu ook wel een vreemde, dit is dan ook zeer slechte reclame voor Ubuntu.

Hoe kun je dit nu slechte reclame voor Ubuntu noemen?


Het is eerder een slechte reclame voor de IT-afdeling van Dexia... Ubuntu ligt hier niet aan de oorzaak, de configuratie van het systeem wel!
«  1  2  3  »

Op dit item kan niet meer gereageerd worden.

Volgende 11:24 Google doet water bij de wijn voor Europese boekuitgevers
Vorige 10:22 Codemasters kondigt nieuwe content aan voor Lotro
VNU Media logo Hosted by True

© 1998 - 2012 Tweakers.net B.V. - Alle rechten voorbehouden - Contact - Jouw privacy - Algemene Voorwaarden

Uitgever van:

Website van het jaar 2011