Hackers publiceren gegevens 453.000 Yahoo-accounts

Hackerscollectief D33Ds Company heeft namen en wachtwoorden van 453.000 accounts van Yahoo-diensten gepubliceerd. Waarschijnlijk zijn de hackers via een sql-injectie bij Yahoo Voice binnengekomen. De gegevens waren niet versleuteld.

Een collectief van hackers dat zich de D33Ds Company noemt, heeft de gebruikersnamen en wachtwoorden van in totaal 453.492 Yahoo-accounts op zijn site geplaatst. Bij de gebruikersnamen gaat het niet alleen om Yahoo-e-mailadressen, maar ook om Gmail-, Live- en AOL-adressen. De hackers zijn binnengekomen via een sql-injectie bij een subdomein van Yahoo. Het collectief meldt niet om welke kwetsbaarheid en welk domein het gaat 'om verdere schade te voorkomen'.

Uit de eveneens bij de publicatie vrijgegeven hostname 'dbb1.ac.bf1.yahoo.com' maakt beveiligingsbedrijf Trusted Sec echter op dat het waarschijnlijk om Yahoo Voice gaat. De accountnamen en wachtwoorden zouden onversleuteld opgeslagen zijn geweest. Naast de accountgegevens zijn ook meer dan 2700 table- en column-namen, en 298 MySQL-variabelen uit de gehackte database gepubliceerd. De authenticiteit van de hack is nog niet geverifieerd en Yahoo heeft nog niet gereageerd op de publicatie.

Reacties (60)

[Devedse]

Ik heb even een analyse uitgevoerd op het password bestand en dit zijn de resultaten:

https://dl.dropbox.com/u/1814002/password%20analyse.png

(In de afbeelding staat de wachtwoorden gerangschikt op hoeveel deze gebruikt zijn met de hoeveelheid erachter, hierna volgt het percentage hoeveel % van de gebruikers dit wachtwoord + alle bovenstaande gebruiken, tot slot volgt de tijd die het zou kosten om met een gemiddelde computer het wachtwoord te bruteforcen mocht deze WEL gehashed zijn met MD5).

Heel veel van de wachtwoorden in de database worden meerdere keren gebruikt, namelijk 31.8% van alle wachtwoorden is niet uniek.

Tevens blijkt dat 16.8% van de wachtwoorden binnen 1 minuut te brute forcen is (wanneer deze gehashed "zouden" zijn met MD5, SHA zou ongeveer 2-3 keer zo lang duren).

42.6% van de passwords blijkt binnen één dag gebruteforced te kunnen worden bij MD5.

Tevens nemen de top 1000 van de wachtwoorden al meer dan 10% in beslag, dat wil zeggen dat met deze 1000 wachtwoorden meer dan 45.000 van de yahoo accounts gehacked zouden kunnen worden.

[Wompus]

Eigenlijk kan je met 1600 wachtwoorden in 10% van de 453.000 accounts. Er zijn veel lege entries waarbij er (nog?) geen wachtwoord opgegeven is.

[Devedse]

Ja inderdaad, deze zijn er binnen de analyse die ik gedaan heb niet uitgefilterd, wanneer deze er wel uitgefilterd worden kom je op ongeveer 1600 uit.

[Xerras]

mirror van hackernews:
http://www.mediafire.com/?769gk65ix183vbd

[Reactie gewijzigd door Xerras op 27 juli 2024 07:14]

[ArnoAG]

Hieruit lijkt het toch om 739853 accounts te gaan.

[Wdude124]

http://www.boston.com/bus...mzXbBDG9rGbUAM/story.html
Het blijkt dus een oude file te zijn.
"Yahoo cautioned that only 5 percent of passwords associated with its account holders were valid."

[MatthiasDS]

Ik vind het bijna niet te geloven dat zelfs bedrijven als Yahoo wachtwoorden ongeëncrypteerd opslaan.
Ik zou het nog kunnen begrijpen dat de lokale PC-winkel met amateuristische webshop niet de kennis heeft waarom dat zo slecht is, maar Yahoo? Komaan zeg.

Wachtwoorden encrypteren, altijd. En geen password retrieval systeem opzetten, maar een password resetsysteem.

[arjankoole]

Ik vind het bijna niet te geloven dat zelfs bedrijven als Yahoo wachtwoorden ongeëncrypteerd opslaan.

Er zijn een aantal services en protocollen die een onversleuteld wachtwoord nodig hebben om te kunnen functioneren. ik weet niet helemaal zeker of dat tegenwoordig nog zo is, maar vroeger in elk geval wel.

[oliveroms]

imap/pop3 bijvoorbeeld bedoel je? of ftp?

Ja, deze protocollen verstuurden het wachtwoord unencrypted. Maar opslag was wel netjes encrypted.

Voordeel: Wachtwoord is encrypted in de DB.
Nadeel: Wachtwoorden worden plaintext over de lijn gestuurt.
Workaround: Via SSL verbinden met de host en dan stuur je over een beveiligde verbinding plaintext data, wat absoluut geen probleem mag zijn. (Tenzij er Man in the middle etc aanvallen zijn).

Vervolgens kan je ook wachtwoorden (bij imap/pop3 om maar even bij het voorbeeld te blijven) ook encrypted versturen. B.v. CRAM-MD5 DIGEST-MD5 NTLM etc. echter moeten dan de wachtwoorden in plain-text in de database opgeslagen staan. Of het ook anders kan, weet ik niet.

Voordeel: Wachtwoord wordt encrypted verzonden.
Nadeel: Dit hoeft niet veiliger te zijn. Als je immers het encrpyted wachtwoord hebt kun je dat zelf ook over de lijn sturen?

[Kosty]

Vervolgens kan je ook wachtwoorden (bij imap/pop3 om maar even bij het voorbeeld te blijven) ook encrypted versturen. B.v. CRAM-MD5 DIGEST-MD5 NTLM etc. echter moeten dan de wachtwoorden in plain-text in de database opgeslagen staan. Of het ook anders kan, weet ik niet.

Er is een belangrijk verschil tussen een versleutelde verbinding en het gebruiken van een versleuteld/gehashed wachtwoord. Het verschil is dat je bij een versleutelde verbinding het exacte wachtwoord - inclusief eventuele versleuteling/hasing (volledig optioneel) - kan doorsturen van client naar server (of peer to peer), waarbij de gegevens volledig veilig blijven zolang de verbinding gegarandeerd versleuteld is, en beide partijen bv. niet geïnfecteerd zijn met een virus (dat de gegevens kan onderscheppen voor ze in/nadat ze uit de versleutelde "tunnel" komen).

Als je een gehashed wachtwoord verstuurt, stuur je eigenlijk nog steeds een plaintext wachtwoord. Daarmee bedoel ik, stel dat je bij het aanmelden bij een service een wachtwoord krijgt. Dat wachtwoord wordt bij die service opgeslagen als MD5 hash van die string. Als jij nu inlogt met dat wachtwoord, bijvoorbeeld via HTTP, door dat wachtwoord in te vullen OF door die hash in te vullen, komt dat in feite op hetzelfde neer: als er iemand tussen jou en de ontvangende partij kan afluisteren, kan die partij dezelfde gegevens doorsturen en inloggen. Het trucje van datasecurity over onversleutelde protocols is ofwel tunneling door een veilig protocol (POP3/SMTP/FTP over PPTP, bijvoorbeeld) of door de overgebrachte gegevens te beïnvloeden met een variabele die alleen bekend is bij de client en bij de server (dus niet bij derde partijen). Voorbeelden daarvan zijn een salt (die opgeslagen gehashte wachtwoorden beveiligen tegen kraken via rainbow tables etc. in het geval dat ze toch gestolen worden) of een token.

Het beste is natuurlijk dat je zowel een versleutelde verbinding en een deftige aanmeldprocedure toepast, anders ben je nog steeds vatbaar. Heeft het zin om in te loggen via 2 of 3-way verification (bv. wachtwoord/token/bericht met code naar telefoon of email) voor een dienst waar jij alleen toegang tot wilt hebben (stel nu een overzicht van jouw financiële situatie), als de teruggestuurd gegevens na authenticatie gewoon plaintext verzonden worden? Dat is namelijk wat er gebeurt bij die "onveilige" protocols zoals HTTP, POP en FTP (waar overigens meestal wel beter beveiligde alternatieven voor bestaan).

[kmf]

Volgens mij was er 1 van de loginmodus voor en raedius server die plaintext-wachtwoorden wilt hebben.

[Niemand_Anders]

Nou APOP heeft bijvoorbeeld het originele wachtwoord nodig welke wordt gehashed met een session token. Omdat de token elke keer anders is gaat bij elke authenticatie een andere hash (in plain text) naar de server.

Maar het probleem is natuurlijk dat die ene login niet alleen voor jouw mail client werkt, maar ook voor jouw Yahoo! account. Google Mail gebruikt imap en smtp over SSL, maar dat wil niet zeggen dat jouw wachtwoord encrypted in de Google database staat.

En als Google een beta product online gooit en daar zit een SQL injection dan zouden alsnog de gegevens op straat kunnen komen. Veel producten beginnen als een simpel project en daar zit meestal de kern van het probleem. De meeste developers welke werken aan een proof-of-concept nemen niet direct alle security vraagstukken mee. Als de PoC vervolgens uiteindelijk best wel groot is geworden, wordt helaas niet altijd opnieuw begonnen. En dan kan het weleens voorkomen dat een injection vulnerability achter blijft in de code..

Visual Studio kan via (static) Code Analysis de meeste SQL injections herkennen. FxCop is de gratis variant hiervan en heeft ook veel mogelijkheden op het gebied van performance en security. Maar voor PHP is er o.a. Pixy en voor java is er bijvoorbeeld Jtest. Er zijn dus gewoon oplossingen om dit te voorkomen..

[DCK]

De gegevens waren niet versleuteld, maar dat wil niet zeggen dat de wachtwoorden er gewoon plaintext instonden. Het lijkt me zeer onwaarschijnlijk dat die niet voldoende sterk gehasht zijn bij Yahoo!.

[Hatsjoe]

Wachtwoorden staan er gewoon in plaintext in, in de DB dump.

Grote fout dus van Yahoo. En dat bepaalde dingen niet met encrypted wachtwoorden kunnen werken gaat hier ook niet op, dit was voor een eigen systeem van Yahoo en in hun beheer. Ze hebben het dus goed verkloot.

[DCK]

Bizar dat Yahoo dit laat gebeuren. Er is geen enkele applicatie die die wachtwoorden plaintext nodig zou moeten hebben.

Ik vind dit zo bizar dat ik mij afvraag of dit wel bij Yahoo vandaan kan komen. Plaintext-wachtwoorden opslaan is iets voor gedateerde of hobbywebsites, niet iets voor bedrijven waar internetdiensten hun core business zijn.

[Katanatje]

Kan iemand die dump nog openen? De dump staat niet meer on-line. Hoe kan men nu weten of je account erbij zit of niet? Of gaat Yahoo de gedupeerden mailen?

edit: zie reactie Xerras hieronder: extra mirror

[Reactie gewijzigd door Katanatje op 27 juli 2024 07:14]

[wootah]

Ja ik ken nog wel een paar bedrijven die dat doen helaas...
EVGA bijvoorbeeld, ook een groot bedrijf... kan je zo je wachtwoord terug krijgen zonder problemen.

Omdat de site down is kun je hier even kijken of jou e-mail er ook bij staat: https://thepiratebay.se/torrent/7436152/yahoo-disclosure.txt
of via de een van de bekende fucktimkuik proxy's: http://labaia.ws/torrent/7436152/yahoo-disclosure.txt

Zelf heb ik (vroeger nog verplicht) een yahoo e-mail voor flickr, maar gelukkig sta ik er niet bij

[Reactie gewijzigd door wootah op 27 juli 2024 07:14]

[Proxy]

http://74.208.161.170:81/yahoo-disclosure.tar.gz

[MatthiasDS]

Ik lees volgend in het artikel:

De accountnamen en wachtwoorden zouden onversleuteld opgeslagen zijn geweest.

In de volgende zin gaat het nog over het vrijgeven van tabel- en kolomnamen. Dat doet me dan geloven dat de wachtwoorden inderdaad plaintext in de DB stonden.

[trixx]

Hoe kun je die conclusie trekken? Dat de tabel en columnnamen kunnen worden opgehaald zegt niets over de inhoud van het veld.

[MatthiasDS]

Dat zegt dat ze DB-toegang hebben verkregen.
En als ze vervolgens stellen dat de accountnamen en wachtwoorden onversleuteld werden opgeslagen (zoals in het artikel staat) lijkt het me dat ze het eveneens over de DB hebben.

[RemcoDelft]

Google doet hetzelfde voor z'n app-store. Klik maar eens op "password vergeten" en je krijgt je eigen password weer per email.

[MatthiasDS]

En waar vind ik die "password vergeten"? Ik heb me even uitgelogd op google play (ik vermoed dat dat de appstore is die je bedoelt?) en heb even naar "geen toegang tot mijn account" gegaan.

Ik krijg dan enkele keuzes (wachtwoord vergeten, gebruikersnaam vergeten, andere aanmeldproblemen). Kies ik voor "wachtwoord vergeten", krijg ik volgend te lezen:

Als u uw wachtwoord opnieuw wilt instellen, geeft u de gebruikersnaam op die u gebruikt om u aan te melden bij Google. Dit kan uw Gmail-adres zijn of een ander e-mailadres dat u heeft gekoppeld aan uw account.

Ik ga dit nu niet doen omdat ik mijn huidig wachtwoord wil behouden, maar het vetgedrukte is duidelijk: het gaat om opnieuw instellen van het wachtwoord en niet om het per mail versturen.


Kan je beschrijven wat jij doet om je password per mail terug te krijgen?

[Reactie gewijzigd door MatthiasDS op 27 juli 2024 07:14]

[xiphoid]

neck.nl encrypt alleen maar. Trouwens. Het is overal een prutje. Wat jammer is. Consequenties zijn voor de CEO, die volgens jaar niet zijn BMW meer kan vernieuwen.

[beyonix]

Is gestolen gegevens online posten de beste manier voor een white-hacker (geen uitspraak doend over de hackers in kwestie) om een beveiligingslek aan de orde te stellen? Door enkel de gehackte partij te notificeren weet je niet zeker dat er iets aan gedaan word, maar op zich is dat jouw probleem niet. Daar komt wel bij dat als dat de insteek is van alle white-hackers, het publiek niet weet hoe lek de organisatie is, als er veel lekken zijn. Op zich vind ik het goed dat dit soort dingen aan het licht komen, maar de gegevens jatten en neergooien opent mogelijk (tijdelijk) meer problemen dan het lek zelf. Dat is snel genoeg verholpen als Yahoo de lijst in handen krijgt. Maar past het niet beter in de hacker-ethiek om te zeggen dat je random geannonimiseerde samples online gooit ter bewijs, als ook statistieken (aantal records) van wat mogelijk was gegeven de tijd die je hebt, en misschien een hash van bepaalde database-backups?

Het zou niet verkeerd zijn als er een tool was die dit soort informatie van systemen kan trekken na inbreuk, helemaal als je er mee zou kunnen aantonen dat je jezelf geen directe toegang hebt gegeven tot de werkelijke data (alleen via die tool). Een utopie waarschijnlijk aangezien het niet zo makkelijk te bewijzen is dat je naast het gebruik van een dergelijke limiterende tool, niet dezelfde hack nog een keer hebt gedaan zonder die tool. En er is ook geen standaard manier om het systeem te laten weten (terugkomend in logs) dat een bepaalde exploit afkomstig is van een gecertificeerde tool of iets dergelijks. Met SQL zou je dat nog in een comment kunnen plaatsen misschien, maar voor buffer-overflows word dat al weer veel lastiger. Ik vind het toch wel intrigerend om na te denken over de condities waaronder dit soort toepassingen wel mogelijk zijn. Het white-hacker fenomeen zou van mij best maatschappelijk ondersteund mogen worden met wetgeving en bijpassende tools!

Edit: misschien een overheids-gesubsideerde white-hacker proxy, waar je alleen met registratie op kan? Dan kan de overheid alles loggen wat daar op gedaan word en eventuele geleden schade kan dan verhaald worden... Zien jullie mogelijkheden?

[Reactie gewijzigd door beyonix op 27 juli 2024 07:14]

[arjankoole]

Is gestolen gegevens online posten de beste manier voor een white-hacker (geen uitspraak doend over de hackers in kwestie) om een beveiligingslek aan de orde te stellen?

Een white-hat zal nooit gestolen gegevens publiceren. Hij zal eventueel de gegevens ge-annonimiseerd doorgeven aan betrouwbare media (zoals tweakers.net), maar dat pas na het bedrijf in kwestie een kans heeft gehad een analyse te doen, en de boel te repareren.

Dat is verantwoord gedrag in dergelijke situaties. dit is onverantwoord, puberaal aandachtstrekken. Ik hoop dan ook dat ze deze 'hackers' (hackers,my ass) in een cel weten te krijgen.

[KillerZero86]

Ik vind eigenlijk dat een bedrijf als Yahoo! eens fatsoenlijk om moet leren gaan met mijn gegevens. Uiteraard is het niet netjes dat de hackers het op het internet hebben gezet, maar na maanden van gekraakte bedrijven weet een bedrijf met zo bizar veel internet kennis in huis als Yahoo! nog steeds niet hoe het een mySQL injectie kan voor komen en hoe het passwords fatsoenlijk kan encrypten? De schuld ligt hier naar mijn mening vooral bij Yahoo!.

[oliveroms]

Crackers danwel scriptkiddies. Hackers zijn ze absoluut niet.

[petervda87]

inderdaad daarom heb ik dus net uit nieuwsgierigheid gwn een paar usernames en pw's gebruikt op zowel yahoo, aol and live mail... maar alle usernames icm met pw's werkt niet.

dus ik denk dat dit gewoon een valse actie is geweest om aandacht te trekken ofzo
ik trek deze conclusie door het feit... dat zowel oal, yahoo en live mail nog niks hierover hebben losgelaten.

edit- ik kom de d33ds.co nog wel op weliswaar niet snel maar ik kom erop

[Reactie gewijzigd door petervda87 op 27 juli 2024 07:14]

[Squ1zZy]

Er zijn er al enkele gewijzigt. Er zijn zeker nog wel accounts waarmee je kunt inloggen.

[WhatsappHack]

En another one bites the dust... Het is echt bizar hoe, zelfs nadat er al maandenlang enorme kraken worden gezet bij mega bedrijven, er nog steeds grote bedrijven (met voldoende IT resources!) zijn die echt enorm dom bezig zijn...

Je zou verwachten dat ze er iets van leren, although: eerlijk is eerlijk: er lopen wel meer idioten rond op het net, maar blijkbaar negeren ze allemaal wat er om hen heen gebeurd... Wie niet horen wil, moet maar voelen. Echt belachelijk dit...

Als het waar is natuurlijk, even wachten op bevestiging

[Verwijderd]

Wat boeit t hun? Ze moeten gewoon een kneiters hoge boete krijgen als ze gehacked worden dan zullen ze wel oppassen.

[Verwijderd]

Ik denk dat het ze wel dergelijk kan schelen, imago schaden. Alleen zal dat tegenwoordig wel minder zijn aangezien er bij meer en meer bedrijven blijkt dat de beveiliging niet op orde is.

Over dat met die boetes valt zeker wat te zeggen, alleen wie gaat die boetes dan innen? Een bedrijf als yahoo is over heel de wereld actief dus zou elk land waar ze dan actief zijn een boeten kunnen innen?

[Inrage]

Tis bijna een sport aan het worden. Misschien krijgen deze hackers net iets te veel media aandacht. Dat lijkt me op dit moment de drijfveer te zijn...

[Trinsec]

Wow. Net even een vriendin van me gewaarschuwd dat haar emailadres en wachtwoord publiek zijn geworden.
Dit is wel erg retarded dat het plaintext is opgeslagen. Hash met salt is toch wel het minste.

Update: volgens haar is haar l/p van de lijst al maanden oud, ze had het allang veranderd. Dit zijn dus blijkbaar oude gegevens. Waarom is het zo laat pas publiek gemaakt? Of is dit gewoon gekopieerd van een vorige hack? Maanden terug had Yahoo ook een hack gehad volgens haar, vandaar dat ze toen haar wachtwoord al had veranderd.

[Reactie gewijzigd door Trinsec op 27 juli 2024 07:14]

[hgoor]

Security blijft een probleem bij veel bedrijven... Probleem blijft dat gebruikers ook overal dezelfde gegevens blijven gebruiken, dus social engineering is ook altijd een probleem. Toch maar even snel checken of ik er niet tussen sta ;-)