ایدهها ثابتن ! از DLL Hijack تا COM Hijack
من قبلا یک پستی نوشتم و کامل توضیح دادم که DLL Hijack چیه و چطور انجام میشه ! اگه یادتون باشه دلیل اصلی DLL Hijack یک Sort Order دیفالت بود که ویندوز ازش استفاده میکرد و اگه برنامه نویس مسیر کامل DLL رو نمیداد شما میتونستید DLL همنام رو قرار بدید که برنامه DLL مخرب/خیرخواه شمارو هم لود بکنه !
مشکل اصلی این بود که شما میدونستید اگه DLL هایجک شده مربوطه فقط هدف خیرخواهانه ی شمارو انجام بده اون برنامه کرش میکنه و از کار میفته ! چون یکسری از فانکشنالیتی هایی که بهش نیاز داشته رو دیگه نمیتونسته از DLL ایی که دنبالش بوده برداره . پس ایده ی هکر ها چی بود؟
استفاده از Proxy !
گفتیم اوکی ! ما وقتی یک DLL رو Hijack میکنیم تمام فانکشنالیتی هایی که خودش داره رو export میکنیم که پراسس اصلی دچار مشکل نشه . ولی اون لا به لا کد های خودمونم میذاریم و DLL هایجک شده هم کار خودشو میکرد هم کار مارو !
پراسس راضی ... هکر راضی.. گور بابای edr ناراضی :))
یکی از موارد جالب امنیت برای خودم اینه که ایده های حمله اکثرا شبیه به همه. بیاید ببینیم چطور چنین مسیری برای COM هم کار میکنه و نگاشتش رو بگیم .
وقتی سیستم به مایکروسافت میگه : من اولویت زندگیت نیستم !
یک واقعیت جالب درباره ی ویندوز اینه . ویندوز همیشه محتویات رجیستری داخل Current User رو به Local Machine ترجیح میده !
تقریبا هم منطقیه ! انگار که میخواد دست یوزر باز تر باشه و بخواد سیستمشو کاستومایز میکنه ولی این موارد User Friendly همیشه برای هکرا انگار جذاب تر از یوزراست :)) سگ آخه میره DLL داخل رجیستری CLSID رو عوض بکنه؟ :)) خو مردی هکره دیگه.
بگذریم . اینو خواستم بگم که اینجا این اولویت رجیستر ها دقیقا شبیه Search Order توی DLL Hijack هستن. یعنی اول سیستم میاد Current User رو چک میکنه چون چیزی اونجا نیست میره تو Local Machine و مقدار اصلی رو برمیداره. شما میدونید که تغییر رجیستری یوزر نیاز به دسترسی ادمین نداره پس میتونید با دسترسی عادی برید و اینکارو انجام بدید :)
تو فرآیند لود شدن COM هکر کجاها میتونه دست ببره؟
ما فلو لود شدن COM ها و استفاده ازش رو توی پست قبلی گفتیم. بیاید ببینیم تو این پروسه هکر کجاها میتونه کرم بریزه؟
اول از همه شما میزنید Wscript.shell رو میخوام . ویندوز اول از همه نیاز داره که wscript.shell رو اصطلاحا Resolve بکنه به یک guid که ما میگفتیم بهش CLSID .
پس میرفت تو مسیر Registery زیر :
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\WScript.Shell\CLSID
و پیدا میکرد که CLSID این بابا چنده که بتونه باهاش کار بکنه .
قبل اینکه ادامه ی فلو رو بریم.. هکر اینجا چیکر میتونه بکنه؟ ایده !
میریم توی همین مسیر در Current User طرف یک wscript.shell درست میکنیم و clsid ایش رو عوض میکنیم به یک guid دیگه. ولی کدوم guid ؟
پس بازم ایده ! هر COM ایی که اسمش رو انتخاب کردیم میریم dll مربوط بهش رو در میاریم. حالا این DLL رو اصطلاحا Proxy میکنیم که همون کارای قبلی رو بکنه و کار ماهم بکنه. بعدش میریم یک COM Object رجیستر میکنیم و guid اون COM رو میذاریم برای wscript.shell !
اگه شما کار HIjack رو اینجا قرار بدید یعنی در لحظه ی Resolve شدن ProgID بهش میگیم ProgID Hijacking .
حالا بریم ادامه فلو دیگه ببینیم کجاهارو میتونیم سیخ بزنیم .
در ادامه که ویندوز موفق شده با ProgID مقدار CLSرو پیدا کنه میره تو مسیر مربوطه بهش تا با استفاده از کلید های زیر بدونه باید چه exe/dll ایی رو لود کنه . یادتونه اسم این کلید بر چه اساسی بود ؟
- اگه Inprocess بود یعنی طبعا ما برای اون COM یک DLL داریم که قراره توی خود پراسس لود بشه و کلید مربوط بهش InProcServer32 بود.
- اگه اون COM قرار بود که خارج از فضای پروسس لود بشه ما با یک exe سروکار داشتیم و کلید مربوط بهش LocalServer32 بود. میدونیم که این لود شدن میتونه خارج از پراسس هم اتفاق بیفته که بهش میگفتیم DCOM . یعنی با ip از یک ماشین مجزا بره کار لود رو انجام بده .
- یک حالت دیگه هم داشتیم که یک پراسس واسط بیاد dll مارو لود بکنه که توی رجیستری ها با کلیدDLL Surrogate میتونستیم ببینیمش.
اینجا قضیه ساده تر از ProgID Hijacking هست مگه نه؟
ایده بسیار ساده ست ! ما میایم یک COM رو انتخاب میکنیم و میریم توی CLSID داخل رجیستری Current User و مسیر DLL یا exe کلید مربوطه رو تغییر میدیم به چیزی که خودمون میخوایم !
ولی اینجاهم حواسمون هست ! سیستم عامل و برنامه ها دارن از COM استفاده میکنن پس نباید فانکشنالیتی خود COM هم از بین بره ! پس ما میایم اون DLL رو Proxy میکنیم تا همه راضی باشن :))
به این کار هم میگیم CLSID Hijacking . که نسبت به ProgID Hijacking میبینید کثیف کاری کمتری داره . دیگه نیاز نیست یک COM جدید رجیستر بکنید و ... فقط تغییر یک مسیر در رجیستری با دسترسی غیر ادمینی و آپلود فایل دلخواه هست داخل سیستم .
بریم دستبه کار شیم ! پیاده سازی CLSID Hijacking
خب خب ! اول از همه یک COM Object رو انتخاب کنید برای Hijack . حالا کدوم بهتره؟ نیاز به تحقیق داره که جلوتر میگم ! من تو مثالم از این رجیستری استفاده کردم :
CLSID\{22AF56E3-F2E0-4A7E-AA0C-6B226EF5ABF8}\InprocServer32
که داره اشاره میکنه به این DLL :
C:\Windows\System32\WorkFoldersShell.dll
چرا این ؟ چون که مربوط به اسکجول تسک هست و میتونه هر بار با لاگین شدن ران بشه ! ( ایده پرسیست )
اول از همه DLL خودم رو نوشتم ولی یک نکته ای ! توی مینیمال ترین DLL ایی هم که خواستید بنویسید حتما باید فانکشن DllGetClassObject رو اکسپورت کنید تا COM ها بتونن کار کنن. نکته مهم همینه ! باقی پروسه همون پروسه نوشتن یک DLL معمولیه . اگر خواستین نمونه ببینید این Repo گیت هاب چیز خوبیه :
اگر هم خواستید میتونید یکم بیشتر کد نویسی کنید و مثل من یک فانکشن برای کدای خودتون بذارید :
extern "C"
{
__declspec(dllexport) STDAPI DllGetClassObject(REFCLSID rclsid, REFIID riid, LPVOID* ppv)
{
WriteLog(L"Proxy DllGetClassObject called");
RunMyCustomCode();
PFN_DllGetClassObject original = GetOriginalExport<PFN_DllGetClassObject>("DllGetClassObject");
if (!original) {
return HRESULT_FROM_WIN32(GetLastError());
}
return original(rclsid, riid, ppv);
}حالا فرض کنید شما یک Fake.dll دارید که میتونه کار پروکسی رو انجام بده. حالا برید از رجیستری مربوط به لوکال ماشین COM مربوطه یک export بگیرید که بتونید در Current User ایمپورتش کنید . فقط با دوتا تغییر کوچیک :)
حالا دقیقا همین فایل رجیستری رو میتونید با یه دستور ساده ایمپورت کنید :
حالا همه چی آماده ست ! کافیه که این COM دوست داشتنی یکبار initiate بشه تا DLL شما ران بشه . همینقدر تمیز و مجلسی .
مثلا من تو کد خودم گذاشته بودم که بعد از initiate شدن یک فایل بسازه توی users/public .
نمونه رضایت مشتری عزیزمون رو میتونید ببینید :
حالا سوال آخر ! واقعا کدوم COM رو هایجک کنیم تا نقش Persist رو برامون بازی کنه . اینجا دیگه واقعا خلاقیت آدماست. شما میتونید با ProcMon مثلا مسیرهایی که توش InprocServer32 دارن رو ببینید تا بفهمید کدوم COM ها با فرکانس بیشتری استفاده میشن یا اینکه خودتون بگردید و ریسرچ کنید که کدوم COM ها تو هر ریبوت حداقل یکبار توسط برنامه ها / سیستم عامل ران میشن .
نهایتا هم چندتا لینک میذارم از جاهایی که تحت عنوان منبع ازشون استفاده کردم. اگر مفید بود لایک کنید و استوری رو بالا بکشید. تشکر .
https://www.221bluestreet.com/offensive-security/windows-components-object-model/com-hijacking-t1546.015
https://www.sektor7.institute/course/rto-pers
https://github.com/leoloobeek/COMProxy/
https://github.com/nccgroup/acCOMplice