حالة غريبة في Malwarebytes

[Gu-sung18]

المقدمة
في الآونة الأخيرة، قمت بتثبيت مضاد الفيروسات Malwarebytes على جهازي. لقد عبثت به قليلاً ولاحظت أن هنالك شيئًا ما كان غريب عند عمل فحص للملفات على القرص. وبطبيعة الحال، فقد دفعني هذا إلى مزيد من البحث لتحديد السبب الرئيسي، لكنني اكتشفت بشكل غير متوقع شيئًا آخر غريبًا بشكل لا يصدق. وبالتالي مجموعة مشاكل وساعات من الاستقصاء لاحقاً، أود أن أقدم لكم ما اكتشفته في هذه الرحلة.

ما هو فحص الملفات؟
بالنسبة لأولئك الغير مدركين، يعد ملف اختبار EICAR عبارة عن ملف تم تطويره لاختبار مضادات الفيروسات عن طريق تشغيل خاصية الكشف عمداً استنادًا إلى سلسلة ASCII التالية:

X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*

لمزيد من المعلومات حول هذا، يرجى زيارة الرابط هنا: https://www.eicar.org.
عندما أكملت تثبيت Malwarebytes، أردت اختباره باستخدام ملف EICAR. لذلك أسقطته في القرص وبعدها انتظرت إشعار الكشف ... ولا شيء ...؟ Malwarebytes لم يرف له جفن. لقد زردت من حدة الأمر وطلبت فحصاً للملف ... ولا شيء!
 

بعد البحث بجوجل عن المشكلة، هنا الملخص من قسم FAQ لماذا Malwarebytes لا يكتشف ملفات EICAR:

لذلك باختصار، تتضمن MB3 بالفعل تقنيات من الجيل التالي من الطراز العالمي لمضادات الفيروسات. تركيبتنا التي تعتمد على signature-less وrules-based تعتبر اكثر فاعليه من تواقيع مضادات الفيروسات. قادر على منع تهديدات وهجمات 0-minute دون تحديثات، حتى الهجمات المستندة إلى السكربتات والملفات التي تعمل من الذاكرة وغيرها من الهجمات المتقدمة. لن نكتشف EICAR لأن EICAR ليس ممثلاً لبيئة التهديد أو الاحتياجات الأمنية الحالية.

شيء غريب ولكن OK.

بعد هذا الحادث الفريد، قررت محاولة معرفة ما إذا كان سيتم الكشف عن أي شيء يتم إسقاطه الى القرص، لذلك قررت أن أجد شيئًا من شأنه ان يضمن اكتشافة: Quasar RAT. لقد قمت بتنزيله وفك ضغطه، في الأنتظار تحسباً لإشعار الكشف ... ولا شيء! مرة أخرى!

لقد أجريت فحصًا يدويًا على ملف Quasar.exe للتحقق مما إذا كان Malwarebytes يعمل على الإطلاق، ويا للعجب، لقد التقطته !
 

استقصاء المشكلة
بالطبع، لم أعجب بما رأيته. كنت أرغب في استقصاء سبب المشكلة لايجاد حل لها. كنت قد عبثت قليلاً مع تطوير kernel driver من قبل، أنا أعرف أين يجب ان انظر.

غمليات Minifilter Callback
يحتوي Windows على نوع خاص من التعاريف-drivers تسمى Minifilters والتي تستخدم لعمليات نظام الملفات. للتسجيل كـ minifilter، التعريف يجب أن يستخدم دالة التسجيل FltRegisterFilter. احد المعاملات-parameters يحدد registration context والذي هو struct يحتوي المعلومات ذات الصلة المراد تقديمها إلى الـ kernel.

typedef struct _FLT_REGISTRATION {
USHORT Size;
USHORT Version;
FLT_REGISTRATION_FLAGS Flags;
const FLT_CONTEXT_REGISTRATION *ContextRegistration;
const FLT_OPERATION_REGISTRATION *OperationRegistration; // <--
PFLT_FILTER_UNLOAD_CALLBACK FilterUnloadCallback;
PFLT_INSTANCE_SETUP_CALLBACK InstanceSetupCallback;
PFLT_INSTANCE_QUERY_TEARDOWN_CALLBACK InstanceQueryTeardownCallback;
PFLT_INSTANCE_TEARDOWN_CALLBACK InstanceTeardownStartCallback;
PFLT_INSTANCE_TEARDOWN_CALLBACK InstanceTeardownCompleteCallback;
PFLT_GENERATE_FILE_NAME GenerateFileNameCallback;
PFLT_NORMALIZE_NAME_COMPONENT NormalizeNameComponentCallback;
PFLT_NORMALIZE_CONTEXT_CLEANUP NormalizeContextCleanupCallback;
PFLT_TRANSACTION_NOTIFICATION_CALLBACK TransactionNotificationCallback;
PFLT_NORMALIZE_NAME_COMPONENT_EX NormalizeNameComponentExCallback;
PFLT_SECTION_CONFLICT_NOTIFICATION_CALLBACK SectionNotificationCallback;
} FLT_REGISTRATION, *PFLT_REGISTRATION;

ضمن هذا الـ struct، هنالك عضو واحد مثير للاهتمام: OperationRegistration.

typedef struct _FLT_OPERATION_REGISTRATION {
UCHAR MajorFunction;
FLT_OPERATION_REGISTRATION_FLAGS Flags;
PFLT_PRE_OPERATION_CALLBACK PreOperation;
PFLT_POST_OPERATION_CALLBACK PostOperation;
PVOID Reserved1;
} FLT_OPERATION_REGISTRATION, *PFLT_OPERATION_REGISTRATION;

هذا الـ struct يصف نوع العملية التي سيتم تسجيلها كـ callback ء(MajorFunction) الدالتين اللتان ستقومان بمعالجة الـcallback ء(PreOperation و PostOperation). PreOperation تعالج الـ callback قبل ان يتم إجراء العملية و PostOperation تعالج الـ callback بعد ان يتم إجراء العملية. يستخدم هذا الـ struct في مصفوفة قد تحدد أنواعًا متعددة من العمليات.

قمة الجبل الجليدي
باستخدام هذه المعرفة، اكتشفت structure التسجيل المستخدمة في FltRegisterFilter:

 

إذا طابقنا الـ offsets مع تعريف الـ struct أعلاه، فيمكننا أن نستنتج أن قيمتي unk_XXX الخضراوتين هما ContextRegistration و OperationRegistration على التوالي. نحن مهتمون بالثانية:
 

يوضح الشكل أعلاه الـ struct لـ OperationRegistration مع العمليات IRP_MJ_CREATE (يفتح مقبض الملف) و IRP_MJ_ACQUIRE_FOR_SECTION_SYNCHRONIZATION. الأمر الغريب هنا هو أنه لا يوجد تسجيل callback مسجل لـ IRP_MJ_WRITE (عمليات كتابة الملفات) أو IRP_MJ_CLEANUP (إغلاق مقبض الملف). يمكن أن يتتبع ذلك أنماط البايتات للملفات الخبيثة التي تتم كتابتها إلى ملف بالإضافة إلى إمكانية فحص ملف بعد فتحه وتعديله. ربما كان هذا هو السبب في الفشل في فحص Quasar؟
على أي حال، تحدد IRP_MJ_CREATE كلاً من PreOperation و PostOperation. يستخدم PostOperation فقط للتنظيف لذلك نحن لسنا مهتمين بذلك. دعونا نلقي نظرة على PreOperation. الدالة في الواقع صغيرة جدًا ولا تحتوي على أي معلومات ذات صلة حول فحص الملفات، لكنني لاحظت الروتين deferred التالي:

الأخذ على حين غرة
إذا قفزنا إلى sub_140005AA0، يمكننا أن نرى هذا:
 

في المربعات الخضراء، هنالك استدعاء لـ RtlCompareUnicodeString، مع المعامل الأول كأمتداد الملف والمعامل الثاني كسلسلة نصية hardcoded فيما يلي السلاسل النصية-strings الثلاث:
 

إذا نظرنا إلى الوراء في المخطط البياني، تم تعريف RtlCompareUnicodeString بإرجاع صفر إذا كانت القيمتان النصيتان اللتان تم توفيرهما متطابقان. يمكننا اتباع الفروع الخضراء التي تلبي الشروط بإرجاع هذه القيمة ونرى التنفيذ حتى نهاية الدالة. يحتوي المربع الأحمر على اليمين على الدالة التي تقوم بفحص الملف. إذا أردنا تجاوز دالة فحص الملفات، كل ما نحتاج إليه هو إعادة تسمية امتداد الملف إلى Manifest، أو Config، أو etl (غير متحسسة لحالة الأحرف)!
 

من الممكن بالفعل تشغيل الملفات القابلة للتنفيذ على الرغم من عدم وجود امتداد exe. أعتقد أن الـ PATHTEXT في الـ environment variable يلعب دورًا في دالة CreateProcess. متغيرالـ PATHTEXT (خاصتي) معرف بأنه:

.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC

تخميني، إذا كان الملف التنفيذي يحتوي على امتداد ملف غير مرتبط-unassociated، فسوف يبحث بشكل تكراري أنواع الملفات هذه بالترتيب (من اليسار إلى اليمين) والتحقق من خلال تحليل رأس الملف. في حالة exe، ستصل إلى قيمة .EXE ، ويتم التعرف عليها بأنها قابلة للتنفيذ بواسطة توقيع MZ، ثم محاولة تنفيذها على هذا النحو. صححني إذا كنت مخطئًا.

البرهان
في ملف الـ GIF التالي، سأظهر أن الملفات الضارة التي تم إسقاطها على القرص لا يتم اكتشافها. بعد ذلك، من خلال تغيير امتداد الملفات إلى etl و manifest، برنامج Malwarebytes لن يستطيع رؤيتهم.

 

Dropper PoC
لقد طورت أيضًا dropper كأثبات لأتمتة هذه العملية.
 

الاستنتاجات
بدأت هذه الرحلة غريبة للغاية وأصبحت أغرب. ليس لدي أي فكرة عن سبب افتقاد التطبيق لبعض عمليات الـ callbacks لنظام الملفات. قد يفسر هذا لماذا Malwarebytes لا يقوم بفحص الملفات عند كتابتها إلى القرص. ليس لدي ادنى فكره عن السبب في أنه تم تقرير إدراج امتدادات الملفات هذه في القائمة البيضاء. ربما كان الامر عبارة عن optimisation من نوع ما؟ ربما كان نابع من افتراضهم انها ملفات غير قابلة للتنفيذ؟ اسمحوا لي أن أعرف ما هو رأيكم.
كما هو الحال دائمًا، يمكنك العثور على الـ PoC هنا على GitHub

https://github.com/NtRaiseHardError/Antimalware-Research/tree/master/Malwarebytes

---------------------------------
اي خطأ في الترجمة يرجى الاشارة اليه لاني لست محترف ولم ابرمج اي شيء يختص بالتعاريف او بنواة التشغيل.
ايظاً انتظر رأيكم بخصوص هذه المشكلة الامنية والتي تمكنك من تجاوز حماية Malwarebytes من خلال تغيير امتداد البرنامج الخبيث.

المصدر

https://0x00sec.org/t/a-curious-case-of-malwarebytes/13746

[MountLegacy]

رائع  اخي الغالي  اعتقد لو جربت علي باقي البرامج ستجد الكثير مها يحتوي علي اخطاء مثل هذه