پیاده سازی تکنیک DLL Search Order Hijacking روی WinSxS

زمان مطالعه: 8 دقیقه

محققای Securityjoes یه گزارشی منتشر کردن در خصوص پیاده سازی تکنیک DLL Search Order Hijacking روی باینری های WinSxS ، که میتونه در فرایند تیم قرمز ، خیلی کمک کننده باشه.

 

معرفی تکنیک DLL Search Order Hijacking :

تکنیک DLL Search Order Hijacking یه روش ساده اما موثر هستش که توسط بازیگران تهدید استفاده میشه. این تکنیک از روشی که برنامه های ویندوزی برای لوود DLLها و فایل های اجرایی خارجی استفاده میکنن و مسیر فایل رو بطور دقیق مشخص نمیکنن ، سوء استفاده میکنه.

به گفته ی MITRE ATT&CK ، روش های مختلفی برای پیاده سازی این تکنیک وجود داره، اما همه ی اونا یه نیازمندی مشترک دارن و اون اینه که برنامه ی مورد نظر نباید مسیر کامل محتوایی که میخواد رو مشخص کنه.

برای اینکه بتونیم این تکنیک رو متوجه بشیم، باید یکمی ویندوز اینترنالز بدونیم. وقتی یه برنامه ای اجرا میشه و برای اجرا نیاز به DLL یا فایل اجرایی دیگه ای داره، اونو باید لوود کنه. تو سیستم های ویندوزی این لوود کردن براساس یه سلسه مراتب و ترتیب انجام میشه. هدف از این کار اینکه اولا دسترسی به منبع تضمین بشه و دوما اینکه اگه توسعه دهنده موقع نصب ، منبعی رو اضافه نکرده باشه، امکان دسترسی به اون وجود داشته باشه.

بخواییم خلاصه بگیم، وقتی شما یه برنامه ای رو اجرا میکنید که اون برنامه به یسری DLL و فایل اجرایی نیاز داره و توسعه دهنده بطور مستقیم هم مسیر اونارو مشخص نکرده باشه ، مثلا تو کدها نگفته که myEXE.dll رو از این مسیر بخون : C:\windows\myEXE.dll، ویندوز برای اینکه بتونه این فایل myEXE.dll رو پیدا کنه ، به ترتیب مسیرهای زیر رو جستجو میکنه و هرکجا که myEXE.dll رو دید ، اونو لوود میکنه :

• دایرکتوری که برنامه در اون اجرا شده.
• فولدر C:\Windows\System32
• فولدر C:\Windows\System
• فولدر C:\Windows
• دایرکتوری کاری جاری
• مسیرهایی که در متغیر محیطی system PATH قرار دارن.
• مسیرهایی که در متغیر محیطی user PATH قرار دارن.

اگه تو این مسیرها پیدا شد که هیچ ، اونو اجرا میکنه ، اما اگه پیدا نشد، خطا میده که مثلا myEXE.dll پیدا نشد.

فرض کنید که من یه برنامه ای نوشتم و برای اجرای برنامه ام، به یه DLL ای بنام myEXE.dll نیاز دارم و بصورت دقیق هم مسیر این DLL رو تو کدهام تعریف نکردم. موقع نصب برنامه ی من، این DLL در فولدر System32 قرار میگیره. حالا مشتری اگه برنامه ی من اجرا کنه، تو سلسه مراتب بالا، تو قدم دوم، به این DLL میرسه و اونو لوود و اجرا میکنه. حالا فرض کنید که یه بازیگر تهدید متوجه میشه که من مسیر رو تعریف نکردم و همچنین چون این DLL تو قدم دوم پیدا میشه، بنابراین میتونه یه DLL مخرب بنام myEXE.dll رو توسعه بده و کنار فایل اجرایی من قرار بده. در این صورت اگه مشتری برنامه ی من رو اجرا کنه، بجای اینکه بره DLL رو از System32 بخونه ، این DLL مخرب رو تو قدم اول پیدا و اجرا میکنه.

این تکنیک به بازیگر تهدید، این امکان رو میده که کدهای مخربشون رو ،در فضای یه پروسس قانونی تزریق و اجرا کنه و در نتیجه باعث فریب تحلیلگران امنیتی و دور زدن محصولات امنیتی بشه. مثلا شما فرض کنید ، ما آنالیز کردیم و متوجه شدیم که Word.exe به یه DLL نیاز داره که فرایند لوود اون آسیب پذیره، در نتیجه اگه یه DLL مخرب رو بجای DLL قانونی بزاریم، موقع اجرای WORD ، کدهای ما هم اجرا میشه و اینجوری این کدها رو در فضای پروسس قانونی WORD اجرا کردیم.

این تکنیک، تکنیک جدیدی نیستش و از گذشته شاهد این بودیم که بازیگران تهدید مختلف ، ازش سوء استفاده کردن. اگه MITRE رو بعنوان یه مرجع در نظر بگیریم، جدول زیر بازیگران تهدیدی که از این تکنیک استفاده کردن رو نشون میده :

 

گروه	مدل استفاده
APT41	برای اجرای پیلود های مخربشون مانند Winnti RAT
Aquatic Panda	برای لوود DLL ، EXE و فایلهای DAT به مموری
BackdoorDiplomacy	برای اجرای DLL از این تکنیک استفاده کردن
Evilnum	از یه بدافزاری بنام TerraTV برای لوود یه DLL مخرب در دایرکتوری TeamViewer استفاده کرده بودن که بصورت قانونی از فولدر System لوود میشد.
menuPass	از این تکنیک استفاده کردن.
RTM	برای لوود DLL مخرب در TeamViewer استفاده کردن.
Threat Group-3390	برای اجرای پیلودهاشون استفاده کردن
Tonto Team	از یه اجرایی قانونی و امضاء شده ی مایکروسافت برای اجرای یه DLL مخرب سوء استفاده کردن.
Whitefly	برای اجرای لودر Vcrodat سوء استفاده کردن

 

WinSxS چیه ؟

فولدر WinSxS (Windows Side by Side) یه مولفه ی حیاتی در نگهداری و بازیابی ویندوز هست و در مسیر C:\Windows\WinSxS قرار داره. وظیفه ی اصلی اون ، نگهداری فایلهای مهم سیستم در کنار هم هستش. وقتی ویندوز در حالت بروزرسانی قرار میگیره، نسخه های قبلی در این فولدر قرار میگیرن و در نتیجه با هر بروزرسانی ویندوز ، حجم این فولدر زیاد میشه.

اگه تو حوزه ی اکسپلویت کرنل ویندوز فعالیت داشته باشید، قطعا با این فولدر آشنا هستید ،چون تو تکنیک Binary Diffing میتونه کاربردی باشه.

اهداف اصلی از ایجاد فولدر WinSxS :

• مدیریت نسخه: چندین نسخه از DLL و فایل های سیستمی رو ذخیره میکنه تا در صورت نیاز دسترسی بهشون تضمین شده باشه. این قابلیت برای حفظ سازگاری با برنامه های مختلف خیلی مهمه، چون برنامه های مختلف ممکنه به نسخه های خاصی از یه مولفه نیاز داشته باشن.
• یکپارچگی سیستم : این فولدر با جلوگیری از قرار گرفتن نسخه های خراب یا نادرست، به یکپارچگی سیستم کمک میکنه. این منجر به پایداری و قابلیت اطمینان سیستم میشه.
• فعالسازی داینامیک : این فولدر امکان فعال/غیرفعال کردن ویژگی های ویندوز رو فراهم میکنه و برای اینکار نیاز به نصب های جداگانه نداره. این باعث میشه تا یه کاربری ، یسری از ویژگی هارو فعال/غیر فعال کنه.

در عمل ، موقع نصب مولفه های ویندوز ، بروزرسانی و برنامه ها ، فایلها بصورت سیستماتیک در فولدر WinSxS قرار میگیرن. این دایرکتوری بعنوان یه مخزن متمرکز برای فایل های سیستم، به ویژه DLL ها عمل میکنه، که بین برنامه ها و مولفه های مختلف به اشتراک گذاشته میشن تا از سازگاری اطمینان حاصل کنن و از مشکلات احتمالی جلوگیری کنن.

در نسخه های سروری ویندوز ، این فولدر رولهای دیگه ای رو هم بازی میکنه تا قابلیت های سرور رو افزایش بده. این فولدر فایلهای حیاتی بازیابی سیستم رو نگهداری میکنه و به فرایند بازیابی کمک میکنه. همچنین بعنوان یه مکانیسم محافظ عمل میکنه و کاربران میتونن در صورت نیاز از بروزرسانی‌ مشکل‌ساز سیستم به حالت پایدار برگردن و به انعطاف‌ پذیری و قابلیت اطمینان سیستم کمک میکنه.

 

 

سوء استفاده از فولدر WinSxS در تکنیک DLL Search Order Hijacking :

در گذشته اکسپلویتهایی توسعه داده شده بود که با استفاده از فولدر WinSxS ، امکان دور زدن UAC رو میداد، اما استفاده از این فولدر در تکنیک DLL Search Order Hijacking برای فرایند تیم قرمز یا حملات واقعی ، برای اولین بار توسط محققای Securityjoes انجام شده.

هدف کلی این تحقیق اینه که ، تکنیک DLL Search Order Hijacking رو برای باینری های موجود در WinSxS پیاده سازی کنیم. این تکنیک یسری مزیت داره از جمله :

• عدم نیاز به امتیاز بالا : با هدف قرار دادن فایلهای موجود در فولدر WinSxS ، ما نیازی به داشتن امتیاز بالا نداریم. مثلا ما اگه بخواییم به فولدر Windows دسترسی داشته باشیم، نیازمند امتیاز بالا هستیم.
• عدم نیاز به باینری های دیگه : با استفاده از این فولدر ، دیگه نیازی به باینری های دیگه بخصوص اونایی که قابلیت شناسایی بالایی در زنجیره حمله دارن رو نداریم. چون این فولدر از قبل دارای فایلهای مورد نیاز آسیب پذیر هستش، دیگه نیازی نیست که اونارو هم به سیستم انتقال بدیم.
• افزایش مخفی کاری : اجرای کد مخرب در فضای برنامه هایی که در فولدر WinSxS قرار دارن، مخفی کاری رو افزایش و خطر شناسایی رو کاهش میده. تحلیلگران بدافزار و همچنین محصولات امنیتی ، بدلیل قابل اعتماد بودن این فایلها، ممکنه اونارو بررسی یا تحلیل نکنن.

هدف اولیه تحقیق ، شناسایی آسیب پذیری های احتمالی در باینری های WinSxS بوده. برای اینکار ، محققا از دو ابزار Process Monitor و یه ابزار شخصی توسعه داده شده برای این تحقیق ، استفاده کردن.

وقتی یه باینری آسیب پذیر رو شناسایی کردن، سلسله مراتبی که ویندوز برای جستجوی فایلهای سیستمی مثلا DLL انجام میده، که بالا توضیح دادیم، رو مشاهده میکنن. یه DLL سفارشی رو در یه فولدر خاص قرار دادن. بعدش اومدن این باینری آسیب پذیر رو اجرا کردن و مشاهده کردن که این DLL سفارشی اجرا شده.

 

 

PoC برای این تحقیق :

محققا برای شناسایی باینری آسیب پذیر در WinSxS ، در برنامه ی Process Monitor یسری فیلتر تنظیم کردن تا نتایج حاوی مقادیر PATH NOT FOUND ، CreateFile و NAME NOT FOUND باشه. همچنین محققا تمرکزشون ،روی مسیر NOT_A_SYSTEM_FOLDER_MS بوده که یه فولدر در دستکاپ هستش و حاوی فایلهایی که در این تحقیق استفاده میشه، هستش.

 

 

تو این فولدر یه DLL سفارشی هم هستش که قراره با استفاده از تکنیک DLL Search Order Hijacking در مموری تزریق بشه. همچنین یه برنامه ای هم توسعه دادن که باینری های موجود در فولدر WinSxS رو اجرا میکنه و اونارو مونیتور میکنه. هدف این فایل شناسایی باینری های آسیب پذیر در فولدر WinSxS هستش.

 

 

بعد از اجرای باینری سفارشیشون، باینری هایی مانند ngentask.exe و aspnet_wp.exe رو شناسایی کردن که دنبال DLLهای مورد نیازشون در فولدر NOT_A_SYSTEM_FOLDER_MS بودن. خب با این اوصاف ، اگه اسم DLL سفارشی رو به DLL مورد نیاز این باینری ها تغییر بدن، میتونن این DLL سفارشی رو اجرا کنن. محققا برای ادامه تحقیق روی ngentask.exe تمرکز کردن.

 

 

همونطور که مشاهده میکنید، دو DLL با نامهای webengine4.dll و mscorsvc.dll مورد نیاز هستش و در فولدر NOT_A_SYSTEM_FOLDER_MS هم مورد جستجو قرار گرفته.

ما میتونیم آسیب پذیری رو با باز کردن یه CMD در فولدرمون ، NOT_A_SYSTEM_FOLDER_MS ، که بعنوان فولدر جاری محسوب میشه، فعال کنیم ، بدون اینکه باینری رو از داخل فولدر WinSxS ، به بیرون کپی/انتقال بدیم. با این کار باینری مورد نظر برای اجرای DLL به سمت فولدر ما هدایت میشه. این قدرت سوء استفاده رو بالا میبره چون فقط نیاز به یه CMD و یه DLL مخرب هستش. اصلا نیاز نیست یه برنامه ی آسیب پذیر رو وارد سیستم قربانی کنید.

 

 

همونطور که در شکل بالا مشاهده میکنید، محققا با تغییر نام Dllشون به mscorsvc.dll و اجرای ngentask.exe از فولدر NOT_A_SYSTEM_FOLDER_MS ، تونستن DLL مخرب رو اجرا کنن.

از طریق ابزار Process Explorer ، محققا تایید کردن که DLLشون رو با موفقیت در پروسس ngentask.exe واقع در WinSxS تزریق کردن.

 

 

محققا اعلام کردن که علاوه بر این باینری، باینری های دیگه ای هم در WinSxS ،میتونن آسیب پذیر باشن. چون سیستم در حال بروزرسانیه و باینری های جدید بهش اضافه میشه. جدول زیر باینری هایی رو نشون میده که در فولدر WinSxS و آسیب پذیر هستن. جدول شامل نام باینری آسیب پذیر و باینری که لوود میکنه هستش. البته شناسایی این فایلها به معنای آسیب پذیر بودن اونا نیست و باید در محیط هدف بررسی بشن .

 

باینری آسیب پذیر	منبع لوود شده
Conhost.exe	ClipUp.exe
Conhost.exe	ipconfig.exe
Conhost.exe	route.exe
Conhost.exe	mcbuilder.exe
Forfiles.exe	cmd.exe
Iediagcmd.exe	ipconfig.exe
Stordiag.exe	SystemInfo.exe
Aspnet_wp.exe	webengine.dll
Aspnet_wp.exe	webengine4.dll
Aspnet_regiis.exe	webengine4.dll
Aspnet_state.exe	webengine4.dll
Csc.exe	VCRUNTIME140_1_CLR0400.dll
Cvtres.exe	VCRUNTIME140_1_CLR0400.dll
Ilasm.exe	fusion.dll
Ilasm.exe	VCRUNTIME140_1_CLR0400.dll
Ngentask.exe	mscorsvc.dll
Ngen.exe	VCRUNTIME140_1_CLR0400.dll
NisSrv.exe	mpclient.dll

 

محققا یه ویدیو هم بعنوان PoC منتشر کردن :

 

 

روش های تشخیص :

محققا برای تشخیص این تکنیک چند تا راه حل پیشنهاد دادن :

• بررسی والد پروسس :
  • رابطه ی بین فرزند و والد در پروسس ها رو بررسی کنید و دنبال موارد زیر باشید :
    • پروسس هایی غیرنرمال که باینری ها رو از فولدر WinSxS اجرا میکنن.
    • باینری هایی که در داخل فولدر WinSxS هستن، باعث ایجاد پروسس های فرزند مشکوک بشن.
• آنالیز رفتار :
  • فعالیت های باینری های موجود در فولدر WinSxS رو با تمرکز بر عملیات فایل و ارتباطات شبکه مونیتور کنید. میتونید دنبال فعالیت های زیر باشید:
    • باینری های WinSxS ای که به سرور ریموت وصل میشن
    • باینری های WinSxS ماژولهارو از فولدرهای غیرمعمول لوود میکنن.

 

منبع