Luka w zabezpieczeniach kamer Meari: co Timmy robi inaczej

Galaxus poinformował o ogólnodostępnych nagraniach z kamer do monitorowania dzieci, a The Verge podał, że problem dotyczył około 1,1 mln urządzeń Meari. Dla mnie wniosek jest trzeźwy: logowanie nie chroni pokoju dziecka, jeśli stojąca za nim platforma nie rozdziela prawidłowo wiadomości, obrazów ani kluczy między poszczególne urządzenia. Timmy nie rozwiązuje wszystkich problemów związanych z bezpieczeństwem. Jednak kluczowe sekrety służące w Timmy do ochrony multimediów i parowania nie znajdują się na platformie obsługującej kamery chmurowe.

Co najprawdopodobniej zawiodło w przypadku Meari

Publiczne doniesienia opisują platformę oferowaną pod markami różnych sprzedawców. Wiele znanych marek sprzedawało kamery korzystające z tej samej infrastruktury Meari/CloudEdge. Dlatego ten incydent jest istotny: gdy współdzielona platforma błędnie wyznacza granice autoryzacji, skutkiem nie jest luka w jednej kamerze, lecz narażenie całej floty urządzeń.

Opisany schemat wykracza poza słabe hasła domyślne. Źródła wskazują na wiadomości MQTT bez wystarczającej kontroli subskrypcji na poziomie poszczególnych urządzeń, publicznie dostępne adresy URL obrazów, słabe maskowanie obrazów oraz klucze statyczne lub możliwe do wyodrębnienia z aplikacji. To awaria platformy: infrastruktura mogła ujawnić dane, które nigdy nie powinny być dostępne dla innego konta.

Jak Timmy tworzy sekret kryptograficzny

Czteroznakowy kod Timmy celowo nie jest sekretem. W kodzie źródłowym służy jedynie jako punkt koordynacyjny: aplikacja wyprowadza z niego meetingKey klucz, dzięki któremu oba urządzenia mogą odnaleźć tę samą sesję wymiany kluczy publicznych w Firestore. Prywatne klucze ECDH nigdy nie opuszczają urządzeń.

Następnie oba urządzenia obliczają ten sam wspólny sekret P-256 ECDH. Klucz parowania jest wyprowadzany lokalnie. Dwucyfrowy SAS jest wyprowadzany ze wspólnego sekretu oraz obu posortowanych kluczy publicznych. Jeśli ta wymiana kluczy zostanie zmanipulowana, urządzenia wyświetlą różne liczby, co informuje użytkowników, by nie potwierdzali parowania.

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
        

Dlaczego transmisji WebRTC nie da się potajemnie podglądać

WebRTC to nie tylko „wysyłanie wideo”. Zanim rozpocznie się transmisja multimediów, urządzenia przeprowadzają uzgadnianie połączenia DTLS. Klucze SRTP dla dźwięku i obrazu są wyprowadzane z tego bezpiecznego kanału transportowego. Pakiety multimedialne są następnie szyfrowane za pomocą SRTP. Serwer TURN może je przekazywać, ale nie otrzymuje kluczy potrzebnych do odszyfrowania dźwięku ani obrazu.

Timmy dodaje przed tym jeszcze jedną warstwę: dane sygnalizacyjne, takie jak oferty SDP, odpowiedzi SDP i kandydaci ICE, są szyfrowane za pomocą AES-256-GCM, zanim trafią do Firestore. Firestore pomaga urządzeniom wynegocjować połączenie; nie służy do przechowywania niezaszyfrowanego obrazu, dźwięku ani danych sygnalizacyjnych w postaci jawnej.

Czego Timmy nadal nie obiecuje

Żadna odpowiedzialnie zaprojektowana elektroniczna niania nie powinna być reklamowana jako niemożliwa do zhakowania. Jeśli telefon zostanie przejęty, każda aplikacja może stać się celem ataku. Złośliwie zmodyfikowana kompilacja aplikacji zmienia model ryzyka. Konfiguracja serwera również musi pozostawać prawidłowa. Węższa deklaracja Timmy dotyczy architektury: Timmy nie tworzy na backendzie możliwych do odczytania materiałów multimedialnych z pokoju dziecka, a krytyczną dla bezpieczeństwa logikę parowania można skontrolować w publicznym projekcie Timmy Core.

Przeczytaj kod źródłowy

• ECDH i SAS w Timmy Core
• Klucz koordynacyjny, klucz dokumentu i AES-GCM
• Reguły Firestore dla sesji i parowania
• Dokumentacja bezpieczeństwa w projekcie Timmy Core

Źródła

• Nagrania z kamer do monitorowania dzieci dostępne dla każdego · Galaxus
• Hakerzy mogli z łatwością oglądać obraz z miliona elektronicznych niań i kamer bezpieczeństwa · The Verge
• nikt nie stawia dziecka w kącie · Sammy Azdoufal
• Poradnik dla rodziców dotyczący tego samego incydentu · Baby Monitor Timmy

← Wróć do bloga