സുരക്ഷ വിശദീകരണം

Meari ബേബി ക്യാമറയിലെ സുരക്ഷാ ദൗർബല്യം: Timmy എന്താണ് വ്യത്യസ്തമായി ചെയ്യുന്നത്

ഭംഗിയായി തയ്യാറാക്കിയ ലോഗിൻ മാത്രം പോരെന്ന് Meari സംഭവം കാണിക്കുന്നു. ബേബി മോണിറ്ററിന്റെ സുരക്ഷ ആർക്കിടെക്ചർ, അനുമതികൾ, കീ മാനേജ്മെന്റ് എന്നിവയെ ആശ്രയിച്ചിരിക്കുന്നു.

സ്വതന്ത്രമായി ആക്‌സസ് ചെയ്യാനാകുന്ന ബേബി ക്യാമറ റെക്കോർഡിംഗുകളെ കുറിച്ച് Galaxus റിപ്പോർട്ട് ചെയ്തു; ഏകദേശം 1.1 ദശലക്ഷം Meari ഉപകരണങ്ങൾ ബാധിക്കപ്പെട്ടതായി The Verge റിപ്പോർട്ട് ചെയ്തു. എനിക്ക് ഇതിലെ പാഠം വ്യക്തമാണ്: പിന്നിലെ പ്ലാറ്റ്ഫോം സന്ദേശങ്ങൾ, ചിത്രങ്ങൾ, കീകൾ എന്നിവ ഓരോ ഉപകരണത്തിനും വ്യക്തമായി വേർതിരിക്കുന്നില്ലെങ്കിൽ, ലോഗിൻ കുട്ടിയുടെ മുറിയെ സംരക്ഷിക്കില്ല. Timmy ലോകത്തിലെ എല്ലാ സുരക്ഷാ പ്രശ്നങ്ങളും പരിഹരിക്കുന്നില്ല. എന്നാൽ Timmyയുടെ നിർണായക മീഡിയയും പേയറിംഗ് രഹസ്യങ്ങളും ക്ലൗഡ്-ക്യാമറ പ്ലാറ്റ്ഫോമിനുള്ളിൽ സൂക്ഷിക്കുന്നില്ല.

Meari സംഭവത്തിൽ എന്താണ് പരാജയപ്പെട്ടതെന്ന് തോന്നുന്നു

പൊതുവായി ലഭ്യമായ റിപ്പോർട്ടുകൾ ഒരു വൈറ്റ്-ലേബൽ പ്ലാറ്റ്ഫോമിനെയാണ് വിവരിക്കുന്നത്. ഉപഭോക്താക്കൾക്ക് വ്യത്യസ്തമായി തോന്നുന്ന പല ബ്രാൻഡുകളും ഒരേ Meari/CloudEdge ഇൻഫ്രാസ്ട്രക്ചറിനെ ആശ്രയിച്ച ക്യാമറകൾ വിറ്റു. അതുകൊണ്ടാണ് ഈ സംഭവം പ്രസക്തമാകുന്നത്: പങ്കിട്ട ഒരു പ്ലാറ്റ്ഫോം ആക്‌സസ് അനുമതിയുടെ അതിർത്തി തെറ്റായി നിശ്ചയിച്ചാൽ, ഫലം ഒരു ദുർബല ക്യാമറയിൽ ഒതുങ്ങില്ല; മുഴുവൻ ഉപകരണനിരയിലേക്കും വ്യാപിക്കുന്ന വിവരച്ചോർച്ചയാകും.

റിപ്പോർട്ട് ചെയ്ത രീതി ദുർബലമായ ഡിഫോൾട്ട് പാസ്‌വേഡുകൾക്കപ്പുറമാണ്. ആവശ്യമായ ഓരോ-ഉപകരണ സബ്‌സ്‌ക്രിപ്ഷൻ നിയന്ത്രണങ്ങളില്ലാത്ത MQTT സന്ദേശങ്ങൾ, പൊതുവായി എത്താവുന്ന ഇമേജ് URL-കൾ, ദുർബലമായ ഇമേജ് ഒളിപ്പിക്കൽ, സ്ഥിരമായതോ ആപ്പിൽ നിന്ന് എടുക്കാവുന്നതോ ആയ കീകൾ എന്നിവയെക്കുറിച്ച് ഉറവിടങ്ങൾ പറയുന്നു. ഇത് ഒരു പ്ലാറ്റ്ഫോം പരാജയമാണ്: മറ്റൊരു അക്കൗണ്ടിന് ഒരിക്കലും ലഭ്യമാകരുതായിരുന്ന ഡാറ്റ ഇൻഫ്രാസ്ട്രക്ചറിലൂടെ വെളിപ്പെടാനിടയായി.

ക്ലൗഡ് ക്യാമറയുടെ അപകടസാധ്യതTimmyയുടെ ബദൽ സുരക്ഷാ രൂപകൽപ്പന
ബാക്ക്‌എൻഡ് ഇമേജ് ഇവന്റുകൾ സംഭരിക്കുകയോ വിതരണം ചെയ്യുകയോ ചെയ്യുന്നു.കുട്ടിയുടെ മുറിയിലെ ചിത്രങ്ങൾക്ക് Timmyയിൽ ക്ലൗഡ് ആർക്കൈവ് ഇല്ല; മീഡിയ ലൈവ് WebRTC ആണ്.
ഒരു ബ്രോക്കറോ സ്റ്റോറേജ് ബക്കറ്റോ ഓരോ ഉപകരണത്തിലേക്കുമുള്ള ആക്‌സസ് കൃത്യമായി നിയന്ത്രിക്കണം.Firestore പേയറിംഗ്, സിഗ്നലിംഗ് ഡാറ്റ മാത്രം കൈകാര്യം ചെയ്യുന്നു; SDP/ICE എഴുതുന്നതിന് മുമ്പ് എൻക്രിപ്റ്റ് ചെയ്യപ്പെടുന്നു.
സ്ഥിരമായ കീകൾ മുഴുവൻ ഉപകരണനിരയെയും ബാധിക്കാം.ഓരോ പേയറിംഗും ഉപകരണങ്ങളിൽ സ്വന്തം P-256 ECDH-ൽ നിന്നുള്ള കീ സൃഷ്ടിക്കുന്നു.
ഒരു റിലേ പാതയെ മീഡിയയിലേക്കുള്ള പ്രവേശനമായി തെറ്റിദ്ധരിക്കാം.TURN എൻക്രിപ്റ്റ് ചെയ്ത SRTP പാക്കറ്റുകൾ കൈമാറുന്നു, പക്ഷേ മീഡിയ കീകൾ സ്വീകരിക്കുന്നില്ല.

Timmy രഹസ്യം എങ്ങനെ സൃഷ്ടിക്കുന്നു

നാല് പ്രതീകങ്ങളുള്ള Timmy കോഡ് ഉദ്ദേശപൂർവം രഹസ്യമാക്കിയിട്ടില്ല. കോഡിൽ അത് ഉപകരണങ്ങൾ പരസ്പരം കണ്ടെത്താനുള്ള ഒരു പോയിന്റ് മാത്രമാണ്: രണ്ട് ഉപകരണങ്ങൾക്കും ഒരേ Firestore പബ്ലിക്-കീ എക്സ്ചേഞ്ച് കണ്ടെത്താനായി ആപ്പ് അതിൽ നിന്ന് ഒരു meetingKey സൃഷ്ടിക്കുന്നു. സ്വകാര്യ 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 ശ്രമം ഉപയോക്താവിന് തിരിച്ചറിയാനാകുമോ?

കോഡ് വായിക്കുക

ഉറവിടങ്ങൾ