আপনার MikroTik-এ RouterOS আপডেট করুন

10 মার্চ সন্ধ্যায়, Mail.ru সমর্থন পরিষেবা ব্যবহারকারীদের কাছ থেকে ইমেল প্রোগ্রামগুলির মাধ্যমে Mail.ru IMAP/SMTP সার্ভারের সাথে সংযোগ করতে অক্ষমতা সম্পর্কে অভিযোগ পেতে শুরু করে৷ একই সময়ে, কিছু সংযোগের মাধ্যমে যাওয়া হয়নি, এবং কিছু একটি শংসাপত্র ত্রুটি দেখায়। "সার্ভার" একটি স্ব-স্বাক্ষরিত TLS শংসাপত্র ইস্যু করার কারণে ত্রুটিটি ঘটেছে৷
 

দুই দিনে, 10 টিরও বেশি অভিযোগ এসেছে ব্যবহারকারীদের কাছ থেকে বিস্তৃত নেটওয়ার্ক এবং বিভিন্ন ডিভাইসের সাথে, এটি অসম্ভাব্য করে যে সমস্যাটি কোনও একটি প্রদানকারীর নেটওয়ার্কে ছিল। সমস্যাটির আরও বিশদ বিশ্লেষণ থেকে জানা গেছে যে imap.mail.ru সার্ভার (পাশাপাশি অন্যান্য মেল সার্ভার এবং পরিষেবাগুলি) DNS স্তরে প্রতিস্থাপিত হচ্ছে। আরও, আমাদের ব্যবহারকারীদের সক্রিয় সাহায্যে, আমরা দেখতে পেয়েছি যে কারণটি তাদের রাউটারের ক্যাশে একটি ভুল এন্ট্রি ছিল, যা একটি স্থানীয় ডিএনএস সমাধানকারীও, এবং যা অনেক ক্ষেত্রে (কিন্তু সমস্ত নয়) MikroTik হিসাবে পরিণত হয়েছে। ডিভাইস, ছোট কর্পোরেট নেটওয়ার্ক এবং ছোট ইন্টারনেট প্রদানকারীর কাছ থেকে খুব জনপ্রিয়।

সমস্যা কি

2019 সালের সেপ্টেম্বরে, গবেষকরা পাওয়া MikroTik RouterOS (CVE-2019-3976, CVE-2019-3977, CVE-2019-3978, CVE-2019-3979) এর বিভিন্ন দুর্বলতা, যা একটি DNS ক্যাশে বিষক্রিয়া আক্রমণের অনুমতি দেয়, যেমন রাউটারের ডিএনএস ক্যাশে ডিএনএস রেকর্ডগুলি ফাঁকি দেওয়ার ক্ষমতা এবং CVE-2019-3978 আক্রমণকারীকে অভ্যন্তরীণ নেটওয়ার্ক থেকে কারও কাছে তার ডিএনএস সার্ভারে প্রবেশের অনুরোধ করার জন্য অপেক্ষা না করার অনুমতি দেয় যাতে সমাধানকারী ক্যাশে বিষাক্ত করা যায়, তবে এমনটি শুরু করার জন্য পোর্ট 8291 (UDP এবং TCP) এর মাধ্যমে নিজেই একটি অনুরোধ। 6.45.7 অক্টোবর, 6.44.6-এ রাউটারওএস 28 (স্থিতিশীল) এবং 2019 (দীর্ঘমেয়াদী) সংস্করণে MikroTik দ্বারা দুর্বলতা সংশোধন করা হয়েছিল, কিন্তু অনুযায়ী গবেষণা বেশিরভাগ ব্যবহারকারী বর্তমানে প্যাচ ইনস্টল করেননি।

এটা স্পষ্ট যে এই সমস্যাটি এখন সক্রিয়ভাবে "লাইভ" শোষণ করা হচ্ছে।

কেন এটা বিপজ্জনক?

একজন আক্রমণকারী অভ্যন্তরীণ নেটওয়ার্কে ব্যবহারকারীর দ্বারা অ্যাক্সেস করা যেকোনো হোস্টের 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 ক্যাশে প্যাসিভ ইনজেকশনের সম্ভাবনাকে দূর করবে না। কর্পোরেট ব্যবহারকারীদের সুরক্ষার জন্য আইএসপিগুলিকে তাদের নেটওয়ার্কগুলিতে এই পোর্টটি ফিল্টার করা উচিত। 

যে সমস্ত ব্যবহারকারীরা একটি প্রতিস্থাপিত শংসাপত্র গ্রহণ করেছেন তাদের জরুরিভাবে ইমেল এবং অন্যান্য পরিষেবাগুলির পাসওয়ার্ড পরিবর্তন করা উচিত যার জন্য এই শংসাপত্রটি গ্রহণ করা হয়েছিল৷ আমাদের পক্ষ থেকে, আমরা সেইসব ব্যবহারকারীদের জানিয়ে দেব যারা দুর্বল ডিভাইসের মাধ্যমে মেল অ্যাক্সেস করে।

PS পোস্টে বর্ণিত একটি সম্পর্কিত দুর্বলতাও রয়েছে লুকাসাফোনভ "রাউটারওএস-এ ব্যাকপোর্ট দুর্বলতা কয়েক হাজার ডিভাইসের হুমকি দেয়".

উত্স: www.habr.com