A Meari babakamera biztonsági rése: mit csinál másképp a Timmy?

A Galaxus szabadon elérhető babafigyelő-kamera-felvételekről számolt be; a The Verge szerint körülbelül 1,1 millió Meari eszköz volt érintett. Számomra a tanulság egyértelmű: a bejelentkezés nem védi a gyerekszobát, ha a mögötte lévő platform nem választja szét megfelelően az üzeneteket, képeket vagy kulcsokat eszközönként. Timmy nem old meg minden biztonsági problémát a világon. De Timmy kritikus média- és párosítási titkai nem egy felhőalapú kamerás platformon vannak.

Mi romolhatott el a Meari esetében

A nyilvános beszámolók egy más márkák neve alatt is értékesített platformot írnak le. Számos ismert márka adott el olyan kamerákat, amelyek ugyanarra a Meari/CloudEdge infrastruktúrára támaszkodtak. Ezért fontos az eset: ha egy közös platform hibásan húzza meg a jogosultsági határt, annak nem egyetlen gyenge kamera, hanem egy teljes eszközparkot érintő kitettség a következménye.

A beszámolókban szereplő minta túlmutat a gyenge alapértelmezett jelszavakon. A források eszközönként nem kellően korlátozott MQTT-üzeneteket, nyilvánosan elérhető képhivatkozásokat, gyenge képelrejtést, valamint statikus vagy az alkalmazásból kinyerhető kulcsokat említenek. Ez platformhiba: az infrastruktúra olyan adatokat fedhetett fel, amelyeknek sosem lett volna szabad másik fiók számára elérhetővé válniuk.

A felhőalapú kamerák kockázata	Timmy megoldása
A háttérrendszer képeseményeket tárol vagy továbbít.	Timmy nem tárol felhőarchívumot a gyerekszobai képekről; a média élő WebRTC-kapcsolaton megy.
Egy közvetítőnek vagy tárhelynek minden eszköznél tökéletesen kell kezelnie a jogosultságokat.	A Firestore csak párosítási és jelzésátviteli adatokat visz; az SDP/ICE titkosítva kerül bele.
A statikus kulcsok egy teljes eszközparkot érinthetnek.	Minden párosítás saját, az eszközökön P-256 ECDH-val származtatott kulcsot hoz létre.
Egy reléútvonalat könnyű összetéveszteni a médiához való hozzáféréssel.	A TURN titkosított SRTP-csomagokat továbbít, de nem kapja meg a médiakulcsokat.

Hogyan hozza létre Timmy a titkot

A négykarakteres Timmy-kód szándékosan nem maga a titok. A kódban csupán találkozási pontként szolgál: az alkalmazás ebből egy meetingKey találkozókulcsot vezet le, így mindkét eszköz megtalálja ugyanazt a Firestore-ban zajló nyilvánoskulcs-cserét. A privát ECDH-kulcsok sosem hagyják el az eszközöket.

Ezután mindkét eszköz ugyanazt a P-256 ECDH megosztott titkot számítja ki. A párosítási kulcs helyben jön létre. A kétjegyű SAS a megosztott titokból és mindkét, rendezett nyilvános kulcsból származik. Ha valaki manipulálja ezt a kulcscserét, az eszközök különböző számokat mutatnak, így a felhasználók tudják, hogy nem szabad jóváhagyniuk a párosítást.

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

Egyszerűsített Timmy biztonsági lánc: a Firestore a találkozás és a jelzésátvitel csatornája; a TURN csak relé; a média WebRTC-titkosítással védett marad.

Miért nem lehet észrevétlenül figyelni a WebRTC-médiát

A WebRTC nem egyszerűen annyi, hogy „videót küld”. Mielőtt megkezdődne a média továbbítása, az eszközök DTLS-kézfogást hajtanak végre. A hang és a videó SRTP-kulcsai ebből a biztonságos átviteli kapcsolatból származnak. A médiacsomagokat ezután SRTP-vel titkosítják. Egy TURN-szerver továbbíthatja ezeket a csomagokat, de nem kapja meg a hang vagy a videó visszafejtéséhez szükséges kulcsokat.

Timmy ezt megelőzően még egy réteget hozzáad: az olyan jelzésátviteli adatokat, mint az SDP-ajánlatok, SDP-válaszok és ICE-jelöltek, AES-256-GCM titkosítással védi, mielőtt azok elérnék a Firestore-t. A Firestore segít az eszközöknek a kapcsolat egyeztetésében; nem arra való, hogy titkosítatlan videó, hang vagy titkosítatlan jelzésátviteli adat legyen benne.

Amit Timmy továbbra sem állít

Egyetlen komoly babafigyelő sem állíthatja, hogy feltörhetetlen. Ha egy telefon kompromittálódik, bármely alkalmazás támadható. Egy rosszindulatú alkalmazásverzió megváltoztatja a kockázati modellt. A szerverkonfigurációnak továbbra is helyesnek kell maradnia. Timmy szerényebb állítása architekturális: elkerüli a háttérrendszer által olvasható, gyerekszobából származó médiaanyagokat, és a biztonságkritikus párosítási logikát a nyilvános alapprojektben ellenőrizhetővé teszi.

Kérdések, amelyeket érdemes feltenni bármely babafigyelő kameráról

Tárol a gyártó képeket vagy videókat?
A média-URL-ek privátak, rövid életűek és eszközönként jogosultsághoz kötöttek?
A kulcsok eszközönként vagy párosításonként jönnek létre, nem pedig statikusan az alkalmazásban?
Egy közvetítő csak az Ön tulajdonában lévő eszközhöz tartozó üzeneteket képes kézbesíteni?
A párosítás lehetővé teszi, hogy az ember észrevegye a közbeékelődéses támadást?

A kód megtekintése

Források

Babafigyelő kamerák felvételei szabadon elérhetők · Galaxus
Egymillió babafigyelő és biztonsági kamera volt könnyen megtekinthető hackerek számára · The Verge
senki sem teszi a babát a sarokba · Sammy Azdoufal
Szülői útmutató ugyanerről az esetről · Baby Monitor Timmy

← Vissza a bloghoz