Beveiligingslek bij Meari-babycamera's: wat Timmy anders doet

Galaxus meldde vrij toegankelijke opnamen van babycamera's; The Verge meldde ongeveer 1,1 miljoen getroffen Meari-apparaten. Voor mij is de les nuchter: een login beschermt de babykamer niet als het achterliggende platform berichten, beelden of sleutels niet zorgvuldig per apparaat scheidt. Timmy lost niet elk beveiligingsprobleem ter wereld op. Maar de kritieke geheimen voor media en koppeling van Timmy worden niet op een cloudcameraplatform bewaard.

Wat er in de Meari-zaak mis lijkt te zijn gegaan

De openbare berichten beschrijven een white-labelplatform. Veel verschillende merken verkochten camera's die afhankelijk waren van dezelfde Meari/CloudEdge-infrastructuur. Daarom is dit incident belangrijk: als een gedeeld platform de autorisatie verkeerd afbakent, ontstaat niet slechts één zwakke camera, maar een lek dat alle betrokken apparaten kan treffen.

Het gemelde patroon gaat verder dan zwakke standaardwachtwoorden. Bronnen beschrijven MQTT-berichten zonder voldoende toegangscontrole per apparaat, publiek bereikbare afbeeldings-URL's, een zwakke verhulling van beelden en statische of uit een app te halen sleutels. Dat is een fout van het platform: de infrastructuur kon gegevens prijsgeven die nooit voor een ander account beschikbaar hadden mogen zijn.

Risico's van cloudcamera's	Timmy's alternatieve architectuur
De backend slaat gebeurtenissen met beeldmateriaal op of distribueert ze.	Timmy heeft geen cloudarchief met beelden uit de babykamer; media worden live via WebRTC verzonden.
Voor elke broker of opslagbucket moet de toegang per apparaat foutloos zijn geregeld.	Firestore bevat alleen gegevens voor koppeling en signalering; SDP- en ICE-gegevens worden versleuteld voordat ze worden opgeslagen.
Statische sleutels kunnen alle apparaten van een productlijn treffen.	Bij elke koppeling wordt op de apparaten een afzonderlijke, via P-256 ECDH afgeleide sleutel aangemaakt.
Een route via een relayserver kan ten onrechte worden aangezien voor toegang tot de media.	TURN stuurt versleutelde SRTP-pakketten door, maar ontvangt geen mediasleutels.

Hoe Timmy het geheim aanmaakt

De Timmy-code van vier tekens is bewust niet het geheim. In de implementatie dient hij alleen als ontmoetingspunt: de app leidt er een meetingKey uit af, zodat beide apparaten in Firestore bij dezelfde uitwisseling van openbare sleutels uitkomen. Privésleutels voor ECDH verlaten de apparaten nooit.

Beide apparaten berekenen vervolgens hetzelfde gedeelde geheim met P-256 ECDH. De koppelingssleutel wordt lokaal afgeleid. De SAS-code van twee cijfers wordt afgeleid van het gedeelde geheim en beide openbare sleutels in gesorteerde volgorde. Als er met die sleuteluitwisseling is geknoeid, tonen de apparaten verschillende getallen. Zo weten gebruikers dat ze de koppeling niet moeten bevestigen.

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

Vereenvoudigde beveiligingsketen van Timmy: Firestore dient als ontmoetingspunt en vervoert signaleringsgegevens; TURN is alleen een relayserver; de media blijven via WebRTC versleuteld.

Waarom WebRTC-media niet ongemerkt kunnen worden afgeluisterd of bekeken

WebRTC is niet simpelweg “video versturen”. Voordat audio of video wordt verzonden, voeren de apparaten een DTLS-handshake uit. De SRTP-sleutels voor audio en video worden afgeleid van die beveiligde verbinding. De mediapakketten worden vervolgens via SRTP versleuteld. Een TURN-server kan die pakketten doorsturen, maar krijgt niet de sleutels die nodig zijn om de audio of video te ontsleutelen.

Timmy voegt daarvoor nog een laag toe: signaleringsgegevens zoals SDP-aanbiedingen, SDP-antwoorden en ICE-kandidaten worden met AES-256-GCM versleuteld voordat ze Firestore bereiken. Firestore helpt de apparaten bij het onderhandelen; het is niet de plek waar onversleutelde video, audio of signaleringsgegevens horen te staan.

Wat Timmy nog steeds niet beweert

Geen enkele serieuze babyfoon zou moeten beweren dat hij onmogelijk te hacken is. Als een telefoon is gecompromitteerd, kan elke app worden aangevallen. Een gemanipuleerde appversie verandert het risicomodel. De serverconfiguratie moet correct blijven. Timmy doet een beperktere, architectonische uitspraak: het vermijdt mediagegevens uit de babykamer die de backend kan lezen en maakt de koppelingslogica die cruciaal is voor de beveiliging controleerbaar in het openbare kernproject.

Vragen die je over elke babycamera kunt stellen

Slaat de aanbieder beelden of clips op?
Zijn media-URL's privé, slechts korte tijd geldig en per apparaat geautoriseerd?
Worden sleutels per apparaat of per koppeling gegenereerd, in plaats van statisch in een app te staan?
Kan een broker alleen berichten afleveren voor het apparaat dat je daadwerkelijk bezit?
Maakt het koppelingsproces het voor een gebruiker mogelijk een man-in-the-middle-aanval te herkennen?

Lees de code

Bronnen

Opnamen van babycamera's vrij toegankelijk · Galaxus
Een miljoen babyfoons en beveiligingscamera's konden gemakkelijk door hackers worden bekeken · The Verge
nobody puts baby in a corner · Sammy Azdoufal
Gids voor ouders over hetzelfde incident · Baby Monitor Timmy

← Terug naar blog