مواضيع ومقالات

مقال : ثغرات dll hijacking تحليلها, أسبابها وطرق الحماية

تم أرشفة هذا المحتوى


مقال يتحدث عن ثغرة 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) والملفات التنفيذية لهم. إفحص قبل التجربة.

عن الكاتب:


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

مقالات ذات صلة

‫15 تعليقات

  1. تحليل أكثر من رائع
    بالنسبة للسؤال حول مشاكل الثغرة هو في الحقيقة ليس مشكل بالصعب
    فتستطيع عند صناعة المكتبة الخاصة بك أن تقوم بعمل DLLEXPORT للدوال المستخدمة من طرف المكتبة الأصلية نحو الدالة المزيفة و هذا مثال
    http://www.exploit-db.com/exploits/14730/

  2. حياكم الله إخواني ,

    بالنسبة لموضوعك أخ عبدالصمد , مثالك قد يوفر مكتبة تحوي دوال بنفس دوال المكتبة الأصل , لكن هل تستطيع إستدعاء هذه الدوال ؟ لا لإنها ستعرض رسالة MessageBox وترجع قيمة 0 بكل الأحوال , أي أن البرنامج المستهدف لن يعمل بشكل طبيعي 🙂

    موضوع الDll Proxy يوفر حل مناسب لمسألة الدوال , لكن تنقصك العديد من الأشياء الأخرى مثل المصادر كما ذكرت في الموضوع 🙂

    مشكور على الرد , دمت بود ,,

  3. جربت الثغرة و تشتغل عادي و البرنامج يشتغل عادي كذلك
    ممكن توضح لو سمحت قصدك من أن البرنامج لن يعمل بشكل طبيعي لأني لم ألاحظ ذلك

  4. أخ عبدالصمد , لنفرض أن هناك مكتبة إسمها files.dll وتحوي دالة إسمها DeleteAllFiles , الدالة تحذف جميع ملفات مجلد محدد.

    قمت أنت بعمل مكتبة خاصة بك وسميتها بنفس الإسم , ووضعت نفس الدالة عن طريق :
    DllExport void DeleteAllFiles() { pwn(); }

    أي أن مكتبتك أيضاَ توفر دالة بنفس الإسم , لكن دالتك تعرض رسالة فقط , كما في مثالك :
    int pwn(){ MessageBox(0, “Firefox DLL Hijacking!”, “DLL Message”, MB_OK); return 0;}

    قام البرنامج بتحميل مكتبتك , لاحظ أن مكتبتك لم تقم بتحميل المكتبة الأصلية , قام البرنامج بإستدعاء GetProcAddress وجلب عنوان دالة DeleteAllFiles من مكتبتك , وأستدعاها ,,

    ما الذي سيحصل ؟ ستظهر له رسالة Pwn فقط !

    لم يتم تحميل , إستدعاء أو حتى السؤال عن المكتبة الأم , البرنامج سيتعامل مع مكتبتك على عماه , وستعود دالتك بقيمة 0 في جميع الأحوال ,

    فكرة الDll Proxy المطروحة في المقالة من موقع CodeProject تقوم على نفس فكرتك , لكنها بدل أن تستدعي دالة Pwn تستدعي الدالة الأصلية وتعود بقيمتها 🙂

    وفكرتي أنا التي أعمل عليها , تقوم على تغيير قيمة LoadLibrary لجعلها تعود بعنوان المكتبة الأصلية وتوفير الكلام المسرود أعلاه كاملاَ 🙂

    اي سؤال , موجودين بالخدمة 🙂 دمتم بود ,,,

  5. أخ اسحاق , في الدقيقة 7:40

    الثغرة إشتغلت , لكن البرنامج المستهدف لم يعمل . وهذا ما يدور حوله الجدل ^^

    أيضاَ أنت قمت بإستيراد أسماء دوال لمجرد أسمائها , دوال مكتبة dwmapi أكثر من التي قمت بإستيرادها بكثير ,,

    مشكور على مشاركتك , وجزاك الله خير ,, دمت بود ,,

  6. أهلا بك أخي فالدقيقة 7.40 طبعا مارح يشتغل البرنامج
    لاننا غيرنا ملف dll الي رح يحمل الملف دام انو تغير الببرنامج مش
    رح يفتح اما بالنسبة للكلمات انا جبت string عوضا عن function
    وهيا كلها شغلة واحدة رح يعطيك الدوال الوجودة بالذاك ويمكن
    تجيبها عن طريق عدة برامج اخرى غير IDA زي olly انا مشيت بطريقة
    سهلة لكي يفهمها الكل والدوال تميزها من اسمها لكثرة تكرار وتقدر
    تستعمل دالة واحدة وتحقنها مفش مشكلة أكبر دوال

    ودمت بود انا ارسلت الفيديو للموقع
    وانشاء الله اذا نزل مرحبا باستفساراتكم
    تحياتي

  7. طريقة البحث عن المكاتب في دالة Loadlibrary*:

    1 – مجلد البرنامج نفسه.
    2 – مجلد نظام ال32بت (system32).
    3 – مجلد نظام ال16بت (system).
    4 – *مجلد العمل الحالي.
    5 – المسارات الموجودة في متغير ال PATH

    يمكنكم الإستزادة من هذا المقال الذي يشرح عن إمكانية عمل EXE hijacking ومعلومات أخرى :http://blog.acrossecurity.com/2010/09/binary-planting-goes-exe.html

    مشكور أستاذ صالح للإشارة , دمتم بود ,,,

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

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

    أي إستفسار , موجودين بالخدمة 🙂

  9. فعلا ثغرات دكية ,, لكن ضعفها في أنها لا يمكن أن تستغل عن بعد (remote) يبقى الأستغلال لوكال ,,,
    تشكر على الطرح المميز و أتمنى لك حظ سعيد في اكتشاف ترقيع ;
    تحيااتي

  10. التغرة بنظام الوينوز نفسه فهي سبب المشكلما ان تصنع مكتبة ديناميكية تقوم بعد تحميلها من قبل النظام او البرنامج المستهذف تقوم بتشغيل تعليمات خبيثة او تصنع ملف تنفيذي وتشغله على الهذف .

اترك تعليقاً

لن يتم نشر عنوان بريدك الإلكتروني. الحقول الإلزامية مشار إليها بـ *

زر الذهاب إلى الأعلى