مقال يتحدث عن ثغرة Dll Hijacking المنتشرة في الفترة الأخيرة, إذ يتساءل البعض, كيف تعمل وهل كل الأجهزة مصابة بها؟ هل كل البرامج يمكن أن تصاب بها وكيف أحمي نفسي؟ كيف أحمي برامجي منها؟ سنتطرق للعديد من الأمور عنها اليوم في نفس الموضوع.

الحمد لله المُطاع .. خالق الإبداع .. فاصل الأنواع .. نحمده أن أرسل إلينا خير داع .. و مكّن دينه في كلّ البقاع .. و أنزل لنا خير كتبه نثاب بالعمل به .. و بتلاوته و بالسماع .. و الصلاة الدائمة على حبيبه و من تبعه إلى يوم الدين بلا إنقطاع.

 

مقدمة:

الكل يعلم عن مكتبات الربط الديناميكي (dll) ودورها في توفير الجهد في التعامل مع النظام , إذ يكفيك للتعامل مع النظام , أن تستدعي المكتبة والدوال الموجودة فيها , فعندما تريد أن تحذف ملفاَ , ستستدعي مكتبة Kernel32.dll وتقوم بإستدعاء دالة DeleteFile التي تقوم بحذف الملف الممرر لها , وعندما تريد الإتصال بمنافذ أو أجهزة أخرى , تقوم بتحميل مكتبة ws2_32 وإستدعاء الدوال الخاصة بالمقابس.

أغلب المكاتب تتواجد في مجلد النظام System32 كما هو معلوم , ويمكنك إرفاق المكتبة مع البرنامج في نفس المجلد في بعض الأحيان عندما لا تتوفر المكاتب في الأجهزة الأخرى , وهنا جاءت المشكلة!

 

فكرة الثغرة:

عندما تقوم بتحميل مكتبة إلى برنامجك , تقوم بإستدعاء دالة LoadLibraryA وتمرير اسم المكتبة لها بالشكل التالي:

LoadLibraryA(“user32”)

سيقوم النظام بالبحث عن مكتبة user32 في نفس مجلد البرنامج أو ما يسمى بالـ Current Directory, إذا لم يجد , سيقوم بالإنتقال إلى المجلدات الموجودة في متغير PATH ويبحث عن المكتبة , ويقوم بتحميلها للذاكرة أو يقوم بإرجال قيمة 0 للدالة دلالة على عدم تحميل المكتبة ,

من هنا يمكننا فهم الفكرة , إذ أن وضع مكتبة خاصة بنا في نفس مجلد العمل للبرنامج , أو في مكان يتم فحصه قبل الSystem32 يؤدي إلى تحميل المكتبة الخاصة بنا بدلاَ من المكتبة الأصلية…

سؤال: إذا كانت الفكرة بهذه البساطة, لماذا لا يمكننا إستغلالها لكل البرامج؟ بوضع أي مكتبة يستعملها البرنامج في نفس مجلد العمل؟
يجب , كما ذكرت أن يقوم البرنامج بتحميل المكتبة عن طريق دالة LoadLibraryA , إذ أن وجود المكتبة في قائمة جدول الإستيراد Import Table سيقوم بتحميل المكتبة من مجلد الSystem32 أولاَ , بهذا تجد أنه لا يمكن إستغلالها , أيضاَ يجب أن لا تكون المكتبة قد تم تحميلها للذاكرة , فمثلاَ عندما تقوم بتحميل مكتبة user32 , المكتبة تحوي العديد من المكاتب التابعة لها في جدول الإستيراد , وسيتم تحميلهم معها ومن نفس مجلدها , بهذا تفشل الثغرة.

 

مثال:

لدينا هنا برنامج يريد إستدعاء adsnt.dll بعد تحميله عن طريق دالة LoadLibraryA , بالشكل التالي:

format PE GUI 4.0

entry start

include ‘win32a.inc’

start:

push _lib

call [LoadlibraryA]

int 3

_lib db “adsnt”,0

section ‘.idata’ import data readable writeable

library kernel32,’kernel32.dll’

import kernel32,

LoadlibraryA , ‘LoadLibraryA’

عندما نقوم بتجربته في المنقح ونقوم بتشغيله , نلاحظ أن المكتبة قد تم تشغيلها وتم تحميل المكتبات المضمنة معها بشكل تام.

dll hijacking

الآن نقوم بعمل dll بنفس الإسم ولنجعلها تقوم بعمل break وقت تشغيلها , على الشكل التالي:

format PE GUI 4.0 DLL

entry DllEntryPoint

include ‘win32ax.inc’

.code

proc DllEntryPoint hinstDLL,fdwReason,lpvReserved

int 3

mov eax,5

ret

endp

نقوم بترجمتها وجعلها في نفس مجلد البرنامج, ونقوم بتسميتها بإسم adsnt.dll

نقوم بتشغيل البرنامج في المنقح , وننتظر النتيجة, ستجد أنه قد تم تحميل مكتبتنا بدل المكتبة الأصلية وهذا هو أساس الثغرة ككل…

dll hijacking

 

سؤال: ماهي المشاكل التي تواجه مطور الثغرة؟ هل الثغرة تعتبر كاملة بالشكل السابق؟
مثالنا السابق يمثل معظم إستغلالات الثغرة لكن إذا أردت أن تقوم بعملك على أكمل وجه, ستضطر لمواجهة العديد من المشاكل. مثلاً إذا قمت بجعل مكتبتك تعمل بدل مكتبة أخرى , يجب أن تقوم بتحميل المكتبة الأصلية وتوفير الدوال التي توفرها هي للبرامج التي تستدعيها وإلا ستكشف على الفور, أي أن البرنامج إذا قام بإستدعاء

GetProcAddress(handle,”SetWindowHookEx”)

مثلاَ, سترجع الدالة بالقيمة 0 لإن مكتبتك لا تحوي دالة SetWindowHookEx فستظهر لجلب جميع دوال المكتبة و يتم عمل ذلك عن طريق تصدير دوال بنفس أسماء المكتبة وجعل دوالك كـ Proxy أو وسيط بينهم كما في الموضوع التالي من موقع CodeProject.

الموضوع يتحدث عن ما ذكرناه , إنشاء مكتبة وسيط بينك وبين المكتبة الأم , بتقليد كافة دوالها والقفز إلى الدوال الأصلية وقت الإستدعاء.

سؤال: هل الدوال هي كل ما توفره المكاتب؟
لا طبعاَ, إذ أن المكاتب توفر مصادر Resources وأشياء أخرى وإذا أردت أن تقوم بإستبدال المكتبة , يجب أن تقوم بمحاكاة.

سؤال: كيف أحمي برنامجي من أن يستغل بهذه الثغرة؟
كما رأينا فإن المشكلة العامة هي بعدم توفير المسار الكامل للنظام لكي يبحث عن المكتبة فيه , بهذا نستطيع القول أننا لم إستدعينا المكاتب بالشكل التالي مثلأَ:

LoadLibraryA(“c:windowssystem32user32.dll”)

فسنتجاوز أي مشكلة مع هذه الثغرة إن شاء الله.

سؤال: كيف أحمي نظامي من هذه الثغرة؟
كما ذكر في شرح الأخ محمد القرني يجب أن تتأكد من الملفات المرفقة مع البرامج والملفات , أيضاَ مايكروسوفت وفرت ترقيع يسمح لك بمنع تحميل المكتبات من مجلدات العمل وإستعمال مجلدات النظام فقط.

أعمل حالياَ على طريقة تقوم بتغيير قيمة الدالة LoadLibraryA الراجعة للبرنامج بحيث يمكننا إستبدالها بقيمة الدالة الأصلية , بهذا نتفادى مشكلة المصادر والدوال وأي تعامل للبرنامج الأصل سيتم مع المكتبة الأم , لكن الموضوع معقد بالنسبة لي , وسأحاول طرح التحديث بأقرب وقت إن شاء الله.

ختاماَ:

شكر للأستاذ صالح  على وقفته معي وتزويدي بالمراجع اللازمة , شكر لكم أيضاَ على قراءة الموضوع.

دمتم في حفظ الله ورعايته ,,,

ملف مرفق: مثال الـ Loader والمكتبة, الكود المصدري (fasm) والملفات التنفيذية لهم. إفحص قبل التجربة.

عن الكاتب:


مصطفى العيسائي, طالب جامعي مهتم بمجالات الأمن والبرمجة.

Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn