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-адресите за медиуми се приватни, краткотрајни и овластени по уред?
- Дали клучевите се создаваат по уред или спарување, наместо да бидат статични во апликацијата?
- Дали посредникот може да испорачува пораки само за уредот што навистина го поседувате?
- Дали при спарувањето човек може да забележи обид за напад „човек во средина“?
Прочитајте го кодот
- ECDH и SAS во Timmy Core
- Клуч за средба, клуч за документ и AES-GCM
- Firestore правила за сесии и спарување
- Безбедносна документација во основниот проект
Извори
- Снимки од бебе-камери слободно достапни · Galaxus
- Еден милион бебе-монитори и безбедносни камери лесно можеле да ги гледаат хакери · The Verge
- никој не го става бебето во агол · Sammy Azdoufal
- Водич за родители за истиот инцидент · Baby Monitor Timmy