ਇਹ ਸਭ ਤੋਂ ਪ੍ਰਚਲਿਤ ਕਿਸਮ ਦੇ ਸਾਫਟਵੇਅਰ ਸਪਲਾਈ ਚੇਨ ਹਮਲਿਆਂ ਬਾਰੇ ਲੇਖਾਂ ਦੀ ਲੜੀ ਦਾ ਪਹਿਲਾ ਐਪੀਸੋਡ ਹੈ: ਉਹ ਜੋ (ab) ਸਾਫਟਵੇਅਰ ਹਿੱਸਿਆਂ ਦੀ ਜਨਤਕ ਰਜਿਸਟਰੀ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ, ਜਿਸਦਾ ਉਦੇਸ਼ ਓਪਨ ਸੋਰਸ ਪ੍ਰੋਜੈਕਟ ਉਹਨਾਂ ਕਲਾਕ੍ਰਿਤੀਆਂ ਨੂੰ ਅਪਲੋਡ ਕਰਨ ਲਈ ਜੋ ਦੂਜੇ ਉਪਭੋਗਤਾਵਾਂ ਨਾਲ ਸਾਂਝੀਆਂ ਕੀਤੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ। ਜਦੋਂ ਬੁਰੇ ਲੋਕ ਉੱਥੇ ਖਤਰਨਾਕ ਸੌਫਟਵੇਅਰ ਪ੍ਰਕਾਸ਼ਤ ਕਰਦੇ ਹਨ, ਰਜਿਸਟਰੀ ਨੂੰ ਮਾਲਵੇਅਰ ਵੰਡ ਲਈ ਇੱਕ ਵਾਹਨ ਵਜੋਂ ਵਰਤਦੇ ਹੋਏ, ਤਾਂ ਸਾਡੇ ਕੋਲ ਸਪਲਾਈ ਚੇਨ ਹਮਲਾ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਪੀੜਤ ਸੰਗਠਨ ਸੰਕਰਮਿਤ ਸੌਫਟਵੇਅਰ ਕੰਪੋਨੈਂਟ ਨੂੰ ਸਥਾਪਤ ਕਰਦੇ ਹਨ ਜਾਂ ਚਲਾਉਂਦੇ ਹਨ।
ਚਰਚਾ ਨੂੰ ਸਰਲ ਬਣਾਉਣ ਲਈ ਅਸੀਂ ਗੱਲ ਕਰਾਂਗੇ ਸਾਫਟਵੇਅਰ ਪੈਕੇਜ:, ਤੀਜੀ ਧਿਰ ਦੁਆਰਾ ਤਿਆਰ ਕੀਤੇ ਗਏ ਪੈਕ ਕੀਤੇ ਰੂਪ ਵਿੱਚ ਹਿੱਸੇ। ਇਸ ਵਿੱਚ ਨਾ ਸਿਰਫ਼ NPM ਜਾਂ Poetry ਵਰਗੇ ਪੈਕੇਜ ਪ੍ਰਬੰਧਕਾਂ ਦੁਆਰਾ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਹਿੱਸੇ ਸ਼ਾਮਲ ਹਨ, ਸਗੋਂ ਇਹ ਵੀ ਸ਼ਾਮਲ ਹਨ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਦੇ ਹਿੱਸੇ ਲਾਇਬ੍ਰੇਰੀਆਂ ਅਤੇ ਚੱਲਣਯੋਗ ਬਾਈਨਰੀਆਂ ਸਮੇਤ, ਕੰਟੇਨਰ ਚਿੱਤਰ, ਅਤੇ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ, ਜਾਂ ਟੂਲ ਐਕਸਟੈਂਸ਼ਨਾਂ ਵਿਕਾਸ, ਨਿਰਮਾਣ ਅਤੇ ਤੈਨਾਤੀ ਸਾਧਨਾਂ ਲਈ। ਅਸੀਂ ਹਰ ਜਗ੍ਹਾ ਖਤਰਨਾਕ ਪੈਕੇਜ ਦੇਖੇ ਹਨ। ਸਾਈਬਰ ਅਪਰਾਧੀਆਂ ਨੂੰ ਕੋਈ ਇਤਰਾਜ਼ ਨਹੀਂ ਹੈ: ਉਹ ਆਧੁਨਿਕ ਸਾਫਟਵੇਅਰ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੁਆਰਾ ਪ੍ਰਦਾਨ ਕੀਤੇ ਗਏ ਵਿਕਲਪਾਂ ਤੋਂ ਖੁਸ਼ ਹੁੰਦੇ ਹਨ ਅਤੇ ਰਜਿਸਟਰੀ ਅਤੇ ਉਸ ਟੂਲ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ ਜੋ ਉਨ੍ਹਾਂ ਦੇ ਉਦੇਸ਼ ਨੂੰ ਸਭ ਤੋਂ ਵਧੀਆ ਢੰਗ ਨਾਲ ਫਿੱਟ ਕਰਦਾ ਹੈ। ਇਸ ਲਈ ਕਿਰਪਾ ਕਰਕੇ ਯਾਦ ਰੱਖੋ ਕਿ ਸਾਫਟਵੇਅਰ ਪੈਕੇਜ ਕੰਟੇਨਰ ਚਿੱਤਰਾਂ, ਬਾਈਨਰੀ ਪੈਕੇਜਾਂ, ਓਪਨ-ਸੋਰਸ ਰਿਪੋਜ਼ਟਰੀਆਂ, ਅਤੇ ਐਕਸਟੈਂਸ਼ਨਾਂ ਜਾਂ ਹਰ ਕਿਸਮ ਦੇ ਪਲੱਗਇਨ (IDEs, CI/CD ਸਿਸਟਮ, ਬਿਲਡ ਟੂਲ)। ਸਾਰੇ ਨਿਯਮਿਤ ਤੌਰ 'ਤੇ ਹਮਲੇ ਦੇ ਅਧੀਨ ਹਨ।
ਇਸ ਲੜੀ ਦੇ 5 ਐਪੀਸੋਡ ਹੋਣਗੇ:
- ਓਪਨ ਸੋਰਸ ਪੈਕੇਜਾਂ ਨਾਲ ਕੀ ਸਮੱਸਿਆ ਹੈ? ਇਹ ਇਸ ਪੋਸਟ ਦਾ ਵਿਸ਼ਾ ਹੈ। ਹਰ ਤਰ੍ਹਾਂ ਦੇ ਅਪਰਾਧੀ ਖਤਰਨਾਕ ਪੈਕੇਜ ਕਿਉਂ ਪ੍ਰਕਾਸ਼ਤ ਕਰ ਰਹੇ ਹਨ? ਮੈਨੂੰ ਕਿਉਂ ਚਿੰਤਾ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ?
- ਖਤਰਨਾਕ ਪੈਕੇਜਾਂ ਦਾ ਸਰੀਰ ਵਿਗਿਆਨ: ਰੁਝਾਨ ਕੀ ਹਨ? ਇਸ ਐਪੀਸੋਡ ਵਿੱਚ, ਅਸੀਂ ਉਸ ਖ਼ਤਰੇ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰਦੇ ਹਾਂ ਜਿਸਦੀ ਅਸੀਂ ਆਪਣੇ MEW ਸਿਸਟਮ ਨਾਲ ਦਿਨ-ਬ-ਦਿਨ ਨਿਗਰਾਨੀ ਕਰ ਰਹੇ ਹਾਂ। ਟਾਈਪੋਸਕੈਟਿੰਗ ਜਾਂ ਨਿਰਭਰਤਾ ਉਲਝਣ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਖਤਰਨਾਕ ਪੈਕੇਟਾਂ ਦੇ ਕਾਰਨ ਇੱਕ ਵੱਡੇ ਪਿਛੋਕੜ ਵਾਲੇ ਸ਼ੋਰ ਦੇ ਨਾਲ, ਹਮਲਿਆਂ ਦਾ ਇੱਕ ਛੋਟਾ ਪ੍ਰਤੀਸ਼ਤ ਬਹੁਤ ਜ਼ਿਆਦਾ ਧੋਖੇਬਾਜ਼ ਹੁੰਦਾ ਹੈ ਅਤੇ ਇੱਕ ਵੱਡਾ ਜੋਖਮ ਪੈਦਾ ਕਰਦਾ ਹੈ। ਹਾਲ ਹੀ ਵਿੱਚ OS ਸੰਬੰਧੀ ਮਾੜੇ ਅਦਾਕਾਰਾਂ ਦਾ ਵਿਵਹਾਰ ਕਿਵੇਂ ਬਦਲਿਆ ਹੈ? ਨੰਬਰ ਕੀ ਹਨ? ਵਰਤੀਆਂ ਗਈਆਂ ਰਣਨੀਤੀਆਂ, ਤਕਨੀਕਾਂ ਅਤੇ ਪ੍ਰਕਿਰਿਆਵਾਂ ਕੀ ਹਨ, ਅਤੇ ਨੁਕਸਾਨਦੇਹ ਕਾਰਵਾਈਆਂ ਕੀ ਹਨ?
- ਓਪਨ ਸੋਰਸ ਖਤਰਨਾਕ ਪੈਕੇਜਾਂ ਤੋਂ ਸੁਰੱਖਿਆ: ਕੀ ਕੰਮ ਕਰਦਾ ਹੈ (ਨਹੀਂ). ਜ਼ਿਆਦਾਤਰ ਸੁਰੱਖਿਆ-ਜਾਗਰੂਕ ਪੇਸ਼ੇਵਰਾਂ ਕੋਲ ਇਸ ਖ਼ਤਰੇ ਨਾਲ ਕਿਵੇਂ ਨਜਿੱਠਣਾ ਹੈ ਇਸ ਬਾਰੇ ਵਿਚਾਰ ਹੁੰਦੇ ਹਨ। ਅਸੀਂ ਸੁਰੱਖਿਆ ਪ੍ਰਬੰਧਕਾਂ ਨੂੰ ਬਿਨਾਂ ਝਿਜਕ ਇਹ ਕਹਿੰਦੇ ਸੁਣਿਆ ਹੈ ਕਿ SCA ਟੂਲ ਪਹਿਲਾਂ ਹੀ ਤੁਹਾਨੂੰ ਦੱਸਦੇ ਹਨ ਕਿ ਪੈਕੇਜ ਵਰਜਨ ਕਦੋਂ ਮਾਲਵੇਅਰ ਹੁੰਦਾ ਹੈ। ਜਾਂ ਇਹ ਕਿ ਉਹ ਜਾਣੇ-ਪਛਾਣੇ, ਬਹੁਤ ਜ਼ਿਆਦਾ ਸਮੀਖਿਆ ਕੀਤੇ ਸੌਫਟਵੇਅਰ ਕੰਪੋਨੈਂਟਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ, ਜਿੱਥੇ ਕੋਈ ਵੀ ਮਾਲਵੇਅਰ ਤੁਰੰਤ ਖੋਜਿਆ ਅਤੇ ਹਟਾਇਆ ਜਾਵੇਗਾ। ਉਹ ਇਹ ਕਿ ਉਹ ਆਪਣੇ ਆਪ ਕਮਜ਼ੋਰੀ ਫਿਕਸ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਓਪਨ ਮਾਈਨਰ/ਪੈਚ ਵਰਜਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ, ਅਤੇ ਇਹ "ਪੈਚ ਜਲਦੀ, ਪੈਚ ਅਕਸਰ" ਸਿਧਾਂਤ ਦੀ ਪਾਲਣਾ ਕਰਦੇ ਹੋਏ, ਓਪਨ ਸੋਰਸ ਨਿਰਭਰਤਾਵਾਂ 'ਤੇ ਜੋਖਮ ਨੂੰ ਘਟਾਉਣ ਦਾ ਸਹੀ, ਸਿਫ਼ਾਰਸ਼ ਕੀਤਾ ਤਰੀਕਾ ਹੈ। ਇਸ ਐਪੀਸੋਡ ਵਿੱਚ, ਅਸੀਂ ਸਮੀਖਿਆ ਕਰਾਂਗੇ ਕਿ ਇਹ ਵਿਚਾਰ ਕਿਉਂ ਗਲਤ ਹਨ, ਅਤੇ ਅਜਿਹੀਆਂ ਗਲਤ ਧਾਰਨਾਵਾਂ ਇਸ ਹਮਲੇ ਦੇ ਵਿਧੀ ਦੀ ਪ੍ਰਸਿੱਧੀ ਵਿੱਚ ਕਿਵੇਂ ਯੋਗਦਾਨ ਪਾ ਰਹੀਆਂ ਹਨ, ਅਤੇ ਸੰਗਠਨਾਂ ਦੁਆਰਾ ਅਨੁਭਵ ਕੀਤੇ ਜਾ ਰਹੇ ਇੱਕ ਭਾਰੀ ਜੋਖਮ ਵਿੱਚ। ਅਸੀਂ ਇਸ ਨਾਲ ਸਮਾਪਤ ਕਰਾਂਗੇ ਕਿ ਕੀ ਕੰਮ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਸ ਵਿੱਚ ਸ਼ਾਮਲ ਯਤਨ ਅਤੇ ਸਰੋਤ ਕੀ ਹਨ।
- ਓਪਨ ਸੋਰਸ ਖਤਰਨਾਕ ਪੈਕੇਜ: ਜ਼ਾਇਜੇਨੀ ਪਹੁੰਚ. ਇਸ ਐਪੀਸੋਡ ਵਿੱਚ, ਅਸੀਂ ਪੇਸ਼ ਕਰਦੇ ਹਾਂ ਕਿ Xygeni 'ਤੇ ਸਾਡੇ ਮਾਲਵੇਅਰ ਅਰਲੀ ਵਾਰਨਿੰਗ (MEW) ਸਿਸਟਮ ਲਈ ਅਸੀਂ ਕਿਹੜੀ ਰਣਨੀਤੀ ਅਪਣਾਉਂਦੇ ਹਾਂ। ਇਹ ਮਲਟੀ-ਸਟੇਜ ਸਿਸਟਮ ਅਸਲ-ਸਮੇਂ ਵਿੱਚ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਇੱਕ ਨਵਾਂ ਪੈਕੇਜ ਸੰਸਕਰਣ ਪ੍ਰਕਾਸ਼ਿਤ ਹੁੰਦਾ ਹੈ, ਵੱਖ-ਵੱਖ ਸਰੋਤਾਂ ਤੋਂ ਸਬੂਤ ਕਿਵੇਂ ਹਾਸਲ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਟ੍ਰਾਈਏਜ ਕਿਵੇਂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਸੀਂ ਕਿਹੜੇ ਵਰਗੀਕਰਨ ਮਾਪਦੰਡਾਂ ਦੀ ਪਾਲਣਾ ਕਰ ਰਹੇ ਹਾਂ, ਅਤੇ ਇੱਕ ਖਤਰਨਾਕ ਪੈਕੇਜ ਉਮੀਦਵਾਰ ਦੀ ਪ੍ਰਕਿਰਤੀ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਅਜੇ ਕੁਝ ਦਸਤੀ ਵਿਸ਼ਲੇਸ਼ਣ ਦੀ ਲੋੜ ਕਿਉਂ ਹੈ? ਸਾਡੀਆਂ ਅੰਦਰੂਨੀ ਅਤੇ ਰਜਿਸਟਰੀ ਟੀਮਾਂ ਤੋਂ ਫੀਡਬੈਕ ਸਿਸਟਮ ਨੂੰ ਗਲਤ ਸਕਾਰਾਤਮਕਤਾਵਾਂ ਨੂੰ ਘੱਟੋ-ਘੱਟ ਕਰਨ ਲਈ ਇਕੱਠੇ ਕੀਤੇ ਗਏ ਪਿਛਲੇ ਸਬੂਤਾਂ ਤੋਂ ਸਿੱਖਣ ਵਿੱਚ ਕਿਵੇਂ ਮਦਦ ਕਰਦਾ ਹੈ। ਅਸੀਂ ਅਤੇ ਅਸੀਂ ਦੱਸਾਂਗੇ ਕਿ ਅਸੀਂ NPM, GitHub, PyPI, ਅਤੇ ਓਪਨ-ਸੋਰਸ ਓਪਨ ਸੋਰਸ ਈਕੋਸਿਸਟਮ ਵਿੱਚ ਹੋਰ ਮੁੱਖ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਨੂੰ ਨਿਵਾਸ ਸਮਾਂ ਘਟਾਉਣ ਵਿੱਚ ਕਿਵੇਂ ਮਦਦ ਕਰ ਰਹੇ ਹਾਂ।.
- ਓਪਨ ਸੋਰਸ ਦਾ ਸ਼ੋਸ਼ਣ: ਬੁਰੇ ਲੋਕਾਂ ਤੋਂ ਕੀ ਉਮੀਦ ਕੀਤੀ ਜਾਵੇ. ਇਹ ਲੜੀ ਉਨ੍ਹਾਂ ਨਵੀਆਂ ਕਾਰਵਾਈਆਂ 'ਤੇ ਕੇਂਦ੍ਰਿਤ ਹੈ ਜੋ ਵਿਰੋਧੀ ਹਮਲਿਆਂ ਨੂੰ ਗੁਪਤ, ਖੋਜਣ ਵਿੱਚ ਔਖਾ, ਖਾਸ ਉਦਯੋਗਾਂ ਵਿਰੁੱਧ ਵਧੇਰੇ ਨਿਸ਼ਾਨਾ ਬਣਾਉਣ ਅਤੇ ਇਸ ਸ਼੍ਰੇਣੀ ਦੇ ਹਮਲਿਆਂ ਤੋਂ ਵਧੇਰੇ ਲਾਭ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਅਪਣਾ ਰਹੇ ਹਨ। ਕੀ ਇਸ ਵਾਹਨ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਰੈਨਸਮਵੇਅਰ ਹਮਲੇ ਕੀਤੇ ਜਾਣਗੇ? ਬੁਰੇ ਲੋਕ ਵਧੇਰੇ ਸੂਝਵਾਨ ਖਤਰਨਾਕ ਪੈਕੇਜ ਪ੍ਰਦਾਨ ਕਰਨ ਲਈ AI ਟੂਲਸ ਦੀ ਵਰਤੋਂ ਕਿਵੇਂ ਕਰ ਰਹੇ ਹਨ? ਕੀ ਚੋਟੀ ਦੇ ਪ੍ਰਸਿੱਧ ਪ੍ਰੋਜੈਕਟ ਖ਼ਤਰੇ ਵਿੱਚ ਹਨ? ਇਹ ਪਾਠਕਾਂ ਨੂੰ ਇਸ ਹਥਿਆਰਾਂ ਦੀ ਦੌੜ ਬਾਰੇ ਇੱਕ ਭਾਵਨਾ ਦੇਣ ਲਈ ਹੈ, ਅਤੇ ਥੋੜ੍ਹੇ ਸਮੇਂ (2024 ਦੇ ਦੂਜੇ ਅੱਧ) ਅਤੇ ਮੱਧਮ ਮਿਆਦ (2025) ਵਿੱਚ ਕੀ ਉਮੀਦ ਕਰਨੀ ਹੈ। ਅਸੀਂ ਸਿੱਖਾਂਗੇ ਕਿ ਹਾਲ ਹੀ ਦੇ ਹਮਲੇ ਕਿਵੇਂ ਪਸੰਦ ਹਨ XZ-Utils ਬੈਕਡੋਰ, ਜਾਂ ਜ਼ਮੀਨ ਤੋਂ ਬਾਹਰ ਰਹਿਣ ਵਾਲੇ ਹਮਲੇ 'ਤੇ ਇਲੈਕਟ੍ਰਾਨ-ਨਿਰਮਾਤਾ ਮਾਰਚ 2024 ਵਿੱਚ ਹੋਣ ਵਾਲੇ ਨਤੀਜੇ ਦਿਖਾ ਰਹੇ ਹਨ ਕਿ ਸਾਨੂੰ ਵਿਰੋਧੀਆਂ ਦੇ ਵਿਕਾਸ ਬਾਰੇ ਚੌਕਸ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ।
ਆਓ ਪਹਿਲੇ ਐਪੀਸੋਡ ਨਾਲ ਸਟੇਜ ਦੀ ਸ਼ੁਰੂਆਤ ਕਰੀਏ: ਖਤਰਨਾਕ ਓਪਨ-ਸੋਰਸ ਓਪਨ ਸੋਰਸ ਪੈਕੇਜਾਂ ਨਾਲ ਕੀ ਹੋ ਰਿਹਾ ਹੈ?
ਓਪਨ ਸੋਰਸ ਪੈਕੇਜਾਂ ਨਾਲ ਕੀ ਸਮੱਸਿਆ ਹੈ?
ਹਾਲ ਹੀ ਦੇ ਸਾਲਾਂ ਵਿੱਚ, ਹਰ ਤਰ੍ਹਾਂ ਦੇ ਗਲਤ ਲੋਕਾਂ ਨੇ ਖਤਰਨਾਕ ਵਿਵਹਾਰ ਪ੍ਰਦਾਨ ਕਰਨ ਲਈ ਓਪਨ-ਸੋਰਸ ਓਪਨ ਸੋਰਸ ਸਾਫਟਵੇਅਰ ਰਜਿਸਟਰੀਆਂ ਦੀ ਵਰਤੋਂ ਕੀਤੀ। ਇਹ ਗਤੀਵਿਧੀਆਂ ਓਪਨ ਸੋਰਸ ਜਿੰਨੀਆਂ ਹੀ ਪੁਰਾਣੀਆਂ ਹਨ, ਪਰ ਪਿਛਲੇ ਤਿੰਨ ਸਾਲਾਂ ਵਿੱਚ ਇਨ੍ਹਾਂ ਦੀ ਬਾਰੰਬਾਰਤਾ ਵਿੱਚ ਵਿਸਫੋਟ ਹੋਇਆ ਹੈ।
ਜਨਤਕ ਰਜਿਸਟਰੀਆਂ ਵਿੱਚ ਖਤਰਨਾਕ ਹਿੱਸਿਆਂ ਨੂੰ ਪ੍ਰਕਾਸ਼ਤ ਕਰਨਾ (ਨਿਰਭਰਤਾ-ਅਧਾਰਤ ਹਮਲੇ) ਇੱਕ ਅਸਮਿਤ ਗੁਰੀਲਾ ਯੁੱਧ ਹੈ ਜਿਸਦੀ ਵਰਤੋਂ ਧਮਕੀ ਦੇਣ ਵਾਲੇ ਲੋਕ ਮਾਲਵੇਅਰ ਵੰਡਣ ਲਈ ਕਰਦੇ ਹਨ, ਉਸ ਭਰੋਸੇ ਦਾ ਲਾਭ ਉਠਾਉਂਦੇ ਹੋਏ ਜੋ ਸੰਗਠਨ ਅਣਜਾਣ ਡਿਵੈਲਪਰਾਂ ਤੋਂ ਆਉਣ ਵਾਲੇ ਓਪਨ-ਸੋਰਸ ਹਿੱਸਿਆਂ ਵਿੱਚ ਪਾਉਂਦੇ ਹਨ (ਯਾਦ ਰੱਖੋ ਨਿਰਭਰਤਾ xkcd ਕਾਮਿਕ?). ਕਿਉਂਕਿ ਤੁਸੀਂ ਪੈਕੇਜਾਂ 'ਤੇ ਭਰੋਸਾ ਕਰਦੇ ਹੋ ਅਤੇ ਪੈਕੇਜ ਸਮੱਗਰੀ ਅਤੇ ਉਹਨਾਂ ਦੀ ਨਿਰਭਰਤਾ ਦੀ ਹੱਥੀਂ ਸਮੀਖਿਆ ਕਰਨ ਵਿੱਚ ਕੋਈ ਇਤਰਾਜ਼ ਨਹੀਂ ਰੱਖਦੇ, ਇਹ ਹਮਲੇ ਅਸਾਧਾਰਨ ਤੌਰ 'ਤੇ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹਨ। ਅਤੇ ਅਸਮਾਨਤਾ ਇਸ ਲਈ ਆਉਂਦੀ ਹੈ ਕਿਉਂਕਿ ਉਹਨਾਂ ਨੂੰ ਵੱਡੇ ਪੱਧਰ 'ਤੇ ਸਵੈਚਾਲਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਅਤੇ ਬੁਰੇ ਲੋਕਾਂ ਨੂੰ ਪੀੜਤ ਨਾਲ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਗੱਲਬਾਤ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਨਹੀਂ ਹੁੰਦੀ ਹੈ। ਉਹ ਸਿਰਫ਼ ਪੈਕੇਜ ਨੂੰ ਜਨਤਕ ਰਜਿਸਟਰੀ ਵਿੱਚ ਅਪਲੋਡ ਕਰਦੇ ਹਨ ਅਤੇ ਇਸਨੂੰ ਜਾਣ ਦਿੰਦੇ ਹਨ।
ਖ਼ਰਾਬ ਪੈਕੇਜ 2022 ਵਿੱਚ 6 ਗੁਣਾ ਵਾਧਾ ਹੋਇਆ, ਅਤੇ 2023 ਵਿੱਚ 2.5 ਗੁਣਾ ਵਧਦਾ ਰਿਹਾ। ਪਿਛਲੇ ਸਾਲ 245,000 ਖਤਰਨਾਕ ਪੈਕੇਜ ਦੇਖੇ ਗਏ ਸਨ, ਜੋ ਕਿ ਪਿਛਲੇ ਸਾਲਾਂ ਦੀ ਕੁੱਲ ਸੰਖਿਆ ਨਾਲੋਂ ਦੁੱਗਣੇ ਤੋਂ ਵੀ ਵੱਧ ਹੈ। ਇਹ ਘਾਤਕ ਵਾਧਾ ਹੈ! 2021 ਦੌਰਾਨ ਸੈਂਕੜੇ ਅਤੇ 2022 ਦੌਰਾਨ ਹਜ਼ਾਰਾਂ ਵਿੱਚ ਪੁਸ਼ਟੀ ਕੀਤੇ ਮਾਲਵੇਅਰ ਦੇ ਰੂਪ ਵਿੱਚ ਪੈਕੇਜ ਹਟਾਉਣ ਤੋਂ ਲੈ ਕੇ ਅਸੀਂ 2023 ਦੌਰਾਨ ਬਹੁਤ ਜ਼ਿਆਦਾ ਪਿਛੋਕੜ "ਸ਼ੋਰ" ਦੇਖਿਆ, ਇਸ ਸਾਲ ਲਈ ਵੀ ਇਸੇ ਤਰ੍ਹਾਂ ਦੀ ਗਤੀ ਦੇ ਨਾਲ। ਅਤੇ "ਘੱਟ ਤੋਂ ਘੱਟ ਵਿਰੋਧ ਦੇ ਮਾਰਗ" 'ਤੇ ਚੱਲਦੇ ਹੋਏ ਬੇਢੰਗੇ ਸਾਈਬਰ ਅਪਰਾਧੀਆਂ ਦੁਆਰਾ ਪੈਦਾ ਹੋਏ ਉਸ ਪਿਛੋਕੜ ਵਿੱਚ ਲੁਕੇ ਹੋਏ, ਉੱਚ-ਪ੍ਰੋਫਾਈਲ ਹਮਲਿਆਂ ਦੀ ਇੱਕ ਘੱਟ ਗਿਣਤੀ ਆਮ ਮੀਡੀਆ ਵਿੱਚ ਵੀ ਸੁਰਖੀਆਂ ਵਿੱਚ ਪਹੁੰਚ ਗਈ।
ਇਹ ਇੰਨੀ ਵੱਡੀ ਸਮੱਸਿਆ ਕਿਉਂ ਹੈ? ਇੱਕ ਹੈ ਭਰੋਸੇ ਦੀ ਹੱਦੋਂ ਵੱਧ ਸਾਰੀ ਚੇਨ ਵਿੱਚ। ਓਪਨ-ਸੋਰਸ ਸਾਫਟਵੇਅਰ ਨੂੰ ਇਸਦੇ ਸਰੋਤ ਕੋਡ ਨਾਲ ਵੰਡਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਇੱਕ ਦਿੱਤੇ ਲਾਇਸੈਂਸ ਦੇ ਤਹਿਤ ਜਾਰੀ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਹਾਂ, ਕੋਈ ਵੀ ਸਰੋਤ ਕੋਡ ਦੀ ਜਾਂਚ ਕਰ ਸਕਦਾ ਹੈ; ਪਰ, ਕੌਣ ਕਰਦਾ ਹੈ? ਕੌਣ, ਇਹ ਜਾਂਚ ਕਰਨ ਤੋਂ ਬਾਅਦ ਕਿ ਸਾਫਟਵੇਅਰ ਵਿੱਚ ਕੋਈ ਮਾਲਵੇਅਰ ਨਹੀਂ ਹੈ, ਸਰੋਤਾਂ ਤੋਂ ਸਾਫਟਵੇਅਰ ਬਣਾਉਂਦਾ ਹੈ? ਕੌਣ, ਪੈਕੇਜ ਕੀਤੇ ਹਿੱਸੇ ਨੂੰ ਪਾਸ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ (ਜਿਸਨੂੰ ਇੱਕ ਪੈਕੇਜ) ਪੈਕੇਜ ਮੈਨੇਜਰ ਜਾਂ ਬਿਲਡ ਟੂਲ ਤੱਕ ਡਾਊਨਸਟ੍ਰੀਮ ਭੇਜ ਕੇ, ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਪੈਕੇਜ ਮਾਲਵੇਅਰ ਨਾਲ ਭਰਿਆ ਨਹੀਂ ਹੈ ਅਤੇ ਉਸ ਮੰਨੇ ਜਾਂਦੇ ਸਰੋਤ ਕੋਡ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ ਜਿੱਥੋਂ ਇਹ ਆਉਣਾ ਚਾਹੀਦਾ ਹੈ?
ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਇੰਨੇ ਆਸਾਨ ਹਮਲਿਆਂ ਦੀ ਇਜਾਜ਼ਤ ਕਿਉਂ ਦਿੰਦਾ ਹੈ?
ਪੈਕੇਜ ਰਜਿਸਟਰੀਆਂ ਖੁੱਲ੍ਹੇ ਹੁੰਦੇ ਹਨ, ਜਿਨ੍ਹਾਂ ਲਈ ਅਕਸਰ ਪ੍ਰਕਾਸ਼ਕ ਦੀ ਪਛਾਣ ਦੀ ਘੱਟੋ-ਘੱਟ ਤਸਦੀਕ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। "ਕੋਈ ਵੀ ਇੱਥੇ ਆਪਣਾ ਸਾਫਟਵੇਅਰ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨ ਲਈ ਸਵਾਗਤ ਕਰਦਾ ਹੈ!" ਹਮਲਾਵਰਾਂ ਲਈ ਬਾਰ ਘੱਟ ਸੈੱਟ ਕੀਤਾ ਗਿਆ ਹੈ: ਉਹ ਡਿਸਪੋਸੇਬਲ ਈਮੇਲ ਪਤਿਆਂ ਅਤੇ ਡਿਸਪੋਸੇਬਲ GitHubgithub ਖਾਤਿਆਂ ਦੀ ਵਰਤੋਂ ਛੋਟੇ, ਫਿਸ਼ਿੰਗ ਵਰਗੇ, ਮੁਹਿੰਮਾਂ ਵਿੱਚ ਸੈਂਕੜੇ ਖਤਰਨਾਕ ਪੈਕੇਜ ਬਣਾਉਣ ਲਈ ਕਰਦੇ ਹਨ। ਸਿਰਫ਼ ਨਿਸ਼ਾਨਾ ਬਣਾਏ ਗਏ ਲੋਕਾਂ ਲਈ ਇੱਕ ਉੱਚ ਸੂਝ-ਬੂਝ ਦੀ ਲੋੜ ਹੈ: ਅਸੀਂ ਬਹੁਤ ਸਾਰੇ ਸਿਤਾਰਿਆਂ ਦੇ ਨਾਲ ਇੱਕ ਭਰੋਸੇਯੋਗ GitHub ਸਰੋਤ ਰਿਪੋਜ਼ਟਰੀ ਬਣਾਉਣਾ ਵੀ ਦੇਖਿਆ ਹੈ ਅਤੇ commitਕਈ ਨਕਲੀ ਯੋਗਦਾਨ ਪਾਉਣ ਵਾਲਿਆਂ ਅਤੇ ਪ੍ਰਸਿੱਧੀ ਅਤੇ ਰੱਖ-ਰਖਾਅ ਦੇ ਹੋਰ ਮਾਪਦੰਡਾਂ ਤੋਂ ਪ੍ਰਾਪਤ ਕਰਨਾ। ਨਕਲੀ ਯੋਗਦਾਨਾਂ ਤੋਂ ਸਟਾਰਗੇਜ਼ਰ ਅਤੇ ਸਾਖ ਆਟੋਮੈਟਿਕ ਕਰਨਾ ਔਖਾ ਨਹੀਂ ਹੈ। ਅਸੀਂ ਹਰ ਤਰ੍ਹਾਂ ਦੇ ਓਪਨ ਸਾਫਟਵੇਅਰ ਬੁਨਿਆਦੀ ਢਾਂਚੇ 'ਤੇ ਦੁਰਵਿਵਹਾਰ ਦੇਖੇ, ਸਿਰਫ਼ ਮਾਲਵੇਅਰ ਹੀ ਨਹੀਂ, ਜਿਵੇਂ ਕਿ ਚਾਹ ਪ੍ਰੋਟੋਕੋਲ ਘਟਨਾ.
ਪੈਕੇਜ ਮੈਨੇਜਰਾਂ ਨੂੰ ਵਰਤੋਂ ਵਿੱਚ ਆਸਾਨੀ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਸੀ, ਸੁਰੱਖਿਆ ਲਈ ਨਹੀਂ।. ਉਹ ਇੰਸਟਾਲ ਤੋਂ ਪਹਿਲਾਂ ਅਤੇ ਇੰਸਟਾਲ ਤੋਂ ਬਾਅਦ ਦੀਆਂ ਸਕ੍ਰਿਪਟਾਂ ਚਲਾ ਸਕਦੇ ਹਨ (ਕਈ ਵਾਰ ਲਾਇਬ੍ਰੇਰੀ ਲਈ ਨੇਟਿਵ ਕੋਡ ਕੰਪਾਇਲ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੁੰਦਾ ਹੈ)। ਨਾਲ ਹੀ, ਪੈਕੇਜ ਮੈਨੇਜਰ ਕਈ ਸਰੋਤਾਂ ਤੋਂ ਪੈਕੇਜ ਇੰਸਟਾਲ ਕਰੋ, ਅਤੇ ਕਈ ਵਾਰ ਡਿਫਾਲਟ ਪਬਲਿਕ ਰਜਿਸਟਰੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਹੁੰਦਾ ਹੈ। ਉਹਨਾਂ ਨੇ ਪ੍ਰਕਾਸ਼ਨ ਬੇਨਤੀ ਵਿੱਚ ਮੈਟਾਡੇਟਾ ਅਤੇ ਪੈਕੇਜ ਵਿੱਚ ਹੀ ਮੈਟਾਡੇਟਾ ਵਿਚਕਾਰ ਕਿਸੇ ਮੇਲ ਦੀ ਜਾਂਚ ਨਹੀਂ ਕੀਤੀ।
ਨਿਰਭਰਤਾਵਾਂ ਨੇਸਟ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ ਅਤੇ ਇੱਕ ਗ੍ਰਾਫ਼ ਬਣਾਉਂਦੀਆਂ ਹਨ। ਨੋਡ (ਜਾਵਾ ਸਕ੍ਰਿਪਟ) ਵਰਗੇ ਕੁਝ ਈਕੋਸਿਸਟਮ ਵਿੱਚ, ਛੋਟੀਆਂ-ਛੋਟੀਆਂ ਨਿਰਭਰਤਾਵਾਂ ਸੈਂਕੜੇ ਜਾਂ ਹਜ਼ਾਰਾਂ ਵਿੱਚ ਇਕੱਠੀਆਂ ਹੁੰਦੀਆਂ ਹਨ। ਇੱਕ ਗੱਲ ਇਹ ਹੈ ਕਿ ਮੇਰੇ ਸਾਫਟਵੇਅਰ ਪ੍ਰੋਜੈਕਟਾਂ ਦੁਆਰਾ ਘੋਸ਼ਿਤ ਸਿੱਧੀਆਂ ਨਿਰਭਰਤਾਵਾਂ 'ਤੇ ਸਖਤ ਨਿਯੰਤਰਣ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਪਰ ਪਰਿਵਰਤਨਸ਼ੀਲ ਨਿਰਭਰਤਾਵਾਂ ਕੰਟਰੋਲ ਕਰਨਾ ਔਖਾ ਹੈ। ਓਪਨ ਸੋਰਸ "ਮੇਰੇ ਦੋਸਤਾਂ ਦੇ ਦੋਸਤ ਮੇਰੇ ਦੋਸਤ ਹਨ" ਦੀ ਪਾਲਣਾ ਕਰਦਾ ਹੈ। ਜੰਗਲੀ ਦੂਰ ਪੂਰਬ ਵਿੱਚ ਭਾਈਚਾਰਾ ਆਮ ਹੈ! ਧਮਕੀ ਦੇਣ ਵਾਲੇ ਇਹ ਜਾਣਦੇ ਹਨ ਅਤੇ ਅਸਪਸ਼ਟ ਨਿਰਭਰਤਾਵਾਂ ਵਿੱਚ ਖਤਰਨਾਕ ਵਿਵਹਾਰ ਨੂੰ ਡੂੰਘਾਈ ਨਾਲ ਛੁਪਾਉਂਦੇ ਹਨ ਜੋ ਅਕਸਰ ਅਣਜਾਣ ਹੁੰਦੇ ਹਨ। ਇਹ ਮਾਮਲਾ ਸੀ ਇਵੈਂਟ-ਸਟ੍ਰੀਮ ਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾ ਕੇ ਕੀਤੀ ਗਈ ਘਟਨਾ ਕੋਪੇ ਵਾਲਿਟ.
ਓਪਨ-ਸੋਰਸ ਸੌਫਟਵੇਅਰ ਆਪਣੀ ਸ਼ੁਰੂਆਤ ਤੋਂ ਹੀ ਇਸ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦਾ ਰਿਹਾ ਹੈ। ਇਸ ਵਿੱਚ ਬਹੁਤਾ ਬਦਲਾਅ ਨਹੀਂ ਆਵੇਗਾ। ਕੁਝ ਪੈਕੇਜ ਰਜਿਸਟਰੀਆਂ ਸਭ ਤੋਂ ਵਧੀਆ ਦੋ-ਕਾਰਕ ਪ੍ਰਮਾਣਿਕਤਾ ਦੀ ਮੰਗ ਕਰ ਰਹੀਆਂ ਹਨ, ਅਤੇ ਅਕਸਰ ਸਿਰਫ਼ ਸਭ ਤੋਂ ਪ੍ਰਸਿੱਧ ਪੈਕੇਜਾਂ ਲਈ। ਕੁਝ ਰਜਿਸਟਰੀਆਂ ਸਕੋਪਸ ਪ੍ਰਦਾਨ ਕਰਦੀਆਂ ਹਨ, ਇੱਕ ਨੇਮਸਪੇਸ ਜੋ ਕਿ ਇੱਕ ਜਾਂਚ ਕੀਤੀ ਗਈ ਸੰਸਥਾ ਦੀ ਮਲਕੀਅਤ ਹੈ, ਪਰ ਦੁਖਦਾਈ ਤੌਰ 'ਤੇ ਦੂਸਰੇ ਇਸਦਾ ਸਮਰਥਨ ਨਹੀਂ ਕਰਦੇ (PyPI) ਜਾਂ ਇਸਨੂੰ ਵਿਕਲਪਿਕ (NPM) ਬਣਾਉਂਦੇ ਹਨ। ਇਹ ਧਿਆਨ ਦੇਣ ਵਾਲੀ ਗੱਲ ਹੈ ਕਿ ਇੱਕ ਸਧਾਰਨ ਸਕ੍ਰੀਨਿੰਗ ਸਕੀਮ (ਗਰੁੱਪ ਆਈਡੀ ਨਾਲ ਮੇਲ ਖਾਂਦੇ DNS ਜਾਂ GitHub ਰਿਪੋਜ਼ਟਰੀ/ਸੰਗਠਨ ਦੇ ਨਿਯੰਤਰਣ ਦੇ ਆਧਾਰ 'ਤੇ) ਅਤੇ ਬਣਾਉਣਾ ਪੀਜੀਪੀ ਦਸਤਖਤ ਲਾਜ਼ਮੀ ਹਨ ਚੈੱਕਸਮ ਨੂੰ ਛੱਡ ਕੇ ਸਾਰੀਆਂ ਕਲਾਕ੍ਰਿਤੀਆਂ ਲਈ ਜ਼ਿਆਦਾਤਰ "ਸ਼ੋਰ", ਟਾਈਪੋਸਕੈਟਿੰਗ ਵਰਗੇ ਖਤਰਨਾਕ ਪੈਕੇਜਾਂ ਨੂੰ ਹਟਾਉਂਦਾ ਹੈ, ਅਤੇ ਬਹੁਤ ਸਾਰੇ ਨੂੰ ਸੀਮਤ ਕਰਦਾ ਹੈ ਨਿਰਭਰਤਾ ਉਲਝਣ. ਸੂਝਵਾਨ ਹਮਲੇ ਸੰਭਵ ਹਨ ਪਰ ਬਹੁਤ ਔਖੇ ਹਨ, ਸਿਰਫ ਕੁਝ ਕੁ ਹੀ ਹਨ ਜਿਵੇਂ ਕਿ com.github.codingandcoding:maven-ਕੰਪਾਈਲਰ-ਪਲੱਗਇਨ ਮਾਵੇਨ ਸੈਂਟਰਲ ਲਈ ਜਾਣਿਆ ਜਾਂਦਾ ਹੈ। ਅਤੇ ਸਾਰੀਆਂ ਮਾਵੇਨ ਰਜਿਸਟਰੀਆਂ ਇੱਕੋ ਜਿਹੇ ਅਭਿਆਸਾਂ ਦੀ ਪਾਲਣਾ ਨਹੀਂ ਕਰਦੀਆਂ!
ਪੈਕੇਜ ਪ੍ਰਬੰਧਕਾਂ 'ਤੇ ਸੁਰੱਖਿਆ ਨਿਯੰਤਰਣ ਬੋਝ ਪਾ ਸਕਦੇ ਹਨ ਪਰ ਨਿਰਭਰਤਾ ਹਮਲਿਆਂ ਨੂੰ ਰੋਕ ਨਹੀਂ ਸਕਦੇ। ਮਲਟੀ-ਫੈਕਟਰ ਪ੍ਰਮਾਣਿਕਤਾ ਦੀ ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਆਟੋਮੇਸ਼ਨ ਲਈ, ਐਕਸੈਸ ਟੋਕਨ ਜਾਂ APIapi ਕੁੰਜੀਆਂ ਵਰਗੇ ਪ੍ਰਾਪਤ ਪ੍ਰਮਾਣ ਪੱਤਰ ਆਟੋਮੇਸ਼ਨ ਸਕ੍ਰਿਪਟਾਂ ਤੋਂ ਕੀਤੀਆਂ ਗਈਆਂ APIapi ਕਾਲਾਂ ਵਿੱਚ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਖਾਤਿਆਂ ਲਈ ਤਿਆਰ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਬਿਨਾਂ ਕਿਸੇ ਬੈਕਿੰਗ ਇੰਟਰਐਕਟਿਵ ਉਪਭੋਗਤਾ ਦੁਆਰਾ ਦੂਜਾ ਕਾਰਕ ਪ੍ਰਦਾਨ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। MFA ਉਪਭੋਗਤਾ ਖਾਤਿਆਂ ਨੂੰ ਪਾਸਵਰਡ ਲੀਕ ਤੋਂ ਬਚਾਉਣ ਲਈ ਚੰਗਾ ਹੈ, ਪਰ ਤਿਆਰ ਕੀਤੇ ਐਕਸੈਸ ਟੋਕਨ ਜਾਂ APIapi ਕੁੰਜੀਆਂ ਨੂੰ ਕਿਰਿਆਸ਼ੀਲ ਹੋਣ 'ਤੇ ਸੁਰੱਖਿਅਤ ਰੱਖਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ, ਨਹੀਂ ਤਾਂ ਉਨ੍ਹਾਂ ਦੇ ਮਾਲਕ ਵਿਰੋਧੀਆਂ ਦੁਆਰਾ ਨਕਲ ਕੀਤੇ ਜਾਣਗੇ। ਪੈਕੇਜ-ਅਧਾਰਤ ਸਪਲਾਈ ਚੇਨ ਮੁਹਿੰਮਾਂ ਦਾ ਇੱਕ ਵੱਡਾ ਹਿੱਸਾ ਲੀਕ ਹੋਈ ਕੁੰਜੀ/ਟੋਕਨ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ। ਬੱਸ ਇਸ ਤਰ੍ਹਾਂ ਦੀਆਂ ਘਟਨਾਵਾਂ ਨੂੰ ਯਾਦ ਰੱਖੋ ਲੇਜ਼ਰ, 3CX, ਅਤੇ ਹੋਰ ਬਹੁਤ ਸਾਰੇ, ਜਿੱਥੇ ਸਪਲਾਈ ਚੇਨ ਹਮਲੇ ਨੂੰ ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਸ਼ੁਰੂਆਤੀ ਘੁਸਪੈਠ ਵਿੱਚ ਗੈਰ-ਇੰਟਰਐਕਟਿਵ ਪ੍ਰਮਾਣ ਪੱਤਰਾਂ ਨੂੰ ਪਹਿਲਾਂ ਬਾਹਰ ਕੱਢ ਦਿੱਤਾ ਗਿਆ ਸੀ।
ਇਸ ਧਮਕੀ ਦਾ ਜਵਾਬ ਕਾਫ਼ੀ ਮਜ਼ਬੂਤ ਨਹੀਂ ਸੀ। ਤੀਜੇ ਐਪੀਸੋਡ ਵਿੱਚ, ਅਸੀਂ ਇਸ ਗੱਲ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰਾਂਗੇ ਕਿ ਕੀ ਕੰਮ ਕੀਤਾ, ਅਤੇ ਕੀ ਬੁਰੀ ਤਰ੍ਹਾਂ ਅਸਫਲ ਰਿਹਾ। ਉਦਯੋਗ ਨੂੰ ਸਮੂਹਿਕ ਤੌਰ 'ਤੇ ਕੰਮ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ standards, ਪ੍ਰਕਿਰਿਆਵਾਂ, ਸਿੱਖਿਆ, ਅਤੇ ਗਲੋਬਲ ਸਪਲਾਈ ਚੇਨਾਂ ਲਈ ਜੋਖਮਾਂ ਨੂੰ ਘਟਾਉਣ ਲਈ ਟੂਲਿੰਗ। ਇਹ ਕੋਈ ਅਜਿਹੀ ਸਮੱਸਿਆ ਨਹੀਂ ਹੈ ਜੋ ਕੋਈ ਇੱਕਲਾ ਸੰਗਠਨ ਆਪਣੇ ਆਪ ਹੱਲ ਕਰ ਸਕਦਾ ਹੈ।
ਇਸ ਭਾਗ ਨੂੰ ਖਤਮ ਕਰਨ ਲਈ, ਮਹੱਤਵਪੂਰਨ ਗਲਤਫਹਿਮੀ: ਅਸੀਂ ਗੱਲ ਕਰ ਰਹੇ ਹਾਂ ਖਤਰਨਾਕ ਪੈਕੇਜ, ਨਹੀਂ ਕਮਜ਼ੋਰ ਇੱਕ। ਕਮਜ਼ੋਰੀਆਂ ਡਿਜ਼ਾਈਨ ਜਾਂ ਕੋਡਿੰਗ ਗਲਤੀਆਂ ਤੋਂ ਆਉਂਦੀਆਂ ਹਨ, ਗਲਤੀ ਨਾਲ ਪੇਸ਼ ਕੀਤੀਆਂ ਗਈਆਂ, ਬਿਨਾਂ ਕਿਸੇ ਮਾੜੇ ਇਰਾਦੇ ਦੇ। ਕਮਜ਼ੋਰੀਆਂ ਦਾ ਸ਼ੋਸ਼ਣ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਪਰ ਬਹੁਤ ਸਾਰੀਆਂ ਨਹੀਂ ਹਨ। ਖਤਰਨਾਕ ਪੈਕੇਜ ਹਮੇਸ਼ਾ ਜਾਣਬੁੱਝ ਕੇ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਜੇਕਰ ਉਹਨਾਂ ਨੂੰ ਚਲਾਇਆ ਜਾਂਦਾ ਹੈ ਤਾਂ 100% ਸ਼ੋਸ਼ਣਯੋਗਤਾ ਹੁੰਦੀ ਹੈ। ਕੋਈ ਤੁਲਨਾਤਮਕ ਜੋਖਮ ਨਹੀਂ! ਇਸ ਲਈ ਇਹ ਦੇਖਣਾ ਵਿਰੋਧਾਭਾਸੀ ਹੈ ਕਿ ਕਮਜ਼ੋਰੀਆਂ ਦਾ ਪਤਾ ਲਗਾਉਣ ਅਤੇ ਘਟਾਉਣ ਲਈ ਕਿੰਨੇ ਯਤਨ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਖਤਰਨਾਕ ਹਿੱਸਿਆਂ ਲਈ ਬਰਾਬਰ ਉਪਾਵਾਂ ਦੀ ਘਾਟ ਹੈ।.
"ਅਸੀਂ ਸੁਰੱਖਿਆ ਨੂੰ ਗੰਭੀਰਤਾ ਨਾਲ ਲੈਂਦੇ ਹਾਂ"
ਆਓ ਰਿਵਾਜ ਦੀ ਕਲਪਨਾ ਕਰੀਏ Acme ਕਾਰਪੋਰੇਸ਼ਨ. Acme, WileCoyote.com ਲਈ ਇੱਕ ਪ੍ਰਮੁੱਖ ਪ੍ਰਦਾਤਾ, ਕੋਲ ਇਸਦੇ ਜ਼ਿਆਦਾਤਰ ਸੌਫਟਵੇਅਰ ਤੀਜੀ ਧਿਰਾਂ ਤੋਂ ਆਉਂਦੇ ਹਨ, ਜਿਸ ਵਿੱਚ 80% ਤੋਂ ਵੱਧ ਓਪਨ-ਸੋਰਸ ਸੋਰਸ ਪ੍ਰੋਜੈਕਟ ਹਨ। ਉਹ ਅੰਦਰੂਨੀ ਵਰਤੋਂ ਲਈ ਸੌਫਟਵੇਅਰ ਤਿਆਰ ਕਰਦੇ ਹਨ, ਪਰ ਉਹ ਆਪਣੇ ਭਾਈਵਾਲਾਂ, ਪ੍ਰਦਾਤਾਵਾਂ ਅਤੇ ਗਾਹਕਾਂ / ਅੰਤਮ-ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਸੌਫਟਵੇਅਰ ਵੀ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ। Acme ਕੋਲ Go, JavaScript, Java, C#, ਅਤੇ Python ਵਿੱਚ ਲਿਖਿਆ ਸੌਫਟਵੇਅਰ ਹੈ, ਅਤੇ ਇਸਦੇ ਜ਼ਿਆਦਾਤਰ ਸੌਫਟਵੇਅਰ ਨੂੰ ਕਲਾਉਡ 'ਤੇ, Kuberneteskubernetes ਕਲੱਸਟਰਾਂ ਦੇ ਅਧੀਨ ਚਲਾਉਂਦਾ ਹੈ। Acme ਡੌਕਰ ਹੱਬ ਅਤੇ ਹੋਰ ਰਜਿਸਟਰੀਆਂ ਤੋਂ ਲਈਆਂ ਗਈਆਂ ਬੇਸ ਤਸਵੀਰਾਂ ਤੋਂ ਆਪਣੀਆਂ ਕਸਟਮ ਤਸਵੀਰਾਂ ਬਣਾਉਂਦਾ ਹੈ। ਅਤੇ ਉਹ ਜਨਤਕ ਰਜਿਸਟਰੀਆਂ ਵਿੱਚ ਕੁਝ ਲਾਇਬ੍ਰੇਰੀਆਂ, ਪੈਕੇਜ ਅਤੇ ਕੰਟੇਨਰ ਚਿੱਤਰਾਂ ਨੂੰ ਵੀ ਸਾਂਝਾ ਕਰਦੇ ਹਨ।
Acme ਸੁਰੱਖਿਆ ਨੂੰ ਗੰਭੀਰਤਾ ਨਾਲ ਲੈਂਦਾ ਹੈ। ਉਹ ਇਸ ਸਮੱਸਿਆ ਤੋਂ ਕਾਫ਼ੀ ਜਾਣੂ ਹਨ open source security, ਅਤੇ ਇਸ ਨਾਲ ਹੋਣ ਵਾਲਾ ਜੋਖਮ। ਸਾਰੇ ਡਿਵੈਲਪਰ, ਸਿਸਟਮ ਮੈਨੇਜਰ, ਅਤੇ DevOpsdevops ਇੰਜੀਨੀਅਰ ਉਹਨਾਂ ਪਿਆਰੀਆਂ ਛੋਟੀਆਂ ਕ੍ਰਿਪਟੋ ਕੁੰਜੀਆਂ ਨੂੰ ਦੂਜੇ-ਕਾਰਕ ਪ੍ਰਮਾਣੀਕਰਨ ਵਜੋਂ ਵਰਤਦੇ ਹਨ। ਸਾਰੇ commitਕੋਡ ਰਿਪੋਜ਼ 'ਤੇ ਦਸਤਖਤ ਕੀਤੇ ਗਏ ਹਨ, ਲਾਜ਼ਮੀ ਕੋਡ ਸਮੀਖਿਆਵਾਂ ਨਾਲ ਸ਼ਾਖਾ ਸੁਰੱਖਿਆ ਸਮਰੱਥ ਹੈ, CI/CD ਤਾਲਾਬੰਦ, ਗੁਪਤ ਵਾਲਟ ਵਿੱਚ ਸਟੋਰ ਕੀਤੇ ਭੇਦ, ਅਤੇ ਇੱਕ ਅੰਦਰੂਨੀ ਰਜਿਸਟਰੀ ਦੇ ਨਾਲ ਅੰਸ਼ਕ ਤੌਰ 'ਤੇ ਬਾਹਰੀ ਰਜਿਸਟਰੀਆਂ ਨੂੰ ਪ੍ਰਤੀਬਿੰਬਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜਿੱਥੇ ਸਿਰਫ਼ ਆਗਿਆ ਪ੍ਰਾਪਤ, ਵਾਈਟ-ਲਿਸਟ ਕੀਤੇ ਭਾਗ ਹੀ ਸਟੋਰ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਇਹ ਜ਼ਰੂਰੀ ਹੈ ਕਿ Acme ਦੁਆਰਾ ਬਣਾਇਆ ਗਿਆ ਸਾਫਟਵੇਅਰ ਇਸ ਰਜਿਸਟਰੀ ਤੋਂ ਤੀਜੀ-ਧਿਰ ਨਿਰਭਰਤਾ ਲਵੇ।
ਸ਼ਾਇਦ ਜ਼ਿਆਦਾਤਰ ਸੰਸਥਾਵਾਂ ਇਸ ਪ੍ਰੋਫਾਈਲ ਵਿੱਚ ਫਿੱਟ ਬੈਠਦੀਆਂ ਹਨ। ਪਿਆਰੇ ਪਾਠਕ, ਜੇ ਤੁਸੀਂ ਅਜੇ ਇੱਥੇ ਹੋ ਤਾਂ ਤੁਹਾਡਾ ਵੀ ਫਿੱਟ ਬੈਠਦਾ ਹੈ, ਹੈ ਨਾ?
ਫਿਰ ਇੱਕ ਬਦਕਿਸਮਤ ਦਿਨ, ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਫਰੰਟਐਂਡ ਡਿਵੈਲਪਰ ਐਕਮੀ ਰਨ 'ਤੇ npm ਇੰਸਟਾਲ acme-cute-lib, ਇਹ ਭੁੱਲ ਜਾਣਾ ਕਿ @acme/cute-lib ਸਹੀ ਸਕੋਪਡ ਨਿਰਭਰਤਾ ਸੀ। ਸਹੀ ਗਲਤੀ ਮਹੱਤਵਪੂਰਨ ਨਹੀਂ ਹੈ, ਬਹੁਤ ਸਾਰੀਆਂ ਚੀਜ਼ਾਂ ਗਲਤ ਹੋ ਸਕਦੀਆਂ ਹਨ ਭਾਵੇਂ ਕੋਈ ਸਾਫਟਵੇਅਰ ਜੀਵਨ ਚੱਕਰ ਦਾ ਸੰਪੂਰਨ ਨਿਯੰਤਰਣ ਮੰਨ ਲਵੇ। ਸਾਡੇ ਡਿਵੈਲਪਰ ਨੂੰ ਨਹੀਂ ਪਤਾ ਸੀ ਕਿ ਇੱਕ APT ਸਮੂਹ Acme ਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾ ਰਿਹਾ ਸੀ ਅਤੇ ਉਸ ਨਾਮ ਹੇਠ ਇੱਕ ਖਤਰਨਾਕ ਭਾਗ ਪ੍ਰਕਾਸ਼ਤ ਕੀਤਾ ਸੀ, ਇੱਕ ਚਲਾਕੀ ਨਾਲ, ਇਸ ਲਈ ਖਤਰਨਾਕ ਵਿਵਹਾਰ ਸਿਰਫ਼ ਉਦੋਂ ਹੀ ਕਿਰਿਆਸ਼ੀਲ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਸਾਫਟਵੇਅਰ Acme ਕੰਪਿਊਟਰਾਂ 'ਤੇ ਸਥਾਪਤ ਹੁੰਦਾ ਹੈ। ਪ੍ਰਕਾਸ਼ਨ ਤੋਂ ਬਾਅਦ ਹਫ਼ਤਿਆਂ ਤੱਕ ਪੈਕੇਜ ਦਾ ਪਤਾ ਨਹੀਂ ਲੱਗਿਆ।
ਇੱਕ ਇੰਸਟਾਲੇਸ਼ਨ ਸਕ੍ਰਿਪਟ ਚਲਾਈ ਜਾਂਦੀ ਹੈ ਜੋ ਪ੍ਰਮਾਣ ਪੱਤਰਾਂ ਦੀ ਖੋਜ ਕਰਦੀ ਹੈ (ਸਾਡੇ ਡਿਵੈਲਪਰ ਦੇ ਲੈਪਟਾਪ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਮਜ਼ੇਦਾਰ ਪਹੁੰਚ ਟੋਕਨ ਸਨ), ਅੰਦਰੂਨੀ ਸੌਫਟਵੇਅਰ ਰਿਪੋਜ਼ਟਰੀਆਂ ਤੱਕ ਪਹੁੰਚ ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ, ਅਤੇ ਉਪਰੋਕਤ ਅੰਦਰੂਨੀ ਰਿਪੋਜ਼ਟਰੀ, ਜੋ ਕਿ ਬੇਸ਼ੱਕ ਸਿਰਫ VPN ਦੁਆਰਾ ਪਹੁੰਚਯੋਗ ਹੈ। ਖਤਰਨਾਕ ਕੋਡ ਮੌਜੂਦਾ VPN ਕਨੈਕਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰਨ ਅਤੇ ਅੰਦਰੂਨੀ ਰਜਿਸਟਰੀ ਵਿੱਚ ਦੂਜੇ-ਪੜਾਅ ਦੇ ਖਤਰਨਾਕ ਹਿੱਸੇ ਨੂੰ ਪ੍ਰਕਾਸ਼ਤ ਕਰਨ ਵਿੱਚ ਕਾਮਯਾਬ ਰਿਹਾ, ਜਿਸ ਨਾਲ Acme ਦੁਆਰਾ ਡਿਲੀਵਰ ਕੀਤੇ ਗਏ ਜ਼ਿਆਦਾਤਰ ਸੌਫਟਵੇਅਰ ਦੁਆਰਾ ਸਾਂਝੀ ਕੀਤੀ ਗਈ ਇੱਕ ਆਮ ਉਪਯੋਗਤਾ ਲਾਇਬ੍ਰੇਰੀ ਪ੍ਰਭਾਵਿਤ ਹੋਈ।
ਹਫ਼ਤਿਆਂ ਬਾਅਦ, Acme ਦੇ ਪ੍ਰਕਾਸ਼ਿਤ ਟੂਲਸ ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਾਲੀਆਂ ਹੋਰ ਸੰਸਥਾਵਾਂ ਨੇ ਆਪਣੇ ਨੈੱਟਵਰਕਾਂ 'ਤੇ ਅਜੀਬ ਟ੍ਰੈਫਿਕ ਦੇਖਣਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ, ਜਿਸ ਵਿੱਚ Acme ਦੇ ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਟ੍ਰੈਫਿਕ ਸੀ ਪਰ Acme ਡੋਮੇਨ ਵਰਗੇ ਹੋਸਟਾਂ ਵੱਲ ਨਿਰਦੇਸ਼ਿਤ ਕੀਤਾ ਗਿਆ ਸੀ। ਟ੍ਰੈਫਿਕ ਨੂੰ ਏਨਕ੍ਰਿਪਟ ਕੀਤਾ ਗਿਆ ਸੀ ਪਰ ਸਿਸਟਮ ਨਿਗਰਾਨੀ ਟੂਲਸ ਨੇ ਅਚਾਨਕ ਫਾਈਲਾਂ ਤੱਕ ਪਹੁੰਚ ਪ੍ਰਾਪਤ ਕੀਤੀ ਅਤੇ ਉਹਨਾਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਲਾਗੂ ਕੀਤਾ ਜੋ ਸਿਸਟਮ ਕਮਾਂਡਾਂ ਵਰਗੀਆਂ ਦਿਖਾਈ ਦਿੰਦੀਆਂ ਹਨ ਪਰ ਜੋ ਡਾਊਨਲੋਡ ਕੀਤੇ ਐਗਜ਼ੀਕਿਊਟੇਬਲ ਨੂੰ ਚਲਾਉਂਦੀਆਂ ਹਨ।
ਬਾਕੀ ਇਤਿਹਾਸ ਹੈ: Acme ਨੇ ਪਹਿਲਾਂ ਇਸ ਗੱਲ ਤੋਂ ਇਨਕਾਰ ਕੀਤਾ ਕਿ ਅਜਿਹਾ ਵਿਵਹਾਰ ਉਨ੍ਹਾਂ ਲਈ ਦੋਸ਼ੀ ਸੀ ਅਤੇ ਸਾਰੇ ਸੁਰੱਖਿਆ ਉਪਾਅ ਲਾਗੂ ਸਨ। ਸਾਈਬਰਸੈਕ ਮੀਡੀਆ ਵੱਲੋਂ ਇਹ ਪੁੱਛਣ ਤੋਂ ਬਾਅਦ ਕਿ ਖੋਜੇ ਗਏ ਵਿਵਹਾਰ ਦਾ ਸਰੋਤ Acme ਦੇ ਹਿੱਸਿਆਂ ਤੋਂ ਕਿਉਂ ਆਇਆ, ਅਤੇ ਸੁਰੱਖਿਆ ਵਿਸ਼ਲੇਸ਼ਣ ਨੇ ਇਹ ਪੋਸਟ ਕੀਤਾ ਕਿ ਉਹ ਹਿੱਸੇ ਚੋਰੀ-ਛਿਪੇ ਮਾਲਵੇਅਰ ਨਾਲ ਕਿੰਨੇ ਉਲਝੇ ਹੋਏ ਸਨ, Acme ਨੂੰ ਘਟਨਾ ਦੀ ਪਛਾਣ ਕਰਨੀ ਪਈ ਅਤੇ ਇੱਕ ਘਟਨਾ ਪ੍ਰਤੀਕਿਰਿਆ ਫਰਮ ਨੂੰ ਬੁਲਾਇਆ। ਇੱਕ ਨਕਾਰਾਤਮਕ ਮਾਰਕੀਟਿੰਗ ਮੁਹਿੰਮ ਜਿਸਨੇ ਇੱਕ ਸਕਿੰਟ ਵਿੱਚ ਮਿਹਨਤ ਨਾਲ ਕਮਾਏ ਵਿਸ਼ਵਾਸ ਨੂੰ ਕਮਜ਼ੋਰ ਕਰ ਦਿੱਤਾ।Acme di ਤੋਂ ਇੱਕ npm ਇੰਸਟਾਲ ਦੂਰ ਸੀsaster"ਇਹ ਇੱਕ ਆਮ ਸੁਰਖੀ ਸੀ। ਫਿਰ ਮੁਕੱਦਮੇ ਅਤੇ ਰੱਦ ਕੀਤੇ ਗਏ ਇਕਰਾਰਨਾਮੇ ਵੀ ਸਾਹਮਣੇ ਆਏ।
ਕੀ ਤੁਸੀਂ ਪਿਛਲੀਆਂ ਜਾਣੀਆਂ-ਪਛਾਣੀਆਂ ਘਟਨਾਵਾਂ ਨਾਲ ਸਮਾਨਤਾਵਾਂ ਦੇਖਦੇ ਹੋ? Acme ਦੋ ਪੜਾਵਾਂ ਵਿੱਚ ਸਪਲਾਈ ਚੇਨ ਘਟਨਾ ਦਾ ਸ਼ਿਕਾਰ ਹੋਇਆ, ਜਿਸ ਵਿੱਚ ਮਿਸ਼ਰਣ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਗਈ ਨਿਰਭਰਤਾ ਉਲਝਣ/ਟਾਈਪੋਸਕੁਏਟਿੰਗ ਹਮਲੇ ਜਿਨ੍ਹਾਂ ਨੇ ਇੱਕ ਡਿਵੈਲਪਰ ਵਰਕਸਟੇਸ਼ਨ ਨੂੰ ਉਹਨਾਂ ਹਿੱਸਿਆਂ ਨੂੰ ਸੰਕਰਮਿਤ ਕਰਨ ਲਈ ਇੱਕ ਬੀਚਹੈੱਡ ਵਜੋਂ ਵਰਤਿਆ ਜੋ ਤੀਜੀ ਧਿਰ ਦੁਆਰਾ ਵਰਤੇ ਜਾਂਦੇ ਸਾਫਟਵੇਅਰ ਵਿੱਚ ਖਤਮ ਹੁੰਦੇ ਸਨ। ਇਸਨੂੰ ਕਿਵੇਂ ਰੋਕਿਆ ਜਾਂ ਘਟਾਇਆ ਜਾ ਸਕਦਾ ਹੈ?
ਜ਼ਹਿਰੀਲੇ ਪੈਕੇਜ ਇੰਨੇ ਮਸ਼ਹੂਰ ਕਿਉਂ ਹਨ?
ਇਹ ਕਾਲਪਨਿਕ ਘਟਨਾ ਦਰਸਾਉਂਦੀ ਹੈ ਕਿ ਓਪਨ-ਸੋਰਸ ਸੁਰੱਖਿਆ ਲਈ ਇੱਕ ਵਾਜਬ ਪਹੁੰਚ ਦੇ ਬਾਵਜੂਦ, ਸੰਗਠਨਾਂ ਨੂੰ ਓਪਨ-ਸੋਰਸ ਹਿੱਸਿਆਂ ਵਿੱਚ ਮਾਲਵੇਅਰ ਦਾ ਸ਼ਿਕਾਰ ਹੋਣ ਤੋਂ ਬਚਣ ਲਈ ਖਾਸ ਉਪਾਵਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਯੋਜਨਾਬੱਧ ਤੌਰ 'ਤੇ, ਧਮਕੀ ਦੇਣ ਵਾਲਾ ਇਹ ਕਰ ਸਕਦਾ ਹੈ:
- ਇੱਕ ਨਵਾਂ ਪੈਕੇਜ ਬਣਾਓ (ਜਾਣੇ-ਪਛਾਣੇ ਟਾਈਪੋਸਕੈਟਿੰਗ ਜਾਂ ਨਿਰਭਰਤਾ ਉਲਝਣ ਦੇ ਤਰੀਕਿਆਂ ਦੀ ਪਾਲਣਾ ਕਰਦੇ ਹੋਏ, ਇਹ ਮਾੜੇ ਲੋਕਾਂ ਦੁਆਰਾ ਵਾਲੀਅਮ ਵਿੱਚ ਸਭ ਤੋਂ ਵੱਧ ਲੰਘਿਆ ਰਸਤਾ ਹੈ);
- ਕਿਸੇ ਮੌਜੂਦਾ ਨੂੰ ਸੰਕਰਮਿਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ, ਜਾਂ ਤਾਂ ਇਸਨੂੰ ਸਰੋਤ ਕੋਡ ਵਿੱਚ ਇੰਜੈਕਟ ਕਰਕੇ, ਇਸਨੂੰ ਇੱਕ ਯੋਗਦਾਨੀ ਦੇ ਰੂਪ ਵਿੱਚ ਭੇਸ ਬਦਲਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਕੇ pull request, ਜਾਂ ਸੋਸ਼ਲ ਇੰਜੀਨੀਅਰਿੰਗ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਰੱਖ-ਰਖਾਅ ਕਰਨ ਵਾਲਾ ਬਣੋ (ਜਿਵੇਂ ਕਿ "ਜਾਓ ਟੈਨ" ਨੇ XZ ਬੈਕਡੋਰ ਵਿੱਚ ਕੀਤਾ ਸੀ ਜਾਂ ਸੱਜਾ9ctrl GitHub ਉਪਭੋਗਤਾ ਨੇ ਇਸ ਵਿੱਚ ਕੀਤਾ ਇਵੈਂਟ-ਸਟ੍ਰੀਮ 2018 ਦੇ ਪਤਝੜ ਵਿੱਚ ਵਾਪਰੀ ਘਟਨਾ), ਜਾਂ ਓਪਨ ਸੋਰਸ ਰਿਪੋਜ਼ਟਰੀ ਪ੍ਰਮਾਣ ਪੱਤਰ ਪ੍ਰਾਪਤ ਕਰਕੇ ਅਤੇ ਰੱਖ-ਰਖਾਅ ਕਰਨ ਵਾਲੇ ਦੀ ਨਕਲ ਕਰਕੇ;
- ਪੈਕੇਜ ਦੇ ਨਿਰਮਾਣ ਦੌਰਾਨ ਮਾਲਵੇਅਰ ਇੰਜੈਕਟ ਕਰੋ, ਜਾਂ ਤਾਂ ਇੱਕ ਖਤਰਨਾਕ ਬਿਲਡ ਸਕ੍ਰਿਪਟ ਚਲਾ ਕੇ, ਜਾਂ ਮੈਨ-ਇਨ-ਦ-ਮਿਡਲ ਇੰਟਰਸੈਪਟਾਂ ਨਾਲ ਪੈਕੇਜ ਡਾਊਨਲੋਡ ਵਿੱਚ ਦਖਲਅੰਦਾਜ਼ੀ ਕਰਨਾ (ਖੁਸ਼ਕਿਸਮਤੀ ਨਾਲ, TLS ਹੁਣ ਜ਼ਿਆਦਾਤਰ ਰਜਿਸਟਰੀਆਂ ਵਿੱਚ ਹਮੇਸ਼ਾ ਲੋੜੀਂਦਾ ਹੈ)।
- ਪੈਕ ਕੀਤੇ ਹਿੱਸੇ ਨੂੰ ਸਿੱਧਾ ਰਜਿਸਟਰੀ ਵਿੱਚ ਇੰਜੈਕਟ ਕਰੋ, ਆਮ ਤੌਰ 'ਤੇ ਰਜਿਸਟਰੀ ਪ੍ਰਮਾਣ ਪੱਤਰਾਂ ਨੂੰ ਕੈਪਚਰ ਕਰਕੇ (Acme's ਵਰਗੇ ਬਹੁਤ ਸਾਰੇ ਸੂਝਵਾਨ ਹਮਲਿਆਂ ਲਈ ਪਸੰਦੀਦਾ ਵਿਕਲਪ, ਜਿੱਥੇ ਪਹਿਲੇ ਪੜਾਅ ਵਿੱਚ ਸਮਝੌਤਾ ਕੀਤੇ ਵਰਕਸਟੇਸ਼ਨ ਵਿੱਚ ਅੰਦਰੂਨੀ ਰਜਿਸਟਰੀ ਪਹੁੰਚ ਟੋਕਨ ਸੀ, ਉਦਾਹਰਨ ਲਈ ਆਮ ਤੌਰ 'ਤੇ .env or ~/.m2/settings.xml: ਬੁਰੇ ਕਾਰਕੁਨ ਜਾਣਦੇ ਹਨ ਕਿ ਰਾਜ਼ ਕਿੱਥੇ ਲੱਭਣੇ ਹਨ)। ਰਜਿਸਟਰੀਆਂ ਵਿੱਚ ਕਮਜ਼ੋਰੀਆਂ ਦਾ ਵੀ ਸ਼ੋਸ਼ਣ ਕੀਤਾ ਗਿਆ।
ਮਾਲਵੇਅਰ ਨਾਲ ਰਜਿਸਟਰੀਆਂ ਨੂੰ ਜ਼ਹਿਰ ਦੇਣਾ ਨਿਰਭਰਤਾ ਹਮਲਿਆਂ ਦਾ ਆਧਾਰ ਹੈ। ਸੂਰਜ ਦੇ ਹੇਠਾਂ ਕੁਝ ਨਵਾਂ ਨਹੀਂ: ਇਸਦਾ ਪ੍ਰਚਲਨ ਫੈਲ ਗਿਆ, ਪਰ ਉਹੀ ਤਕਨੀਕਾਂ ਹੁਣ ਵੀ ਕੰਮ ਕਰਦੀਆਂ ਹਨ ਜੋ ਪੰਜ ਸਾਲ ਪਹਿਲਾਂ ਸਨ।
ਸਰੋਤ: ਬੈਕਸਟੈਬਰ ਦਾ ਚਾਕੂ ਸੰਗ੍ਰਹਿ.
ਖਤਰਨਾਕ ਪੈਕੇਜ ਇੰਸਟਾਲੇਸ਼ਨ ਦੌਰਾਨ, ਸਾਫਟਵੇਅਰ ਬਿਲਡ ਦੌਰਾਨ, ਜਾਂ ਰਨਟਾਈਮ 'ਤੇ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ। ਅਤੇ ਵਿਵਹਾਰ ਜਾਣਕਾਰੀ ਐਕਸਫਿਲਟਰੇਸ਼ਨ ਤੋਂ ਲੈ ਕੇ ਦੂਜੇ ਪੜਾਅ ਦੀ ਕੋਸ਼ਿਸ਼ ਲਈ ਰਾਜ਼ ਕੱਢਣ, ਸਰੋਤ ਕੋਡ ਐਕਸਟਰੈਕਸ਼ਨ, ਵਾਧੂ ਮਾਲਵੇਅਰ ਛੱਡਣ ਤੱਕ ਹੁੰਦਾ ਹੈ। ਅਗਲੇ ਐਪੀਸੋਡ ਵਿੱਚ, ਅਸੀਂ ਖਤਰਨਾਕ ਪੈਕੇਜਾਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਾਂਗੇ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਕਾਸ਼ਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
ਹੋਰ ਪੜ੍ਹਨ
ਅਗਲਾ ਐਪੀਸੋਡ ਖਤਰਨਾਕ ਪੈਕੇਜਾਂ ਦਾ ਸਰੀਰ ਵਿਗਿਆਨ: ਰੁਝਾਨ ਕੀ ਹਨ? ਸਾਡੇ ਮਾਲਵੇਅਰ ਅਰਲੀ ਚੇਤਾਵਨੀ ਸਿਸਟਮ ਨਾਲ ਅਸੀਂ ਦਿਨ-ਬ-ਦਿਨ ਅਸਲ ਮਾਮਲਿਆਂ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰਾਂਗੇ ਜਿਨ੍ਹਾਂ ਦੀ ਅਸੀਂ ਨਿਗਰਾਨੀ ਕਰ ਰਹੇ ਹਾਂ। ਅਸੀਂ ਸਮੀਖਿਆ ਕਰਾਂਗੇ ਕਿ ਕਿਸ ਕਿਸਮ ਦੇ ਮਾਲਵੇਅਰ ਦੇਖੇ ਗਏ ਸਨ, ਅਤੇ ਕਿਹੜੀਆਂ ਰਣਨੀਤੀਆਂ, ਤਕਨੀਕਾਂ ਅਤੇ ਪ੍ਰਕਿਰਿਆਵਾਂ ਮਨਪਸੰਦ ਹਨ। ਅਸੀਂ ਗੁੰਝਲਦਾਰਤਾ ਦੀ ਜਾਂਚ ਕਰਾਂਗੇ ਅਤੇ ਉਹ ਸੰਭਾਵੀ ਸਮੀਖਿਅਕਾਂ ਤੋਂ ਕਿਵੇਂ ਲੁਕਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ, ਖੋਜ ਤੋਂ ਬਚਣ ਲਈ ਚੋਰੀ ਦੀਆਂ ਤਕਨੀਕਾਂ, ਅਤੇ ਉਹ ਟੈਲੀਮੈਟਰੀ ਅਤੇ ਲੇਟਰਲ ਮੂਵਮੈਂਟ ਨਾਲ ਕਿਵੇਂ ਵਿਕਸਤ ਹੋ ਰਹੇ ਹਨ। ਕਿਰਪਾ ਕਰਕੇ ਜੁੜੇ ਰਹੋ!
ਹਵਾਲੇ
- ਬੈਕਸਟੈਬਰ ਦਾ ਚਾਕੂ ਸੰਗ੍ਰਹਿ: ਓਪਨ ਸੋਰਸ ਸਾਫਟਵੇਅਰ ਸਪਲਾਈ ਚੇਨ ਹਮਲਿਆਂ ਦੀ ਸਮੀਖਿਆ. ਐਮ. ਓਹਮ ਅਤੇ ਹੋਰ, ਮਈ 2020।
- ਓਪਨ ਸੋਰਸ ਮਾਲਵੇਅਰ ਸੁਰੱਖਿਆ. ਜ਼ਾਇਗੇਨੀ ਤੋਂ ਵਾਈਟਪੇਪਰ।
- Software Supply Chain Security ਪਿਛਾਖੜੀ: 2024 ਨੂੰ ਸੁਰੱਖਿਅਤ ਬਣਾਉਣਾ. ਜ਼ਾਇਗੇਨੀ ਤੋਂ ਰਿਪੋਰਟ।
