IWD এবং wpa_supplicant-এ Wi-Fi প্রমাণীকরণ বাইপাস করার সমস্যা

ওপেন প্যাকেজ IWD (Intel inet Wireless Daemon) এবং wpa_supplicant-এ দুর্বলতা চিহ্নিত করা হয়েছে, যা একটি ওয়্যারলেস নেটওয়ার্কের সাথে ক্লায়েন্ট লিনাক্স সিস্টেমের সংযোগ সংগঠিত করতে ব্যবহৃত হয়, যা প্রমাণীকরণ প্রক্রিয়াকে বাইপাস করে:

• IWD-তে, দুর্বলতা (CVE-2023-52161) শুধুমাত্র তখনই দেখা যায় যখন অ্যাক্সেস পয়েন্ট মোড সক্রিয় থাকে, যা IWD-এর জন্য সাধারণ নয়, যা সাধারণত ওয়্যারলেস নেটওয়ার্কের সাথে সংযোগ করতে ব্যবহৃত হয়। দুর্বলতা আপনাকে পাসওয়ার্ড না জেনে একটি তৈরি অ্যাক্সেস পয়েন্টের সাথে সংযোগ করতে দেয়, উদাহরণস্বরূপ, যখন ব্যবহারকারী স্পষ্টভাবে তাদের ডিভাইস (হটস্পট) এর মাধ্যমে নেটওয়ার্ক অ্যাক্সেস করার ক্ষমতা প্রদান করে। সমস্যাটি IWD সংস্করণ 2.14 এ স্থির করা হয়েছে৷

  নিরাপদ ওয়্যারলেস নেটওয়ার্কের সাথে প্রথম সংযোগ করার সময় ব্যবহৃত 4-পদক্ষেপ যোগাযোগ চ্যানেল আলোচনার সময় সমস্ত পদক্ষেপের ক্রম সঠিকভাবে পরীক্ষা করতে ব্যর্থতার কারণে দুর্বলতা সৃষ্টি হয়। পূর্ববর্তী পর্যায়টি সম্পন্ন হয়েছে কিনা তা পরীক্ষা না করেই যে IWD সংযোগ আলোচনার যেকোনো পর্যায়ের জন্য বার্তা গ্রহণ করে, একজন আক্রমণকারী দ্বিতীয় পর্যায়ের বার্তা পাঠানোকে বাইপাস করতে পারে এবং অবিলম্বে চতুর্থ পর্যায়ের একটি বার্তা পাঠাতে পারে এবং নেটওয়ার্কে অ্যাক্সেস পেতে পারে। , যে পর্যায়ে প্রমাণীকরণ চেক করা হয় সেটি এড়িয়ে যাচ্ছে।

  এই ক্ষেত্রে, IWD প্রাপ্ত চতুর্থ-পর্যায়ের বার্তার জন্য MIC (মেসেজ ইন্টিগ্রিটি কোড) কোড যাচাই করার চেষ্টা করে। যেহেতু প্রমাণীকরণ পরামিতি সহ দ্বিতীয় পর্যায়ের বার্তাটি পাওয়া যায়নি, চতুর্থ পর্যায়ের বার্তাটি প্রক্রিয়া করার সময়, PTK (Pairwise Transient Key) কী শূন্যতে সেট করা হয়। তদনুসারে, একজন আক্রমণকারী একটি নাল PTK ব্যবহার করে MIC গণনা করতে পারে এবং এই যাচাইকরণ কোডটি IWD দ্বারা বৈধ হিসাবে গ্রহণ করা হবে। এই আংশিক সংযোগ আলোচনা শেষ করার পরে, আক্রমণকারীর ওয়্যারলেস নেটওয়ার্কে সম্পূর্ণ অ্যাক্সেস থাকবে, যেহেতু অ্যাক্সেস পয়েন্টটি তার পাঠানো ফ্রেমগুলি পাবে, একটি নাল PTK কী দিয়ে এনক্রিপ্ট করা।

• wpa_supplicant (CVE-2023-52160) এ চিহ্নিত একটি সমস্যা একজন আক্রমণকারীকে একজন ব্যবহারকারীকে একটি কাল্পনিক ওয়্যারলেস নেটওয়ার্কে প্রলুব্ধ করতে দেয় যা ব্যবহারকারী যে নেটওয়ার্কের সাথে সংযোগ করতে চায় তার একটি ক্লোন। যদি একজন ব্যবহারকারী একটি জাল নেটওয়ার্কের সাথে সংযোগ স্থাপন করে, আক্রমণকারী ব্যবহারকারীর এনক্রিপ্ট না করা ট্রানজিট ট্রাফিকের (উদাহরণস্বরূপ, HTTPS ছাড়া সাইটগুলিতে অ্যাক্সেস) বাধা সংগঠিত করতে পারে।

  পিইএপি (প্রোটেক্টেড এক্সটেনসিবল অথেনটিকেশন প্রোটোকল) প্রোটোকল বাস্তবায়নে ত্রুটির কারণে, ভুলভাবে কনফিগার করা ব্যবহারকারী ডিভাইসের সাথে সংযোগ করার সময় একজন আক্রমণকারী প্রমাণীকরণের দ্বিতীয় পর্যায়টি এড়িয়ে যেতে পারে। প্রমাণীকরণের দ্বিতীয় পর্যায়টি বাইপাস করা একজন আক্রমণকারীকে একটি বিশ্বস্ত Wi-Fi নেটওয়ার্কের একটি জাল ক্লোন তৈরি করতে এবং ব্যবহারকারীকে পাসওয়ার্ড পরীক্ষা না করেই জাল নেটওয়ার্কে সংযোগ করার অনুমতি দেয়৷

  wpa_supplicant-এ সফলভাবে আক্রমণ চালানোর জন্য, সার্ভারের TLS শংসাপত্রের যাচাইকরণ ব্যবহারকারীর পক্ষ থেকে নিষ্ক্রিয় করতে হবে এবং আক্রমণকারীকে অবশ্যই ওয়্যারলেস নেটওয়ার্ক শনাক্তকারী (SSID, পরিষেবা সেট শনাক্তকারী) জানতে হবে। এই ক্ষেত্রে, আক্রমণকারীকে অবশ্যই শিকারের বেতার অ্যাডাপ্টারের সীমার মধ্যে থাকতে হবে, তবে ক্লোন করা বেতার নেটওয়ার্কের অ্যাক্সেস পয়েন্টের সীমার বাইরে। PEAP প্রোটোকল ব্যবহার করে WPA2-Enterprise বা WPA3-Enterprise সহ নেটওয়ার্কগুলিতে আক্রমণ সম্ভব।

  wpa_supplicant বিকাশকারীরা বলেছেন যে তারা সমস্যাটিকে একটি দুর্বলতা হিসাবে বিবেচনা করেন না, কারণ এটি শুধুমাত্র খারাপভাবে কনফিগার করা বেতার নেটওয়ার্কগুলিতে ঘটে যেগুলি সার্ভারের TLS শংসাপত্র যাচাই না করেই PEAP (EAP-TTLS) এর সাথে একত্রে EAP প্রমাণীকরণ ব্যবহার করে৷ সার্টিফিকেট যাচাই ছাড়া কনফিগারেশন সক্রিয় আক্রমণ থেকে সুরক্ষিত নয়। যারা দুর্বলতা আবিষ্কার করেছেন তারা দাবি করেছেন যে এই ধরনের ভুল কনফিগারেশনগুলি সাধারণ এবং ব্যাপক, যা wpa_supplicant চালিত অনেক Linux, Android এবং Chrome OS-ভিত্তিক গ্রাহক ডিভাইসগুলিকে ঝুঁকির মধ্যে ফেলেছে।

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

উত্স: opennet.ru