مجازی‌سازی عملکردهای شبکه (Network Function Virtualization) با بهره‌گیری از فناوری‌های مجازی‌سازی و سخت‌افزارهای عمومی، میان‌افزارهای قابل‌برنامه‌ریزی درون‌شبکه‌ای را فراهم می‌کند و در میان تمامی تولیدکنندگان اصلی تجهیزات شبکه به محبوبیت گسترده‌ای دست یافته است.
با این حال، اعمال فازینگ هدایت‌شده با پوشش (coverage-guided fuzzing) که یکی از پیشرفته‌ترین روش‌های کشف آسیب‌پذیری به شمار می‌رود بر روی این تجهیزات شبکه مجازی‌سازی ‌شده چالش‌برانگیز است؛ چرا که این دستگاه‌ها بطور ناگزیر از سازوکارهای حافظت از یکپارچگی (Integrity Protection) استفاده می‌کنند.

در این مقاله، ما چارچوبی برای فازینگ هدایت‌ شده با پوشش به نام NDFuzz را برای تجهیزات شبکه مجازی‌سازی‌شده ارائه می‌کنیم که از یک روش نوین برای دور زدن حافظت از یکپارچگی بهره می‌برد. این چارچوب با استفاده از یک تکنیک غیرتهاجمی و با طراحی دقیق برای استنتاج دایرکتوری سراسری صفحات (Page Global Directory Inference)، قادر است فرایندهای تجهیزات شبکه مجازی‌سازی‌ شده را از هایپروایزرها (hypervisor) تشخیص دهد.

ما NDFuzz را بر پایه دو فازر جعبه‌سیاه (black-box) پیاده‌سازی کرده و آن را با استفاده از سه پروتکل شبکه شاخص شامل SNMP، DHCP و NTP، بر روی ۹ دستگاه محبوب شبکه مجازی‌سازی ‌شده ارزیابی کرده‌ایم. نتایج نشان می‌دهد که NDFuzz در مقایسه با نسخه‌های جعبه‌سیاه متناظر خود، به‌طور میانگین ۳۶٪ بهبود در پوشش کد به دست می‌آورد.

NDFuzz با بهره‌گیری از هدایت مبتنی بر پوشش، موفق به کشف دو آسیب‌پذیری روز-صفر (0Day) و یک آسیب‌پذیری روز-یک (1Day) شده است، در حالی که فازر جعبه‌سیاه تنها قادر به یافتن یکی از آن‌ها بوده است. تمامی آسیب‌پذیری‌های کشف‌شده توسط تولیدکنندگان مربوطه تأیید شده‌اند.

کلمات کلیدی: فازینگ هدایت‌شده توسط پوشش، دستگاه‌های شبکه، مجازی‌سازی عملکرد شبکه

1. مقدمه

مجازی‌سازی عملکردهای شبکه (Network Function Virtualization – NFV) که نخستین‌بار در مقاله‌ای در سال ۲۰۱۲ مطرح شد، میان‌افزارهای قابل‌برنامه‌ریزی درون‌شبکه‌ای را برای ساخت سرویس‌های شبکه‌ای فراهم می‌کند که از استحکام و مقیاس‌پذیری بیشتری برخوردارند.
عملکردهای شبکه مجازی‌سازی ‌شده (Virtualized Network Functions – VNFs) بر بستر سخت‌افزارهای عمومی (Commodity Hardware)، مانند ماشین‌های x86، ساخته می‌شوند و به‌طور طبیعی از نوآوری‌های غنی موجود در پشته‌های (stack) نرم‌افزاری خود، از جمله سیستم‌عامل‌ها، بهره‌برداری مجدد می‌کنند.

بنابراین، VNFها اساساً پیاده‌سازی‌های نرم‌افزاری توابع شبکه هستند و می‌توانند به عنوان یک ماشین مجازی ایزوله با همان عملکرد همتایان فیزیکی اختصاصی خود مستقر شوند (میجومبی و همکاران، ۲۰۱۶؛ هان و همکاران، ۲۰۱۵). جدول ۱ خلاصه‌ای از ۱۲ دستگاه شبکه مجازی محبوب در ۹ فروشنده اصلی با ۵ عملکرد متمایز (ستون ۳) را نشان می‌دهد که کاربرد گسترده NFV را نشان می‌دهد. همانطور که جدول ۱ نشان می‌دهد، فروشندگان پیشرو تجهیزات شبکه، از جمله Cisco (خط ۲، ۳)، Juniper (خط ۱۱، ۱۲)، Fortinet (خط ۸) و موارد دیگر، شروع به توسعه لوازم شبکه مجازی مبتنی بر سیستم عامل‌های متن‌باز رایج، مانند لینوکس یا Free BSD، کرده‌اند. این سیستم عامل‌ها در ستون «سیستم عامل» نشان داده شده‌اند. بنابراین، یک VNF در حال اجرا شامل یک هسته سفارشی و چندین فرآیند فضای کاربری است که به عملکردهای مختلف شبکه تعلق دارند.

متأسفانه، کارکردهای شبکه مجازی‌سازی‌شده (VNFs)، همانند نمونه‌های فیزیکی و اختصاصی خود، با تهدیدات امنیتی جدی ناشی از آسیب‌پذیری‌ها مواجه هستند؛ از جمله آسیب‌پذیری CVE-2016-6366¹ در پروتکل SNMP، آسیب‌پذیری CVE-2017-3881² در پروتکل مدیریت خوشه (Cluster Management Protocol – CMP) و آسیب‌پذیری CDPWN در پروتکل کشف سیسکو (Cisco Discovery Protocol – CDP). این آسیب‌پذیری‌ها بر اساس نسخه ۳٫۰ سیستم امتیازدهی آسیب‌پذیری‌های رایج (CVSS 3.0)، همگی در سطح «بحرانی» یا «شدید» ارزیابی شده‌اند.

بنابراین، محققان به دنبال معرفی کشف خودکار آسیب‌پذیری برای VNFها هستند. فازینگ هدایت‌شده با پوشش یکی از کارآمدترین روش‌ها برای کشف آسیب‌پذیری‌ها است (Manèset al. 2019) اگرچه کارهای تحقیقاتی متعددی برای بهبود اثربخشی فازینگ هدایت‌شده با پوشش پیشنهاد شده است (Lyu و همکاران، 2019؛ Yue و همکاران، 2020؛ Böhme و همکاران، 2017؛ Rawat و همکاران، 2017؛ Gan و همکاران، 2018)، بار اصلی اعمال چنین تکنیک فازینگی بر روی VNFها، به دست آوردن اطلاعات دقیق زمان اجرا از فرآیندهای فضای کاربری، مانند مسیرهای اجرای آنها و اجرای بلوک‌های پایه trace است، زیرا یک VNF در واقع یک ماشین مجازی با حفاظت از یکپارچگی داخلی است. جدول 1 تکنیک‌های مختلف حفاظت از یکپارچگی ستون‌های N.Shell و X.Pکه توسط فروشندگان مختلف اتخاذ شده است را برجسته می‌کند، 9 دستگاه از 12 دستگاه حداقل به یک نوع تکنیک حفاظت از یکپارچگی مجهز هستند. به عنوان مثال، CLI رابط خط فرمان رابط تعامل رایج برای VNFها است. اما، اغلب یک پوسته‌ی اصلاح‌شده با دستورات سفارشی ارائه شده توسط فروشندگان برای VNFها است که منجر به عدم توانایی در فراخوانی یک پوسته‌ی معمولی، مانند bash و هر نرم‌افزار third-parity می‌شود.

از دیدگاه هایپروایزر (که به عنوان مانیتور ماشین مجازی، VMM نیز شناخته می‌شود)، ردیابی فرآیندهای فضای کاربری ساده است و به عنوان بخشی از درون‌نگری ماشین مجازی VMI به خوبی مورد مطالعه قرار گرفته است (جین و همکاران، ۲۰۱۴). متاسفانه، تکنیک‌های فعلی VMI به دلیل شیوه‌ی نفوذی آنها نمی‌توانند با VNFها مقابله کنند: اکثر رویکردها نیاز به تزریق کد به ماشین‌های مجازی مهمان دارند، در حالی که حفاظت از یکپارچگی VNFها چنین تزریقی را مجاز نمی‌داند. اول، محدودیت راه‌اندازی هرگونه نرم‌افزار شخص ثالث، رویکردهایی مانند بازسازی ساختارهای داده هسته توسط درایورها (Henderson و همکاران، ۲۰۱۴؛ Yan و Yin، ۲۰۱۲، https://libvmi.com/، https://github.com/CiscoTalos/pyrebox) و کاشت کد (Carbone و همکاران، ۲۰۱۲؛ Sharif و همکاران، ۲۰۰۹) را غیرممکن می‌کند، زیرا همه این روش‌ها نیاز به کامپایل و راه‌اندازی درایورها در داخل ماشین‌های مجازی مهمان دارند. دوم، تنوع سیستم عامل‌ها برای VNFهای مختلف و عدم وجود پیکربندی‌های خاص هسته، پیوند فرآیند (Dolan-Gavitt و همکاران، ۲۰۱۱؛ Fu و Lin، ۲۰۱۲) و بازسازی ساختارهای داده هسته توسط تجزیه و تحلیل حافظه (Socała و Cohen، ۲۰۱۶) را نیز که هر دو برای تولید ابزارهایی برای تصویربرداری لحظه‌ای از برنامه‌های فضای کاربری به پیکربندی دقیق هسته متکی هستند، برای VNFها مناسب نمی‌کند. چالش ردیابی فرآیندهای فضای کاربری یک گام حیاتی در اعمال فازینگ هدایت‌شده توسط پوشش به VNFها است. حفاظت از یکپارچگی که معمولاً توسط VNFهای موجود اتخاذ می‌شود، یک چالش حیاتی را ایجاد می‌کند: چگونه می‌توان یک فرآیند فضای کاربری خاص از VNFها را از طریق هایپروایزر به روشی غیرتهاجمی ردیابی کرد؟

رویکرد ما یک چارچوب فازینگ هدایت‌شده توسط پوشش برای VNFها با یک تکنیک مکان‌یابی فرآیند غیرتهاجمی پیشنهاد می‌کنیم. این تکنیک با استنباط مقدار صحیح دایرکتوری سراسری صفحات (PGD – Page global directory) فرآیند هدف (به اختصار PGD هدف) پیاده‌سازی می‌شود، که به طور گسترده به عنوان شناسایی فرآیند در نظر گرفته می‌شود (Schumilo و همکاران، ۲۰۱۷؛ Aschermann و همکاران، ۲۰۱۹؛ Henderson و همکاران، ۲۰۱۴، https://libvmi.com/، https://github.com/Cisco-Talos/pyrebox، از دیدگاه هایپروایزر. برخلاف رویکردهای سنتی که توسط حفاظت از یکپارچگی محدود می‌شوند، می‌توانیم PGD هدف را با یک تحلیل دیفرانسیل سبک وزن، که از دو نوع اطلاعات مرتبط با PGD که توسط سه عملیات قابل کنترل کنترل می‌شوند، بهره می‌برد، استنباط کنیم. دو نوع اطلاعات کانال جانبی برای تشخیص PGD هدف از سایرین کافی هستند. سپس می‌توانیم ردپای در حال اجرای فرآیند هدف را از ردپای در حال اجرای ترکیبی سیستم با PGD هدف استخراج کنیم.

در این مقاله، یک نمونه اولیه (Prototype) از چارچوب فازینگ هدایت‌شده با پوشش به نام NDFuzz پیاده‌سازی شده است. برای فرایند هدفی که قرار است فاز شود، مقدار دایرکتوری سراسری صفحات آن (PGD – Page global directory) به‌صورت غیرتهاجمی قابل استنتاج است. با در اختیار داشتن PGD هدف، هایپروایزر می‌تواند فرایند هدف را شناسایی و مکان‌یابی کند.

در طول فرایند فازینگ، NDFuzz نقشه‌بیت (Bitmap) به سبک AFL مربوط به فرایند هدف را جمع‌آوری کرده و این اطلاعات را برای هدایت فرایند فازینگ بازخور می‌دهد. به‌منظور پایش رفتارهای غیرعادی فرایند هدف، ما یک سازوکار مبتنی بر ردیابی (Tracing-based) درون لایه VMM برایگرفتن سیگنال SIGSEGV ارائه می‌دهیم و همچنین یک سازوکار خارج از VMM مبتنی بر جهش پوشش (Coverage-jumping) را برای رسیدگی به سایر استثناها به کار می‌گیریم.

ما NDFuzz را بر روی دو فازر جعبه سیاه پیاده‌سازی می‌کنیم: یک فازر متن‌باز بالغ Mutiny (https://github.com/Cisco-Talos/mutiny-fuzzer) و یک فازر داخلی که برای پروتکل DHCP طراحی شده است و از فازر هدایت‌شده با پوشش جعبه خاکستری (greybox) در هر دو نوع پشتیبانی می‌کند. ما از NDFuzz برای فازینگ سه پروتکل پرکاربرد، SNMP، DHCP و NTP، روی 9 نمونه VNF محبوب از هفت فروشنده استفاده می‌کنیم. NDFuzz در مقایسه با همتایان جعبه سیاه خود، می‌تواند عملکرد فازینگ VNFها را با حداقل بهبود پوشش متوسط 27٪ به طور قابل توجهی بهبود بخشد. علاوه بر این، NDFuzz دو آسیب‌پذیری روز صفر روز و یک آسیب‌پذیری روز یک را با راهنمایی پوشش کشف می‌کند در حالی که فازرهای جعبه سیاه فقط می‌توانند یکی از آنها را پیدا کنند. هر سه آسیب‌پذیری کشف شده توسط فروشندگان مربوطه تأیید شده‌اند.

این مقاله موارد زیر را ارائه می‌دهد:

تکنیک استنتاج PGD مبتنی بر تحلیل دیفرانسیلی برای VNFها

تکنیک پیشنهادی می‌تواند مقدار PGD یک فرآیند شبکه‌بندی داده شده از یک VNF را به روشی غیرتهاجمی استنتاج کند. نکته کلیدی این است که تغییر مقدار PGD هدف به طور قابل توجهی متفاوت از سایر PGDها باشد.

یک چارچوب فازی هدایت‌شده با پوشش برای VNFها

با استفاده از PGD هدف، NDFuzz می‌تواند اطلاعات زمان اجرا از یک فرآیند کاربر را به دست آورد و اطلاعات را به فازر بازگرداند. دو مکانیسم نظارتی، یعنی یک مکانیسم درون VMM مبتنی بر ردیابی و یک مکانیسم بیرون VMM مبتنی بر پرش پوششی، برای گرفتن هر چه بیشتر استثنائات ارائه شده‌اند. به عنوان یک چارچوب، NDFuzz می‌تواند برای تقویت فازرهای جعبه سیاه استفاده شود. NDFuzz یک فازری را که توسط خودمان برای DHCP توسعه داده شده است، ادغام می‌کند. ما همچنین یک فازر پروتکل عمومی موجود Mutiny (https://github.com/Cisco-Talos/mutiny-fuzzer) را برای پشتیبانی از ضبط و راهنمایی پوشش بهبود می‌دهیم.

آسیب‌پذیری‌های کشف شده در VNFهای مختلف NDFuzz برای فازی کردن سه پروتکل، SNMP، DHCP و NTP، در نه VNF محبوب تولید شده توسط هفت فروشنده استفاده می‌شود. در مجموع، سه آسیب‌پذیری توسط فروشندگان تأیید شده است، از جمله دو آسیب‌پذیری تازه کشف شده و یک آسیب‌پذیری ثابت شده.

این مقاله به شرح زیر سازماندهی شده است: بخش “مشاهده و انگیزه” مشاهدات و انگیزه ما را برای غلبه بر چالش‌ها ارائه می‌دهد. بخش “پیشینه فنی” به طور خلاصه برخی از اصطلاحات فنی مهم را معرفی می‌کند. بخش “مرور کلی” طرح کلی NDFuzz را نشان می‌دهد که شامل دو مرحله اصلی است که در دو بخش بعدی معرفی می‌شوند.

بخش «فاز اول: استنتاج PGD هدف» جزئیات استنتاج PGD را بر اساس تحلیل تفاضلی توضیح می‌دهد. بخش «فاز دوم: فازینگ هدایت‌شده با پوشش» طراحی و پیاده‌سازی فرآیند فازینگ را شرح می‌دهد. بخش «آزمایش و ارزیابی» نتیجه NDFuzz را نشان می‌دهد. کاستی‌ها و کارهای آینده در بخش «بحث» مورد بحث قرار گرفته‌اند. بخش «کارهای مرتبط» کارهای مرتبط را فهرست می‌کند. در نهایت، بخش «نتیجه‌گیری» این مقاله را خلاصه می‌کند.

2. مشاهده و انگیزه

شکل ۱ یک رویه معمول فازینگ برای یک دستگاه شبکهٔ مجازی‌سازی‌شده را نشان می‌دهد که به‌صورت یک ماشین مجازی اجرا می‌شود و شامل چندین فرایند داخلی است. فرایندهای مختلف، پروتکل‌های متفاوتی را پردازش می‌کنند که هرکدام متناظر با یک بلوک کنترل فرایند (PCB) در فضای کرنل هستند. زمان‌بندی فرایندها همانند زمان‌بندی عادی کرنل لینوکس انجام می‌شود. همچنین، در صورت کرش کردن یک فرایند، کرنل سیگنال‌های استثنا مانند SIGSEGV را به فرایند مربوطه ارسال می‌کند.

به‌دلیل سازوکارهای حفاظت یکپارچگی در VNFها، فازینگ جعبه‌سیاه یکی از مستقیم‌ترین روش‌ها برای کشف آسیب‌پذیری‌ها محسوب می‌شود و به‌طور گسترده در فازینگ دستگاه‌های IoT استفاده شده است (Feng et al. 2021؛ Chen et al. 2018؛ Zhang et al. 2019). منطق اصلی فازینگ در ماژول ارسال‌کنندهٔ بسته پیاده‌سازی می‌شود که قادر است درخواست‌های جهش‌یافته را به فرایند هدف ارسال کند (پیکان زرد در شکل ۱). در صورتی که ارتباط قطع شود یا پاسخ با محتوای خاصی دریافت گردد، ممکن است کرش رخ دهد و درخواست مربوطه ثبت می‌شود.

با این حال، فازینگ جعبه‌سیاه سه محدودیت اصلی دارد:
(۱) ارزیابی کارایی، مانند پوشش کد، دشوار است.
(۲) بدون راهنمایی اطلاعات زمان اجرا مانند پوشش، جهش‌دهی ناکارآمد است.
(۳) پایش مبتنی بر پاسخ (که با عنوان بررسی زنده‌بودن یا liveness-check نیز شناخته می‌شود (Muench et al. 2018)) قابلیت اطمینان پایینی دارد.
اگرچه فازینگ هدایت‌شده با پوشش به‌طور گسترده برای رفع این کاستی‌ها در نرم‌افزارها استفاده می‌شود، اما نمی‌توان آن را به‌صورت مستقیم برای VNFها به‌کار گرفت.

برای فازینگ هدایت‌شده توسط پوشش (فازینگ جعبه خاکستری)، یک کنترل‌کننده فازینگ برای هدایت جهش مطابق با پوشش مربوط به درخواست معرفی شده است. با این حال، پوشش VNFها به دلیل بررسی‌های یکپارچگی آسان نیست. راه بالقوه، کاشت یک برنامه در دستگاه‌های شبکه مجازی برای نظارت بر اطلاعات زمان اجرا است (گائو و همکاران، 2020). این روش به دو پیش‌شرط نیاز دارد که توسط VNFها پشتیبانی نمی‌شوند، یعنی توانایی کاشت یک برنامه و مجوز اجرای برنامه. تنها راه کلی، دستیابی به پوشش کد به روشی غیرتهاجمی با استفاده از هایپروایزر است. روش غیرتهاجمی به معنای عدم تغییر VNF اصلی، عدم نیاز به مجوز پوسته و عدم قرار دادن عامل است.

با توجه به این محدودیت‌ها، برخی از کارهای کمکی هایپروایزر مانند TriforceAFL (https://github.com/nccgroup/) ، kAFL (Schumilo و همکاران، ۲۰۱۷)، REDQUEEN (Aschermann و همکاران، ۲۰۱۹) و FirmAFL (Zheng و همکاران، ۲۰۱۹) همگی نمی‌توانند کار کنند. از دیدگاه هایپروایزر، تمام اطلاعات زمان اجرا از سیستم عامل مهمان، مانند دستورالعمل‌ها، رجیسترها و حافظه را می‌توان مستقیماً به دست آورد. با این حال، این اطلاعات فقط داده‌های خام بدون اطلاعات معنایی هستند که همان مشکل شکاف معنایی شناخته شده است (Dolan-Gavitt و همکاران، ۲۰۱۱). همانطور که در مقدمه توضیح داده شد، کارهای متعددی برای حل شکاف معنایی با تکنیک VMI در سناریوی فازینگ ما محدود هستند. همانطور که جدول ۱ نشان می‌دهد، VNF های متعددی بر روی سیستم عامل چندوظیفه‌ای مدرن (لینوکس، FreeBSD و غیره) توسعه داده شده‌اند.

بنابراین سرویس‌های مختلف شبکه همیشه به عنوان فرآیندهای دیمن مختلف اجرا می‌شوند و هدف فازینگ ما در واقع فرآیند کاربر یک VNF است. تنها چیزی که برای راهنمایی پوشش نیاز داریم، ردیابی است. بنابراین مشکل اصلی زمانی حل می‌شود که بتوانیم ردیابی صحیح فرآیند هدف را از داده‌های خام ترکیبی از نمای هایپروایزر فیلتر کنیم. فهرست سراسری صفحه PGD یک فرآیند برای تشخیص فرآیندهای مختلف در سناریوی ما با سه ویژگی مناسب است:

(1) برای مکانیسم صفحه‌بندی برای یک فرآیند، لینوکس و FreeBSD هر دو یک مدل صفحه‌بندی چند سطحی را اتخاذ می‌کنند. سطح بالا PGD است، یک قاب صفحه فیزیکی که برای فرآیندهای مختلف منحصر به فرد است و می‌تواند به عنوان یک شناسایی فرآیند در نظر گرفته شود.

(2) برخلاف هدف (یعنی تجزیه‌گر تصویر) که چرخه حیات آن فقط یک دور تجزیه در فازینگ جریان اصلی است (Gan و همکاران 2018، http://lcamt uf.coredump.cx/afl/، Lyu و همکاران 2019؛ Aschermann و همکاران 2019)، فرآیند شبکه همیشه به عنوان یک فرآیند شبح عمل می‌کند و درخواست‌های شبکه را به طور مداوم در یک فرآیند واحد مدیریت می‌کند. بدیهی است که مقدار PGD ثابت است مگر اینکه فرآیند از کار بیفتد یا مجدداً راه‌اندازی شود.

(3) هنگامی که هسته یک فرآیند را زمان‌بندی می‌کند، PGD در یک رجیستر ویژه CR3 از x86 و x86_64 بارگذاری می‌شود. تغییر این رجیستر را می‌توان به عنوان یک رویداد خاص از هایپروایزر در نظر گرفت. به عبارت دیگر، هنگامی که مقدار PGD فرآیند هدف مشخص شد، هایپروایزر می‌تواند با نظارت بر تغییر رجیستر CR3 بداند که آیا فرآیند هدف زمان‌بندی و اجرا شده است یا خیر. این مشاهدات نشان می‌دهد که می‌توانیم سرویس شبکه هدف، یک فرآیند دیمن، را به روشی غیرمداخله‌ای از طریق به دست آوردن مقادیر صحیح PGD فرآیند هدف ردیابی کنیم. NDFuzz بر سرویس شبکه‌ای تمرکز دارد که سه ویژگی را برآورده می‌کند:

(1) عملکرد آن مستقل است و به عنوان یک فرآیند دیمن واحد عمل می‌کند.

(2) پروتکل کاملاً یا جزئی بدون حالت است به طوری که درخواست‌ها به یکدیگر مرتبط نیستند.

(3) سرویس در معماری C/S مستقر شده است و فرآیند به عنوان سرور کار می‌کند در حالی که فازر کلاینت است.

3. پیشینه فنی

در این بخش، به طور خلاصه برخی از اصطلاحات فنی مهم این مقاله را معرفی می‌کنیم.

3.1 QEMU

QEMU یک پایشگر ماشین مجازی میزبانی‌شده (Hosted Virtual Machine Monitor) با قابلیت کامپایل JIT است که کد هدف را به دستورالعمل‌های بومی ترجمه کرده و با سرعت بومی اجرا می‌کند. مولد کد کوچک (Tiny Code Generator – TCG) ، با ترجمه بلوک‌های پایه‌ای مهمان (Guest Basic Blocks) به یک نمایش میانی مستقل از معماری (Intermediate Representation – IR) عمل می‌کند و سپس بخش پشتی (Backend) این نمایش میانی را به دستورالعمل‌های بومی میزبان تنزل می‌دهد.

دو حالت کلی برای اجرا وجود دارد: حالت کاربر (User Mode) و حالت سیستم (System Mode). در حالت کاربر، امکان اجرای یک فرایند منفرد وجود دارد، در حالی که در حالت سیستم، یک سیستم‌عامل کامل (ماشین مجازی، VM) شامل پردازنده و انواع تجهیزات جانبی شبیه‌سازی می‌شود. پروتکل ماشین QEMU نسخه ۴ (QEMU Machine Protocol – QMP) در حالت سیستم برای کنترل ماشین مجازی، مانند ذخیره/بارگذاری snapshot، استخراج از حافظه (memory dump) و عملیات مشابه، مورد استفاده قرار می‌گیرد.

در حوزه فازینگ، حالت کاربر QEMU معمولاً برای سناریوهای فازینگ برنامه‌های باینری منفرد به کار می‌رود؛ مانند حالت QEMU در AFL. در مقابل، حالت سیستم همواره برای اهدافی مانند هسته سیستم‌عامل (kernel) که به یک سیستم کامل نیاز دارند، استفاده می‌شود.

3.2 سرویس‌های شبکه

پروتکل مدیریت ساده شبکه (Simple Network Management Protocol – SNMP) یک پروتکل استاندارد اینترنتی است که برای مدیریت، پایش و نظارت بر دستگاه‌های متصل به شبکه استفاده می‌شود. این پروتکل به‌طور گسترده در سامانه‌های مدیریت شبکه به‌کار می‌رود و از طریق شناسه‌های شیء (Object Identifier – OID) که بیانگر توابع و وضعیت‌های مختلف دستگاه هستند، عملیات پایش شبکه را انجام می‌دهد.

پروتکل پیکربندی پویای میزبان (Dynamic Host Configuration Protocol – DHCP) یک پروتکل کلاینت/سرور است که برای اختصاص خودکار آدرس‌های IP و سایر پارامترهای ارتباطی به دستگاه‌های متصل به شبکه طراحی شده است. DHCP به‌طور گسترده در تجهیزاتی که دارای شبکه محلی (LAN) هستند—مانند روترها، گیت‌وی‌ها، فایروال‌ها و تجهیزات مشابه—مورد استفاده قرار می‌گیرد.

پروتکل زمان شبکه (Network Time Protocol – NTP) برای همگام‌سازی زمان بین گره‌های مختلف شبکه بر روی شبکه‌های بسته‌محور با تأخیر متغیر طراحی شده است. این پروتکل قادر است تصحیح زمانی با دقت بالا را برای سایر کلاینت‌های شبکه فراهم کند و یکپارچگی و سازگاری زمان را در سطح شبکه حفظ نماید.

3.3 نمای کلی

شکل ۲ نمای کلی سطح‌بالای چارچوب فازینگ ما، NDFuzz، را توصیف می‌کند. این چارچوب از دو فاز حیاتی تشکیل شده است: فاز استنتاج PGD هدف (فاز I) که به تحلیل تفاضلی تعویض فرآیندها وابسته است تا شناسایی فرآیند هدف، در واقع مقدار PGD یک فرآیند، به‌دست آید. سپس فاز II از این مقدار PGD برای هدایت فازینگ مبتنی بر پوشش استفاده می‌کند. از آنجا که PGD همواره هنگام راه‌اندازی مجدد فرآیند یا سیستم تغییر می‌کند، برای هر تصویر VNF داده‌شده یک snapshot می‌گیریم تا از انجام کارهای تکراری جلوگیری شود. برای یک تصویر VNF مشخص، یک snapshot که شامل مقدار PGD فرآیند هدف است می‌تواند به‌عنوان یک نمونه فازینگ در نظر گرفته شود. این نمونه فازینگ می‌تواند برای اهداف مختلف به‌صورت مستقل کپی و مستقر شود.

فاز اول یک VNF در حال اجرا را به‌عنوان ورودی‌ای در نظر می‌گیرد که توسط QEMU سفارشی‌شده، مانیتور ماشین مجازی (VMM یا هایپروایزر)، پشتیبانی می‌شود. اگرچه QEMU سفارشی‌شده می‌تواند تمام اطلاعات زمان اجرای یک VNF را به‌دست آورد، اطلاعات معنایی همچنان ناشناخته است. خوشبختانه تنها چیزی که برای هدایت فازینگ مبتنی بر پوشش نیاز داریم، مقدار PGD فرآیند هدف (TP) است. ما مجموعه‌ای از مقادیر PGD فرآیندهای فعال و زمان‌های تعویض فرآیند آن‌ها را ثبت می‌کنیم. با استفاده از این دو ویژگی، می‌توان از یک تحلیل تفاضلی سبک‌وزن برای استنتاج مقدار صحیح PGD مربوط به TP بهره برد. به این روش مبتنی بر کانال جانبی، می‌توان TP را به‌صورت خودکار، دقیق و کارآمد مکان‌یابی کرد. مراحل اصلی در نیمهٔ چپ شکل ۲ نشان داده شده‌اند.

هایپروایزر سفارشی یک فهرست از مقادیر PGD و دفعات زمان‌بندی آن‌ها را ثبت می‌کند. به‌منظور اطمینان از اینکه TP زمان‌بندی شود، در طول ثبت PGDها به‌طور پیوسته به TP درخواست ارسال می‌کنیم. سپس TP را غیرفعال یا مجدداً راه‌اندازی می‌کنیم و فهرست دیگری از مقادیر PGD و زمان‌های زمان‌بندی ثبت می‌شود. در ادامه، یک تحلیل تفاضلی سبک‌وزن بر روی دو فهرست مقادیر PGD اعمال می‌شود تا PGD هدف به‌دست آید.

فاز دوم در نیمه راست شکل ۲ نمایش داده شده است. در طول فرآیند فازینگ، کنترل‌کننده فازینگ، QEMU سفارشی‌شده و ارسال‌کننده بسته را با دستورات کنترلی هماهنگ می‌کند. کنترل‌کننده فازینگ پیکربندی فرآیند هدف را بارگذاری می‌کند، QEMU سفارشی‌شده را مقداردهی اولیه می‌کند و ارسال‌کننده بسته را راه‌اندازی می‌کند. با استفاده از مقدار PGD فرآیند هدف، QEMU سفارشی‌شده می‌تواند با پایش تغییرات ثبات CR3 در معماری x86 یا x86_64 تشخیص دهد که آیا TP زمان‌بندی شده است یا خیر. بنابراین، رد اجرای فرآیند هدف می‌تواند هنگام اجرای TP ثبت شود. این ثبت به پردازش درخواست مرتبط است.

پیش از آنکه ارسال‌کننده بسته یک درخواست جهش‌یافته ارسال کند، کنترل‌کننده فازینگ به QEMU اطلاع می‌دهد تا ثبت رد اجرا را فعال کند. پس از آنکه درخواست به‌طور کامل پردازش شد، کنترل‌کننده فازینگ ثبت را غیرفعال کرده و ردهای اجرایی را برای هدایت پوشش از QEMU سفارشی‌شده از طریق پروتکل QMP و حافظه اشتراکی دریافت می‌کند. QEMU سفارشی‌شده می‌تواند یک bitmap به سبک AFL را در یک حلقه اجرای عادی ثبت کند. به‌محض وقوع یک کرش، می‌توان آن را با دو مکانیزم پایش کرد. یک مکانیزم پایش درون VMM می‌تواند سیگنال استثنا، مانند SIGSEGV، را با دقت از طریق ردگیری جزئی کرنل دریافت کند. علاوه بر این، یک مکانیزم پایش خارج از VMM مبتنی بر پرش پوشش توسعه داده شده است تا استثناهایی را که توسط روش درون VMM از دست می‌روند شناسایی کند.

پس از ثبت درخواست استثنایی، کنترل‌کننده فازینگ snapshot اولیه VNF را بارگذاری می‌کند تا فازینگ ادامه یابد. کل این فرآیند برای VNF کاملاً شفاف است زیرا هیچ تغییری در VNF اعمال نمی‌شود، هیچ مجوز شِل نیاز نیست و هیچ برنامه عاملی قرار داده نمی‌شود. این یک روش غیرتهاجمی برای تبدیل فازینگ جعبه‌سیاه به فازینگ جعبه‌خاکستری برای VNF است.

3.3.1 فاز اول: استنتاج PGD فرایند هدف

در این بخش، پیاده‌سازی دقیق مکان‌یابی فرایند با استفاده از تحلیل تفاضلی (Differential Analysis) را توضیح می‌دهیم. با توجه به محدودیت‌های محیطی VNFها، دستیابی به offsetهای خاص کرنل که در روش‌های متداول VMI و تحلیل حافظه مورد نیاز هستند، دشوار است؛ بنابراین، امکان به‌دست‌آوردن نگاشت سنتی بین فرایندها و مقادیر PGD وجود ندارد. با این حال، هدف ما با VMI متفاوت است. به‌جای استخراج حجم زیادی از اطلاعات مربوط به Process Control Block (PCB)، تنها به مقدار PGD فرایند هدف برای شناسایی آن نیاز داریم.

با وجود محدودیت‌های ذاتی VNFها، همچنان می‌توان بخشی از وضعیت داخلی آن‌ها—مانند وضعیت یک سرویس شبکه—را کنترل کرد. نخست، از طریق CLI یا سایر روش‌های مدیریتی (مانند رابط وب)، می‌توان یک سرویس شبکه را فعال، غیرفعال یا راه‌اندازی مجدد کرد؛ این سرویس شبکه به یک فرایند userland متناظر است که با یک مقدار PGD مشخص مرتبط می‌باشد. به‌طور مشخص، فعال‌سازی یک سرویس شبکه، فرایند را به یک مقدار PGD بایند می‌کند، و غیرفعال‌سازی یا ری‌استارت سرویس این رابطه را حذف می‌نماید.

دوم، از دیدگاه هایپروایزر، تمامی مقادیر PGD فرایندهای userland را می‌توان با پایش سوئیچ رجیستر CR3 به‌دست آورد. در یک بازه زمانی مشخص، نه‌تنها می‌توان ثبت کرد که چه مقادیر PGD در CR3 بارگذاری شده‌اند (که نشان‌دهندهٔ تعداد فرایندهای سوئیچ‌شده است)، بلکه مدت زمان یا تعداد دفعات بارگذاری هر PGD را نیز می‌توان اندازه‌گیری کرد که بیانگر فرکانس اجرای فرایند متناظر است.

سوم، سرویس‌های شبکه معمولاً به‌صورت daemon اجرا می‌شوند و در یک حلقهٔ تکرارشونده شامل «انتظار برای درخواست → پردازش درخواست → انتظار برای درخواست بعدی» قرار دارند. هنگامی که یک درخواست از خارج به VNF می‌رسد، کرنل بر اساس پورت مربوطه، فرایند متناظر را بیدار می‌کند و در نتیجه سوئیچ فرایند رخ می‌دهد.

در نهایت، می‌توان از طریق CLI محیط VNF را به‌گونه‌ای پیکربندی کرد که یک محیط پایدار (Stable) ایجاد شود؛ محیطی که شامل فرایند هدف، حداقل تعداد ممکن از فرایندهای نامرتبط (با غیرفعال‌سازی آن‌ها) و سرویس‌های سیستمی غیرقابل پیکربندی باشد.

این چهار نکته متناظر با دو نوع اطلاعات کانال جانبی (Side-Channel) و سه عملیات برای تغییر آن‌ها هستند. با کنترل بایند کردن (عملیات ۱) و حذف رابطه (عملیات ۲) بین فرایند هدف و مقدار PGD، می‌توان یک مجموعه از مقادیر PGD شامل PGD فرایند هدف و مجموعه‌ای دیگر بدون آن به‌دست آورد (اطلاعات ۱). با ارسال درخواست‌های شبکه به فرایند هدف (عملیات ۳)، تعداد دفعات زمان‌بندی آن—که معادل تعداد سوئیچ‌های فرایند است—افزایش می‌یابد (اطلاعات ۲). در نتیجه، عملیات ۳ باعث می‌شود زمان‌بندی PGD هدف به‌مراتب بیشتر از حالت پیش‌فرض شود.

با یک محیط به‌خوبی پیکربندی‌شده، این روش تفاوت معناداری میان فرایند هدف و سایر فرایندها از نظر الگوی سوئیچ فرایند ایجاد می‌کند و نویز را به حداقل می‌رساند. بنابراین، این مجموعه عملیات و اطلاعات برای تعیین صحیح مقدار PGD فرایند هدف از طریق تحلیل تفاضلی کاملاً کافی است.

الگوریتم ۱: مکان‌یابی فرایند با تحلیل تفاضلی

				
					Input: A running VNF V , a method trigger(TV )to request the target process TV .
Output: A fuzzing instance containing Vsnapshot and PGD value P of target process TV .
binding(TV );
Vsnapshot ← take snapshot(V ) ;
P GDs ← {} ;
while process switch time &lt;N do
		Note this trigger running is concurrent with process switching recording ;
	trigger(TV ) ;
	P GD value ← monitor CR3 switching(V ) ;
	if P GDs.has key(P GD value) then
		P GDs[P GD value] ← P GDs[P GD value] + 1 ;
	else
		P GDs[P GD value] ← 1 ;
eliminating(TV );
P GDs without target ← {} ;
while process switch time &lt;N do
	P GD value ← monitor CR3 switching(V ) ;
	if P GDs without target.has key(P GD value) then
		P GDs without target[P GD value] ← P GDs without target[P GD value] + 1 ;
	else
		P GDs without target[P GD value] ← 1 ;
P GD set ← set(P GDs) \ set(P GDs without target);
P ← select P GD value with most switching(P GD set, P GDs);
return P , Vsnapshot ;

الگوریتم ۱ نحوه استنباط مقدار PGD فرآیند هدف TV یک VNF را نشان می‌دهد. ما عملیات‌های اتصال (TV و حذف TV را برای نمایش عملیات ۱ و عملیات ۲ با پیکربندی صحیح تعریف می‌کنیم و ماشه TV به معنای درخواست شبکه برای فرآیند هدف TV از خارج از VNF عملیات ۳ است. ابتدا TV را با فعال کردن سرویس و گرفتن یک عکس فوری برای فازینگ بعدی به یک مقدار PGD متصل می‌کنیم. همانطور که در فاز اول: استنتاج PGD هدف توضیح داده شد، هنگامی که TV در حال اجرا است و توسط یک درخواست شبکه تحریک می‌شود، برنامه‌ریزی می‌شود. بنابراین ما از هایپروایزر برای ثبت N بار سوئیچینگ فرآیند (ما همیشه از ۱۰۰۰ استفاده می‌کنیم) و تحریک همزمان فرآیند توسط شبکه استفاده می‌کنیم. سپس لیستی از PGDها را که شامل تمام مقادیر PGD با هر زمان سوئیچینگ فرآیند است، به دست می‌آوریم. به دلیل استراتژی ما، مقدار PGD هدف باید در PGDهایی با بالاترین زمان سوئیچینگ فرآیند باشد. سپس با غیرفعال کردن یا راه‌اندازی مجدد سرویس، رابطه TV و PGD هدف را از بین می‌بریم. می‌توانیم به طور مشابه لیست PGDs_without_target را بدست آوریم. در مرحله بعد، PGDها و PGDs_without_target را به مجموعه‌هایی از مقادیر PGD تبدیل می‌کنیم و مجموعه تفاضلی PGDset را بدست می‌آوریم. در نهایت، عناصری را که مقادیر PGD یکسانی از PGDset و لیست PGDها دارند، مقایسه می‌کنیم و مقدار PGD با بیشترین زمان‌های برنامه‌ریزی شده، مقادیر PGD فرآیند هدف است.

این روش برای یافتن فرآیند برای سیستم‌های عامل چندوظیفه‌ای مختلف مانند لینوکس و FreeBSD عمومی است. بدیهی است که نسخه‌ها به سختی تحت تأثیر قرار می‌گیرند، زیرا این یک طراحی کلی از سیستم عامل است. در معماری x86 و x86_64، رجیستر CR3 مقادیر PGD را ذخیره می‌کند و دستورالعمل‌های خواندن یا نوشتن این رجیستر خاص هستند. اگرچه نمی‌توانیم تمام فرآیندها و مقادیر PGD را از طریق تحلیل حافظه که به آفست‌ها یا اطلاعات اشکال‌زدایی بستگی دارد، نگاشت کنیم، اما این روش برای سناریوی ما کافی است.

ما QEMU را به‌عنوان هایپروایزر خود سفارشی‌سازی کرده‌ایم تا با اتصال (Hook) به دستورالعمل‌های مرتبط با CR3، مقادیر PGD را ثبت کند. پیاده‌سازی محرک (Trigger) برای TV به پروتکل مربوط به TV وابسته است. این محرک برای فرایند هدف در VNFs مختلفی که از یک پروتکل یکسان استفاده می‌کنند، به‌صورت عمومی قابل استفاده است؛ اما برای فرایند هدفی با یک پروتکل جدید، نیاز به سفارشی‌سازی دارد.

پیاده‌سازی یک محرک ساده است، زیرا تنها کافی است یک بسته شبکه به پورت صحیح VNF ارسال شود. این بسته می‌تواند از ارتباطات عادی ضبط (Capture) شده باشد یا بر اساس مستندات RFC مربوطه به‌صورت دستی ساخته شود.

3.3.2 فاز دوم: فازینگ هدایت ‌شده با پوشش

با در اختیار داشتن اطلاعات کنترل فرایند، می‌توان یک فرایند سطح کاربر (Userland) را از طریق هایپروایزر ردیابی و پایش کرد و اطلاعات زمان اجرا را برای هدایت فرایند فازینگ جمع‌آوری نمود. در این بخش، پیاده‌سازی مرحله فازینگ تشریح می‌شود. بخش «هدایت کل فرایند فازینگ« روند کامل فازینگ VNFs را توضیح می‌دهد. بخش «پایش یک برنامه سطح کاربر» نشان می‌دهد که چگونه می‌توان از دید هایپروایزر وقوع یک کرش (crash) را تشخیص داد. در نهایت، بخش «هایپروایزر سفارشی‌سازی‌شده» جزئیات پیاده‌سازی QEMU سفارشی‌شده را ارائه می‌کند.

3.4 هدایت کل فرایند فازینگ

شکل ۳ تعامل کامل فازینگ در NDFuzz را نشان می‌دهد. کنترل‌کننده فازینگ با کنترل QEMU سفارشی‌شده و ارسال‌کننده بسته‌ها، کل فرایند را هدایت می‌کند. QEMU سفارشی‌شده وظیفه اجرای ابزاربندی پویای باینری (Dynamic Binary Instrumentation) را برای پایش استثناها و ردیابی فرایند هدف بر عهده دارد.

ارسال‌کننده بسته‌ها (Packet Sender)، بسته‌ها را ساخته و به‌واسطه اعلان کنترل‌کننده فازینگ آن‌ها را ارسال می‌کند. QEMU در حین پردازش هر بسته، اطلاعات زمان‌واقعی را ثبت می‌کند. کنترل‌کننده فازینگ با توجه به پاسخ برنامه سطح کاربر و با در نظر گرفتن یک محدودیت زمانی قابل قبول (Timeout)، زمان شروع و پایان ثبت نقشه‌بیت (Bitmap) و ردیابی را تعیین می‌کند. سپس اطلاعات نقشه‌بیت هر درخواست از طریق حافظه مشترک و با استفاده از دستور سفارشی‌شده QMP همگام‌سازی می‌شود.

بر اساس اطلاعات نقشه‌بیت، موارد جالب (Interesting Cases) به‌عنوان راهنما در صف اولویت قرار داده می‌شوند. هم‌زمان، کنترل‌کننده فازینگ با QEMU در خصوص پایش سیگنال‌ها همگام‌سازی کرده و پوشش کد را برای ماژول پایش پوشش تحلیل می‌کند. در صورت بروز یک استثنا، کنترل‌کننده فازینگ اطلاعات مربوطه را ذخیره کرده و سپس Snapshot را برای ادامه فازینگ مجدداً بارگذاری می‌کند. تمامی عملیات فرمان‌دهی و کنترل به‌صورت شفاف نسبت به دستگاه اجراشده بر روی هایپروایزر انجام می‌شود؛ به‌گونه‌ای که دستگاه تمام درخواست‌ها را همانند حالت عادی پردازش می‌کند.

ما یک لایه میانی برای ارسال بسته‌ها طراحی کرده‌ایم تا با فازینگ پروتکل‌های سفارشی‌سازی‌شده مختلف سازگار باشد. این لایه شامل یک رابط جهش (Mutation Interface) است که در نخ جهش (Mutation Thread) استفاده می‌شود و یک رابط ارسال (Sending Interface) که در نخ ارتباطی (Communication Thread) به کار می‌رود. نخ جهش وظیفه اعمال جهش بر روی درخواست‌ها را به‌گونه‌ای بر عهده دارد که با مشخصات پروتکل سازگار بوده و در عین حال صف آزمون (Testing Queue) را نگه‌داری می‌کند، در حالی که نخ ارتباطی مطابق با قواعد پروتکل با فرایند هدف ارتباط برقرار کرده و صف موارد جالب (Interesting Queue) را مدیریت می‌کند.

نخ جهش (Mutation Thread)، درخواست‌ها را از صف موارد جالب دریافت کرده و پس از اعمال جهش، آن‌ها را در صف آزمون قرار می‌دهد. در مقابل، نخ ارتباطی موارد آزمون را که منجر به افزایش پوشش کد شده‌اند در صف موارد جالب ذخیره می‌کند تا هدایت مبتنی بر پوشش فراهم شود.

علاوه بر یکپارچه‌سازی پروتکل‌های سفارشی، ما قابلیت‌های هسته‌ای کنترل‌کننده فازینگ را به‌صورت مجموعه‌ای از APIها پیاده‌سازی کرده‌ایم تا از سازگاری و تطبیق فازرهای شبکه‌ای جعبه‌سیاه موجود پشتیبانی شود. بدین ترتیب، یک فازر جعبه‌سیاه می‌تواند به‌سادگی اطلاعات پوشش کد را برای ارزیابی عملکرد به دست آورد و حتی از فازینگ هدایت‌شده با پوشش کد نیز پشتیبانی کند.

3.5 پایش یک برنامه سطح کاربر (Monitoring a Userland Program)

ردیابی یک برنامه سطح کاربر می‌تواند اطلاعات پوشش (Coverage) را فراهم کند که مبنای هدایت فازینگ خاکستری (Graybox Fuzzing) است.. NDFuzz به محض وقوع یک استثنا، باید بتواند پایان اجرای هدف را تشخیص داده و مورد آزمون (Testcase) مربوطه را ثبت کند. شایان توجه است که این فرآیند پایش باید به‌صورت غیرتهاجمی (Non‑intrusive) انجام شود. روش بررسی زنده‌بودن (Liveness-check) پیشنهادشده توسط Muench و همکاران (۲۰۱۸) تنها بخشی از سناریوهای موردنظر ما را پوشش می‌دهد و دارای محدودیت‌های مشخصی است.

به‌منظور پایش استثناها از دید هایپروایزر، ما دو سازوکار مکمل ارائه می‌دهیم: ردیابی اجرای handler استثنا و مشاهده جهش در پوشش کد (Coverage Jumping) در فرایند سطح کاربر.

در پایش درون VMM یا In‑VMM Monitoring، بر اساس پژوهش Muench و همکاران (۲۰۱۸)، تکنیک Segment Tracking قادر است حدود ۸۰٪ از انواع آسیب‌پذیری‌های مصنوعی شناسایی‌شده در آزمایش‌های آن‌ها را کشف کند. در سیستم‌عامل‌های Linux و FreeBSD، شناسایی خطای تقسیم‌بندی (SIGSEGV) معادل بهره‌گیری از این تکنیک تلقی می‌شود. هنگامی که یک برنامه سطح کاربر دچار نقض دسترسی حافظه می‌شود، هسته سیستم‌عامل کنترل اجرا را در دست گرفته و از طریق ارسال سیگنال SIGSEGV فرایند هدف را مطلع می‌سازد.

از منظر فازینگ مبتنی بر هایپروایزر، ردیابی اجرای handler سیگنال در حین اجرای فرایند هدف یک سازوکار عمومی برای پایش درون VMM محسوب می‌شود. قاعده ۱ (Rule 1) سازوکار پایش درون VMM را مشخص می‌کند. با توجه به اینکه مقدار PGD هدف از پیش مشخص است و handler فرایند بسته به هسته سیستم‌عامل متفاوت است، ما handler مربوط به SIGSEGV را با شناسایی آدرس بلوک پایه هسته که شامل دسترسی به رشته‌های شاخص خاص است، مکان‌یابی می‌کنیم.

در لینوکس، زمانی که یک برنامه، فضای کاربر SIGSEGV را ایجاد می‌کند، هسته با فراخوانی تابع printk() و استفاده از رشته قالب “%s%s[%d]: segfault at ” اطلاعات استثنا را ثبت می‌کند. در FreeBSD، رشته شاخص متناظر “(core dumped)” است. استخراج باینری هسته نیز با mount کردن تصاویر VNF به‌سادگی امکان‌پذیر است.

در پایش خارج از VMM (Out‑of‑VMM Monitoring)، اگرچه پایش سیگنال SIGSEGV قادر است بخش عمده‌ای از کرش‌های فرایند را شناسایی کند، اما برخی وضعیت‌های استثنایی دیگر نیز می‌توانند موجب کرش یا خاتمه اجرای فرایند شوند؛ از جمله کرش ناشی از سیگنال SIGABRT که معمولاً در اثر خطاهای heap رخ می‌دهد، یا راه‌اندازی مجدد فرایند توسط watchdog. از آنجا که رسیدگی به سیگنال SIGABRT به‌مراتب پیچیده‌تر از SIGSEGV است، شناسایی آن برای پایش درون VMM مناسب نیست. در چنین شرایطی، اتکا صرف به پایش SIGSEGV می‌تواند منجر به از دست رفتن برخی نمونه‌های آزمون استثنایی شود.

با این حال، نادیده گرفتن این خطاهای منفی کاذب (False Negatives) باعث اختلال در کل فرایند فازینگ خاکستری مبتنی بر مقدار PGD هدف می‌شود. برای مثال، اگر فرایند هدف بر اثر دریافت سیگنال SIGABRT کرش کند، سازوکار پایش درون VMM قادر به تشخیص آن نخواهد بود، اما watchdog ممکن است فرایند را برای بازیابی وضعیت اجرا مجدداً راه‌اندازی کند. پس از راه‌اندازی مجدد، فرایند می‌تواند درخواست‌های شبکه را مشابه قبل پردازش کند، اما مقدار PGD آن به دلیل راه‌اندازی مجدد تغییر کرده است. از آنجا که NDFuzz برای استخراج اطلاعات زمان اجرا از مقدار PGD هدف استفاده می‌کند، تغییر PGD ناشی از این خطاهای منفی کاذب باعث اختلال جدی در کل فرایند فازینگ شده و کاملاً غیرقابل‌قبول است.

از این‌رو، ما یک سازوکار پایش تکمیلی مبتنی بر پوشش ارائه می‌دهیم که بر پایه یک مشاهده ظریف در فرایند ردیابی برنامه سطح کاربر طراحی شده است. همان‌گونه که در بخش «فاز اول: استنتاج PGD هدف» بیان شد، مقدار PGD در طول اجرای عادی فرایند هدف تغییر نمی‌کند و QEMU اطلاعات پوشش را با اعمال فیلتر بر اساس این مقدار PGD ثبت می‌کند. بنابراین، به‌محض خاتمه اجرای فرایند، QEMU اصلاح‌شده دیگر قادر به ردیابی هیچ اجرایی با مقدار پیشین CR3 نخواهد بود. این وضعیت منجر به یک «جهش پوششی (Coverage Jumping)» از مقدار غیرصفر به صفر می‌شود و بدین‌ترتیب وقوع استثنایی را آشکار می‌سازد که توسط سازوکار پایش درون VMM شناسایی نشده است.

اگرچه پایش خارج از VMM ممکن است در برخی شرایط نادر، خاتمه‌هایی را شناسایی کند که مستقیماً ناشی از یک آسیب‌پذیری نیستند، ما بر این باوریم که ثبت این خروج‌های غیرمنتظره نیز برای تضمین عملکرد صحیح و پایدار کل فرایند فازینگ ضروری است.

3.6 هایپر وایزر سفارشی

به‌منظور پشتیبانی از فازینگ خاکستری، ما یک نسخه سفارشی از QEMU را بر پایه QEMU‑TCG توسعه داده‌ایم. با این پیاده‌سازی در سطح پایین، یک وظیفه فازینگ می‌تواند تنها بر روی یک رایانه شخصی یا در محیط ابری مستقر شود. ما عملیات خواندن و نوشتن ثبات CR3 در QEMU را متصل (hook) کرده‌ایم تا تشخیص دهیم آیا فرایند هدف در حال زمان‌بندی (Scheduled) است یا خیر. همچنین، موتور TCG را برای انجام ابزاربندی پویای باینری اصلاح کرده و یک نقشه‌بیت به سبک AFL مبتنی بر پوشش یال (Edge Coverage) را برای هدایت فرایند فازینگ فراهم کرده‌ایم.

در طول ردیابی فرایند سطح کاربر، سه نوع دستورالعمل ممکن است مشاهده شود: دستورالعمل‌های مربوط به فرایند صحیح سطح کاربر، دستورالعمل‌های سایر فرایندهای سطح کاربر، و دستورالعمل‌های هسته. ما با استفاده از مقدار PGD فرایند هدف، دستورالعمل‌های متعلق به فرایند صحیح سطح کاربر را فیلتر می‌کنیم. سپس با بهره‌گیری از مقادیر RIP یا EIP، دستورالعمل‌های فضای هسته و فضای کاربر را از یکدیگر تفکیک می‌کنیم.

یک راه ساده برای انجام ابزاربندی پویای باینری، اتصال حلقه اجرای TCG در تابع cpu_exec() از فایل qemu/accel/tcg/cpu-exec.c است. با این حال، این رویکرد با غیرفعال‌سازی قابلیت block chaining یا زنجیره بلوکی منجر به سربار کارایی بسیار بالایی می‌شود. در مقایسه با اجرای کد بومی، فرایند ترجمه پرهزینه است و در اجرای عادی QEMU، بلوک‌های ترجمه‌شده (Translation Blocks یا TBs) در حافظه پنهان TCG ذخیره می‌شوند.

هنگامی که TB اجرا می‌شود، QEMU بلوک پایه‌ای بعدی را شناسایی می‌کند که این امر نیز سربار عملکرد اضافی به همراه دارد. ازاین‌رو، QEMU مکانیزم زنجیره بلوکی را برای اتصال TBهای مجاور فراهم می‌کند؛ برای مثال، به‌صورت یک پرش مستقیم به مقصدی با آدرس از پیش مشخص. در صورت نبود بهینه‌سازی زنجیره بلوکی ، هر بلوک پایه‌ای به‌طور مکرر و با هزینه ترجمه بالا و بدون استفاده از حافظه پنهان مجدداً ترجمه خواهد شد. در QEMU حالت سیستم (System‑mode) مورد استفاده ما، چنین سرباری کاملاً غیرقابل‌قبول است.

++AFL (Fioraldi و همکاران، ۲۰۲۰) این مشکل را با درج محاسبه نقشه‌بیت پوشش (Bitmap Calculation) مستقیماً درون بلوک‌های ترجمه حل کرده و به بهبود سرعتی در حدود ۳ تا ۴ برابر دست یافته است (https://andreafioraldi.github.io/articles/2019/07/20/aflpp-qemu-compcov.html).

با الهام از این بهینه‌سازی، ما تابع کمکی خود را مستقیماً درون بلوک ترجمه (Translation Block) برای اهداف ردیابی و پایش درج کرده‌ایم. نقشه‌بیت پوشش (Bitmap) در حافظه مشترک ذخیره می‌شود و پیش از هر تکرار فازینگ بازنشانی می‌گردد. با وقوع هر انتقال یال (Edge Transition)، بایت متناظر در نقشه‌بیت افزایش می‌یابد.

پیاده‌سازی سازوکار پایش اندکی با ردیابی متفاوت است. از آنجا که پایش بر اجرای handler استثنا متمرکز است و این handler به آدرس یک بلوک پایه‌ای مشخص وابسته است، ما تابع کمکی را در زمان ترجمه همان بلوک پایه‌ای درج می‌کنیم. در نتیجه، هنگامی که این بلوک پایه‌ای اجرا می‌شود، تابع کمکی با علامت‌گذاری سیگنال، فرآیند پایش را محقق می‌سازد.

4. آزمایش و ارزیابی

در این بخش، پیاده‌سازی نمونه اولیه NDFuzz را ارزیابی می‌کنیم. به‌طور خلاصه، هدف ما پاسخ‌گویی به پرسش‌های پژوهشی زیر است:

عمومیت (Generality) – آیا تکنیک استنتاج PGD هدف ما روی VNFهای مختلف به‌خوبی کار می‌کند؟
بهبود پوشش (Coverage Improvement) – میزان افزایش پوشش کد با استفاده از هدایت مبتنی بر پوشش چقدر است؟
کشف آسیب‌پذیری‌ها (Vulnerability Discovery) – اثربخشی NDFuzz در شناسایی آسیب‌پذیری‌های واقعی در VNFs چگونه است؟
سربار (Overhead) – میزان سربار ناشی از ابزاربندی و اجرای NDFuzz چقدر است؟
مطالعه موردی (Case Study) – چگونه هدایت مبتنی بر پوشش، فرآیند کشف آسیب‌پذیری‌ها را شکل می‌دهد؟

4.1 تنظیمات آزمایش

ما فازینگ خود را روی یک Ubuntu 20.04 LTS با پردازنده Intel(R) Xeon(R) Gold 6242R CPU @ 3.10GHz و حافظه ۱۲۰ گیگابایتی مستقر کردیم. برای جلوگیری از نویز احتمالی بین دستگاه‌های مختلف (ترافیک ARP، NDP و غیره) که ممکن است بر فازینگ تأثیر بگذارد، جداسازی شبکه را برای هر نمونه فازینگ انجام دادیم. به طور خاص، ما یک ماشین مجازی کامل را برای یک نمونه فازینگ و استقرار NDFuzz آماده می‌کنیم.

به هر ماشین مجازی ۸ گیگابایت حافظه و ۵۰ گیگابایت دیسک مجازی اختصاص داده می‌شود. کل فرآیند از فاز اول تا فاز دوم به صورت خودکار انجام می‌شود و تنها تلاش دستی برای پیکربندی دستگاه‌ها صورت می‌گیرد. با توجه به تفاوت قابل توجه بین دستگاه‌ها، تکمیل پیکربندی سرویس‌های SNMP نسخه 2DHCP و NTP برای آماده‌سازی یک نمونه فازینگ، حدود 3 ساعت برای هر دستگاه طول کشید. به منظور تأیید عملکرد NDFuzz در بهبود پوشش و یافتن خرابی‌ها، ما از چهار موتور فازینگ استفاده می‌کنیم که شامل 2 موتور فازینگ عمومی Mutiny-No-Feedback و Mutiny-Feedback و 2 موتور فازینگ سفارشی پروتکل ZDHCPNo-Feedback و ZDHCP-Feedback است.

ما در مجموع 18 نمونه فازینگ را آزمایش کردیم و هر یک از آنها با کپی کردن توسط چندین موتور فازینگ آزمایش شده‌اند. کل ساعت‌های فازینگ CPU برابر با 3168 (9*2*72+4*4*72+5*2*72) ساعت است.

4.2 اندازه کد NDFuzz

جدول 2، آمار NDFuzz را نشان می‌دهد. ما حدود 1.8 هزار خط کد C برای سفارشی‌سازی QEMU برای نیاز خود اضافه کردیم. Mutiny اصلی حدود 2.0 هزار خط کد پایتون دارد و ما 0.7 هزار خط اضافه می‌کنیم که شامل API NDFuzz برای فعال کردن دریافت اطلاعات زمان اجرا است. برای حالت Mutiny-FB، حدود 0.8 هزار خط پایتون به Mutiny اصلی اضافه کردیم. ZDHCP-NFB حدود 4.6 هزار خط کد پایتون با API NDFuzz برای ثبت پوشش در فازینگ جعبه سیاه است.

کل NDFuzz برابر با 6.2 هزار خط کد پایتون با ZDHCP-FB است که با آن ادغام شده است.

4.3 عمومیت برای دستگاه‌های مختلف

به منظور نشان دادن عمومیت NDFuzz، ما نُه VNF دنیای واقعی را به عنوان اهداف فازینگ از بین هفت فروشنده معروف Arista، Juniper، SonicWALL، Fortinet، Hillstone، Pulsesecure و Vyos انتخاب کردیم. این دستگاه‌ها به انواع Switch، Router، Firewall، Gateway و SSLVPN تعلق دارند. جدول 3 اطلاعات دقیق نه VNF هدف ما را نشان می‌دهد.

می‌توانیم ببینیم که 77.8٪ (7 از 9) دستگاه مبتنی بر لینوکس با نسخه‌های مختلف هستند، به جز Juniper که مبتنی بر FreeBSD است. نسخه‌های هسته لینوکس با فاصله 11 ساله از 2.6.32 تا 4.19.142 متفاوت هستند. یکی از هفت VNF مبتنی بر لینوکس x86 و بقیه x86_64 هستند.

اگرچه این دو معماری مشابه هستند، اما همچنان مانند قراردادهای فراخوانی متفاوت هستند. با این حال، تکنیک استنتاج PGD هدف سبک وزن ما می‌تواند PGD هدف صحیح را در بین سیستم عامل‌ها و نسخه‌های مختلف به دست آورد. دلیل این امر این است که مکانیسم‌های زمان‌بندی فرآیند برای سیستم عامل‌های چندوظیفه‌ای مختلف عمومی هستند. ما پروتکل‌های SNMP، DHCP و NTP را به عنوان سرویس هدف انتخاب کردیم. SNMP یک پروتکل بدون وضعیت معمولی است که برای مدیریت یک دستگاه بر اساس گره‌های OID مختلف استفاده می‌شود.

DHCP کمی متفاوت است، زیرا شامل سمت کلاینت و سرور می‌شود که سمت سرور، هدف فازینگ ماست. ما DHCP را نیز به‌صورت بدون‌وضعیت (stateless) در نظر می‌گیریم تا تمرکز روی تحلیل گزینه‌ها (option parsing) باشد؛ به این صورت که آدرس IP را ثابت نگه می‌داریم و هر درخواست را با یک شناسهٔ نشست یکتا علامت‌گذاری می‌کنیم.
NTP نسبت به SNMP و DHCP ساده‌تر است و برای همگام‌سازی زمان بین گره‌های مختلف شبکه استفاده می‌شود. پشتیبانی این سه پروتکل در دستگاه‌های مختلف در ستون‌های ۶ تا ۸ جدول ۳ فهرست شده است. همهٔ دستگاه‌ها می‌توانند PGD فرایند هدف را در کمتر از ۲۰ ثانیه به‌دست آورند که در مقایسه با فازینگ ۷۲ ساعته، کاملاً کارا و قابل صرف‌نظر است.

برای تبیین فاز I، نسبت و رتبهٔ زمان‌بندی فرایندها را محاسبه کردیم که جزئیات آن در جدول ۴ آمده است. ابتدا PGD فرایند هدف را از طریق تحلیل تفاضلی در فاز I استخراج کردیم. سپس snapshot را بارگذاری کرده و بر اساس PGD صحیح، تعداد پیش‌فرض دفعات زمان‌بندی را شمارش نمودیم. درصد به‌دست‌آمده نشان‌دهندهٔ سهم زمان‌بندی PGD هدف از مجموع هزار بار سوییچ فرایند است.
SNMP‑T، DHCP‑T و NTP‑T آمار PGD هدف در حالتی هستند که عملیات تحریک (trigger) انجام شده است. SNMP‑N، DHCP‑N و NTP‑N آمار مربوط به اجرای عادی VNF را نشان می‌دهند.

از SNMP‑N، DHCP‑N و NTP‑N مشخص است که فرایندهای SNMP، DHCP و NTP در حالت عادی با سهم کمی زمان‌بندی می‌شوند. در مقابل، SNMP‑T، DHCP‑T و NTP‑T نشان می‌دهند که با اعمال عملیات trigger، این فرایندها با سهمی به‌مراتب بیشتر و با رتبه‌های بالاتر زمان‌بندی می‌شوند. در میان ۹ VNF، در مجموع اطلاعات ۱۸ مقدار PGD استخراج شد که شامل ۹ مورد برای SNMP، ۴ مورد برای DHCP و ۵ مورد برای NTP است. با اعمال trigger، ۹ مورد از این ۱۸ مقدار در رتبهٔ اول و بقیه در رتبهٔ دوم قرار گرفتند. دلیل این امر آن است که برخی فرایندهای سیستمی ممکن است اولویتی بالاتر از فرایند هدف داشته باشند.

روش اصلی برای به دست آوردن مقدار PGD از طریق تحلیل حافظه است اما بر اساس فرض غیر مداخله‌گر، ما نمی‌توانیم ورودی مناسب را به روش خودشان مانند بازسازی ساختارهای داده هسته توسط درایورها و موارد دیگر به دست آوریم. بنابراین این روش بالقوه سوال دیگری است که باید حل شود.

راه حل تحلیل دیفرانسیل ما فقط می‌تواند PGD را استنباط کند و نمی‌تواند اطلاعات دقیقی مانند نام فرآیند مربوط به این مقدار PGD را به دست آورد، در حالی که روش بالقوه می‌تواند محتوای دقت را به دست آورد. این عیب اصلی است. از سوی دیگر، روش بالقوه باید هر فایل هسته را تجزیه کند تا اطلاعات مورد نیاز را استخراج کند و سپس کل تصویر لحظه‌ای حافظه را تجزیه کند، که پیچیده است و مراحل بیشتری نسبت به راه حل ما دارد. این مزیت راه حل ماست.

4.4 بهبود پوشش کد

ما همه VNFها را با هزینه قابل توجهی کمتر از هدف و زمان فازینگ با کمک مجازی‌سازی نسبت به دستگاه‌های فیزیکی فاز کردیم. موتورهای فازینگ به شرح زیر نشان داده شده‌اند:

Mutiny-No-Feedback (Mutiny-NFB) Mutiny (https://github.com/Cisco-Talos/mutiny-fuzzer) یک چارچوب فازینگ شبکه است که درخواست‌های خام PCAPها را تغییر می‌دهد. این چارچوب توسط تیم امنیتی Cisco Talos توسعه داده شده است و از Radamsa (https://gitlab.com/akihe/radamsa) برای انجام جهش‌ها استفاده می‌کند. به عنوان یک فازینگ مبتنی بر جهش، فایل PCAP را به عنوان ورودی در نظر می‌گیرد و یک الگوی فازینگ مطابق با محتویات تولید می‌کند.

بنابراین Mutiny برای پروتکل‌های TCP یا UDP عمومی است و برای فازینگ پروتکل جعبه سیاه طراحی شده است تا بتواند VNFها را آزمایش کند. ما آن را به عنوان یک معیار برای نشان دادن عملکرد فازینگ جعبه بلوکی انتخاب می‌کنیم. ما Mutiny را با APIهای خود تطبیق می‌دهیم تا اطلاعات پوشش را بدون تغییر منطق فازینگ اصلی ثبت کنیم. این چارچوب می‌تواند تمام پروتکل‌های هدف SNMP، DHCP و NTPرا آزمایش کند. بازخورد-شورش Mutiny-FB بر اساس اطلاعات پوشش، ما Mutiny را با پشتیبانی از هدایت پوشش، بیشتر اصلاح کردیم. در واقع، ما یک صف اولویت‌دار برای ذخیره درخواست‌های جالب جهت هدایت جهش اضافه کردیم. اگر صف خالی باشد، منطق فازی اصلی را اجرا می‌کند.

ZDHCP بدون بازخورد ZDHCP-NFB -DHCP یک پروتکل محبوب برای دستگاه‌هایی است که از گزینه‌های مختلف برای نشان دادن عملکرد یک درخواست استفاده می‌کنند. کلاینت DHCP اطلاعات مختلفی را از طریق گزینه‌های مختلف از سرور DHCP درخواست می‌کند. سپس سرور DHCP گزینه‌ها و پاسخ‌ها را به کلاینت حل می‌کند. یک درخواست DHCP می‌تواند شامل چندین گزینه مختلف باشد که در RFC 2132 و موارد دیگر شرح داده شده است. بنابراین، ما ZDHCP را طوری طراحی و پیاده‌سازی کردیم که به جای جهش کاملاً تصادفی مانند Mutiny، بر جهش و ترکیب گزینه‌ها تمرکز کند.

شکل 4 ایده اصلی ZDHCP را نشان می‌دهد. در پیاده‌سازی ZDHCP، ما از ۱۱۹ گزینه پیاده‌سازی شده در scapy (https://scapy.net/) برای کمک به ساخت یک بسته DHCP قانونی استفاده می‌کنیم. ZDHCP به عنوان یک کلاینت برای فاز کردن سرور DHCP و به عنوان یک فازر جعبه سیاه عمل می‌کند که با APIهای NDFuzz نیز برای ثبت پوشش فرآیندهای هدف سازگار شده است.

بازخورد ZDHCP (ZDHCP-FB) همانطور که در بخش فرعی “راهبری فازینگ کامل” توضیح داده شد، ما یک لایه میانی را طراحی می‌کنیم تا با پیاده‌سازی‌های مختلف فازر پروتکل سازگار باشد. پیاده‌سازی رابط جهش و رابط ارسال در ZDHCP ساخته شده است. بنابراین، ادغام ZDHCP در NDFuzz آسان است. ما از پوشش برای هدایت جهش گزینه‌ها استفاده می‌کنیم. برای هر VNF که از SNMP پشتیبانی می‌کند، ما Mutiny-FB و Mutiny-NFB را با همان بذر (Seed) برای حداقل ۷۲ ساعت اجرا می‌کنیم.

بذرهای اولیه (Seeds) مربوط به SNMP مبتنی بر شناسه‌های شیء (OIDs) هستند که با استفاده از ابزار استاندارد snmpwalk به دست می‌آیند. ابزار snmpwalk با ارسال درخواست‌های SNMP_GET‑NEXT یک زیر‌درخت از مقادیر مدیریتی را بازیابی می‌کند. ما از این ابزار برای استخراج گره ریشه و به‌دست‌آوردن تمامی OIDهای مربوط به هر VNF استفاده می‌کنیم. سپس این OIDها را به قالب مورد استفاده Mutiny، یعنی فایل‌های PCAP، تبدیل می‌کنیم.

برای پروتکل DHCP، فازرهای Mutiny‑FB، Mutiny‑NFB، ZDHCP‑NFB و ZDHCP‑FB را با همان بذرهای اولیه اجرا می‌کنیم. از آنجا که ابزاری مشابه snmpwalk برای DHCP وجود ندارد، بذرهای اولیه DHCP را از دو طریق تهیه می‌کنیم: نخست، با جمع‌آوری درخواست‌ها در طول ارتباطات عادی شبکه، و دوم، با تولید درخواست‌ها بر اساس مشخصات پروتکل و سپس پالایش آن‌ها به‌گونه‌ای که تنها درخواست‌هایی که سرور DHCP به آن‌ها پاسخ می‌دهد، انتخاب شوند.

شکل ۵ روند پوشش یال‌ها (Edge Trend) طی ۷۲ ساعت فازینگ هر نمونه فازینگ را نشان می‌دهد. زیرشکل‌های (a) تا (i) مربوط به SNMP، زیرشکل‌های (j) تا (m) مربوط به DHCP و زیرشکل‌های (n) تا (r) مربوط به NTP هستند. شکل ۶ بهبود پوشش یال‌ها را برای موتورهای فازینگ مختلف در همان نمونه فازینگ نشان می‌دهد.

برای SNMP (شکل 6a)، مقایسه Mutiny بسیار مستقیم و گویا است؛ به‌طور متوسط، Mutiny-FB حدود ۵۶.۹۳٪ پوشش یال بیشتری نسبت به Mutiny-NFB ارائه می‌دهد که از ۹.۲۲٪ برای SG6000 تا ۱۰۶.۳۳٪ برای vMX متغیر است.

برای DHCP (شکل 6b)، مقایسه کمی پیچیده‌تر است زیرا چهار موتور فازینگ وجود دارد. به‌منظور مقایسه نتایج از جنبه‌های مختلف، ما چهار نوع مقایسه را به‌صورت زیر محاسبه کرده‌ایم:

1Mutiny-FB در مقابل Mutiny-NFB و ZDHCP-FB در مقابل ZDHCP-NFB Mutiny-FB به طور متوسط 03٪ بهبود نسبت به Mutiny-NFB از 7.33٪ SG6000 تا 68.32٪ FortiGate دارد. ZDHCP-FB به طور متوسط 66.58٪ بهبود نسبت به ZDHCP-NFB دارد. از 32.28٪ VyOS به 98.56٪ vMX مربوط به ZDHCP این مقایسه‌ها، همراه با نتایج SNMP، ثابت می‌کنند که راهنمای پوشش می‌تواند در واقع حاشیه امنیت را برای پروتکل‌ها و موتورهای فازینگ مختلف بهبود بخشد.
ZDHCP-NFB در مقابل Mutiny-NFB ZDHCP-NFB ما همچنین با میانگین بهبود 26.72٪ از 3.48٪ VyOS به 77.57٪ PSA، عملکرد بهتری نسبت به Mutiny-NFB دارد. این ثابت می‌کند که جهش متمرکز بر گزینه می‌تواند نمونه آزمایشی را تولید کند که شامل گزینه‌های پیچیده‌تر ساخته شده است.
ZDHCP-FB در مقابل Mutiny-FB با راهنمایی پوشش، ZDHCP-FB به طور متوسط 37٪ بهبود نسبت به Mutiny-FB دارد. این نشان می‌دهد که مزیت عملکرد ZDHCP توسط بازخورد بیشتر افزایش می‌یابد.
ZDHCP-FB در مقابل Mutiny-NFB در نهایت، ZDHCP-FB را با Mutiny-NFB مقایسه می‌کنیم تا بهبود حاصل از همکاری موتور فازینگ و راهنمایی پوشش را نشان دهیم. میانگین ۱۱۳.۶۷٪ است از ۳۶.۸۸٪ VyOS تا ۲۰۸.۸۲٪ مقایسه NTP شکل ۶c مشابه SNMP است، Mutiny-FB به طور متوسط ۲۷.۲۵٪ پوشش لبه بیشتری نسبت به Mutiny-NFB از ۴.۳۲٪ vMX تا ۷۲.۳۱٪ Fortinet انجام می‌دهد.

4.5 کشف آسیب‌پذیری

در طول ۷۲ ساعت فازینگِ ۱۳ نمونه مختلف، تعداد زیادی کرش (Crash) شناسایی شد و به‌صورت دستی تحلیل گردید. جدول ۵ جزئیات مربوط به این یافته‌ها را نشان می‌دهد. ما دو کرش منحصربه‌فرد در پروتکل DHCP و یک کرش در SNMP را تأیید کرده‌ایم. پس از گزارش این کرش‌ها به فروشندگان، دو مورد به‌عنوان آسیب‌پذیری روز صفر (VUL1) تأیید شدند و مورد دیگر (VUL2) قبلاً رفع شده بود. این سه آسیب‌پذیری تنها با ارسال یک درخواست فعال می‌شوند.

اگرچه این آسیب‌پذیری‌ها ابتدا در دستگاه‌های شبکه مجازی کشف شدند، مطابق پاسخ فروشندگان، بر دستگاه‌های شبکه فیزیکی نیز تأثیرگذار هستند.

VUL1 ابتدا توسط ZDHCP-NFB در 24.95 ساعت و توسط ZDHCP-FB در 9.97 ساعت یافت می‌شود. این نشان می‌دهد که راهنمای پوشش می‌تواند کشف آسیب‌پذیری را تسریع کند. VUL2 ابتدا توسط Mutiny-FB در 33.7 ساعت و توسط ZDHCP-FB در 1.34 ساعت یافت می‌شود. VUL2 علاوه بر نشان دادن مزیت راهنمای پوشش، ثابت می‌کند که ZDHCP سفارشی ما با صرفه‌جویی 96 درصدی در زمان، عملکرد بسیار بهتری نسبت به Fuzzer عمومی Mutiny دارد. در مقایسه با DHCP، SNMP محدودیت قالب‌بندی سختگیرانه‌ای دارد. اگرچه با توجه به راهنمایی‌های پوشش‌دهی، Mutiny فقط یک آسیب‌پذیری در مورد SNMP پیدا کرد، زیرا به دلیل رمزگذاری OID، تغییر یک بسته قانونی دشوار است. SNMP از شناسه شیء OID برای مدیریت اشیاء مختلف استفاده می‌کند و تجزیه OID بخش عمده‌ای از فرآیند SNMP را تشکیل می‌دهد. با این حال، OID با استفاده از قوانین رمزگذاری پایه BER رمزگذاری می‌شود که برآورده کردن آن با فازینگ تصادفی Mutiny دشوار است و جهش‌های متعددی در طول بررسی قالب‌بندی حذف می‌شوند.

جدول 6 آمار عملکرد مکانیسم‌های نظارت In-VMM و Out-of-VMM را نشان می‌دهد. در واقع، این نتیجه اولیه بدون حذف داده‌های تکراری است و نتیجه پس از حذف داده‌های تکراری در جدول 5 نشان داده شده است. ما فقط FortiGate و vEOS را فهرست می‌کنیم زیرا آنها تنها دو دستگاهی هستند که آسیب‌پذیری‌ها را پیدا کرده‌اند. این دو مکانیسم نظارت هیچ خرابی در 7 دستگاه دیگر را ثبت نمی‌کنند. اولاً، این جدول نشان می‌دهد که تعداد خرابی‌ها در DHCP با راهنمای پوشش به طور قابل توجهی افزایش یافته است (551 در مقابل 2395)، که همچنین اثربخشی راهنمای پوشش را نشان می‌دهد. ثانیاً، همانطور که در زیربخش نظارت بر یک برنامه Userland توضیح داده شده است، اگر نظارت InVMM نتواند بلافاصله یک خرابی را تشخیص دهد، نظارت Out-of-VMM می‌تواند آن را تشخیص دهد تا از منفی‌های کاذب جلوگیری کند، ستون‌های O ضرورت آن را نشان می‌دهند.

4.6 سربار ردیابی غیرتهاجمی

ارزیابی سربار به‌سادگی امکان‌پذیر نیست. اهداف معیارهای مرسوم فازینگ (Dolan‑Gavitt و همکاران، ۲۰۱۶؛ Hazimeh و همکاران، ۲۰۲۰) با سناریوی فازینگ فرایندهای daemon سازگار نیستند و افزون بر این، اغلب دستگاه‌های هدف ما قادر به اجرای آن‌ها نمی‌باشند. ازاین‌رو، ارزیابی را بر اساس پروتکل هدف SNMP انجام می‌دهیم که همواره می‌توان آن را با استفاده از ابزار استاندارد snmpwalk که خارج از دستگاه اجرا می‌شود، پیمایش کرد. با اندازه‌گیری هزینه اجرای snmpwalk، می‌توان سربار را به‌صورت واقع‌بینانه‌تری برآورد کرد.

ما زمان پردازش برنامه snmpd را برای ارتباطاتی که توسط snmpwalk برقرار می‌شوند به‌عنوان معیار (Benchmark) جمع‌آوری کرده و از آن برای محاسبه سربار از دو بُعد متفاوت استفاده می‌کنیم.

ما با هوک‌کردن تابع سوئیچینگ CR3، زمان کل اجرای تنها فرایند هدف snmpd و همچنین زمان کل اجرای سیستم‌عامل (شامل اجرای تمام فرایندها) را محاسبه می‌کنیم. به این ترتیب، می‌توانیم سربار را هم برای فرایند هدف به‌صورت مجزا و هم برای کل VNF (شامل همه فرایندها) محاسبه کنیم.

شکل ۷ آمار مربوط به سربار را نشان می‌دهد. برای هر دستگاه، میله آبی بیانگر سربار فرایند منفرد SNMP و میله نارنجی نشان‌دهنده سربار کل VNF است.

از نظر سربار ثبت یال‌های پوشش (edge recording)، سربار اعمال‌شده بر کل VNF در بازه ۳٫۰٪ (SG6000) تا ۲۴٫۵٪ (SMA) با میانگین ۱۱٫۷٪ قرار دارد که به‌طور معناداری کمتر از سربار فرایند هدف است؛ سربار فرایند هدف بین ۹٫۳٪ (SG6000) تا ۳۷٫۰٪ (SMA) با میانگین ۱۹٫۴٪ متغیر است.

دلیل این تفاوت آن است که QEMU سفارشی‌شده تنها فرایند هدف و تعداد محدودی از دستورهای هسته را ردیابی می‌کند، در حالی که اجرای سایر فرایندها و بخش عمده‌ای از دستورهای هسته تحت تأثیر قرار نمی‌گیرند. از آنجا که در سناریوی واقعی فازینگ، سربار در سطح کل VNF معیار مهم‌تری محسوب می‌شود، این میزان سربار برای انجام فازینگ قابل قبول ارزیابی می‌شود.

4.7 مطالعه موردی

در این بخش، یک مطالعه موردیِ تفصیلی درباره آسیب‌پذیری VUL2 ارائه می‌کنیم تا نقش و تأثیر راهنمایی مبتنی بر پوشش (coverage guidance) روشن شود. برای این منظور، دو پیکربندی ZDHCP-NFB (بدون بازخورد) و ZDHCP-FB (با بازخورد پوشش) را با یکدیگر مقایسه می‌کنیم تا نشان دهیم کشف آسیب‌پذیری VUL2 بدون استفاده از بازخورد پوشش، به‌مراتب دشوار است.

اگرچه VUL2 یک آسیب‌پذیری 1‑Day محسوب می‌شود، اما از نظر فنی بسیار قابل‌توجه است، زیرا ریشه آن به سرریز در بخش داده‌ها (Data Section Overflow) بازمی‌گردد. شکل ۸ توصیف انتزاعی این آسیب‌پذیری را نشان می‌دهد. همان‌طور که شکل فرعی (b) مشاهده می‌شود، دو آرایه مجاور به نام‌های content_buffer و format_buffer وجود دارند. آرایه format_buffer یک رشته قالب (Format String) مانند “%s,%d” را ذخیره می‌کند و content_buffer رشته فرمت‌شده‌ای را نگه می‌دارد که متناظر با format_buffer است.

زمانی که فرایند DHCP یک درخواست DHCP دریافت می‌کند، ابتدا هر گزینه (Option) را تجزیه کرده و سپس توابع مرتبط را فراخوانی می‌نماید. در حالت عادی، نوع گزینه‌ها با یکدیگر متفاوت هستند، اما ZDHCP قادر است درخواست‌هایی را جهش دهد که شامل گزینه‌هایی با نوع یکسان باشند (که به اختصار dup-options نامیده می‌شوند). فرایند DHCP تمامی گزینه‌های هم‌نوع را جمع‌آوری کرده و مقادیر آن‌ها را به‌صورت یک مقدار واحد به هم متصل (Concatenate) می‌کند تا dup-options را پردازش نماید. توابع merge_duplicated_options() و log_duplicated_options() در شکل فرعیa این روند را نشان می‌دهند.

ریشه اصلی آسیب‌پذیری، عدم بررسی طول داده پس از عملیات الحاق مقادیر است. زمانی که مقدار نهایی در content_buffer ذخیره می‌شود، ممکن است یک سرریز بافر در بخش داده‌ها توسط تابع vsprintf() رخ دهد. در طول فرآیند جهش‌دهی (Mutation)، محتوای داده سرریز می‌تواند تغییر کند و در نتیجه، آرگومان format_string تابع vsprintf() در حین اجرای این تابع تغییر کرده و در نهایت باعث کرش فرایند شود.

شکل فرعیd تحول جهش (Mutation Evolution) را نشان می‌دهد و نواحی رنگی وضعیت بافرها پس از پردازش هر درخواست را مشخص می‌کنند. بر اساس یک درخواست اولیه I، اولین گره جهش D شامل گزینه‌هایی از نوع تکراری (duplicated type) است. پردازش D تابع log_duplicated_options() را فراخوانی می‌کند و بافرها به‌درستی پر می‌شوند و سرریز رخ نمی‌دهد.

سپس یک درخواست پیچیده‌تر C می‌تواند بر اساس D تکامل یابد و شامل مقادیر گزینه‌ای پیچیده‌تر باشد. این جهش باعث می‌شود محتوای بیشتری در content_buffer ذخیره شود و ممکن است منجر به سرریز به format_buffer شود. با این حال، اگر کاراکتر ویژه‌ای باعث سرریز format_buffer نشود، این سرریز ممکن است کرش ایجاد نکند. این تکرار (Iteration) به دلیل پردازش گزینه‌ها و الحاق مقادیر، تعداد یال‌های پوشش بیشتری نسبت به D ایجاد می‌کند.

جهش مبتنی بر C ممکن است به‌تدریج محتوا و طول داده‌ها را تغییر دهد تا به درخواست مهم نهایی C_c برسد. این جهش شامل چندین placeholder قالب مانند “%s” و موارد دیگر است که باعث می‌شود تابع vsprintf() به آدرس غیرمجاز دسترسی پیدا کند و کرش ایجاد شود.

جدول ۷ نسبت انواع مختلف درخواست‌ها در زیرشکل (d) را برای ZDHCP-NFB و ZDHCP-FB مقایسه می‌کند. بذر اولیه شامل ۳ گروه است که به ترتیب شامل ۵، ۱۰ و ۲۰ درخواست با نوع گزینه یکسان هستند تا تمرکز بر کشف VUL2 حفظ شود. هر موتور فازینگ حداکثر ۱ ساعت تست می‌کند و زمانی متوقف می‌شود که VUL2 فعال شود.

اگرچه هر دو موتور ZDHCP-FB و ZDHCP-NFB قادر به جهش دادن درخواست‌های نوع D و C هستند، موتور با بازخورد پوشش (FB) احتمال بسیار (4.9x, 8.1x, 9.3x) برای جهش دادن درخواست‌های نوع C نسبت به NFB دارد.

5. بحث

یکپارچه‌سازی فازرهای شناخته‌شده – ما فازرهای جعبه خاکستریِ شناخته‌شده‌ای مانند AFL++، AFL و موارد مشابه را به‌طور مستقیم در NDFuzz ادغام نکرده‌ایم. دلیل اصلی این است که این فازرها اساساً برای سرویس‌های شبکه‌ای طراحی نشده‌اند و جریان کاری فازینگ آن‌ها تفاوت اساسی با سناریوی فازینگ VNFها دارد. علاوه بر این، این ابزارها معمولاً برای استخراج پوشش اجرا به ابزارگذاری ایستا یا ابزارگذاری پویای باینری در حالت user-mode QEMU متکی هستند؛ رویکردی که با محدودیت‌های VNFها از جمله بسته‌بودن کد منبع، مکانیزم‌های حفاظتی قوی و اجرا در قالب QEMU system-mode سازگار نیست.

اگرچه AFLNET ‏(Pham et al., 2020) به‌طور خاص بر فازینگ پروتکل‌های شبکه تمرکز دارد، اما همچنان برای به‌دست‌آوردن پوشش اجرا به کد منبع وابسته است. در مقابل، NDFuzz قادر است پوشش اجرا را بدون نیاز به کد منبع استخراج کند و از نظر مفهومی می‌توان این مکانیزم را برای AFLNET نیز تطبیق داد؛ با این حال، انجام این کار مستلزم بازطراحی اساسی کل جریان فازینگ است، به‌ویژه در بخش پیاده‌سازی fork server و نحوه تعامل با شبیه‌سازی سطح سیستم QEMU (به‌جای شبیه‌سازی سطح کاربر در حالت AFL-QEMU). چنین تغییری برای سازگاری با VNFها کاری غیرساده و پرهزینه محسوب می‌شود.

در آینده، ما قصد داریم این فازرهای مطرح که عمدتاً برای نرم‌افزارهای متن‌باز طراحی شده‌اند را در NDFuzz یکپارچه کنیم تا از راهبردهای پیشرفته‌تر فازینگ آن‌ها برای تحلیل و کشف آسیب‌پذیری در VNFها بهره‌برداری شود.

5.1 پروتکل‌های وضعیت‌مند (Stateful Protocols)

ما در این کار، فازینگ پروتکل‌های وضعیت‌مند را مدنظر قرار نداده‌ایم، زیرا این موضوع خود یک بُعد مستقل در فازینگ پروتکل‌ها محسوب می‌شود. با این حال، VNFها مجموعه‌ داده‌ای بسیار مناسب برای این هدف هستند، به‌ویژه در مورد پروتکل‌های لایه کنترل‌ (control plane) مانند BGP، OSPF و پروتکل‌های مشابه. چارچوب NDFuzz این قابلیت را دارد که در کارهای آینده برای این نوع پروتکل‌ها تطبیق داده شود و پوشش کد را با وضعیت‌های پروتکل به‌صورت ترکیبی مورد استفاده قرار دهد.

5.2 قابلیت‌های سخت‌افزاری (Hardware Assistance)

پیاده‌سازی QEMU سفارشی‌شده در NDFuzz مبتنی بر TCG است و نه KVM، زیرا راهکار KVM مستلزم تغییر در کرنل میزبان بوده و برای جمع‌آوری اطلاعات زمان اجرا از فرایندهای userland به Intel PT وابسته است. رویکرد مبتنی بر TCG محدودیت‌های کمتری دارد، در حالی که استفاده از KVM می‌تواند کارایی بالاتری ارائه دهد. بررسی و ادغام این رویکرد به‌عنوان یکی از مسیرهای کارهای آینده برای بهبود NDFuzz در نظر گرفته شده است.

5.3 تطبیق معماری (Architecture Adaptation)

ما هیچ VNFی را که بر معماری‌هایی غیر از x86 و x86_64 اجرا شود مشاهده نکرده‌ایم، با این حال روش پیشنهادی ما ماهیتی عمومی دارد و NDFuzz می‌تواند با تغییرات جزئی برای معماری‌های دیگر نیز تطبیق داده شود.

5.4 تطبیق پروتکل (Protocol Adaptation)

دستگاه‌های شبکه مجازی‌شده شامل پروتکل‌های متعددی هستند، اما در این کار تنها سفارشی‌سازی فازر برای پروتکل DHCP پیاده‌سازی شده است. در آینده، ما قصد داریم فازرهای سفارشی بیشتری برای پروتکل‌های خاص توسعه دهیم تا دامنهٔ کاربرد NDFuzz گسترش یابد.

6. کارهای مرتبط (Related Work)

فازینگ غیرتهاجمی دستگاه‌های شبکه مجازی‌شده ترکیبی از چندین تکنیک مستقل در حوزه تحقیق امنیتی است. تکنیک‌های مرتبط‌تر شامل Virtual Machine Introspection (VMI) و چند پروژه فازینگ جعبه خاکستری با کمک هایپروایزر هستند، اما هیچ‌کدام قادر به رفع کامل نیازمندی‌های ما نیستند.

6.1 مجازی‌سازی عملکرد شبکه (Network Function Virtualization)

تجهیزات شبکه برای مدت طولانی، خدمات شبکه را به‌صورت سخت‌افزار اختصاصی و نرم‌افزار سفارشی ارائه می‌دادند. این موضوع باعث ایجاد مشکل موسوم به Network Ossification می‌شود و افزودن سرویس‌ها یا ارتقای شبکه را دشوار می‌کند (لی و همکارانش، ۲۰۱۸). برای غلبه بر این مشکلات، مؤسسه اروپایی استانداردهای مخابراتی (ETSI) مفهوم Network Function Virtualization یا NFV را پیشنهاد داد تا عملکردهای شبکه‌ای که قبلاً توسط سخت‌افزار اختصاصی و ویژه ارائه می‌شدند، به‌صورت مجازی پیاده‌سازی شوند (Paper 2012).

به‌عنوان یکی از سه جزء اصلی چارچوب NFV، عملکردهای شبکه مجازی (VNF – Virtualized Network Functions) نسخه‌های نرم‌افزاری از دستگاه‌های شبکه هستند که می‌توانند بر روی زیرساخت مجازی‌سازی عملکرد شبکه (NFVI) مستقر شوند. اجزای VNF متنوع هستند و شامل روتر، سوئیچ، گیت وی‌های SSL VPN، اسکنرهای ویروس و غیره می‌شوند.

تولیدکنندگان مطرحی مانند Cisco، Juniper، Fortinet و دیگران، محصولات NFV خود را ارائه کرده و نسخه‌های مجازی این دستگاه‌ها را در دسترس قرار داده‌اند. نرم‌افزار VNF دقیقاً مشابه نرم‌افزار دستگاه فیزیکی هم‌مدل خود است.

در واقع، VNF می‌تواند به طور جداگانه به عنوان یک دستگاه شبکه مجازی با کمک هایپروایزرهایی مانند QEMU/KVM، VMware و Hyper-V روی رایانه COTS مستقر شود. از دیدگاه تحقیقات امنیتی، یک شبکه مجازی را می‌توان با روش فازینگ جعبه سیاه به عنوان یک دستگاه شبکه فیزیکی برای پیکربندی و عملکردهای مشابه آزمایش کرد. با این حال، دستگاه شبکه مجازی شده را می‌توان به عنوان یک ماشین مجازی نیز در نظر گرفت. بدیهی است که می‌توانیم با کمک هایپروایزر سفارشی، اطلاعات زمان اجرا بیشتری نسبت به دستگاه شبکه فیزیکی به دست آوریم و فازینگ جعبه سیاه را به فازینگ جعبه خاکستری هدایت‌ شده با پوشش تبدیل کنیم.

6.2 بازرسی ماشین مجازی و تحلیل حافظه (Virtual Machine Introspection and Memory Analysis)

طی چند دهه گذشته، تکنیک مجازی‌سازی به‌طور گسترده‌ای در حوزه‌های مختلف، به‌ویژه رایانش ابری و مراکز داده استفاده شده است. هایپروایزر (VMM) به‌عنوان زیرساخت این تکنیک که در سطح پایین سیستم‌عامل قرار دارد، امکان انتقال نظارت سیستم را از روش‌های سنتی درون VM (In-VM) به روش‌های خارج از VM (Out-of-VM) فراهم کرده است، که به آن بازرسی ماشین مجازی یا Virtual Machine Introspection (VMI) گفته می‌شود.

با استخراج و بازسازی وضعیت‌های سیستم‌عامل مهمان (Guest OS) در میزبان (Host)، VMI از مزایای ایزولاسیون و مدیریت توسط هایپروایزر بهره می‌برد و به‌طور گسترده در کاربردهای امنیتی مورد استفاده قرار گرفته است، از جمله:

شناسایی نفوذ (Intrusion Detection) – (Payne و همکاران، ۲۰۰۸)
تحلیل بدافزار (Malware Analysis) – (Dolan-Gavitt و همکاران، ۲۰۱۱؛ Fu و Lin، ۲۰۱۲، https://github.com/Cisco-Talos/pyrebox)
مدیریت ماشین مجازی- (Virtual Machine Management) – (Sharif و همکاران، ۲۰۰۹؛ Srinivasan و همکاران، ۲۰۱۱، https://libvmi.com/)
فارنزیک حافظه (Memory Forensics) – (Fu و Lin، ۲۰۱۲ ، https://github.com/volatilityfoundation/volatility)

ابزارها و پروژه‌های متن‌باز مرتبط شامل PyReBox، LibVMI و Volatility هستند که در گیت‌هاب قابل دسترس می‌باشند.

یکی از چالش‌های شناخته‌شده در VMI، مسئله شکاف معنایی (Semantic Gap) است (Dolan-Gavitt و همکاران، ۲۰۱۱)، که استخراج اطلاعات سطح بالای معنایی مانند اطلاعات فرایندهای مهمان از داده‌های سطح پایین مانند dump حافظه سیستم‌عامل را دشوار می‌کند.

یکی از راه‌حل‌های رایج، استفاده از ساختارهای داده کرنل است که از طریق تحلیل کد منبع یا اجرای درایورهای خاص به‌دست می‌آیند (Wang و همکاران، ۲۰۱۵؛ LibVMI؛ PyReBox؛Volatility).

ابزارهایی مانند Virtuoso (Dolan-Gavitt و همکاران، ۲۰۱۱) و VMST (Fu و Lin، ۲۰۱۲) با بازاستفاده مستقیم از باینری‌های برنامه‌های بازرسی بومی (مانند ps یا lsmod) سعی می‌کنند شکاف معنایی را بدون نیاز به ساختار داده‌های کرنل پر کنند. با این حال، این روش‌ها سربار عملکرد زیادی ایجاد می‌کنند.

Hybrid-Bridge (Saberi و همکاران، ۲۰۱۴) با ترکیب آموزش آفلاین Virtuoso و هدایت داده‌های کرنل VMST، عملکرد را بهبود می‌بخشد. این روش مستلزم آن است که VMهای مورد اعتماد (Fast-Bridge و Slow-Bridge) نسخه همان سیستم‌عامل VMهای غیرمطمئن را اجرا کنند.

تکنیک‌های تحلیل حافظه و تکنیک‌های VMI در زمینه استخراج اطلاعات معنایی (semantic information) دارای اشتراکات گسترده‌ای هستند. تفاوت اصلی این است که تحلیل حافظه بیشتر بر استخراج اطلاعات معنایی از طریق تحلیل ایستا (Static Analysis) تمرکز دارد، مانند:

مهندسی معکوس (Reverse Engineering) – (Case و همکاران، ۲۰۱۰)
استفاده از امضاهای داده‌ای (Data Signatures) برای استخراج اطلاعات معنایی کرنل – (Lin و همکاران، ۲۰۱۱؛ Dolan-Gavitt و همکاران، ۲۰۰۹)

ابزارهایی مانند Firmadyne (Socałaو Cohen، ۲۰۱۶) روشی مستقیم مبتنی بر شبیه‌سازی-کامپایل (emulating-compilation) ارائه می‌دهند تا با توجه به نسخه و فایل پیکربندی، چیدمان ساختارها (struct layout) پیش‌بینی شود و اطلاعات معنایی دقیق به‌دست آید.

ابزار ORIGEN (Feng و همکاران، ۲۰۱۶) با ترکیب تحلیل جریان داده (Data Flow Analysis) و جستجوی باینری، سعی می‌کند برخی دستورات نشان‌دهنده offset را در نسخه‌های مختلف استخراج کند. با این حال، امضاهای یک نسخه منفرد و روش جستجوی دستورات ممکن است در مواجهه با نسخه‌های بسیار متفاوت قابل اعتماد نباشند.

6.3 فازینگ جعبه خاکستری (Graybox) با هایپروایزر

تکنیک فازینگ جعبه خاکستری در میانه فازینگ جعبه سیاه (Beizer ۱۹۹۵; Myers و همکاران ۲۰۰۴) و فازینگ جعبه سفید (Godefroid و همکاران ۲۰۰۸) قرار دارد. فازینگ‌های Greybox از اطلاعات زمان اجرا مانند پوشش کد برای هدایت اجرای فازینگ استفاده می‌کنند. فازینگ مدرن معروف AFL (http://lcamtuf.coredump.cx/afl/) دو راه برای جمع‌آوری اطلاعات زمان اجرا ارائه می‌دهد: ابزار دقیق ایستا برای هدف منبع باز یا ابزار دقیق پویا برای هدف منبع بسته (باینری). ابزار دقیق پویا به مکانیزم تولیدکننده کد کوچک (TCG) QEMU (Bellard 2005) بستگی دارد.

فازینگ دودویی AFL در حالت کاربر QEMU کار می‌کند که می‌تواند یک فرآیند واحد را اجرا کند. با این حال، برای سناریوهای مربوط به سیستم عامل در حال اجرا مانند فازینگ هسته یا سیستم عامل شبیه‌سازی شده محدود است. TriforceAFL (https://github.com/nccgroup/TriforceAFL) و kAFL (Schumilo و همکاران، ۲۰۱۷) اطلاعات پوشش را با سفارشی‌سازی هایپروایزر برای فازینگ هسته بدون کد منبع به دست می‌آورند. REDQUEEN (Aschermann و همکاران، ۲۰۱۹) که بر اساس kAFL توسعه یافته است، می‌تواند برنامه فضای کاربری را با راهنمایی پوشش با حالت سیستم QEMU فازینگ کند.

با کمک هایپروایزر، می‌تواند کد مربوط به بررسی‌های مجموع کنترلی را اصلاح کند. Firm-AFL (Zheng et al. 2019) که بر اساس Firmadyne (Chen et al. 2016) و DECAF (Henderson et al. 2014) ساخته شده است، از هایپروایزر برای مدیریت پشتیبانی I/O و syscall استفاده می‌کند. فازینگ می‌تواند با هزینه کمی از تجهیزات سبک، از هایپروایزر بهره ببرد. اگرچه فازینگ جعبه خاکستری با هایپروایزر و VMI هر دو از هایپروایزر برای نظارت بر اطلاعات زمان اجرای مهمان استفاده می‌کنند، اما به دلیل هدف متفاوت هستند. برخلاف تکنیک VMI که با دیدگاه کلان به دنبال است، فازینگ همیشه بر اطلاعات زمان اجرا مانند پوشش و وضعیت فرآیند یک فرآیند یا ماژول واحد تمرکز می‌کند. در واقع، فازینگ با هایپروایزر فقط از زیرمجموعه کوچکی از اطلاعات معنایی VMI استفاده می‌کند، بنابراین می‌توان شکاف معنایی را با هزینه قابل قبولی حل کرد.

6.4 فازینگ دستگاه‌های تعبیه‌ شده

در واقع، ارتباط دستگاه‌های تعبیه‌شده با فازینگ مشابه دستگاه‌های شبکه است. در سال‌های اخیر چندین کار بر اساس ارتباطات شبکه‌ای انجام شده است. IoTFuzzer (Chen و همکاران، ۲۰۱۸) با هدف یافتن خرابی‌های حافظه بر اساس اتصال منطق ارتباطی برنامه‌های مرتبط اندروید طراحی شده است. SRFuzzer (Zhang و همکاران، ۲۰۱۹) یک چارچوب فازینگ خودکار جعبه سیاه برای کشف آسیب‌پذیری‌های چند نوع است. کاستی‌های فازینگ جعبه سیاه مدت‌هاست که مورد بحث قرار گرفته است. بنابراین، Snipuzz (Feng و همکاران، ۲۰۲۱) روشی را برای استنباط ردپاهای در حال اجرا با تجزیه و تحلیل محتوای پاسخ برای غلبه بر این محدودیت‌ها پیشنهاد می‌کند. اثربخشی آن به کیفیت پیام‌های sni بستگی دارد.

ppets که به میزان اطلاعات قابل دریافت از پاسخ‌های دستگاه‌ها بستگی دارد. بنابراین، در پروتکل‌های متعددی که این ویژگی را ندارند (مانند SNMP، DHCP، NTP و موارد دیگر) محدود است. Firm-AFL (Zheng و همکاران، 2019) ردیابی کامل را با بیت‌مپ به سبک AFL با شبیه‌سازی پشتیبانی شده توسط Firmadyne (Chen و همکاران، 2016) جمع‌آوری می‌کند. محیط شبیه‌سازی با یک هسته سفارشی قابل کنترل است که نمی‌تواند توسط VNFها برآورده شود.

7. نتیجه‌گیری

ما در این مقاله، یک مکانیزم سبک برای استنتاج PGD ارائه کردیم که مبتنی بر تحلیل تفاضلی (Differential Analysis) است و هیچ عملیات تهاجمی (Intrusive) انجام نمی‌دهد. ما با استفاده از مقادیر PGD هدف، یک چارچوب ماژولار به نام NDFuzz معرفی کردیم که امکان فازینگ غیرتهاجمی دستگاه‌های شبکه مجازی‌شده با هدایت پوشش (Coverage-Guided Fuzzing) را فراهم می‌سازد.

ما همچنین با استفاده از NDFuzz، نُه VNF محبوب از هفت تولیدکننده مختلف را فازینگ کردیم و در نهایت، طی ۷۲ ساعت فازینگ با چهار موتور فازینگ مختلف، موفق به کشف ۳ آسیب‌پذیری شدیم.

8. منابع

				
					1. Aschermann C, Schumilo S, Blazytko T, Gawlik R, Holz T (2019) Redqueen: fuzzing with input-to-state correspondence. In: NDSS, vol 19, pp 1–15
2. Beizer B (1995) Black-box testing: techniques for functional testing of software and systems. Wiley, New York Bellard F (2005) Qemu, a fast and portable dynamic translator. In: USENIX annual technical conference, FREENIX Track, California, USA, vol 41, p 46
3. Böhme M, Pham V-T, Roychoudhury A (2017) Coverage-based Greybox fuzzing as Markov chain. IEEE Trans Softw Eng 45(5):489–506
4. Carbone M, Conover M, Montague B, Lee W (2012) Secure and robust monitoring of virtual machines through guest-assisted introspection. In: International workshop on recent advances in intrusion detection. Springer, pp 22–4
5. Case A, Marziale L, Richard GG III (2010) Dynamic recreation of kernel data structures for live forensics. Digit Investig 7:32–40
6. Chen DD, Woo M, Brumley D, Egele M (2016) Towards automated dynamic analysis for Linux-based embedded firmware. In: NDSS, vol 1, pp 1
7. Chen J, Diao W, Zhao Q, Zuo C, Lin Z, Wang X, Lau WC, Sun M, Yang R, Zhang K (2018) Iotfuzzer: Discovering memory corruptions in IoT through app- based fuzzing. In: NDSS
8. Cisco-Talos: mutiny fuzzing framework. https:// github. com/ Cisco-Talos/mutiny- fuzzer
9. Compare coverage for AFL++ QEMU. https:// andre afior aldi. github. io/ artic les/2019/ 07/ 20/ aflpp-qemu-compc ov. html
10. Dolan-Gavitt B, Srivastava A, Traynor P, Giffin J (2009) Robust signatures for
11. kernel data structures. In: Proceedings of the 16th ACM conference on computer and communications security, pp 566–577
12. Dolan-Gavitt B, Leek T, Zhivich M, Giffin J, Lee W (2011) Virtuoso: narrowing the
13. semantic gap in virtual machine introspection. In: 2011 IEEE symposium on security and privacy. IEEE, pp 297–312
14. Dolan-Gavitt B, Hulin P, Kirda E, Leek T, Mambretti A, Robertson W, Ulrich F,
15. Whelan R (2016) Lava: large-scale automated vulnerability addition. In:2016 IEEE symposium on security and privacy (SP), pp 110–121. https://doi. org/ 10. 1109/ SP. 2016. 15
16. Feng Q, Prakash A, Wang M, Carmony C, Yin H (2016) Origen: automatic extraction of offset-revealing instructions for cross-version memory analysis. In: Proceedings of the 11th ACM on Asia conference on computer and communications security, pp 11–22
17. Feng X, Sun R, Zhu X, Xue M, Wen S, Liu D, Nepal S, Xiang Y (2021) Snipuzz:black-box fuzzing of IoT firmware via message snippet inference. arXiv: 2105. 05445
18. Fioraldi A, Maier D, Eißfeldt H, Heuse M (2020) Afl++: combining incremental steps of fuzzing research. In: 14th {USENIX} workshop on offensive technologies ( {WOOT} 20)
19. Fu Y, Lin Z (2012) Space traveling across vm: automatically bridging the semantic gap in virtual machine introspection via online kernel data redirection. In: 2012 IEEE symposium on security and privacy. IEEE, pp 586–600
20. Gan S, Zhang C, Qin X, Tu X, Li K, Pei Z, Chen Z (2018) Collafl: path sensitive fuzzing. In: 2018 IEEE symposium on security and privacy (SP). IEEE, pp 679–696
21. Gao Z, Dong W, Chang R, Wang Y (2020) Fw-fuzz: a code coverage-guided fuzzing framework for network protocols on firmware. Concurr Comput Pract Exp
22. Godefroid P, Levin MY, Molnar DA et al (2008) Automated whitebox fuzz testing. In: NDSS , vol 8, pp 151–166
23. Han B, Gopalakrishnan V, Ji L, Lee S (2015) Network function virtualization: challenges and opportunities for innovations. IEEE Commun Mag 53(2):90–97. https:// doi. org/ 10. 1109/ MCOM. 2015. 70453 96
24. Hazimeh A, Herrera A, Payer M (2020) Magma: a ground-truth fuzzing benchmark. In: Proceedings of the ACM on measurement and analysis of computing systems, vol 4, no 3. https:// doi. org/ 10. 1145/ 34283 34
25. Helin A. Radamsa, a general-purpose fuzzer. https:// gitlab. com/ akihe/ radam sa
26. Henderson A, Prakash A, Yan LK, Hu X, Wang X, Zhou R, Yin H (2014) Make it work, make it right, make it fast: building a platform-neutral whole- system dynamic binary analysis platform. In: Proceedings of the 2014 international symposium on software testing and analysis, pp 248–258
27. Jain B, Baig MB, Zhang D, Porter DE, Sion R (2014) Sok: introspections on trust and the semantic gap. In: 2014 IEEE symposium on security and privacy. IEEE, pp 605–62
28. Li J, Zhao B, Zhang C (2018) Fuzzing: a survey. Cybersecurity 1(1):1–13 LibVMI. https:// libvmi. com/
29. Lin Z, Rhee J, Zhang X, Xu D, Jiang X (2011) Siggraph: brute force scanning of kernel data structure instances using graph-based signatures. In: Ndss
30. Lyu C, Ji S, Zhang C, Li Y, Lee W-H, Song Y, Beyah R (2019) {MOPT}: optimized mutation scheduling for fuzzers. In: 28th {USENIX} security symposium ( {USENIX} security 19), pp 1949–1966
31. Manès VJM, Han H, Han C, Cha SK, Egele M, Schwartz EJ, Woo M (2019) The art, science, and engineering of fuzzing: a survey. IEEE Trans Softw Eng 47:2312–2331
32. Mijumbi R, Serrat J, Gorricho J-L, Bouten N, De Turck F, Boutaba R (2016) 
33. Network function virtualization: state-of-the-art and research challenges.
34. IEEE Commun Surv Tutor 18(1):236–262. https:// doi. org/ 10. 1109/ COMST. 2015. 24770 41
35. Muench M, Stijohann J, Kargl F, Francillon A, Balzarotti D (2018) What you corrupt is not what you crash: Challenges in fuzzing embedded devices. In:
36. Network and distributed system security symposium (NDSS)
37. Myers GJ, Badgett T, Thomas TM, Sandler C (2004) The art of software testing, vol 2. Wiley, New York
38. NCCGroup: Project Triforce: run AFL on everything! https:// github. com/ nccgroup/ Trifo rceAFL
39. Paper NW (2012) Network functions virtualisation: an introduction, benefits, enablers, challenges &amp; call for action. Issue 1
40. Payne BD, Carbone M, Sharif M, Lee W (2008) Lares: an architecture for secure active monitoring using virtualization. In: 2008 IEEE symposium on security and privacy (sp 2008). IEEE, pp 233–247
41. Pham V-T, Böhme M, Roychoudhury A (2020) Aflnet: a greybox fuzzer for network protocols. In: 2020 IEEE 13th international conference on software testing, validation and verification (ICST). IEEE, pp 460–465
42. PyREBox. https:// github. com/ Cisco-Talos/ pyreb ox
43. Rawat S, Jain V, Kumar A, Cojocar L, Giuffrida C, Bos H (2017) Vuzzer: application-aware evolutionary fuzzing. In: NDSS, vol 17, pp 1–14
44. Saberi A, Fu Y, Lin Z (2014) Hybrid-bridge: efficiently bridging the semantic gap in virtual machine introspection via decoupled execution and training memoization. In: Proceedings of the 21st annual network and distributed system security symposium (NDSS’14)
45. Scapy. https:// scapy. net/
46. Schumilo S, Aschermann C, Gawlik R, Schinzel S, Holz T (2017) kafl: hardware assisted feedback fuzzing for {OS} kernels. In: 26th {USENIX} security symposium ( {USENIX} security 17), pp 167–182 Sharif MI, Lee W, Cui W, Lanzi A (2009) Secure in-vm monitoring using hardware virtualization. In: Proceedings of the 16th ACM conference on computer and communications security, pp 477–487 snmpwalk. https:// linux. die. net/ man/1/ snmpw alk
47. Socała A, Cohen M (2016) Automatic profile generation for live Linux memory analysis. Digit Investig 16:11–24
48. Srinivasan D, Wang Z, Jiang X, Xu D (2011) Process out-grafting: an efficient “out-of-vm” approach for fine-grained process execution monitoring. In: Proceedings of the 18th ACM Conference on computer and communications security, pp 363–374
49. Volatility framework—volatile memory extraction utility framework. https://github. com/ volat ility found ation/ volat ility
50. Wang G, Estrada ZJ, Pham C, Kalbarczyk Z, Iyer RK (2015) Hypervisor introspection: a technique for evading passive virtual machine monitoring. In: 9th {USENIX} workshop on offensive technologies ( {WOOT} 15)
51. Yan LK, Yin H (2012) Droidscope: seamlessly reconstructing the {OS} and dalvik semantic views for dynamic android malware analysis. In: 21st {USENIX} security symposium ( {USENIX} security 12), pp 569–584
52. Yue T, Wang P, Tang Y, Wang E, Yu B, Lu K, Zhou X (2020) Ecofuzz: adaptive energy-saving greybox fuzzing as a variant of the adversarial multi-armed bandit. In: 29th {USENIX} security symposium ( {USENIX} security 20), pp 2307–2324
53. Zalewski M. American fuzzy lop. http:// lcamt uf. cored ump. cx/ afl/
54. Zhang Y, Huo W, Jian K, Shi J, Lu H, Liu L, Wang C, Sun D, Zhang C, Liu B (2019)
55. Srfuzzer: an automatic fuzzing framework for physical SOHO router devices to discover multi-type vulnerabilities. In: Proceedings of the 35th annual computer security applications conference, pp 544–556
56. Zheng Y, Davanian A, Yin H, Song C, Zhu H, Sun L (2019) Firm-afl: high throughput greybox fuzzing of iot firmware via augmented process emulation. In: 28th {USENIX} security symposium ( {USENIX} security 19), pp 1099–1114

NDFuzz: یک چارچوب غیرتهاجمی برای فازینگ هدایت‌ شده با پوشش در تجهیزات شبکه مجازی‌سازی‌ شده

NDFuzz: a non-intrusive coverage-guided fuzzing framework for virtualized network devices