Hostingbedrijf: hack bij Simpel was mogelijk door fout bij migratie

Het lek, waardoor databases van de virtuele providers Simpel, Youfone en Lebara benaderbaar bleken voor een hacker, was het gevolg van een menselijke fout bij de migratie. Dat zegt hostingbedrijf Aspider. De databases zijn wel verouderd.

De databases die de hacker kon inzien worden niet langer gebruikt, blijkt uit een verklaring die Aspider heeft gegeven aan Tweakers.net. "Wij betreuren dit echt ten zeerste. Dit had niet mogen gebeuren. Wij doen er alles aan om dit in de toekomst te voorkomen", aldus Aspider-directeur Patrick Meyer.

Aspider beheert de databases, omdat het websites ontwikkelt voor de getroffen bedrijven. Aspider wijt het feit dat de databases nog benaderbaar waren aan een 'menselijke fout'. Het ging in totaal om 158 databases, waaronder die van virtuele providers Simpel, Youfone en Lebara. Ook artiesten als Rene Froger zijn getroffen. De hacker kwam binnen via een lek op de site van Frans Bauer.

De hack kwam aan het licht toen de hacker Vodafone Webcare tipte via een dm op Twitter. De database van virtuele provider Simpel bevatte niet alleen namen en e-mailadressen, maar ook gegevens over wanneer en met wie klanten aan het bellen waren, zogenoemde verkeersgegevens. Simpel moet die gegevens bewaren, zodat de recherche die kan opvragen bij een strafrechtelijk onderzoek. Diensten op de site van de virtuele provider werden zaterdag uit voorzorg offline gehaald.

Aspider heeft Fox-IT een scan laten uitvoeren en daarbij kwamen meer lekken aan het licht. Die zijn onmiddellijk gedicht, zo zegt Aspider. Ook worden andere maatregelen genomen om herhaling te voorkomen, al is onduidelijk welke dat zijn.

Reacties (46)

[Silence]

Wij doen er alles aan om dit in de toekomst te voorkomen. Deden ze dat maar altijd dan gebeuren dit soort dingen ook niet.

[DrFurioux]

Doen ze er ALLES aan? Alles? Maar zodra geld een rol gaat spelen dan verliest het woordje "alles" toch ineens z'n waarde..

En hoe kun je door 1 mensenlijke fout in godsnaam 158 Databases "hacken"?

[Blokker_1999]

De hoogste privileges op een db server geven toegang tot alle databases van die server. Als men dus toegang krijgt tot een account met zulke privileges word het eenvoudig om alle databases te zien.

[sys64738]

Aangezien het via de website van Frans Bauer is gebeurd, zou dat dus betekenen dat die site met een root/sa/sys account gekoppeld was aan de database.... Ach, het zou me niet eens verbazen.

Je ziet het zo vaak dat men 20 applicaties heeft draaien en er maar 1 of 2 db users aangemaakt zijn. Lekker allemaal connecten als admin en gaan. Verrekte handig totdat je dit soort dingen aan de hand krijgt en het toch niet zo'n goed idee bleek.

Daarnaast: hoe kan dit veroorzaakt worden door een migratie? Blijkbaar gingen ze over naar nieuwe database (omdat ze claimen dat de oude nog draaiden). Lijkt me niet heel ingewikkeld toch? Stop applicatie (of maak read only), dump db, import db, zet applicatie over op nieuwe db, test, kill oude db. Op welk punt zou hier de veiligheid in het gedrang komen? Kan volgens mij allemaal vrij veilig uitgevoerd worden.

[terror538]

Hoe dom kan je als organisatie zijn om al dat soort websites als admin de database in te laten schrijven ?!?

Ik bedoel:
ik maak een nieuwe website/wp-install/drupal whatever. Ik maak een nieuw databeestje aan, ik maak een nieuwe user met een random password van 16 karakters en klaar. welgeteld 1 minuut werk, maximaal.

Hoe vaak moet je uberhaubt nog direct in de database schrijven ???

[leuk_he]

Hoe vaak?

bij de migratie, waar je het lekker even even als root doet... die gebruiker die jij aanmaakt doe je ook "even" als root.

merk op, in jouw beschrijving zit die fout ook: Je maakt als laatste stap een nieuwe user aan. Je hebt dus in jouw beschrijving het databeest als root aangemaakt -> waarmee lekje een LEK wordt.

ik zeg niet dat JIJ het fout doet, maar zo snel is de fout wel gemaakt....

En het moet allemaal zo snel en goedkoop mogelijk immers....

[David Mulder]

Heel simpel: stel je vergeet even een setting om te zetten dat de administrator inactief is, of een setting om te zetten dat de frans bauwer site naar de nieuwe databases verwijst terwijl de oude de security meuk net overhoop is gehaald vanwege de migratie, of weet ik veel wat. Ondanks dat het vreselijk is dat dit is gebeurt is, is het echt niet zo vreemd. De enige manier vaak om dit soort hacks *echt* te voorkomen (het lek in de frans bauer site zelf) is volledig geen oude code te gebruiken whatsoever, en dat is financieel niet haalbaar, maja.

[jippe]

Nou heel simpel? Je bedoelt luie designers?

Welke designer/beheerder staat nou toe dat site_x met credentials op de localhost MySql ook rechten heeft op de andere DBs? Lijkt mij meer een laxs gevalletje.

Eigen CMSje ontwikkeld??, voor het gemak meer even allemaal dezelfde username/pwd op de database. Is toch allemaal localhost ( of voor mij part een een dedicated SQL bak).
Zolang het maar lekker werkt vanuit het de CMS interface. Eigen medewerkers vanuit je CMS lekker overal bij, en de klant minder rechten op de tabellen.

Kun je lekker overla dezelfde dbconnect copy/pasten.

[Verwijderd]

Uitlezen van config bestand waar DB info in staat lijkt mij logischer,.

[Heli0s]

Ik neem aan dat al die Databases op een server gehoste worden, dan is een lek wat te toegang geeft tot een super user / root genoeg

[sypie]

Ik denk dat dit betekent dat ze nu een extra regeltje in hun migratieprocedure neerzetten: Denk er aan om oude databases te verwijderen, deze zijn gevoelig voor hacks.

En daarmee is de kous af voor de provider, ze hebben er toch alles aan gedaan om het te voorkomen in de toekoms?

[Niemand_Anders]

En elke database EIGEN credentials geven! Zelfs als de databases op dezelfde machine staan, kan het natuurlijk niet zo zijn dat je via de database credentials van de Frans Bouwer website bij de database van Simpel of een andere klant kunt komen!

Daarbij hoeveel websites ken jij welke NA de migratie nog steeds de oude database(s) benaderen?

Aan de andere kunt mag je je afvragen of databases van telecom providers niet op een dedigated database server behoren te staan. En hoe zit het met de backup bestanden. Staan de backups van de Frans Bouwer, Rene Froger en Simpel ook gezellig op dezelfde DVD/disk/tape?

Wat mij betreft mag het CBP Simpel heel erg hard aanpakken. Dit soort privacy gevoelige informatie behoort niet op een shared server en Simpel had dat moeten voorkomen! Dit is gewoon nalatigheid van meerdere partijen op meerdere niveaus.

De woordvoerder had beter kunnen spreken van een lawine van menselijke fouten.

[jippe]

Idd.

Kennelijk is de prijs nog steeds een issue en wordt er niet voor dedicated hosting gekozen door dergelijk partijen. En daarna nog eens de scheiding tussen rollen van Web/Db/App.
Met juiste firewalls ertussen.

Ik denk dat het vaker dan je denkt voorkomt.
We zien gelukkig niet alles als publiek.
Maar ook bij huisartsen, apotheken, webshops.

Als het CBP hier iets mee kan doen, is dat alleen maar omdat het komt bovendrijven.
Het zou mooier zijn als er richtlijnen zijn, waar ook een waakhond achter zit. Met tanden.

Uiteindelijk gaat het allemaal om geld en moet de klant veiligheid "beleven".
Dat is echter een ballon die in 80%( eigen ervaring) van de gevallen zo lek is.
Sales en after sales doen het verhaal, project management knijpt implementatie af om deadlines en kosten te bewaken. Eindproduct, half af....

[Hensz]

Daar zouden ze bij een migratie nooit rekening mee hebben moeten houden. Die databases waren naar verluidt niet in gebruik en horen daarom never nooit niet op een live webserver o.i.d. te staan, maar op een disk of tape in een kast of kluis!

[DeTeraarist]

Aspider heeft Fox-IT een scan laten uitvoeren en daarbij kwamen meer lekken aan het licht. Die zijn onmiddellijk gedicht, zo zegt Aspider.

Geloven ze het zelf ook? Zaterdag ontdekt, zondag auditje gehad en gisteren alles gefixed?

[highflyer]

dat kan wel, DMZ aan oh laten we dat maar uit zetten

[arjankoole]

Geloven ze het zelf ook? Zaterdag ontdekt, zondag auditje gehad en gisteren alles gefixed?

Ik doe zelf security scans, en de meeste gaatjes zijn in 5 minuten te pluggen. Dat is echt geen big deal. Het zijn vaak de kleine en simpele dingen (die heel groot kunnen worden qua gevolgen) die je als eerste over het hoofd ziet.

[rockhopper]

Kwalijke zaak, maar ja als het een menselijke fout betreft dan helpt zelfs de beste beveiliging niet. Vergelijk het een beetje met je waardevolle spullen in een mooie "state of the art" kluis leggen om vervolgens deze niet af te sluiten.
Je zou denken dat ze de data-verkeersgegevens ergens 'offline' bewaren en alleen beschikbaar maken op het moment van aanvraag door recherche.
Dat er meer fouten opeens opduiken nu er een extra scan door aspider / fox-it is natuurlijk wel een slechte zaak. Dit betekend volgens mij dat er zonder die menselijke fout ook al een boel rammelt.

[Johnny]

"Je zou denken dat ze de data-verkeersgegevens ergens 'offline' bewaren en alleen beschikbaar maken op het moment van aanvraag door recherche."

Dan voorkom je nog steeds "menselijke fouten" niet. De enige manier om er voor te zorgen dat dit soort gegevens nooit openbaar worden gemaakt is door ze simpelweg niet op te slaan.

De bewaarplicht van dit soort gegevens zal in de toekomst toch onhoudbaar blijken omdat de gegevens uiteindelijk (door "menselijke fouten") zullen lekken en meer schade aanrichten dat het bewaren als voordeel heeft.

[IJzerlijm]

Als je niks opslaat kan je ook nooit een claim 'ik heb niet 3 uur gebeld, geef me m'n geld terug' behandelen. Je kan dan beter de tent sluiten.

[Pikoe]

De database van virtuele provider Simpel bevatte niet alleen namen en e-mailadressen, maar ook gegevens over wanneer en met wie klanten aan het bellen waren, zogenoemde verkeersgegevens. Simpel moet die gegevens bewaren, zodat de recherche die kan opvragen bij een strafrechterlijk onderzoek. Diensten op de site van de virtuele provider werden zaterdag uit voorzorg offline gehaald.

Het is gewoon wachten op hackers die al deze informatie gaan verzamelen en online zetten.
Veel mensen vinden dit nog normaal, maar wat als straks je browsergeschiedenis online wordt gezet, of de database van je lokale coffeeshop of het patiëntendossier van je arts.

Privacy bestaat niet meer met al die bewaarplichten.

[Reactie gewijzigd door Pikoe op 23 juli 2024 19:56]

[Blokker_1999]

Waarom zit jij dan in hemelsnaam nog op het internet?

We kunnen niet de eenvoud van ICT wensen zonder de risicos. Mensen maken fouten, hebben ze altijd gedaan en zullen ze altijd blijven doen. Wil je niets te maken hebben met de fouten van een ander, zoek dan de eenzaamste plaats op deze aardkloot op, ga daar wonen en hoop dat niemand ooit de fout maakt om er eens te passeren.

[Pikoe]

Het is vrij simpel: Wat niet bewaard wordt kan niet worden gevonden.

Ik weet wat er van mij op internet te vinden is, een hoop. Dat vind ik niet zozeer erg, maar als iemand zomaar mijn hele geschiedenis kan gaan zien vind ik dat wel erg.
Het is gewoon erg dat dit kan, menselijke fout of niet. Juist omdat mensen fouten kunnen maken zouden dit soort dingen gewoon niet bewaard moeten worden.


Privacy is overigens wel iets wat relatief is. Als je iets doet hoeft dat niet altijd anoniem te kunnen. Maar als jij niets om privacy geeft, veel plezier met de GPS chip die door je regering geimplanteerd zal worden om je 24/7 te volgen zodat het 'veiliger wordt' op de wereld.

Mensen met iets kwaads in de zin kunnen dit soort dingen omzeilen, en de normale man wordt de dupe van dit soort lekken.

[Reactie gewijzigd door Pikoe op 23 juli 2024 19:56]

[Verwijderd]

Fout lijkt me bekend: MySQL poort stond open voor de buitenwereld. In de oudere MySQL versies zat een lek ( http://www.security.nl/ar...ekken_door_MySQL-lek.html ) , waardoor authenticatie in 1 van de 256 gevallen altijd lukt. Kinderspel dus, waar weinig kennis voor nodig was. Vervolgens is het een SQL query om de databases naar je toe te trekken.

[jippe]

Nou dan kan het dus idd een menselijk fout zijn.

Tijdens de migratie even 3306 openzetten. Beide kanten. /CHECK
Overpompen. /CHECK
Dicht. /FAIL


Wat dan weer wel raar is, is dat jou gemelde lek op oudere SQL en MarinaDB van toerpassing is. Ik heb nog nergens gelezen dat dit ook zo was.
En op de nieuwe server staat neem ik aan de nieuwste gepatchte MySQL 5.5.xx?

[Verwijderd]

Hoe weten jullie dat het mySQL betreft hm?

[BlackHawkDesign]

Inderdaad, op en top speculatie hier. Ik vind het altijd zo lachwekkend dat mensen hier beginnen te schreeuwen, terwijl ze de feiten niet kennen.

Hoe kan het gebeuren dat die oude databases niet opgeruimd zijn? Heel simpel:
- Er vind een migratie plaats, de oude database wordt vervangen voor de nieuwe
- De oude wordt nog achtergehouden voor een eventuele rollback
- De oude database blijft bestaan omdat niemand hem opruimt., immers gezamelijke verantwoording, is geen verantwoording. Iedereen denkt namelijk, als ik hem verwijdert, misschien gaat er dan toch iets stuk..

Oftewel begin niet gelijk te schreeuwen, het kan jou ook net zo goed overkomen ..

[gitaarwerk]

Wat ik een kwalijke zaak vind is dat de hacker goodwill toont door de juiste kanalen te vinden en aantoont dat er fouten zijn; voor de provider om op te lossen. In plaats hiervan starten ze een rechtzaak tegen hem en overdrijft men alles. Ipv gaten dichten, de hacker bedanken voor de info en verde gaan,... Maar nee. Simpel bellen werkt niet, omdat zulke providers alleen maar via protocol handelen (om zo die kosten te drukken).

Tja,...

[bigfoot1942]

Dan verschillen we hierover redelijk van mening als het gaat om 'hacker die goodwill toont'.
Ik heb niet het idee dat mijn data in handen is van een erg integer persoon als deze de hack bekend maakt bij de concurrent. Lijkt me toch niet te overziene fout voor een 'white hat' hacker, hiermee is je hoed al minstens lichtgrijs.

[Rho d Berth]

Het is een kwestie van tijd dat alle onze gegevens worden gehackt en openbaar worden. Big Brother is niet de overheid, maar we zijn het met z'n allen. Alles wordt straks gefilmd, gefotografeerd, opgeslagen. En informatie komt vanzelf een keertje vrij.

Kunnen we allemaal boos over doen, en proberen tegen te houden, lukt toch niet. Accepteer het en gedraag je zo dat wanneer jouw gegevens op straat komen te liggen in de toekomst je je niet hoeft te schamen.

En het lijkt mij dat de overheid wetgeving moet intrekken die partijen verplicht gegevens te bewaren. Wat niet bewaart wordt kan ook niet worden gestolen.

[Verwijderd]

Dus pas wanneer er wat gebeurd is gaan ze op fouten scannen? Volgens mij moet er een wetgeving komen dat bedrijven die gehacked worden een dikke boete krijgen gebaseerd op hoe moeilijk de hack was.

[r2504]

Fouten kunnen altijd gebeuren... maar het blijft me verbazen wat voor data bedrijven op publieke webservers hebben staan. Dergelijke 'verkeersgegevens' hoeven volgens mij absoluut niet op zo'n webserver te staan... maar op de backend databases van een bedrijf.