مایکروسافت در Patch Tuesday فوریه 2024، آسیب پذیری CVE-2024-21338 را بر اساس یک راهنمای امنیتی از جان وویتشک و Avast منتشر کرد. این یک نقص جدید «ارتقای سطح دسترسی از سطح ادمین به کرنل» در ویندوز است. این آسیب پذیری به بازیگران مخرب (در این مورد عمدتا گروه Lazarus مرتبط با کره شمالی) اجازه می دهد تا از طریق روتکیت FudModule.dll به دسترسی کرنل دست یابند.

تاکتیک BYOVD (Bring Your Own Vulnerable Driver) که به معنای استفاده از درایورهای آسیب پذیر امضا شده توسط خود مهاجم است، به طور گسترده توسط بازیگران تهدید و توسعه دهندگان بدافزار در سراسر جهان به کار می‌رود تا به دسترسی کرنل برسند، اما این مورد فراتر از BYOVD عمل می کند. این روش با درایورهای ویندوزی که از پیش روی سیستم نصب شده اند نیز کار می کند؛ از جمله appid.sys، درایوری که اصلا برای AppLocker ویندوز استفاده شده است. طبق وب سایت مایکروسافت، «AppLocker به شما کمک می کند کنترل کنید که کدام برنامه ها و فایل ها توسط کاربران اجرا شوند.»

آسیب پذیری CVE-2024-21338 از طریق ارتباط IOCTL (Input Output Control) توابع مشخصی در درایور appid.sys را مورد هدف قرار می دهد. به طور مشخص، تابع AipSmartHashImageFile می تواند از کد کنترلی آسیب پذیر IOCTL با مقدار 0x22A018 فراخوانی شود. با فراخوانی این کد کنترلی و ارسال یک بافر ورودی با ساختار خاص، می توانیم فیلد PreviousMode در متن نخ _KTHREAD را مخدوش کنیم. فیلد PreviousMode تعیین می کند که آیا فراخوانی مستقیم سیستم (توابع Nt/Zw) توسط کرنل یا توسط کاربر انجام شده است. با در نظر داشتن این موضوع، اکنون می توان فراخوانی های مستقیم سیستمی را اجرا کرد که روی کرنل سیستم عامل اثر می گذارند و در نتیجه بازیگر مخرب می تواند به کرنل قربانی دسترسی پیدا کند.

1. اطلاعات اولیه درباره آسیب پذیری

آسیب پذیری CVE-2024-21338 از نوع آسیب‌پذیری ارتقاء سطح دسترسی در هسته ویندوز[1] است که مشکل Untrusted Pointer Dereference (ارجاع‌زداییِ اشاره‌گرِ غیرقابل‌اعتماد) ‌در درایور هسته مایکروسافت بنام appid.sys دارد که با ارسال IOCTL و ساختار آسیب پذیر همراه آن می تواند منجر به Elevation of Privilege از نوع بردار Local یا LPE شود.

این آسیب پذیری نیازمند سطح دسترسی مورد نیاز Privileges Required برای امکان اجرای فرایند در کانتکست کاربری LocalService است، برای اجرا نیاز به تعامل کاربر ندارد.

در ادامه این سند ترجمه بخش هایی از مستندات و تحلیل های موجود را ذکر خواهیم کرد و پس از آن خودمان سورس را ویرایش و سیستم را دیباگ میکنیم تا لحظه تریگر شدن آسیب پذیری پیش و پس از آن را مشاهده و بررسی کنیم.

جدول شمارش نقاط ضعف[2]:

CWE-ID	CWE Name	Source
NVD-CWE-noinfo	Insufficient Information	cwe source acceptance level NIST
CWE-822	Untrusted Pointer Dereference	Microsoft Corporation

با استفاده از این لینک میتوانید اطلاعات بیشتری را در ارتباط با آسیب پذیری “Untrusted Pointer Dereference” بدست آورید:

CVSS Score	Severity	Version	Vector String
7.8	HIGH	3.1	CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H/E:F/RL:O/RC:C

2. مقاله اول[2]

2.1 تحلیل

هدف اصلی روتکیت FudModule.dll که توسط گروه Lazarus ساخته شده، فرار از شناسایی توسط محصولات EDR/آنتی ویروس است، از طریق تغییر رفتار آنها یا پنهان کردن عملکردشان، همانطور که در «Lazarus and the FudModule Rootkit: Beyond BYOVD» نشان داده شده است. با این حال، در چارچوب پست Avast با عنوان «Admin to Kernel Zero-Day» در این مقاله روی عملکرد روتکیت تمرکز نمی کنیم. در عوض، روی نحوه کار آسیب پذیری appid.sys، روش های بهره برداری از آن و نحوه برطرف شدن آن توسط پچ MSRC در آخرین نسخه های ویندوز تمرکز خواهیم کرد.

در تاریخ 13 فوریه 2024، در جریان Patch Tuesday، مرکز پاسخگویی امنیتی مایکروسافت (MSRC) یک آسیب پذیری جدید با شناسه CVE-2024-21338 را افشا کرد که به مهاجم امکان می دهد با ارسال دستورالعمل های مخصوص به یک گجت از طریق توابع در معرض IOCTL، حافظه کرنل را بخواند و بنویسد.

ابتدا، برای هر گونه ارتباط از طریق IOCTL در ویندوز، لازم است یک هندل به درایوری که با آن ارتباط برقرار می کنیم باز کنیم. در این مورد، با تحلیل درایور appid.sys (AppLocker) در IDA Pro، می توانیم در تابع DriverEntry ببینیم که شی ای که باید برای آن هندل باز شود، “\Device\AppID” است، همانطور که در تصویر زیر نشان داده شده است.

با این حال، وقتی تلاش می کنیم تا با استفاده از NtCreateFile یک هندل مدیر سیستم (administrator) به “\Device\AppID” باز کنیم، با کد NTSTATUS برابر 0xC0000022 (STATUS_ACCESS_DENIED) مواجه می شویم؛ به این معنی که کاربر مدیرسیستم دسترسی های لازم برای باز کردن هندل به دستگاه AppID را ندارد. این موضوع ما را به این سوال می رساند که چه مجوزهایی لازم است تا بتوانیم موفقیت آمیز هندل را باز کنیم. با بررسی تابع آسیب پذیر AipSmartHashImageFile برای پی بردن به دلیل عدم توانایی در باز کردن هندل به دستگاه “\Device\AppID”، کشف کردیم که از طریق یک ارجاع خارجی در تابع AipSmartHashImageFile می توان به تابع AipDeviceIoControlDispatch رسید. این تابع مرتبط با هاندلری است که تمامی فراخوانی های IOCTL به درایور را از طریق هندل Device پردازش می کند.

با باز کردن این فراخوان می توان دید که تابع AipSmartHashImageFile از طریق کد IOCTL 0x22A018 فراخوانی می شود، همانطور که در شکل زیر نشان داده شده است.

خوب، حالا که کد IOCTL را داریم، چه کاری از آن ساخته است؟ علاوه بر ارسال درخواست کنترلی به آن تابع خاص از طریق NtDeviceIoControl، خود کد IOCTL ساختار مشخصی دارد. با تجزیه کد IOCTL در تابع AipSmartHashImageFile می بینیم که طبق مستندات IOCTL مایکروسافت این کد IOCTL برای فراخوانی به مجوز 0x0002 (FILE_WRITE_ACCESS) نیاز دارد. این به این معنی است که احتمالا درایور ما نیز برای باز کردن هندل به همین مجوز نیاز دارد. اما کدام کاربر روی دستگاه AppID این مجوز را به ما می دهد؟ برای یافتن پاسخ می توان از ابزار WinObj از مجموعه SysInternals استفاده کرد تا همه اشیای سیستم نصب شده فعلی را فهرست کنیم که شامل تمام دستگاه ها و درایورها نیز می شود. با بررسی مجوزهای دستگاه AppID با استفاده از برنامه WinObj می بینیم که گروه Administrators در ACL دستگاه AppID مجوز نوشتن (Write) لازم را ندارد، همانطور که در تصویر زیر نشان داده شده است.

و همچنین مشاهده می‌کنیم که حساب کاربری LOCAL SERVICE مجوز نوشتن لازم را دارد و می‌تواند با موفقیت از طریق این کد IOCTL به تابع مورد نظر دسترسی پیدا کرده و آن را فراخوانی کند.

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

2.2 توسعه

مرحله بهره برداری با به دست آوردن دسترسی به هندل “\Device\AppID” آغاز می شود. برای این کار، نیاز به داشتن مجوز LOCAL SERVICE در فرایند خود داریم. برای کسب این دسترسی، باید تکنیک های جعل توکن دسترسی (token impersonation) را به کار ببریم تا مجوز Local Service را در فرایند خود پیاده سازی کنیم.

توکن دسترسی ویندوز چیست؟ بر اساس مستندات مایکروسافت، توکن دسترسی «شیئی است که زمینه امنیتی یک فرایند یا نخ را توصیف می کند. اطلاعات موجود در توکن شامل هویت و سطح دسترسی حساب کاربری مرتبط با فرایند یا نخ است. وقتی یک کاربر وارد سیستم می شود، سیستم رمز عبور کاربر را با اطلاعات ذخیره شده در یک پایگاه داده امنیتی مقایسه می کند. اگر رمز عبور تایید شود، سیستم یک توکن دسترسی تولید می کند. هر فرایندی که به نمایندگی از آن کاربر اجرا می شود دارای یک نسخه از توکن دسترسی است.»

این توکن ها را می توان از فرایندهای راه دور در ویندوز با بررسی اینکه آیا فرایند دارای سطح دسترسی مشخصی است یا نه، به سرقت برد. در این مورد، برای ارتقا از سطح ادمین به «NT AUTHORITY\SYSTEM (S-1-5-18)» دو سطح دسترسی لازم است: «SeDebugPrivilege» و «SeAssignPrimaryTokenPrivilege».

فرایند «winlogon.exe» توکن هایی با هر دو سطح دسترسی را افشا می کند چون طبق طراحی این فرایند با حساب SYSTEM اجرا می شود؛ زیرا باید وضعیت ورود به سیستم ویندوز را مدیریت کند و کاربر می تواند به سادگی با آن تعامل کند، در نتیجه کاربر می تواند توکن دسترسی «NT AUTHORITY\SYSTEM» را از winlogon کپی کند.

پس از اینکه با موفقیت توکن SYSTEM را با استفاده از «DuplicateTokenEx» تکثیر کردیم، اکنون می توانیم توکن دسترسی «NT AUTHORITY\LOCAL SERVICE (S-1-5-19)» را با جستجوی هر توکنی که دارای سطوح دسترسی یادشده باشد به دست آوریم: «SeDebugPrivilege» و «SeImpersonatePrivilege». معمولا بیشتر فرایندهای «svchost.exe» به صورت «NT AUTHORITY\LOCAL SERVICE» اجرا می شوند، بنابراین یافتن یکی از آنها باید بسیار ساده و سریع باشد.

حالا که دسترسی «NT AUTHORITY\LOCAL SERVICE» را داریم، یعنی دسترسی نوشتن به هندل دستگاه «AppID» («\Device\AppID») و کد کنترلی 0x22A018 را داریم، می توانیم با موفقیت هندل مذکور را باز کنیم. با باز کردن هندل صحیح و دسترسی به تابع AipSmartHashImageFile می توانیم یک بارگذاری مفید (payload) بسازیم تا «مقدار بایت PreviousMode» را خراب کنیم.

PreviousMode یک فیلد در هر ساختار _KTHREAD است که نشان می دهد فراخوانی سیستم از KernelMode فرا خوانده شده یا از UserMode. با این فرض، برخی فراخوانی های سیستمی Nt یا Zw (فراخوانی های مستقیم) مقدار PreviousMode را با چک کردن فیلد PreviousMode نخ جاری بررسی می کنند. در ادامه یک مثال از قطعه کد فراخوانی سیستم «NtWriteVirtualMemory» گرفته شده از آسمبل شدن ntoskrnl.exe آمده است:

فیلد PreviousMode یک شمارش ساده با دو عضو است: UserMode و KernelMode، که مقدار KernelMode برابر صفر و UserMode برابر یک است. با دانستن اینکه می توانیم این مقدار را در ساختار _KTHREAD جاری در حافظه تغییر دهیم، عمیق تر می شویم تا بفهمیم فساد حافظه این فیلد در عمل چگونه کار می کند.

عامل اصلی که اجازه می دهد آسیب پذیری PreviousMode کار کند تابع AppHashComputeImageHashInternal است، که توسط تابع AppHashComputeFileHashesInternal درون تابع AipSmartHashImageFile فراخوانی می شود، همان طور که در تصویر زیر نشان داده شده است.

همانطور که در تصویر زیر می بینیم، دو پارامتر از طریق این زنجیره توابع منتقل می شوند و در نهایت به AppHashComputeImageHashInternal می رسند، که بر اساس یک بافر کنترل شده توسط کاربر، یک اشاره گر تابع کنترل شده توسط کاربر را اجرا می کند؛ در این مورد، این بافر از طریق فراخوانی ما به کد کنترلی 0x22A018 تامین می شود.

حالا، آیا نمی توانیم یک شِل‌کد در فضای کاربر بنویسیم که کنترل را به کدی بدهد که باعث شود نخ جاری مقدار PreviousMode را به 0 کاهش دهد؟ متاسفانه نمی توانیم. باید با kCFG و SMEP آشنا شویم.

SMEP (Supervisor Mode Execution Prevention) اجازه نمی دهد کد فضای کاربر در سطح دسترسی بالاتر اجرا شود، بنابراین اجرای شِل‌کد در فضای کاربر برای رسیدن به هدف مورد نظر ممکن نیست.
kCFG (Kernel Control Flow Guard) فراخوانی به اشاره‌گرهای تابع دلخواه یا تایید نشده را ممنوع می کند، به ویژه آنهایی که به آدرس های فضای کاربر یا موقعیت هایی خارج از نقشه بیت CFG تعیین شده برای توابع معتبر کرنل اشاره دارند. این مکانیزم تضمین می کند که همه فراخوانی های غیرمستقیم تابع در برابر سیاست یکپارچگی جریان کنترل بررسی شوند و از منحرف شدن جریان اجرا به قطعات کد مخرب یا غیرمنتظره جلوگیری نمایند.

با توجه به این دو مکانیزم حفاظتی، اکنون باید تابعی بیابیم که در نقشه بیت CFG متعلق به یک تابع کرنل معتبر وجود داشته باشد تا به عنوان هدف مشروع برای یک فراخوانی غیرمستقیم تابع محسوب شود. ایده‌آل این است که این تابع قابلیت‌هایی ارائه دهد که برای بهره‌برداری بیشتر قابل استفاده باشند، در این مورد عملیات حافظه، و در عین حال محدودیت‌های تعیین‌شده توسط kCFG و SMEP را رعایت کند.

با کمک پژوهش‌های قبلی در این زمینه، مقاله Windows AppLocker Driver Privilege Escalation (CVE-2024-21338) نحوه یافتن توابع معتبر CFG در نقشه بیت CFG را تشریح می‌کند. تابع انتخاب‌شده برای POC ما ExpProfileDelete است که یک تابع معتبر در CFG محسوب می‌شود و عملکرد آن در واقع برای هدف مورد نظر ما مناسب است. با نگاه به دیس اسمبلی تابع ExpProfileDelete:

می توانیم ببینیم که تابع یک پارامتر دریافت می کند که به تابع ObfDereferenceObject پاس داده می شود. این پارامتر سپس باعث می شود آدرسی که به تابع ExpProfileDelete پاس داده شده کاهش یابد، و در نتیجه مقدار داده در آدرس PreviousMode از 1 به 0 تغییر کند؛ این امر موجب می شود فراخوانی های سیستمی NtWriteVirtualMemory و NtReadVirtualMemory فراخوانی های خود را از حالت کرنل تفسیر کنند. این امکان به یک کاربر مخرب اجازه می دهد حافظه فضای کرنل را در سیستمی که از این آسیب پذیری سوءاستفاده می کند کنترل کند.

2.3 اصلاح

پچی که توسط Microsoft Security Response Center در فوریه منتشر شد، قبل از فراخوانی AipSmartHashImageFile یک بررسی ExGetPreviousMode اضافه کرد که مانع از این می شود که فراخوانی های فضای کاربر باعث فعال شدن callback شوند. شکل زیر دیس اسمبلی همان کد کنترلی را در نسخه های جدیدتر ویندوز نشان می دهد.

با استفاده از ابزار BinDiff که تفاوت های بین دو باینری را نمایش می دهد، می توانیم تغییرات اعمال شده در پچ را نیز مشاهده کنیم که صرفا یک بررسی ExGetPreviousMode است.

2.4 اثبات مفهوم

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

2.5 نتیجه گیری

خلاصه اینکه آسیب پذیری CVE-2024-21338 تهدید قابل توجهی برای ارتقای سطح دسترسی در سیستم های ویندوز ایجاد می کند، به ویژه اینکه گروه Lazarus از آن برای دور زدن مکانیزم های حفاظتی معمول مانند EDR و آنتی ویروس استفاده کرده است. این آسیب پذیری یک تکنیک پیشرفته را نشان می دهد که فراتر از روش BYOVD عمل می کند؛ با دستکاری فیلد PreviousMode در کرنل سطح دسترسی غیرمجاز به دست می آورد و همزمان با استفاده از تکنیک های پیشرفته جعل توکن امکان اجرای کد از سطح ادمین تا کرنل را فراهم می سازد. پاسخ مایکروسافت از جمله انتشار پچ حیاتی در به روز رسانی فوریه، نشان دهنده بازی پی در پی بین کارشناسان امنیت و بازیگران تهدید است. تحقیق و بررسی درباره CVE-2024-21338 به درک بهتر نحوه وقوع و بهره برداری این نوع آسیب پذیری در محیط واقعی کمک می کند.

در ادامه مقاله دیگری را مورد بررسی قرار خواهیم داد که نکات مهمی را شامل می شود:

1. مقاله دوم [1]

3.1 خلاصه روند کار

در این مقاله، به طور خلاصه کوتاهی است از نکات اصلی که در ادامه متن بررسی می‌شود. در این سند به طور خلاصه مطالب زیر گفته شده است:

باگ در تابع `AppHashComputeImageHashInternal()` قرار دارد و با ارسال یک IOCTL با مقدار `0x22A018` به دستگاه `\\Device\Appid` امکان‌پذیر است. ([Crowdfense] [1])
در این باگ، دو اشاره‌گر (pointer) از بافر ورودی IOCTL انتظار می‌رود.
این نقص باعث می‌شود بتوان کنترل کامل Instruction Pointer و داده‌های آرگومان اول را در یک callback به دست گرفت.
طبق مجوز (ACL) دستگاه، فقط کاربران `LOCAL SERVICE` و `AppIDSvc` اجازه ارسال این IOCTL را دارند.
درایور هدف یعنی `sys` به‌طور پیش‌فرض بارگذاری نیست و برای فعال شدن باید از طریق سرویس AppLocker یا ارسال رویدادی به ETW خاص فعال شود.

3.2 چالش‌ها

3.2.1 SMEP & kCFG

با اینکه ما کنترل کامل روی اشاره‌گر دستورالعمل [3] داریم، نمی‌توانیم مستقیم یک آدرس فضای کاربر[4] را بدهیم و شلکد [5] خود را اجرا کنیم، زیرا مکانیزم محافظتی[6] جلوگیری از اجرای کد در حالت سرپرست SMEP[7] در کار است.
تابع callback یک فراخوانی غیرمستقیم[8] انجام می‌دهد، بنابراین باید یک اشاره‌گر معتبر در فضای کرنل[9] بیابیم تا از محافظت [10]kCFG عبور یا دور زدن[11] کنیم.

3.2.2 KASLR

از آنجا که این اکسپلویت در بستر یا زمینه[12] کاربر LocalService اجرا خواهد شد، KASLR در اینجا مانع قابل توجهی ایجاد نمی کند. با کمک فراخوان سیستمی پایدار ()NtQuerySystemInformation می‌توانیم به سادگی تقریبا تمامی آدرس های کرنل لازم برای ساختن اکسپلویت را فاش [13] کنیم.

3.3 بارگذاری درایور هدف

از آنجا که درایور به طور پیش فرض بارگذاری نمی شود، می توانیم آن را به صورت دستی یا از طریق مدیریت سرویس (Service Manager) یا با ارسال رخداد به یک ارائه دهنده ETW مربوط به AppLocker برای راه اندازی سرویس AppID بارگذاری کنیم. برای اهداف تست، این درایور از قبل در فضای کرنل بارگذاری شده بود.

3.4 بهره برداری[14]

3.4.1 تحلیل علت اصلی[15]

زمانی که یک IOCTL با مقدار 0x22A018 دریافت شود، تابع ()AipSmartHashImageFile برای پردازش این کد کنترلی فراخوانی می شود. در ویندوز 11، انتظار می رود پارامتر اول یک اشاره‌گر به ساختار زیر باشد:

				
					typedef struct _HASH_IMAGE_FILE {
    PVOID ImageContext;             // pointer to the context of hashing file image
    FILE_OBJECT *FileObject;        // kernel object pointer of file 
    PVOID CallbackTable;            // pointer to callback functions
    ULONGLONG Action;               // not so sure  
} HASH_IMAGE_FILE, *PHASH_IMAGE_FILE;

سپس تابع ()AppHashComputeFileHashesInternal فراخوانی می شود تا هش فایل هدف را محاسبه کند. دو پارامتر اول ارسال شده به این تابع قابل کنترل توسط کاربر هستند:

بعد از انجام برخی مقداردهای اولیه، تابع ()AppHashComputeFileHashesInternal تابع ()AppHashComputeImageHashInternal را برای به دست آوردن مقدار(های) هش فراخوانی می کند و دو پارامتر اول مستقیماً به تابع هدف منتقل می‌شوند.

در داخل تابع ()AppHashComputeImageHashInternal، پیش از محاسبه هش تصویر هدف، دو فراخوانی callback را از اشاره گر پارامتر دوم انجام می دهد؛ این اشاره گرها کاملا توسط کاربر قابل کنترل هستند. این امر منجر به ایجاد شرایطی می شود که در آن می توان به کنترل کامل اشاره گرِ دستورالعمل (RIP) دست یافت. به طور کلی، نمودار فراخوانی تابع آسیب پذیر به صورت زیر است:

3.4.2 SMEP & kCFG bypassing

به دلیل فعال بودن SMEP و kCFG، اگر مستقیماً یک گجت ROP تصادفی یا شلکد را از فضای کاربر فراخوانی کنیم، کرنل با یک بررسی خطا متوقف می‌شود (bug check). در عوض، باید توابع سودمندی بیابیم که به ما در انجام یک حمله مبتنی بر داده (data-only attack) کمک کنند.

بعد از مطالعه چند مقاله، متوجه شدم تابع ()nt!SeSetAccessStateGenericMapping به طور گسترده برای عبور از kCFG استفاده می شود. با این حال، این تابع نیاز دارد پارامتر اول به یک ساختار اشاره کند که اندازه آن حداقل 0x50 باشد:

در عین حال، IOCTL هدف انتظار دارد که اشاره گر ورودی دارای اندازه 0x20 باشد (اندازه ساختار _HASH_IMAGE_FILE):

تصمیم گرفتم خودم یک گجت پیدا کنم. بعد از صرف زمان برای جستجوی توابع کوچکی که بسته به قیود داده شده کارهای جالب انجام می دهند، یک گزینه ی مناسب یافتم: nt!DbgkpTriageDumpRestoreState. این گجت امکان بازنویسی 8 بایت در آفست 0x2078 از اشاره گر اول را فراهم می کند (این ساختار اشاره گر ImageContext است) با مقدار موجود در آفست 0x10 (فیلد CallbackTable در این حالت) از ساختار ورودی.

3.5 ساختن کد بهره بردار[16]

5.3.1 دو روش ممکن برای بهره‌برداری از این باگ با استفاده از گجت مذکور وجود دارد:

مقداردهی فیلد PreviousMode در شیء هدف KTHREAD، سپس سوءاستفاده از فراخوان‌های سیستمی NtReadProcessMemory/NtWriteProcessMemory برای به‌دست‌آوردن امکان خواندن/نوشتن دلخواه (arbitrary read/write) روی فضای کرنل. در گزارش Avast، گروه Lazarus از این روش استفاده کرده است.
بازنویسی ساختار _SEP_TOKEN_PRIVILEGES در توکن فرایند جاری برای فعال کردن SeDebugPrivilege و سپس سوءاستفاده از این سطح دسترسی برای تزریق شِل‌کُد در یک فرایند دارای سطح دسترسی. این روش نیازمند راه‌اندازی باگ دو بار است تا هم فیلدهای Present و هم Enabled بازنویسی شوند.

اگرچه مقدار نوشته شده همان اشاره گر به فیلد CallbackTable در ساختار _HASH_IMAGE_FILE است، این مقدار باید یک اشاره گر معتبر باشد. با این حال، با استفاده از تابع VirtualAlloc می توان باز هم یک مقدار مناسب برای نوشتن ساخت، زیرا هیچ یک از دو روش ارائه شده نیاز به یک مقدار بسیار مخصوص ندارند. در اکسپلویت من، هر دو روش را برای دستیابی به یک پوسته SYSTEM نشان داده ام.

3.5.2 کد بهره بردار

کد اکسپلویت در این مخزن آدرس گیت هاب منتشر شده است.

3.5.3 دمو

در لینک های زیر میتوانید فیلم دمو دو تکنیک استفاده شده را مشاهده کنید:

POC 1 – Abusing PreviousMode

POC 2 – Abusing SeDebugPrivilege

درادامه خودمان هم برخی موارد را در دیباگر مورد بررسی قرار خواهیم داد:

4. بررسی برخی موارد با ریموت کرنل دیباگ

4.1 اجرای آسیب پذیری

در اولین مرحله با توجه به اینکه آبجکت این دستگاه با سطح دسترسی ادمین قابل نوشتن نیست، آنرا بررسی خواهیم کرد.

همانطور که در تصویر زیر مشاهده میکنید کاربر LocalService دسترسی کامل به این دستگاه دارد پس ما در مرحله اول بایستی توکن خود را تغییر بدهیم، که خارج از حوصله این سند است و ما فعلا از ابزارpsexec مایکروسافت استفاده میکنیم تا کمحیط دستور با توکن مورد نظرمان را اجرا کنیم.

پس از اجرای برنامه بهره بردار و تریگر شدن نقطه توقف دستی ما در کد برنامه بهره بردار، exploit.exe را مشاهده می‌کنید:

در این مرحله آماده سازی و ساختن ساختار مورد نظر برای ارسال به درایور انجام می‌شود و برنامه با دسترسی بالا اجر ا می‌گردد. در این مرحله توکن سیستم روی توکن پروسه فعلی نوشته می‌شود.

با توجه به اینکه بخش هایی از کد در کرنل اجرا میگردد روی درایور Appid نقاط توقف خود را تنظیم میکنیم تا رسیدن بافر به این درایور و تریگر شدن کد بهره بردار را مشاهده کنیم.

پس از خاتمه دادن برنامه سیستم کرش نمیکند چرا که ما prev را به حالت اصلی یعنی کد کاربر تغییر داده ایم و برنامه با موفقیت خاتمه پیدا میکند و این مورد باعث میشود کد بهره بردار به اصطلاح پایدارتر یا Reliable شود.

در تصویر زیر بازگرداندن فلگ‌های حافظه به حالت درست را مشاهده می‌کنید.

با اجرای موفقیت آمیز در کرنل و بازگشت پاسخ از کرنل:

بخش مهم قبل از تغییر فلگ prev در حافظه توسط گدجت مورد نظر:

تغییر 4 بایت اول فلگ PRev:

تغییر 4 بایت دوم فلگ PRev:

تغییر موفقیت آمیز و برگشت به ادامه اجرای روال:

بازگشت موفق آمیز از کرنل:

اجرای ترد اصلی پس از بازگشت موفق از کرنل با true کردن فلگ مربوطه:

سرقت توکن سیستم و اجرای خط فرمان سیستم:

4.2 راه کار مقابله

مایکروسافت برای این آسیب پذیری وصله ای را تولید کرده است که با نصب نسخه متناسب سیستم عامل مورد استفاده خود از این لینک یا با نصب آخرین بروزرسانی در windows update صورت خودکار میتوانید از اجرای این آسیب پذیری ممانعت بعمل آورید. همانطور که در تصویر مشاهده میکنید در صورت نصب وصله مورد نظر اکسپلویت قادر به گرفتن هندل از درایور نیست.

پیش از نصب وصله:

4.3 پس از نصب وصله:

تلاش برای اجرا روی یک سیستم عامل که پیش تر بروزرسانی شده است، همانطور که مشاهده می‌کنید سیستم قادر به گرفتن هندل از درایور فوق نیست:

4.4 توضیح روند این آسیب پذیری

Userland send IOCTL (0x22A018):

برنامه کاربر در اولین مرحله اقدام به ارسال ioctl به کرنل و درایور هدف خود یعنی appid می کند البته پیش از آن اقدام به ساختن بافر ورودی مورد نظر (تنظیم callbackهای سو استفاده کننده) را انجام داده است.

AipDeviceIoControlDispatch() <- dispatch IOCTL to driver:

با ارسال شدن ioctl در درایور هدف dispatch روال آن فراخوانی شده و بخش کنترل کننده کد ioctl که در بالا ذکر شده است توابع بعدی که باید این بافر را پردازش کنند رافراخوانی میکند.

AipSmartHashImageFile():

اولین تابعی که توزیع کننده یا dispatcher فراخوانی میکند این تابع است.

AppHashComputeFileHashesInternal():

این تابع زنجیره دیگری است که فراخوانی می شود.

AppHashComputeImageHashInternal():

در نهایت تابع آسیب پذیر فراخوانی میگردد.

read callback ptrs from param (both pointers are user-controllable):

پس از فراخوانی اقدام به خواندن اشاره گر های callback ها توسط پارامتر های ورودی تابع می کند، دقیقا نقطه ای که توسط برنامه مد کاربر قادر به کنترل کرنل میشود و آسیب پذیر است.

indirect call -> callback1 / callback2:

در نهایت فراخوانی غیر مستقیم دو callback ارسال شده به درایور appid.

potential RIP takeover:

در نهایت موفق به بدست گرفتن رجیستر RIP میشویم که کنترل اجرای برنامه را در دست دارد(با نگهدار آدرس بعدی که باید اجرا شود).

Change PreviousMode:

با تغییر دادن فیلد PreviousMode سیستم عامل تصور میکند که کد از کرنل فراخوانی شده است و به برنامه کاربر اجازه خواندن توکن های سیستم و تغییر توکن خود را میدهد.

5. مراجع:

				
					https://www.crowdfense.com/windows-applocker-driver-lpe-vulnerability-cve-2024-21338/
https://hakaisecurity.io/cve-2024-21338-from-admin-to-kernel-through-token-manipulation-and-windows-kernel-exploitation/research-blog/
https://hackyboiz.github.io/2025/01/12/l0ch/bypassing-kernel-mitigation-part2/en/
https://nero22k.github.io/posts/windows-applocker-driver-elevation-of-privilege-cve-2024-21338/
https://www.crowdfense.com/windows-applocker-driver-lpe-vulnerability-cve-2024-21338/
https://www.cve.org/CVERecord?id=CVE-2024-21338
https://nvd.nist.gov/vuln/detail/cve-2024-21338
https://cwe.mitre.org/data/definitions/822.html
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-21338
https://learn.microsoft.com/en-us/windows/security/application-security/application-control/app-control-for-business/applocker/applocker-overview

اصطلاحات:

[1] Windows Kernel Elevation of Privilege Vulnerability
[2] Weakness Enumeration
[3] Instruction Pointer
[4] user-mode pointer
[5] shellcode
[6] mitigation
[7] Supervisor Mode Execution Prevention
[8] indirect call
[9] kernel space
[10] Kernel Control Flow Guard
[11] bypass
[12] context
[13] Leak
[14] Exploitation
[15] Root Cause Analysis
[16] Building the exploit

تحلیل آسیب پذیری CVE-2024-21338

CVE-2024-21338 Vulnerability Analysis