cisco-talos/mutiny-fuzzerمُختبر بروتوكول الشبكة الذي يُعيد تشغيل حركة مرور PCAP عبر محرك طفري (Radamsa) لاكتشاف الثغرات بسرعة في المضيفات المستهدفة من خلال معالجات ومراقبات رسائل قابلة للتخصيص.
المقالة هنا:
روابط لعرض فيديو يوتيوب التوضيحي:
لمزيد من الميزات الموجهة لحملات التمويه/التغذية الراجعة/الأدوات المساعدة:
إطار عمل التمويه Mutiny هو موهن شبكات يعمل عن طريق إعادة تشغيل ملفات PCAP من خلال موهن تحويري. الهدف هو البدء في تمويه الشبكات بأسرع ما يمكن، على حساب الدقة الشاملة.
سير العمل العام لـ Mutiny هو أخذ عينة من حركة المرور المشروعة، مثل طلب متصفح، وإدخالها في نص تحضيري لإنشاء ملف .fuzzer. بعد ذلك، يمكن تشغيل Mutiny باستخدام ملف .fuzzer هذا لتوليد حركة مرور ضد مضيف هدف، مع تحوير الحزم التي يريدها المستخدم.
هناك إضافات تسمح بتغيير سلوك Mutiny، بما في ذلك تغيير الرسائل بناءً على الإدخال/الإخراج، وتغيير كيفية استجابة Mutiny لأخطاء الشبكة، ومراقبة الهدف في سلسلة منفصلة.
يستخدم Mutiny Radamsa لإجراء التحويرات.
وكيل Decept هو وكيل شبكة متعدد الأغراض يمكنه توجيه حركة المرور من اتصال مأخذ نص عادي أو TLS TCP/UDP/مجال إلى اتصال مأخذ نص عادي أو TLS TCP/UDP/مجال، من بين ميزات أخرى. إنه رفيق جيد لـ Mutiny، حيث يمكنه إنشاء ملفات .fuzzer مباشرة، وهو مفيد بشكل خاص عند تمويه اتصالات TLS، والسماح لـ Mutiny بالاتصال بمضيفي TLS.
تقدم sample_apps فكرة أساسية عن بعض الأشياء التي يمكن القيام بها باستخدام الموهن، مع بعض التطبيقات/العملاء المختلفين للاختبار.
كتب بواسطة James Spadaro ([email protected]) و Lilith Wyatt ([email protected])
تأكد من تثبيت python و scapy.
قم بفك ضغط Radamsa وشغّل make (ليس عليك تشغيل make install، إلا إذا كنت تريده في
/usr/bin - سيستخدم Radamsa المحلي) قم بتحديث mutiny.py بمسار
Radamsa إذا قمت بتغييره.
احفظ ملف pcap في مجلد. قم بتشغيل mutiny_prep.py على <XYZ>.pcap (يمكن أيضًا تمرير
دليل معالج مخصص إذا وجد، مزيد أدناه). أجب على الأسئلة، وستحصل على ملف
<XYZ>.fuzzer في نفس مجلد pcap.
قم بتشغيل mutiny.py <XYZ>.fuzzer <targetIP> سيبدأ هذا التمويه. سيتم حفظ السجلات
في نفس المجلد، تحت دليل
<XYZ>_logs/<time_of_session>/<seed_number>
ملفات .fuzzer قابلة للقراءة البشرية ومعلقة. تسمح بتغيير خيارات متنوعة على أساس كل ملف fuzzer، بما في ذلك أي رسالة أو أجزاء رسالة يتم تمويهها.
داخل ملف .fuzzer توجد محتويات الرسالة. هذه ببساطة أسطر تبدأ إما بـ 'inbound' أو 'outbound'، للإشارة إلى اتجاه الرسالة. وهي بتنسيق سلسلة Python، مع استخدام '\xYY' للأحرف غير القابلة للطباعة. يتم إنشاؤها تلقائيًا بواسطة 'mutiny_prep.py' ووكيل Decept، ولكن في بعض الأحيان تحتاج إلى تعديل يدوي.
إذا كانت الرسالة تحتوي على الكلمة المفتاحية 'fuzz' بعد 'outbound'، فهذا يشير إلى أنه سيتم تمويهها عبر Radamsa. يمكن أن تحتوي رسالة معينة على استمرار سطر، ببساطة عن طريق وضع المزيد من بيانات الرسالة بين علامتي اقتباس في سطر جديد. في هذه الحالة، سيتم دمج هذا السطر الثاني مع الأول.
بدلاً من ذلك، يمكن استخدام الكلمة المفتاحية 'sub' للإشارة إلى مكون فرعي. يسمح هذا بتحديد مكون منفصل للرسالة، من أجل تمويه أجزاء معينة فقط وللتيسير داخل معالج الرسائل.
فيما يلي مثال على مجموعة بيانات رسالة عشوائية:
outbound 'say'
' hi'
sub fuzz ' and fuzz'
' this'
sub ' but not this\xde\xad\xbe\xef'
inbound 'this is the server's'
' expected response'
سيؤدي هذا إلى إرسال Mutiny say hi and fuzz this but not this(0xdeadbeef). سيتم إرسال 0xdeadbeef كـ 4 بايتات ست عشرية. سيتم تمرير and fuzz this عبر Radamsa للتمويه، بينما سيتم ترك say hi و but not this(0xdeadbeef) دون تغيير.
سينتظر Mutiny ردًا من الخادم بعد إرسال الرسالة الواحدة أعلاه، بسبب السطر 'inbound'. الرد المتوقع من الخادم هو this is the server's expected response. لن يفعل Mutiny الكثير مع هذه البيانات، بخلاف معرفة ما إذا كان ما أرسله الخادم فعليًا يطابق هذه السلسلة. إذا حدث تعطل، فسيقوم Mutiny بتسجيل كل من الإخراج المتوقع من الخادم وما رد به الخادم فعليًا.
تحتوي mutiny_classes/ على الفئات الأساسية لمعالج الرسائل والمراقب ومعالج الاستثناءات. يمكن نسخ أي من هذه الملفات إلى نفس مجلد ملف .fuzzer (افتراضيًا) أو إلى مجلد فرعي منفصل محدد كـ 'processor_dir' داخل ملف .fuzzer.
تسمح هذه الفئات الثلاث بتخزين ردود الخادم وتغيير الرسائل الصادرة، ومراقبة الهدف على سلسلة منفصلة، وتغيير كيفية تعامل Mutiny مع الاستثناءات.
يحدد معالج الرسائل عمليات الاستدعاء المختلفة التي يتم استدعاؤها أثناء تشغيل التمويه. داخل عمليات الاستدعاء هذه، يمكن تشغيل أي كود Python. من الناحية العملية، يتم استخدامها بشكل أساسي بثلاث طرق.
الأكثر شيوعًا هو عندما يرسل الخادم رموزًا تحتاج إلى إضافتها إلى الرسائل الصادرة المستقبلية. على سبيل المثال، إذا قامت رسالة Mutiny الأولى بتسجيل الدخول، واستجاب الخادم بمعرف جلسة، فيمكن استخدام رد الاستدعاء postReceiveProcess() لتخزين معرف الجلسة هذا. ثم، في preSendProcess()، يمكن تعديل البيانات الصادرة باستخدام معرف الجلسة هذا. مثال على ذلك موجود في sample_apps/session_server.
استخدام شائع آخر لمعالج الرسائل هو تحديد الرسالة المموهة أو تغييرها. على سبيل المثال، إذا كان الخادم دائمًا ما يتجاهل الرسائل الأكبر من 1000 بايت، فقد لا يستحق إرسال أي رسائل كبيرة. يمكن استخدام preSendProcess() لتقصير الرسائل بعد التمويه ولكن قبل إرسالها أو لإثارة استثناء.
يؤدي إثارة استثناء إلى الطريقة الأخيرة التي يتم بها استخدام معالج الرسائل بشكل شائع. داخل رد الاستدعاء، يمكن إثارة أي استثناءات مخصصة معرفة في mutiny_classes/mutiny_exceptions.py. هناك العديد من الاستثناءات، جميعها معلقة، والتي ستسبب سلوكيات مختلفة من Mutiny. تتضمن هذه بشكل عام التسجيل أو إعادة المحاولة أو إحباط التشغيل الحالي.
لدى المراقب دالة monitorTarget() يتم تشغيلها على سلسلة منفصلة عن الموهن الرئيسي Mutiny. الغرض هو السماح بتنفيذ عملية طويلة الأمد يمكنها مراقبة مضيف بطريقة ما. يمكن أن يكون هذا أي شيء يمكن القيام به في Python، مثل التواصل مع برنامج مراقبة يعمل على الهدف، أو قراءة ملف طويل، أو حتى مجرد اختبار اتصال المضيف بشكل متكرر، اعتمادًا على متطلبات جلسة التمويه.
إذا اكتشف المراقب تعطلًا، فيمكنه استدعاء signalMain() في أي وقت. سيؤدي هذا إلى إرسال إشارة إلى السلسلة الرئيسية لـ Mutiny بحدوث تعطل، وسيقوم بتسجيل التعطل. يجب أن تعمل هذه الدالة عمومًا في حلقة لا نهائية، لأن العودة ستؤدي إلى إنهاء السلسلة، ولن يتم إعادة تشغيلها.
يحدد معالج الاستثناءات ما يجب أن يفعله Mutiny مع استثناء معين أثناء جلسة تمويه. بشكل عام، ستقوم دالة processException() بترجمة استثناءات Python ومستوى نظام التشغيل إلى إجراءات معالجة أخطاء Mutiny بأفضل ما يمكن.
على سبيل المثال، إذا تلقى Mutiny 'Connection Refused'، فإن الرد الافتراضي هو افتراض أن الخادم الهدف قد مات بشكل غير قابل للاسترداد، لذلك سيقوم Mutiny بتسجيل التشغيل السابق والتوقف. هذا صحيح في معظم الحالات، ولكن يمكن تغيير هذا السلوك إلى أي من الاستثناءات في mutiny_classes/mutiny_exceptions.py حسب الحاجة، مما يسمح بتخصيص اكتشاف التعطل وتصحيح الأخطاء.