Kahinaan sa seguridad ng Meari baby camera: ano ang naiiba sa Timmy

Iniulat ng Galaxus na malayang naa-access ang mga recording mula sa baby camera; iniulat naman ng The Verge na humigit-kumulang 1.1 milyong Meari device ang apektado. Para sa akin, malinaw ang aral: hindi napoprotektahan ng login ang silid ng sanggol kung hindi malinaw na naihihiwalay ng platform sa likod nito ang mga mensahe, larawan, o key para sa bawat device. Hindi nalulutas ng Timmy ang lahat ng problema sa seguridad sa mundo. Pero ang kritikal na media at mga lihim sa pairing ng Timmy ay wala sa loob ng cloud-camera platform.

Ano ang mukhang pumalya sa kaso ng Meari

Inilalarawan ng mga pampublikong ulat ang isang white-label platform. Maraming nakikitang brand ang nagbenta ng mga camera na umaasa sa parehong Meari/CloudEdge infrastructure. Kaya mahalaga ang insidenteng ito: kapag mali ang authorization boundary sa isang shared platform, hindi lang isang mahina na camera ang nalalantad kundi buong fleet ng mga device.

Hindi lang ito tungkol sa mahihinang default password. Inilalarawan ng mga source ang mga MQTT message na walang sapat na kontrol sa subscription para sa bawat device, mga image URL na maaabot ng publiko, mahinang pagtatago sa mga larawan, at mga static key o key na maaaring makuha mula sa app. Pagkabigo ito ng platform: maaaring maglantad ang imprastraktura ng data na hindi kailanman dapat makita ng ibang account.

Panganib ng cloud camera	Disenyo ng Timmy bilang tugon
Nag-iimbak o namamahagi ang backend ng mga image event.	Walang cloud archive ang Timmy para sa mga larawan sa silid ng sanggol; live WebRTC ang media.
Kailangang perpektong i-authorize ng broker o bucket ang bawat device.	Pairing at signaling data lang ang dumadaan sa Firestore; naka-encrypt ang SDP/ICE bago ito isulat.
Maaaring makaapekto ang static key sa buong fleet.	Bawat pairing ay gumagawa ng sarili nitong key na mula sa P-256 ECDH sa mga device.
Maaaring mapagkamalan ang relay path na access sa media.	Nagpapasa ang TURN ng mga naka-encrypt na SRTP packet pero hindi nito natatanggap ang media key.

Paano ginagawa ng Timmy ang lihim

Sadyang hindi ang apat na character na Timmy code ang lihim. Sa code, rendezvous point lang ito: mula rito ay bumubuo ang app ng isang meetingKey para mahanap ng parehong device ang parehong palitan ng public key sa Firestore. Hindi kailanman umaalis sa mga device ang private ECDH key.

Pagkatapos, kinukuwenta ng dalawang device ang iisang P-256 ECDH shared secret. Lokal na binubuo ang pairing key. Ang dalawang-digit na SAS ay binubuo mula sa shared secret at sa dalawang public key na inayos sa parehong pagkakasunod-sunod. Kung may makialam sa pagpapalitan ng key, magkaibang numero ang ipapakita ng mga device, kaya malalaman ng mga user na hindi nila dapat kumpirmahin ang pagpapares.

sequenceDiagram
    participant Baby as Baby device
    participant Firestore as Firestore meeting point
    participant Parent as Parent device
    participant Turn as TURN relay

    Baby->>Baby: Generate P-256 ECDH keypair
    Parent->>Parent: Generate P-256 ECDH keypair
    Baby->>Firestore: Write public key only under meetingKey
    Parent->>Firestore: Write public key only under meetingKey
    Firestore-->>Baby: Parent public key
    Firestore-->>Parent: Baby public key
    Baby->>Baby: Compute sharedSecret + SAS
    Parent->>Parent: Compute sharedSecret + SAS
    Baby-->>Parent: Humans compare SAS on both screens
    Baby->>Firestore: Write SDP/ICE encrypted with AES-256-GCM
    Parent->>Firestore: Write SDP/ICE encrypted with AES-256-GCM
    Baby-)Turn: WebRTC media as DTLS/SRTP packets
    Turn-)Parent: Relay forwards encrypted packets
    Note over Turn: TURN sees network metadata, not media keys

Pinasimpleng security chain ng Timmy: ang Firestore ay para sa rendezvous at signaling transport; relay lang ang TURN; nananatiling naka-encrypt sa WebRTC ang media.

Bakit hindi basta mapapanood nang palihim ang WebRTC media

Hindi lang basta “magpadala ng video” ang WebRTC. Bago dumaloy ang media, nagsasagawa ang mga device ng DTLS handshake. Mula sa secure na transport na ito ang SRTP key para sa audio at video. Pagkatapos, naka-encrypt bilang SRTP ang mga media packet. Maaaring ipasa ng TURN server ang mga packet na iyon, pero wala itong key na kailangan upang mabuksan ang audio o video.

May dagdag na layer ang Timmy bago iyon: ang signaling data gaya ng SDP offer, SDP answer, at ICE candidate ay naka-encrypt gamit ang AES-256-GCM bago makarating sa Firestore. Tinutulungan ng Firestore ang mga device na mag-negotiate; hindi ito lugar para sa cleartext na video, audio, o signaling.

Ano ang hindi pa rin inaangkin ng Timmy

Walang seryosong baby monitor ang dapat mag-claim na imposible itong ma-hack. Kapag nakompromiso ang phone, puwedeng atakihin ang anumang app. Iba ang risk model kapag may malisyosong app build. Dapat manatiling tama ang server configuration. Mas limitado ang claim ng Timmy, at tungkol ito sa arkitektura: iniiwasan nito ang media artifact mula sa silid ng sanggol na nababasa ng backend at ginagawang masusuri ang security-critical na pairing logic sa pampublikong core project.

Mga tanong na dapat itanong tungkol sa anumang baby camera

Nag-iimbak ba ang vendor ng mga larawan o clip?
Pribado ba ang mga media URL, panandalian lang ba ang bisa, at may authorization ba para sa bawat device?
Ginagawa ba ang mga key para sa bawat device o pairing, sa halip na static sa loob ng app?
Makakapaghatid ba ang broker ng mga mensahe para lang sa device na talagang pagmamay-ari mo?
Kaya ba ng pairing na ipaalam sa tao kung may man-in-the-middle na pagtatangka?

Basahin ang code

Mga Source

Malayang naa-access ang mga recording mula sa baby camera · Galaxus
Isang milyong baby monitor at security camera ang madaling mapanood ng mga hacker · The Verge
walang naglalagay ng baby sa sulok · Sammy Azdoufal
Gabay para sa mga magulang tungkol sa parehong insidente · Baby Monitor Timmy

← Bumalik sa blog