Meari ਬੇਬੀ ਕੈਮਰਾ ਸੁਰੱਖਿਆ ਕਮਜ਼ੋਰੀ: Timmy ਕੀ ਵੱਖਰਾ ਕਰਦਾ ਹੈ

Galaxus ਨੇ ਬੇਬੀ ਕੈਮਰਿਆਂ ਦੀਆਂ ਰਿਕਾਰਡਿੰਗਾਂ ਦੇ ਖੁੱਲ੍ਹੇ ਤੌਰ 'ਤੇ ਉਪਲਬਧ ਹੋਣ ਬਾਰੇ ਰਿਪੋਰਟ ਕੀਤਾ; The Verge ਨੇ ਲਗਭਗ 1.1 ਮਿਲੀਅਨ ਪ੍ਰਭਾਵਿਤ Meari ਡਿਵਾਈਸਾਂ ਬਾਰੇ ਦੱਸਿਆ। ਮੇਰੇ ਲਈ ਸਬਕ ਸਪੱਸ਼ਟ ਹੈ: ਜੇ ਪਿੱਛੇ ਦਾ ਪਲੇਟਫਾਰਮ ਹਰ ਡਿਵਾਈਸ ਲਈ ਸੁਨੇਹਿਆਂ, ਤਸਵੀਰਾਂ ਜਾਂ ਕੁੰਜੀਆਂ ਨੂੰ ਢੰਗ ਨਾਲ ਵੱਖ ਨਾ ਰੱਖੇ, ਤਾਂ ਲੌਗਇਨ ਬੱਚੇ ਦੇ ਕਮਰੇ ਦੀ ਰੱਖਿਆ ਨਹੀਂ ਕਰਦਾ। Timmy ਦੁਨੀਆ ਦੀ ਹਰ ਸੁਰੱਖਿਆ ਸਮੱਸਿਆ ਹੱਲ ਨਹੀਂ ਕਰਦਾ। ਪਰ Timmy ਦੇ ਅਹਿਮ ਮੀਡੀਆ ਅਤੇ ਪੇਅਰਿੰਗ ਰਾਜ਼ ਕਿਸੇ ਕਲਾਊਡ-ਕੈਮਰਾ ਪਲੇਟਫਾਰਮ ਦੇ ਅੰਦਰ ਨਹੀਂ ਰਹਿੰਦੇ।

ਹਾਰਡਵੇਅਰ ਜਾਂ ਐਪ ਅਸਲ ਫ਼ਰਕ ਨਹੀਂ ਹੈ

ਭੌਤਿਕ ਬੇਬੀ ਕੈਮਰਾ ਹੋਵੇ ਜਾਂ ਫੋਨ-ਆਧਾਰਿਤ ਬੇਬੀ ਮਾਨੀਟਰ ਐਪ, ਦੋਹਾਂ ਸਾਹਮਣੇ ਇੱਕੋ ਬੁਨਿਆਦੀ ਸਮੱਸਿਆ ਹੁੰਦੀ ਹੈ: ਨੈੱਟਵਰਕ ਨਾਲ ਜੁੜਿਆ ਮਾਈਕ੍ਰੋਫੋਨ ਅਤੇ ਕੈਮਰਾ ਪਰਿਵਾਰ ਦੇ ਨਿੱਜੀ ਕਮਰੇ ਵਿੱਚ ਰੱਖੇ ਜਾਂਦੇ ਹਨ। ਅਹਿਮ ਗੱਲ ਇਹ ਨਹੀਂ ਕਿ ਉਤਪਾਦ ਹਾਰਡਵੇਅਰ ਹੈ ਜਾਂ ਸਾਫਟਵੇਅਰ, ਸਗੋਂ ਇਹ ਹੈ ਕਿ ਖਾਤੇ, ਡਿਵਾਈਸ, ਬ੍ਰੋਕਰ, ਸਟੋਰੇਜ, ਰੀਲੇ ਅਤੇ ਕੁੰਜੀਆਂ ਇਸ ਤਰ੍ਹਾਂ ਬਣੇ ਹੋਣ ਕਿ ਕੋਈ ਹੋਰ ਖਾਤਾ ਚੁੱਪਚਾਪ ਕਿਸੇ ਹੋਰ ਦੇ ਸੈਸ਼ਨ ਤੱਕ ਪਹੁੰਚ ਨਾ ਬਣਾ ਸਕੇ।

Meari ਮਾਮਲੇ ਵਿੱਚ ਕੀ ਨਾਕਾਮ ਹੋਇਆ ਲੱਗਦਾ ਹੈ

ਜਨਤਕ ਰਿਪੋਰਟਾਂ ਇੱਕ ਵ੍ਹਾਈਟ-ਲੇਬਲ ਪਲੇਟਫਾਰਮ ਦਾ ਵਰਣਨ ਕਰਦੀਆਂ ਹਨ। ਕਈ ਦਿਖਣ ਵਿੱਚ ਵੱਖਰੇ ਬ੍ਰਾਂਡ ਅਜੇਹੇ ਕੈਮਰੇ ਵੇਚ ਰਹੇ ਸਨ ਜੋ ਇੱਕੋ 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 offers, SDP answers ਅਤੇ ICE candidates ਵਰਗਾ ਸਿਗਨਲਿੰਗ ਡਾਟਾ Firestore ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ AES-256-GCM ਨਾਲ ਐਨਕ੍ਰਿਪਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। Firestore ਡਿਵਾਈਸਾਂ ਨੂੰ ਗੱਲਬਾਤ ਕਰਕੇ ਕਨੈਕਸ਼ਨ ਬਣਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ; ਇਹ ਸਾਫ਼-ਪਾਠ ਵੀਡੀਓ, ਆਡੀਓ ਜਾਂ ਸਾਫ਼-ਪਾਠ ਸਿਗਨਲਿੰਗ ਰੱਖਣ ਦੀ ਥਾਂ ਨਹੀਂ ਹੈ।

Timmy ਫਿਰ ਵੀ ਕੀ ਦਾਅਵਾ ਨਹੀਂ ਕਰਦਾ

ਕੋਈ ਵੀ ਗੰਭੀਰ ਬੇਬੀ ਮਾਨੀਟਰ ਆਪਣੇ ਆਪ ਨੂੰ ਹੈਕ ਨਾ ਹੋ ਸਕਣ ਵਾਲਾ ਨਹੀਂ ਕਹਿਣਾ ਚਾਹੀਦਾ। ਜੇ ਫੋਨ ਨਾਲ ਸਮਝੌਤਾ ਹੋ ਜਾਵੇ, ਤਾਂ ਕਿਸੇ ਵੀ ਐਪ 'ਤੇ ਹਮਲਾ ਹੋ ਸਕਦਾ ਹੈ। ਖ਼ਰਾਬ ਨੀਅਤ ਵਾਲੀ ਐਪ ਬਿਲਡ ਖਤਰੇ ਦਾ ਮਾਡਲ ਬਦਲ ਦਿੰਦੀ ਹੈ। ਸਰਵਰ ਦੀ ਸੰਰਚਨਾ ਸਹੀ ਰਹਿਣੀ ਲਾਜ਼ਮੀ ਹੈ। Timmy ਦਾ ਸੀਮਿਤ ਦਾਅਵਾ ਆਰਕੀਟੈਕਚਰਕ ਹੈ: ਇਹ ਬੈਕਐਂਡ ਵੱਲੋਂ ਪੜ੍ਹੀ ਜਾ ਸਕਣ ਵਾਲੀ ਬੱਚੇ ਦੇ ਕਮਰੇ ਦੀ ਮੀਡੀਆ ਸਮੱਗਰੀ ਤੋਂ ਬਚਦਾ ਹੈ ਅਤੇ ਸੁਰੱਖਿਆ ਲਈ ਅਹਿਮ ਪੇਅਰਿੰਗ ਲੌਜਿਕ ਨੂੰ ਜਨਤਕ ਕੋਰ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਜਾਂਚਣਯੋਗ ਬਣਾਉਂਦਾ ਹੈ।

ਕਿਸੇ ਵੀ ਬੇਬੀ ਕੈਮਰੇ ਬਾਰੇ ਪੁੱਛਣ ਵਾਲੇ ਸਵਾਲ

ਕੀ ਵਿਕਰੇਤਾ ਤਸਵੀਰਾਂ ਜਾਂ ਕਲਿੱਪਾਂ ਸੰਭਾਲਦਾ ਹੈ?
ਕੀ ਮੀਡੀਆ URL ਨਿੱਜੀ, ਥੋੜ੍ਹੇ ਸਮੇਂ ਲਈ ਅਤੇ ਹਰ ਡਿਵਾਈਸ ਲਈ ਅਧਿਕ੍ਰਿਤ ਹਨ?
ਕੀ ਕੁੰਜੀਆਂ ਐਪ ਦੇ ਅੰਦਰ ਸਥਿਰ ਹੋਣ ਦੀ ਬਜਾਏ ਹਰ ਡਿਵਾਈਸ ਜਾਂ ਪੇਅਰਿੰਗ ਲਈ ਬਣਦੀਆਂ ਹਨ?
ਕੀ ਬ੍ਰੋਕਰ ਸਿਰਫ਼ ਉਸੇ ਡਿਵਾਈਸ ਲਈ ਸੁਨੇਹੇ ਭੇਜ ਸਕਦਾ ਹੈ ਜਿਸ ਦੇ ਤੁਸੀਂ ਅਸਲ ਮਾਲਕ ਹੋ?
ਕੀ ਪੇਅਰਿੰਗ ਨਾਲ ਕਿਸੇ ਇਨਸਾਨ ਨੂੰ ਮੈਨ-ਇਨ-ਦ-ਮਿਡਲ ਕੋਸ਼ਿਸ਼ ਦਾ ਪਤਾ ਲੱਗ ਸਕਦਾ ਹੈ?

ਕੋਡ ਪੜ੍ਹੋ

ਸਰੋਤ

← ਬਲੌਗ 'ਤੇ ਵਾਪਸ ਜਾਓ