Channels
Powered by True

Planet zet per ongeluk klantgegevens bij abonnee online

Door Wilbert de Vries, maandag 14 januari 2008 15:16
Submitter: soulrider, views: 29.678

Planet heeft per ongeluk een archiefbestand met de gegevens van enkele tienduizenden klanten in de home-directory van een site van een klant geplaatst. De provider heeft inmiddels de procedures aangescherpt om herhaling te voorkomen.

De bewuste Planet-klant ontdekte het zip-bestand van ruim 239MB vlak na de kerstdagen in zijn home-directory. Na het uitpakken bleek het 2GB aan klantgegevens van Planet te betreffen, waaronder klantnummers, ip-adressen, namen, mail-aliassen en versleutelde wachtwoorden. Ook gaf het bestand, met daarin 2,5 miljoen entry's, inzicht in welke klanten diensten als spam- en virusfilters afnemen, zo blijkt uit het relaas van de klant op GoT.

KPN, het moederbedrijf van Planet, erkent bij monde van woordvoerster Eke Wolters dat er een fout is gemaakt. "Een van de systeembeheerders heeft tijdens het maken van een backup een tikfout gemaakt waardoor het bestand op de verkeerde plek werd opgeslagen."

"Een slordige fout", geeft Wolters toe. "Onze procedures zijn inmiddels aangescherpt waardoor herhaling moet worden voorkomen. Deze manier van backuppen is per direct verboden."

Volgende: Epic Games gaat uitbreiden 15:48
Vorige in Pro: LG.Philips boekt recordkwartaal 15:11
Vorige: Jowood brengt Sam & Max en Agatha Christie naar de Wii 14:28

Reacties

«  1  2  3  4  5  »


Dan zal hij er nog niks aan hebben want het is niet op een legale manier verkregen.

"Deze manier van backuppen is per direct verboden."

Hoe lang gebruikten ze die manier dan? Gebruikten ze altijd de websites van klanten voor het backuppen? Ik vind het schokkend hoe makkelijk de gegevens van al die gebruikers online kwamen...

[Reactie gewijzigd door Devilpuppet]


nee, ze gebruikten niet altijd de websites van klanten. Nooit eigenlijk (althans dat lijkt me stug).
Echter, door een typefout kwam het wel op de website van een klant.

Handig, je homedirectories gewoon tussen de website mappen van je klanten pleuren...
Gelooft iemand ook dat de homedirectories van het perosneel zo tussen de webfolders van de klanten staan zodat je je homedirs op de langzame webservers hebt draaien, of je websites gevoed wordn vanaf je interne fileservers?

Ben ik de enige die dat het punt "dapper" allang voorbij vind en meer aan "roekeloos" begint te denken? Ik kan het eigenlijk niet eens serieus nemen, die melding, eerlijk gezegd geloof ik niet dat iemand zo stom z'n netwerk inricht.

[Reactie gewijzigd door KnetterGek]


Weet jij door het gegeven 'typfout' hoe het netwerk in elkaar zit of hoe zelfs de directorystructuur op de pc van de backupper eruit ziet? De persoon in kwestie kan toch twee externe lokaties lokaal gemount hebben, en bij het maken van de backup net de foute externe lokatie opgeven?

Het is zeker een slordige fout, maar om nou te concluderen dat lokaties fout gekozen zijn, of zelfs het hele netwerk stom ingericht is aan de hand van een typfout gaat nogal ver.

waar lees jij dat de personeel en klanten mappen op dezelfde server draaien ?

1 cijfer of letter fout in een shortcut en je zit plots op een gans andere plaats gegevens weg te schrijven.

bvb
favorites:
- Data store (backup)
- Data Technologies Inc (klant)

ALT+a, D enter
ipv
ALT+a, D, D enter

of bvb naar het verkeerde openstaande venster een filetje verslepen omdat je met 2 of meer dingen tegelijkertijd bezig bent, ...

Toegegeven: het is een slordige fout, maar ik durf er m'n hand niet voor in het vuur te steken dat jij nog nooit per ongeluk een cijfertje fout hebt getypt in een IP-adres of shortcut. gezien je job/studie lijkt het me straf dat je nog nooit een fout (van een ander) bent tegengekomen ;)

en wat moet een medewerker van een helpdesk met een favorite van een www folder van een klant ??? of met een mount van diezelfde folder ?
Dit is niet een klein stom foutje, dit is een oerdomme fout die nooit had mogen gebeuren en nooit gebeurd had kunnen zijn als ze bv die 2 dingen op goede manier hadden gescheiden

Het lijkt me dat er iets meer aan de hand is. Iemand exporteert de klanten database, zipt hem en sleept hem naar z'n webspace (en kiest de verkeerde). Dat is geen backuppen, dat is stelen.

[Reactie gewijzigd door MrAngry]


Dat slaat nergens op,

Exporteren doe je meestal als je iets wilt back-uppen dus dat staat vast. Vervolgens lees ik dat een 2GB file gezipt wordt naar een 239MB file dus lijkt me logisch dat ze dat doen aangezien dat veel tijd (kopieren), eventueel brandwerk en geld (loonuren, totale opslag) scheelt. Dat die mensen een tikfoutje maken oke, hoort zeker niet, maar wat zou iemand met 10000end klantenbestanden willen waar ongeveer 5% echt een interessant abbonoment hebben? Tenslotte zijn het net zo goed mensen als wij en er is niemand die perfect is, laat staan superman, tot nu toe is er nog nergens schade dus van geluk mag je ook wel spreken..

Ik vind dat er van een mug een olifant wordt gemaakt. Planet weet zelf precies welke klanten er onder vallen en als die problemen vertonen gaan ze zeker niet moeilijk doen.

Ik vind het behoorlijk naief om te denken dat ze zo'n database handmatig backuppen en dan ook nog eens op een webserver. Logischer lijkt me dat een van de medewerkers van Planet geen schoon geweten heeft. Dat gezegd hebbende vind ik zeker niet dat er van een mug een olifant wordt gemaakt.

Het gaat om 2,5 miljoen email adressen en wachtwoorden. Nou weet ik niet wat jij in je mail hebt staan, maar als je toegang hebt tot mijn mail account kan je me financieel redelijk slopen denk ik. Daarnaast geeft hetzelfde wachtwoord wellicht ook toegang tot de webserver en kan je dus helemaal los met gegevens jatten van andere bedrijven.
Uiteraard moet je dan wel eerst het wachtwoord uit de database vissen, die zullen we gehashed zijn, maar dat is wel te doen.

Ik vind het daarom helemaal geen mug en het is echt een schande dat dit kon gebeuren.

Het gaat helemaal niet om 2.5 miljoen gebruikers maar enekele 10000en, dat scheel heel veel ;)

Hieruit kan je de conclusie trekken dat ze of

1) geen gescheiden systemen hebben voor de klant en voor de eigen organisatie

of

2) De "systeembeheerder" in kwestie hele andere bedoelingen had met het maken van een "backup".

Lekker zwart/wit. Het kan echt zijn dat ze gewoon een hele slechte/goedkope manier hebben van backups maken. Het is dus niet of/of. Maar de punten die je noemt zijn wel de eerste en meest waarschijnlijke.

Ooit eens gedacht aan een netwerk datastorage server, die kan door meerdere servers tegelijk aangelijk benaderd worden voor je data.

Maar ook dan kan je een 2de datastorage server apart neerzetten voor je eigen bedrijf ja...

In plaats van op de X:\backups werd de meuk op X:\website\klantx gezet :X
Het lijkt me eerder een geval van even snel wat dingen verplaatsen want onze backuptapes zitten vol. Zoiets kan je niet met een tiepvaud voor elkaar krijgen :P Wat hier verteld is maar de halve waarheid.

Onder linux kunnen vele disks in dezelfde directory uitkomen.
Zo staan waarschijnlijk alle klanten onder /home/<klantnaam>
Nou wordt home ook vaak gebruikt door backupprogramma's e.d. en kan dus een backup op /home/backup terecht komen.
Waarschijnlijk is er een typfout gemaakt, zodat dit /home/balckup of /bakcup is geworden. Nog steeds slordig, maar het kan gebeuren. (Fouten maken is nog steeds menselijk)

Dan nog, ik zou mijn klantenbestanden niet op dezelfde (storage) server opslaan als de (publieke) webserver.

"Een van de systeembeheerders heeft tijdens het maken van een backup een tikfout gemaakt waardoor het bestand op de verkeerde plek werd opgeslagen."
Vaag verhaal. Als het nou bij het terugzetten van een backup zou zijn gebeurd, geloof ik het wel. Maar bij het maken van een backup...? :?

Tjah, ik neem ook aan dat je backups maakt door een geautomatiseerd process...

Handmatig dingen backup'en gebeurt nogal vaak onregelmatig of wordt zelfs vergeten.
Planet, je hebt je zaakjes erg slecht op orde als dit soort dingen gebeurt...
Backups zijn gewoon erg erg belangrijk om te hebben.

Hoezo vaag verhaal? Ik ken tientallen pakketten die ingebouwde backup/restore-mogelijkheden hebben waarbij de padnamen volledig dynamisch in te regelen zijn (al dan niet door de menselijke factor).

Heel simpel eigenlijk.

Stel ze maken heel netjes, maar basic een backup van de /home waar alle user data op staat. Erg netjes dat ze die moeite nemen om userdata te backuppen. Nou hebben ze als enige 'extra' de DB backup. mysql -dump | zip backup.zip of zo denk dan.

Dus ja, nu heb je 2 opties, of je zet dat bestand ergens neer en doet daar een 2de backup serie voor, of je gooit het in de /home/backupuser en laat het op die manier automatish mee back uppen.

Netjes is anders, maar mss is het makkelijker/handiger/verzin maar iets. Laksheid waarschijnlijk, maar goed, tis einde van de wereld niet. Wat ik niet helemaal begrijp is die 'tikfout'. Het genereren van je database dump laat je toch wel automatish gebeuren? Oth als hij net het scrptje aan het bewerken was om een andere backupuser dir te pakken; danwel dit een tijdelijk iets was omdat hun apparte systeem problemen had en de admin niet wilde riskeren dat de db niet geback upped werd ...

Hoe je het went of keert vele onschuldige mogelijkheden dat echt en oprecht gewoon een 'foutje' was. De gevolgen uiteraard wat erger dan gehoopt natuurlijk.

Stel je moet iets aanpassen in de database. Ga je er dan blind van uit dat de backup van die nacht goed is gegaan, of maak je voor de zekerheid even snel een dump.
Ik in iedergeval het laatste. Wil er zeker van zijn dat ik een backup heb. Waarschijnlijk is bij het intypen iets mis gegaan.

SQLDUMP ~jans (klant)
ipv
SQLDUMP ~jan (systeembeerder)

Dan is er toch echt iets fout gegaan bij het uitdelen van beheerderaccounts: als die qua naam zoveel (kunnen) lijken op normale users is dat per definitie risicovol.

En de argeloze gebruiker maar afvragen waarom hij ineens zoveel spam krijgt...

Zo gaat dat dus. Dit geval komt dan in het nieuws, maar wat als er een minder goedwillende klant de gegevens in handen had gekregen?

Dat KPN of Planet vrijwel niet reageren via de normale weg, komt omdat ze alle contact met de "boze" klant zoveel mogelijk willen vermijden. Nu pakt dat dus in hun nadeel uit; de helpdesk is er alleen om zoveel mogelijk klanten af te schepen.

[Reactie gewijzigd door Arnout]


als extra spam krijgen het enige gevolg is van zo'n blunder mag je nog blij zijn!

Als je al extra gespamd wordt, vraag je je dan niet eens af of ze nog wel meer hebben vrijgegeven?? Emailadres valt mijns inziens ook onder persoonsgegevens...

Ach ja het is erg zuur dat ze er helemaal niets mee deden aldus de thread op tweakers (ik heb hem gevolgd en erin gepost. Het feit an sich is nog niet zo erg, maar meer het feit dat ze er vervolgens geen actie op wilden ondernemen en alles afschoven maakt het erg.
Vergissen is menselijk, maar zeker een ISP moet wel willen+kunnen handelen om de eigen fouten op te lossen :). Zeker mbt privacy.

Wat was een adequate oplossing geweest? Alle getroffen klanten een nieuwe naam en e-mail adres geven? :)

Ik zie het al voor me:

Geachte meneer Lapalazala,

Door een storing in ons systeem is uw naam en e-mail adres in verkeerde handen gevallen. Om uw privacy te beschermen, zijn we genoodzaakt u andere persoonsgegevens te verstrekken.

Uw nieuwe naam is de heer Frans de Vries#71.
Uw e-mailadres wordt F.De.Vries#71@planet.nl

Excuses voor het ongemak.
Planet Klantenservice

Ze hadden op zijn minst het betreffende bestand dat op die homepage stond onmiddelijk kunnen wissen in plaats van twee weken niets doen...

Ik wil dat ook helemaal niet goedpraten. Het is duidelijk dat planet steken heeft laten vallen door eerst een grove fout te maken en vervolgens niet goed en snel te reageren.

Ik wilde alleen aangeven dat sommige fouten onherstelbaar zijn. Gelekte info kan je niet ontlekken. Wachtwoorden e.d. kunnen aangepast worden, maar 'echte' gegevens niet.
(en grappig zijn, dat wou ik ook)

De klant had het bestand reeds verwijderd van de hompage vlak na het gedownload te hebben.

En is dit bestand nu ook uitgelekt naar het net? of is de ontvanger van dit bestand zo netjes geweest om het zelf te verwijderen?

Volgens de thread op tweakers, heeft hij het niet gepubliceerd, dus ik denk het niet . Alhoewel niemand natuurlijk zeker weet dat een derde het ook niet van zijn homepage heeft gehaald....
Iig heb ik niet het idee dat de 'ontdekker' de zaak op internet heeft gedropt :) (gelukkig maar,hulde).

Wat denk je nu zelf?

Denk je dat hij én het bestand uitlekt naar het internet én hij ook meldt in bezit te zijn ervan? Dan graaf je je eigen graf natuurlijk.

Ook ik heb de thread gevolgd op het forum en het antwoord is 'nee'.

Dus? Anderen kunnen het ook gedownload hebben hoor ;)

Ah op die fiets. Ja dat zou kunnen, maar ik dacht dat met uitlekken 'opzet' bedoeld werd. :)

En van opzettelijk uitlekken is bij de beste man géén sprake.

Planet kan dit heel makkelijk uitzoeken door middel van hun apache (of welke webserver dan ook) logs door te zoeken op bestandsnaam.zip... Mocht het daar in voorkomen, behalve dan met de ontdekker, dan zijn ze flink de pineut. Anders hebben ze flink mazzel dat er gelukking nog steeds eerlijke mensen in deze wereld zijn.

Lees het linkje naar het forum en je weet meteen het antwoord :)

De SG is niet voor iedereen toegankelijk ;) Dus toch wel handig om het hier te vermelden.

Ik vraag mij inderdaad af hoe die gegevens publiek zijn geworden.

Het voorbeeld heb ik al eerder op GoT gegeven maar hier nog maar een keer:

Waarom gaat een beheerder MET DE HAND een backup maken om deze dan maar op zijn eigen webspace te zetten:

/www/Pietjens
Echter maakt hij een typfout en komt het in
/www/Pietjes
terecht. Ben ik de enige die dit niet geloof? Of KPN is erg slordig of deze beheerder wou bewust deze gegevens stelen.

Verder vraag ik mij af of dit contract breuk is van de kant van Planet. Ik zou namelijk graag willen overstappen. Ik wou dit al langer maar nu zeker.

Omdat een backup niet altijd geautomatiseerd kan/hoeft/moet!

Als ik nu een backup van een SQL-database wil, wil ik niet afhankelijk zijn van snapshots of scheduled backups of andere jobs die andere servers/software. Dan kies ik voor de optie "Backup Database" en daar kan elke Jan Joker een tikfout in maken naar welke directory dat gaat.

Wel mooi trouwens dat de helft van de commentaren valt over "hoe kan dat nou" maar zelf waarschijnlijk geen enkele manier/vorm van backup zelf hebben draaien.

Als ik handmatig een backup van een database wil hebben dan roep ik gewoon handmatig het backup scripts aan.

> en daar kan elke Jan Joker een tikfout in maken naar welke directory dat gaat.

Als een tikfout zulke grote gevolgen heeft, moet je toch echt je procedures aanpassen zodat simpele tikfoutjes niet meer dit soort dingen tot gevolg hebben.
Bovendien zouden dit soort backups toch encrypted moeten zijn.

[Reactie gewijzigd door Olaf van der Spek]


Als ik handmatig een backup van een database wil hebben dan roep ik gewoon handmatig het backup scripts aan.

Als een tikfout zulke grote gevolgen heeft, moet je toch echt je procedures aanpassen zodat simpele tikfoutjes niet meer dit soort dingen tot gevolg hebben.
Over die tikfout kunnen we het eens zijn; dat is procedureel anders in te regelen of te controleren.

Over de backup-job heb ik nog wel vraagtekens/opmerkingen. Niet elk backup-pakket snapt/ziet dat je iets van een live server wil backuppen. Hierdoor kunnen CPU-cycles verkeerd worden uitgedeeld en benadeel je de users die op dat moment van de server iets opvragen. Middels bepaalde handmatige akties kan je prioriteiten soms/anders afvangen om de impact op sommige momenten te minimaliseren.

Als ik handmatig een backup van een database wil hebben dan roep ik gewoon handmatig het backup scripts aan.
Een typfout in de aanroep (parameter?) een typfout in het script? Het kan allemaal...

-Ik zie niet in dat je je backups op dezelfde server zet als de webspaces van je klanten.
-Ik zie ook niet gebeuren dat dit door een "typfout" kan gebeuren. Ik denk niet dat de directory van je backups en je webspaces zo hard op elkaar lijken dat ze door een typfout door elkaar gehaald worden.

Ja maar zet je die backup dan ook in een publiek toegankelijke webspace? Of die van die gebruiker was of niet, een voor een webserver toegankelijke directory is natuurlijk niet de plaats voor een backup met vertrouwelijke klantgegevens.

Edit: Heb de reactie een beetje ingekort want hetzelfde is al een paar keer gezegd.

[Reactie gewijzigd door GekkePrutser]


In vredesnaam, waarom zou je de voorkeur hebben tot handmatige backups ipv geautomatiseerde? Juist bij een SQL server wil je een geautomatiseerd proces, omdat daar de data snel veranderd wil je betrouwbare backups en daarom wil je dus niet afhankelijk zijn van een systeembeheerder die fouten maakt (fouten maken hoort nu eenmaal bij het mens-zijn).

Ik sluit mij eigenlijk aan bij de groep "Hoe kan dat nou" zeggers, hoewel ik bang ben dat Planet zeker niet het enige bedrijf is met (blijkbaar) een zwak security beleid, helaas :(
Wel mooi trouwens dat de helft van de commentaren valt over "hoe kan dat nou" maar zelf waarschijnlijk geen enkele manier/vorm van backup zelf hebben draaien.
Dat zit wel goed hier.. ieder uur een backup naar m'n thuisserver. Dat werkt een stuk beter dan iedere week een cdtje branden kan ik je verzekeren ;)

Helemaal mee eens, ik zit er ook sterk over na te denken om te gaan wieberen.

Uit eigen ervaring weet ik dat ze uiterst lomp met klantengegevens omgaan.
Al is het maar mijn emailadres, die tot voor kort bij niemand, behalve mij en de provider bekend was, in het rond strooien zodat mijn mailbox sinds een halfjaar vol loopt met spam.

Hulde...

Je weet toch wel dat spammers ook spammen naar random mailadressen zonder dat ze weten of die adressen bestaan? Dat jij spam krijgt zegt dus absoluut niets over de provider.

Ik verwacht eerder een typefout in de geest van :

cp backupfile ~backupdir
ipv
cp backupfile /backupdir

waarbij de file dus in de homedirectory van de gebruiker backupdir terecht komt.
(Wat was eigenlijk de gebruikersnaam waar de file naartoe gekopieerd was?)

[Reactie gewijzigd door borkhuis]


heel goed mogelijk ja, and de gebruiker een naam zoals backup zou hebben gehad.
nou hebben planet-abonnees intern namen als abc12345 dus dan krijg je zo iets niet zo snel. maar stel dat de systeembeheerder het handig vond om de backup te zetten in iets met de datum er in, en dat hij dec281410 een goede naam vond voor de backup van 28 december 14:10 uur. en dat dat nou net de naam van een gebruiker was.
blijft stom, maar eht zou kunnen

waarom wordt een backup van die gegevens zowiezo riching een webserver gebackupped.

moet toch zeker wel een HEEL erg groote typfout zijn. Ik heb best wel wat moeite met dit te geloven eigenlijk :-/

Waarschijnlijk worden ze gebackupd naar een NAS of een SAN. De backup wordt waarschijnlijk weg geschreven naar een plek als /home/Pietjes. Wanneer er per ongeluk in een verkeerde directory terecht komt kan het gebeuren dat het bestand beschikbaar wordt voor de buiten wereld.

Dit neemt niet weg dat Planet eens kritisch mag denken over de lange termijnsbeveiliging, zoals het backuppen van gegevens ook fysiek te scheiden van de user data.

Of men heeft redelijk snel dit moeten doen, typt een paar letters. drukt op tab, krijgt de aanvulling en drukt op enter. Niet oplettende dat de verkeerde naam er stond... Maar alsnog erg slordig ja.
«  1  2  3  4  5  »

Op dit item kan niet meer gereageerd worden.

Volgende: Epic Games gaat uitbreiden 15:48
Vorige in Pro: LG.Philips boekt recordkwartaal 15:11
Vorige: Jowood brengt Sam & Max en Agatha Christie naar de Wii 14:28

Powered by True
RSS VNU Media logo
© 1998 - 2008 Tweakers.net - Alle rechten voorbehouden
Uitgever van: