Lỗ hổng bảo mật camera em bé Meari: Timmy làm khác gì

Galaxus đưa tin các bản ghi từ camera em bé có thể được truy cập tự do; The Verge đưa tin khoảng 1,1 triệu thiết bị Meari bị ảnh hưởng. Với tôi, bài học cần nhìn nhận một cách tỉnh táo là: thao tác đăng nhập không thể bảo vệ phòng của bé nếu nền tảng phía sau không tách bạch đúng cách tin nhắn, hình ảnh hoặc khóa của từng thiết bị. Timmy không giải quyết được mọi vấn đề bảo mật trên đời. Tuy nhiên, các bí mật quan trọng dùng để bảo vệ dữ liệu đa phương tiện và quy trình ghép nối của Timmy không nằm trong một nền tảng camera đám mây.

Có vẻ điều gì đã thất bại trong vụ Meari

Các báo cáo công khai mô tả một nền tảng nhãn trắng. Nhiều thương hiệu khác nhau bán camera phụ thuộc vào cùng một hạ tầng Meari/CloudEdge. Đó là lý do sự cố này đáng chú ý: khi một nền tảng dùng chung xác định sai ranh giới phân quyền, hậu quả không chỉ là một camera có bảo mật yếu mà là nguy cơ lộ dữ liệu trên quy mô toàn bộ hệ thống thiết bị.

Mô hình được báo cáo không chỉ là mật khẩu mặc định yếu. Các nguồn mô tả tin nhắn MQTT thiếu kiểm soát đăng ký nhận tin theo từng thiết bị, URL hình ảnh có thể truy cập công khai, cách che giấu hình ảnh yếu và khóa tĩnh hoặc có thể trích xuất từ ứng dụng. Đây là thất bại ở cấp nền tảng: hạ tầng có thể để lộ dữ liệu lẽ ra không bao giờ được cung cấp cho một tài khoản khác.

Rủi ro của camera đám mây	Thiết kế đối trọng của Timmy
Backend lưu trữ hoặc phân phối các sự kiện hình ảnh.	Timmy không có kho lưu trữ đám mây dành cho hình ảnh trong phòng bé; dữ liệu đa phương tiện được truyền trực tiếp qua WebRTC.
Broker hoặc bucket phải phân quyền chính xác cho từng thiết bị.	Firestore chỉ chứa dữ liệu ghép nối và báo hiệu; SDP/ICE được mã hóa trước khi được ghi vào đó.
Khóa tĩnh có thể ảnh hưởng đến cả hệ thống thiết bị.	Mỗi lần ghép nối tạo một khóa riêng trên các thiết bị, được suy ra từ P-256 ECDH.
Việc dữ liệu đi qua một máy chủ chuyển tiếp có thể khiến người dùng lầm tưởng rằng máy chủ đó truy cập được dữ liệu đa phương tiện.	TURN chuyển tiếp các gói SRTP đã mã hóa nhưng không nhận được khóa dùng để giải mã dữ liệu đa phương tiện.

Timmy tạo bí mật như thế nào

Mã Timmy gồm bốn ký tự được chủ ý thiết kế để không phải là bí mật. Trong mã nguồn, mã này chỉ đóng vai trò là một điểm hẹn: ứng dụng suy ra một meetingKey từ đó để cả hai thiết bị tìm được cùng một trao đổi khóa công khai trên Firestore. Khóa ECDH riêng tư không bao giờ rời khỏi thiết bị.

Sau đó, cả hai thiết bị tính ra cùng một bí mật dùng chung bằng P-256 ECDH. Khóa ghép nối được tạo ngay trên thiết bị. Mã SAS gồm hai chữ số được tạo từ bí mật dùng chung và cả hai khóa công khai đã được sắp xếp theo thứ tự. Nếu quá trình trao đổi khóa bị can thiệp, hai thiết bị sẽ hiển thị các số khác nhau, qua đó cảnh báo người dùng không xác nhận ghép nối.

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

Chuỗi bảo mật giản lược của Timmy: Firestore đóng vai trò là điểm hẹn và kênh truyền dữ liệu báo hiệu; TURN chỉ là máy chủ chuyển tiếp; dữ liệu đa phương tiện luôn được WebRTC mã hóa.

Vì sao nội dung WebRTC không thể bị xem lén âm thầm

WebRTC không chỉ đơn giản là “gửi video”. Trước khi dữ liệu đa phương tiện được truyền đi, các thiết bị thực hiện quá trình bắt tay DTLS. Khóa SRTP cho âm thanh và video được suy ra từ kênh truyền bảo mật đó. Sau đó, các gói dữ liệu đa phương tiện được mã hóa bằng SRTP. Máy chủ TURN có thể chuyển tiếp các gói này nhưng không nhận được khóa cần thiết để giải mã âm thanh hoặc video.

Trước đó, Timmy bổ sung thêm một lớp bảo vệ: dữ liệu báo hiệu như SDP offer, SDP answer và ICE candidate được mã hóa bằng AES-256-GCM trước khi đến Firestore. Firestore giúp các thiết bị thương lượng kết nối; đây không phải là nơi lưu video, âm thanh hoặc dữ liệu báo hiệu chưa mã hóa.

Những điều Timmy vẫn không tuyên bố

Không có thiết bị theo dõi em bé nghiêm túc nào nên tuyên bố rằng mình không thể bị hack. Nếu điện thoại bị xâm nhập, bất kỳ ứng dụng nào cũng có thể bị tấn công. Một bản dựng ứng dụng độc hại sẽ làm thay đổi mô hình rủi ro. Cấu hình máy chủ vẫn phải luôn chính xác. Tuyên bố có phạm vi hẹp hơn của Timmy liên quan đến kiến trúc: Timmy tránh tạo ra các tệp dữ liệu đa phương tiện trong phòng bé mà backend có thể đọc, đồng thời cho phép mọi người kiểm tra logic ghép nối có vai trò then chốt đối với bảo mật trong dự án lõi công khai.

Những câu hỏi nên đặt ra với mọi camera em bé

Nhà cung cấp có lưu trữ hình ảnh hoặc video không?
Các URL truy cập dữ liệu đa phương tiện có được bảo mật, chỉ tồn tại trong thời gian ngắn và được phân quyền theo từng thiết bị không?
Khóa có được tạo theo từng thiết bị hoặc lần ghép nối, thay vì là khóa tĩnh trong ứng dụng không?
Broker có chỉ gửi tin nhắn cho đúng thiết bị bạn thực sự sở hữu không?
Quá trình ghép nối có giúp người dùng phát hiện một cuộc tấn công xen giữa (man-in-the-middle) không?

Đọc mã nguồn

Nguồn

Bản ghi từ camera em bé có thể được truy cập tự do · Galaxus
Một triệu thiết bị theo dõi em bé và camera an ninh dễ dàng bị hacker xem được · The Verge
không ai được dồn em bé vào góc · Sammy Azdoufal
Hướng dẫn cho phụ huynh về cùng sự cố này · Baby Monitor Timmy

← Quay lại blog