اینترنت اشیاء (Internet of Things – IoT) از زمان پیدایش خود یک مسیر طولانی را پیموده است. بااینحال، فرایند استانداردسازی سامانههای اینترنت اشیاء برای دستیابی به راهکارهای امن اینترنت اشیاء همچنان در مراحل ابتدایی خود قرار دارد. پژوهشگران تاکنون مقالات مروری ارزشمند متعددی درباره چارچوبها (Frameworks)، معماریها (Architectures) و همچنین تهدیدهای موجود در لایههای مختلف اینترنت اشیاء ارائه کردهاند. بااینوجود، بخش عمدهای از پژوهشهای موجود، جنبههای امنیتی میانافزار (Firmware) در زیستبوم اینترنت اشیاء را نادیده گرفتهاند. ازاینرو، فقدان یک مطالعه مروری جامع درباره امنیت میانافزار اینترنت اشیاء احساس میشود؛ مطالعهای که دلایل اساسی ناامنی میانافزار در اینترنت اشیاء را برجسته کند، آسیبپذیریها را فهرست نماید و مرور عمیقی از مهمترین تکنیکهای تحلیل را ارائه دهد. این مقاله با هدف پر کردن این خلأ تدوین شده و تا آنجا که نویسندگان اطلاع دارند، نخستین مقاله مروری جامع درباره امنیت و ناامنی میانافزار دستگاههای اینترنت اشیاء را ارائه میکند. این پژوهش با تأکید بر اهمیت امنیت میانافزار آغاز میشود و سپس با بررسی جنبههای فنی، تجاری، استانداردسازی و پژوهشی، دلایل اصلی ناامنی میانافزار را شناسایی میکند. بهطور خاص، دامنه، سیر تکامل و ساختار داخلی میانافزارهای اینترنت اشیاء همراه با پیامدهای امنیتی آنها مورد بحث قرار گرفته است. علاوه بر این، یک ردهبندی (Taxonomy) از آسیبپذیریهای میانافزار اینترنت اشیاء ارائه شده است. همچنین چالشها و پیچیدگیهایی که مانع از شناسایی آسیبپذیریهای میانافزار میشوند بررسی شده و پس از آن، ابزارها و تکنیکهای موجود برای ارزیابی آسیبپذیریها بهصورت تفصیلی تحلیل شدهاند. تحلیل و بررسی مقایسهای جامعی نیز از مهمترین تکنیکهای تحلیل ارائه شده است که در آن، آسیبپذیریهای قابل کشف، روششناسی مورد استفاده و پلتفرمها و/یا معماریهای پشتیبانیشده توسط هر تکنیک بررسی میشوند. در بخش پایانی، چندین مسئله پژوهشی مهم شناسایی شدهاند تا زمینه را برای توسعه پژوهشهای آینده در حوزه امنیت میانافزار اینترنت اشیاء فراهم سازند. در نهایت، مجموعهای از توصیهها برای تأمینکنندگان، توسعهدهندگان و یکپارچهسازان دستگاههای اینترنت اشیاء ارائه شده است.
کلیدواژهها (Keywords): اینترنت اشیاء (IoT)، امنیت اینترنت اشیاء (IoT Security)، میانافزار اینترنت اشیاء (IoT Firmware)، تحلیل میانافزار (Firmware Analysis)، امنیت میانافزار (Firmware Security)، مهندسی معکوس میانافزار (Firmware Reverse Engineering)
1. مقدمه (Introduction)
پیشبینی میشود تولید انبوه دستگاههای اینترنت اشیاء (Internet of Things – IoT) با نرخ بسیار بالایی رشد کند [1, 2, 3]. استقرار فناوری 5G نیز استفاده کنونی از دستگاههای اینترنت اشیاء را بیش از پیش افزایش خواهد داد. در نتیجه، سرمایهگذاری قابل توجهی در حوزه اینترنت اشیاء مشاهده میشود [4, 5]. اینترنت اشیاء هماکنون حجم عظیمی از دادههای مربوط به انسانها را جمعآوری و ارائه میکند و به همین دلیل، محدوده تهدید علیه حریم خصوصی افراد ناگزیر گسترش خواهد یافت [4, 6, 7]. افزون بر این، تنوع و گستردگی دستگاههای اینترنت اشیاء به اندازهای است که سازمانها و پژوهشگران مختلف، تعاریف متفاوتی از اینترنت اشیاء ارائه میکنند [2, 8, 9]. ازاینرو، مدیریت امنیت در زیستبوم اینترنت اشیاء به وظیفهای دشوار تبدیل شده است. بنابراین، افزایش وابستگی انسانها به فناوری [10] لزوماً تضمینکننده حریم خصوصی یا امنیت نیست. علاوه بر این، اینترنت اشیاء حاصل همگرایی چندین فناوری مختلف است و در نتیجه، تمامی مسائل امنیتی موجود نیز به این حوزه منتقل شدهاند [11, 12].
حملات متعددی ثبت شدهاند که در آنها از اینترنت اشیاء بهعنوان ابزاری برای هدف قرار دادن زیرساختهای موجود استفاده شده است [13]. پژوهشگران بیش از یک دهه است که روی امنیت دستگاههای اینترنت اشیاء کار میکنند. بااینحال، بخش عمده این پژوهشها بر امنیت شبکه و امنیت سامانه در اینترنت اشیاء متمرکز بودهاند [14, 13, 15, 8, 2, 16, 17, 18, 19] و بخش میانافزار معمولاً نادیده گرفته شده است. میانافزار نوعی نرمافزار در هر دستگاه است که با سختافزار (hardware) دستگاه تعامل دارد. در سطح میانافزار، بالاترین سطح دسترسی (privilege) روی هر سامانه وجود دارد. ازاینرو، در صورتی که میانافزار به مخاطره افتاده یا مورد نفوذ قرار گیرد، کل سامانه نیز عملاً تحت کنترل مهاجم قرار خواهد گرفت. بر اساس یک گزارش فنی (White Paper)[1] ، که مهاجمان شناختهشدهای مانند Fancy Bear اکنون از میانافزار برای اجرای حملات مخرب استفاده میکنند، زیرا امنیت این بخش از لایههای کامپیوتری معمولاً نادیده گرفته میشود[2]. خوشبختانه، در رایانههای همهمنظوره (General-Purpose Computers)، مشخصات استانداردی برای توسعه لایه میانافزار وجود دارد؛ از جمله میتوان به UEFI و Coreboot[3] اشاره کرد. افزون بر این، طبق گزارش UEFI، تا سال 2018 حدود 80 تا 90 درصد رایانههای شخصی و سرورهای مورد استفاده در سراسر جهان از میانافزار مبتنی بر UEFI استفاده میکردند. بنابراین، مدیریت یک استاندارد واحد برای تقریباً تمامی سامانههای یک حوزه خاص چندان دشوار نیست. به همین دلیل، سوءاستفاده از آسیبپذیریهای میانافزار در رایانههای سنتی معمولاً به صرفه نبوده است.
بااینحال، امنیت میانافزار اینترنت اشیاء کاملاً متفاوت است. میانافزار چه در سطح پایین (Low-Level) و چه در سطح بالا (High-Level)، بخش قابلتوجهی از نرمافزار موجود در یک دستگاه اینترنت اشیاء را تشکیل میدهد. ازاینرو، سوءاستفاده (exploitation) موفق از هر بخش میانافزار معمولاً به در اختیار گرفتن کامل دستگاه منجر میشود [13, 20, 6]. برخلاف امنیت میانافزار در رایانههای همهمنظوره، امنیت میانافزار در دستگاههای اینترنت اشیاء به دلایل متعددی چالشبرانگیز است. نخست آنکه توسعهدهندگان میانافزار اینترنت اشیاء معمولاً آگاهی و شناخت محدودی از امنیت دستگاههای اینترنت اشیاء دارند [14, 21]. دوم از آنجا که بیشتر دستگاههای اینترنت اشیاء همواره روشن بوده و به اینترنت متصل هستند، سوءاستفاده از آسیبپذیریهای آنها کاملاً محتمل است.
سوم آنکه تنوع گسترده و روزافزون معماریها، استانداردسازی راهکارها و رسمیسازی ابزارهای تحلیل آسیبپذیری میانافزار اینترنت اشیاء را تقریباً ناممکن میسازد. چهارم آنکه ماهیت محدود از نظر منابع در دستگاههای اینترنت اشیاء، ایجاد توازن میان کارایی و امنیت را اجتنابناپذیر میکند. در نهایت، برخی از دستگاههای اینترنت اشیاء فاقد سازوکار بهروزرسانی هستند [22, 14] و معمولاً یک فایل میانافزار بر روی هزاران دستگاه نصب میشود. بنابراین، یک آسیبپذیری در میانافزار میتواند در طیف وسیعی از دستگاهها با موفقیت مورد سوءاستفاده قرار گیرد. افزون بر این، بهروزرسانیهای میانافزار غالبا بر افزودن قابلیتها و امکانات جدید متمرکز میباشند تا رفع اشکالات و آسیبپذیریهای موجود. ازاینرو، ممکن است آسیبپذیریها به نسخههای بعدی میانافزار نیز منتقل شوند و در نتیجه در نسلهای بعدی دستگاهها همچنان باقی بمانند. این عوامل و دلایل دیگر، ناامنی مزمن موجود در اینترنت اشیاء را تشدید میکنند. ازاینرو، راهکارهای موجود برای ارزیابی امنیت اینترنت اشیاء، علاوه بر ضعفهای ذاتی تکنیکهای تحلیل (برای مثال تحلیل ایستا (Static Analysis))، از محدودیتهای خاص اینترنت اشیاء نیز رنج میبرند؛ محدودیتهایی که فرایندهای مهندسی معکوس میانافزار (Firmware Reverse Engineering) و تحلیل آسیبپذیری را با دشواری مواجه میکنند.
پژوهشگران و علاقهمندان به اینترنت اشیاء راهکارهای متعددی را برای مقابله با مشکلات امنیتی این حوزه توسعه دادهاند. پژوهشگران همچنین با نگارش مطالعات مروری جامع، مسائل امنیتی و راهکارهای متناظر آنها را مورد بررسی قرار دادهاند. بااینحال، حتی در مواردی که راهکارهایی مبتنی بر امنیت میانافزار ارائه شدهاند، همچنان نیاز مبرمی به یک مطالعه مروری جامع وجود دارد که اهمیت میانافزار را در امنیت اینترنت اشیاء مشخص کند. افزون بر این، در ادبیات موجود، مرز میان مؤلفههای مختلف نرمافزاری یک دستگاه اینترنت اشیاء ــ مانند سیستمعامل (Operating System)، بوتلودر (Bootloader)، نرمافزار کاربردی (Application) و میانافزار ــ اغلب مبهم است و این موضوع میتواند موجب سردرگمی توسعهدهندگان راهکارها شود. در نهایت، بیشتر مطالعات مروری بر امنیت معماری سامانههای اینترنت اشیاء تمرکز دارند؛ درحالیکه امنیت نرمافزار خودِ دستگاه نیز یک بردار حمله (Attack Vector) بسیار مهم به شمار میرود. این عوامل و دلایل دیگر، به شکلگیری پرسشهای مهم امنیت میانافزار اینترنت اشیاء منجر شدهاند که در جدول 1 مطرح شدهاند. ما معتقدیم حل مسائل امنیت میانافزار اینترنت اشیاء از طریق رویکرد علت و معلولی امکانپذیر است. ازاینرو، شناسایی دلایل ناامنی میانافزار و اتخاذ رویکردی گامبهگام برای رفع هر یک از این مشکلات میتواند به دستیابی به میانافزار امن در اینترنت اشیاء منجر شود. در ادامه این مقاله، با شناسایی دلایل بنیادین این مسائل و سپس بررسی راهکارهای مقابلهای مرتبط با هر یک از آنها در بخشهای بعدی، به پرسشهای مطرحشده در جدول 1 پاسخ خواهیم داد.
جدول ۱. مهمترین پرسشها در خصوص امنیت میانافزار اینترنت اشیاء که در بخشهای مختلف این مقاله مورد بحث قرار گرفتهاند:
پرسشها:
- میانافزار اینترنت اشیاء (IoT Firmware) چه تفاوتی با سایر انواع میانافزارها دارد و پیامدهای امنیتی این تفاوتها چیست؟ (بخش ۲)
- نقش و دامنه عملکرد میانافزار اینترنت اشیاء چیست و این میانافزار در گذر زمان چگونه تکامل یافته است؟ (بخش ۲)
- مهمترین دلایل ناامنی میانافزار اینترنت اشیاء چیست و چگونه به وضعیت کنونی رسیدهایم؟ (بخش ۲.۴)
- متداولترین آسیبپذیریهای مشاهده شده در میانافزار اینترنت اشیاء کداماند؟ (بخش ۳)
- چالشهای اصلی در تحلیل امنیت میانافزار چیست و این چالشها چرا به وجود آمدهاند؟ (بخش ۴)
- مهمترین تکنیکهای تحلیل میانافزار کداماند و هر یک بر چه آسیبپذیریها و معماریهای اینترنت اشیاء تمرکز دارند؟ (بخش ۴)
- چه راهکارهای بالقوهای برای رفع این مشکلات وجود دارد؟ (بحش ۵.۶)
1.1 دستاوردهای پژوهش (Contribution)
این مقاله درصدد است با پر کردن شکافهای مطرحشده، به پژوهشگران جدید در این حوزه از راههای زیر کمک کند:
- ما یک مرور نظاممند جامع (Comprehensive Systematic Literature Review) از امنیت میانافزار اینترنت اشیاء و تکنیکهای ارزیابی آن ارائه میکنیم.
- این مقاله دلایل مهم و تأثیرگذاری را که به ناامنی میانافزار در دستگاههای اینترنت اشیاء منجر میشوند، فهرست میکند. افزون بر این، یک ردهبندی (Taxonomy) از آسیبپذیریهای میانافزار اینترنت اشیاء ارائه شده است.
- علاوه بر شناسایی چالشهای موجود در مهندسی معکوس میانافزار اینترنت اشیاء، خلاصهای بهروز از راهکارهای برجسته، ویژگیهای آنها و تحلیل این راهکارها نیز ارائه و بررسی شده است.
- در پایان، فرصتهای پژوهشی بالقوه و همچنین مجموعهای از توصیهها برای حل مسائل امنیت میانافزار ارائه شدهاند.
1.2 ساختار مقاله (Paper Organization)
این مقاله در هفت بخش سازماندهی شده است. بخش 2 به تشریح انگیزه انجام این پژوهش، برخی مباحث زمینهای و همچنین دلایل ناامنی میانافزار اینترنت اشیاء اختصاص دارد. در بخش 3، یک ردهشناسی از آسیبپذیریهای میانافزار اینترنت اشیاء ارائه میشود. بخش 4 برخی از مهمترین تکنیکهای تحلیل میانافزار برای شناسایی آسیبپذیریهای امنیتی را معرفی میکند. در بخش 5، بر تعدادی از مسائل باز پژوهشی که برای دستیابی به میانافزار امن اینترنت اشیاء نیازمند بررسی بیشتر هستند تأکید میشود. در بخش 6 توصیههایی برای تأمینکنندگان، توسعهدهندگان و یکپارچهسازان اینترنت اشیاء ارائه شده و در نهایت، مقاله در بخش 7 جمعبندی میشود.
2. انگیزه پژوهش (Motivation)
شکل 1 هدف این مقاله را نشان میدهد. نخستین انگیزه مهم برای نگارش این مقاله، نبود مطالعات مروری یا تحلیلهای جامع از مرورهای ادبیات موجود در حوزه امنیت میانافزار اینترنت اشیاء است. دوم آنکه، تفاوت نقش و دامنه میانافزار در اینترنت اشیاء و رایانههای سنتی را تبیین خواهیم کرد. به دلیل تنوع گسترده دستگاههای اینترنت اشیاء، نقش و دامنه عملکرد میانافزار نیز دستخوش تغییر میشود. ازاینرو، معتقدیم ارزیابی امنیت میانافزار در دستگاههای اینترنت اشیاء ضرورتی جدی دارد. سوم آنکه، مجموعهای از دلایل مهمی را که به ناامنی میانافزار اینترنت اشیاء منجر شدهاند فهرست میکنیم. برای این منظور، روند تکامل میانافزار اینترنت اشیاء در طول سالها و رویدادهایی که در این تغییرات نقش داشتهاند بررسی میشود. در خلال بررسی این سه جنبه از امنیت میانافزار اینترنت اشیاء، به دو پرسش اساسی نیز پاسخ خواهیم داد: 1. میانافزار اینترنت اشیاء چه تفاوتی با سایر انواع میانافزار دارد و پیامدهای امنیتی این تفاوتها چیست؟ 2. نقش و دامنه عملکرد میانافزار اینترنت اشیاء چیست و این میانافزار در گذر زمان چگونه تکامل یافته است؟
2.1 مرور پیشینه پژوهش (Literature Review)
مقالات متعددی در حوزه امنیت اینترنت اشیاء منتشر شدهاند. بهطور کلی، میتوان این آثار را در سه دسته اصلی طبقهبندی کرد: 1. مطالعات مروری عمومی درباره امنیت اینترنت اشیاء: این دسته امنیت اینترنت اشیاء را بررسی میکنند، اما تمرکز آنها بر جنبه میانافزار نیست. 2. مطالعات مروری تخصصی درباره میانافزار اینترنت اشیاء: این دسته بهطور ویژه به مرور ادبیات موجود در زمینه امنیت میانافزار اینترنت اشیاء میپردازند. 3. راهکارها و چارچوبهای موجود: این آثار با هدف ارائه یک راهکار جدید یا پیشنهاد یک چهارچوب (Framework) برای تحلیل میانافزار اینترنت اشیاء تدوین شدهاند، اما در ضمن، بخشی از راهبردهای موجود را نیز مرور میکنند. در ادامه، هر یک از این دستهها به صورت جداگانه بررسی میشوند.
مطالعات مروری جامع عمومی درباره امنیت اینترنت اشیاء: مطالعات مروری متعددی درباره امنیت اینترنت اشیاء بهطور کلی منتشر شدهاند. برای نمونه، پژوهشهای [13] و [23] تهدیدها و آسیبپذیریهای مختلف موجود در زیستبوم اینترنت اشیاء را بررسی میکنند. افزون بر این، پژوهش [13]، دستورالعملهایی برای توسعه یک چارچوب امنیتی ویژه تأمینکنندگان اینترنت اشیاء ارائه میدهد. این پژوهش همچنین حوزههای کلیدی پژوهش را شناسایی کرده و توصیههایی ارائه میدهد. بااینحال، این مطالعات آسیبپذیریها را از منظر رویکرد لایهای معماری اینترنت اشیاء بررسی میکنند؛ در حالی که آسیبپذیریهای مرتبط با خود دستگاه اینترنت اشیاء و مؤلفههای نرمافزاری آن مورد توجه قرار نگرفتهاند. سایر پژوهشها مانند [24] نیز بر موضوعات خاصی در امنیت اینترنت اشیاء تمرکز دارند؛ از جمله ربایش کنترل (Control Hijacking) [20]، امنیت دوربینهای مدار بسته (CCTV) [25] و بدافزارهای اینترنت اشیاء (IoT malware) [26]. هرچند این مطالعات از جامعیت مناسبی برخوردارند، اما جنبه میانافزار در امنیت اینترنت اشیاء عموماً در آنها مغفول مانده است.
مطالعات مروری جامع تخصصی درباره میانافزار اینترنت اشیاء: راهبرد ارائه شده در [24] سطوح حمله (Attack Surfaces) مختلف در دستگاههای اینترنت اشیاء را در قالب رابطهای سختافزاری، نرمافزاری و پروتکلی شناسایی کرده و راهکارهای مرتبط با آنها را مرور میکند. بااینحال، این مطالعه قادر به شناسایی چالشها، آسیبپذیریها و دلایل بنیادین ناامنی میانافزار اینترنت اشیاء نیست. یک مطالعه مروری مرتبطتر اما مختصرتر در [27] ارائه شده است. نویسندگان این پژوهش، راهکارهای موجود برای شناسایی آسیبپذیریهای میانافزار اینترنت اشیاء را طبقهبندی کردهاند؛ اما تحلیل این راهکارها، نوع آسیبپذیریهای پوششدادهشده توسط هر راهکار و همچنین آسیبپذیریهای مرتبط با انواع مختلف میانافزار را بررسی نکردهاند.
پژوهش [28] در سال 2018، چالشهای بهوجودآمده در فرایند فازینگ (Fuzzing) دستگاههای نهفته (Embedded Devices) را بررسی کرد. این مطالعه بهطور خاص رفتار آسیبپذیریهای ناشی از خرابی حافظه (Memory Corruption Vulnerabilities) را در انواع مختلف دستگاههای نهفته تحلیل نمود. در پژوهشی جدیدتر، [29] تعداد 28 چالش اصلی در شبیهسازی میانافزار اینترنت اشیاء را شناسایی کردهاند. این پژوهش همچنین ابزارهای متعددی را برای شبیهسازی (Emulation) و تحلیل پویا (Dynamic Analysis) با هدف شناسایی آسیبپذیریها بررسی کرده است. افزون بر این، برخی از حوزههای مهم پژوهشی در زمینه شبیهسازی و اجرا در سختافزار دیگر (Re-hosting) میانافزار را معرفی میکند. بااینحال، هیچیک از این دو مطالعه به آسیبپذیریهای امنیتی میانافزار و همچنین تکنیکهای مرتبط با تحلیل ایستا (Static Analysis) نپرداختهاند.
راهکارها و چارچوبهای موجود (Existing Solutions and Frameworks): مقالات دیگری نیز وجود دارند که چارچوبهایی را برای امنیت اینترنت اشیاء پیشنهاد یا ارزیابی کردهاند [30, 15, 31]. برخی پژوهشها نیز بر ارائه یک راهکار خاص متمرکز هستند و عمدتاً از یکی از انواع روشهای تحلیل استفاده میکنند. این راهکارها برای شناسایی آسیبپذیریهای میانافزار اینترنت اشیاء از تحلیل ایستا [32, 6, 33, 34, 35, 36] یا تحلیل پویا [37, 38, 39, 40] بهره میگیرند. در این فرایند، پدیدآورندگان برخی از چالشهای کلیدی موجود در اجرای تحلیل ایستا و تحلیل پویا را نیز شناسایی کردهاند. افزون بر تحلیل ایستا و پویا، چندین تکنیک فازینگ نیز برای کشف انواع مختلف آسیبپذیریها در میانافزار دستگاههای اینترنت اشیاء به کار گرفته شدهاند [41, 38]. بااینحال، چنین پژوهشهایی معمولاً بر یک نوع خاص از تحلیل متمرکز هستند و تنها بخشی از تکنیکهای مهندسی معکوس، آسیبپذیریها و چالشهای ویژه همان روش را بررسی میکنند. افزون بر این، پدیدآورندگان پژوهش [42] با ارزیابی امنیت 16 دستگاه متداول اینترنت اشیاء، نحوه اجرای مهندسی معکوس را بررسی کردهاند. آنها با استفاده از تکنیکهایی مانند تزریق خطا (Fault Injection) نشان میدهند که دستگاههای اینترنت اشیاء غالباً دارای گذرواژههای ضعیف هستند. علاوه بر این، Jonas [43] ابزارها و تکنیکهای مختلفی را برای بررسی میانافزار اینترنت اشیاء و شناسایی آسیبپذیریهای آن معرفی میکند. بااینوجود، این آثار و پژوهشهای مشابه دیگر [44, 45, 42] گستره و عمق کامل موضوع امنیت میانافزار اینترنت اشیاء را پوشش نمیدهند.
اگرچه موضوعات مختلفی در مقالات فوق بهصورت پراکنده مورد بحث قرار گرفتهاند، هنوز یک مطالعه مروری جامع که بهطور ویژه بر تحلیل امنیت میانافزار اینترنت اشیاء متمرکز باشد و جنبههای کلیدی این حوزه را با جزئیات کافی بررسی کند، وجود ندارد. افزون بر این، بخشی از پژوهشهای موجود نیز قدیمی شدهاند. این مقاله چالشها، آسیبپذیریها، مهمترین راهکارهای تحلیل میانافزار، مسیرهای پژوهشی آینده و در نهایت توصیههای تخصصی مرتبط با حوزه امنیت میانافزار اینترنت اشیاء را بررسی و شناسایی میکند. ازاینرو، تا آنجا که اطلاع داریم، این مقاله نخستین اثری است که مسیر ورود پژوهشگران جدید به حوزه میانافزار اینترنت اشیاء را هموار میسازد. هدف ما از این مقاله ارائه تصویری جامع از وضعیت کنونی امنیت میانافزار اینترنت اشیاء و پر کردن خلأهای موجود در ادبیات پژوهش است.
2.2 برداشتهای نادرست درباره میانافزار اینترنت اشیاء (Misconception about IoT Firmware)
هر عملیاتی که توسط یک دستگاه محاسباتی انجام میشود، مستلزم اجرای نوعی کد است. از نمایش عبارت «hello world» روی صفحهنمایش گرفته تا برقراری ارتباط سختافزار با هسته (Kernel) از طریق درایورهای دستگاه (Device Drivers)، بخش قابلتوجهی از این کدها در قالب میانافزار اجرا میشوند. بااینحال، در دستگاههای اینترنت اشیاء، نقش و دامنه عملکرد میانافزار تفاوت چشمگیری با سامانههای سنتی دارد. در برخی موارد، تمامی اجزای نرمافزاری یک دستگاه اینترنت اشیاء، از جمله نرمافزار کاربردی (Application) و سیستمعامل (Operating System – OS)، درون میانافزار قرار میگیرند. این اجزا یا در حافظه فقطخواندنی (Read Only Memory – ROM) دستگاه ذخیره شدهاند یا در حافظه فلش (Flash Memory) آن قرار دارند. ازاینرو، میانافزار در دستگاههای اینترنت اشیاء قابلیتها و مسئولیتهای بسیار گستردهتری نسبت به میانافزار در سامانههای سنتی بر عهده دارد. در نتیجه، تأمین امنیت میانافزار بهطور اجتنابناپذیر به وظیفهای پیچیده و چالشبرانگیز تبدیل میشود. شکل 2 مقایسهای میان پشته نرمافزاری (Software Stack) سامانههای سنتی (شکل 2a) و انواع مختلف دستگاههای اینترنت اشیاء (شکلهای 2b و 2c) ارائه میدهد. همانگونه که مشاهده میشود، تنوع گسترده دستگاههای اینترنت اشیاء پیامدهای مستقیمی بر ماهیت میانافزار آنها دارد. در نتیجه، دامنه و نقش میانافزار در دستگاههای اینترنت اشیاء بهطور قابلتوجهی متفاوت است و همین موضوع، تأمین امنیت میانافزار اینترنت اشیاء را به چالشی دشوار تبدیل میکند.
جدول 2. تحلیل مقایسهای تفصیلی میان پژوهشهای موجود و مقاله حاضر:
جدول 3: مقایسه ویژگیها و قابلیتهای میانافزار اینترنت اشیاء با میانافزار سنتی:
2.2.1 دامنه و نقش میانافزار اینترنت اشیاء (Scope and Role of IoT Firmware)
به دلیل ماهیت فراگیر و فراوانی گسترده دستگاههای اینترنت اشیاء، ساختار داخلی این دستگاهها بسته به منابع سختافزاری در دسترس میتواند بسیار متفاوت باشد. ازاینرو، تعیین مرزهای مشخص میان مؤلفههای مختلف نرمافزاری در یک دستگاه اینترنت اشیاء چندان معنادار نیست. در نتیجه، سه نوع متداول از میانافزار اینترنت اشیاء شناسایی شدهاند [42]:
- میانافزار بدون سیستمعامل (Bare Metal): این دستگاهها فاقد سیستمعامل هستند و کد ذخیره شده در تراشه را مستقیماً اجرا میکنند.
- میانافزار مبتنی بر سیستمعامل بلادرنگ (Real-Time Operating System – RTOS): این نوع میانافزار برای دستگاههایی بهکار میرود که برنامههای بلادرنگ را اجرا میکنند و تنها به قابلیتهای محدودی از سیستمعامل نیاز دارند.
- میانافزار مبتنی بر لینوکس (Linux-Based Firmware): این نوع میانافزار در دستگاههایی استفاده میشود که از منابع سختافزاری بیشتری برخوردار بوده و انتظار میرود قابلیتهای بیشتری را ارائه دهند.
امروزه اکثر دستگاهها از میانافزار مبتنی بر لینوکس استفاده میکنند، زیرا منابع سختافزاری دستگاههای اینترنت اشیاء بهتدریج قدرتمندتر شدهاند [47]. همانگونه که در شکل 2b نشان داده شده است، محتوای معمول یک میانافزار لینوکسی شامل دادههای هدر (Header Data)، بوتلودر (Bootloader)، کرنل (Kernel) و سیستم فایل (Filesystem) میباشد [12, 48, 49, 50]. شکل 2c نیز نمونههایی از دستگاههای مدرن اینترنت اشیاء نظیر Raspberry Pi، BeagleBone و Arduino Uno را نمایش میدهد که از بسیاری جهات به یک رایانه سنتی شباهت دارند.
تفاوتهای معماری اشاره شده تأثیر مستقیمی بر وظایف و قابلیتهای میانافزار در دستگاههای اینترنت اشیاء دارند. هرچند نقش میانافزار در رایانههای همهمنظوره در طول زمان دستخوش تغییر شده است، اما وظایف سنتی آن معمولاً شامل بررسی سلامت تجهیزات جانبی، مدیریت اتصال و جداسازی دستگاهها و آمادهسازی فرایند راهاندازی سیستم بوده است. در مقابل، میانافزار اینترنت اشیاء وظایف بسیار گستردهتری را بر عهده دارد که از جمله آنها میتوان به موارد زیر اشاره کرد: برقراری ارتباط با سایر دستگاهها؛ دریافت و نصب بهروزرسانیهای از راه دور (Over-The-Air Updates – OTA)؛ پیادهسازی سرویسهای کاربردی؛ دربرگرفتن کرنل سیستم؛ جمعآوری اطلاعات ثبت رویدادها (Logging Information)؛ نگهداری وضعیت دستگاه؛ مدیریت سیستم فایل؛ و حتی در برخی موارد، دربرگرفتن کل سیستمعامل. بسته به نوع سکوی مورد استفاده و کاربرد دستگاه، لایه میانافزار در یک سامانه اینترنت اشیاء ممکن است بسیار سبک و صرفاً در حد یک نرمافزار کاربردی باشد یا برعکس، تمام نرمافزار موجود در دستگاه را دربرگیرد. جدول 3 مقایسهای اجمالی میان وظایف میانافزار در دستگاههای اینترنت اشیاء و میانافزار رایانههای سنتی ارائه میکند. این وظایف و مسئولیتهای گسترده و سایر قابلیتهای مشابهی که توسط میانافزار دستگاههای اینترنت اشیاء ارائه میشوند [51]، مفهوم امنیت را در حوزه اینترنت اشیاء بازتعریف کردهاند. بنابراین، پیامدهای امنیتی ناشی از آنها را نه میتوان نادیده گرفت و نه میتوان با همان رویکردهای مورد استفاده برای میانافزارهای سنتی با آنها مقابله کرد.
2.3 ریشههای عمیق ناامنی (Deep Roots of Insecurity)
برای درک دلایل بنیادین ناامنی میانافزار اینترنت اشیاء، ابتدا باید مسیر شکلگیری و تکامل آن را بررسی کرد. شکل 3 مجموعهای از رویدادها را نشان میدهد که به توسعه و تکامل میانافزار اینترنت اشیاء منجر شدهاند. اگرچه مفهوم اینترنت اشیاء نخستین بار در سال 1999 توسط کوین اشتون (Kevin Ashton) مطرح شد [16, 52]، اما نخستین «شیء (Thing)» متصل به اینترنت، یک دستگاه فروش خودکار نوشابه کوکاکولا (CocaCola) بود که در سال 1982 در دانشگاه Carnegie Mellon واقع در شهر Pittsburgh آمریکا راهاندازی شد. حتی پیش از آن نیز سازمان پروژههای پژوهشی پیشرفته دفاعی آمریکا (Defense Advanced Research Projects Agency – DARPA)، شبکههای حسگر بیسیم (Wireless Sensor Networks – WSNs) را توسعه داده بود؛ فناوری که امروزه در قلمرو اینترنت اشیاء قرار میگیرد. تحولات متعددی در فاصله دهههای 1960 تا 1990، رخ داد که به جداسازی نرمافزار از سختافزار انجامید و در نهایت بسیاری از قابلیتهای موجود در سیستمعامل و سختافزار را به میانافزار منتقل کرد [53]. توسعه سیستمعاملهای بلادرنگ (RTOS) در دهه 1980 و استفاده از مدل شیءگرا (Object-Oriented Model – OOM) به ایجاد میانافزارهای قابلاعتماد و پایدار کمک کرد. علاوه بر این، توسعه کدهای ماژولار (Modular) باعث شد در فاصله سالهای 1990 تا 2000 دستگاههایی با ویژگیهای مشابه اینترنت اشیاء ظهور کنند. در اواسط دهه 1990، لینوکس پشتیبانی گستردهای دریافت کرد و به گزینهای مناسب برای سامانههای نهفته (Embedded systems) تبدیل شد. مایکروسافت نیز در اواخر دهه 1990 با ارائه نسخه نهفته ویندوز وارد این حوزه شد. آغاز قرن بیستویکم، شرایط لازم برای توسعه سریع دستگاههای اینترنت اشیاء را فراهم کرد. از جمله این عوامل میتوان به موارد زیر اشاره کرد: استفاده از کدهای ماژولار نظیر سیستمعاملها، بوتلودرها و کتابخانههای شخص ثالث؛ در دسترس بودن فناوریهای ارتباطی مانند RFID و Wi-Fi؛ وجود پروتکلهای شبکه مورد نیاز همچون NAT و IPv6؛ پیشرفتهای چشمگیر در حوزه سختافزار؛ و سرمایهگذاری گسترده سرمایهگذاران در بازار اینترنت اشیاء. با وجود آنکه اینترنت اشیاء در نگاه نخست یک داستان موفقیت کامل به نظر میرسد، اما هر گام در مسیر توسعه آن پیامدهای پنهانی نیز به همراه داشته است. برخی از این پیامدها در جدول 4 ارائه شدهاند.
مشکلات اشاره شده در جدول ۴ تنها عواملی نیستند که به ایجاد آسیبپذیریهای مختلف در میانافزارهای امروزی اینترنت اشیا منجر میشوند. توسعه بیوقفه دستگاههای اینترنت اشیاء همچنین موجب شکلگیری روندهای تجاری ناسالمی در زیستبوم امنیت میانافزار شده است. در ادامه، برخی از این روندهای نامطلوب که تأثیر منفی بر امنیت میانافزار اینترنت اشیاء داشتهاند، معرفی میشوند:
- مشارکتهای تجاری ناکارآمد (Flawed Business Partnership): در بسیاری از موارد، تولیدکنندگان اصلی طرح (Original Design Manufacturers – ODMs) و تولیدکنندگان اصلی تجهیزات (Original Equipment Manufacturers – OEMs) توجه کافی به امنیت دستگاه یا میانافزار اینترنت اشیاء ندارند. حتی در مواردی که امنیت مورد توجه قرار میگیرد، ممکن است کد توسعهیافته توسط ODM و تحویل شده به OEM دارای اشکال یا ضعف امنیتی باشد؛ ضعفی که در نهایت میتواند در هزاران محصول تجاری تکثیر شود [48, 55].
- استفاده از پایگاه کد آماده و از پیش تعیین شده (Predetermined Code Base): تولیدکنندگان برای کاهش زمان عرضه محصول به بازار و کاهش حجم کد، اغلب از پایگاههای کد قدیمی و رایگان و همچنین کتابخانههای موجود استفاده میکنند. این رویکرد معمولاً منجر به استفاده از چارچوبهای ناامن و در نتیجه تولید میانافزارهای آسیب پذیر میشود [12].
- نصب دربِ پشتی (Backdoor Installation): در برخی موارد، تامینکنندگان یا تولیدکنندگان، خود به صورت عمدی دربهای پشتی متعددی را در میانافزار تعبیه میکنند [17, 12, 32].
- توسعهدهندگان کمتجربه (Inexperienced Developers): رشد انفجاری صنعت اینترنت اشیاء باعث شده است بسیاری از شرکتها برای کاهش زمان عرضه محصول به بازار، توسعهدهندگان کمتجربه را استخدام کنند. نتیجه این رویکرد، تولید نرمافزارهای ناامن است [12, 48].
- کارایی در برابر امنیت (Performance vs. Security): به طور کلی مسئولیتپذیری اندکی نسبت به امنیت در حوزه اینترنت اشیاء وجود دارد. بسیاری از تولیدکنندگان عملکرد را بر امنیت ترجیح میدهند. طبق یک نظرسنجی که با حمایت IBM و Arxan انجام شده است، 48 درصد از تولیدکنندگان اینترنت اشیاء هیچگونه آزمون امنیتی روی برنامههای اینترنت اشیاء خود انجام نمیدهند[4].
جدول 4. پیامدهای امنیتی و فنی ناشی از تحولات مختلف در مسیر تکامل اینترنت اشیاء:
- آگاهی امنیتی کاربران نهایی (End-User Security Awareness): مصرفکنندگان محصولات نیز معمولاً دانش اندکی درباره امنیت و حریم خصوصی دارند. حتی در صورت آگاهی، رشد سریع تعداد دستگاههای اینترنت اشیاء فرصت کافی برای یادگیری، سازگاری و شناخت ضعفهای امنیتی محصولات را از آنها میگیرد [42]. از سوی دیگر، تولیدکنندگان نیز اغلب به دلیل بیتوجهی خود به امنیت، هیچ دستورالعمل امنیتی مشخصی در اختیار کاربران قرار نمیدهند.
- بهروزرسانیهای نامنظم میانافزار (Sporadic Firmware Updates): به منظور رفع آسیبپذیریها و افزودن قابلیتهای جدید، بهروزرسانیهای مداوم ضروری هستند. بااینحال، ممکن است تأمین کننده تمایلی به استفاده از بهروزرسانی از راه دور (OTA) نداشته باشد. در چنین شرایطی، اگر مسئولیت بهروزرسانی به کاربر واگذار شود، احتمال دارد میانافزار هرگز بهروزرسانی نشود.
- بهروزرسانیهای مبتنی بر قابلیتهای جدید (Feature-Specific Updates): هر بهروزرسانی میانافزار الزاماً به معنای رفع آسیبپذیریها یا ارتقاء امنیت نیست. در بسیاری از موارد، بهروزرسانی صرفاً شامل افزودن قابلیت جدید و چند خط کد تازه است که خود میتواند منشأ آسیبپذیریهای جدید باشد[5].
- عدم دسترسی به میانافزار یاسورسکد (No Firmware Source): بسیاری از تامینکنندگان فایلهای میانافزار محصولات خود را منتشر نمیکنند و همچنین سورسکد فایلهای اجرایی را در اختیار عموم قرار نمیدهند. در نتیجه، جامعه پژوهشی نمیتواند بهطور مؤثر در شناسایی و رفع آسیبپذیریها مشارکت کند.
- پیادهسازی پروتکلهای غیراستاندارد (Non-Standard Protocols Implementation): برخی شرکتها با توسعه یا دستکاری پروتکلهای استاندارد متناسب با نیازهای خود، از استانداردهای رسمی فاصله میگیرند. این رویکرد میتواند به تولید دستگاههای آسیبپذیر منجر شود [56].
- نبود نهادهای نظارتی مؤثر (Lack of Regulatory Agencies): اگرچه سازمانهایی وجود دارند که راهنماها و بهترین رویههای امنیتی را ارائه میدهند، اما نهاد الزامآوری که این توصیهها را بر تولیدکنندگان دستگاههای اینترنت اشیاء تحمیل کند، وجود ندارد. حتی در مواردی که نهادهای نظارتی فعال هستند، فرایند اعمال الزامات امنیتی معمولاً کُند میباشد. در نتیجه، همچنان شرکتهایی با تجربه محدود اقدام به توسعه و یکپارچهسازی دستگاههای اینترنت اشیاء بدون درنظر گرفتن امنیت ذاتی میکنند.[6]
3. آسیبپذیریهای امنیتی در میانافزار اینترنت اشیاء (Security Vulnerabilities in IoT Firmware)
برخی از مهمترین دلایل ناامنی میانافزار اینترنت اشیاء در بخش قبل شناسایی و بررسی شدند. با تکیه بر آن مباحث، اکنون میتوان آسیبپذیریهای رایج مشاهده شده در میانافزار اینترنت اشیاء را معرفی کرد. بخشی از این آسیبپذیریها در سایر فناوریها نیز مشاهده میشوند؛ موضوعی که با توجه به ماهیت اینترنت اشیاء به عنوان ترکیبی از چندین فناوری مختلف، کاملاً قابل انتظار است. بااینحال، همین ویژگی موجب میشود اینترنت اشیاء در مقایسه با بسیاری از فناوریهای دیگر با مخاطرات امنیتی بیشتری مواجه باشد. در شکل 4، یک ردهبندی (Taxonomy) از آسیبپذیریهای میانافزار اینترنت اشیاء ارائه شده است. در ادامه، هر یک از این دستههای آسیبپذیری بهصورت جداگانه بررسی میشوند.
3.1 آسیبپذیریهای خرابی حافظه (Memory Corruption Vulnerabilities)
در بسیاری از دستگاههای اینترنت اشیاء، آسیبپذیریهای متداول خرابی حافظه شناسایی شدهاند. این دسته شامل آسیبپذیریهایی نظیر سرریز بافر (Buffer Overflow)، نقضها و خطاهای مرتبط با اشارهگرها (Pointer Violations)، سرریز اعداد صحیح (Integer Overflows)، رشتههای قالببندی کنترلنشده (Uncontrolled Format Strings)، عدم وجود بررسی حدود (Missing Bound Checks) و سردرگمی نوع (Type Confusion) است. این آسیبپذیریها در دستگاههای اینترنت اشیاء رایج هستند، زیرا محدودیتهای حافظه در بسیاری از این دستگاهها زمینه بروز خرابی حافظه را فراهم میکند [57]. افزون بر این، واحدهای حیاتی محافظت از حافظه نظیر واحد مدیریت حافظه (Memory Management Unit – MMU) در بسیاری از دستگاههای کوچک اینترنت اشیاء وجود ندارند که این مسئله مقاومت دستگاه را در برابر حملات مبتنی بر نقض حافظه بیشازپیش کاهش میدهد [40]. بهطور معمول، آسیبپذیریهای خرابی حافظه میتوانند به کرش کردن سیستم (System Crash)، افزایش سطح دسترسی (Privilege Escalation)، تزریق کد (Code Injection) و سایر پیامدهای امنیتی منجر شوند.
3.2 اعتبارنامههای کدگذاریشده درون برنامه (Hard-Coded Credentials)
تامینکنندگان در بسیاری از موارد اطلاعات حساس را بدون رعایت ملاحظات امنیتی کافی در فایل میانافزار قرار میدهند. این مسئله میتواند منجر به افشای اطلاعات حیاتی مانند نام کاربری، گذرواژه، گواهیها (Certificates)، کلیدهای رمزنگاری داده و URLهای مهم شود. در واقع، مشاهده شده است که چندین دستگاه از گواهیهای SSL یکسان استفاده میکنند؛ بدین معنا که در صورت دستیابی به یک گواهی SSL، رمزگشایی ترافیک تمامی آن دستگاهها امکانپذیر خواهد بود [32]. برخی دستگاهها نیز دارای دربهای پشتی (Backdoors) هاردکدشده هستند که گاهی با اهداف مخرب و گاهی با نیتهای ظاهراً مشروع در میانافزار قرار داده شدهاند [6, 58]. در چنین شرایطی، مهاجمان میتوانند با تحلیل میانافزار دستگاهها، اعتبارنامههای کدگذاریشده درون برنامه (Hard-Coded) را استخراج کرده و به میانافزار یا دادههای تولیدشده توسط دستگاه اینترنت اشیاء دسترسی پیدا کنند.
3.3 مؤلفههای (اصلی) منسوخ و قدیمی (Outdated Core Components)
بخش عمدهای از دستگاههای اینترنت اشیاء بر پایه مؤلفههای قدیمی و آسیبپذیر ساخته میشوند [59]. این مؤلفهها شامل بوتلودر، هسته، کتابخانههای سیستمی و مجموعهای از کتابخانههای شخص ثالث هستند. استفاده از این مؤلفهها مزایایی مانند دسترسپذیری، سهولت استفاده و در برخی موارد کیفیت مناسب کدنویسی را به همراه دارد. بااینحال، مشکل اساسی آن است که این مؤلفهها باید به صورت مستمر بهروزرسانی شوند. در حوزه اینترنت اشیاء، بهروزرسانیها معمولاً نه از سوی تامینکنندگان و نه از سوی کاربران نهایی جدی گرفته نمیشوند. حتی در صورت استفاده از نسخههای بهروز، چرخه انتشار بهروزرسانیها متوقف نمیشود و نسخههای جدید بهطور مداوم عرضه میشوند. در برخی موارد توسعهدهندگان نیز به دلیل تنبلی، و یا به علت ناسازگاریهای نرمافزاری (Compatibility Issues)، قادر به استفاده از نسخههای جدیدتر نیستند یا از آن اجتناب میکنند. در نتیجه، سوءاستفاده از این دستگاهها برای مهاجمان بسیار آسانتر میشود. طی بررسی انجام شده روی نمونههای مختلف میانافزار اینترنت اشیاء، مشاهده شد که بسیاری از آسیبپذیریهای هسته لینوکس در نسخههای بعدی میانافزار نیز همچنان باقی ماندهاند.
3.4 رابطهای آسیبپذیر (Vulnerable Interfaces)
برای برقراری ارتباط با دستگاههای اینترنت اشیاء از رابطهای مختلفی استفاده میشود. مهمترین این رابطها عبارتاند از: مهمترین این رابطها شامل رابط وب (Web Interface) و APIها (Application Programming Interfaces) برای اتصال به سایر اجزای اکوسیستم دستگاههای اینترنت اشیاء مانند تلفنهای همراه، دستگاههای همتا (Peers)، سرورها، و سامانههای رایانش ابری (Cloud Computing) یا رایانش لبهای (Edge Computing) میشوند.
بسیاری از این رابطها به دلیل پیادهسازی ناامن APIها دارای آسیبپذیریهای مختلف هستند. گزارشهای متعددی نشان میدهد که تعداد زیادی از دستگاههای اینترنت اشیاء از آسیبپذیریهای متنوع وب رنج میبرند [11, 27, 37]. از آنجا که رابط وب یکی از رایجترین روشهای ارتباطی است، مهاجمان بدافزارهای اختصاصی نظیر IoTReaper را برای سوءاستفاده از آسیبپذیریهای رابط وب توسعه دادهاند [60]. علاوه بر این، فقدان پشتیبانی از احراز هویت دومرحلهای (Two-Factor Authentication) در بسیاری از سرویسهای ابری اینترنت اشیاء همچنان یکی از مشکلات حل نشده این حوزه محسوب میشود [61].
3.5 ارتباطات شبکهای آسیبپذیر (Vulnerable Network Communications)
بخش قابلتوجهی از ارتباطات شبکهای در اینترنت اشیاء ناامن میباشند؛ چرا که این سامانهها باید با وجود محدودیت منابع، تنوع بالایی از قابلیتها را نیز ارائه دهند. مهمترین سرویسها و پروتکلهای ارتباطی مورد استفاده در اینترنت اشیاء عبارتاند از: WiFi، Bluetooth، ZigBee، LoRa، 3G/4G/LTE، SSL/TLS، SSH، TelNet، TFTP. برخی از این پروتکلها توسط تامینکنندگان، متناسب با نیازهای خاص آنها تغییر داده میشوند که این موضوع به ایجاد ضعفهای امنیتی منجر میشود. در موارد دیگر نیز پورتهای غیرضروری باز باقی میمانند یا سرویسهای قدیمی و بلااستفاده همچنان فعال هستند. بر اساس گزارشی از Symantec، بیشترین تعداد حملات علیه دستگاههای اینترنت اشیاء از طریق رابط ناامن TelNet[7] انجام شده است. هرچند پیادهسازی یک مدل ارتباطی استاندارد در دستگاههای اینترنت اشیاء برای دستیابی به تعاملپذیری (Interoperability) بسیار مطلوب است، اما وجود تنها یک آسیبپذیری در چنین مدلهایی میتواند میلیونها دستگاه را در معرض خطر قرار دهد. نمونهای از این وضعیت، مجموعه آسیبپذیریهای Ripple20 است که در سال 2020 توسط آزمایشگاه پژوهشی JSOF کشف شد. این مجموعه شامل 19 آسیبپذیری روز صفر (Zero-Day Vulnerabilities) در پشته TCP/IP شرکت Treck بود. از آنجا که پشته Treck بهطور گسترده در دستگاههای اینترنت اشیاء مورد استفاده قرار میگیرد، میلیونها دستگاه در معرض آسیبپذیری قرار دارند [62].
3.6 مکانیزم بهروزرسانی آسیبپذیر (Vulnerable Update Mechanism)
بخش بزرگی از دستگاههای اینترنت اشیاء هرگز توسط کاربران بهروزرسانی نمیشوند. همچنین، استفاده از بهروزرسانی از راه دور (OTA) در بسیاری از این دستگاهها هنوز رایج نیست [63]. حتی زمانی که فرایند بهروزرسانی انجام میشود، سازوکار مورد استفاده برای بهروزرسانی میانافزار اغلب دارای ضعفهای امنیتی است. برای مثال، پژوهشگران توانستهاند پروتکل بهروزرسانی دستگاههای شناخته شدهای مانند FitBit را با وجود بهرهگیری از رمزنگاری سرتاسری (End-to-End Encryption) مورد سوءاستفاده قرار دهند [64]. سایر آسیبپذیریهای مرتبط شامل موارد زیر هستند: انتقال فایلهای بهروزرسانی بهصورت متن آشکار (Cleartext)؛ ناامن بودن سرور بهروزرسانی؛ نبود اعتبارسنجی میانافزار توسط دستگاه پس از دریافت آن [65]. اگرچه جامعه پژوهشی در تلاش برای استانداردسازی سازوکارهای بهروزرسانی است، اما دستیابی به یک راهکار جامع همچنان چالشبرانگیز به نظر میرسد. اخیراً نیز کارگروه مهندسی اینترنت (Internet Engineering Task Force – IETF)، پیشنویس یک معماری برای بهروزرسانی امن میانافزار دستگاههای اینترنت اشیاء تهیه کرده است[8].
3.7 آسیبپذیریهای ناشی از پیکربندی نادرست (Misconfiguration Vulnerabilities)
کاربران نهایی معمولاً آگاهی محدودی درباره مدیریت پیکربندی دستگاههای اینترنت اشیاء دارند و این موضوع میتواند به بروز مشکلات امنیتی جدی منجر شود. در این دستگاهها امکان پیکربندی مؤلفههای مختلفی از جمله سیستمعامل، سرویسهای شبکه، سامانههای ثبت رویداد (Logging)، گزینههای اعلان و اطلاعرسانی، برنامههای وب و تنظیمات پیشفرض احراز هویت وجود دارد. بسیاری از دستگاهها با تنظیمات پیشفرض ناامن عرضه میشوند و اصلاح این تنظیمات بر عهده کاربر است. با این حال، حتی در صورت آگاهی از مخاطرات امنیتی، کاربران ممکن است به دلیل محدودیت دانش فنی قادر به بازپیکربندی صحیح تمامی بخشها نباشند. پیکربندی نادرست مؤلفههایی مانند iptables [26]، وبسرورها (Web Servers) [32]، سازوکارهای رمزنگاری، اعتبارنامههای احراز هویت، BusyBox، uClibCو فرایند بوت سیستم (System Bootup) از جمله نمونههای رایج این دسته از آسیبپذیریها به شمار میروند.
3.8 آسیبپذیریهای احراز هویت (Authentication Vulnerabilities)
یکی از رایجترین آسیبپذیریهای مشاهده شده در زیستبوم اینترنت اشیاء، دور زدن سازوکار احراز هویت (Authentication Bypass) است [27]. در برخی موارد، تامینکنندگان دستگاه برای مدیریت یا بهروزرسانی از راه دور، دربهای پشتی را در سامانه تعبیه میکنند. حتی در نبود چنین دربهای پشتی، مهاجمان ممکن است با کشف خطاهای موجود در رویههای احراز هویت [6] بتوانند کدهای دارای سطح دسترسی بالا را اجرا کنند. پیادهسازی احراز هویت مناسب در اینترنت اشیاء دشوار است، زیرا این دستگاهها از یکسو با محدودیت منابع مواجهاند (هستند) و از سوی دیگر نیازمند سازوکارهای امنیتی نسبتاً پیچیده میباشند. برای دور زدن سازوکارهای احراز هویت ضعیف، از روشهایی نظیر: فازینگ (Fuzzing)، حملات بروتفورس (Brute Force) و تزریق خطا (Fault Injection) استفاده میشود. علاوه بر این، استفاده از نامهای کاربری و گذرواژههای رایج و ضعیف توسط تولیدکنندگان یا کاربران نهایی موجب شده است میلیونها دستگاه توسط بدافزارهایی نظیر Mirai[9]، Silex[10] و Nyadrop[11] آلوده شده و در اختیار مهاجم قرار گیرند. مشکلات امنیتی تنها به احراز هویت محدود نمیشوند؛ در صورت نبود سازوکارهای مناسب کنترل دسترسی (Access Control)، آسیبپذیریهای مجوزدهی (Authorization Vulnerabilities) نیز ایجاد میشوند که غالباً به افزایش سطح دسترسی منجر میگردند. بر اساس گزارش اخیر شرکت F-Secure، حدود 87 درصد از تهدیدهای مشاهده شده علیه اینترنت اشیاء ناشی از استفاده از اعتبارنامههای ضعیف یا پیشفرض بودهاند. با وجود آنکه بدافزار Mirai در سال 2016 ظهور کرد، این بدافزار همچنان در سالهای 2018 و 2019 یکی از موفقترین حملات علیه اینترنت اشیاء به شمار میآمد؛ زیرا بسیاری از دستگاهها همچنان از گذرواژههایی مانند «123456» یا حتی گذرواژه خالی استفاده میکردند.
3.9 عدم انطباق با استانداردها (Non-compliance)
از آنجا که اینترنت اشیاء (Internet of Things – IoT) همچنان یک فناوری نوظهور به شمار میرود، استانداردها، قوانین و مقررات جدیدی از سوی نهادهای مختلفی مانند OWASP، IoT SF و مؤسسه ملی استانداردها و فناوری (National Institute of Standards and Technology – NIST) معرفی شدهاند.این نهادها مجموعهای از دستورالعملها، تجارب برتر(Best Practices) و توصیههای فنی را برای طراحی، توسعه، استقرار و یکپارچهسازی امن سامانههای اینترنت اشیاء ارائه میکنند. با این حال، تولیدکنندگان معمولاً از این دستورالعملها بهدرستی پیروی نکرده و در نهایت هیچ سیاست امنیتی مشخصی تدوین نمیکنند و یا سیاستهایی مبهم و ناکارآمدی ارائه میدهند که به طراحی امنیتی ضعیف منجر میشود. ناتوانی در رعایت استانداردها و الزامات امنیتی میتواند پیامدهایی نظیر موارد زیر را در پی داشته باشد: نشت دادهها (Data Leakage)، بوت ناامن سامانه (Insecure Booting)، استفاده از الگوریتمهای رمزنگاری ضعیف، مدیریت نامناسب اعتبارنامهها (Credentials)، استفاده از سرویسهای منسوخ و آسیبپذیر.
3.10 دادههای آلوده (Tainted Data)
سامانههای اینترنت اشیاء ماهیتی تعاملی دارند و از این رو اطلاعات حساس کاربران را دریافت، ذخیره، منتقل و پردازش میکنند. به همین دلیل، هنگام تبادل داده میان مؤلفههای مختلف یک سامانه اینترنت اشیاء، باید تحلیل مناسب دادهها از طریق اعتبارسنجی (Validation) و پالایش یا پاکسازی داده (Sanitization) انجام شود. مؤلفههای متداول در چنین سامانههایی عبارتاند از: دستگاه اینترنت اشیاء، درگاه (Gateway)، بسترهای رایانش ابری و لبه (Cloud/Edge Platforms). تحلیل آلودگی (Taint Analysis) به منظور ارزیابی این موضوع انجام میشود که آیا دادهها در یک قالب یا وضعیت مشخص میتوانند منجر به نقض امنیت شوند یا خیر. نبود کنترل مناسب بر دادههای ورودی و خروجی میتواند زمینهساز حملات متداولی مانند تزریق SQL (SQL Injection)، و XSS (Cross-Site Scripting) شود.
4. تکنیکهای اصلی تحلیل میانافزار (Principal Firmware Analysis Techniques)
در این بخش، مؤثرترین روشهای تحلیلی که طی سالهای گذشته برای شناسایی آسیبپذیریهای میانافزار اینترنت اشیاء توسعه یافتهاند بررسی میشوند. در این مقاله، این راهکارها با عنوان «تکنیکهای اصلی تحلیل میانافزار» شناخته میشوند. این تکنیکها عمدتاً بر سه رویکرد اصلی استوار هستند: تحلیل ایستا (Static Analysis)، تحلیل پویا (Dynamic Analysis)، فازینگ (Fuzzing). علاوه بر این، برخی رویکردهای ترکیبی (Hybrid Approaches) نیز مورد بررسی قرار گرفتهاند.
بهطور کلی، تحلیل میانافزار فرایندی ساده و سرراست نیست؛ زیرا پیش از انجام هرگونه تحلیل، ابتدا باید میانافزار به دست آمده و سپس مهندسی معکوس (Reverse Engineering) شود. شکل 5 تعدادی از مراحل مورد نیاز در فرایند مهندسی معکوس میانافزار اینترنت اشیاء را نشان میدهد، هرچند این مراحل تنها بخشی از فعالیتهای مورد نیاز هستند و تمام تلاشهای لازم را پوشش نمیدهند. برای مثال، برخی تولیدکنندگان به منظور افزایش امنیت، ساختار سیستم فایل (Filesystem) را سفارشیسازی میکنند. بنابراین، پیش از ورود به بررسی تکنیکهای تحلیل میانافزار، ابتدا موانع و چالشهای موجود در فرایند مهندسی معکوس میانافزار را بررسی میکنیم.
4.1 مهندسی معکوس (Reverse Engineering)
مهندسی معکوس فرایند بررسی محتوا و رفتار یک میانافزار (Firmware) است [49]. مهندسی معکوس امکان تحلیل میانافزار بهمنظور شناسایی آسیبپذیریها را فراهم میکند. این فرایند کاری طولانی، زمانبر، پیچیده و عمدتاً دستی است که به مهارت فنی قابلتوجهی نیاز دارد [49, 48, 50, 67]. میانافزارهای IoT معمولاً بهصورت فایلهای باینری (Binary) و بدون دسترسی به سورسکد ارائه میشوند [6, 51]. با این حال، پیش از آغاز مهندسی معکوس، خودِ فرایند دستیابی به میانافزار دستگاههای IoT یک چالش مهم محسوب میشود [6, 37, 67]. دستیابی به میانافزار تنها مشکل موجود در مهندسی معکوس نیست. در ادامه، مجموعهای از چالشها معرفی میشوند که به عنوان پیشنیازهای اساسی مهندسی معکوس میانافزار مطرح هستند.
4.1.1 دستیابی به میانافزار (Firmware Acquisition)
سه روش اصلی برای جمعآوری فایلهای میانافزار عبارتاند از:
- دریافت از تولیدکننده (Collection from Vendor): اگرچه اکثر تولیدکنندگان، میانافزار دستگاههای IoT خود را در اختیار عموم قرار نمیدهند، اما میانافزار برخی دستگاهها مستقیماً از وبسایت شرکت سازنده قابل دانلود است [11]. جمعآوری این فایلها از وبسایتهای مختلف بهصورت دستی عملاً امکانپذیر نیست و حتی از منظر فنی نیز کار سادهای محسوب نمیشود. هرچند میتوان خزندهها (Crawlers) یا اسکریپتهای جمعآوریکننده (Scrapers) را برای دانلود خودکار این فایلها توسعه داد [50, 32]، اما تولیدکنندگان مختلف از روشهای متفاوتی برای ارائه فایلهای میانافزار استفاده میکنند؛ موضوعی که خودکارسازی این فرایند را دشوار میسازد [6]. برای مثال، برخی وبسایتها از پیوندهای پویا (Dynamic Links) مبتنی بر جاوااسکریپت برای دانلود استفاده میکنند که از طریق سورسکد صفحه قابل استخراج نیستند. در چنین شرایطی، ممکن است بتوان فایل میانافزار را از سرور FTP شرکت سازنده دریافت کرد، اما این کار معمولاً با از دست رفتن بخشی از فرادادهها (Metadata) همراه است [50]. این قبیل مشکلات باعث میشوند که حتی در صورت انتشار عمومی میانافزارها نیز جمعآوری کامل آنها فرایندی دشوار باشد. ازاینرو، نیاز به یک مخزن متمرکز برای نگهداری فایلهای میانافزارهای مختلف احساس میشود [32].
- استخراج از سختافزار (Extraction from Hardware): روش دیگر، استخراج مستقیم میانافزار از دستگاه اصلی از طریق اشکالزدایی (debugging) درگاههایی مانند JTAG (کوتاه شده عبارت Joint Test Action Group) یا UART (کوتاه شده عبارت Universal Asynchronous Receiver-Transmitter) است [58, 49]. همچنین برخی روشهای سختافزاری دیگر نیز برای این منظور پیشنهاد شدهاند [42]. بدیهی است که این روش مستلزم دسترسی فیزیکی به دستگاه است. حتی در صورت وجود چنین دسترسی، برخی دستگاههای IoT از سازوکارهای امنیت سختافزاری مناسبی بهره میبرند که مانع استخراج کد ذخیره شده در حافظههای Flash یا ROM میشود.
- استخراج میانافزار در حین بهروزرسانی OTA (Grabbing During OTA Update): از طریق بهروزرسانیهای OTA (Over-The-Air) میتوان کل میانافزار یا بخشهایی از آن را بهروزرسانی کرد [15]. بسیاری از تولیدکنندگان از مکانیزمهای بهروزرسانی امن استفاده نمیکنند؛ بنابراین ممکن است مهاجم بتواند در حین فرایند بهروزرسانی، فایل میانافزار را شنود (Sniff) و دریافت کند.
4.1.2 استخراج بسته میانافزار (Firmware Unpacking)
همانگونه که پیشتر اشاره شد، میانافزار معمولاً یک فایل باینری است که تمامی قابلیتهای دستگاه را در خود جای داده است. نخستین مرحله در مهندسی معکوس، شناسایی و استخراج این اجزا از یک فایل باینری واحد است؛ فرایندی که در برخی موارد شامل اصلاح و بستهبندی مجدد (Repacking) نیز میشود. دشواری اصلی این مرحله از آنجا ناشی میشود که هیچ استاندارد واحدی برای تولید فایلهای میانافزار وجود ندارد. به دلیل نبود استانداردسازی، تولیدکنندگان مختلف از روشهای متفاوتی برای بازتولید میانافزار استفاده میکنند. برخی شرکتها حتی قالبهای اختصاصی برای فایلهای میانافزار [6, 38, 32] یا سیستمفایلهای اختصاصی [37] توسعه دادهاند. از دیگر چالشهای این مرحله میتوان به موارد زیر اشاره کرد: میانافزارهای رمزگذاری شده (Encrypted Firmware) [38]؛ میانافزارهای مبهمسازی شده (Obfuscated Firmware) [68]؛ فایلهای یکپارچه (Monolithic Firmware) که در آنها سیستمعامل، هسته (Kernel)، برنامه کاربردی IoT و سایر اجزای نرمافزاری در قالب یک فایل واحد ترکیب شدهاند [32]؛ استفاده از الگوریتمهای فشردهسازی غیرمتعارف. اگرچه ابزارهایی برای تسهیل فرایند استخراج اجزی میانافزار وجود دارند، اما این ابزارها نیز محدودیتهای خاص خود را دارند. نخست آنکه خروجی آنها همیشه قابل اعتماد نیست [37]. دوم آنکه این فرایند همچنان زمانبر و عمدتاً دستی است و خودکارسازی کامل آن آسان نیست [6]. برخی ابزارها قادرند تحلیل آنتروپی (Entropy Analysis) را روی فایلهای میانافزار انجام دهند تا وجود رمزگذاری یا مبهمسازی را تشخیص دهند. معمولاً مقدار آنتروپی بالا نشانهای از رمزگذاری یا مبهمسازی دادهها است [11]. با این حال، بررسی دستی فایلها با ابزارهایی مانند HxD همچنان یکی از روشهای رایج و مؤثر محسوب میشود.
4.1.3 دیکامپایلکردن (Decompiling)
فایلهای میانافزار معمولاً بدون سورسکد ارائه میشوند. از آنجا که خواندن مستقیم کد ماشین برای انسان قابل درک نیست، مهندسی معکوس بدون تبدیل آن به شکل قابل فهم امکانپذیر نخواهد بود [69]. دیکامپایل (Decompilation)، فرایند تبدیل کد ماشین به زبانهای سطح بالای قابل فهم برای انسان است [49]. این فرایند خود شامل مراحل متعددی از جمله: دیساسمبلی (Disassembly)، تبدیل به نمایش میانی سطح بالاتر و تحلیل جریان داده (Lifting and Data-Flow Analysis)، تحلیل جریان کنترل (Control-Flow Analysis)، تحلیل نوع داده (Type Analysis) میشود [70]. دیساسمبلی نخستین مرحله است که در آن کد ماشین به معادل اسمبلیِ قابل خواندن برای انسان تبدیل میشود. این فرایند به عوامل مختلفی وابسته است. برای مثال، نوع کامپایلر مورد استفاده نقش مهمی در موفقیت دیساسمبلی (disassembly) دارد. کامپایلرهای مدرن معمولاً دادهها و بخشهای اجرایی را از یکدیگر تفکیک میکنند؛ اما برخی کامپایلرهای قدیمی دادهها را در بخشهای اجرایی قرار میدادند و بدین ترتیب فرایند تشخیص مرز میان داده و کد اجرایی را برای ابزارهای دیکامپایل دشوار میکردند. علاوه بر این، دیکامپایل به معماری سختافزاری نیز وابسته است؛ زیرا کد ماشین برای یک معماری مشخص تولید میشود. استفاده از ابزار دیکامپایل نامناسب برای معماری مقصد منجر به شکست فرایند خواهد شد. اگرچه معماریهای x86 و x64 در رایانههای متداول رایج هستند، اما در اکوسیستم IoT طیف گستردهای از معماریهای متفاوت مورد استفاده قرار میگیرد.
مشکلات موجود در مرحله دیساسمبلی به مراحل بعدی نیز منتقل میشوند و میتوانند باعث بروز خطا در کل فرایند دیکامپایل شوند. در مرحله تبدیل به نمایش میانی سطح بالاتر (Lifting) و تحلیل جریان داده، کد اسمبلی به یک نمایش میانی سطح بالاتر تبدیل میشود. سپس در تحلیل جریان کنترل، مسیرهای اجرای برنامه با استفاده از گرافهای جریان کنترل (Control Flow Graphs) استخراج میشوند. در نهایت، تحلیل نوع داده برای شناسایی انواع دادههای موجود در برنامه انجام میشود. هر یک از این مراحل دارای چالشها و محدودیتهای خاص خود هستند و بروز خطا در هر بخش میتواند منجر به تولید کد دیکامپایل شده نادرست یا ناقص شود. به همین دلیل، دیکامپایل برنامههای بزرگ بسیار دشوارتر است؛ زیرا بازسازی صحیح کل برنامه معمولاً امکانپذیر نیست. ازاینرو، شناسایی بخشهایی از برنامه که از اهمیت بیشتری برخوردارند، رویکردی مطلوب محسوب میشود. در این زمینه، دیباگرها (Debuggers) نقش مهمی ایفا میکنند. دیباگرها امکان مشاهده رفتار داخلی برنامه در حین اجرا را فراهم میکنند و به تحلیلگر کمک میکنند بخشهای مهمتر کد را شناسایی کند. در نتیجه، حجم کدی که نیازمند بررسی دقیق است کاهش مییابد.
بهطور کلی، دیکامپایل (Decompilation) فرایندی پیچیده است و همواره با موفقیت کامل همراه نیست. با این حال، ابزارهایی وجود دارند که عملکرد قابل قبولی در این زمینه ارائه میدهند. برخی از این ابزارها که در جدول 5 نیز معرفی شدهاند عبارتاند از: Radare2، IDA (Interactive Disassembler)، Ghidra. البته تمام این ابزارها رایگان نیستند. برای مثال، نسخه حرفهای IDA Pro هزینه بسیار بالایی دارد.
4.1.4 سایر چالشها (Other Challenges)
مسائلی که تاکنون مطرح شدند، تنها چالشهای موجود در فرایند مهندسی معکوس میانافزار نیستند. برای مثال، استفاده از بستهبندهای کد (Packers) یکی از روشهایی است که مهندسی معکوس را به فرایندی دشوار و زمانبر تبدیل میکند. در این روش، عملکرد اصلی کد بدون تغییر باقی میماند، اما ساختار و نحوه نمایش آن بهگونهای تغییر داده میشود که کد ظاهری نامفهوم و غیرقابلدرک پیدا کند. پکرها میتوانند میانافزار را رمزگذاری (Encrypt) یا مبهمسازی (Obfuscate) کنند. اگرچه این تکنیکها در اصل تأثیر مستقیمی بر تحلیل پویا (Dynamic Analysis) ندارند، اما فرایند تحلیل ایستا (Static Analysis) را بهمراتب دشوارتر میسازند [68]. بهطور سنتی، بدافزارها از پکرها برای پنهانسازی هویت خود استفاده میکنند. با این حال، تولیدکنندگان تجهیزات IoT نیز از این ابزارها بهمنظور جلوگیری از مهندسی معکوس میانافزار بهره میگیرند.
مشکل مهم دیگر، نبود فراداده (Metadata) مرتبط با فایلهای میانافزار است. در اختیار داشتن صرفِ فایل باینری کافی نیست؛ بلکه لازم است تحلیلگر بداند که چه محتوایی را باید درون آن انتظار داشته باشد. فراداده معمولاً شامل اطلاعاتی مانند: تاریخچه تغییرات (Change Log)، اطلاعات تولیدکننده، نام محصول، تاریخ انتشار، شماره نسخه است [50]. برای مثال، جهت تسهیل فرایند دیکامپایل، آگاهی از معماری سختافزاری هدفی که میانافزار برای آن کامپایل شده است ضروری است. همچنین اگر بتوان نوع کاربرد دستگاه IoT را شناسایی کرد، میتوان بهصورت شهودی درباره بسیاری از ویژگیهای آن از جمله: سیستمعامل مورد استفاده، پروتکلهای شبکه، کتابخانههای نرمافزاری، و سایر اجزای نرمافزاری استنتاجهایی انجام داد که دید مناسبی نسبت به وضعیت امنیتی دستگاه فراهم میکنند. برخی تولیدکنندگان نیز برای جلوگیری از حملات مبتنی بر سختافزار (Hardware-based Hacking)، درگاههای اشکالزدایی (Debugging Ports) را مبهمسازی (Obfuscate) یا غیرفعال میکنند [38, 42]. این موضوع نیز مانع دیگری در مسیر مهندسی معکوس محسوب میشود.
شکل 6 نمایی کلی از مسئله ناامنی میانافزار را ارائه میدهد و مهمترین عوامل مؤثر بر آن را در قالبی یکپارچه نمایش میدهد. بهطور کلی، عوامل اصلی در چهار دسته طبقهبندی شدهاند: 1. چرخه حیات توسعه میانافزار (Firmware Development Lifecycle)، 2. مهندسی معکوس (Reverse Engineering)، 3. چالشهای عمومی IoT (Generic IoT Issues) و 4. سایر عوامل (Other Issues).
4.2 تکنیکهای تحلیل (Analysis Techniques)
بهطور کلی، دو رویکرد اصلی برای کشف آسیبپذیریها در یک سامانه وجود دارد. رویکرد نخست، تزریق ورودیهای مخرب و طراحی شده به سیستم با هدف ایجاد رفتارهای غیرمنتظره است؛ رفتارهایی که میتوانند منجر به نقض امنیت سیستم شوند. این روش عموماً با عنوان فازینگ (Fuzzing یا Fuzz Testing) شناخته میشود. رویکرد دوم، استفاده از تحلیل ایستا (Static Analysis) و/یا تحلیل پویا (Dynamic Analysis) است. صرفنظر از رویکرد انتخاب شده، کشف دستی آسیبپذیریها همواره امکانپذیر نیست و حتی در صورت دستیابی به نتایج مطلوب، از منظر مقیاسپذیری راهکار مناسبی بهشمار نمیرود [71].
در این بخش از مقاله، راهکارهای موجود، روششناسیهای بهکاررفته در آنها و ابزارها یا تکنیکهای مورد استفاده برای خودکارسازی فرایند تحلیل و کشف آسیبپذیریهای امنیتی در میانافزار دستگاههای IoT و بهطور کلی سامانههای نهفته (Embedded Systems) بررسی میشوند. هدف ما مرور پژوهشهای موجود بهترتیب زمانی و با تمرکز بر دستاوردهای نسبتاً جدید است تا پژوهشگر بتواند با آخرین پیشرفتهای این حوزه آشنا شود. همچنین تلاش میکنیم تحلیلها را بهگونهای ارائه دهیم که پژوهشگران و متخصصان بتوانند از میان راهکارهای موجود، مناسبترین تکنیک را برای تحلیل جامع و مقیاسپذیر میانافزار دستگاههای IoT انتخاب کنند. اگرچه تمامی روشهای بررسیشده در این بخش الزاماً برای دستگاههای IoT طراحی نشدهاند، اما قابلیت بهکارگیری در شناسایی آسیبپذیریهای این دستگاهها را دارند. ازاینرو، تمامی ابزارها و تکنیکهای مهم تحلیل آسیبپذیری میانافزار بهصورت مختصر معرفی خواهند شد. در حوزه میانافزارهای IoT، دو رویکرد تحلیل ایستا و تحلیل پویا بیشترین کاربرد را دارند. بنابراین، پیش از معرفی تکنیکهای مبتنی بر این دو رویکرد، ابتدا مزایا و محدودیتهای هر یک در زمینه تحلیل میانافزار بررسی میشود. سپس به روشهای ترکیبی یا هیبریدی (Hybrid Approaches) و رویکردهای مبتنی بر فازینگ پرداخته خواهد شد.
4.2.1 تحلیل ایستا (Static Analysis)
بازبینی و تحلیل کد در هر سامانهای یکی از مهمترین اقدامات برای ارتقای امنیت محسوب میشود [72]. تحلیل ایستا به بررسی نرمافزار بدون اجرای واقعی آن گفته میشود [68]. از لحاظ تاریخی، تحلیل ایستا ابتدا برای شناسایی خطاهای برنامهنویسی از طریق ابزاری به نام Lint مورد استفاده قرار گرفت [73]. با گذشت زمان، کاربردهای تحلیل ایستا گسترش یافت و امروزه علاوه بر کشف خطاهای نرمافزاری، در تحلیلهای امنیتی نیز نقش مهمی ایفا میکند. یکی از مزایای اصلی تحلیل ایستا این است که برای بررسی میانافزار، نیازی به دسترسی فیزیکی به دستگاه وجود ندارد [32]. از این منظر، تحلیل ایستا راهکاری مقیاسپذیر محسوب میشود. از جمله آسیبپذیریهایی که از طریق تحلیل ایستا قابل شناسایی هستند میتوان به موارد زیر اشاره کرد: ارجاعات نامعتبر (Invalid References)، سرریز بافر (Buffer Overflow)، آسیبپذیریهای خرابی حافظه (Memory Corruption Vulnerabilities)، خطاهای قطعهبندی حافظه (Segmentation Faults)، متغیرهای مقداردهینشده (Uninitialized Variables) [74, 32].
با این حال، پیش از انجام تحلیل ایستا، دسترسی به سورسکد یا حداقل دیکامپایلکردن کد ضروری است. افزون بر این، کد دیکامپایلشده قادر به بازیابی تمامی اطلاعات موجود در نسخه اصلی برنامه نیست [68]. از سوی دیگر، انجام تحلیل ایستا بهصورت دستی فرایندی پرهزینه و زمانبر است و از این منظر ممکن است مقیاسپذیری آن زیر سؤال برود. برای رفع این مشکل، استفاده از ابزارهای خودکار تحلیل کد راهکار مناسبی بهشمار میرود. هرچند این ابزارها شناسایی خطاها را تسهیل میکنند، اما معمولاً تعداد زیادی مثبت کاذب (False Positive) تولید میکنند [32]. با این حال، بسته به نوع تحلیل ایستای مورد استفاده در ابزار (برای مثال تحلیل ایستای مبتنی بر الگو (Pattern-Based Static Analysis))، میتوان میزان این مثبتهای کاذب را تا حد زیادی کاهش داد. یکی دیگر از مزایای تحلیل ایستا آن است که میتواند تمامی بخشهای کد را بدون چشمپوشی از هیچ قسمت بررسی کند. بااینحال، زمانی که کد مبهمسازی یا رمزگذاری شده باشد، انجام تحلیل ایستا عملاً امکانپذیر نخواهد بود [58]. مناسبترین زمان برای بهرهگیری از تحلیل ایستا در زیستبوم امنیت IoT، مرحله توسعه سورسکد است؛ جایی که میتوان بیشترین بهره را از قابلیتهای امنیتی این رویکرد به دست آورد. جدول 6 مقایسهای میان تحلیل ایستا و تحلیل پویا ارائه میدهد. ستون اول، معیارهای مقایسه را نشان میدهد و ستونهای دوم و سوم توضیح میدهند که هر یک از این دو رویکرد در چه جنبههایی نسبت به دیگری برتری دارند.
راهکارهای تحلیل ایستا (Static Analysis Solutions): در سال ۲۰۱۲، گریس (Grace) یک تحلیل ایستا بر روی برنامههایی که به عنوان بخشی از فایل میانافزار رسمی اندروید (Stock Android Firmware) ارائه میشدند، انجام داد [75]. اگرچه هدف اصلی این پژوهش کشف آسیبپذیریهای میانافزار نبود، اما موفق شد در برنامههای از پیش نصب شده نشت مجوزها (Permission Leaks) را شناسایی کند. در این روش، پس از استخراج بایتکد دالویک (Dalvik Bytecode) برنامههای از پیش نصب شده، یک گراف جریان کنترل (Control Flow Graph – CFG) ساخته میشود تا با بررسی تمام مسیرهای ممکن اجرای کد، نشتهای احتمالی مجوزها شناسایی شوند. این پژوهش بر مدل امنیتی مبتنی بر مجوز اندروید استوار بود. ابزار توسعهیافته با نام Woodpecker معرفی شد، اما به دلیل بررسی تنها ۱۳ فایل میانافزار مربوط به تلفنهای اندرویدی مختلف، یک تحلیل در مقیاس بزرگ محسوب نمیشد.
در سال ۲۰۱۴، پژوهش Costin یکی از پایههای اصلی حوزه شناسایی آسیبپذیریهای میانافزار را بنا نهاد [32]. وی تحلیل ایستای گستردهای را بر روی بیش از ۳۲ هزار فایل میانافزار انجام داد. پس از تحلیل این فایلها، بیش از ۶۹۳ آسیبپذیری مختلف شناسایی شد که در میان آنها ۳۸ آسیبپذیری روز-صفر (Zero-Day) نیز وجود داشت. نتایج این پژوهش نشان داد که بیش از ۱۴۰ هزار دستگاه متصل و قابل دسترس از طریق اینترنت تحت تأثیر این آسیبپذیریها قرار دارند. در این کار، تکنیک جدیدی برای تحلیل ایستای کد ارائه نشد؛ بلکه از یک موتور همبستگی (Correlation Engine) استفاده شد تا آسیبپذیریهای کشف شده در یک دستگاه برای شناسایی همان آسیبپذیریها در سایر دستگاهها مورد استفاده قرار گیرد. همین مکانیزم همبستگی موجب مقیاسپذیری راهکار شد. برخی از آسیبپذیریهای کشف شده عبارت بودند از: دسترسی به کلیدهای RSA، فایلهای کلید مجاز SSH برای اتصال از راه دور و هش گذرواژههایی که مستقیماً در میانافزار قرار داده شده بودند.
جدول 5: ابزارهای مهندسی معکوس و تحلیل میانافزار:
جدول ۶: مقایسه روشهای تحلیل ایستا و پویا برای ارزیابی امنیت میانافزار:
ابزار Firmalice [6] که در اوایل سال ۲۰۱۵ توسط Shoshitaishvili معرفی شد، یکی دیگر از ابزارهای تحلیل باینری برای بررسی آسیبپذیریهای میانافزار دستگاههای نهفته (Embedded) است. این ابزار قادر است برنامه را به بخشهای کوچکتر (Program Slicing) تقسیم کرده و با استفاده از اجرای نمادین (Symbolic Execution) مسیرهای مختلف را برای شناسایی آسیبپذیریهای دور زدن مکانیزم احراز هویت (Authentication Bypass) بررسی کند. یکی از ویژگیهای مهم Firmalice مقیاسپذیری آن است. البته منظور از مقیاسپذیری در اینجا اجرای موازی برشهای (slice) مختلف میانافزار برای رسیدن به نقاط دارای دسترسی ویژه در کد است؛ نه تحلیل همزمان تعداد زیادی فایل میانافزار، همانند پژوهش Costin.
Firmalice را میتوان نوعی تحلیل ایستای هوشمند دانست؛ زیرا برای تشخیص اینکه یک دستور دارای سطح دسترسی ویژه است یا خیر، باید «سیاست امنیتی» دستگاه را درک کند. از دیگر مزایای آن میتوان به مستقل بودن از معماری سختافزاری اشاره کرد؛ بهطوریکه از معماریهای مختلفی از جمله ARM و PPC پشتیبانی میکند [76]. در سال ۲۰۱۶، Shoshitaishvili به همراه تیم خود ابزاری به نام ANGR [10] را توسعه داد که هم در تحلیل ایستا و هم در تحلیل پویا کاربرد دارد. امروزه بسیاری از ابزارهای تحلیل میانافزار برای انجام تحلیلهای خود از ANGR استفاده میکنند. در ادامه، در سال ۲۰۱۵ ابزار متنباز دیگری با نام PIE (Parser Identification in Embedded Systems) [9] معرفی شد که برای شناسایی مؤلفههای تجزیهکننده (Parser Components) و بخشهای پیچیده کد طراحی شده بود. پیش از انجام طبقهبندی، کد باینری میانافزار از طریق LLVM به یک زبان میانی (intermediate languag) تبدیل میشود. PIE قادر است بدون نیاز به مستندات یا سورسکد، میانافزار سیستمهای نهفته را تحلیل کند. این قابلیت اهمیت زیادی دارد؛ زیرا تنوع بالای دستگاههای نهفته و IoT, جمعآوری فرادادهها و درک محتوای تحت تحلیل را دشوار میسازد. از PIE میتوان برای موارد زیر استفاده کرد: شناسایی آسیبپذیریهای قابل اکسپلویت، استخراج مشخصات پروتکلها، کشف دستورات پنهان. این ابزار بر روی چهار دستگاه پرکاربرد شامل: GPS، کنتور برق (Power Meter)، هارددیسک (HDD)، PLC آزمایش شده و نتایج موفقیتآمیزی ارائه کرده است؛ بنابراین گزینهای مناسب برای ممیزی امنیتی میانافزار دستگاههای IoT محسوب میشود.
استفاده از گرافهای جریان کنترل (CFG) در تحلیل آسیبپذیریهای میانافزار مؤثر است، اما از نظر مقیاسپذیری محدودیتهایی دارد. در سال ۲۰۱۶، Feng و همکارانش الگوریتمی به نام Genius [77] را معرفی کردند که با ترکیب یادگیری ماشین (Machine Learning) و بینایی رایانهای (Computer Vision) تلاش میکرد مشکل مقیاسپذیری CFGها را برطرف کند. پس از آن، در سال ۲۰۱۷، Xu و همکارانش با ارائه سامانه Gemini [78] مبتنی بر شبکههای عصبی، عملکردی بهتر از Genius ارائه دادند. Gemini علاوه بر کاهش زمان آموزش، توانست تعداد بیشتری آسیبپذیری را در فایلهای میانافزار شناسایی کند. در سال ۲۰۱۹، Wang روشی دو مرحلهای برای شناسایی آسیبپذیریهای میانافزار مبتنی بر شباهت کد (Code Similarity) پیشنهاد کرد [79]. وی در مقایسه با Gemini ادعا کرد که روش پیشنهادی او هم از نظر دقت و هم از نظر کارایی عملکرد بهتری دارد.
یکی از مشکلات رایج در توسعه میانافزار، وجود اعتبارنامههای مستندسازینشده یا دربهای پشتی (Backdoors) است که معمولاً هیچ راه مستقیمی برای آگاهی از وجود آنها وجود ندارد. ابزار Stringer [59] که بر پایه تحلیل ایستای خودکار میانافزار طراحی شده، برای رفع این مشکل توسعه یافته است. Thomas و همکارانش با استفاده از Stringer موفق شدند ۷۵۹۰ فایل میانافزار را تحلیل کنند و سه درب پشتی را شناسایی نمایند که دو مورد آنها پیشتر ناشناخته بودند؛ رویههای پردازش دادههای ایستا (Static Data Processing Routines) را تشخیص دهند. مزیت اصلی این پژوهش علاوه بر سبک بودن ابزار، قابلیت استفاده در مقیاس بزرگ و کاهش نیاز به تحلیل دستی است.
همچنین Thomas در سال ۲۰۱۷ سامانه دیگری با نام HumIDIfy [35] را توسعه داد که برای شناسایی قابلیتهای مخفی و مستندسازی نشده در میانافزار طراحی شده است. این سامانه علاوه بر آن، قادر به شناسایی آسیبپذیریهای دور زدن احراز هویت نیز هست. ویژگی منحصربهفرد این پژوهش، استفاده از یادگیری ماشین برای کشف قابلیتهای پنهان است. پژوهشگران مجموعهای از پروفایلهای رفتاری مورد انتظار را با استفاده از زبانی به نام زبان توصیف قابلیتهای باینری (Binary Functionality Description Language – BFDL) ایجاد میکنند و سپس رفتار واقعی کد را با این پروفایلها مقایسه مینمایند. در صورت مشاهده اختلافات قابل توجه، احتمال وجود قابلیتهای مخفی در میانافزار مطرح میشود. برای آموزش دستهبندی نیمهنظارتی (Semi-Supervised Classifier)، از ۸۰۰ فایل میانافزار برای آموزش و ۱۰۰ نمونه برای آزمون استفاده شد که در نهایت دقتی حدود ۹۶ درصد و تقریباً بدون مثبت کاذب (False Positive) به دست آمد. با وجود نوآورانه بودن این روش، نمیتوان آن را راهکاری کامل دانست؛ زیرا به دانش تخصصی انسانی و همچنین فرادادههای میانافزار نیاز دارد. در غیر این صورت، احتمال تولید تعداد زیادی هشدار اشتباه افزایش مییابد.
در سال ۲۰۱۸، سامانه FirmUp [36] تلاش کرد آسیبپذیریها را در نسخههای جدیدتر میانافزار با استفاده از تحلیل ایستا شناسایی کند. پژوهشگران با بهرهگیری از CFGها و تکنیک Program Slicing موفق شدند ۳۴۷ آسیبپذیری در ۱۴۷ نسخه جدید میانافزار را کشف کنند. با استفاده از ابزارهایی نظیر Binwalk، IDA Pro، ANGRپدیدآورندگان ادعا کردند که نرخ شناسایی آسیبپذیری آنها بهطور میانگین ۴۵ درصد بهتر از روشهای پیشرفته موجود (State-of-the-Art) بوده است. در نهایت، در سال ۲۰۱۸، Chin-Wei Tien سامانه UFO (Universal Firmware Vulnerability Observer) [80] را معرفی کرد. UFO یک سامانه جامع کشف آسیبپذیری میانافزار است که به دلیل توانایی در مهندسی معکوس میانافزار، افشای گذرواژهها و شناسایی دربهای پشتی شهرت یافته است. این سامانه از الگوریتمی جدید به نام Shell Script Dependency (ShDep) استفاده میکند. (UFO اطمینان حاصل میکند که دستگاههای تعبیه شده اینترنت اشیا (Embedded IoT Devices) از استانداردهای امنیتی و حریم خصوصی مختص IoT مانند OWASP، [12]UL-2900 و ICSA Labs[13] پیروی میکنند).
بر اساس گزارش پدیدآورندگان، UFO توانست ۹۶ درصد از ۲۳۷ دستگاه بررسی شده را با موفقیت مهندسی معکوس کند. نتایج حاکی از آن است که بیش از ۷۰ درصد دستگاهها دارای آسیبپذیریهای رایج هستند. یکی از محدودیتهای UFO این است که در صورتی که میانافزار دارای مبهمسازی (Obfuscation) یا رمزگذاری (Encryption) باشد، قادر به انجام مهندسی معکوس فایلسیستمهای موجود در میانافزار نخواهد بود. با این حال، پدیدآورندگان ادعا میکنند که قابلیت استخراج فایلسیستم میانافزار در UFO نسبت به Firmware-Mod-Kit عملکرد بهتری دارد. در جدول ۷ مقایسهای از مهمترین تکنیکهای تحلیل مبتنی بر تحلیل ایستا ارائه شده است.
جدول 7: ارزیابی راهحلهای مبتنی بر تحلیل ایستا:
4.2.2 تحلیل پویا (Dynamic Analysis)
در بخش قبل، مزایا و قابلیتهای مختلف تحلیل ایستا (Static Analysis) مورد بحث قرار گرفت. با وجود تمامی مزایای آن، یکی از بزرگترین محدودیتهای این رویکرد آن است که بدون در اختیار داشتن دستگاه واقعی، امکان آزمایش عملی و سوءاستفاده (Exploitation) از سیستم وجود ندارد. برای رفع این محدودیت، یا باید خود دستگاه در دسترس باشد یا اینکه میانافزار با استفاده از ابزارهایی نظیر KLEE [81] یا QEMU [82] شبیهسازی (Emulate) شود. برخلاف تحلیل ایستا که در آن میانافزار تجزیه شده و کد آن مورد مطالعه قرار میگیرد، در تحلیل پویا میتوان کد را اجرا و رفتار آن را در زمان اجرا مشاهده کرد. در چنین شرایطی، الزاماً نیازی به آگاهی کامل از ساختار داخلی برنامه وجود ندارد؛ بلکه میتوان ورودیهای مختلف، حتی تصادفی، را به سیستم اعمال کرد و با مشاهده خروجیها، رفتار آن را تحلیل نمود.
با این حال، تحلیل پویای میانافزار مستلزم در اختیار داشتن فرادادههای (Metadata) مربوط به میانافزار است تا بتوان محیط اجرایی مناسبی برای شبیهسازی آن فراهم کرد. در واقع، بدون اطلاع از معماری سختافزاری و مشخصات بستر هدف، شبیهسازی بسیاری از میانافزارها امکانپذیر نیست. تحلیل پویا بهویژه در شرایط زیر کاربرد دارد: زمانی که سورسکد در دسترس نباشد؛ هنگامی که فرآیند دیکامپایل (Decompilation) موفقیتآمیز نباشد؛ برای معماریهایی که ابزار دیکامپایلر مناسبی ندارند. برای مثال، در مورد معماری Xtensa دیکامپایلر شناخته شده و کاملی وجود ندارد؛ بنابراین تحلیل پویا تنها گزینه عملی محسوب میشود. البته تحلیل پویا نیز محدودیتهای خاص خود را دارد. مهمترین محدودیت آن، مقیاسپذیری پایین در تحلیل میانافزار است؛ زیرا شبیهسازی خودکار میانافزار همواره امکانپذیر نیست و هر دستگاه ممکن است به پیکربندی اختصاصی برای شبیهسازی نیاز داشته باشد.
راهکارهای تحلیل پویا (Dynamic Analysis Solutions): FIE [83] یک ابزار متنباز (Open Source) است که در سال 2013 معرفی شد و بر پایه موتور اجرای نمادین (Symbolic Execution Engine) KLEE [81] توسعه یافته است. با این حال، FIE بهطور اختصاصی برای خانواده میکروکنترلرهای (microcontrollers) MSP430 طراحی شده است. این ابزار روی 99 فایل میانافزار مختلف از خانوادههای گوناگون MSP430 آزمایش شد. FIE بهگونهای توسعه یافته است که توجه ویژهای به مکانهای حافظه مرتبط با تجهیزات جانبی (Peripherals) و فراخوانی هندلرهای وقفه (Interrupt Handlers) داشته باشد؛ قابلیتی که امکان تحلیل انعطافپذیر رفتار تجهیزات جانبی را فراهم میکند. FIE موفق شد در میان 99 فایل میانافزار متعلق به 13 خانواده متمایز از میکروکنترلرهای MSP430، تعداد 21 خطا (Bug) را شناسایی کند.
یکی از تکنیکهای منحصربهفرد مورد استفاده در FIE، هرس وضعیت (State Pruning) است که با حذف اجرای وضعیتهای تکراری، حتی برای فایلهای میانافزار کوچک نیز کارایی تحلیل را افزایش میدهد. برای این منظور، FIE تمامی وضعیتهای تحلیلشده قبلی را ردیابی و ثبت میکند. تکنیک دیگری که در FIE به کار گرفته شده، محوشدگی حافظه (Memory Smudging) است. در این روش، FIE شمارندههای حلقه (Loop Counters) را به صورت خودکار شناسایی کرده و آنها را با متغیرهای نمادین جایگزین میکند تا پوشش کد (Code Coverage) افزایش یابد. Avatar [58] که در سال 2014 معرفی شد، چارچوبی منحصربهفرد برای انجام تحلیل پویا روی میانافزار دستگاههای نهفته است. در Avatar، دستورالعملهای میانافزار شبیهسازی میشوند، در حالی که عملیات ورودی/خروجی (I/O Operations) به سختافزار واقعی دستگاه هدایت میشوند. در نتیجه، میانافزار روی یک ماشین خارجی شبیهسازی میشود، اما همچنان با سختافزار واقعی تعامل دارد.
Avatar در سه سناریوی امنیتی مختلف به کار گرفته شده است: مهندسی معکوس (Reverse Engineering)، کشف آسیبپذیری (Vulnerability Discovery)، شناسایی دربِ پشتی (Backdoor Detection). این چارچوب روی سه کلاس مختلف از تجهیزات سختافزاری آزمایش شد که شامل یک تلفن GSM، یک بوتلودر (Bootloader) دیسک سخت و یک گره حسگر بیسیم (Wireless Sensor Node) بودند. پس از آمادهسازی اولیه، از QEMU [82] ــ که یک شبیهساز متنباز است ــ برای شبیهسازی میانافزار استفاده میشود. همچنین موتور مشهور اجرای سمبلیک KLEE قادر است مسیرهای مختلف اجرای میانافزار را برای جستجوی آسیبپذیریها بررسی کند. مشکل اصلی Avatar وابستگی آن به سختافزار واقعی برای کشف آسیبپذیریها است. از سوی دیگر، اجرای کامل فرایند از محیط شبیهساز تا سختافزار واقعی زمانبر است. بنابراین، این راهکار از مقیاسپذیری (Scalability) مناسبی برخوردار نیست. Daming در فوریه 2016، نخستین سامانه خودکار تحلیل پویای میانافزار با نام Firmadyne [50] را معرفی کرد. این سامانه بر آسیبپذیریهای میانافزارهای مبتنی بر لینوکس (Linux) در دستگاههای متصل به شبکه تمرکز دارد. Firmadyne مجموعهای شامل 23,035 فایل میانافزار را با موفقیت تحلیل کرد و توانست تأیید کند که 887 فایل میانافزار در برابر یک یا چند اکسپلویت (Exploit) آسیبپذیر هستند.
این سامانه قادر است با استفاده از اسکریپتهای نوشته شده بهصورت دستی، وبسایتهای تأمینکنندگان (Vendors) را پیمایش کرده و فایلهای میانافزار را به همراه فرادادههای (Metadata) مربوط به آنها بهصورت خودکار جمعآوری کند. در هسته این سامانه، نسخهای سفارشیسازیشده از Binwalk برای استخراج کرنل (Kernel) موجود در فایل میانافزار به کار گرفته میشود. سپس Firmadyne با استفاده از QEMU یک کرنل Linux را با تنظیمات سفارشی متناسب با میانافزار تحت تحلیل شبیهسازی میکند. در ادامه، انواع مختلفی از روشهای تحلیل پویا برای کشف و اکسپلویت آسیبپذیریها روی میانافزار شبیهسازی شده اجرا میشوند. Firmadyne همچنین از چهارچوب (Framework) مشهور Metasploit [84] برای اکسپلویت آسیبپذیریها استفاده میکند. دو بهبود مهمی که میتوان برای Firmadyne در نظر گرفت عبارتاند از 1. افزودن قابلیت تحلیل سامانههای غیر مبتنی بر Linux (برای مثال RTOSها) 2. بهبود روشهای استخراج میانافزار بهمنظور پشتیبانی از فایلهای میانافزار مبهمسازیشده (Obfuscated) و رمزگذاریشده (Encrypted).
جدول ۸: ارزیابی راهکارهای مبتنی بر تحلیل پویا:
Costin در سال 2016 پس از پژوهش خود در حوزه تحلیل ایستای میانافزار، یک چهارچوب (Framework) کاملاً خودکار برای تحلیل پویای میانافزار [37] پیادهسازی کرد. راهکار ارائهشده توسط Costin از شبیهسازی کامل سامانه (Full System Emulation) از طریق QEMU استفاده میکند و نیازی به سختافزار واقعی ندارد. هدف این تحلیل، کشف آسیبپذیریها در سامانههای مبتنی بر لینوکس (Linux) از طریق بررسی رابطهای وب نهفته (Embedded Web Interfaces) با استفاده از ابزارهایی مانند Arachni، Zed Attack Proxy (ZAP) [85]و w3af [27] بود. این پژوهش همچنین امکان استفاده از ابزارهای متداول دیگری نظیر Nmap [86] و Nessus [87] را برای اسکن و Metasploit را برای اکسپلویت آسیبپذیریها فراهم کرد. اگرچه تحلیل پویای انجام شده منجر به کشف 225 آسیبپذیری جدید در 45 فایل میانافزار مختلف شد، اما پدیدآورندگان معتقدند که هنوز ظرفیت قابل توجهی برای بهبود وجود دارد. این بهبودها میتوانند از طریق ارتقای ابزارهای تحلیل مورد استفاده و همچنین افزایش دقت شبیهسازی میانافزار حاصل شوند؛ زیرا تحلیل پویا ذاتاً با چالشهای خودکارسازی (Automation) مواجه است.
Palavicini در سال 2017، پژوهشی را روی دستگاههای اینترنت اشیاء صنعتی (Industrial Internet of Things – IIoT) با هدف کشف آسیبپذیریهای میانافزار انجام داد [88]. این پژوهش نیمهخودکار بر شناسایی آسیبپذیریها در سامانههای کنترل صنعتی متمرکز است و از مجموعهای از ابزارهای مختلف برای انجام تحلیل استفاده میکند. این کار جامع از ابزارهای تحلیل باینری (Binary Analysis) نظیر ANGR، سامانه استدلال سایبری (Cyber Reasoning System – CRS) موسوم به Mechanical Phish [89]، ابزار American Fuzzy Lop (AFL) [90] و همچنین ابزارهای مجازیسازی مانند OpenPLC [91]، Firmadyne و QEMU برای کشف آسیبپذیریها بهره میگیرد. این فرایند در سه مرحله انجام میشود: 1. استخراج بسته میانافزار (Firmware Blob) بهمنظور استخراج کد قابل شبیهسازی 2. شبیهسازی کد استخراجشده با استفاده از OpenPLC، QEMU و Firmadyne 3. تحلیل کد از طریق روشهایی نظیر فازینگ (Fuzzing) و اجرای سمبلیک (Symbolic Execution). نتیجه این تحلیل، کشف دربهای پشتی (Backdoor)، نشت اطلاعات و کدهایی بود که برای ایجاد باتنتها (Botnets) مورد استفاده قرار میگیرند.
در سال 2019 نیز چهارچوب (Framework) جدیدی با نام FIoT معرفی شد که برای شناسایی مشکلات خرابی حافظه (Memory Corruption) در میانافزار دستگاههای اینترنت اشیاء با منابع محدود طراحی شده است. FIoT از اجرای سمبلیک برای انجام آزمون فازینگ روی بخشهای منتخب میانافزار استفاده میکند تا آسیبپذیریهای مرتبط با خرابی حافظه را در معماریهای پردازنده مختلف شناسایی کند. با این حال، FIoT تنها بخشهای خاصی از کد را که احتمال ارتباط آنها با آسیبپذیریهای سرریز بافر (Buffer Overflow) وجود دارد، برش (slice) داده و تحلیل میکند. علاوه بر این، اجرای سمبلیک فرایندی پرهزینه از نظر محاسباتی است؛ بنابراین این راهکار برای فایلهای میانافزار بزرگ و پیچیده قابل استفاده نیست. پدیدآورندگان موفق شدند در 115 دستگاه کوچک اینترنت اشیاء، تعداد 35 آسیبپذیری روز صفر (Zero-Day) مرتبط با خرابی حافظه را کشف کنند. مقایسهای از مهمترین روشهای تحلیلی مبتنی بر تحلیل پویا در جدول 8 ارائه شده است.
4.2.3 تحلیل ترکیبی (Hybrid Analysis)
در این بخش، سامانههایی بررسی میشوند که برای کشف آسیبپذیریها در اینترنت اشیاء (IoT) یا سامانههای نهفته (Embedded Systems)، از هر دو روش تحلیل ایستا (Static Analysis) و تحلیل پویا (Dynamic Analysis) استفاده میکنند. در عمل، بسیاری از سامانهها ماهیتی ترکیبی دارند؛ برای مثال، پژوهش Costin [37] که در بخش پیشین بررسی شد، در واقع ترکیبی از تحلیل ایستا و تحلیل پویا را برای دستیابی به خودکارسازی کامل به کار گرفته است. با این حال، در اینجا به اختصار چند سامانه را بررسی میکنیم که از نظر ماهیت، کاملاً ترکیبی محسوب میشوند.
DroidRay [92] سامانهای است که در سال 2014 برای کشف کدها و برنامههای مخرب در میانافزار (Firmware) دستگاههای اندرویدی توسعه یافت. این سامانه روی بیش از 250 فایل میانافزار اندروید اعمال شد و نتایج نشان داد که حدود 8٪ از برنامههای از پیش نصب شده دارای نشانههای آسیبپذیر هستند و 7.6٪ از فایلهای میانافزار نیز ردپاهایی از بدافزار (Malware) را در خود دارند. پدیدآورندگان، فایلهای APK مربوط به برنامههای مختلف را هم بهصورت ایستا و هم بهصورت پویا جمعآوری کردند. در تحلیل ایستا، فایلهای APK از طریق جستجوی فایل AndroidManifest.xml از درون فایل میانافزار استخراج شدند؛ در حالی که در تحلیل پویا، میانافزار روی دستگاه اندرویدی فلش (Flash) شد و مجموعهای از دستورات برای استخراج فایلهای APK از میانافزار اجرا گردید. علاوه بر این، نشانههای این برنامهها با استفاده از تحلیل ایستا بررسی و برای شناسایی ویروسها اسکن شدند. DroidRay همچنین بهصورت ایستا دستورات iptables را جستجو میکند و به صورت پویا نیز دستور iptable-list-rules را اجرا میکند تا قوانین ترافیکی مخرب را شناسایی کند.
نمونه دیگری از تحلیل ترکیبی یا هیبریدی (Hybrid Analysis) در سال 2018 بر امنیت میانافزار دستگاههای ردیابیکننده Fitbit (Fitbit tracker firmware) انجام شد. اگرچه سامانه Fitbit شامل ابر (cloud)، برنامه کاربردی (app) و دستگاه ردیابیکننده از رمزنگاری پیشرفته بهره میبرد، اما تحلیل جامع زیستبوم Fitbit و میانافزار آن وجود چندین آسیبپذیری امنیتی را در این سامانه آشکار ساخت. در مرحله تحلیل ایستا، از IDA Pro استفاده شد و مشخص گردید که طرح رمزنگاری XTEA در حالت EAX به کار گرفته شده است. همچنین سایر پارامترهای رمزنگاری نیز مشاهده شدند که در نهایت امکان رمزگشایی موفق پیامها و حتی تولید پیامهای رمزگذاریشده همراه با کد احراز اصالت پیام (Message Authentication Code – MAC) را فراهم کردند. پدیدآورندگان توانستند بهصورت پویا پروتکل بهروزرسانی میانافزار را مورد سوءاستفاده قرار دهند و تمامی سازوکارهای امنیتی دستگاه، از جمله رمزنگاری و احراز هویت، را غیرفعال کنند. در سال 2019، پژوهش [31] از چهارچوب (Framework) خودکار تشخیص آسیبپذیری AutoDES استفاده کرد و با اکسپلویت آسیبپذیریهای شناسایی شده، نتایج آن را اعتبارسنجی نمود. پدیدآورندگان، مقایسهای میان AutoDES و Mechanical Phish ارائه کردهاند و ادعا میکنند که AutoDES از نظر کارایی، زمانبندی منابع، تشخیص آسیبپذیری و بهرهبرداری از آنها (Vulnerability Exploitation) عملکرد بهتری دارد.
4.2.4 روشهای مبتنی بر فازینگ (Fuzzing Based Techniques)
در سالهای اخیر، فازینگ (Fuzzing) توجه پژوهشگران را بهعنوان روشی برای کشف آسیبپذیریهای میانافزار اینترنت اشیاء به خود جلب کرده است. جدول 9 روند روبهرشد استفاده از روشهای مبتنی بر فازینگ را در سالهای اخیر نشان میدهد. در ادامه، برخی از مهمترین این روشها بررسی میشوند.
IoTFuzzer [38] یکی از این چهارچوبها (Framework) است که در سال 2018 معرفی شد و بر این ایده استوار است که برای یافتن آسیبپذیریهای میانافزار اینترنت اشیاء باید برنامههای کاربردی مرتبط با آن مورد فازینگ قرار گیرند. IoTFuzzer با استفاده از رویکرد جعبهسیاه (Black-Box) و از طریق فازینگ هدایتشده مبتنی بر پروتکل (Protocol-Guided Fuzzing)، آسیبپذیریهای احتمالی ناشی از خرابی حافظه (Memory Corruption) را در دستگاههای اینترنت اشیاء شناسایی میکند. این فرایند از طریق ارسال پیامهای پیامهای اکتشافی یا کاوشگر (Probing Messages) از سوی برنامههای کاربردی تلفن همراه مرتبط با دستگاههای اینترنت اشیاء انجام میشود. نمونه اولیه توسعهیافته، یک فازر (Fuzzer) خودکار است که هنگام آزمایش روی 17 دستگاه واقعی، موفق به کشف 15 آسیبپذیری شد که 8 مورد از آنها پیشتر ناشناخته بودند.
این چهارچوب (Framwork) در دو مرحله عمل میکند. مرحله نخست به درک و تحلیل برنامههای موبایلی مرتبط با دستگاههای اینترنت اشیاء اختصاص دارد. در مرحله دوم، فازینگ مستمر از طریق ارسال پیامهای آزمون به دستگاه اینترنت اشیاء انجام میشود. دستگاه بهصورت پویا از نظر وقوع کرش (Crash) پایش میشود و پیامهای خرابی حاصل از دستگاه، ثبت و گزارش میگردند. Zheng یک فازر جعبه خاکستری (Grey-Box Fuzzer) با نام Firm-AFL [93] پیادهسازی کرد که از کتابخانه POSIX پشتیبانی میکند. این فازر میانافزار اینترنت اشیاء با استفاده از روشی موسوم به شبیهسازی تقویتشده فرایند (Augmented Process Emulation)، توان عملیاتی (Throughput) بالاتری را فراهم میکند. با این حال، Firm-AFL بر پایه AFL و Firmadyne توسعه یافته است؛ به این معنا که هر میانافزاری که توسط Firmadyne قابل شبیهسازی نباشد، با Firm-AFL نیز قابل فازینگ نخواهد بود. با وجود این محدودیت، Firm-AFL توانایی مؤثری در کشف آسیبپذیریهای روز یکم (One-Day) و روز صفر (Zero-Day) دارد. اگرچه این سامانه از معماریهای MIPS و ARM پشتیبانی میکند، اما تنها برای سیستمعاملهای مبتنی بر POSIX قابل استفاده است.
جدول 9: روند روبهرشد راهکارهای مبتنی بر فازینگ (Fuzzing) در سالهای اخیر:
جدول 10. مقایسه و ارزیابی راهکارهای تحلیل ایستا و پویا بر اساس پوشش آسیبپذیریها، پلتفرمهای اجرایی و معماریهای پشتیبانی شده:
FIRMCORN [41] در سال 2020، به عنوان ابزاری برای انجام آزمون فازینگ روی میانافزار اینترنت اشیاء با هدف کشف آسیبپذیریها معرفی شد. پدیدآورندگان یک سازوکار فازینگ مبتنی بر آسیبپذیری (Vulnerability-Oriented Fuzzing) توسعه دادهاند که از یک الگوریتم جستجوی کد آسیبپذیر برای شناسایی آسیبپذیریهای موجود در میانافزار اینترنت اشیاء استفاده میکند. علاوه بر این، آنها یک روش اجرای مجازی بهینهسازیشده (Optimized Virtual Execution) پیشنهاد کردهاند تا با ناپایداریها و خطاهای موجود در فرایند شبیهسازی مقابله شود. FIRMCORN از Unicorn Engine [94] استفاده میکند و از چهار معماری شامل x86 32، x86 64، ARM 32و MIPS 32 پشتیبانی میکند. با وجود این، پشتیبانی آن تنها به میانافزارهای مبتنی بر لینوکس (Linux) محدود است. پدیدآورندگان ادعا میکنند که FIRMCORN قادر است طی دو ساعت، دو آسیبپذیری روز صفر را در یک میانافزار مشخص شناسایی کند. با این حال، چالشهای ذاتی مقیاسپذیری (Scalability) که در تحلیل پویا وجود دارند، همچنان یکی از موانع اصلی روشهای مبتنی بر فازینگ باقی خواهند ماند.
4.3 بحث و بررسی (Discussion)
شکل ۷ تعداد راهکارهای ارائهشده از سال ۲۰۱۴ تاکنون را نشان میدهد. با این حال، بیشتر این راهکارها بهطور تخصصی برای تحلیل میانافزار اینترنت اشیاء توسعه یافتهاند و نه برای تحلیل عمومی نرمافزارها. همچنین تعداد راهکارهایی که از تکنیکهای یادگیری ماشین (Machine Learning – ML) استفاده میکنند تا بتوانند بهمرور زمان تکامل یابند نیز نشان داده شده است. علاوه بر این، جدول 10 بهمنظور مشخص کردن راهکارهای موجود برای هر دسته از آسیبپذیریها، به همراه پلتفرمها (Platforms) و معماریهای پشتیبانی شده توسط آنها ارائه شده است. تحلیل دقیق دادهها ما را به نتایج زیر رسانده است:
- بیشتر راهکارها بر تحلیل ایستا (Static Analysis) متکی هستند تا تحلیل پویا (Dynamic Analysis)، زیرا تحلیل پویا وابستگی شدیدی به سختافزار دارد [56]. با این حال، در سالهای اخیر روند روبهرشدی در توسعه راهکارهای مبتنی بر فازینگ (Fuzzing) مشاهده میشود. برخی نمونهها عبارتاند از [111]، [107]، [114]، [117]، [126]، [127]، [41]، [93]، [38]، [98]، [101] و [128]. این موضوع نشان میدهد که میتوان با بهرهگیری از راهکارهای موجود، چارچوبهایی توسعه داد که طیف گستردهای از دستههای مختلف آسیبپذیریها را پوشش دهند.
- با وجود اینکه تعداد دستگاههای مبتنی بر لینوکس در سالهای اخیر نسبتاً کاهش یافته است، اغلب راهکارها برای پلتفرم لینوکس توسعه داده شدهاند. با این حال، همچنان نیاز به توسعه راهکارهایی برای میانافزارهای Bare-Metal(میانافزارهایی که هیچگونه سیسامعاملی ندارند و مستقیماً روی سختافزار اجرا میشوند) و میانافزارهای مبتنی بر ویندوز وجود دارد.
- اگرچه اغلب راهکارها از معماریهای ARM و MIPS پشتیبانی میکنند، برای سایر معماریها نیز پشتیبانیهایی ارائه شده است. با این وجود، راهکارهای مختلف که از معماریهای متفاوت پشتیبانی میکنند، دستههای متفاوتی از آسیبپذیریها را پوشش میدهند؛ بنابراین، همه راهکارهای مناسب لزوماً در برابر یک آسیبپذیری خاص مؤثر نیستند. ازاینرو، با توجه به تنوع بسیار زیاد معماریها و سکوهای مورد استفاده در اینترنت اشیاء، نمیتوان تنها به یک راهکار برای تمامی دستگاهها اتکا کرد.
- توجه ویژهای، تمرکز قابل توجهی به برخی دستههای آسیبپذیری مانند دور زدن احراز هویت (Authentication Bypass)، خرابی حافظه (Memory Corruption) و اعتبارنامههای کدگذاریشده درون برنامه (Hard-Coded Credentials) شده است. اما برخی دستههای دیگر نظیر پیکربندیهای نادرست (Misconfigurations)، دادههای آلوده (Tainted Data)، مسائل مربوط به انطباق (Compliance Issues) و شناسایی مکانیزمهای آسیبپذیر بهروزرسانی، کمتر مورد توجه قرار گرفتهاند. افزون بر این، بیشتر پژوهشهای موجود مبتنی بر اقدامات واکنشی (Reactionary Measures) هستند و راهبرد پیشگیرانه (Proactive Strategy) مشخصی ارائه نشده است. این مسئله یکی از دلایل محدود بودن تعداد راهکارهای قادر به کشف آسیبپذیریهای روز صفر (Zero-Day) است.
- تمامی دستهها و زیرمجموعههای آسیبپذیریها در دامنه پوشش هر راهکار قرار نمیگیرند. به عنوان مثال، آسیبپذیریهای برنامههای کاربردی وب بسیار متنوع هستند و ابزارها و روشهای مبتنی بر تحلیل ایستا تنها بخشی از این آسیبپذیریها را شناسایی میکنند.
- طیف گستردهای از روشها برای تحلیل میانافزار مورد استفاده قرار میگیرند؛ از جمله پروفایلسازی توابع (Function Profiling)، برش برنامه (Program Slicing)، تحلیل روابط میان اسکریپتهای شل (Shell Scripts)، شبیهسازی قطعهکدها (Code Snippets Emulation) و شبیهسازی تقویت شده فرایند (Augmented Process Emulation).
- مقیاسپذیری (Scalability) در بسیاری از راهکارها یک چالش جدی محسوب میشود. این راهکارها یا زمانبر هستند، یا منابع زیادی مصرف میکنند، یا برای انجام تحلیل به مداخله انسانی نیاز دارند. همچنین در حوزه شبیهسازی، هنوز راهکاری ایدهآل برای شبیهسازی خودکار طیف متنوعی از فایلهای میانافزار وجود ندارد.
- بیشتر راهکارها، انعطافپذیری محدودی دارند؛ یعنی تنها یک دسته یا زیردسته خاص از آسیبپذیریها را پوشش میدهند. البته برخی راهکارها مانند [129] و [77] به دلیل روششناسی اتخاذ شده قادر به شناسایی تعداد زیادی از آسیبپذیریها هستند. با این حال، هر دوی این راهکارها مبتنی بر تحلیل ایستا هستند و تحلیل ایستا همواره با احتمال تولید مثبت کاذب (False Positive) همراه است.
- استفاده از فناوریهایی مانند هوش مصنوعی (Artificial Intelligence – AI) و یادگیری ماشین بسیار محدود است. بنابراین، دستیابی به خودکارسازی گسترده و قابلیت خودبهبوددهی (Self-Improvement) در این حوزه هنوز امکانپذیر نشده است.
بدیهی است که توسعه یک راهکار کاملاً ایدهآل امکانپذیر نخواهد بود. با این حال، ایجاد چارچوبی که بتواند مسیر تکامل بهسوی یک راهکار ایدهآل را هموار کند، بسیار ارزشمند خواهد بود. در بخش بعدی، مسائل باز پژوهشی را بررسی میکنیم که پژوهشگران میتوانند برای تسهیل توسعه یک راهکار نزدیک به ایدهآل روی آنها تمرکز کنند.
جدول ۱۱: مسائل پژوهشی باز:
5. مسائل باز پژوهشی (Open Research Issues)
این بخش موانعی را بررسی میکند که روند پیشرفت در حوزه امنیت میانافزار را کُند کردهاند. از دیدگاهی دیگر، میتوان این موانع را فرصتهایی برای جامعه پژوهشی و/یا توسعهدهندگان متنباز در نظر گرفت. رفع این موانع در نهایت مسیر توسعه یک راهکار جامع و چندمنظوره برای تحلیل میانافزار اینترنت اشیاء را هموار خواهد کرد. در ادامه، فهرستی از مسائل باز پژوهشی ارائه میشود که مطابق جدول 11 دستهبندی شدهاند.
5.1 چارچوب یکپارچه ممیزی میانافزار (Unified Firmware Auditing Framework)
در این مقاله راهکارهای متعددی بررسی شدهاند، اما اغلب آنها تنها زیرمجموعه یا دسته خاصی از آسیبپذیریهای میانافزار را پوشش میدهند. پژوهشهای آینده باید بهجای توسعه راهکارهای منفرد، بر توسعه چارچوبهایی متمرکز شوند که این راهکارها بتوانند به عنوان اجزای آن عمل کنند. نمونههای مطلوب چنین چارچوبهایی را میتوان در [30]، [130] و [31] مشاهده کرد. توسعه یک چارچوب خودتکاملیابنده (Self-Evolving)، توسعهپذیر (Extendable)، مستقل از پلتفرم (Platform-Independent) و خودکار، فرایند ممیزی، آزمون و اعتبارسنجی میانافزار را برای تولیدکنندگان اینترنت اشیاء تسهیل خواهد کرد. چنین چارچوبی باید بهطور همزمان از تحلیل ایستا و تحلیل پویا پشتیبانی کند و مستقل از پلتفرم باشد. همچنین ماژولار (Modular) کردن چهارچوب (Framework) ممیزی بر اساس دستههای مختلف دستگاههای اینترنت اشیاء [131] یا پلتفرم مختلف، میتواند ایده مناسبی باشد. بدیهی است که این چارچوب باید قابلیت ممیزی جنبههای سختافزاری، میانافزار و ارتباطات دستگاههای اینترنت اشیاء را از منظر انطباق، پیکربندی و خطاهای پیادهسازی داشته باشد.
5.2 پشته یکپارچه میانافزار (Unified Firmware Stack)
امنیت و ناامنی میانافزار زمانی دگرگون خواهد شد که یک پشته (Stack) یکپارچه و مستقل از ماشین برای توسعه میانافزار ایجاد شود و توسط تولیدکنندگان دستگاههای اینترنت اشیاء مورد استفاده قرار گیرد. حتی اگر پشته جدیدی توسعه داده نشود و تنها از پشتههای پشتیبانی شده موجود، مانند رابط یکپارچه توسعهپذیر میانافزار (Unified Extensible Firmware Interface – UEFI)، استفاده شود، باز هم میتواند امنیت میانافزار را به میزان چشمگیری افزایش دهد. برای مثال، مطالعات موجود نشان میدهند که درباره استفاده از UEFI در دستگاههای اینترنت اشیاء برداشتهای نادرستی وجود دارد و توسعهدهندگان [12]میانافزار اینترنت اشیاء میتوانند به این فناوری اعتماد کنند [132]. با این وجود، طراحی یک پشته میانافزار اختصاصی برای اینترنت اشیاء و نیازهای آینده آن همچنان ضروری است.
5.3 خودکارسازی مهندسی معکوس (Automation of Reverse Engineering)
همانگونه که پیشتر اشاره شد، مهندسی معکوس مهارتی است که در طول زمان کسب میشود. انجام تحلیل در مقیاس بزرگ تنها زمانی امکانپذیر خواهد بود که سطح مناسبی از خودکارسازی حاصل شود. یکی از حوزههایی که میتواند نقش مهمی در این زمینه ایفا کند، یادگیری ماشین (Machine Learning – ML) است. افزودن یک لایه یادگیری ماشین به فرایند مهندسی معکوس میتواند با برقراری ارتباط میان اجزای مختلف اطلاعات، وظیفه تحلیل را برای انسان سادهتر کند. بهطور خاص، ML میتواند از طریق یادگیری، مسائل مشابه را در معماریهای مختلف شناسایی کند. افزون بر این، قادر است میانافزارها را بهصورت جامع آزمون کرده و خطاهای انسانی را کاهش دهد.
5.4 گسترش پشتیبانی شبیهسازی برای معماریهای بیشتر (Emulation Support for Additional Architectures)
همانگونه که پیشتر بیان شد، تحلیل ایستا ممکن است تعداد زیادی مثبت کاذب تولید کند و در عین حال برخی آسیبپذیریها را که تنها در تحلیل پویا قابل کشف هستند نادیده بگیرد. همانطور که در بخش 4 مشاهده شد، تعداد راهکارهای مبتنی بر تحلیل ایستا بسیار بیشتر از راهکارهای مبتنی بر تحلیل پویا است. دلیل اصلی این مسئله پیچیدگی ذاتی و محدودیت پشتیبانی از شبیهسازی در معماریهای مختلف در رویکرد پویا است. ازاینرو، انجام پژوهشهایی برای گسترش QEMU یا ابزارهای مشابه به منظور پشتیبانی از تعداد بیشتری از معماریهای پردازنده ضروری است.
5.5 بهبود شبیهسازیها (Improved Emulations)
شبیهسازی همواره بدون نقص نیست. برای مثال، ممکن است شبیهسازیها به دلیل در دسترس نبودن پارامترهای NVRAM دچار شکست شوند [38]. بنابراین، علاوه بر افزودن پشتیبانی از پلتفرمهای بیشتر، ارتقای عملکرد و قابلیت اطمینان روشهای شبیهسازی موجود نیز ضروری است. به عنوان نمونه میتوان به FEMU اشاره کرد که یک چارچوب شبیهسازی ترکیبی برای FPGA (Field-Programmable Gate Array) است و میتواند در حین شبیهسازی سامانه، خطاها را شناسایی و اصلاح کند.
5.6 پشتیبانی از دیکامپایل برای تمامی معماریها (Decompiling Support for All Architectures)
برای برخی معماریهای پردازنده هنوز دیکامپایلر (Decompiler) مناسبی وجود ندارد. برای مثال، Xtensa یکی از معماریهایی است که از پشتیبانی مطلوب دیکامپایلرها و دیباگرها (Debuggers) برخوردار نیست.
5.7 ابزارهای بهتر (Better Tools)
در این مقاله و همچنین مقالات ارجاع شده، ابزارهای متعددی مورد بررسی قرار گرفتهاند. با این حال، بسیاری از این ابزارها با محدودیتها و مشکلات مختلفی مواجه هستند. برخی از این ابزارها عملکرد مورد انتظار را ارائه نمیکنند. برخی دیگر اساساً برای دستگاههای نهفته یا اینترنت اشیاء طراحی نشدهاند [37]. همچنین بعضی ابزارها دیگر پشتیبانی نمیشوند؛ مانند Firmware Analysis ToolKit. علاوه بر این، برخی ابزارها نظیر FRAK و Firmalice صرفاً در قالب نام یا چارچوب پژوهشی معرفی شدهاند و پدیدآورندگان آنها هیچ ابزار اجرایی یا سورسکدی منتشر نکردهاند. از سوی دیگر، برخی ابزارهای قدرتمند مانند IDA Pro بسیار گرانقیمت بوده و متنباز نیستند افزون بر این، مهندسی معکوس فعالیتی نیست که تنها با یک ابزار انجام شود؛ بلکه مستلزم استفاده ترکیبی از مجموعهای از ابزارهای غنی از قابلیتهای مختلف است. فارغ از تمامی این چالشها، حتی ابزارهایی که مفید تلقی میشوند نیز به دلیل تنوع بسیار زیاد دستگاههای اینترنت اشیاء، ممکن است نرخ بالایی از مثبت کاذب (False Positive) و منفی کاذب (False Negative) داشته باشند [85]. بنابراین، برای استخراج، درک، کالبدشکافی و تحلیل فایلهای میانافزار بهمنظور شناسایی آسیبپذیریها، لازم است تلاش بیشتری برای بهبود ابزارهای موجود و توسعه ابزارهای جدید جهت پوشش شکافهای فعلی صورت گیرد.
5.8 گردآوری فراداده (Metadata Collection)
تمامی میانافزارهایی که از تأمینکنندگان (Vendors) دریافت میشوند، لزوماً همراه با فراداده (Metadata) مرتبط خود ارائه نمیشوند. بااینحال، فراداده یکی از عوامل اساسی در تحلیل میانافزار محسوب میشود. پژوهشگران و توسعهدهندگان باید بر گردآوری فراداده تمرکز کنند؛ زیرا این اطلاعات نهتنها تحلیل ایستا (Static Analysis) و تحلیل پویا (Dynamic Analysis) را تسهیل میکنند، بلکه با هدایت فرآیند تحلیل به سمت شناسایی آسیبپذیریهای متداول، میتوانند زمان کلی تحلیل را نیز کاهش دهند. برای مثال، میتوان ابزاری توسعه داد که با دریافت یک میانافزار بهعنوان ورودی، فراداده مرتبط با آن را استخراج و ارائه کند. چنین ابزاری میتواند بهصورت خودکار به وبسایت اصلی تأمینکننده مراجعه کند یا با کاوش در ساختار داخلی خود میانافزار، اطلاعات موردنیاز را جمعآوری نماید. بهطور کلی، نیاز مبرمی به یک پایگاه داده عمومی از میانافزارها به همراه فراداده آنها وجود دارد تا پژوهشگران و متخصصان امنیت بتوانند از این اطلاعات بهرهمند شوند و در عین حال دانش و تجربیات خود را نیز برای کمک به تولیدکنندگان به اشتراک بگذارند.
5.9 بهروزرسانی امن میانافزار (Secure Firmware Update)
سازمانهای برجسته امنیت اینترنت اشیاء از جمله آژانس امنیت سایبری اتحادیه اروپا (European Union Agency for Cybersecurity – ENISA) [133]، OWASP، IoTSFو Symantec[13]، بهروزرسانی امن میانافزار اینترنت اشیاء را یکی از مهمترین ارکان امنیت اینترنت اشیاء میدانند و آن را بهشدت توصیه میکنند. پروتکلهای متعددی برای بهروزرسانی امن اینترنت اشیاء پیشنهاد شدهاند که از جمله آنها میتوان به استاندارد SUIT متعلق به IETF [134] و سایر راهکارهای مطرحشده [14]در [135, 136, 137, 138, 139] اشاره کرد. اگرچه طراحی و استفاده از یک سازوکار اختصاصی و امن برای بهروزرسانی ایده مناسبی است، اما وجود یک چارچوب استاندارد برای بهروزرسانی میانافزار میتواند یکی از بزرگترین بردارهای حمله (Attack Vector) در زیستبوم اینترنت اشیاء را مسدود کند [22]. جامعه پژوهشی میتواند این شکاف را با ارائه یک سازوکار بهروزرسانی پوشش دهد که برای طیف گستردهای از دستگاههای اینترنت اشیاء قابل استفاده باشد، از معماریهای مختلف پشتیبانی کند و در عین حال انعطافپذیری لازم برای بهروزرسانی بخشی یا کامل مؤلفههای میانافزار را فراهم سازد.
5.10 بررسی میانافزارهای غیر مبتنی بر لینوکس (Investigate Non-Linux Firmware)
بخش عمده پژوهشهای انجامشده در حوزه تحلیل میانافزار بر سامانههای مبتنی بر لینوکس متمرکز بودهاند. دسترسپذیری ابزارهای رایگان و متنباز برای میانافزارهای لینوکسی، شناخت گسترده از لینوکس، محبوبیت آن و سهم قابلتوجه این سیستمعامل در بازار میانافزار [140]، در کنار پیچیدگی تحلیل میانافزارهای غیرلینوکسی، موجب شده است که توجه کمتری به این دسته از میانافزارها معطوف شود. با وجود این، بخش بزرگی از میانافزارها همچنان بر پایه سامانههای غیرلینوکسی توسعه یافتهاند. ازاینرو، لازم است برای میانافزارهای مبتنی بر سایر سیستمعاملها یا سامانههای فاقد سیستمعامل، پژوهشهایی بهمنظور ابداع روشهای جدید برای شناسایی و رفع آسیبپذیریها انجام شود. در این مسیر، درک رفتار معماری دستگاه، تحلیل قالب و فرآیند استخراج (Unpacking) اجزای میانافزار و در نهایت شناخت رفتار کد میتواند به حل این مسئله کمک کند. با این حال، این موضوع همچنان چالشی جدی محسوب میشود؛ زیرا توسعه چنین سامانههایی فاقد استانداردسازی مشخص است و عمدتاً به رویکرد توسعهدهنده یا تولیدکننده وابسته است.
5.11 سیستمعاملهای اختصاصی اینترنت اشیاء (IoT Specific Operating Systems)
رشد شتابان تعداد دستگاههای اینترنت اشیاء موجب شده است که توسعه سیستمعاملهای کاملاً اختصاصی برای این حوزه با چالشهای جدی مواجه شود. ازاینرو، بسیاری از دستگاههای اینترنت اشیاء در حال حاضر از نسخههای سبکسازیشده یا سفارشیشده سیستمعاملهایی بهره میبرند که در اصل برای کاربردها و محیطهای دیگری طراحی شدهاند. Embedded Linux و VxWorks نمونههایی از این دسته هستند. در مقابل، تعدادی سیستمعامل نیز بهطور ویژه برای اینترنت اشیاء توسعه یافتهاند؛ از جمله: Contiki، Android Things، LiteOS. با توجه به گستردگی طیف منابع سختافزاری در دستگاههای اینترنت اشیاء و تنوع ذاتی آنها، لازم است سیستمعاملهای امن و متنوعی متناسب با نیازهای مختلف طراحی و توسعه یابند. در عمل، استفاده از یک سیستمعامل واحد برای دستگاههای بسیار محدود اینترنت اشیاء و همچنین درگاههای اینترنت اشیاء (IoT Gateways) همواره امکانپذیر نیست. افزون بر این، باید هماهنگی و همسویی مناسبی میان طراحی سیستمعامل، طراحی میانافزار و استانداردهای مربوطه برقرار باشد.
6. توصیهها (Recommendations)
پرداختن به مسائل پژوهشی مطرحشده میتواند در بلندمدت به ارتقای امنیت میانافزار اینترنت اشیاء کمک کند. بااینحال، در این بخش مجموعهای از پیشنهادها و اقدامات عملی ارائه میشود که تولیدکنندگان و سایر ذینفعان میتوانند برای توسعه میانافزاری امن و مقاوم از آنها بهره ببرند. فهرست توصیههای مؤثر به شرح زیر است:
- انتخاب سیستمعامل یکی از تصمیمهای حیاتی در طراحی یک دستگاه اینترنت اشیاء است. بنابراین این انتخاب باید بر مبنای معیارهای فنی مشخص انجام شود و نه بهصورت تصادفی. به گفته افضل (Afzal)، انتخاب سیستمعامل باید بر اساس معماری سختافزاری زیربنایی صورت گیرد [141]. توسعهدهندگان میتوانند با انجام نگاشت ویژگیها (Feature Mapping) برای هر سیستمعامل، گزینه بهینه را انتخاب کنند. از جمله این ویژگیها میتوان به موارد زیر اشاره کرد: ارتباط میانفرآیندی (Inter-Process Communication)، بهرهوری انرژی، مقاومت در برابر خطاها، امنیت، حریم خصوصی. انتخاب صحیح سیستمعامل امکان بهرهبرداری حداکثری از سختافزار را فراهم میکند و دسترسی به SDKها و درایورهای موردنیاز برای توسعه و پشتیبانی را تسهیل میسازد. افزون بر این، حذف کتابخانهها و بستههای غیرضروری نیز میتواند احتمال سوءاستفاده از آسیبپذیریهای بالقوه را کاهش دهد.
- برای بهرهگیری حداکثری از ظرفیت جامعه پژوهشی و همسو شدن با رویکرد نوین زیستبومهای مشارکتی، انتشار عمومی میانافزار دستگاههای اینترنت اشیاء اقدامی مثبت خواهد بود [15][51] انتشار سورسکد و طراحی میانافزار موجب مشارکت بیشتر پژوهشگران و توسعهدهندگان شده و مسیر استانداردسازی پشتههای میانافزار را هموار میکند.
- میتوان از فناوری بلاکچین (Blockchain) برای شناسایی دستکاری میانافزار اینترنت اشیاء استفاده کرد.
- از آنجا که مهاجمان قادرند میانافزار را از راه دور تغییر دهند، ذخیره فراداده میانافزار به همراه جمعآزما (Checksum) آن در بلاکچین (Blockchain) میتواند برای تشخیص دستکاری میانافزار مورد استفاده قرار گیرد [142]. اگرچه فناوری بلاکچین در حوزه بهروزرسانی میانافزار مورد توجه قرار گرفته است [143]، اما تاکنون برای بسیاری از کاربردهای دیگر بهصورت گسترده آزمایش نشده است.
- تولیدکنندگان اصلی تجهیزات (Original Equipment Manufacturers – OEMs) و تولیدکنندگان طرح اصلی (Original Design Manufacturers – ODMs) میتوانند با پایبندی به پروتکلهای استاندارد امنیتی و استفاده از پایگاه کدهای نرمافزاری بهروز، دستگاههای اینترنت اشیاء ایمنتری تولید کنند. برای نمونه، همانگونه که پیشتر اشاره شد، استفاده از رابط توسعهپذیر یکپارچه میانافزار (Unified Extensible Firmware Interface – UEFI) میتواند بدون تأثیر منفی بر عملکرد و نیازمندیهای حافظه، امنیت را افزایش دهد. علاوه بر این، بهرهگیری از پروتکلهای کنترل دسترسی میاندامنهای (Cross-Domain Access Control – CDAC) مانند Shibboleth [144]، xDAuth [145] و OAuth [146] میتواند امنیت دستگاههای اینترنت اشیاء را بهطور چشمگیری ارتقا دهد [147].
- بهروزرسانی میانافزار باید از طریق سازوکارهای امن بهروزرسانی از راه دور (Over-The-Air Updates – OTA) انجام شود. همچنین باید از وجود رابطهای سختافزاری غیرضروری که امکان استخراج یا تخلیه کد (Code Dumping) را فراهم میکنند، جلوگیری شود.
- کد باید در طول توسعه و پیش از انتشار، با استفاده از ابزارهای تخصصی کشف آسیبپذیری بهطور مناسب تست شود. برای مثال، ابزار Flawfinder میتواند برای شناسایی مشکلات امنیتی احتمالی در کدهای /C++C مورد استفاده قرار گیرد. همچنین تولیدکنندگان میتوانند مطابق شکل 8، تحلیل ایستا و تحلیل پویا را بهصورت مؤثرتری در چرخه عمر توسعه میانافزار اینترنت اشیاء به کار گیرند. بهطور مشخص: تحلیل ایستا در مرحله توسعه [72] و تحلیل پویا پس از تکمیل محصول و برای اعتبارسنجی و آزمون مورد استفاده قرار گیرد. همانگونه که در شکل نشان داده شده است، با نزدیک شدن به پایان مرحله توسعه، میزان استفاده از تحلیل ایستا و پویا باید افزایش یابد.
علاوه بر موارد فوق، توجه به نقش بازیگران مختلف در توسعه یک سامانه اینترنت اشیاء اهمیت فراوانی دارد. شکل 9 نشان میدهد که چگونه برخی از بازیگران کلیدی میتوانند اقداماتی مؤثر برای رفع آسیبپذیریهای شناختهشدهای که پیشتر مطرح شدند انجام دهند. ما معتقدیم طراحان فناوری، تولیدکنندگان و نهادهای قانونگذار مسئولیت بزرگی در بهبود زیستبوم کلی اینترنت اشیاء بر عهده دارند. همچنین سایر ذینفعان، از جمله سرمایهگذاران، میتوانند با اختصاص زمان بیشتر به شرکتها برای توسعه محصولات با سطح امنیت بالاتر، نقش مهمی در ارتقای امنیت ایفا کنند.
7. نتیجهگیری (Conclusion)
گسترش روزافزون استفاده از دستگاههای اینترنت اشیاء برای تسهیل زندگی روزمره و تحقق خودکارسازی، روندی اجتنابناپذیر به نظر میرسد. بااینحال، بهرهبرداری ایمن و روزمره از این دستگاهها مستلزم برخورداری از سطح مناسبی از امنیت است. ارتقای امنیت میانافزار اینترنت اشیاء میتواند نوعی تضمین واقعی در برابر حملات متداول علیه این دستگاهها فراهم کند. در این مقاله، مجموعهای از مفاهیم مهم ارائه شد که اهمیت امنیت میانافزار را برجسته میکنند. بهویژه، برخی از نقاط حساس در طراحی و توسعه میانافزار که منجر به ناامنی دستگاههای اینترنت اشیاء میشوند مورد بررسی قرار گرفتند.
علاوه بر این، چالشهای موجود در انجام تحلیل جامع امنیت میانافزار تشریح شد. همچنین نقاط قوت و ضعف راهکارهای موجود ارزیابی شدند و نتیجه گرفته شد که نیاز مبرمی به یک چهارچوب (Framework) جامع و چندمنظوره برای ممیزی میانافزار اینترنت اشیاء وجود دارد. اگرچه توصیههای مهمی برای تولیدکنندگان، توسعهدهندگان، یکپارچهسازان و سایر ذینفعان ارائه شد، اما باور داریم که استانداردسازی میتواند بخش قابلتوجهی از خلأهای امنیتی موجود در میانافزار اینترنت اشیاء را برطرف کند. این پژوهش مبانی مستحکمی را برای توسعه چهارچوبی (Framework) فراهم کرده است که بتواند میانافزار اینترنت اشیاء را در برابر دستههای مختلف آسیبپذیریهای امنیتی ممیزی کند. برنامههای آتی ما شامل توسعه چهارچوبی (Framework) خواهد بود که نهتنها برنامههای کاربردی دستگاه اینترنت اشیاء، بلکه سختافزار و پروتکلهای اتصال شبکه آن را نیز مورد ممیزی و ارزیابی قرار دهد.
ارجاعات:
[1] LOJAX First UEFI rootkit found in the wild, courtesy of the Sednit group, https://www.welivesecurity.com/wp-content/uploads/2018/09/ESET-LoJax.pdf
[2] Getting a handle on firmware security, https://uefi.org/sites/default/files/resources/Getting%20a%20Handle%20on%20Firmware%20Security%2011.11.17%20Final.pdf
[3] Coreboot firmware https://coreboot.org/
[4] 82017 Study on Mobile and Internet of Things Application Security, https://www.ponemon.org/local/upload/file/Arxan% 20Report%20Final%205.pdf
[5] 9Firmware Revision History |Wireless Firmware: Current Products |Firmware, https://www.lectrosonics.com/Support/ Firmware-Lookup/firmware-lookup-directory.html
[6] 0IoT threats: Explosion of ’smart’ devices filling up homes leads to increasing risks, https://blog.f-secure.com/iot-threats/
[7] Internet Security Threat Report (ISTR) 2019 |Symantec, https://www.symantec.com/security-center/threat-report
[8] draft-ietf-suit-architecture-16- A Firmware Update Architecture for Internet of Things, https://tools.ietf.org/html/draftietf-suit-architecture-16
[9] Mirai “internet of things” malware from Krebs DDoS attack goes open source, https://nakedsecurity.sophos.com/2016/10/ 05/mirai-internet-of-things-malware-from-krebs-ddos-attack-goes-open-source/
[10] New Silex malware is bricking IoT devices, has scary plans, https://www.zdnet.com/article/new-silex-malware-isbricking-iot-devices-has-scary-plans/
[11] IoT : Explosion of ’smart’ devices filling up homes leads to increasing risks, https://blog.f-secure.com/iot-threats/
[12] Firmware security for IoT devices, https://www.embedded-computing.com/articles/firmware-security-for-iot-devices
[13] ISTR ransomware & business 2016,http://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/ISTR2016_Ransomware_and_Businesses.pdf
[14] Github: Uptane, https://github.com/uptane
[15] Helping researchers with IoT firmware vulnerability discovery, https://www.helpnetsecurity.com/2018/11/19/iot-firmwarevulnerability-discovery/
تشکر و قدردانی (Acknowledgements)
این پژوهش با حمایت مالی «مرکز ملی امنیت سایبری پاکستان (National Center for Cyber Security – NCCS)» انجام شده است.
منابع
[1] O. Arias, J. Wurm, K. Hoang, Y. Jin, Privacy and security in internet of things and wearable devices, IEEE Transactions on Multi-Scale Computing Systems 1(2) (2015) 99–109.
[2] M. Hung, Leading the IoT: Gartner insights on how to lead in a connected world, Gartner Research (2017) 1–29.
[3] CISCO, Internet of things at a glance (2016).
[4] I. Lee, K. Lee, The Internet of Things (IoT): Applications, investments, and challenges for enterprises, Business Horizons 58(4) (2015) 431–440.
[5] N. Kshetri, The evolution of the internet of things industry and market in China: An interplay of institutions, demands and supply, Telecommunications Policy 41(1) (2017) 49–67.
[6] Y. Shoshitaishvili, R. Wang, C. Hauser, C. Kruegel, G. Vigna, Firmalice-Automatic Detection of Authentication Bypass Vulnerabilities in Binary Firmware., NDSS (2015).
[7] F. Zafar, H. A. Khattak, M. Aloqaily, R. Hussain, Carpooling in connected and autonomous vehicles: Current solutions and future directions, ACM Computing Surveys (2021).
[8] L. Atzori, A. Iera, G. Morabito, The internet of things: A survey, Computer Networks 54(15) (2010) 2787–2805.
[9] K. Pretz, The next evolution of the internet, IEEE Magazine The Institute 50(5) (2013).
[10] Y. Shoshitaishvili et al., SoK: (State of) the art of war: Offensive techniques in binary analysis, IEEE Symposium on Security and Privacy (2016) 138–157.
[11] D. Miessler, Securing the internet of things: Mapping attack surface areas using the OWASP IoT top 10, RSA Conference (2015).
[12] A. Gupta, The IoT Hacker’s Handbook, Springer (2019).
[13] I. Makhdoom et al., Anatomy of threats to the internet of things, IEEE Communications Surveys & Tutorials 21(2) (2018) 1636–1675.
[14] H. A. Abdul-Ghani et al., A comprehensive IoT attacks survey based on a building-blocked reference model, IJACSA 9(3) (2018) 355–373.
[15] M. Ammar et al., Internet of Things: A survey on the security of IoT frameworks, Journal of Information Security and Applications 38 (2018) 8–27.
[16] V. Adat, B. B. Gupta, Security in Internet of Things: issues, challenges, taxonomy, and architecture, Telecommunication Systems 67(3) (2018) 423–441.
[17] Z. Ling et al., IoT security: an end-to-end view and case study, arXiv:1805.05853 (2018).
[18] J. Gubbi et al., Internet of Things (IoT): A vision, architectural elements, and future directions, Future Generation Computer Systems 29(7) (2013) 1645–1660.
[19] C. Kolias et al., DDoS in the IoT: Mirai and other botnets, Computer 50(7) (2017) 80–84.
[20] A. Mohanty et al., Control-hijacking vulnerabilities in IoT firmware: A brief survey, IoTSec Workshop (2018).
[21] S. Siboni et al., Security testbed for internet-of-things devices, IEEE Transactions on Reliability 68(1) (2019) 23–44.
[22] K. Zandberg et al., Secure firmware updates for constrained IoT devices using open standards: A reality check, IEEE Access 7 (2019) 71907–71920.
[23] N. Neshenko et al., Demystifying IoT security: an exhaustive survey on IoT vulnerabilities, IEEE Communications Surveys & Tutorials 21(3) (2019) 2702–2733.
[24] M. Yu et al., A survey of security vulnerability analysis, discovery, detection, and mitigation on IoT devices, Future Internet 12(2) (2020) 27.
[25] A. Costin, Security of CCTV and video surveillance systems, 2016.
[26] A. Costin, J. Zaddach, IoT malware: Comprehensive survey, BlackHat USA (2018).
[27] W. Xie et al., Vulnerability detection in IoT firmware: A survey, ICPADS (2017) 769–772.
[28] M. Muench et al., What you corrupt is not what you crash: Challenges in fuzzing embedded devices, NDSS (2018).
[29] C. Wright et al., Challenges in firmware re-hosting, emulation, and analysis, ACM Computing Surveys 54(1) (2021).
[30] I. Nadir et al., An auditing framework for vulnerability analysis of IoT system, EuroSPW (2019) 39–47.
[31] Z. Wang et al., Automated vulnerability discovery and exploitation in the internet of things, Sensors 19(15) (2019) 3362.
[32] A. Costin et al., A large-scale analysis of the security of embedded firmwares, USENIX Security (2014) 95–110.
[33] A. Costin, Large Scale Security Analysis of Embedded Devices’ Firmware, PhD Thesis (2015).
[34] L. Cojocar et al., PIE: Parser identification in embedded systems, ACSAC (2015) 251–260.
[35] S. L. Thomas et al., HumIDIFy: hidden functionality detection in firmware, DIMVA (2017) 279–300.
[36] Y. David et al., FirmUp: precise static detection of common vulnerabilities in firmware, PLDI (2018) 392–404.
[37] A. Costin et al., Automated dynamic firmware analysis at scale, AsiaCCS (2016) 437–448.
[38] J. Chen et al., IoTFuzzer: discovering memory corruptions in IoT through app-based fuzzing, NDSS (2018).
[39] J. Zaddach et al., Avatar: a framework for dynamic security analysis of embedded systems, NDSS (2014).
[40] L. Zhu et al., FIoT: detecting memory corruption in lightweight IoT firmware, TrustCom (2019) 248–255.
[41] Z. Gui et al., FirmCorn: vulnerability-oriented fuzzing of IoT firmware, IEEE Access (2020).
[42] O. Shwartz et al., Reverse engineering IoT devices: effective techniques and methods, IEEE IoT Journal 5(6) (2018) 4965–4975.
[43] J. Zaddach, A. Costin, Embedded devices security and firmware reverse engineering, BlackHat USA (2013).
[44] G. Palavicini Jr et al., Towards firmware analysis of IIoT, 2017.
[45] S. Vasile et al., Breaking all the things: firmware extraction techniques for IoT devices, 2018.
[46] J. Zaddach, A. Costin, Embedded devices security and firmware reverse engineering, BlackHat USA (2013).
[47] A. Milinković et al., Choosing the right RTOS for IoT platform, Infoteh-Jahorina 14 (2015) 504–509.
[48] A. Guzman, A. Gupta, IoT Penetration Testing Cookbook, Packt (2017).
[49] A. Manske, Conducting a vulnerability assessment of an IP camera (2019).
[50] D. D. Chen et al., Towards automated dynamic analysis for Linux-based embedded firmware, NDSS (2016).
[51] V. Zimmer et al., Embedded Firmware Solutions, Apress (2015).
[52] P. Suresh et al., A state of the art review on IoT history and technology, ICSEMR (2014) 1–8.
[53] G. H. Sockut, Firmware/hardware support for operating systems, ACM SIGMICRO (1975) 17–26.
[54] A. Chatzigeorgiou, G. Stephanides, Evaluating performance and power of programming in embedded processors, 2002.
[55] A. Gilchrist, IoT security issues, Walter de Gruyter (2017).
[56] L. Cojocar et al., PIE: parser identification in embedded systems, ACSAC (2015).
[57] N. G. Tsoutsos, M. Maniatakos, Anatomy of memory corruption attacks in embedded systems, IEEE Embedded Systems Letters 10(3) (2018) 95–98.
[58] J. Zaddach et al., AVATAR framework for embedded systems analysis, NDSS (2014).
[59] S. L. Thomas et al., Stringer: detecting backdoors in firmware, ESORICS (2017).
[60] A. Greenberg, The Reaper IoT botnet report, Wired (2017).
[61] M. B. Barcena, C. Wueest, Insecurity in the Internet of Things, Symantec (2015).
[62] M. Kol, Jsof Research Lab (2020).
[63] M. Lezzi et al., Cybersecurity for Industry 4.0, Computers in Industry 103 (2018) 97–110.
[64] J. Classen et al., Anatomy of a vulnerable fitness tracking system, PACM IMWUT 2(1) (2018).
[65] E. Bertino, N. Islam, Botnets and Internet of Things security, Computer 50(2) (2017) 76–79.
[66] A. Mandal et al., Cross-program taint analysis for IoT systems, SAC (2020) 1944–1952.
[67] I. Sutherland et al., Reverse engineering process for binary files, Computers & Security 25(3) (2006) 221–227.
[68] M. Egele et al., Survey on malware analysis techniques, ACM CSUR 44(2) (2012) 6.
[69] M. Popa, Binary code disassembly for reverse engineering, 2012.
[70] M. Serrano, Lecture Notes on Decompilation (2013).
[71] A. Petukhov, D. Kozlov, Detecting vulnerabilities using dynamic analysis, 2008.
[72] B. Chess, G. McGraw, Static analysis for security, IEEE Security & Privacy 2(6) (2004) 76–79.
[73] S. C. Johnson, Lint, a C program checker, 1977.
[74] H. Chen et al., Model checking one million lines of C code, NDSS (2004).
[75] M. C. Grace et al., Capability leaks in Android, NDSS (2012).
[76] C. May et al., PowerPC Architecture specification, 1994.
[77] Q. Feng et al., Graph-based bug search for firmware, CCS (2016) 480–491.
[78] X. Xu et al., Neural network-based binary similarity detection, arXiv:1708.06525 (2017).
[79] Y. Wang et al., Code similarity analysis for firmware vulnerability detection, IEEE Access 7 (2019) 14171–14185.
[80] C.-W. Tien et al., UFO backdoor discovery in IoT firmware, ISSREW (2018).
[81] C. Cadar et al., KLEE symbolic execution system, OSDI (2008).
[82] F. Bellard, QEMU dynamic translator, USENIX (2005).
[83] D. Davidson et al., FIE: firmware analysis via symbolic execution, USENIX Security (2013).
[84] H. Moore, Metasploitable 2 exploit guide (2012).
[85] J.-b. Hou et al., Vulnerability detection in embedded firmware, Procedia Computer Science 107 (2017) 814–818.
[86] M. Wolfgang, Host discovery with nmap (2002).
[87] R. Rogers, Nessus network auditing, Elsevier (2011).
[88] G. Palavicini Jr et al., IIoT firmware analysis, 2017.
[89] Y. Shoshitaishvili et al., Mechanical Phish autonomous hacking, IEEE S&P 16(2) (2018) 12–22.
[90] M. Zalewski, AFL fuzzer, 2017.
[91] T. R. Alves et al., OpenPLC project, GHTC (2014) 585–589.
[92] M. Zheng et al., DroidRay Android firmware evaluation, ACM (2014) 471–482.
[93] Y. Zheng et al., Firm-AFL fuzzing framework, USENIX Security (2019) 1099–1114.
[94] D. Maier et al., Kernelspace fuzzing via emulation, WOOT (2019).
[95] J.-C. Fonbonne, IoT fuzz testing tool, C&ESAR (2016).
[96] D.-i. Jang et al., IoT protocol fuzzer design, Springer (2017).
[97] N. Karamchandani, Mutation-based protocol fuzzer (2017).
[98] B. Yu et al., Multi-stage message generation fuzzing, CCS (2019).
[99] P. Srivastava et al., FirmFuzz IoT firmware analysis, 2019.
[100] Y. Zheng et al., Greybox fuzzing for IoT programs, IPCCC (2019).
[101] D. Wang et al., Black-box fuzzing IoT web interfaces, Security and Communication Networks (2019).
[102] Y. Yao et al., Privilege separation vulnerabilities in IoT firmware, ESORICS (2019).
[103] Z. Gui et al., FirmNano fuzzing framework, ICSESS (2020).
[104] M. Kim et al., FIRM-AE large-scale emulation, ACSAC (2020).
[105] Z. Gao et al., FW-Fuzz framework, Concurrency and Computation (2020).
[106] B. Feng et al., P2IM peripheral modeling, USENIX Security (2020).
[107] H.-W. Kim et al., Coverage-guided IoT fuzzing, JKIISC (2020).
[108] M. Börsig et al., ESP32 fuzzing framework, WIFS (2020).
[109] X. Feng et al., Snipuzz black-box fuzzing, CCS (2021).
[110] H. Zhang et al., SIoTFuzzer stateful fuzzing, Applied Sciences 11(7) (2021) 3120.
[111] J. Kim et al., Firm-Cov greybox fuzzing, IEEE Access 9 (2021) 101627–101642.
[112] P. Liu et al., IFIZZ firmware testing, ASE (2021) 805–816.
[113] Q. Yin et al., FirmHunter grey-box fuzzing, Applied Sciences 11(19) (2021) 9094.
[114] R. Fan et al., ARM-AFL fuzzing framework, ACNS (2020) 239–254.
[115] E. Hwang et al., Dual-level peripheral modeling fuzzing, IEEE Access 9 (2021).
[116] A. Mera et al., DICE firmware analysis, IEEE S&P (2021) 1938–1954.
[117] Q. Yin et al., Feedback-enhanced fuzzing, ICCT (2021) 754–758.
[118] M. Kil, Log-based IoT fuzzer (2021).
[119] K. Cheng et al., Dtaint vulnerability detection, DSN (2018) 430–441.
[120] Z. B. Celik et al., Sensitive information tracking in IoT, USENIX Security (2018) 1687–1704.
[121] Firmwalker GitHub tool (2020).
[122] Trommel GitHub tool (2020).
[123] IoT Inspector platform (2020).
[124] Firmalyzer platform (2020).
[125] D. Yu et al., IoT firmware identification via weak password analysis, IEEE Access 8 (2020) 7981–7992.
[126] C. Zhang et al., BIFF fuzzing framework, ASE (2021) 1161–1165.
[127] C. Păduraru et al., RiverIoT fuzzing framework proposal, SERP4IoT (2021) 52–58.
[128] X. Liu et al., HFuzz NB-IoT fuzzing, Future Generation Computer Systems 108 (2020) 390–400.
[129] H. Wang et al., Special issue on IoT security and privacy, World Wide Web 21(1) (2018) 1–6.
[130] G. Lally, D. Sgandurra, Framework for IoT security testing, 2018.
[131] C. Bormann et al., RFC 7228 terminology for constrained-node networks (2014).
[132] M. Krau, D. Wei, UEFI misconceptions, 2014.
[133] ENISA, Baseline security recommendations for IoT, 2017.
[134] B. Moran et al., Firmware update architecture for IoT, IETF (2019).
[135] L. Morel et al., Security of bootloaders and firmware updaters, 2019.
[136] H. Chandra et al., OTA firmware update in mesh networks, APCC (2016) 115–118.
[137] X. He et al., Blockchain-based OTA updates, Omni-Layer Intelligent Systems (2019) 164–171.
[138] G. Jurkovic et al., Remote firmware update for embedded systems, MIPRO (2014) 1019–1023.
[139] S. Schmidt et al., Secure firmware OTA update, IoTSU (2016).
[140] I. Skerrett, IoT Developer Survey 2016, Eclipse IoT (2016).
[141] B. Afzal et al., Social IoT applications framework, Future Generation Computer Systems 92 (2019) 718–731.
[142] J.-M. Lim et al., ChainVeri blockchain firmware verification, iThings (2018) 1050–1056.
[143] B. Lee, J.-H. Lee, Blockchain-based secure firmware update, Journal of Supercomputing 73(3) (2017) 1152–1167.
[144] J. Jensen et al., Federated identity management, IEEE Security & Privacy 11(2) (2012) 34–41.
[145] M. Alam et al., Cross-domain access control framework, SACMAT (2011) 31–40.
[146] B. Leiba, OAuth web authorization protocol, IEEE Internet Computing (2012).
[147] S. Zahra et al., Cross-domain security and interoperability in IoT, IEEE Internet of Things Journal (2021).
