Saugumo paaiškinimas

Meari kūdikių kamerų saugumo spraga: kuo „Timmy“ skiriasi

„Meari“ atvejis rodo, kad vien sklandžiai veikianti prisijungimo sistema saugumo neužtikrina. Kūdikio stebėjimo saugumas priklauso nuo sistemos architektūros, prieigos teisių ir raktų valdymo.

„Galaxus“ pranešė apie laisvai prieinamus kūdikių kamerų įrašus, o „The Verge“ – apie maždaug 1,1 mln. paveiktų „Meari“ įrenginių. Man išvada paprasta: prisijungimo sistema neapsaugo vaiko kambario, jei už jos esanti platforma tinkamai neatskiria kiekvieno įrenginio pranešimų, vaizdų ar raktų. „Timmy“ neišsprendžia visų pasaulio saugumo problemų. Tačiau saugumui itin svarbūs „Timmy“ medijos perdavimo ir susiejimo slaptieji duomenys nelaikomi debesijos kamerų platformoje.

Kas, regis, nepavyko Meari atveju

Viešuose pranešimuose aprašoma baltosios etiketės platforma. Daugelis rinkoje matomų prekių ženklų pardavinėjo kameras, naudojusias tą pačią „Meari“ / „CloudEdge“ infrastruktūrą. Todėl šis incidentas svarbus: kai bendroje platformoje neteisingai nustatomos prieigos teisių ribos, pažeidžiama ne viena silpnai apsaugota kamera, o visas įrenginių parkas.

Aprašytos problemos neapsiriboja silpnais numatytaisiais slaptažodžiais. Šaltiniuose minimi MQTT pranešimai be pakankamos kiekvieno įrenginio prenumeratos kontrolės, viešai pasiekiami vaizdų URL, silpnas vaizdų užmaskavimas ir statiniai arba iš programėlės išgaunami raktai. Tai platformos lygmens saugumo spraga: infrastruktūra galėjo atskleisti duomenis, kurie niekada neturėjo būti prieinami kitai paskyrai.

Debesų kamerų rizikaKaip „Timmy“ suprojektuota kitaip
Serverio sistema saugo arba platina su vaizdais susijusius įvykių duomenis.„Timmy“ neturi vaiko kambario vaizdų debesijos archyvo; medija realiuoju laiku perduodama per „WebRTC“.
Pranešimų tarpininkas arba debesijos saugykla turi nepriekaištingai tikrinti kiekvieno įrenginio prieigos teises.„Firestore“ perduoda tik susiejimo ir signalizavimo duomenis; SDP/ICE prieš įrašant užšifruojami.
Statiniai raktai gali paveikti visą įrenginių parką.Kiekvieno susiejimo metu įrenginiuose sukuriamas atskiras iš P-256 ECDH išvestas raktas.
Retransliavimo kelias gali būti klaidingai palaikytas prieiga prie medijos.TURN persiunčia užšifruotus SRTP paketus, bet negauna medijos raktų.

Kaip „Timmy“ sukuria slaptąjį raktą

Keturių simbolių „Timmy“ kodas sąmoningai nėra slaptasis raktas. Kode jis yra tik susitikimo taškas: programėlė iš jo išveda meetingKey , kad abu įrenginiai galėtų rasti tą patį „Firestore“ viešųjų raktų apsikeitimą. Privatūs ECDH raktai niekada nepalieka įrenginių.

Tada abu įrenginiai apskaičiuoja tą pačią P-256 ECDH bendrąją paslaptį. Susiejimo raktas išvedamas pačiuose įrenginiuose. Dviejų skaitmenų SAS išvedamas iš bendrosios paslapties ir abiejų surikiuotų viešųjų raktų. Jei kas nors įsikiša į šį raktų apsikeitimą, įrenginiai parodo skirtingus skaičius ir taip įspėja naudotojus nepatvirtinti susiejimo.

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
        

Supaprastinta „Timmy“ saugumo grandinė: „Firestore“ naudojama susitikimui ir signalizavimui perduoti; TURN yra tik relė; medija lieka užšifruota per „WebRTC“.

Kodėl „WebRTC“ medijos negalima nepastebimai stebėti

„WebRTC“ nėra vien tik vaizdo siuntimas. Prieš pradedant perduoti mediją, įrenginiai atlieka DTLS saugaus ryšio užmezgimo procedūrą. Iš šio saugaus ryšio išvedami garso ir vaizdo SRTP raktai. Tada medijos paketai užšifruojami naudojant SRTP. TURN serveris gali persiųsti šiuos paketus, tačiau negauna raktų, kurių reikia garsui ar vaizdui iššifruoti.

„Timmy“ prieš tai prideda dar vieną sluoksnį: signalizavimo duomenys, tokie kaip SDP pasiūlymai, SDP atsakymai ir ICE kandidatai, prieš pasiekdami „Firestore“ užšifruojami AES-256-GCM. „Firestore“ padeda įrenginiams susiderėti; joje nenumatyta laikyti nešifruoto vaizdo, garso ar nešifruotų signalizavimo duomenų.

Ko „Timmy“ vis dar neteigia

Joks rimtas kūdikio stebėjimo sprendimas neturėtų teigti, kad jo neįmanoma nulaužti. Jei telefoną užvaldo įsilaužėliai, gali būti atakuojama bet kuri programėlė. Kenkėjiška programėlės versija pakeičia rizikos pobūdį. Serverio konfigūracija taip pat turi išlikti tinkama. Siauresnis „Timmy“ teiginys susijęs su jos architektūra: serveryje nėra vaiko kambario medijos duomenų, kuriuos jis galėtų perskaityti, o saugumui itin svarbią susiejimo logiką galima patikrinti viešame pagrindinio kodo projekte.

Klausimai apie bet kurią kūdikio kamerą

  • Ar tiekėjas saugo vaizdus arba klipus?
  • Ar medijos URL yra privatūs, trumpalaikiai ir autorizuojami kiekvienam įrenginiui?
  • Ar raktai kuriami kiekvienam įrenginiui ar susiejimui, o ne laikomi statiškai programėlėje?
  • Ar pranešimų tarpininkas gali perduoti tik su jūsų iš tiesų turimu įrenginiu susijusius pranešimus?
  • Ar susiejimas leidžia žmogui pastebėti tarpininko ataką?

Skaityti kodą

Šaltiniai