Објаснување за безбедноста

Безбедносна ранливост кај бебе-камерите Meari: што Timmy прави поинаку

Случајот Meari покажува дека убаво направеното најавување не е доволно. Безбедноста на бебе-мониторот зависи од архитектурата, овластувањето и управувањето со клучеви.

Galaxus објави дека снимки од бебе-камери биле слободно достапни; The Verge објави дека биле засегнати околу 1,1 милион уреди Meari. За мене, поуката е едноставна: најавувањето не ја штити детската соба ако платформата зад него не ги одделува јасно по уред пораките, сликите или клучевите. Timmy не го решава секој безбедносен проблем во светот. Но критичните тајни за медиумите и спарувањето на Timmy не се наоѓаат во платформа за камери во облак.

Што изгледа дека потфрлило во случајот Meari

Јавните извештаи опишуваат white-label платформа. Многу видливи брендови продавале камери што зависеле од истата инфраструктура Meari/CloudEdge. Токму затоа инцидентот е важен: кога заедничка платформа погрешно поставува граница за овластување, резултатот не е една слаба камера, туку изложеност на ниво на цел парк уреди.

Пријавениот образец оди подалеку од слаби стандардни лозинки. Изворите опишуваат MQTT пораки без доволна контрола на претплатите по уред, јавно достапни URL-адреси за слики, слабо прикривање на сликите и статични или клучеви што може да се извлечат од апликацијата. Тоа е неуспех на платформата: инфраструктурата можела да открие податоци што никогаш не требало да бидат достапни за друга сметка.

Ризик од камери во облакПристапот на Timmy
Заднинскиот систем складира или дистрибуира настани со слики.Timmy нема облачна архива за слики од детската соба; медиумите се пренесуваат во живо преку WebRTC.
Посредник или складиште мора совршено да го овластува секој уред.Firestore пренесува само податоци за спарување и сигнализација; SDP/ICE се шифрира пред да се запише.
Статичните клучеви може да влијаат на цел парк уреди.Секое спарување создава сопствен клуч изведен од P-256 ECDH на уредите.
Реле-патеката може погрешно да се смета за пристап до медиумите.TURN препраќа шифрирани SRTP пакети, но не ги добива медиумските клучеви.

Како Timmy ја создава тајната

Четирикарактерниот код на Timmy намерно не е тајната. Во кодот, тој е само точка за средба: апликацијата извлекува meetingKey од него, за двата уреди да можат да ја најдат истата размена на јавни клучеви во Firestore. Приватните ECDH клучеви никогаш не ги напуштаат уредите.

Потоа двата уреди ја пресметуваат истата P-256 ECDH заедничка тајна. Клучот за спарување се изведува локално. Двоцифрениот SAS се изведува од заедничката тајна плус двата подредени јавни клуча. Ако некој ја измени таа размена на клучеви, уредите прикажуваат различни броеви, што им кажува на корисниците да не го потврдуваат спарувањето.

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
        

Поедноставен безбедносен синџир на Timmy: Firestore е транспорт за средба и сигнализација; TURN е само реле; медиумите остануваат шифрирани со WebRTC.

Зошто WebRTC медиумите не можат тивко да се гледаат

WebRTC не е само „испрати видео“. Пред да почнат да течат медиумите, уредите вршат DTLS ракување. SRTP клучевите за аудио и видео се изведуваат од тој безбеден транспорт. Потоа медиумските пакети се шифрирани како SRTP. TURN сервер може да ги препраќа тие пакети, но не ги добива клучевите потребни за отворање на аудиото или видеото.

Timmy додава слој пред тоа: податоците за сигнализација, како SDP понуди, SDP одговори и ICE кандидати, се шифрираат со AES-256-GCM пред да стигнат до Firestore. Firestore им помага на уредите да преговараат; не е место каде што треба да има видео, аудио или сигнализација во отворен текст.

Што Timmy сè уште не тврди

Ниту еден сериозен бебе-монитор не треба да тврди дека не може да биде хакиран. Ако телефонот е компромитиран, секоја апликација може да биде нападната. Злонамерна верзија на апликацијата го менува моделот на ризик. Конфигурацијата на серверот мора да остане исправна. Потесното тврдење на Timmy е архитектонско: избегнува медиумски артефакти од детската соба што може да ги чита заднинскиот систем и овозможува безбедносно критичната логика за спарување да се провери во јавниот основен проект.

Прашања што треба да ги поставите за секоја бебе-камера

  • Дали производителот складира слики или снимки?
  • Дали URL-адресите за медиуми се приватни, краткотрајни и овластени по уред?
  • Дали клучевите се создаваат по уред или спарување, наместо да бидат статични во апликацијата?
  • Дали посредникот може да испорачува пораки само за уредот што навистина го поседувате?
  • Дали при спарувањето човек може да забележи обид за напад „човек во средина“?

Прочитајте го кодот

Извори