میلیاردها دستگاه در معرض آسیب‌پذیری جدید بلوتوث موسوم به BLESA قرار دارند
حمله‌ی جدید BLESA به‌دنبال نفوذ ازطریق فرایند اتصال مجدد بلوتوث است که اغلب نادیده گرفته می‌شود. برخلاف آسیب‌پذیری‌های قبلی، نقص فنی در عملیات اتصال مجدد بلوتوث باعث اجرای حمله می‌شود.
میلیاردها گوشی هوشمند، تبلت، لپ‌تاپ و سایر دستگاه‌های IoT در سراسر دنیا دراختیار کاربران هستند و همگی آن‌ها نرم‌افزار بلوتوث مشابهی دارند که تحقیقات نشان می‌دهد یک نقص فنی، آن‌ها را دربرابر برخی حملات آسیب‌پذیر کرده است.
حمله‌ی BLESA سرنام عبارت Bluetooth Low Energy Spoofing Attack است که آسیب‌پذیری دستگاه‌های دارای پروتکل Bluetooth Low Energy را تحت‌الشعاع قرار می‌دهد.
پروتکل Bluetooth Low Energy که با سرواژه‌ی BLE شناخته می‌شود، نسخه‌ی سبک‌تری از استاندارد اصلی بلوتوث است؛ البته با این تفاوت که درزمینه‌ی مصرف باتری بهینه‌سازی شده است تا هم‌زمان با حفظ اتصال بلوتوث در مصرف باتری نیز صرفه‌جویی کند.
باتوجه‌به ویژگی بهینه‌سازی مصرف باتری در پروتکل BLE، بیشتر تولیدکنندگان قطعات در دهه‌ی گذشته از این پروتکل در دستگاه‌های خود استفاده می‌کردند و باعث شد تقریبا هر دستگاهی که دارای باتری باشد از این فناوری بهره‌مند شود.
باتوجه‌به استفاده‌ی وسیع از فناوری BLE، محققان امنیتی و دانشگاهیان زیادی درطول سال‌های گذشته روی امنیت و آسیب‌پذیری این فناوری مطالعه کردند و تاکنون آسیب‌پذیری‌های فراوانی گزارش شده است.
با‌این‌حال، اکثریت قریب به‌اتفاق تحقیقات انجام‌شده روی مسائل امنیتی BLE، تقریبا متمرکز بر فرایند اتصال و جفت‌شدن (Pairing) دو دستگاه بوده و بخش‌عظیمی از پروتکل BLE نادیده گرفته شده است.
پروژه‌ی تحقیقاتی که در دانشگاه پردو (Purdue University) توسط یک تیم هفت نفره متشکل از دانشگاهیان انجام شد، تمرکز مطالعات را روی بخشی از پروتکل BLE معطوف کرد که نقش حیاتی در عملیات روزانه‌ی BLE ایفا می‌کند و پیش‌از این کم‌تر مورد توجه تیم‌های تحقیقاتی قرار گرفته بود.
تمرکز تحقیقات این پروژه، حول فرایند «اتصال مجدد» معطوف است. منظور از این فرایند، عملیاتی است که بعداز احراز هویت دو دستگاه BLE به‌عنوان کلاینت و سرور به‌صورت مکرر انجام می‌شود.
به‌عبارتی دیگر، اتصال مجدد یا Reconnection زمانی انجام می‌شود که دو دستگاه از محدوده‌ی اتصال یکدیگر خارج می‌شوند و مجددا به محدوده‌ی اتصال برمی‌گردند. معمولا در زمان اتصال مجدد، دو دستگاه BLE کلیدهای رمزنگاری یکدیگر را که در زمان فرایند جفت‌شدن ردوبدل کرده بودند، مورد بازبینی قرار می‌دهند و اتصال مجدد برقرار می‌شود تا انتقال اطلاعات ازطریق BLE ادامه پیدا کند.
اما تیم تحقیقاتی پردو می‌گوید مشخصات رسمی BLE فاقد اطلاعات دقیق برای توصیف جزئی فرایند بازبینی کدرمزنگاری شده و اتصال مجدد است. درنتیجه، دو مشکل سیستمی، راه خود را در روش اجرای نرم‌افزار BLE بازکرده‌اند. این دو مشکل عبارت‌اند از:
۱- احراز هویت درزمان اتصال مجدد به‌جای اینکه اجباری باشد، اختیاری انجام می‌شود.
۲- ممکن است فرایند احراز هویت برای اتصال مجدد به‌طورکلی انجام نشود، به‌خصوص اگر کاربر نتواند دستگاه را مجبور به احراز هویت کند.
حال این دو مشکل، راه را برای اجرای حمله‌ی بلوتوثی BLESA باز می‌کنند. درواقع، مهاجم از مرحله‌ی احراز هویت برای اتصال مجدد بین دو دستگاه رد می‌شود و داده‌های جعلی با اطلاعات غلط به دستگاه BLE ارسال و کاربر را تهییج می‌کند تصمیمات نادرستی بگیرد. بدین ترتیب، حمله‌ی بلوتوثی BLESA، دردسته حملات Spoofing (جعل) قرار می‌گیرد.
درادامه می‌توانید نسخه‌ی نمایشی حمله‌ی بلوتوثی BLESA را تماشا کنید.
متأسفانه، چندین پشته نرم‌افزاری BLE تحت تأثیر این آسیب‌پذیری قرار دارند.
با وجود اینکه دستگاه‌های زیادی دارای این آسیب‌پذیری هستند؛ اما خوشبختانه، این نقص فنی در همه‌ی پیاده‌سازی‌های واقعی روی دستگاه‌های BLE موفقیت‌آمیز نبوده است.
محققان دانشگاه پردو در گزارش خود عنوان کردند که چندین پشته نرم‌افزاری را که برای پشتیبانی از ارتباطات BLE در سیستم‌عامل‌های مختلف مورد استفاده قرار می‌گیرند، بادقت بررسی کرده‌اند. طبق یافته‌های محققان، پشته‌های نرم‌افزاری BlueZ (مورد استفاده برای دستگاه‌های IoT برپایه‌ی لینوکس)، Flouride (مخصوص دستگاه‌های برپایه‌ی اندروید) و دستگاه‌های BLE مخصوص iOS همگی دربرابر حمله‌ی BLESA آسیب‌پذیر بودند؛ اما پشته‌ی نرم‌افزاری دستگاه‌های BLE ویندوزی درمقابل این حمله ایمن بودند.
تیم تحقیقاتی در مقاله‌ی چاپ‌شده در ماه گذشته چنین نوشت:
تا تاریخ ۲۲ جون سال ۲۰۲۰ میلادی، اپل باتوجه‌به شناسه‌ی امنیتی CVE-2020-9770 که درباره‌ی آسیب‌پذیری بلوتوث بوده، مشکل نرم‌افزاری BLE را مرتفع کرده است؛ اما پیاده‌سازی BLE روی اندروید در دستگاه‌هایی که توسط تیم ما آزمایش شدند، همچنان آسیب‌پذیر بودند. برای مثال، دستگاه Google Pixel XL با سیستم‌عامل اندروید ۱۰ دربین دستگاه‌های آزمایش‌شده قرار داشته است.
همچنین، تیم BlueZ که توسعه‌ی دستگاه‌های IoT برپایه‌ی لینوکس را به‌عهده دارند، گفته است کدهای ناقصی را که باعث می‌شود راه برای اجرای حمله‌ی BLESA بازشود، حذف خواهند کرد و به‌جای آن‌ها کدهایی به‌کار می‌گیرند که فرایند اتصال مجدد BLE را با دقت انجام دهد تا دربرابر حمله‌ی BLESA ایمن شود.
متأسفانه، این نقص فنی مانند سایر نقص‌های فنی گذشته‌ی بلوتوث یک مشکل بزرگ‌تر دارد و آن ارائه‌ی وصله‌ی امنیتی برای تمام دستگاه‌های آسیب‌پذیر دربرابر حمله است. از یک سو، وسعت و تعداد زیاد دستگاه‌ها کار را دشوار می‌کند و ازسویی دیگر، برخی دستگاه‌ها هستند که به‌هیچ‌عنوان امکان دریافت وصله را ندارند.
برخی از تجهیزات IoT محدودشده که درطی یک دهه‌ی اخیر فروش رفته‌اند از قابلیت دریافت به‌روزرسانی پشتیبانی نمی‌کنند و مکانیزم به‌روزرسانی برای آن‌ها تعریف نشده است؛ بنابراین این دسته از تجهیزات برای همیشه بدون وصله امنیتی باقی خواهند ماند.
محافظت درمقابل حمله‌های بلوتوثی معمولا منوط به محافظت از دو دستگاه درحال اتصال در محیط کنترل شده است؛ اما در حمله‌ی BLESA، محافظت بسیار دشوار است، زیرا این نوع حمله عملیات تکرارشونده‌ی اتصال مجدد را هدف قرار می‌دهند.
مقاله‌های مرتبط:
مهاجمان می‌توانند با استفاده از حمله‌ی خودداری از خدمات (Denial-of-Service)، اتصال بلوتوث را بین دو دستگاه قطع کنند و دو دستگاه را در شرایط اتصال مجدد قرار دهند تا شرایط برای اجرای حمله‌ی BLESA فراهم شود. حفاظت از دستگاه‌های BLE درمقابل قطعی اتصال و کاهش سیگنال امری غیرممکن است.
موضوع این آسیب‌پذیری زمانی بیشتر اهمیت پیدا کرد که تیم تحقیقاتی براساس آمارهای قدیمی میزان استفاده از دستگاه‌های BLE دارای پشته‌ی نرم‌افزاری آسیب‌پذیر، متوجه شد که تعداد دستگاه‌های آسیب‌پذیر به میلیاردها عدد می‌رسد.
حال تمام این دستگاه‌ها نیازمند وصله‌ی امنیتی نرم‌افزاری هستند تا دربرابر این‌گونه حملات مقاوم شوند.
اطلاعات تکمیلی درباره‌ی حمله‌ی BLESAدر مقاله‌‌ای با عنوان BLESA: Spoofing Attacks against Reconnections in Bluetooth Low Energy دردسترس است؛ همچنین علاقه‌مندان می‌توانند ازطریق لینک پیوست‌شده فایل پی‌دی‌اف مقاله را دانلود کنند. مقاله‌ی این تیم تحقیقاتی در کنفرانس USENIX WOOT 2020 در ماه آگوست ارائه شد.
