ਸੁਰੱਖਿਆ ਖੋਜਕਰਤਾ Frank Chu ਨੇ ਖੋਜਿਆ ਕਿ tl;dv—ਇੱਕ AI-ਸੰਚਾਲਿਤ ਮੀਟਿੰਗ-ਨੋਟ ਸੇਵਾ ਜੋ Zoom ਅਤੇ Teams ਨਾਲ ਜੁੜਦੀ ਹੈ—ਨੇ 181,874 ਨਿੱਜੀ ਮੀਟਿੰਗ ਟ੍ਰਾਂਸਕ੍ਰਿਪਟ ਲੀਕ ਕਰ ਦਿੱਤੇ ਕਿਉਂਕਿ ਇੱਕ ਸਿੰਗਲ Firebase ਸੁਰੱਖਿਆ ਨਿਯਮ (security rule) ਗਾਇਬ ਸੀ, ਜਿਸ ਨਾਲ ਕੋਈ ਵੀ ਲੌਗ-ਇਨ ਕੀਤਾ ਹੋਇਆ ਯੂਜ਼ਰ ਪੂਰੇ ਰਿਕਾਰਡ ਨੂੰ ਪੜ੍ਹ ਸਕਦਾ ਸੀ। ਇਸ ਉਲੰਘਣਾ ਨੇ 35,003 ਡੋਮੇਨਾਂ ਦੇ 84,312 ਯੂਜ਼ਰਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕੀਤਾ, ਜੋ ਕਿ ਇੱਕ ਯਾਦ ਦਿਵਾਉਣ ਵਾਲੀ ਗੱਲ ਹੈ ਕਿ ਇੱਕ ਛੋਟੀ ਜਿਹੀ ਕੌਂਫਿਗਰੇਸ਼ਨ ਦੀ ਗਲਤੀ ਸਭ ਤੋਂ ਗੁਪਤ ਕਾਰਪੋਰੇਟ ਗੱਲਬਾਤ ਨੂੰ ਉਜਾਗਰ ਕਰ ਸਕਦੀ ਹੈ।

ਲੀਕ ਕਿਵੇਂ ਹੋਈ

tl;dv ਨੋਟਸ ਨੂੰ Google Firebase ਦੇ Firestore ਡਾਟਾਬੇਸ ਵਿੱਚ ਸਟੋਰ ਕਰਦਾ ਹੈ। Firestore ਵਿੱਚ, ਡਿਵੈਲਪਰ ਸੁਰੱਖਿਆ ਨਿਯਮ ਲਿਖਦੇ ਹਨ ਜੋ ਇਹ ਤੈਅ ਕਰਦੇ ਹਨ ਕਿ ਕੌਣ ਹਰੇਕ ਦਸਤਾਵੇਜ਼ ਨੂੰ ਪੜ੍ਹ ਸਕਦਾ ਹੈ ਜਾਂ ਲਿਖ ਸਕਦਾ ਹੈ। tl;dv ਦੇ ਜ਼ਿਆਦਾਤਰ ਕਲੈਕਸ਼ਨਾਂ (collections) ਨੂੰ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਲੌਕ ਕੀਤਾ ਗਿਆ ਸੀ, ਪਰ meetings ਕਲੈਕਸ਼ਨ ਵਿੱਚ ਅਜਿਹਾ ਨਿਯਮ ਨਹੀਂ ਸੀ ਜੋ ਬੇਨਤੀ ਕਰਨ ਵਾਲੇ ਦੀ ਪਛਾਣ ਦੀ ਜਾਂਚ ਕਰੇ। ਨਤੀਜਾ ਸਧਾਰਨ ਸੀ: ਇੱਕ ਵਾਰ ਜਦੋਂ ਯੂਜ਼ਰ ਐਪ ਵਿੱਚ ਸਾਈਨ-ਇਨ ਕਰ ਲੈਂਦਾ ਸੀ, ਤਾਂ API ਸੇਵਾ ਦੁਆਰਾ ਸਟੋਰ ਕੀਤੇ ਗਏ ਹਰ ਮੀਟਿੰਗ ਦਸਤਾਵੇਜ਼ ਦੀ ਇੱਕ ਸੂਚੀ ਵਾਪਸ ਕਰ ਦਿੰਦਾ ਸੀ।

ਇੱਥੇ ਕੋਈ ਗੁੰਝਲਦਾਰ ਐਕਸਪਲੋਇਟ (exploit), ਕੋਈ ਮਾਲੀਸ਼ੀਅਸ ਪੇਲੋਡ (malicious payload) ਜਾਂ ਅੰਡਰਲਾਈਂਗ AI ਮਾਡਲ ਦੀ ਉਲੰਘਣਾ ਨਹੀਂ ਸੀ। ਇਹ ਕਮਜ਼ੋਰੀ ਐਕਸੈਸ-ਕੰਟਰੋਲ ਦੀ ਇੱਕ ਰਵਾਇਤੀ ਲਾਪਰਵਾਹੀ ਸੀ—ਕੋਡ ਦੀ ਇੱਕ ਲਾਈਨ ਦੀ ਘਾਟ ਜੋ ਇਹ ਕਹਿਣੀ ਚਾਹੀਦੀ ਸੀ, "ਸਿਰਫ਼ ਮਾਲਕ ਜਾਂ ਸੱਦਾ ਦਿੱਤੇ ਗਏ ਭਾਗੀਦਾਰ ਹੀ ਇਸ ਮੀਟਿੰਗ ਨੂੰ ਦੇਖ ਸਕਦੇ ਹਨ।" ਕਿਉਂਕਿ ਨਿਯਮ ਗਾਇਬ ਸੀ, ਕੋਈ ਵੀ ਪ੍ਰਮਾਣਿਤ (authenticated) ਯੂਜ਼ਰ ਸੱਦੇ ਦੀ ਸਥਿਤੀ ਦੀ ਪਰਵਾਹ ਕੀਤੇ ਬਿਨਾਂ ਹਰ ਟ੍ਰਾਂਸਕ੍ਰਿਪਟ ਨੂੰ ਲਿਸਟ ਕਰ ਸਕਦਾ ਸੀ ਅਤੇ ਡਾਊਨਲੋਡ ਕਰ ਸਕਦਾ ਸੀ।

ਇਹ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ

ਮੀਟਿੰਗ ਟ੍ਰਾਂਸਕ੍ਰਿਪਟਾਂ ਵਿੱਚ ਅਕਸਰ ਬੋਰਡ-ਰੂਮ ਵਿਚਾਰ-ਵਟਾਂਦਰਾ, ਪ੍ਰੋਡਕਟ ਰੋਡਮੈਪ, ਕਾਨੂੰਨੀ ਸਲਾਹ ਅਤੇ ਵਿਕਰੀ ਦੇ ਗੱਲਬਾਤ ਸ਼ਾਮਲ ਹੁੰਦੀ ਹੈ। ਜਦੋਂ ਉਹ ਸ਼ਬਦ ਜਨਤਕ ਤੌਰ 'ਤੇ ਪੜ੍ਹਨਯੋਗ ਹੋ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਮੁਕਾਬਲੇਬਾਜ਼ ਰਣਨੀਤਕ ਜਾਣਕਾਰੀ ਇਕੱਠੀ ਕਰ ਸਕਦੇ ਹਨ, ਵਕੀਲਾਂ ਨੂੰ ਗੁਪਤਤਾ ਦੀਆਂ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਦੀ ਮੁੜ-ਜਾਂਚ ਕਰਨੀ ਪੈ ਸਕਦੀ ਹੈ, ਅਤੇ ਕਰਮਚਾਰੀ ਉਨ੍ਹਾਂ ਸਾਧਨਾਂ 'ਤੇ ਭਰੋਸਾ ਗੁਆ ਲੈਂਦੇ ਹਨ ਜਿਨ੍ਹਾਂ 'ਤੇ ਉਹ ਨਿਰਭਰ ਹਨ। ਲੱਖਾਂ ਰਿਕਾਰਡ ਇਸ ਨੂੰ ਇੱਕ ਪ੍ਰਣਾਲੀਗਤ ਅਸਫਲਤਾ ਬਣਾਉਂਦੇ ਹਨ ਜੋ ਕਿਸੇ ਵੀ ਅਜਿਹੀ ਸੰਸਥਾ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦੀ ਹੈ ਜਿਸਨੇ ਇਸਦੇ ਪਰਮਿਸ਼ਨ ਮਾਡਲ ਦੀ ਬਾਰੀਕੀ ਨਾਲ ਜਾਂਚ ਕੀਤੇ ਬਿਨਾਂ tl;dv ਨੂੰ ਅਪਣਾਇਆ ਹੈ।

ਪ੍ਰਤੀਕਿਰਿਆ ਵਿੱਚ ਦੇਰੀ

Chu ਨੇ ਜਨਵਰੀ ਵਿੱਚ tl;dv ਦੀ ਟੀਮ ਨੂੰ ਗਾਇਬ ਨਿਯਮ ਬਾਰੇ ਰਿਪੋਰਟ ਕੀਤੀ ਸੀ। ਇਸਦਾ ਹੱਲ—ਸਹੀ ਰੀਡ-ਰਿਸਟ੍ਰਿਕਸ਼ਨ (read-restriction) ਜੋੜਨਾ ਅਤੇ ਨਿਯਮਾਂ ਦੇ ਸੈੱਟ ਨੂੰ ਮੁੜ-ਤੈਯਾਰ ਕਰਨਾ—ਅਗਸਤ ਤੱਕ ਲਾਗੂ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਸੀ। ਖੋਜ ਅਤੇ ਸੁਧਾਰ ਦੇ ਵਿਚਕਾਰ ਛੇ ਮਹੀਨਿਆਂ ਦਾ ਸਮਾਂ ਉਸ ਕਮਜ਼ੋਰੀ ਲਈ ਅਸਾਧਾਰਨ ਤੌਰ 'ਤੇ ਲੰਬਾ ਹੈ ਜੋ ਸੰਵੇਦਨਸ਼ੀਲ ਡਾਟਾ ਤੱਕ ਬਿਨਾਂ ਕਿਸੇ ਰੋਕ-ਟੋਕ ਦੇ ਪਹੁੰਚ ਪ੍ਰਦਾਨ ਕਰਦੀ ਹੈ। ਇਹ ਦੇਰੀ ਕੰਪਨੀ ਦੀ ਵਲਨਰੇਬਿਲਟੀ-ਮੈਨੇਜਮੈਂਟ (vulnerability-management) ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਕਮੀਆਂ ਨੂੰ ਉਜਾਗਰ ਕਰਦੀ ਹੈ, ਟ੍ਰਾਇਜ (triage) ਤੋਂ ਲੈ ਕੇ ਪੈਚ ਡਿਪਲਾਈਮੈਂਟ ਤੱਕ।

AI-ਸੰਚਾਲਿਤ ਏਜੰਟਾਂ ਲਈ ਇੱਕ ਵਿਆਪਕ ਸਬਕ

ਇਸ ਘਟਨਾ ਨੂੰ ਅਕਸਰ "AI ਜੋਖਮ" ਵਜੋਂ ਦੇਖਿਆ ਜਾਂਦਾ ਹੈ, ਫਿਰ ਵੀ ਇਸਦਾ ਮੂਲ ਕਾਰਨ ਰਵਾਇਤੀ ਐਕਸੈਸ-ਕੰਟਰੋਲ ਦੀ ਗਲਤੀ ਹੈ। AI ਏਜੰਟ—ਚਾਹੇ ਉਹ ਮੀਟਿੰਗਾਂ ਦਾ ਟ੍ਰਾਂਸਕ੍ਰਿਪਸ਼ਨ ਕਰਨ, ਈਮੇਲ ਡਰਾਫਟ ਕਰਨ, ਜਾਂ ਦਸਤਾਵੇਜ਼ਾਂ ਦਾ ਸਾਰ ਲਿਖਣ—ਸਰਵਿਸ-ਅਕਾਊਂਟ ਅਧਿਕਾਰਾਂ (service-account privileges) ਨਾਲ ਚੱਲਦੇ ਹਨ ਜੋ ਉਹਨਾਂ ਨੂੰ ਉਸੇ ਡਾਟਾ ਤੱਕ ਪਹੁੰਚ ਦਿੰਦੇ ਹਨ ਜਿਸ ਤੱਕ ਇੱਕ ਮਨੁੱਖੀ ਯੂਜ਼ਰ ਪਹੁੰਚ ਸਕਦਾ ਹੈ। ਜਦੋਂ ਉਹ ਅਧਿਕਾਰ ਬਹੁਤ ਜ਼ਿਆਦਾ ਵਿਆਪਕ ਹੁੰਦੇ ਹਨ, ਤਾਂ AI ਕਿਸੇ ਵੀ ਹੋਰ ਬੈਕਐਂਡ ਸੇਵਾ ਵਾਂਗ ਡਾਟਾ ਲੀਕ ਹੋਣ ਦਾ ਇੱਕ ਸਾਧਨ ਬਣ ਜਾਂਦਾ ਹੈ।

ਸੰਸਥਾਵਾਂ ਅੱਜ ਕੀ ਕਰ ਸਕਦੀਆਂ ਹਨ

  • ਅਥੋਰਾਈਜ਼ੇਸ਼ਨ ਲੌਜਿਕ (Authorization logic) ਦੀ ਜਾਂਚ ਕਰੋ – ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ AI ਟੂਲ ਦੁਆਰਾ ਵਰਤਿਆ ਜਾਣ ਵਾਲਾ ਹਰ ਡਾਟਾਬੇਸ ਕਲੈਕਸ਼ਨ, API ਐਂਡਪੁਆਇੰਟ, ਜਾਂ ਕਲਾਉਡ ਸਟੋਰੇਜ ਬੱਕਟ 'ਲੀਸਟ-ਪ੍ਰਿਵਿਲੇਜ' (least-privilege) ਚੈੱਕ ਲਾਗੂ ਕਰਦਾ ਹੈ। tl;dv ਵਿੱਚ ਹੋਈ ਗਲਤੀ ਵਾਂਗ ਗਾਇਬ ਜਾਂ ਬਹੁਤ ਜ਼ਿਆਦਾ ਇਜਾਜ਼ਤ ਦੇਣ ਵਾਲੇ ਨਿਯਮਾਂ ਦੀ ਭਾਲ ਕਰੋ।
  • ਰਿਕਾਰਡਿੰਗ ਦਾ ਘੇਰਾ ਸੀਮਤ ਕਰੋ – ਨੋਟ-ਲੈਖਣ ਏਜੰਟ ਨੂੰ ਸਿਰਫ਼ ਉਹਨਾਂ ਮੀਟਿੰਗਾਂ ਨੂੰ ਕੈਪਚਰ ਕਰਨ ਲਈ ਕੌਂਫਿਗਰ ਕਰੋ ਜਿਨ੍ਹਾਂ ਲਈ ਤੁਸੀਂ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਅਧਿਕਾਰਤ ਕਰਦੇ ਹੋ। ਡਿਫੌਲਟ-ਆਨ-ਰਿਕਾਰਡ ਸੈਟਿੰਗ ਹ

ਮੁੱਖ ਗੱਲ: AI ਟੂਲ ਉਨਾ ਹੀ ਸੁਰੱਖਿਅਤ ਹਨ ਜਿੰਨੇ ਉਹ ਐਕਸੈਸ ਕੰਟਰੋਲ ਹਨ ਜੋ ਉਹਨਾਂ ਦੁਆਰਾ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਡੇਟਾ ਦੀ ਰੱਖਿਆ ਕਰਦੇ ਹਨ। Firestore ਦੇ ਇੱਕ ਨਿਯਮ ਦੀ ਘਾਟ ਨੇ ਇੱਕ ਲਾਭਦਾਇਕ ਨੋਟ-ਲੈਖਣ ਸਹਾਇਕ ਨੂੰ ਇੱਕ ਵੱਡੇ ਡੇਟਾ ਲੀਕ ਵਿੱਚ ਬਦਲ ਦਿੱਤਾ; ਨਿਯਮਤ ਤੌਰ 'ਤੇ ਟੈਸਟ ਕੀਤੀਆਂ ਗਈਆਂ ਇਜਾਜ਼ਤਾਂ ਹੀ ਇਕਲੌਤੀ ਭਰੋਸੇਯੋਗ ਰੱਖਿਆ ਹਨ।