Lek bij Hello Kitty-fansite gedicht

Sanrio, de eigenaar van Hello Kitty, zegt het veiligheidslek dat leidde tot een server-hack, gedicht te hebben. De database met meer dan 3,3 miljoen gebruikers van sanriotown.com, de officiële fansite van onder meer Hello Kitty, werd online gezet door hackers.

Sanrio Digital zegt dat het probleem intern onderzocht wordt en dat het lek gedicht is. Ook zouden verschillende nieuwe beveiligingsmaatregelen op de servers zijn gezet. Volgens Sanrio is er geen andere informatie gestolen of bekendgemaakt. Ook zou er geen creditcard- of andere betalingsinformatie zijn buitgemaakt. Wachtwoorden van betalingsinformatie zouden wel veilig zijn opgeslagen, meldt het bedrijf aan NBC.

De buitgemaakte database bevat volgens eerdere berichten onder andere namen, geboortedata, geslacht, land van herkomst en e-mailadressen. Omdat het om Hello Kitty-liefhebbers gaat, zullen er veel accounts van kinderen tussen zitten. De sha-1-wachtwoordhashes liggen ook op straat en waren niet gesalt, samen met de eventuele hints en hun antwoorden.

Niet alleen de site achter sanriotown.com gebruikt de database. Ook andere sites van het Japanse bedrijf achter Hello Kitty en andere figuren gebruiken dezelfde database. Hoe lang de informatie al online staat, is niet bekend. De oudste datum die te achterhalen is, is van 22 november 2015.

Reacties (40)

[KevinT]

Tja, helaas pindakaas. Maar zijn ze niet te laat?

[Slavy]

Dat is een mosterd na de maaltijd opmerking. Misschien dat ze bij Hello Kitty de beveiliging hadden kunnen verbeteren (mijn kennis van DB's is niet al te sterk) maar het goede is dat ze wel rap hebben gereageerd op de problemen en hier hopelijk ook een les uit hebben gehaald.

[svenslootweg]

Ja, dat hadden ze zeker kunnen verbeteren. Het gaat hoogstwaarschijnlijk namelijk gewoon om een MongoDB server die ze zonder wachtwoord publiek op het internet hebben laten staan - iedereen had er dus mee kunnen verbinden en alle data kunnen dumpen, zonder enige vorm van authenticatie. Er is ook geen manier om te weten of dat wel of niet gebeurd is.

Dit heeft dus helemaal niets met een "foutje" te maken, en alles met grove nalatigheid.

Hier meer.

[Reactie gewijzigd door svenslootweg op 23 juli 2024 10:47]

[gimbal]

Ongelofelijk.

Waar de misser intern ook zit, het is wel duidelijk dat er ook geen audits gedaan worden door externe security instanties, want die hadden dat al in de eerste testrun ontdekt. Er is duidelijk heel veel niet in orde qua security bij die club.

[svenslootweg]

Inderdaad.

Ik vind sowieso dat de bewijslast voor beveiligingslekken wel eens omgedraaid mag worden, aangezien het overgrote deel(!) door dit soort idiote nalatigheid veroorzaakt wordt. In plaats van een aanname dat het een "foutje" was, zouden we eigenlijk een aanname moeten hebben dat het nalatigheid was, tenzij het bedrijf anders aan kan tonen.

Ik merk het ook wel als ik met niet-technische mensen over beveiliging praat - de heersende gedachte is "ja maar, niets is perfect, dus als iets gehackt wordt, dan kan dat nou eenmaal gebeuren" - en dat is zeer, zeer zorgwekkend. De leugenachtige "damage control"-marketing van gehackte bedrijven heeft duidelijk zijn vruchten afgeworpen.

[ArcticLight]

Uit het artikel:

De sha-1-wachtwoordhashes liggen ook op straat en waren niet gesalt, samen met de eventuele hints en hun antwoorden.

Dit is op z'n zachtst gezegd slordig te noemen. Ik mag hopen dat ze hier van geleerd hebben, maar het had eigenlijk al niet eens zo moeten gebeuren, gewoon waardeloos beveiligd.

[geerttttt]

Maar, SHA1 hashes kun je niet terugtransformeren naar normale passwords, althans niet eenvoudig toch? (alleen met bruteforce?).

Of waren de daadwerkelijke passwords ook in de DB?

[Stevie-P]

Sha1 is tegenwoordig een heel snelle bewerking. Dus je kan inderdaad brute force alle mogelijke wachtwoorden gaan sha1en en binnen de kortste tijd heb je een heleboel wachtwoorden die je kunt koppelen aan gebruikersnaam/email adres.

[Glodenox]

Als er geen salt toegepast werd (die in essentie het woord dat geëncrypteerd werd een pak langer maakt) kan je vrij gemakkelijk een rainbow table opstellen/downloaden van alle mogelijke opties en zo de beveiliging omkeren.

EDIT: ter verduidelijking: rainbow table: databank met de velden woord en SHA1-hash. Als je alle woorden (tot een bepaalde lengte wegens plaatsbeperkingen) in deze tabel hebt staan kan je in je databank zoeken op de hash en kijken welk woord hier tegenover staat.

Stel dat men aan alle wachtwoorden eenzelfde voldoende grote salt had toegevoegd: dan zou men om efficiënt te zijn een eigen rainbow table moeten opstellen waarbij telkens de salt toegevoegd wordt bij elke poging. Dit duurt al een stuk langer, maar eenmaal men de tabel voldoende groot heeft gemaakt wordt het kraken van de meeste wachtwoorden triviaal. Om dan nog maar te zwijgen van het aantal hints (die ook in de databank zaten) die gewoon gelijk zijn aan het wachtwoord (mensen zijn gemakzuchtig).

Stel dat men voor elk wachtwoord een aparte salt had toegevoegd (moet dan ook in de databank opgeslagen worden): dan moet men per wachtwoord inderdaad gaan bruteforcen. Men weet wel welke salt men moet toevoegen achter het woord dat men gaat proberen te raden, maar men moet voor elk record alle mogelijke woorden aflopen, wat ondoenbaar is.
Een rainbow table maken heeft dan ook geen zin aangezien het aantal mogelijkheden zo gigantisch is dat men nooit voldoende plaats heeft om alle mogelijkheden op te slagen. Een hash collision is ook geen probleem aangezien men dan het origineel wachtwoord nog altijd niet weet. Andere sites zullen wel andere hashes gebruiken, dus de match die je dan gevonden hebt zal elders nog altijd niet werken. Ook is er geen risico van "1 wachtwoord gekraakt = alle zelfde wachtwoorden ook gevonden". Zelfs het wachtwoord "wachtwoord" zou in deze opstelling vrij lang duren om te ontcijferen.

[Reactie gewijzigd door Glodenox op 23 juli 2024 10:47]

[Bubbles]

Het niet kunnen terug transformeren van SHA1 klopt, maar dat geldt voor ieder hashing-algortime, waaronder ook MD5 (al helemaal niet veilig voor gebruik met wachtwoorden ). Dat is het hele idee ervan: controle van input wordt gedaan door die input op dezelfde manier te hashen en de hashes met elkaar te vergelijken. Dit in tegenstelling tot encryptiealgoritmes, die een decryptiesleutel hebben om zo de originele input weer terug te kunnen krijgen.

SHA1 is echter al een hele tijd niet meer 'veilig' genoeg: in 2005 werden er al vraagtekens bij gezet en in 2010 besloot het NIST dat overheidsinstanties moesten overstappen op SHA2 omdat die het niet meer veilig genoeg achtten. Datzelfde is nu ook al aan het gebeuren met SHA2. De SHA3-standaard is net dit jaar vrijgegeven.

Dat Sanrio Digital nu nog SHA1 gebruikte, en bovendien de wachtwoorden niet eerst salt voordat ze werden gehashed, is ronduit slordig te noemen.

[Reactie gewijzigd door Bubbles op 23 juli 2024 10:47]

[KevinT]

Als een site persoonlijke informatie van jou in bezit heeft verwacht jij ook dat zij hun zaakjes op orde hebben. Ik vind persoonlijk dat je ze dit echt wel kwalijk kan nemen hoor.

[elmuerte]

Als een site persoonlijke informatie van jou in bezit heeft verwacht jij ook dat zij hun zaakjes op orde hebben.

Daar gaat het dus al fout. Verwacht nooit dat een andere beter met je persoonlijk informatie om kan gaan dan jij. De grote bedrijven en overheden hebben al moeite met persoonlijk informatie geheim te houden. Waarom zouden kleine bedrijven, en websites dat wel kunnen.

[Deralte]

Tja, imo slechts ten dele. Alles is te hacken, geen idee welk lek hier misbruikt werd, maar de schuld ligt niet noodzakelijk bij hen.

[bwerg]

"Alles is te hacken" is een dooddoener van jewelste. Dat is een leuk excuus voor als een lek wordt veroorzaakt door third party software die iedereen veilig achtte. Maar je mag van een beheerder toch wel verwachten dat ze de algemeen bekende "best practices" toch gewoon kennen en toepassen.

Dat is alsof je fietsenmaker je een fiets verkoopt waarvan het wiel loszit, en als je op je smoeltje gaat reageert je fietsenmaker met "tja, alles kan stuk".

Niet dat bekend is wat het lek nou is, maar als je je data niet netjes opslaat heb je de schijn al behoorlijk tegen.

[Reactie gewijzigd door bwerg op 23 juli 2024 10:47]

[Blokker_1999]

In de tijd dat deze site gemaakt werd, werden mogelijk wel degelijk goede beslissingen genomen. Daar kunnen wij niet over oordelen. Het feit dat wachtwoorden met sha-1 opgeslagen worden getuigt toch al van enige kennis (anders was het gewoon md5 geweest) maar het is goed mogelijk dat na het opleveren van de site er geen geld meer werd vrijgemaakt door het hogere management om deze te onderhouden, verbeteren met de tijd.

Zonder verder inzicht in de organisatie alsook hoe men is binnen geraakt is het onmogelijk om te oordelen over de bekwaamheid van de beheerders.

[PcDealer]

Onder best practices hoort ook onderhoud, een evaluaties. Als het inderdaad zo is dat de site in het jaar kruik online is gegaan en daarna zo is gebleven, is dat nalatigheid.

[Deralte]

Het is idd een dooddoener, maar zoals hieronder aangegeven waren de creditkaartgegevens en de paswoorden netjes versleuteld opgeslagen. De aard van de hack is voorlopig nog onbekend, dus, het is mogelijk slechts ten dele (of helemaal niet) de schuld van de beheerders. Zonder te weten hoe ze binnenkwamen kan je niemand iets verwijten.

[jimmy_dg]

Bij een hack ben je altijd te laat. En als een eventueel lek wel word gedicht bij dergelijk website hoor je dit uiteraard niet elke keer in het nieuws.

[koku]

Dat ze dit zeggen, geeft al aan hoe weinig ze begrijpen of ervan geleerd hebben...

The vulnerable data did not include credit card information or other payment information and passwords were securely encrypted.

Ze zouden iedereen een mail moeten sturen met de aanmoediging om het wachtwoord te wijzigen en ook op andere sites waar hetzelfde wachtwoord wordt gebruikt.

[Reactie gewijzigd door koku op 23 juli 2024 10:47]

[To_Tall]

Afhankelijk hoe je het interperteer..

Zij geven hiermee aan, de gebruikers van de site dat hun wachtwoorden en betaal informatie veilig was opgeslagen en niet zomaar bruikbaar is.

Aan de andere kant kan het zo zijn dat zij natuurlijk wel aan het achterhoofd aan het krabbelen zijn om dit in de toekomst te voorkomen. Gezien dit toch echt wel de geloofwaardigheid en betrouwbaarheid heeft geschaad. Waarbij dus klanten zullen/kunnen mislopen en daarbij dus ook inkomsten derving..

[Niemand_Anders]

Er zijn op het internet genoeg lijsten te vinden met de meest voorkomende wachtwoorden. Men hoeft alleen een sha1-hash van die wachtwoorden te maken en te kijken hoeveel van de password hashes overeenkomt met de wachtwoorden uit de database.

Een bijkomend nadeel voor Sanrio is dat Hello Kitty vooral kinderen als gebruikers heeft en die hebben over het algemeen eenvoudige wachtwoorden. Een hacker doet bijvoorbeeld een sha1 hash van 'password' maken. Dat levert de volgende hash op '5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8'. Vervolgens probeert hij accounts te vinden met deze hash en zal daarna op de website proberen in te loggen. Kan hij met success inloggen op de website, dan kan hij de volledige password lijst gaan hashen..

Het nadeel van een dergelijk offsite backup is dat daar vaak zowel de database als de website staan. Zelfs als men een site-hash of een user-based salt zou hebben gebruikt zou dit geen enkele toegevoegde waarde hebben gehad op de beveiliging. De site-salt had dan zeer waarschijnlijk ergens in een bestand op de webserver (backup) gestaan. De user-salt wordt vaak ook opgeslagen bij het user-record en die zou men dus ook hebben gehad. Dit geldt voor ELKE website! Als een website zonder gebruiken van third-party services de password hash kan genereren, dan kan de hacker dat ook als hij de beschikking heeft over de website code en de database. Daarom zie je dat forums steeds vaker gebruik maken van SSO (Single Sign On) van social media aanbieders zoals Google, Facebook, Twitter en Microsoft.. Een developer is geen security export en een security expert is vaak geen programmeur. Het gevolg is dat meer dan 85% van de website op het internet de user password op straat liggen als men toegang heeft tot de website code en een database dump.

Zelfs als de hacker slechts 50% van de wachtwoorden weet terug te halen, hebben we het nog steeds over 1,6 miljoen accounts..

[njitter]

iets met klok en klepel?

Een site-salt en user-salt hebben wel zeker nut. Met een site-salt moet je een site-specifieke rainbow table aanmaken. Met een user-salt kun je niet eens een rainbow table aanmaken.

Zie hier een simpel voorbeeld van het nut van een User Salt: http://www.learncfinaweek.com/week1/Secure_Password_Storage/

[Reactie gewijzigd door njitter op 23 juli 2024 10:47]

[svenslootweg]

SHA1 moet uberhaupt helemaal niet gebruikt worden - het is namelijk geen password hash. Scrypt en bcrypt zijn vandaag de dag de enige acceptabele opties voor password hashing.

[Gomez12]

Met een user-salt kun je niet eens een rainbow table aanmaken.

iets met klok en klepel?

Overal kan je een rainbow table van aanmaken, alleen het praktische nut van een rainbow-table voor een user-salt is bijna nul.
Want het aanmaken van een rainbow-table is gewoon simpelweg bruteforcen (maar dan eigenlijk nog traag, want je moet opeens ook schrijfacties gaan doen wat je met regulier brute-forcen niet hebt) terwijl je normale winst ongeveer 1 user is.

Wat echter wel zinnig is, ook met user-salts is een "mini"-rainbow table met daarin heel specifieke data. Zo hebben veel systemen een basis inlog genaamd admin, dat is veelal 1 van de eerste inlogs in het systeem, oftewel het id heeft een grote kans kleiner dan 100 te zijn en je hebt veel mensen die enkel user-salt gebruiken en site-salt vergeten en dan ook nog eens voor een user-salt een toch al bestaand iets als een id gebruiken.
En dan krijg je de grappige situatie dat je "meest belangrijke" account opeens het makkelijkste na te gaan is.

[Zezura]

Ja inderdaad. Met zijn sha-1 niet salted.

[Anoniem: 112442]

Ik heb er geen enkel probleem mee dat sites gehackt worden.

Maar waarom direct zo'n zaken openlijk publiceren. Dit ruikt voor mij naar afpersen.

Mij lijkt het logisch dat je
eerst daar de eigenaar van de site gaat
als dit niet werkt naar de autoriteiten
als dit niet werkt de media
als dit niet werkt dan pas publiceren.

Ik vind het dubbel ongepast als je data van kinderen publiceert.

Van mij mogen ze deze knakkers voor een lange tijd opsluiten.

Ik heb helemaal niets tegen hacken e ik vind dat bedrijven die hun zaakjes niet op orde hebben, echt in gebreken gebleven zijn, geen updates installeert etc, flink aangepakt moeten worden.
En dat een hacker die zich netjes gedraagt, niet zoals deze hackers, in geen geval vervolgd mag worden.

[Jack Flushell]

Ik heb er geen enkel probleem mee dat sites gehackt worden.

Dus jij hebt er ook geen probleem mee dat jouw wachtwoorden op straat konen te liggen? Want dat zeg je. Het hangt natuurlijk af van het doel van de hack.

[Anoniem: 112442]

[...]


Dus jij hebt er ook geen probleem mee dat jouw wachtwoorden op straat konen te liggen? Want dat zeg je. Het hangt natuurlijk af van het doel van de hack.

Nee dat zeg ik helemaal niet. je moet mijn verhaal even lezen.

Ik zeg namelijk dat hackers die wachtwoorden e.d. publiceren flink aangepakt moeten worden.
Hackers die dat niet doen en er voor zorgen dat het internet veiliger wordt, door samen te werken met het bedrijf en/of de autoriteiten, een bescherming en mogelijk een beloning moeten krijgen.

[blorf]

Hm, ze hebben een pop-up over de leeftijd er tussen gezet. Nu werkt een script dat automatisch accounts aanmaakt niet meer.

[biglia]

Fansite is nog licht uitgedrukt. Dit is de officiële website en geen hobbyproject. Dat is een verschil.

[Dj Neo Ziggy]

Dit spel is zo bizar! Mijn vrouw heeft Hello Kitty online twee jaar gespeeld!
Het zag er meer uit als een veredelde chatroom met toevallig wat dungeons en mobs.

[Jordymt]

Nu kun je je afvragen of consumenten die zich daar aanmelden wel goed zijn. Je gaat toch je creditcard gegevens niet invullen op een Hello Kitty website, of ben ik nu gek. Ik vind die website er nou niet betrouwbaar uitzien.

[Silence]

Dit is toevallig online gezet, maar ik zit ook vaak zat in databases met 200k+ users, webshops met CC gegevens alles gewoon plain text, dus zo special is het allemaal niet. Er zijn zoveel sites lek trust me

[Reactie gewijzigd door Silence op 23 juli 2024 10:47]

[_Thanatos_]

Wachtwoorden van betalingsinformatie zouden wel veilig zijn opgeslagen

En vervolgens

De sha-1-wachtwoordhashes liggen ook op straat en waren niet gesalt, samen met de eventuele hints en hun antwoorden.

Dat eerste is dus gewoon glashard gelogen.

[Anoniem: 80487]

Ik vind een hack waar een database met 3,3 Miljoen gebruikers buitgemaakt wordt redelijk significant...

[Gimmick]

Dit is natuurlijk wel wereldnieuws

Een database met meer dan 3,3 miljoen gebruikers

Het is technieuws, misschien geen wereldnieuws voor jou, maar een straaljager neergeschoten ( 1 of 2 piloten ) of een airliner met 400 passagiers en crew ?

Waar ligt de grens dan ?

Of is het omdat er Hello Kitty staat, en dat niet in jouw denkbeeld past als geldig tijdverdrijf ?

[Reactie gewijzigd door Gimmick op 23 juli 2024 10:47]

[Leader98]

Als het een database was geweest met gegevens over vlinders met 3,3 miljoen gebruikers zouden we er hier dan ook een nieuwsitem over hebben gezien?

En ik zette de natuurlijk niet voor niets

[Gimmick]

Als het een database was geweest met gegevens over vlinders met 3,3 miljoen gebruikers zouden we er hier dan ook een nieuwsitem over hebben gezien?

En ik zette de natuurlijk niet voor niets

Waarschijnlijk wel, want dit soort hacks komt vaker voor, en ook kleinere database's zijn vatbaar.
Op deze manier komen andere beheerders ( misschien) in actie omdat ze getriggerd worden hiermee.
De gebruikers zelf zijn in het artikel niet relevant ( als persoon ) maar de omvang en manier waarop dus wel

een smiley in het bericht wil niet zeggen dat de opmerking irrelevant moet zijn, het is geen kapstokje om achter te verschuilen als je opmerking of grapje niet begrepen wordt als zodanig

[Leader98]

Ik ben benieuwd naar toekomstige nieuwsitems (en durf niet meer te smilen)