'Gegevens van 1,5 miljoen accounts van e-sportswebsite ESEA verschijnen online'

ESEA, een grote e-sportscommunity, heeft bekendgemaakt dat de gegevens van zijn leden zijn uitgelekt. Dit zou het gevolg zijn van een afpersingspoging, waarbij een persoon vijftigduizend dollar van de organisatie eiste om de diefstal van data van 1,5 miljoen accounts stil te houden.

Leakedsource, een site die gebruikers zowel gratis als tegen betaling in gehackte databases laat zoeken, laat aan CSO weten dat het om een afpersing zou gaan. CSO schrijft dat het contact met ESEA heeft opgenomen, maar dat er nog geen bevestiging vanuit de organisatie is. ESEA zelf laat alleen via Twitter weten dat er gegevens zijn uitgelekt, maar dat het niet kan verifiëren of het daadwerkelijk om zijn eigen gegevens gaat. Het aantal van 1,5 miljoen accounts is eveneens afkomstig van Leakedsource.

Bij de database zou het gaan om negentig mogelijke informatievelden per gebruiker, waaronder gebruikersnaam, met bcrypt gehasht wachtwoord, voor- en achternaam, adres, geboortedatum en PSN- of Xbox Live-id. Verschillende Reddit-gebruikers hebben hun gegevens in de uitgelekte database kunnen vinden, aldus CSO. Bcrypt wordt over het algemeen als een veilig hashingalgoritme gezien.

ESEA had zijn leden op 30 december al op de hoogte gesteld van het feit dat iemand toegang had tot gegevens van gebruikers. In die mededeling schreef het bedrijf dat het op 27 december bericht over de hack kreeg van een onbekend persoon. In de recente tweet schrijft het bedrijf dat het 'al verwachtte dat de gegevens online zouden kunnen verschijnen'. In beide mededelingen noemt ESEA zelf geen aantallen. Via de site van de organisatie kunnen spelers van verschillende games het onder andere in wedstrijden tegen elkaar opnemen.

Reacties (39)

[Anonymoussaurus]

Via de volgende link kun je controleren of jouw account tussen de gehackte accounts zit: https://www.leakedsource.com/main/

Je kunt filteren op:

• Username
• E-mail adres
• Naam
• IP-adres

Je kunt jezelf ook uit de database verwijderen van LeakedSource. Dat kan hier: https://www.leakedsource.com/main/removal

This tool will allow you to automatically remove yourself from our site completely so that we no longer have to manually deal with removal requests and we can read all the messages we get sent.

After 24 hours your request(from this page) is also removed from our system leaving truly no trace you were ever here. Our goal is to educate users on what information is out there, once you have become aware we have no reason to know anything about you.

[biglia]

8 hits op mijn (wegwerp) e-mailadres. Bij AdultFriendFinder.com zelfs 2x. Eentje bij twitter.com en bij tumblr.com. Ik wist niet dat ze gehacked waren.

[rnenator]

Ze hebben nog best veel info:

• register_date
• City
• State/Province
• last_login
• username
• firstname
• lastname
• hash
• email
• birthday
• zip_code
• Phone number
• Website
• SteamID
• PSN_ID
• XboxID

Gelukkig was mijn account zeer incompleet en inaccuraat, want een naam en telefoonnummer in zo'n database kan voor behoorlijk wat overlast zorgen.

[Devaqto]

Wel mooi om te zien dat wachtwoorden gehasht zijn met bcrypt, ipv de blunder MD5 bijvoorbeeld. Bcrypt is samen met PBKDF2 een van de veiligste en beste opties om wachtwoorden te hashen.

Hier een leuke reactie over bcrypt voor diegene die het interessant vinden:
http://security.stackexch...e?answertab=votes#tab-top

[MarvinJames]

Ik ben zelf helemaal niet thuis in de beveiliging en encryptie, maar waarom doen we niet alle informatie van iemand encrypten i.p.v. alleen het wachtwoord?

[Ozzy]

Er zijn grofweg 2 mechanismes:
Hashen (dit is wat je bij wachtwoorden ziet): dit is (in principe) een richting. Met een hash kun je niet meer de oorspronkelijke "tekst" terughalen. Bij het inloggen vult iemand zijn wachtwoord in en op basis daarvan wordt de hash opnieuw berekend en die wordt vergeleken met de opgeslagen hash. Als die matchen dan is het wachtwoord goed.

Encryptie (dit is wat je bij gegevensbeveiliging ziet): dit is twee richtingen op. Met behulp van een sleutel kun je de originele "tekst" ontsluiten.

De voornaamste reden dat dit niet gebeurd, is omdat encryptie/decryptie voor vertraging zorgt. Een database wordt gebruikt om naar gegevens te zoeken. Bijvoorbeeld "Geef mij gebruikers die postcode 1234AB hebben". Als die postcodes geëncrypt zijn, moeten alle postcodes van alle records gedecrypt worden voordat de resultaten worden teruggegeven. Ditzelfde argument gaat ook op als je de postcode zou hashen.

Het wordt nog lastiger bij een zoekopdracht "Geef mij alle gebruikers met postcodes die beginnen met 12". Dit is nagenoeg onmogelijk omdat met hashes te doen. Omdat je dan alle mogelijke postcodes moet hashen en dan naar allemaal zoeken ( dus 1200AA, 1200AB etc, tot aan 1299ZZ). Dat is niet werkbaar.

[Anoniem: 51637]

Bijvoorbeeld "Geef mij gebruikers die postcode 1234AB hebben". Als die postcodes geëncrypt zijn, moeten alle postcodes van alle records gedecrypt worden voordat de resultaten worden teruggegeven.

Er bestaan ook cryptosystemen waarbij queries op versleutelde data uitgevoerd kunnen worden, waarbij de hele boel versleuteld blijft, dat zijn homomorfe systemen. Het probleem met deze dingen is alleen dat ze niet goed in staat zijn om de structurele eigenschappen van de brontekst te verbergen, waardoor een aanvaller in staat kan zijn om versleutelde data te wijzigen. Als ik bijvoorbeeld weet dat 'maak 100 euro over naar rekening 263' versleuteld wordt als 'abc def ghi jkl mno pqr stu', dan kan ik erachter komen dat 'def' het bedrag is en 'stu' het rekeningnummer. Dan kan ik, door 'def' en 'stu' te veranderen, een ander geldig bericht maken en zo een betaling in de soep laten lopen.

[Reactie gewijzigd door Anoniem: 51637 op 23 juli 2024 18:04]

[meneerdeman]

Duidelijke uitleg! Tnx!

[preske]

En als je het hebt over vertraging, over welke factor gaat het hier dan?

[Erik-Hendriks]

Het hashen van postcodes is sowieso nutteloos omdat er maar een beperkt aantal postcodes zijn, en je binnen 1 minuten een hash postcode table genereert.

[atlaste]

Encryptie van data kan tegenwoordig inderdaad prima, maar is niet per-se een oplossing. Enterprise databases zoals SQL Server bieden het gewoon aan out-of-the-box.

Waarom is dat niet een oplossing? Als je bijv. zoekt door de data, moet de database dus de data kunnen lezen. Per-record encryptie maakt dat onmogelijk. Encryptie op tabel niveau kan ook, maar dat betekent dat je server die de request doet (meestal de web server) nog steeds de decryptie key ergens moet opslaan. Als iemand op de eoa manier bij de servers achter de firewall kan, helpt dat dus niet...

Ik denk overigens dat je het nog een stap verder moet trekken.

Mijn bedrijf heeft als policy om alleen data te verzamelen als we het echt nodig hebben en alleen data te bewaren voor de periode dat dit noodzakelijk is. Encryptie en (sterke) hashing waar mogelijk. In sommige gevallen is die termijn helaas wel lang, bijv. facturatiegegevens (en dus NAW) van klanten. Maar het betekent ook dat als je data niet hebt, het dus ook niet gestolen worden (op welke manier dan ook).

Dergelijke policies zijn helaas meer uitzondering dan regel. De meeste bedrijven en zelfs de meeste CMS gooien informatie gewoon plain-text in de database; dat is wel lekker makkelijk. En helaas worden ook nog veel te veel wachtwoorden met MD5 gehasht.

[Byron010]

Helemaal met je eens, was ook gelijk het eerste waar ik aan dacht.

Toch een +1 voor ESEA voor het gebruik van bCrypt en het op de hoogte stellen van de gebruikers. Kunnen Yahoo en dergelijke nog wat van leren.

[The Realone]

Er staat wel mooi dat ESEA gebruikers op de hoogte zou hebben gebracht, maar ik heb echt geen communicatie van ze daarover mogen ontvangen en mijn account valt er wel degelijk onder.

[ptk078]

Als het goed is moest je twee weken terug je wachtwoord resetten. En ze hebben een forum post gedaan.

[The Realone]

Das mooi, maar ik heb daar dus een account die ik eigenlijk nooit gebruik. Wachtwoord dien je pas aan te passen als je inlogt (wat ik dus nu pas voor het eerst doe) en het forum lees ik daar niet. Een mail naar alle gebruikers is toch wel het minste wat je kunt doen lijkt me.

[The Realone]

Waar gaat dit nu over? Hoezo ga ik laconiek om met mijn accounts? Ik heb eens een ESEA account aangemaakt om dit te gebruiken, maar heb dat recentelijk niet meer gedaan. De account kan ik niet verwijderen en jij gaat mij niet wijs maken dat jij van alle honderden accounts die jij ooit aangemaakt hebt precies weet wat de status ervan is, of dat jij er van op de hoogte bent dat er bij die partijen een security breach is geweest. Dat heeft totaal niks met laconiek zijn te maken.

Human error dan...Hoe zie je dat precies voor je? Ik heb simpelweg geen mail gehad en er wordt ook nergens gesproken over een mail die door ESEA zou zijn verzonden. De enige communicatie die ik hier nu over zie is een forumpost op de site van ESEA, iets wat je niet ziet als je dit niet actief gebruikt.

[Juliuth]

De enige communicatie die ik hier nu over zie is een forumpost op de site van ESEA, iets wat je niet ziet als je dit niet actief gebruikt.

Ja het zou uiteraard netjes zijn als ze iedereen een mailtje zouden doen maar je zegt het net zelf al. "Iets wat je niet ziet als je dit niet actief gebruikt". Denk je dat als jij geen Tweaker was, en ik zeg wat; 2 jaar geen gebruik hebt gemaakt van je account bij ESEA. Dat het je dan nog kon schelen wat er was gebeurt?

Het beste zou inderdaad zijn als iedereen (lees: de meeste) zich zoals hier, bezig zou houden met veilig online zijn etc. Dit is helaas gewoonweg niet het geval. Dus ergens kan ik me wel voorstellen dat ESEA alleen hun actieve mensen inlicht d.m.v een forumpost. Anders zaaien ze "onnodig" (uiteraard niet helemaal onnodig maar voor het idee) paniek onder een groep mensen die al ik weet niet hoelang geen gebruik meer maken van hun diensten.

[The Realone]

Al deed ik er 10 jaar niks mee (en in mijn geval ging het "maar" om 2 maanden), feit is dat zij de beschikking hebben over enkele gegevens van mij en dat die nu zijn buitgemaakt. Of die gegevens er nu 3 jaar geleden of 3 dagen geleden ingezet zijn maakt echt niet uit. Ik wil graag weten als persoonlijke gegevens van mij gejat worden bij iemand.

Inlichten is alles behalve paniek zaaien, het is een kwestie van fatsoen, moreel besef en in bepaalde gevallen zelfs een wettelijke verplichting.

[Juliuth]

Ja maar dit is omdat (ik ga er vanuit dat dit zo is) jij weet wat je kan/moet doen. Er zijn zat mensen die bij zo'n "hack" totaal geen idee hebben wat ze moeten/kunnen doen. Die gaan hun haar verfen en emigreren naar Mexico.

[Wim-Bart]

Meerdere complimenten zijn op zijn plaats:
- bcrypt voor password hashing, dus niks te achterhalen met rainbow tables en snelle GPU voor kraken van wachtwoord
- ze hebben niet toegegeven aan afpersing
- ze zijn open over het hele verhaal

Wel een minpunje, waarom zijn de overige velden niet versleuteld......

[Anoniem: 310408]

Wel een minpunje, waarom zijn de overige velden niet versleuteld......

Ozzy legt precies uit waarom dat vrijwel onmogelijk is:

Ozzy in 'nieuws: 'Gegevens van 1,5 miljoen accounts van esportswebsite ESEA v...

[Byron010]

om die (volgens het artiekel) 90 ovirgen velden te encrypten (hashen begin je al niet aan) ben je aardig wat tijd + cpu load kwijt voor 1,5Mln gebruikers. En gebruik maken van zwakke encryptie is basically the same als geen encryptie.

However, wel hadden bepaalde prioriteit velden versleuteld mogen zijn.. 90 velden zijn er wel heel veel maar het had best gekund om de 5 belangrijke wel te versleutelen..

[neonite]

Weer eens wat anders dan opeens een bitcoin miner in je client.

[biglia]

Oh, je hebt gelijk. Het gaat om hetzelfde bedrijf: nieuws: E-sportsorganisatie krijgt boete voor verborgen Bitcoin-miner .

[RGAT]

ESEA heeft wel vaker bijzonder aparte tot schandalige dingen gedaan
Van de bitcoinminer tot een halve rootkit...
Voor mij is het geen mogelijkheid doordat ze virtualisatie blokeren, moet ik 2 computers kopen: 1 voor studie en 1 voor gaming puur omdat ESEA naast allerlei kernel driver troep ook dat afdwingt...

[Plainside]

Ik wist dat ESEA groot was maar 1.5mil o.o
Heb het zelf ook wel een keer geprobeerd maar gewoon teveel gezeik als je het mij vraagt.
Kunnen ze niet zoals Lydia een WW reset doen(snap dat dit een impact kan hebben).

[The Third Man]

Wachtwoorden zijn niet het grootste probleem (dankzij bcrypt), het gaat om de persoonsgegevens die op straat terecht zijn gekomen. Je kan niet even een geboortedatum-reset doen.

[Reactie gewijzigd door The Third Man op 23 juli 2024 18:04]

[lukjah]

Een geboortedatum is dan ook niet echt heel erg prive. Daarnaast is het ook erg makkelijk te bruteforcen mocht je hem ergens nodig hebben. Meerendeel van die users zullen tussen de 15 en 25 jaar zijn. Dat is dan 10*365 mogelijkheden.

[Ozzy]

Geboortedatum, postcode en dat soort "niet-privé" zaken wordt toch vaak gevraagd als controle bij banken, verzekeraars, webwinkels als je ze aan de telefoon hebt.
Met een naam, postcode, iban en/of een geboortedatum kun je dus al genoeg. En dit zijn ook gegevens die over het algemeen niet-gecrypt in de database staan.

Emailadressen en telefoonnummers geldt eigenlijk hetzelfde voor. Een berg van dat soort gegevens, waarvoor een groot deel gewoon in gebruik zullen zijn is geld waard voor ongure types.

[Reactie gewijzigd door Ozzy op 23 juli 2024 18:04]

[Olaf van der Spek]

wordt toch vaak gevraagd als controle bij [/b]banken, verzekeraars, webwinkels[/b] als je ze aan de telefoon hebt.

En *daar* gaat het dus echt fout..

[biglia]

Vaak is je geboortedatum het antwoord op een van de eerste vragen die je moet beantwoorden wanneer je je paswoord opvraagt bij andere diensten. Als je die vraag dus al weet, ben je al een stap dichter bij het opvragen van je paswoord. Het is natuurlijk geen grote ramp, maar wel best vermijdbaar.

Bij van die kleine websites waar geboortedatum verplicht is (niet vaak dus), vul ik enkel 01/01/[geboortejaar] in.

[Reactie gewijzigd door biglia op 23 juli 2024 18:04]

[rnenator]

Bij webshops doe ik meestal de dag na de registratie. Dan krijg je vaak ook nog een "verjaardagsaanbieding" in je e-mail wat je zo 10% korting kan opleveren.

[The Third Man]

In welke situatie zou je een geboortedatum brute forcen het is toch juist een controlevariabele die gebruikt wordt bij aanvragen en zo. Als je bijvoorbeeld een verzekering aanvraagt en die datum wordt correct ingevuld, dan gaat daar geen bel van rinkelen later. Het is dus een gewild gegeven voor id-fraude, en ja het staat ook vaak op Facebook etc, maar lang niet bij iedereen.

[jpsch]

schrikkeljaar

[Plainside]

Ja, bedacht het me net iets te laat.
Gaat lastig worden tenzij elk van die 1.5mil gebruikers zijn gegevens vals heeft ingevuld wat mij sterk lijkt.

[ptk078]

Ze hebben een reset gedaan, wachtwoord & 2FA

[SinergyX]

Om bepaalde top toernooien te kunnen zien, moest je ook geregistreerd zijn, dus denk dat aardig deel van die 1,5 miljoen gewoon bezoekers/kijkers waren en niet daadwerkelijk gamers.

Edit, zie net die leakedsource:
•Youku.com - 100,244,186 users

Dat is toch compleet ander niveau dan 1,5 miljoen gebruikers.

[Reactie gewijzigd door SinergyX op 23 juli 2024 18:04]

[Jokuh]

Het gaat weer totaal mis met ESEA. Eergisteren waren spontaan alle karma's van alle users -1337. Binnen enkele minuten gingen ze offline met de volgende melding:

"We were undergoing standard website maintenance and some changes were made through tests. We are in the process of restoring these changes."

Pure damage control en voorliegen van abonnees.