És akkor 31 millió felhasználó személyes adata...

2017. december 11. 18:21 - Csizmazia Darab István [Rambo]

Megkerült? Biztonságban volt és maradt? Boldogan élt, míg meg nem halt? Ja nem, hát egyik sem, hanem éppen hogy sajnálatos módon kiszivárgott. Mindezt pedig egy olyan mulasztás révén, amit 2017-ben még leírni is szégyen.

"But the server wasn't protected with a password, allowing anyone to access the company's database of user records, totaling more than 577 gigabytes of sensitive data."

Nem igazán ez a megfelelő mondat, amit szívesen hallunk egy incidens kapcsán. Vagyis az adatszivárgás oka gyakorlatilag az volt, hogy a fejlesztő egyáltalán nem használt semmilyen hitelesítést az adatbázis-kiszolgáló védelmére.

A virtuális billentyűzet program Android és iOS alatt is elérhető, de a beszámolók szerint "csak" az Android rendszert üzemeltető felhasználók személyes adatai kerültek most veszélybe.

Az ellopott adatok magukban foglalták a felhasználók teljes nevét, e-mail címét, helyadatait, az adott készülék IMSI és IMEI számát, valamint annak gyártmányát és modelljét, az Android verzió számát, a felhasználók nyilvános Google-profilját és a felhasználók címjegyzékeinek tartalmát is.

Az elképesztő szó nem igazán írja le az esetet, és különösen az okkal kapcsolatosan érez az ember elemi fájdalmat.

Közben a i.type alapítója és igazgatója cáfolni igyekezett az értesüléseket, szerinte az "csak egy másodlagos adatbázis volt", illetve hogy az IMEI számot valójában nem is gyűjtötték, na és hogy a GPS adatok nem is voltak annyira pontosak, meg különben is.

Ezzel szemben az ESET biztonsági szakértője, Mark James elmondta, brutális hibának számít így, hitelesítés nélkül, bárki által hozzáférhető-letölthető módon személyes adatokat tárolni.

A felhasználóknak minden egyes mobilos alkalmazás letöltésénél érdemes óvatosnak lenni, ám különösen a billentyűzettel kapcsolatos alkalmazásoknál fontos a megbízhatóság, hiszen az ilyen appok természetüknél fogva hozzáférhetnek a felhasználók által beírt összes adatunkhoz, beleértve a legérzékenyebb információkat, például a jelszavainkat vagy a hitelkártya adatainkat.

26 komment

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

2017.12.11. 19:34:56

Függetlenül attól, hogy ezért a céget felszámolni, helyét sóval behinteni, felelősöket a farkuknál fogva fellógatni...
Nem ők voltak, akik valami nosql szart használtak, aminek a default konfigja olyan, hogy mindenkinek mindent megenged? Nem tudom, hol láttam ma vagy tegnap valami ilyesmit.

különvélemény 2017.12.12. 05:29:28

" és a felhasználók címjegyzékeinek tartalmát is."

Ez szimpla adatlopás a cég részéről.
Igazán megbüntethetné már az EU az összes olyan céget, kezdve a viberrel, amelyik ellopja a címjegyzék adatait.
Ugyanis a felhasználó csak a saját személyes adataival kapcsolatban nyilatkozhat, mikor elfogadja az EULA-t, máséról nem. Így ezeket letölteni/tárolni/kezelni 3. félnek bűncselekmény.

CoolKoon 2017.12.12. 07:49:11

Uff, ez azon kevés cikkek egyike, aminek az olvasásakor szó szerint leesett az állam O_o A "csak egy másodlagos adatbázis volt" kifogás meg gyakorlatilag a "(durva) vicc" kategória.

CoolKoon 2017.12.12. 08:12:32

"Nem ők voltak, akik valami nosql szart használtak, aminek a default konfigja olyan, hogy mindenkinek mindent megenged?" - Az lehet, de épeszű programozó akkor se csinál ilyet, pláne "üzleti" szoftvernél.

CoolKoon 2017.12.12. 08:13:11

@hullajelölt88: Szóval az előző posztom neked ment...

CoolKoon 2017.12.12. 08:15:32

@különvélemény: "Igazán megbüntethetné már az EU az összes olyan céget, kezdve a viberrel, amelyik ellopja a címjegyzék adatait." - Igen, tényleg megbüntethetné, csak az a baj, hogy az ilyen cégek általában EU-n kívül bejegyzett kis halak, amikkel vsz. nem igazán éri meg foglalkozni.

2017.12.12. 09:04:22

@CoolKoon: csak ha ez tényleg így van, akkor az említett adatbázis fejlesztőjének is van némi sara ezügyben.

CoolKoon 2017.12.12. 09:09:14

@hullajelölt88: De miért? Lehet, hogy az SQLite-al akar konkurálni, és (épp ezért) kliensoldali gyorsítótárazásra tervezték. Ahhoz meg nem kellenek mindenféle brutális biztonsági beállítások, mert fölösleges. Ha pedig valami programozó nem erre a célra használja, akkor magára vessen.

2017.12.12. 09:35:40

@CoolKoon: azért 2017-ben hadd legyen elvárás egy adatbázistól, hogy jelszóvédetten adjon csak ki bármit, legalább net irányban. Bármi legyen is az elsődleges célja. Szerintem. Sőt, ha a GDPR-t nézzük...:)

2017.12.12. 09:36:18

@kvadrillio: ezt az elmebeteg spammert kivágná valaki? Végleg.

2017.12.12. 09:40:11

@különvélemény: hát nem tudom. Korábban nem hallottam róla, tegnap már benne volt a felhasználási feltételekben, hogy milyen adatokat tárolhatnak és elvileg(!!!) ez kikapcsolható volt. Ha ez korábban is így volt, akkor a felhasználók egyeztek bele.

CoolKoon 2017.12.12. 09:43:05

@hullajelölt88: "azért 2017-ben hadd legyen elvárás egy adatbázistól, hogy jelszóvédetten adjon csak ki bármit" - Hát, akkor bizony van számodra egy rossz hírem: a Firefox pl. MINDEN adatodat kódolatlan, jelszó nélküli SQLite adatbázisokban tárolja. Most akkor égszakadás-földindulás, ugye?

Csizmazia Darab István [Rambo] · http://antivirus.blog.hu 2017.12.12. 09:46:47

Sziasztok srácok, köszi hogy benéztetek!

Felelősség pedig biztosan lenne, viszont a felelősségvállalás sajnos sokszor átmegy tagadásba, kummantásba, valóságszépítésba, és jönnek a SONY (eleinte tagadás), Diginotar (nincs tájékoztatás, szerintük nem jelentős esemény), Adobe (eleinte tagadták, "csak" 3 millió, utána pedig 150 millió ügyféladat, 3.2 millió hitel- és bankkártya adat, sőt forráskódok is) , LinkedIn (6.5 milla személyes adat, mert nincs salted hash), BKK, Posta, és napokig sorolhatók szánalmas mentegetődzések.

2018. május 25. sem fog mindent varázsütésre megoldani, de azért rászorítja az ilyen hozzáállású cégeket a jobb személyes adatkezelésre: a bünti 20 mEUR vagy a cég árbevételének 4%-a.

És ha nem cégként, hanem felhasználóként a mi védendő személyes adataink felől nézzük, akkor igenis tegyenek meg mindent, ami az "elvárható legnagyobb gondosság" meg az előírások szerint elvárható lenne.

dr. mesterséges színezék 2017.12.12. 10:11:34

@CoolKoon: "a Firefox pl. MINDEN adatodat kódolatlan, jelszó nélküli SQLite adatbázisokban tárolja. "

Ahogy az sqlite, úgy a kódolatlanság is csak részben igaz: a logins.json pl. értelemszerűen nem sqlite, és abban az encryptedUsername és encryptedPassword nem kódolatlan.
Amúgy igen, pl. history se tartozna illetéktelen betolakodóra.
Az, hogy a böngészőknél nem követelmény, hanem csak lehetőség a master jelszó használata, nem szabad, hogy hivatkozási alap legyen, hogyaszongyuk "mert például ott se": ezek elrettentő példák.

dr. mesterséges színezék 2017.12.12. 10:18:11

@Csizmazia Darab István [Rambo]: 'És ha nem cégként, hanem felhasználóként a mi védendő személyes adataink felől nézzük, akkor igenis tegyenek meg mindent, ami az "elvárható legnagyobb gondosság" meg az előírások szerint elvárható lenne.'

Szerintem az igazán kényszerítő erő nem a büntetés volna, hanem olyan kötelesség, hogy az érintett felhasználónak nem himihumi levelet küldünk arról, hogy minden fasza, de változtasd meg a jelszavadat, mert amúgy jó az, ha meg van változtatva, hanem konkrétan azzal, hogy "a hibánkból kiszivárogtak a nálunk tárolt adataid, kedves felhasználónk, ezért azt javasoljuk, hogy..."

2017.12.12. 10:31:31

@CoolKoon: kiadja netes interfészre??? Funkcionális analfabetizmus rulezik :D

CoolKoon 2017.12.12. 10:46:34

@hullajelölt88: Igen. Elég egy rosszul megírt szkript, és bárhova kiadja. De fölösleges ezen rugóznod, mert a lényeg, hogy az SQLite SE ilyen célra lett tervezve, ezért épeszű ember nem is használja ilyesmire.

2017.12.12. 11:00:59

@CoolKoon: a sqlite kiadja a netre??? De, ezen "rugózom", mert ha igaz, amit olvastam, egyszerűen rákapcsolódtak user/jelszó nélkül az adatbázisra és így vitték el az adatokat. Ez meg azért történhetett meg, mert az adatbáziskezelő default konfigja olyan volt, hogy mindenkinek mindent kiadott. A sqlite elsődlegesen lokális kapcsolaton dolgozik, nem is tudom, hálózatról elérhető-e egyáltalán. Hogy egy esetleges firefox hiba segítségével illetéktelen is hozzáférhet, az más téma.

CoolKoon 2017.12.12. 11:09:01

@dr. mesterséges színezék: "Ahogy az sqlite, úgy a kódolatlanság is csak részben igaz: a logins.json pl. értelemszerűen nem sqlite" - Ja igen, a JSON az SQLite mellett a másik , Firefox által használt technológia.
"abban az encryptedUsername és encryptedPassword nem kódolatlan." - Ahogy a key3.db-ben se (meg gondolom, a key4.db-ben se), igaz. De ezek közül egyik se az adatbázis biztonsági rendszerének "érdeme", hanem direkt, épp az adatbázis "hiányosságának" megkerülésére irányuló óvintézkedés.
"Az, hogy a böngészőknél nem követelmény, hanem csak lehetőség a master jelszó használata, nem szabad, hogy hivatkozási alap legyen" - Jó, de talán pont ezért ritka dolog, hogy fontos, körültekintő biztonsági intézkedéseket igénylő adatokat (pl. személyes adatokat) SQLite-ra, vagy valamilyen hasonló technológiára építenek.

CoolKoon 2017.12.12. 11:14:04

@hullajelölt88: "De, ezen "rugózom"" - Vagyis terelsz.

"amit olvastam, egyszerűen rákapcsolódtak user/jelszó nélkül az adatbázisra és így vitték el az adatokat" - Akkor még egyszer: mi van, ha az adatbázis alapból NEM szerveoldali használatra lett tervezve? Vagy te akkor is nyafogni fogsz, ha a kispolszki tengelye eltörik a rápakolt tehet miatt, mondván, hogy "há autó, bírja már az ólomnehezékeim súlyát bazmeg!"?

"A sqlite elsődlegesen lokális kapcsolaton dolgozik, nem is tudom, hálózatról elérhető-e egyáltalán." - Igen, mert NEM arra tervezték, hogy szerveroldali alkalmazásokat szolgáljon ki.

2017.12.12. 11:38:03

@CoolKoon: terelek. Jó. Itt befejeztem, képzelj amit akarsz. Hülyeséget hajtogatsz,de mindegy.

Muad\\\'Dib 2017.12.12. 11:46:55

@hullajelölt88:
Nem, nem beszél hülyeséget. Ha egy fejlesztő KÉPTELEN elolvasni egy termék dokumentációját, sőt még arra is képtelen, hogy megállapítsa mire használható meg mire nem, akkor az nem a termék sara (még akkor sem, ha amúgy az is egy rakás fo*). Ember itt nem egy kibas*ott windows 10-ről beszélünk, ahol nem elvárás, hogy a felhasználó értsen hozzá. Ha egy fejlesztő, devop, vagy akárki nem jut el odáig, hogy mit kell a default beállításról átállítani, hogy az neki megfeleljen akkor ott nagyon mély gond van. Meg a fejekben is, ahol az a nézet, hogy a default beállítás olyan kéne legyen, amin joskapista bt hobbiprogramozója mindenféle hozzáértés nélkül rögtön high tech secure infrastruktúrát épít ki.

CoolKoon 2017.12.12. 12:14:44

@hullajelölt88: "Hülyeséget hajtogatsz,de mindegy." - Mivel (pl. @dr. mesterséges színezék -el ellentétben) annyira kínosan kerülöd a konkrétumokat, hadd kérdezzem már meg: használtál már valaha is BÁRMILYEN adatbáziskezelő szoftvert? Esetleg (próbaképp) intéztél valamilyet az AWS-en keresztül? Vagy próbáltál már meg akárcsak sima XML vagy JSON fájlba lementeni valamilyen struktúrát?

2017.12.12. 13:10:58

@Muad\\\'Dib: egy szóval nem mondtam, hogy itt a t. fejlesztő egy kicsit is ártatlan. Hülye/dilettáns/mindkettő. Ettől még kibaszott nagy felelőtlenség egy adatbázis szervertől, illetve a fejlesztőitől, ha netről elérhető és az a default, hongy authentikácio nélkül bárki eléri a benne tárolt adatokat. Nem, dBaseIII-tól és az általam ismert, csak lokálisan elérhető sqlite-tól nem várok ilyesmit, azok csak fájlok.

különvélemény 2017.12.13. 06:00:39

@hullajelölt88:
Nem ő dönti el, hogy milyen adatokat tárolhat, hanem a törvények.
Mint írtam, ha a te telefonkönyvedben benne van az én nevem, címem, telefonszámom, emailcímem, stb. mert mostanában bármit bele lehet írni, arra te nem adhatsz felhatalmazást, mert nem a te adatod.

2017.12.13. 07:27:08

@különvélemény: ez jogos. Viszont ezen az alapon kezdhetnék a fészbúkkal is. Bár nem tudom, megvan-e még a jö szokásuk, hogy a feltöltött képeken látható embereket azonosítják... (és az mindegy, hogy publikálják vagy csak tárolják)
süti beállítások módosítása