Backblaze B2 - Facebook adatszivárgási biztonsági incidens

Adatszivárgási biztonsági incidensbe keveredett a Backblaze felhő alapú adattárolással foglalkozó cég, amely leginkább az évenként publikált merevlemez megbízhatósági statisztikákról lehet ismerős a HUP olvasói számára. Egy Twitter-felhasználó lett figyelmes arra, hogy miközben megpróbált letölteni egy backupot a Backblaze B2 webes felületét használva, a böngésző állapotsorában megjelent a "Várakozás a facebook.com-ra" üzenet. Az oldal forrását megvizsgálva észrevette, hogy a beépített FB tracking-pixel elküldi a B2 bucket-ben szereplő fájlok neveit és méreteit a facebook.com-nak betöltődés közben. A FB tracking-pixel akkor is jelen volt, ha a felhasználó korábban nem engedélyezett semmilyen követő-szkriptet az adatvédelmi beállításokban.

A cég elismerte a biztonsági incidenst és kijavította a hibát. Részletesebb tájékoztatást a vizsgálatok lefolytatása után ígérnek.

Hozzászólások

Szerencsére azért ez viszonylag korlátozott incidens és simán lehet egy szokott supply chain attack, vagyis megint a kurva indiaiak.

FB-os tracking szkriptről van szó, nincs szükség supply chain attackra, hogy adatszivárgás legyen. :) Ott van pl. az autoconf beállítás:

The Facebook pixel will send button click and page metadata (such as data structured according to Opengraph or Schema.org formats) from your website to improve your ads delivery and measurement and automate your pixel setup.

Tehát ha valami ehhez hasonló beállításon átsiklottak a tracking-pixel berakásánál, akkor a FB szkript simán beolvashatott pár meta-adatot az admin felületről, amit nem neki szántak eredetileg és már meg is van az adatszivárgás.

Felmerül inkább a kérdés, hogy mi a búbánatért kell 3rd party tracking szkripteket rakni a fizető ügyfeleknek szánt belső admin felületre?

Felmerül inkább a kérdés, hogy mi a búbánatért kell 3rd party tracking szkripteket rakni a fizető ügyfeleknek szánt belső admin felületre?

egy fizetos belso admin feluletre miert is akarna adatszivarogtato cuccot berakni? logikai ellentmondas, a ceg ugyis tud minden infot (*kiveve ha kodolva van, de akkor is egyszerubb sajat scriptbe rejteni a lopo cuccot), minek neki egy facebook fele tracking pixel? 

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Felmerül inkább a kérdés, hogy mi a búbánatért kell 3rd party tracking szkripteket rakni a fizető ügyfeleknek szánt belső admin felületre?

Mert oda is kell még egy buborék befektetőék jakuzzijába. Valami onlinemarketing-szélhámosnak meg el is hitték, hogy lesz tőle.

Baszki, egyre tobbet gondolkodok azon, hogy feher listas tuzfal kene a gepemre, hogy a kifele kapcsolodas ip/domain alapjan el legyen dobva, pontosabban kap a bongeszo egy body perbody oldalt azt jonapot.

Csak kene egy lista, hogy mi lett igy megvalaszolva, hogy lehessen feher listara tenni, nameg a valtozo dolgok lekezelese is maceras lesz, az tuti.

Ahh, p1csaba az egesszel, lehet, hogy jobb strategia az elarasztasos modszer, minden bongeszo general veletlenszeru hulyesegeket, hogy ne lehessen profilozni az embert. Vagy az eldobhato bongeszoket kellene tobbet hasznalnom? Qubes alatt ez nem gond, de telefonrol, Android alatt en is bent vagyok az olban, es csak begetek a tobbi birka mellett. Ehh.

A Pi-hole elvileg tudja, amit leírtál, vagy ha nem akarsz üzemeltetéssel foglalkozni, akkor a https://nextdns.io/ Mindkettő már DNS szinten megfogja a nem kívánt elemeket.

A böngészős fehérzaj-generátorral az a gond, hogy ha nem csinálják elegen, akkor pontosan ellenkező hatást fejt ki. :) Inkább épp fordítva kell gondolkodni: a böngésződ lenyomata egyezzen meg a legelterjedtebbel, akkor egyedileg nem tudnak vele beazonosítani.

Kijöttek egy magyarázattal tegnap. Március 8-án elindítottak egy reklámkampányt a Google Tag Manager-rel, ami kirakosgatta a FB tracking pixelt is az oldalakra. Csak azt felejtették el beállítani, hogy a bejelentkezett felhasználók admin felületére ne kerüljön ki a tracking pixel...