0xricksanchez/fisy-fuzzهذا هو الإطار الكامل لاختبار نظام الملفات (fuzzing) الذي قدمته في مؤتمر Hack in the Box 2020 Lockdown Edition في أبريل.
هذا هو الإطار الكامل لاختبار الاختراق (fuzzing) لنظام الملفات الذي قدمته في مؤتمر Hack in the Box 2020 Lockdown Edition في أبريل.
الهدف من هذا الإطار هو اكتشاف ثغرات أمنية في نواة أنظمة UNIX مع تركيز قوي على أنظمة BSD. تم تطويره واختباره بشكل مكثف ضد FreeBSD وOpenBSD وNetBSD، ولكنه يدعم أيضًا بشكل بسيط أنظمة Linux. تمكنا من اكتشاف أكثر من 100 ثغرة فريدة في نواة أنظمة الملفات المستندة إلى UFS وEXT، مع الحصول أيضًا على الكثير من البصيرة حول الإضافة الحديثة لـ ZFS.
يمكن استخدام makeFS2.py كأداة مستقلة لتوليد أنظمة ملفات صالحة مختلفة. يتم شرح الاستخدام بالتفصيل في مستودع مواد المؤتمر.
تم اختبار الإطار فقط على Ubuntu 18.04. يعتمد على KVM وQEMU وlibvirt. يقوم Requirements.sh بإعداد جميع التبعيات الضرورية. قد يكون الإطار يعمل بكامل وظائفه على أحدث إصدار من Ubuntu 20.04. يمكن دعم أنظمة مضيفة أخرى غير قائمة على بسهولة، ولا يتطلب ذلك سوى تغييرات طفيفة في . بمجرد الانتهاء من المتطلبات، يمكنك متابعة خطوات الإعداد!
aptRequirements.shارجع إلى SETUP.md. إذا كانت بعض الخطوات غير واضحة، فيرجى التواصل!
لبدء الاختبار، ما عليك سوى تنفيذ: python3 run.py. اعتمادًا على إعدادك، قد تحتاج إلى صلاحيات sudo. عندما يبدأ كل شيء بنجاح، يمكنك الاتصال بجلسة tmux للاختبار عبر:
(sudo) tmux attach-session -t fsfuzzer
يمكن تكوين الإطار من خلال البرنامج النصي src/config/fuzzing_config.py:
# [مواصفات مهام الاختبار]
# قائمة بالقواميس التي تحدد كل مثيل اختبار
fuzzer = [
{
"name": "fuzz1", # اسم ما للتدوين الداخلي
"fs_creator_vm": "genBox", # الاسم كما هو محدد في libvirt للآلة الافتراضية التي تدير إنشاء نظام الملفات، يمكن أن يكون نفسه عبر جميع المثيلات
"fuzzing_vm": "fuzzBox_0", # الاسم كما هو محدد في libvirt للآلة الافتراضية التي تدير إنشاء نظام الملفات
"mutation_engine": "radamsa, 0", # محرك التحوير الذي سيتم استخدامه، وحجم التحوير (radamsa لا يأخذ معامل حجم)
"target_fs": "ufs2", # نظام الملفات المستهدف
"target_size": 15, # الحجم الأقصى لنظام الملفات بالميجابايت
"populate_with_files": 10, # عدد الملفات التي سيتم إنشاؤها
"max_file_size": 1024, # الحد الأقصى لحجم الملف بالبايت لكل ملف تم إنشاؤه
"enable_dyn_scaling": False, # سيعمل القياس الديناميكي على زيادة حجم نظام الملفات بشكل دوري
},
]
# [بيانات الاعتماد]
# بيانات اعتماد المستخدم الجذر للآلات الافتراضية
# من المتوقع أن تكون هذه متطابقة عبر جميع المثيلات، ولكن ليس بالضرورة أن تكون للمستخدم الجذر
user = "root"
pw = "root"
محركات التحوير المتاحة هي:
تم تنفيذ القياس الديناميكي في البداية لاختبار ما إذا كان حجم نظام الملفات يؤثر على الأعطال المحتملة. لم أتمكن من تحديد قيمة محفزة لحجم نظام الملفات تتغير عندها الأعطال، لذلك يمكن ترك هذه العلامة معطلة. كما يمنع ذلك التدهور في الأداء عند التشغيل الطويل لأن أنظمة الملفات الأكبر تستغرق وقتًا أطول في التحوير.
يجب أن تكون معلمات الإعداد المتبقية واضحة بذاتها.
يظهر الفيديو أدناه عرضًا توضيحيًا سريعًا حيث يستهدف مثيلان للاختبار كليهما FreeBSD مع نظام ملفات UFS2 تم تحويره باستخدام radamsa ونظام ملفات EXT تم قلبه عشوائيًا بالبايتات. يؤدي نظام ملفات UFS المحور مباشرة إلى تعطل، مما يوضح مدى سرعة تعطيل النواة.
باستخدام هذا الإعداد، تمكنت من العثور على أكثر من 100 ثغرة فريدة في نواة FreeBSD وNetBSD وOpenBSD لأنظمة الملفات المستندة إلى UFS وEXT. من بين هذه الأعطال، كان لدي مجموعة من الأعطال المثيرة للاهتمام:
كانت غالبية الأعطال عبارة عن رفض خدمة (DoS) للنواة. علاوة على ذلك، لا تزال غالبية الأعطال التي تم مواجهتها غير مصححة حتى اليوم (مايو 2020). لذا، جرب العثور على ثغرات في النواة في تطبيقات أنظمة الملفات :).
تم بناء هذا المشروع بأكمله باستخدام 'التطوير الموجه بالثقة'، مما يعني أنه نما بشكل كبير جدًا وبسرعة كبيرة من فكرة إثبات مفهوم واحدة. وبالتالي، لا توجد اختبارات أيضًا، وعلى الأرجح هناك بعض الأخطاء. أنا آسف إذا واجهت أعطالًا (ليست مرتبطة بذعر النواة) ولكن لا تتردد في تقديم طلب سحب أو التواصل معي وسأصلح الأمور في أقرب وقت ممكن!
تويتر: @0xricksanchez