פגיעות אבטחה במצלמות תינוק של Meari: מה Timmy עושה אחרת

Galaxus דיווחה על הקלטות ממצלמות תינוק שהיו נגישות לכל; The Verge דיווח על כ־1.1 מיליון מכשירי Meari שנפגעו. מבחינתי, הלקח ברור: התחברות לחשבון לא מגינה על חדר התינוק אם הפלטפורמה שמאחוריה לא מפרידה כראוי בין הודעות, תמונות או מפתחות לכל מכשיר. Timmy לא פותרת כל בעיית אבטחה בעולם. אבל סודות המדיה והצימוד הקריטיים של Timmy לא נמצאים בתוך פלטפורמת מצלמות ענן.

מה כנראה השתבש במקרה של Meari

הדיווחים הפומביים מתארים פלטפורמת white-label. מותגים רבים מכרו מצלמות שהתבססו על אותה תשתית Meari/CloudEdge. לכן האירוע חשוב: כשפלטפורמה משותפת מגדירה לא נכון גבול הרשאות, התוצאה אינה מצלמה חלשה אחת, אלא חשיפה של צי מכשירים שלם.

הדפוס שדווח חורג מסיסמאות ברירת מחדל חלשות. המקורות מתארים הודעות MQTT ללא בקרת הרשמה מספקת לכל מכשיר, כתובות URL של תמונות שהיו נגישות לציבור, הסוואת תמונות חלשה ומפתחות סטטיים או מפתחות שאפשר לחלץ מהאפליקציה. זהו כשל פלטפורמה: התשתית יכלה לחשוף נתונים שלעולם לא היו אמורים להיות זמינים לחשבון אחר.

איך 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
        

למה אי אפשר לצפות במדיית WebRTC בלי שיבחינו בכך

WebRTC אינו רק "שליחת וידאו". לפני שהמדיה זורמת, המכשירים מבצעים לחיצת יד של DTLS. מפתחות ה‑SRTP לאודיו ולווידאו נגזרים מהתעבורה המאובטחת הזו. חבילות המדיה מוצפנות לאחר מכן כ‑SRTP. שרת TURN יכול להעביר את החבילות האלה, אך אינו מקבל את המפתחות הנדרשים לפתיחת האודיו או הווידאו.

Timmy מוסיפה שכבה עוד לפני כן: נתוני איתות כמו הצעות SDP, תשובות SDP ומועמדי ICE מוצפנים ב‑AES-256-GCM לפני שהם מגיעים ל‑Firestore. Firestore עוזרת למכשירים לנהל משא ומתן; היא לא המקום שבו אמורים להימצא וידאו, אודיו או נתוני איתות לא מוצפנים.

מה Timmy עדיין לא טוענת

שום מוניטור תינוק רציני לא אמור לטעון שאי אפשר לפרוץ אליו. אם טלפון נפרץ, אפשר לתקוף כל אפליקציה. גרסת אפליקציה זדונית משנה את מודל הסיכון. גם תצורת השרת חייבת להישאר נכונה. הטענה המצומצמת יותר של Timmy היא ארכיטקטונית: היא נמנעת מארטיפקטים של מדיה מחדר התינוק שה־backend יכול לקרוא, והופכת את לוגיקת הצימוד הקריטית לאבטחה לניתנת לבדיקה בפרויקט הליבה הציבורי.

קריאת הקוד

• ECDH ו‑SAS ב‑Timmy Core
• מפתח פגישה, מפתח מסמך ו‑AES-GCM
• כללי Firestore לשיחות ולצימוד
• תיעוד אבטחה בפרויקט הליבה

מקורות

• הקלטות ממצלמות תינוק היו נגישות לכל · Galaxus
• מיליון מוניטורים לתינוק ומצלמות אבטחה היו ניתנים לצפייה בקלות בידי האקרים · The Verge
• אף אחד לא שם את התינוק בפינה · Sammy Azdoufal
• מדריך להורים על אותו אירוע · Baby Monitor Timmy

← חזרה לבלוג