Online omgeving voor kinderen Animal Jam meldt datalek van 46 miljoen accounts

De 'virtuele wereld' voor kinderen Animal Jam heeft te maken met een datalek waarbij 46 miljoen accounts gemoeid zijn, zo meldt ontwikkelaar WildWorks. Naast inlognamen en wachtwoordhashes gaat het om enkele miljoenen e-mailadressen van ouders.

WildWorks meldt dat het woensdag achter het datalek kwam omdat een database aangeboden werd op het hackersforum raidforums.com. De database is naar schatting rond 10 tot 12 oktober gestolen. Op de Animal Jam-site zet de ontwikkelaar op een rij welke gegevens ontvreemd zijn. Het gaat om 32 miljoen gebruikersnamen die gekoppeld zijn aan accounts van ouders, en 7 miljoen e-mailadressen van die ouderaccounts. Ook de sha1-wachtwoordhashes zijn gestolen. Volgens BleepingComputers zijn de hashes gesalt maar zijn er ook berichten dat 13 miljoen wachtwoorden gekraakt zijn, al zou WildWorks dat niet kunnen bevestigen.

Van 12.653 ouderaccounts liggen ook de namen en factuuradressen op straat en ook zijn van enkele miljoenen accounts de geboortedata en sexe onderdeel van de database. De ceo van WildWorks meldt BleepingComputer dat hij denkt dat de criminelen via een buitgemaakte AWS-sleutel toegang tot de database wisten te krijgen. Deze key zouden ze in handen hebben gekregen door toegang tot de Slack-server te krijgen. De topman meldt daarnaast dat het om een deel van het totale aantal Animal Jam-accounts gaat dat sinds 2010 geregistreerd is.

Animal Jam is een bij kinderen populaire online omgeving met spelletjes. De dienst heeft meer dan 130 miljoen geregistreerde accounts en 3,3 miljoen maandelijks actieve spelers. WildWorks adviseert gebruikers om bij Haveibeenpwned te controleren of hun e-mailadres in de gestolen database stond.

Reacties (39)

Ik had het vorige week al in de gaten! Mijn dochter heeft alleen een outlook.com account en een Animal Jam account. Kreeg al een melding van MS dat er zoveel inlogpogingen waren gedaan. Gelukkig stond mfa aan.

gebruikte je dan hetzelfde ww op Animal Jam als voor de e-mail?

Dat maakt voor de melding van het aantal foutieve inlogpogingen niet uit.

ah lol, ja natuurlijk.

Maar hij gaf aan MFA aan te hebben staan en ging ik daarom er vanuit dat hij daarom faalde qua inloggen

[Reactie gewijzigd door Boy op 13 november 2020 10:51]

Ik vraag me nu wel af, waarom word er niet gekozen voor het encrypten van e-mail addressen?

Je kunt niet zoeken in een encrypted database. Als je het emailadres gebruikt om iemands account te vinden bij bijvoorbeeld het inloggen, zou je bij elke inlogpoging eerst alle emailadressen in je database moeten decrypten. Dat is en enorm inefficient, en zorgt er voor dat je alsnog de hele tijd al je emailadressen ontsleuteld ergens hebt liggen.

Kun je niet de encryption zoeken, dus de invoer encrypten en die vergelijken, zoals gehashte wachtwoorden die vergeleken worden? Ik zeg wss iets stoms nu.

Dat is helemaal niet stom gedacht. Er zijn uiteraard wel bepaalde beveiligingseisen die je daarbij in acht moet nemen. Ook moet je beseffen dat je server zwaarder wordt belast doordat er veel encryptieslagen nodig zijn. Er zijn zeer zeker methodes om alle data encrypted op te slaan en hier toch op een bepaalde manier in te kunnen zoeken maar dit zijn afwegingen die je moet maken. Is het wel echt nodig om een e-mailadres veilig op te slaan. Sla dan liever de persoonsgegevens en facturatieadressen encrypted op.

Envryptie heeft vaak ook nog een individuele publieke 'sleutel' . Als je dezelfde gegevens envrypt, kan de geencrypte versie dus 2x verschillend zijn (maar by decrypten krijg je dan weer verschillende gegevens.

Zoeken op deze gegevens gaat dan dus niet werken (er is niet 1 hash waarop je kan zoeken). Alternatief is dat je hashes trekt van emailadressen en deze gebruikt als 'inlognaam' om op te zoeken, dan maak je het al weer wat moeilijker.

Ook gehashte wachtwoorden worden tegenwoordig niet meer 'oipgezocht' in de database. Hashen van hetzelfde wachtwoord levert vaak, door een uniek toegevoegd gedeelte, iedere keer een andere hash op.

Als je kijkt op bijvoorbeeld https://bcrypt-generator.com/ en het wachtwoord 1234 probeert, dan is de eerste keer bijvoorbeeld de hash:
$2y$12$e53VLUkm9k/.i3UFK7E8Eehq9vo1QxX5G0lQ858Cc7kCQSCeKJKx.
de tweede keer:
$2y$12$OjwKUyF7wORb.rmeeoUpGu0sUSGimv6UjuCSjXKghpv5HhdPMvTRm

Data is rest of data in transit zijn andere plekken om te encrypten, die ook wel vaker gebruikt worden, of encryptie zal op database niveau ondersteunt moeten worden.

[Reactie gewijzigd door gorgi_19 op 13 november 2020 14:36]

Je kunt wel zoeken in een encrypted database. Echter niet met het origineel. Je zult dan eerst een encrypt moeten doen van de ingevoerde data. En die kun je dan weer vergelijken. Heb je echter wel altijd dezelfde sleutel en die zit dan ook in de applicatie verwerkt dus of het helpt tegen hacks betwijfel ik.

In plaats van alle mail adressennin DB te decrypten ga je dan dus de input encrypten dat is natuurlijk een stuk sneller.

Er zijn hele goede cryptografische libs te verkrijgen tegenwoordig. Gebruik hiervan is simpel en beveiliging hoog doordat deze goed cryptografisch correct zijn opgezet.

Ja, er zit in de applicatie een sleutel. Echter in moderne applicaties worden er extra salts en keys per veld toegevoegd voor versterkte versleuteling. Het salt-per-password patroon of met asymetrische encryptie het public/private key met keychain idee. De applicatiesleutel wordt hier aan toegevoegd voor extra uniekheid.

m.a.w. zal je in z'n geval wanneer je de applicatie sleutel hebt nogsteeds lastig bij de waardes kunnen komen omdat dit niet het enige geheim is wat gebruikt wordt voor hashing/encryption.

Daarnaast is encrypted zoeken wel degelijk mogelijk. Er zijn hier genoeg oplossingen voor. Blind indexing als bekendste stategie, bij mij althans.

[Reactie gewijzigd door Muna34 op 13 november 2020 10:12]

Google lost dit op door zowel de index als de data te encrypten. Als je als applicatie toegang tot de data hebt, door middel van een geldige sessie van de klant mag je een key opvragen voor de decryptie van de data van de klant in de sessie. Daarmee wordt dan de index beschikbaar en kan er dus snel gezocht worden in de inhoud. In de praktijk zit het iets gedetailleerder in elkaar maar dit is wel hoe het in principe werkt.

Ik zeg niet dat er geen theoretische oplossingen voor bestaan (mijn statement "je kunt niet zoeken in een encrypted database" valt tot zekere hoogte over te twisten als je de wetenschap er op naslaat), maar wel dat dingen snel onpraktisch worden. De realiteit is echter dat Google hier engineeringtijd in kan stoppen en dit soort oplossingen niet beschikbaar zijn voor iedereen op niet-Google schaal.

Het wordt tijd dat we van meer partijen dit soort oplossingen gaan verwachten, begrijp me niet verkeerd. Maar voor dit soort apps zo'n oplossing kunnen gebruiken moet de stand van de techniek veel verder zijn.

130 miljoen accounts... Dat is geen kleine toko die daar achter zit. Die kunnen prima over ressourcen beschikken om een fatsoenlijke oplossing te ontwikkelen. Dit is gewoon laksheid.

[Reactie gewijzigd door zotteke op 13 november 2020 04:20]

Je kunt helaas niet zien aan de hoeveelheid gebruikers hoeveel resources daar achter zitten. Sowieso is dit verre, verre van Google-schaal.

[Reactie gewijzigd door DCK op 13 november 2020 03:51]

Ah tuurlijk! Ik had nog niet zover door gedacht oeps
Dankje!

Omdat ze je dan nooit kunnen mailen voor wat dan ook. Zij het reclame, zij het nuttige info zoals een mail dat er iets niet klopt met account of wat dan ook.

Jawel, als ze de encryptiesleutel apart opslaan?

Dus niet in dezelfde database?

Ze kunnen dan niet eenvoudig zoeken naar een emailadres in de database, maar als je met een user name inlogt is dat niet zo'n probleem?

Ja maar waar dan? De applicatie of iets anders moet er toch bij kunnen. Dus als die er bij kan dan kan een hacker dat ws ook.

Plus je voegt behoorlijke complexiteit toe die ook weer vatbaar is voor kwetsbaarheden en het kost best veel resources (dus duur in bijvoorbeeld cloud).

Tja, dat zijn de praktische problemen, maar in theorie is het wel een interessant idee.

Maar als de applicatie de key ingebouwd heeft, of kan uitlezen uit een bestand.

Dan moet een hacker naast de verbinding met de database, ook je source of key bestand stelen.

Of is het praktisch gezien is dat ook wat er gebeurd bij een API, waarbij een database niet direct via het internet bereikt kan worden maar alleen via een api?

nouja wel zo handig om te weten naar welke email je de recovery email moet sturen, en naar welke email je updates moet versturen, en naar welke email je iets moet sturen om contact op te nemen in het algemeen.

Encrypten is iets heel anders dan hashen. Iets wat je encrypt kun je ook decrypten en dus de oorspronkelijke waarde terughalen. Met hashen kan dat niet (tenzij de hashmethode te zwak is, maar dat is alsnog geen weg die je wilt bewandelen als je de data regelmatig weer in oorspronkelijke staat wilt hebben).

Emailadressen encrypten kan dus prima, en als je de sleutel op een andere plek bewaart hebben ze aan alleen de database niet voldoende om bij de emailadressen te kunnen.

Precies. Symetrische en asymetrische encryptie.

Er zijn ook genoeg libs die applicaties secure maken met de meest moderne encryptie. Moderne ORM's ondersteunen dit ook en hierdoor wordt implementatie kinderspel. Dan haal je het email veld op en hoef je niet eens over encrypten/decrypten na te denken en gebeurd het in de achtergrond.

Hebben we inmiddels niet een punt bereikt waarop elk email adres van elke persoon inmiddels al ergens in een lekkende database gezeten heeft en op een commerciele spamlijst staat? Zo ja, is het niet een goed idee om een europees wetsvoorstel te maken die elke website met login, verplicht een 2FA te laten aanbieden als optie?

Daarmee voorkom je het achterliggende probleem niet, het hacken en vrijspelen van gegevens die niet enkel een mailadres en een hashed paswoord zijn. Al is het betreurend dat een dienst van deze grootte in 2020 SHA1 gebruikt (deze wanpraktijken mogen ze bijvoorbeeld eerder aanpakken).

Zo ja, is het niet een goed idee om een europees wetsvoorstel te maken die elke website met login, verplicht een 2FA te laten aanbieden als optie?

En hoe had dat hier iets kunnen voorkomen? Denk dat je het lek niet snapt.

Sterker nog, vaak gaat 2FA via SMS, hoe onveilig ook. Dat had het probleem nog groter gemaakt doordat de hackers ook de GSM nummers hebben.

Je doet net alsof het heel moeilijk is, maar SIM swapping komt veel voor en wordt gewoon door verveelde tieners uitgevoerd.

Denk niet alleen aan kinderspelletjes. Banken gebruiken ook SMS voor 2FA. Als hackers zowel je email alsook je GSM hebben, wordt identiteitsdiefstal weer iets gemakkelijker.

Dat lijkt mij lastig te regelen. Kan zoiets ook op websites waarvan de eigenaar niet in de EU is gevestigd?

Overigens zou een dergelijke maatregel wel werken bij hergebruik van wachtwoorden: een gekraakt wachtwoord is dan niet meer voldoende voor een andere website. Een stukje risicoverlaging is er dus wel. Echter, 2FA is (helaas) geen heilige graal. Ik zou mij bij een datalek zorgen maken om gerichte phishingacties, omdat de aanvaller precies weet hoe deze jou moet adresseren (met informatie die normaliter niet of niet zomaar te vinden is op het internet, denk aan: NAW, bankrekeningnummer, burgerservicenummer, bijzondere persoonsgegevens).

Met en gepersonaliseerde e-mail, een goed gejat inlogscherm (als je handig bent met Kali Linux en de vele tools hoeft dat niet heel lastig te zijn) en een beetje geluk heeft een aanvaller zo je wachtwoord en extra token gejat. E-mailadressen van mij zitten helaas ook in datalekken, het aantal phishingmails is daardoor ook sterk toegenomen. Tja, met gerichte phishingmails kan ik mij wel voorstellen dat er mensen zijn die erin trappen.

https://haveibeenpwned.com

Ik denk dat Troy Hunt ondertussen echt een redelijke collectie heeft De login is dan ook niet echt het probleem. Het email adres wordt opgeslagen in de database, zelfs al zou je dit encrypten (zwak of sterk), dan zou theoretisch een hacker nogsteeds de waardes kunnen bemachtigen.

Hoe kunnen we dit oplossen? Partijen die gevoelige data verwerken een pentester in de hand laten nemen. Security hardening toepassen, encyptie laten doorlichten om te kijken of deze voldoet aan de huidige standaard.

Offtopic: Ik kom nog systemen in de wild tegen (of grote e-commerce pakketten) waar simpelweg md5 of sha1 gebruikt wordt als standaard methode voor wachtwoorden

2FA is een begrip, geen protocol of technologie. 2FA wil zeggen dat je met behulp van een tweede authenticatie factor (de eerste factor is voornamelijk username + password) jezelf kan authenticeren op een dienst. Microsoft zei dat sms als 2FA onveilig was. dit omdat sms in essentie onveilig is.

Maar 2FA is niet alleen sms, je hebt ook 2FA aan de hand van codes via applicaties op jouw gsm of ander toestel. Dan heb je ook nog keuze voor fysieke sleutel zoals de yubico key. Daarnaast kan je ook 2FA instellen op basis van een vingerafdruk of iets anders. 2FA stopt niet bij gewoon een sms, het begrip is zoveel groter.

2FA is niet onveilig. De door jouw genoemde gebruiksmethoden zijn echter wel onveilig. Als je een 2FA app gebruikt zoals Google Authenticator dan heb je daar geen last van en dan is 2FA veilig toe te passen.

Datalek, mooi woord voor inbraak en diefstal.