Meari-ის ბავშვის კამერის უსაფრთხოების…რას აკეთებს Timmy სხვაგვარად

Galaxus-მა გაავრცელა ინფორმაცია ყველასთვის ხელმისაწვდომი ბავშვის კამერის ჩანაწერების შესახებ; The Verge-ის ცნობით, ხარვეზი Meari-ის დაახლოებით 1.1 მილიონ მოწყობილობას შეეხო. ჩემთვის დასკვნა მკაფიოა: შესვლის სისტემა ბავშვის ოთახს ვერ დაიცავს, თუ მის უკან მდგომი პლატფორმა შეტყობინებებს, სურათებსა და გასაღებებს თითოეული მოწყობილობის მიხედვით მკაფიოდ არ მიჯნავს. 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 კანდიდატები, Firestore-მდე მისვლამდე AES-256-GCM-ით იშიფრება. Firestore მოწყობილობებს კავშირის შეთანხმებაში ეხმარება; ის არ არის ადგილი, სადაც დაუშიფრავი ვიდეო, აუდიო ან სასიგნალო მონაცემები უნდა ინახებოდეს.

რას არ ამტკიცებს Timmy

არც ერთი სერიოზული ბავშვის მონიტორის მწარმოებელი არ უნდა ირწმუნებოდეს, რომ მისი გატეხვა შეუძლებელია. თუ ტელეფონი კომპრომეტირებულია, ნებისმიერი აპი შეიძლება თავდასხმის სამიზნე გახდეს. აპის მავნებლურად შეცვლილი ვერსია რისკის მოდელს ცვლის. სერვერის კონფიგურაცია ყოველთვის სწორად უნდა იყოს გამართული. Timmy-ის უფრო ვიწრო მტკიცება არქიტექტურას ეხება: ის არ ქმნის ბავშვის ოთახიდან მიღებულ, ბექენდისთვის წაკითხვად მედიამონაცემებს და უსაფრთხოებისთვის კრიტიკულ დაწყვილების ლოგიკას საჯარო ძირითად პროექტში შესამოწმებელს ხდის.

კითხვები, რომლებიც ნებისმიერ ბავშვის კამერაზე უნდა დასვათ

ინახავს თუ არა მომწოდებელი სურათებს ან კლიპებს?
არის თუ არა მედიის URL-ები პირადი, ხანმოკლე მოქმედების და თითოეული მოწყობილობისთვის ცალ-ცალკე ავტორიზებული?
გასაღებები თითოეული მოწყობილობისთვის ან დაწყვილებისთვის იქმნება თუ აპში სტატიკურადაა ჩაშენებული?
შეუძლია თუ არა ბროკერს მოგაწოდოთ მხოლოდ იმ მოწყობილობის შეტყობინებები, რომელიც ნამდვილად თქვენ გეკუთვნით?
აძლევს თუ არა დაწყვილება მომხმარებელს შესაძლებლობას, შეამჩნიოს შუამავლის (man-in-the-middle) შეტევის მცდელობა?

კოდის ნახვა

წყაროები

← ბლოგზე დაბრუნება

Meari-ის ბავშვის კამერის უსაფრთხოების ხარვეზი: რას აკეთებს Timmy სხვაგვარად