ਆਪਣੇ MikroTik 'ਤੇ RouterOS ਨੂੰ ਅੱਪਡੇਟ ਕਰੋ

10 ਮਾਰਚ ਦੀ ਸ਼ਾਮ ਨੂੰ, Mail.ru ਸਹਾਇਤਾ ਸੇਵਾ ਨੂੰ ਈਮੇਲ ਪ੍ਰੋਗਰਾਮਾਂ ਰਾਹੀਂ Mail.ru IMAP/SMTP ਸਰਵਰਾਂ ਨਾਲ ਜੁੜਨ ਦੀ ਅਯੋਗਤਾ ਬਾਰੇ ਉਪਭੋਗਤਾਵਾਂ ਤੋਂ ਸ਼ਿਕਾਇਤਾਂ ਮਿਲਣੀਆਂ ਸ਼ੁਰੂ ਹੋ ਗਈਆਂ। ਉਸੇ ਸਮੇਂ, ਕੁਝ ਕੁਨੈਕਸ਼ਨ ਨਹੀਂ ਲੰਘੇ, ਅਤੇ ਕੁਝ ਇੱਕ ਸਰਟੀਫਿਕੇਟ ਗਲਤੀ ਦਿਖਾਉਂਦੇ ਹਨ। ਗਲਤੀ "ਸਰਵਰ" ਦੁਆਰਾ ਸਵੈ-ਦਸਤਖਤ ਕੀਤੇ TLS ਸਰਟੀਫਿਕੇਟ ਜਾਰੀ ਕਰਨ ਕਾਰਨ ਹੋਈ ਹੈ।
 

ਦੋ ਦਿਨਾਂ ਵਿੱਚ, 10 ਤੋਂ ਵੱਧ ਸ਼ਿਕਾਇਤਾਂ ਉਪਭੋਗਤਾਵਾਂ ਦੁਆਰਾ ਵਿਭਿੰਨ ਕਿਸਮਾਂ ਦੇ ਨੈਟਵਰਕਾਂ ਅਤੇ ਵਿਭਿੰਨ ਡਿਵਾਈਸਾਂ ਦੇ ਨਾਲ ਆਈਆਂ, ਜਿਸ ਨਾਲ ਇਹ ਸੰਭਾਵਨਾ ਨਹੀਂ ਹੁੰਦੀ ਕਿ ਸਮੱਸਿਆ ਕਿਸੇ ਇੱਕ ਪ੍ਰਦਾਤਾ ਦੇ ਨੈਟਵਰਕ ਵਿੱਚ ਸੀ। ਸਮੱਸਿਆ ਦੇ ਵਧੇਰੇ ਵਿਸਤ੍ਰਿਤ ਵਿਸ਼ਲੇਸ਼ਣ ਤੋਂ ਪਤਾ ਲੱਗਾ ਹੈ ਕਿ imap.mail.ru ਸਰਵਰ (ਨਾਲ ਹੀ ਹੋਰ ਮੇਲ ਸਰਵਰ ਅਤੇ ਸੇਵਾਵਾਂ) ਨੂੰ DNS ਪੱਧਰ 'ਤੇ ਬਦਲਿਆ ਜਾ ਰਿਹਾ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਸਾਡੇ ਉਪਭੋਗਤਾਵਾਂ ਦੀ ਸਰਗਰਮ ਮਦਦ ਨਾਲ, ਅਸੀਂ ਪਾਇਆ ਕਿ ਕਾਰਨ ਉਹਨਾਂ ਦੇ ਰਾਊਟਰ ਦੇ ਕੈਸ਼ ਵਿੱਚ ਇੱਕ ਗਲਤ ਐਂਟਰੀ ਸੀ, ਜੋ ਕਿ ਇੱਕ ਸਥਾਨਕ DNS ਰੈਜ਼ੋਲਵਰ ਵੀ ਹੈ, ਅਤੇ ਜੋ ਕਿ ਬਹੁਤ ਸਾਰੇ (ਪਰ ਸਾਰੇ ਨਹੀਂ) ਮਾਮਲਿਆਂ ਵਿੱਚ MikroTik ਨਿਕਲਿਆ। ਡਿਵਾਈਸ, ਛੋਟੇ ਕਾਰਪੋਰੇਟ ਨੈਟਵਰਕਾਂ ਅਤੇ ਛੋਟੇ ਇੰਟਰਨੈਟ ਪ੍ਰਦਾਤਾਵਾਂ ਤੋਂ ਬਹੁਤ ਮਸ਼ਹੂਰ ਹੈ।

ਸਮੱਸਿਆ ਕੀ ਹੈ

ਸਤੰਬਰ 2019 ਵਿੱਚ, ਖੋਜਕਰਤਾਵਾਂ ਮਿਲਿਆ MikroTik RouterOS (CVE-2019-3976, CVE-2019-3977, CVE-2019-3978, CVE-2019-3979) ਵਿੱਚ ਕਈ ਕਮਜ਼ੋਰੀਆਂ, ਜੋ ਕਿ ਇੱਕ DNS ਕੈਚ ਜ਼ਹਿਰੀਲੇ ਹਮਲੇ ਦੀ ਆਗਿਆ ਦਿੰਦੀਆਂ ਹਨ, ਜਿਵੇਂ ਕਿ ਰਾਊਟਰ ਦੇ DNS ਕੈਸ਼ ਵਿੱਚ DNS ਰਿਕਾਰਡਾਂ ਨੂੰ ਧੋਖਾ ਦੇਣ ਦੀ ਸਮਰੱਥਾ, ਅਤੇ CVE-2019-3978 ਹਮਲਾਵਰ ਨੂੰ ਅੰਦਰੂਨੀ ਨੈੱਟਵਰਕ ਤੋਂ ਕਿਸੇ ਵਿਅਕਤੀ ਨੂੰ ਰਿਜ਼ੋਲਵਰ ਕੈਸ਼ ਨੂੰ ਜ਼ਹਿਰ ਦੇਣ ਲਈ ਆਪਣੇ DNS ਸਰਵਰ 'ਤੇ ਐਂਟਰੀ ਦੀ ਬੇਨਤੀ ਕਰਨ ਦੀ ਉਡੀਕ ਨਾ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ, ਪਰ ਅਜਿਹਾ ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਪੋਰਟ 8291 (UDP ਅਤੇ TCP) ਰਾਹੀਂ ਖੁਦ ਇੱਕ ਬੇਨਤੀ। MikroTik ਦੁਆਰਾ 6.45.7 ਅਕਤੂਬਰ, 6.44.6 ਨੂੰ RouterOS 28 (ਸਥਿਰ) ਅਤੇ 2019 (ਲੰਮੀ ਮਿਆਦ) ਦੇ ਸੰਸਕਰਣਾਂ ਵਿੱਚ ਕਮਜ਼ੋਰੀ ਨੂੰ ਫਿਕਸ ਕੀਤਾ ਗਿਆ ਸੀ, ਪਰ ਇਸਦੇ ਅਨੁਸਾਰ ਖੋਜ ਜ਼ਿਆਦਾਤਰ ਉਪਭੋਗਤਾਵਾਂ ਨੇ ਇਸ ਸਮੇਂ ਪੈਚ ਸਥਾਪਤ ਨਹੀਂ ਕੀਤੇ ਹਨ।

ਇਹ ਸਪੱਸ਼ਟ ਹੈ ਕਿ ਇਸ ਸਮੱਸਿਆ ਦਾ ਹੁਣ ਸਰਗਰਮੀ ਨਾਲ "ਲਾਈਵ" ਸ਼ੋਸ਼ਣ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ।

ਇਹ ਖ਼ਤਰਨਾਕ ਕਿਉਂ ਹੈ

ਇੱਕ ਹਮਲਾਵਰ ਅੰਦਰੂਨੀ ਨੈੱਟਵਰਕ 'ਤੇ ਕਿਸੇ ਉਪਭੋਗਤਾ ਦੁਆਰਾ ਐਕਸੈਸ ਕੀਤੇ ਗਏ ਕਿਸੇ ਵੀ ਹੋਸਟ ਦੇ DNS ਰਿਕਾਰਡ ਨੂੰ ਧੋਖਾ ਦੇ ਸਕਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਇਸ 'ਤੇ ਆਵਾਜਾਈ ਨੂੰ ਰੋਕਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਜੇ ਸੰਵੇਦਨਸ਼ੀਲ ਜਾਣਕਾਰੀ ਨੂੰ ਐਨਕ੍ਰਿਪਸ਼ਨ ਤੋਂ ਬਿਨਾਂ ਪ੍ਰਸਾਰਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ (ਉਦਾਹਰਨ ਲਈ, TLS ਤੋਂ ਬਿਨਾਂ http:// ਉੱਤੇ) ਜਾਂ ਉਪਭੋਗਤਾ ਇੱਕ ਜਾਅਲੀ ਸਰਟੀਫਿਕੇਟ ਸਵੀਕਾਰ ਕਰਨ ਲਈ ਸਹਿਮਤ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਹਮਲਾਵਰ ਉਹ ਸਾਰਾ ਡਾਟਾ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਕਨੈਕਸ਼ਨ ਰਾਹੀਂ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ ਲੌਗਇਨ ਜਾਂ ਪਾਸਵਰਡ। ਬਦਕਿਸਮਤੀ ਨਾਲ, ਅਭਿਆਸ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਜੇਕਰ ਕਿਸੇ ਉਪਭੋਗਤਾ ਕੋਲ ਜਾਅਲੀ ਸਰਟੀਫਿਕੇਟ ਸਵੀਕਾਰ ਕਰਨ ਦਾ ਮੌਕਾ ਹੈ, ਤਾਂ ਉਹ ਇਸਦਾ ਫਾਇਦਾ ਉਠਾਏਗਾ।

SMTP ਅਤੇ IMAP ਸਰਵਰ ਕਿਉਂ, ਅਤੇ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਕੀ ਬਚਾਇਆ ਗਿਆ

ਹਮਲਾਵਰਾਂ ਨੇ ਈਮੇਲ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੇ SMTP/IMAP ਟ੍ਰੈਫਿਕ ਨੂੰ ਰੋਕਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਿਉਂ ਕੀਤੀ, ਨਾ ਕਿ ਵੈਬ ਟ੍ਰੈਫਿਕ, ਹਾਲਾਂਕਿ ਜ਼ਿਆਦਾਤਰ ਉਪਭੋਗਤਾ HTTPS ਬ੍ਰਾਊਜ਼ਰ ਦੁਆਰਾ ਆਪਣੇ ਮੇਲ ਤੱਕ ਪਹੁੰਚ ਕਰਦੇ ਹਨ?

SMTP ਅਤੇ IMAP/POP3 ਦੁਆਰਾ ਕੰਮ ਕਰਨ ਵਾਲੇ ਸਾਰੇ ਈਮੇਲ ਪ੍ਰੋਗਰਾਮ ਉਪਭੋਗਤਾ ਨੂੰ ਗਲਤੀਆਂ ਤੋਂ ਬਚਾਉਂਦੇ ਹਨ, ਉਸਨੂੰ ਇੱਕ ਅਸੁਰੱਖਿਅਤ ਜਾਂ ਸਮਝੌਤਾ ਕੀਤੇ ਕਨੈਕਸ਼ਨ ਦੁਆਰਾ ਲੌਗਇਨ ਅਤੇ ਪਾਸਵਰਡ ਭੇਜਣ ਤੋਂ ਰੋਕਦੇ ਹਨ, ਹਾਲਾਂਕਿ ਮਿਆਰ ਦੇ ਅਨੁਸਾਰ RFC 8314, 2018 ਵਿੱਚ ਵਾਪਸ ਅਪਣਾਇਆ ਗਿਆ ਸੀ (ਅਤੇ Mail.ru ਵਿੱਚ ਬਹੁਤ ਪਹਿਲਾਂ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਸੀ), ਉਹਨਾਂ ਨੂੰ ਕਿਸੇ ਵੀ ਅਸੁਰੱਖਿਅਤ ਕਨੈਕਸ਼ਨ ਦੁਆਰਾ ਉਪਭੋਗਤਾ ਨੂੰ ਪਾਸਵਰਡ ਰੁਕਾਵਟ ਤੋਂ ਬਚਾਉਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, OAuth ਪ੍ਰੋਟੋਕੋਲ ਈਮੇਲ ਕਲਾਇੰਟਸ ਵਿੱਚ ਬਹੁਤ ਘੱਟ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ (ਇਹ Mail.ru ਮੇਲ ਸਰਵਰਾਂ ਦੁਆਰਾ ਸਮਰਥਿਤ ਹੈ), ਅਤੇ ਇਸਦੇ ਬਿਨਾਂ, ਹਰੇਕ ਸੈਸ਼ਨ ਵਿੱਚ ਲੌਗਇਨ ਅਤੇ ਪਾਸਵਰਡ ਪ੍ਰਸਾਰਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਬ੍ਰਾਊਜ਼ਰ ਮੈਨ-ਇਨ-ਦ-ਮਿਡਲ ਹਮਲਿਆਂ ਤੋਂ ਥੋੜ੍ਹਾ ਬਿਹਤਰ ਸੁਰੱਖਿਅਤ ਹੋ ਸਕਦੇ ਹਨ। ਸਾਰੇ mail.ru ਨਾਜ਼ੁਕ ਡੋਮੇਨਾਂ 'ਤੇ, HTTPS ਤੋਂ ਇਲਾਵਾ, HSTS (HTTP ਸਖਤ ਆਵਾਜਾਈ ਸੁਰੱਖਿਆ) ਨੀਤੀ ਸਮਰਥਿਤ ਹੈ। HSTS ਸਮਰਥਿਤ ਹੋਣ ਦੇ ਨਾਲ, ਇੱਕ ਆਧੁਨਿਕ ਬ੍ਰਾਊਜ਼ਰ ਉਪਭੋਗਤਾ ਨੂੰ ਜਾਅਲੀ ਸਰਟੀਫਿਕੇਟ ਸਵੀਕਾਰ ਕਰਨ ਦਾ ਆਸਾਨ ਵਿਕਲਪ ਨਹੀਂ ਦਿੰਦਾ ਹੈ, ਭਾਵੇਂ ਉਪਭੋਗਤਾ ਚਾਹੁੰਦਾ ਹੋਵੇ। HSTS ਤੋਂ ਇਲਾਵਾ, ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਇਸ ਤੱਥ ਦੁਆਰਾ ਬਚਾਇਆ ਗਿਆ ਸੀ ਕਿ 2017 ਤੋਂ, Mail.ru ਦੇ SMTP, IMAP ਅਤੇ POP3 ਸਰਵਰ ਇੱਕ ਅਸੁਰੱਖਿਅਤ ਕਨੈਕਸ਼ਨ 'ਤੇ ਪਾਸਵਰਡ ਟ੍ਰਾਂਸਫਰ ਕਰਨ ਦੀ ਮਨਾਹੀ ਕਰਦੇ ਹਨ, ਸਾਡੇ ਸਾਰੇ ਉਪਭੋਗਤਾਵਾਂ ਨੇ SMTP, POP3 ਅਤੇ IMAP ਦੁਆਰਾ ਪਹੁੰਚ ਲਈ TLS ਦੀ ਵਰਤੋਂ ਕੀਤੀ, ਅਤੇ ਇਸ ਲਈ ਲੌਗਇਨ ਅਤੇ ਪਾਸਵਰਡ ਸਿਰਫ ਤਾਂ ਹੀ ਰੋਕ ਸਕਦੇ ਹਨ ਜੇਕਰ ਉਪਭੋਗਤਾ ਖੁਦ ਧੋਖੇ ਨਾਲ ਕੀਤੇ ਸਰਟੀਫਿਕੇਟ ਨੂੰ ਸਵੀਕਾਰ ਕਰਨ ਲਈ ਸਹਿਮਤ ਹੁੰਦਾ ਹੈ।

ਮੋਬਾਈਲ ਉਪਭੋਗਤਾਵਾਂ ਲਈ, ਅਸੀਂ ਹਮੇਸ਼ਾ ਮੇਲ ਤੱਕ ਪਹੁੰਚ ਕਰਨ ਲਈ Mail.ru ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਸਿਫਾਰਸ਼ ਕਰਦੇ ਹਾਂ, ਕਿਉਂਕਿ... ਉਹਨਾਂ ਵਿੱਚ ਮੇਲ ਨਾਲ ਕੰਮ ਕਰਨਾ ਬ੍ਰਾਊਜ਼ਰਾਂ ਜਾਂ ਬਿਲਟ-ਇਨ SMTP/IMAP ਕਲਾਇੰਟਸ ਨਾਲੋਂ ਵਧੇਰੇ ਸੁਰੱਖਿਅਤ ਹੈ।

ਕੀ ਕਰਨਾ ਹੈ

MikroTik RouterOS ਫਰਮਵੇਅਰ ਨੂੰ ਇੱਕ ਸੁਰੱਖਿਅਤ ਸੰਸਕਰਣ ਵਿੱਚ ਅਪਡੇਟ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ। ਜੇ ਕਿਸੇ ਕਾਰਨ ਕਰਕੇ ਇਹ ਸੰਭਵ ਨਹੀਂ ਹੈ, ਤਾਂ ਪੋਰਟ 8291 (tcp ਅਤੇ udp) 'ਤੇ ਟ੍ਰੈਫਿਕ ਨੂੰ ਫਿਲਟਰ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ, ਇਹ ਸਮੱਸਿਆ ਦੇ ਸ਼ੋਸ਼ਣ ਨੂੰ ਗੁੰਝਲਦਾਰ ਬਣਾ ਦੇਵੇਗਾ, ਹਾਲਾਂਕਿ ਇਹ DNS ਕੈਸ਼ ਵਿੱਚ ਪੈਸਿਵ ਇੰਜੈਕਸ਼ਨ ਦੀ ਸੰਭਾਵਨਾ ਨੂੰ ਖਤਮ ਨਹੀਂ ਕਰੇਗਾ। ISPs ਨੂੰ ਕਾਰਪੋਰੇਟ ਉਪਭੋਗਤਾਵਾਂ ਦੀ ਸੁਰੱਖਿਆ ਲਈ ਆਪਣੇ ਨੈੱਟਵਰਕਾਂ 'ਤੇ ਇਸ ਪੋਰਟ ਨੂੰ ਫਿਲਟਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। 

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

PS ਪੋਸਟ ਵਿੱਚ ਵਰਣਿਤ ਇੱਕ ਸੰਬੰਧਿਤ ਕਮਜ਼ੋਰੀ ਵੀ ਹੈ ਲੂਕਾਸਾਫੋਨੋਵ "RouterOS ਵਿੱਚ ਬੈਕਪੋਰਟ ਕਮਜ਼ੋਰੀ ਸੈਂਕੜੇ ਹਜ਼ਾਰਾਂ ਡਿਵਾਈਸਾਂ ਨੂੰ ਖਤਰੇ ਵਿੱਚ ਪਾਉਂਦੀ ਹੈ".

ਸਰੋਤ: www.habr.com