otsmr/blackbox-fuzzingاختبار Fuzzing لأجهزة إنترنت الأشياء باستخدام الراوتر TL-WR902AC كمثال
هذه هي نسخة HTML من ورقة الفصل الدراسي الخاصة بي والتي يمكن تنزيلها كملف PDF هنا.
أصبحت التغذية العشوائية (Fuzzing) "واحدة من أكثر الطرق فعالية" لاكتشاف الأخطاء في البرمجيات. وبهذا الادعاء أو بأدعاءات مشابهة، تبدأ العديد من الأوراق البحثية الحالية المتعلقة بالتغذية العشوائية [google-scholar]. كان الهدف الرئيسي من ورقة الفصل الدراسي السابقة حول موضوع "إنترنت الأشياء الهشّة" هو إيجاد خطأ متعلق بالذاكرة ثم كتابة استغلال لهذه الثغرة. وقد تمكّنّا من إيجاد ثغرة عبر عكس هندسة البرنامج الثابت (firmware)، لكن لم يتم العثور على أخطاء متعلقة بالذاكرة. إن إيجاد تجاوز سعة المخزن المؤقت عن طريق عكس هندسة ملف ثنائي يدويًا ليس فقط مستهلكًا للوقت، بل يتطلب أيضًا الكثير من الخبرة. وفي الوقت نفسه، تهدف التغذية العشوائية إلى أن تكون "الطريقة الأكثر فعالية" لإيجاد مثل هذه الثغرات المرتبطة بالذاكرة فعلى سبيل المثال، قدّمت Google أداة OSS-Fuzz التي تقوم باستمرار بالتغذية العشوائية للبرمجيات مفتوحة المصدر وقد وجدت بالفعل أكثر من 10,000 ثغرة عبر 1,000 مشروع [oss-fuzz].
الهدف من ورقة الفصل الدراسي هذه هو مرة أخرى إيجاد ثغرة متعلقة بالذاكرة، لكن هذه المرة باستخدام التغذية العشوائية. يجب أن تكون الثغرة المستهدفة قابلة للاستغلال عبر الشبكة دون معرفة بيانات اعتماد المسؤول. تصف هذه الورقة الطريقة لتحقيق هذا الهدف. ولهذا، تنقسم الورقة إلى جزأين. يركز الجزء الأول على كيفية إيجاد هدف واعد، وما الأدوات التي يمكن استخدامها، ومما يجب أن يتكون الهدف الجيد للتغذية العشوائية. ثم يصف الجزء الثاني كيفية تطوير وتصحيح أخطاء harness قادر على اختبار وظيفة معينة في ملف ثنائي بالتغذية العشوائية. ثم يُستخدم الـ harness المطوَّر بواسطة AFL++ للتغذية العشوائية على الوظيفة المستهدفة. في ما يلي، يتم تقديم خلفية مختصرة وعن الوضع الحالي لأحدث التقنيات عندما يتعلق الأمر بالتغذية العشوائية لأجهزة إنترنت الأشياء.
جميع الملفات التي أُنشئت في سياق ورقة الفصل الدراسي هذه منشورة بالكامل أيضًا على GitHub ويمكن الوصول إليها باستخدام العنوان التالي: otsmr/blackbox-fuzzing.
إن التغذية العشوائية لأجهزة إنترنت الأشياء ليست بالأمر السهل مثل التغذية العشوائية لمشروع مفتوح المصدر. غالبًا ما يكون الكود المصدري مملوكًا، مما يجعل التغذية العشوائية بالصندوق الرمادي، التي تُجهّز الكود المصدري لتحقيق أفضل أداء للتغذية العشوائية، مستحيلة [afl-persistent]. أيضًا، غالبًا لا تدعم أدوات التغذية العشوائية بنية المعالج (CPU) بشكل أصلي، مما يتطلب استخدام محاكٍ مثل QEMU [qemu] وهو ما يبطئ أيضًا سرعة التغذية العشوائية [afl-persistent]. وهناك مشكلة أخرى تتمثل في الأجهزة الطرفية، مما يعقّد تطوير نهج عام. الورقة البحثية "التغذية العشوائية للأنظمة المدمجة: مراجعة للتحديات والأدوات والحلول" [embedded-fuzzing] تقدم نظرة عامة على استراتيجيات التغذية العشوائية المختلفة، مثل التغذية العشوائية للأنظمة المدمجة القائمة على العتاد. معظم هذه الاستراتيجيات تحتاج إلى الكود المصدري للبرنامج المستهدف، مثل نقل الكود المصدري لأدوات التغذية العشوائية مثل AFL إلى أجهزة إنترنت الأشياء المبنية على ARM لتشغيل الأداة على عتاد إنترنت الأشياء. تشغيل الأداة على عتاد الجهاز ينطوي أيضًا على مشاكل في الأداء لأنها غالبًا تحتوي على معالجات منخفضة المستوى، وهي أبطأ من معالجات أجهزة الكمبيوتر المكتبية العادية. وهناك نهج آخر قدّمته هذه الورقة وهو التغذية العشوائية المدمجة القائمة على المحاكاة حيث يتم تنفيذ برنامج مستهدف واحد داخل محاكٍ لإجراء تغذية عشوائية موجّهة بالتغطية، أو يتم محاكاة النظام الكامل.
النهج المذكورة أعلاه جميعها تستهدف ملفًا ثنائيًا مباشرةً باستخدام محاكٍ أو عن طريق تجهيز
الكود المصدري. تتطلب هذه النهج إعداد تغذية عشوائية يجب غالبًا أن يكون مصممًا خصيصًا
لجهاز إنترنت أشياء واحد ويصعب تعميمه. لهذا، أنشأ الباحثون برنامجًا
IoTFuzzer يهدف إلى أن يكون إطار تغذية عشوائية آليًا يسعى إلى "إيجاد ثغرات تلف الذاكرة
دون الوصول إلى صور البرامج الثابتة الخاصة بها
[iotfuzzer]." IoTFuzzers
ويستند إلى ملاحظة أن معظم أجهزة إنترنت الأشياء لديها تطبيق جوال للتحكم بها، وأن هذه التطبيقات
تحتوي على معلومات حول البروتوكول المستخدم للتواصل مع الجهاز. ثم يقوم البرنامج
بتحديد المنطق الخاص بالبرنامج وإعادة استخدامه لتحوير حالات الاختبار لاختبار أجهزة إنترنت الأشياء
المستهدفة بفعالية [iotfuzzer].
يصف الـ harness تسلسل استدعاءات API التي تعالج المدخلات المقدمة من أداة التغذية العشوائية. وعلى العكس من التطبيق العادي الذي لا يحتاج غالبًا إلى harness، فإن المكتبة التي تنفذ دوالًا قابلة لإعادة الاستخدام يجب استدعاؤها باستخدام المعاملات الصحيحة وبالتسلسل الصحيح أيضًا، بحيث يمكن استدعاء الحالة بين استدعاءات متعددة للدوال المشتركة. إن إخضاع المكتبة للتغذية العشوائية دون بناء آلة الحالة من غير المرجح أن ينجح، وستُنشئ بدلًا من ذلك الكثير من حالات التعطل الإيجابية الكاذبة عند عدم فرض تبعيات المكتبة. يمكن أن يحدث هذا عندما يتم، على سبيل المثال، تخطّي فحص حجم المخزن المؤقت بواسطة أداة التغذية العشوائية مما يؤدي إلى تجاوز سعة مخزن مؤقت زائف.
في هذه الورقة، سيتم اختبار التطبيقات العادية بالتغذية العشوائية، ولكن بسبب التبعيات العتادية لاستخدام المآخذ (sockets) وتعدد الخيوط، نحتاج إلى إنشاء harness لها أيضًا. يتم تحميل الـ harness في سياق الملف الثنائي ويمكنه استدعاء الدوال الداخلية للبرنامج المستهدف، كما هو موضح في الكود 10.
يصف مصطلح "corpus" عينات الإدخال الصالحة أو حالات الاختبار ويعمل كمرجع أساسي لتوليد بيانات إدخال جديدة أثناء عملية التغذية العشوائية. في الكود 10 سيكون هذا، على سبيل المثال، طلب HTTP. ثم تستفيد أدوات التغذية العشوائية من هذه المجموعة لإنشاء حالات اختبار محوَّرة أو متنوعة مما يساعد في اكتشاف الثغرات البرمجية من خلال استكشاف مختلف سيناريوهات الإدخال.
الجزء الأكثر استهلاكًا للوقت في التغذية العشوائية بالصندوق الأسود هو إيجاد
دالة قابلة للاستغلال في البرنامج الثابت. الخطوة الأولى هي العثور على
ملفات ثنائية مثيرة للاهتمام، على سبيل المثال، تكون متاحة عبر الشبكة،
أو تستخدم دوالًا غير آمنة، أو لا تحتوي على ميزات أمان مثل
تفعيل كناري المكدس (stack canary)، وهو حماية من تجاوز سعة المخزن المؤقت. ورقتنا السابقة
([iovt]) وصفت بالفعل كيفية استخراج البرنامج الثابت
من الموجّه المستهدف وكيفية العثور على ملف ثنائي قد يكون خطيرًا.
ولهذا، تم استخدام أداة EMBA [emba]. تقوم EMBA بترتيب جميع
الملفات الثنائية الموجودة في البرنامج الثابت حسب عدد الدوال غير الآمنة مثل
strcpy، والوصول إلى الشبكة، والحماية الأمنية مثل كناري المكدس أو
بت NX (NX-Bit) التي تصبح مثيرة للاهتمام عند استغلال تجاوز سعة المخزن المؤقت،
وهو ما يمكن العثور عليه في الكود 1.
الكود 1: نتيجة EMBAs للاستخدامات غير الآمنة للدالة strcpy.
```