Data van 20 miljoen gebruikers van AI-beeldgenerator Cutout.Pro gelekt

AI-beeldgenerator Cutout.Pro is het slachtoffer geworden van een datalek. Bij een aanval eerder deze week werden de gegevens van bijna 20 miljoen accounts gestolen, melden datalekzoekmachine Have I Been Pwned en securitybedrijf HackManac.

Naast e-mailadressen en IP-adressen zijn ook namen van gebruikers en salted MD5-wachtwoordhashes gestolen. De gegevens worden aangeboden op een populair hackersforum en via Telegram-kanalen, meldt Have I Been Pwned. Niet alle gelekte data zijn uniek: 29 procent zat al in de database van de zoekmachine en was dus al eerder gelekt.

HackManac merkte het datalek als eerste op. Volgens het beveiligingsbedrijf beweert de cybercrimineel achter de aanval, die schuilgaat onder de alias 'KryptonZambie', nog altijd toegang te hebben tot de systemen van Cutout.Pro. Ook zegt de aanvaller dat er vooral e-mailadressen en wachtwoorden gestolen zijn. Cutout.Pro moet deze beweringen echter nog bevestigen. Hoe de gegevens gestolen konden worden, is niet bekendgemaakt.

Reacties (26)

[gorgi_19]

Zo te zien is het niet de eerste keer dat ze een datalek hebben gehad.

Vorig jaar rond deze tijd was er sprake van een verkeerde configuratie, waardoor hun database open stond.

[Skyaero]

Even drie seconden op hun website geneusd:
- De gebruikersnaam en wachtwoord wordt met een GET request verstuurd. Dat betekent dat deze dus (mogelijk) in de serverlogs eindigt, omdat bij een GET request alle data in de url staat.
- De applicatie geeft specifiek aan of het de gebruikersnaam, of het wachtwoord is dat incorrect is. En is daar open voor een 'enumeration attack', je kunt zoeken welke accounts er in het systeem staan.
- Er zit geen rate limiter op de login, waardoor bovenstaande supermakkelijk te scripten is.

Als dit al niet in orde is, verbaast mij de rest ook niet.

[Oon]

Het feit dat gebruikersnaam en wachtwoord verstuurd worden betekent dus sowieso al dat ze geen gebruik maken van een nette moderne standaard OAuth2 flow, maar een implicit grant gebruiken, die al heel lang als onveilig bestempeld wordt.

[DevWouter]

Ook bij OAuth2 worden meestal (lees: bijna altijd) gebruikersnaam en wachtwoorden verstuurd als je moet inloggen bij de identity provider. Het grote verschil is wel dat de identity provider niet dezelfde hoeft te zijn als de dienst waar je inlogt en dat maakt het iets veiliger.

En implicit grant is vooral zodat de afnemende dienst niet de OAuthProvider hoeft te benanderen om het bevestigd te krijgen.

[Oon]

Leuk, maar dat is toch echt gewoon niet meer van deze tijd. Implicit flows sturen onnodig je authenticatie informatie van de client naar een losse back-end, terwijl een code grant flow of iedere andere wel-veilige manier dat niet doet.

Er zijn enkele situaties waarin een implicit flow wel acceptabel is, maar dat is een simpele SPA niet.

[DevWouter]

Code grants met PKCE versturen een afgeleide authenticatie door naar een losse backend. Authenticatie is meer dan alleen gebruikersnaam en wachtwoord.

[holoduke51]

Kan net zogoed met een post request gebeuren. Ook body van een request kan worden gelogd. Onze nginx logs loggen alles. Zowiezo om te goed te begrijpen wat wel en niet word gelogd (voor deze partij)

[Zebby]

Het is natuurlijk wel een verschil of dit standaard gedrag is (bij GET, de URL loggen doe je bijna altijd), of gecodeerd (resultaten van POST).

[jarco5000]

MD5? Dat is toch al heel lang achterhaald, ook al gebruik je salt. Bizar dat dit nog gebruikt is bij een moderne applicatie.

[Heaget]

Ik weet niet of achterhaald het juiste woord is, maar met moderne GPU's is het mogelijk om miljarden MD5 hashes per seconde te berekenen, dus veilig is het in ieder geval niet. ( Bron: https://www.phoronix.com/review/arc-graphics-compute-q1/4 )

[joost00719]

Achterhaald voor het hashen van wachtwoorden, maar zeker niet achterhaald in andere use cases. Wordt nog regelmatig gebruikt om te kijken of twee bestanden gelijk zijn.

[Saven]

Om wachtwoorden te hashen is md5 al meer dan 10 jaar achterhaald en al meer dan 15 af te raden Het is al compleet idioot dat dit algoritme nog wordt gebruikt in legacy applicaties, laat staan in een moderne app als deze.

[banaj]

Ach, Windows gebruikt nog MD-4, hoor je niemand over

[OruBLMsFrl]

NTLM wordt wel ook al langer afgeraden, Kerberos only is mogelijk in moderne Windows omgevingen. Maar het verdient allemaal zeker ook geen schoonheidsprijs, voelt onnodig moeilijk te beveiligen zelfs.

[holoduke51]

MD5 is een super snelle hasher. Daar wordt het enorm veel gebruikt. Waarschijnlijk op jou telefoon meerdere keren per seconden gedurende 24 uur. Memory validatie etc.
Maar voor passwords inderdaad niet echt handig. Een simpele lookup tabel voor md5 wachtwoorden zijn er zat. Soms echter is de hash niet bedoeld voor veiligheid, maar voor andere doeleinden.

[bush]

Ik snap gewoon niet dat er nog applicaties zijn die authenticatie zelf willen doen. Er zijn zat OAUTH providers die dat voor jou regelen, en veel beter dan dat je het zelf kan

[RoestVrijStaal]

Dan maak je jezelf weer afhankelijk van die OAuth provider(s).

En die OAuth providers krijgen ook inzicht in wat je gebruikers uitspoken; zoals bijvoorbeeld wanneer en waar ze inloggen in jouw dienst, wanneer ze jouw dienst gebruiken.

En OAuth providers zijn je niet verplicht om de mogelijkheid te garanderen. Ze kunnen jouw bedrijf van de een om de andere dag cancellen.

[SinergyX]

En dan? Goed, ik heb je wachtwoord niet.. maar de rest van jouw informatie op die site geregisteerd heb ik dus wel in de pocket. Ergste geval deed iedereen netjes hun wachtwoord policie en waren het allemaal unieke wachtwoorden, salted, OAUTH of 128bit encrypted.. je had er per definitie toch al niets aan.

[SPee]

Of je gebruikt een gespecialiseerde tool hiervoor als je het in eigen beheer wil hebben.

Maarja, een eigen database met daarin je gebruikers is wel zo makkelijk, dan een tool als keycloack leren kennen en gebruiken. Ik ben nu ook aan het werk aan een applicatie dat zelf de gebruikers beheert. Gelukkig wel met betere encryptie van het wachtwoord en 2FA. Maar helaas wel een eigen database (tabel) met accounts.

[SherlockHolmes]

Geld

[banaj]

Ter informatie: Ik heb de data bekeken en van de 20 miljoen accounts zit er bij de meeste geen hash, 'slechts' bij ongeveer 1,75 miljoen. Die zijn inderdaad van het type salted MD-5. Dus voor een enkele hash kan je op hoge snelheid kraken op je game-GPU. Wat veel mensen vergeten is dat als je er ongericht 1,75 miljoen gaat kraken dus wel met de snelheid SUPERSNELLE_GPU gedeeld door 1,750,000 te maken hebt, wat weer traag kan zijn.

[telenut]

Waar kan je die vinden? Geen zin om te betalen voor have I been Powned :-)

[computerjunky]

Waarom geef je überhaupt data vraag ik me af. Als een site mijn data vraagt dan ben ik meteen weg naar de volgende site of gebruik ik het lekker niet.

[gorgi_19]

Alleen een IP-adres is al data

Maar iets breder... Je kan daar credits kopen voor gebruik. Alleen daarvoor al moet je wat data verschaffen, in de vorm van naam en accountgegevens.

[banaj]

Huh, HIBP is toch gratis?

Data b.v. hierrrr.

[Radio69belgium]

Helaas is mijn muziek productie slachtoffer.
Om 3:30 werd ons Microsoft account gehackt door 7 verschillende ip's uit china.
Ik heb onmiddellijk actie ondernomen meteen wachtwoord veranderd. Tegen 3:32u snachts
Was het paswoord veranderd en heb ik ook onmiddellijk mijn Microsoft mail veranderd.
Ook heb ik mijn Pasworden van alle emailadresen veranderd. Alle logins veranderd. Van alles waar wij gebruik van maken zowel alles van mijn bedrijf en zowel als privè. Ik heb al een mail gestuurd naar cutout ze weigeren de antwoorden. Ik heb na gekeken begin vorige maand naar mijn email. En die was niet gelekt. Na de hack opnieuw gecheckt en wel gelekt door cutout ik we bekijken wat we kunnen doen tegen cutout. Gelekt is gelekt en is inbreuk en blijft inbreuk op mijn privacy en mijn klanten en de zangers bands waar we mee werken. De meeste leken komen meestal door een menselijke fout. Ofwel klikken ze op iets waar ze niet moeten op klikken ofwel een foute setting van de veiligheid.