Тлумачэнне пра бяспеку

Уразлівасць бяспекі дзіцячай камеры Meari: чым Timmy адрозніваецца

Выпадак Meari паказвае, што нават добра адпрацаванага механізму ўваходу ў акаўнт недастаткова. Бяспека відэаняні залежыць ад архітэктуры, аўтарызацыі і кіравання ключамі.

Аўтар Апублікавана Абноўлена

Galaxus паведаміў пра запісы з дзіцячых камер, якія былі ў свабодным доступе; The Verge напісаў пра прыкладна 1,1 мільёна закранутых прылад Meari. Для мяне выснова стрыманая і адназначная: уваход у акаўнт не абараняе дзіцячы пакой, калі платформа за ім не раздзяляе належным чынам паведамленні, выявы і ключы для кожнай прылады. Timmy не вырашае ўсіх праблем бяспекі ў свеце. Але крытычна важныя медыя і сакрэты спалучэння Timmy не захоўваюцца ў платформе воблачных камер.

Што, імаверна, пайшло не так у выпадку Meari

У публічных паведамленнях апісваецца платформа, якую розныя кампаніі выкарыстоўвалі для продажу камер пад уласнымі брэндамі. Многія вядомыя брэнды прадавалі камеры, што залежалі ад адной інфраструктуры 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 тычыцца архітэктуры: Timmy не стварае на сервернай частцы даступных для чытання медыяматэрыялаў з дзіцячага пакоя, а крытычна важную логіку спалучэння можна праверыць у адкрытым праекце Timmy Core.

Пра што спытаць у пастаўшчыка любой відэаняні

  • Ці захоўвае вытворца выявы або відэакліпы?
  • Ці з'яўляюцца URL-адрасы медыя прыватнымі і кароткачасовымі і ці аўтарызуецца доступ да іх асобна для кожнай прылады?
  • Ці ствараюцца ключы для кожнай прылады або спалучэння, а не выкарыстоўваюцца як статычныя ўнутры праграмы?
  • Ці можа брокер дастаўляць паведамленні толькі для прылады, якая сапраўды вам належыць?
  • Ці дазваляе спалучэнне чалавеку заўважыць спробу атакі «чалавек пасярэдзіне»?

Прачытаць код

Крыніцы

← Назад да блога