Verifications.io leak

Security-all

In February 2019, the email address validation service verifications.io suffered a data breach. Discovered by Bob Diachenko and Vinny Troia, the breach was due to the data being stored in a MongoDB instance left publicly facing without a password and resulted in 763 million unique email addresses being exposed. Many records within the data also included additional personal attributes such as names, phone numbers, IP addresses, dates of birth and genders. No passwords were included in the data. The Verifications.io website went offline during the disclosure process, although an archived copy remains viewable.

Compromised data: Dates of birth, Email addresses, Employers, Genders, Geographic locations, IP addresses, Job titles, Names, Phone numbers, Physical addresses

Most éjszaka kaptam a leakről emailt a have I been pwned-tól. Elég szép kis adatbáziskapcsolásnak tűnik, részletek azoknak, akik nem kaptak mailt. Az nem igazán derül ki számomra, hogy az email címből hogyan építették tovább a másik adatokat, pedig ez lett volna érdekes, főleg az érdekelt volna, hogy az én emailcímem mellett milyen adatok vannak fent, de ez ebből nem derül már ki.
A cikkekben közöltek alapján mindenkinek volt email címe az adatbázisban, a többi adat pedig már nem minden emailhez volt hozzátársítva, így pwned értesítése tök haszontalannak tűnik jelen esetben, mivel úgy tűnik az érintett adatok köre minden emailcímnél egy egyedi kombináció. Itt az ideje leiratkozni?

  • 2217 megtekintés

( hajbazer v | 2019. 03. 10., v – 13:35 )

Itt az ideje nem centralizáltan tárolni a felhasználók adatait, feltétlen bizalmat követelve tőlük, marketingszövegekkel elhitetve velük, hogy az adataik biztonságban vannak.

"Remove spamtraps and hard bounces with our email validation and email verification service. Keep your email lists and data clean with good email hygiene." - hirdeti a Google-ba SEO-zott marketing bullshit, az azóta már elérhetetlen oldal keresési találata alatt.

Csak gratulálhatunk nekik. Sikerült a második legnagyobb gyűjteménynek járó helyet elvinniük ( a Wired cikke szerint az elsőt). A vállalati arrogancia, a költségoptimalizálgatás, a hozzá nem értő, olcsó munkaerő alkalmazása, az ejj jó lesz az úgy is örökérvényű rendezőelv mind-mind meghozta gyümölcsét.

Különösen felháborító, hogy a cég hirdetőktől (értsd: marketing bullshitterektől és spammerektől) kapott e-mail címeket és személyes adatokat tárolt, azzal a céllal, hogy a spam szűrőket kikerülve ellenőrizze, hogy a hirdetők néphülyítése bizonyíthatóan célba ért-e. Persze, miért is vigyáztak volna az adatokra, ha nem is az övéik voltak.

( toMpEr | 2019. 03. 10., v – 14:46 )

Úgy tűnik a mongodb a legjobb dolog, ami a hackerekkel történt az elmúlt 20 évben.

Korábban: Unsecured MongoDB databases expose Kremlin's backdoor into Russian businesses

The researcher says that after his initial finding, he later found the same "admin@kremlin.ru" account on over 2,000 other MongoDB databases that had been left exposed online, all belonging to local and foreign businesses operating in Russia.
Examples include databases belonging to local banks, financial institutions, big telcos, and even Disney Russia.

https://www.zdnet.com/article/unsecured-mongodb-databases-expose-kremli…

Fun-fact: a wired.com meglátogatásával közel 100 céghez (nem számolva azokat, akiknek ezek a céget tovább adják) jutnak el a meta-adataid: https://imgur.com/UjqPdIv

Én magam is dolgozok MongoDB-vel, és nem is a programmal van a gond, hanem inkább a default beállításokkal és a doksival.
Amikor megismerkedtem vele, sokáig nem találtam, hogy lehet rávenni, hogy bármi hitelesítést kérjen. Ráadásul a dokumentációban a példa-programok nagy része úgy volt felépítve, hogy auth nélküli adatbázissal dolgozom.
Persze idővel megtaláltam, mit hogy lehet, de az szomorú, hogy nem ez az alap beállítás, és nem is próbálják erőltetni.
Első indításkor például jó lenne, ha kötelezően beállíttatna egy jelszót, és a későbbiekben soha többé nem fogadna el semmit sem hitelesítés nélkül.

Nagy Péter
www.ddo.hu

( istii | 2019. 03. 10., v – 16:27 )

Több domain-al is feliratkoztam, 2e+ címből 17-et érintett a jelenlegi szivárgás. Biztosan megtartom a feliratkozást, jó tudni, hogy milyen mail címek érintettek.

( procika v | 2019. 03. 10., v – 19:53 )

Saját címem meg ügyfél is érintett. Ez egyáltalán milyen oldal? Nem is rémlik, hogy lett volna dolgom vele. Szerk.: A MongoDB fejlesztőinek a kezét kellene tördelni, hogy alapból minden auth nélkül elérhető nem csak localhostról. Én is beszívtam évekkel ezelőtt. Megkértek dobjam fel, a szejlesztőknek kell. Én feltettem, de nem ismertem, idő meg volt megnézni milyen hibák vannak. Meg sem gondoltam ekkora kaki.

> Saját címem meg ügyfél is érintett. Ez egyáltalán milyen oldal? Nem is rémlik, hogy lett volna dolgom vele.

How this all works:
- Someone uploads a list of email addresses that they want to validate.
- Verifications.io has a list of mail servers and internal email accounts that they use to “validate” an email address.
- They do this by literally sending the people an email. If it does not bounce, the email is validated.
- If it bounces, they put it in a bounce list so they can easily validate later on.

Szóval ez ilyen API volt, ami megmondta egy emailről, hogy él-e még. Mondjuk, hogy miért kellett zip / phone / address / gender / user IP / DOB a db-be azt nem tudom

- pontosan: Dates of birth, Email addresses, Employers, Genders, Geographic locations, IP addresses, Job titles, Names, Phone numbers, Physical addresses
- ezek nem derülnek kia bounce/nem bounce-ból, valamint fogalmam sincs, hogy milyen banánköztársaságban működnek ahol ezeket jogszerűen össze lehet rakni
- gyanúm szerint valami maltegoszerűséget akartak összecsiholni, és egy szép nagy adatbázist összeharácsolni mindenhonnan ahol csak értek bármit, és mindezt nem szerették volna kirakni a kirakatba de valaki lenyúlta az adatbázist.

Persze, nyilván a MongoDB fejlesztőinek a hibája, ha kellően nemtörődöm, megélhetési mérnök úr vagy ahhoz, hogy körültekintően járj el, amikor rád bíznak egy ilyen feladatot. Rohadjon meg az összes MongoDB fejlesztő, mert nem a kényelmeskedők out-of-the-box hülyebiztos biztonságát biztonság illúzióját valósították meg.

Ebben még egyet is tudnék érteni, viszont ha a MongoDB definíció szerint így működik, annak fel nem ismerése nem a MongoDB mérnökök felelőtlensége. Ha veszel egy számzáras lakatot, ami alapból 000-n nyílik és te lusta (vagy hülye) vagy átállítani a nyitó számot, az nem a gyártó (vagy az eladó üzlet) felelőssége, ha később Móricka bepróbálkozik és kinyílik neki 000-án (mint az összes többi marháé, akiét előtte próbálta).

Egészen egyszerűen arról van itt szó, hogy néhány burzsoá szociopata marketingstrici csinált egy céget, ami 700 millió felhasználó személyes adataival üzérkedett, őket verifikált reklámfelületként értékesítendő (értsd: a felhasználókat szükségtelen dolgok megvásárlására birkaterelendő), de akkora sóher banda voltak, hogy az adatbázist is egy alulfizetett okostelefongenerációs IQ=80 gyakornok tapicskolta össze nekik, mert csak őt voltak hajlandóak megfizetni.

Az adatbázis biztonságát és az abba való bejutást hasonlítottam össze a lakattal.

Ha előfordul olyan feature, ami nincs ledoksizva és ennek ellenére mégis default hozzáférést biztosít az adatbázishoz (akármilyen jogosultsággal), az a fejlesztők hanyagsága és felelőtlensége. De nagyjából idáig terjed. Onnantól, hogy le van doksizva, az üzemeltető fősodratú tapicskoló segédmunkatárs felelőssége. Ahogy a Verifications.io esetében is ez a helyzet.