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)
Wij doen er alles aan om dit in de toekomst te voorkomen. Deden ze dat maar altijd dan gebeuren dit soort dingen ook niet.
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"?
En hoe kun je door 1 mensenlijke fout in godsnaam 158 Databases "hacken"?
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.
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.
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.
Uitlezen van config bestand waar DB info in staat lijkt mij logischer,.
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.
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.
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.
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 ???
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 ???
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....
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....
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
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?
En daarmee is de kous af voor de provider, ze hebben er toch alles aan gedaan om het te voorkomen in de toekoms?
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.
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.
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....
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....
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!
Want daarmee kunnen geen menselijke fouten worden gemaakt?
Ik durf op basis van de naam van deze organisatie (hint: ASP) te voorspellen dat ze vrij weinig Linux-servers hebben draaien.
Verder worden applicatiefouten voor zover ik kan zien niet echt afgevangen door SELinux, dat OS zorgt er alleen voor dat een applicatie niet ineens iets heel anders gaat doen dan waarvoor 'ie is geregistreerd. Dan kun je wel zeggen dat je webapplicatie alleen maar uit een bepaalde map mag lezen en dat 'ie een databaseverbinding mag maken, maar als je dan door een configuratiefout (er wordt als te veel mogende user verbonden) en een applicatiefout (je kunt ook data selecteren uit andere databases) alsnog data lekt, heb je alsnog pech.
En nee, ik heb geen idee hoe SELinux precies werkt, dus mijn reactie is even onderbouwd als de jouwe.
Verder worden applicatiefouten voor zover ik kan zien niet echt afgevangen door SELinux, dat OS zorgt er alleen voor dat een applicatie niet ineens iets heel anders gaat doen dan waarvoor 'ie is geregistreerd. Dan kun je wel zeggen dat je webapplicatie alleen maar uit een bepaalde map mag lezen en dat 'ie een databaseverbinding mag maken, maar als je dan door een configuratiefout (er wordt als te veel mogende user verbonden) en een applicatiefout (je kunt ook data selecteren uit andere databases) alsnog data lekt, heb je alsnog pech.
En nee, ik heb geen idee hoe SELinux precies werkt, dus mijn reactie is even onderbouwd als de jouwe.
Ja, goed idee. Want met SELinux ben je niet meer vatbaar voor slq injections, man-in-the-middle attacks, ddos aanvallen, dom mensenlijk gedrag en alle andere dingen die fout kunnen gaan.
Dit soort hacks wordt echt niet veroorzaakt door een brak host os maar door stomme fouten in de implementatie en uitrol van (web)applicaties. Zelfs het veiligste OS in de wereld gaat jou niet tegenhouden als je een simpele webapp bakt die admin rechten heeft op de database en vatbaar is voor sql injecties bv.
Dit soort hacks wordt echt niet veroorzaakt door een brak host os maar door stomme fouten in de implementatie en uitrol van (web)applicaties. Zelfs het veiligste OS in de wereld gaat jou niet tegenhouden als je een simpele webapp bakt die admin rechten heeft op de database en vatbaar is voor sql injecties bv.
Geloven ze het zelf ook? Zaterdag ontdekt, zondag auditje gehad en gisteren alles gefixed?Aspider heeft Fox-IT een scan laten uitvoeren en daarbij kwamen meer lekken aan het licht. Die zijn onmiddellijk gedicht, zo zegt Aspider.
dat kan wel, DMZ aan oh laten we dat maar uit zetten 
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.Geloven ze het zelf ook? Zaterdag ontdekt, zondag auditje gehad en gisteren alles gefixed?
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.
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.
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."Je zou denken dat ze de data-verkeersgegevens ergens 'offline' bewaren en alleen beschikbaar maken op het moment van aanvraag door recherche."
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.
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.
Het is gewoon wachten op hackers die al deze informatie gaan verzamelen en online zetten.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.
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 dinsdag 10 juli 2012 09:50]
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.
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.
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.
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 dinsdag 10 juli 2012 10:55]
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.
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.
Zeker iets als skip-grant-tables vergeten weer weg te halen o.i.d.
[Reactie gewijzigd door Sfynx op dinsdag 10 juli 2012 10:05]
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.
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?
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?
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.
Als je Frans Bauer rondsnuffelde kwam je vroeger of later bij Simpel uit, hoe verzinnen ze het... 
Op dit item kan niet meer gereageerd worden.
Populair: Tablets Samsung Websites en communities Mobiele telefoons Google Apple Microsoft Sony Games Politiek en recht
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
