پژوهشگران امنیتی نشان دادهاند که میتوان به دستگاههای IoT (اینترنت اشیا) از طریق فایروال نفوذ کرد — آن هم بدون نیاز به هرگونه آسیبپذیری نرمافزاری و حتی بدون وجود IP عمومی.
این مدل حمله، یک تغییر بزرگ در چشمانداز تهدیدات IoT ایجاد میکند، زیرا:
نیازی به اکسپلویت نیست
نیازی به دسترسی محلی یا اینترنتی دستگاه نیست
حتی دستگاههای داخل اینترانت نیز قابل کنترل هستند
کل ماجرا به سوءاستفاده از نحوه اعتماد دستگاهها به پلتفرمهای مدیریت ابری برمیگردد.
🟦 چگونه معماری دستگاههای IoT راه نفوذ را فراهم کرده است؟
در سناریوی سنتی، مهاجمان با پیدا کردن IP و اکسپلویت فریمور، وارد دستگاه IoT میشدند.
اما سازمانهایی که:
دستگاهها را پشت فایروال نگه میدارند
اکسپوژر اینترنتی ندارند
بهموقع آنها را پچ میکنند
معمولاً امنتر هستند.
پژوهش جدید خلاف این تصور را ثابت میکند.
🟦 مدل حمله جدید: ربایش کانال مدیریت ابری
در کنفرانس Black Hat Europe، «Jincheng Wang» و پژوهشگر امنیتی «Nik Xe» یک مدل حمله PoC ارائه خواهند داد که طی آن:
مهاجم بدون آسیبپذیری و بدون IP، تنها با تقلید دستگاه IoT میتواند کنترل کامل آن را از طریق ابر بهدست گیرد.
یعنی:
میتواند هر تعداد دستگاه را همزمان هدف بگیرد
حتی دستگاههای صرفاً داخل LAN نیز قابل نفوذ هستند
فایروالها هیچ نشانهای از حمله نمیبینند
کلید ماجرا: اعتماد بیش از حد پلتفرمهای ابری به SN یا MAC Address.
🟦 دستگاه IoT چگونه خودش را به ابر معرفی میکند؟
دستگاههای IoT برای احراز هویت در سرویسهای ابری معمولاً اطلاعاتی مانند:
Serial Number (SN)
MAC Address
را ارسال میکنند.
چون این دستگاهها ساده و کمامکانات هستند، معمولاً روشهای پیچیدهتری مثل:
کلیدهای سختافزاری
گواهیهای امن
توکنهای ساختاریافته
را ندارند.
همین باعث ایجاد یک نقطه بحرانی میشود.
🟦 چگونه مهاجم دستگاه را جعل میکند؟
مهاجم فقط به دو داده نیاز دارد:
SN یا MAC Address دستگاه
الگوریتمی که پلتفرم ابری از آن برای تولید Credential استفاده میکند
چگونه این اطلاعات بهدست میآید؟
بسیاری از تولیدکنندگان هنوز SN/MAC را «اطلاعات حساس» نمیدانند
این اطلاعات از طریق APIهای محلی بدون احراز هویت در دسترس هستند
برخی دستگاهها SN را روی شبکه Broadcast میکنند
MAC Address را میتوان Brute Force کرد (نیمی از آن که Prefix ثابت است)
مرحله بعد
مهاجم فریمور را تحلیل میکند تا:
منطق احراز هویت
روش ساخت Credential
APIهای ابری
را استخراج کند.
🟦 رقابت برای تصاحب کانال ابری
پس از ساخت Credential معتبر:
مهاجم خودش را جای دستگاه به ابر معرفی میکند
اتصال قانونی دستگاه را قطع و جایگزین میکند
سپس دوباره اتصال قانونی را برمیگرداند تا هیچ ردپایی دیده نشود
اما کنترل ابری در اختیار مهاجم باقی میماند
از دید سازمان:
همهچیز عادی است
هیچ لاگ مشکوکی دیده نمیشود
فایروال هیچ ارتباط غیرمجاز را مسدود نمیکند
اما دستگاه فرمانهای مدیریتی مهاجم را از طریق ابر دریافت میکند.
🟦 راهکار دفاعی چیست؟
پژوهشگران تأکید میکنند:
«تنها راه، بازطراحی کامل احراز هویت در اکوسیستم مدیریت ابری IoT است.»
پیشنهادها:
احراز هویت چندمرحلهای وقتی IP دستگاه تغییر میکند
استفاده از UUIDهای تصادفی بهجای SN/MAC
محدود کردن APIهای محلی و جلوگیری از افشای اطلاعات
تفکیک کانال ابری مدیریت از کانال داده
اعمال مدل اعتماد حداقلی (Zero Trust) برای ارتباطات ابری
🟦 چرا این حمله خطرناک است؟
چون:
قابل ردیابی نیست
بر اساس رفتار عادی دستگاه انجام میشود
هیچ اکسپلویت یا بدافزاری نیاز ندارد
هر دستگاه IoT کارخانهای، خانگی و سازمانی هدف احتمالی است
پژوهشگران هشدار میدهند:
«عدم وجود گزارشهای بزرگ، نشانه امن بودن نیست. سازندگان معمولاً سایلنت پچ میکنند.»
🟦 جمعبندی
این مدل حمله نشان میدهد که:
امنیت IoT از اساس دچار یک ضعف معماری است
حملات بدون نیاز به آسیبپذیری قابل اجرا هستند
فایروالها نمیتوانند این مدل ربایش کانال ابری را تشخیص دهند
سازمانها باید نگاه خود به امنیت IoT را بازنگری کنند
منابع: