۱. مقدمه
در دسامبر 2024، تیم تحقیقاتی MDSec در جریان توسعه ابزارهای ردتیم (Red Team) خود، با رفتاری غیرمعمول در مکانیزم انتقال تنظیمات Accessibility ویندوز مواجه شد. این رفتار، که در نگاه اول صرفاً یک ناهماهنگی جزئی در جریان انتقال داده بین کلیدهای رجیستری به نظر می‌رسید، در واقع نشانه‌ای از یک نقص معماری عمیق‌تر بود. طی ماه‌های بعد، محققان دریافتند که این رفتار قابل بهره‌برداری است و به مهاجمی با حداقل دسترسی کاربری اجازه می‌دهد تا بالاترین سطح اختیار سیستم‌عامل یعنی SYSTEM را در اختیار بگیرد. این آسیب‌پذیری، که بعد با نام RegPwn شناخته شد، از ژانویه 2025 تا اواخر فوریه 2026 به‌صورت داخلی در عملیات ردتیم استفاده شد. در نهایت پس از ارجاع به مایکروسافت، با شناسه CVE-2026-24291 ثبت و در مارس 2026، پچ (Patch) آن منتشر شد.
آنچه RegPwn را از بسیاری از آسیب‌پذیری‌های ارتقاء سطح دسترسی متمایز می‌کند، نه پیچیدگی فنی آن، بلکه ظرافت منطقی آن است. این آسیب‌پذیری نه از آسیب‌پذیری‌های پیچیده، بلکه از یک اشتباه ساده در طراحی مجوزهای دسترسی ناشی می‌شود. سیستم به کاربر کم‌سطح اجازه نوشتن در مکانی را می‌دهد که بعدها یک پروسه SYSTEM آن را به‌عنوان منبع معتبر می‌خواند. این الگو اعتماد کورکورانه یک پروسه سطح‌بالا به داده‌ای است که توسط کاربر عادی قابل تغییر است و نمونه‌ای کلاسیک از نقص در مرز اعتماد (Trust Boundary) است.
این سند، تحلیل فنی جامعی از CVE-2026-24291 ارائه می‌دهد. از ریشه‌های معماری نقص تا مکانیزم دقیق بهره‌برداری و راهکارهای رفع آن. لازم به ذکر است که تکه‌کدهای ارائه‌شده در این سند دارای حذفیات هدفمند هستند و صرفاً شامل بخش‌های مهم و مرتبط با موضوع می‌باشند. برای مشاهده کد منبع کامل و اثبات مفهوم، به مخزن رسمی MDSec مراجعه کنید.
۱.۱ اطلاعات اجمالی آسیب‌پذیری
جدول ۱: اطلاعات اجمالی آسیب‌پذیری
شماره آسیب پذیری: | CVE-2026-24291 |
امتیاز (CVSS): | 7.8 (High) |
مولفه درگیر: | Windows Accessibility Infrastructure (ATBroker.exe) |
نوع آسیب پذیری: | Elevation of Privilege (EoP) |
قابلیت در صورت اکسپلویت: | ارتقاء سطح دسترسی از Standard User به SYSTEM |
۱.۲ تحلیل‌های از پیش ارائه شده
جدول ۲: تحلیل‌های از پیش ارائه شده
نام تحلیلگر | تاریخ انتشار | لینک |
MDSec Research | 13 مارس 2026 | RIP RegPwn |
SecureLayer7 | 23 مارس 2026 | https://blog.securelayer7.net/cve-2026-24291-regpwn-windows-privilege-escalation/ |
Microsoft | 10 مارس 2026 | https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-24291/ |
۱.۳ معرفی ویژگی Accessibility در ویندوز
ویندوز برای پشتیبانی از بهره‌وری، خلاقیت و سهولت استفاده برای تمامی افراد طراحی شده است. از این رو قابلیت‌هایی تحت عنوان ویژگی‌های Accessibility در آن تعبیه شده است. هدف اصلی این قابلیت‌ها، بهبود قابلیت استفاده از ویندوز برای کاربرانی با انواع محدودیت‌های جسمی است، از جمله درجات مختلف ضعف بینایی (تا نابینایی کامل)، کم‌شنوایی، ناتوانی جسمی یا اختلال در عملکرد حرکتی.
مایکروسافت به منظور مدیریت متمرکز این ابزارها، یک کامپوننت اختصاصی تحت عنوان ATBroker.exe (Assistive Technology Broker) را طراحی کرده است که به عنوان لایه میانی بین سیستم‌عامل و ابزارهای Accessibility عمل می‌کند. ATBroker نقش واسط را ایفا می‌کند، درخواست‌های فعال‌سازی ابزارهای Accessibility را دریافت، پیکربندی مربوطه را از رجیستری بارگذاری، و ابزار مناسب را با سطح دسترسی لازم اجرا می‌کند. فهرست ابزارهای نصب‌شده روی سیستم در کلید زیر ثبت می‌شود:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Accessibility\ATs
برخی از شناخته‌شده‌ترین این ابزارها عبارتند از:
- On-Screen Keyboard (osk.exe): صفحه‌کلید مجازی بر روی صفحه‌نمایش
- Narrator: خواننده صفحه برای کاربران نابینا
- Magnifier: بزرگ‌نمایی بخش‌هایی از صفحه
- Speech Recognition: کنترل ویندوز از طریق صدا
- Sticky Keys / Filter Keys / Toggle Keys: کمک به کاربران با محدودیت حرکتی
از دیدگاه امنیتی، آنچه این ابزارها را متمایز می‌کند، سطح دسترسی ویژه‌ای است که برای عملکرد صحیح به آن نیاز دارند. ابزارهای Accessibility باید بتوانند با پنجره‌های متعلق به سایر پروسه‌ها تعامل داشته باشند، از جمله ارسال ورودی، خواندن محتوا، و نمایش روی آن‌ها. به این منظور، مایکروسافت مکانیزمی به نام UIAccess Flag را طراحی کرده است که به یک پروسه اجازه می‌دهد با سطح High Integrity اجرا شود، بدون اینکه کاربر با یک UAC Prompt مواجه شود، به شرط اینکه باینری از یک مسیر معتبر (مانند C:\Windows\System32) اجرا شده و دارای امضای دیجیتال معتبر باشد.
۱.۳.۱ مروری برUser Account Control
UAC یک قابلیت امنیتی در ویندوز است که برای محافظت از سیستم‌عامل در برابر تغییرات غیرمجاز طراحی شده‌است. زمانی که انجام تغییراتی در سیستم به سطح دسترسی مدیریتی (Administrator) نیاز داشته باشد، UAC Prompt به کاربر اطلاع می‌دهد و به او امکان می‌دهد آن تغییر را تایید یا رد کند. UAC با محدود کردن دسترسی کدی که ممکن است با دسترسی Administrator اجرا شود، امنیت دستگاه را افزایش می‌دهد. این قابلیت به کاربران کمک می‌کند تا درباره اقداماتی که ممکن است بر پایداری و امنیت دستگاهشان تأثیر بگذارد، تصمیم آگاهانه بگیرند. UAC به‌طور پیش‌فرض فعال است و در صورتی که دسترسی مدیریتی داشته باشید می‌توانید آن را پیکربندی کنید.
۱.۳.۱.۱ تاریخچه ایزوله‌سازی حریم خصوصی رابط کاربری (User Interface Privacy Isolation (UIPI))
پیش از ویندوز ویستا (Vista)، هر پروسه‌ای که روی دسکتاپ (Desktop) کاربر اجرا می‌شد می‌توانست پنجره‌های متعلق به پروسه‌های دیگر از جمله پروسه‌های سطح سیستم (SYSTEM) را از طریق ارسال Window Message کنترل کند. این آسیب‌پذیری ساختاری که با نام Shatter Attack شناخته می‌شود، به یک کاربر محدود اجازه می‌داد از طریق ارسال پیام‌های دستکاری‌شده به یک پنجره سطح بالا، به سطح دسترسی خود را افزایش دهد (Privilege Escalation). راه‌حل اولیه مایکروسافت، حذف رابط کاربری از کد‌های با سطح دسترسی بالا (Privileged) بود. اما با معرفی UAC در ویندوز ویستا، که پروسه‌ها را در سطوح یکپارچگی (Integrity) متفاوت روی یک دسکتاپ اجرا می‌کرد، نیاز به یک مکانیزم ساختار یافته‌تری احساس شد. مایکروسافت ایزوله‌سازی حریم خصوصی رابط کاربری را معرفی کرد که بر پایه کنترل یکپارچگی اجباری (Mandatory Integrity Control) بنا شده بود. اگر سطح یکپارچگی (Integrity Level) یک پروسه پایین‌تر از پروسه‌ی دیگری باشد، ارسال Message به آن پنجره مسدود می‌شود. ویستا همچنین پروسه‌های کاربری را از دسکتاپ سرویس‌ها جدا کرد تا حتی در صورت ناکافی بودن UIPI، رابط کاربری سرویس‌ها برای پروسه‌های محدود قابل دسترسی نباشد.
۱.۳.۱.۲ مزایای کنترل حساب کاربری (User Account Control (UAC))
هدف از UAC، دسترسی Adminstrator آگاهانه است. به عبارت دیگر، UAC تضمین می‌کند که هیچ برنامه‌ای نمی‌تواند بدون اطلاع و رضایت کاربر به سطح دسترسی بالاتر دست یابد. همانطور که می‌دانیم پروسه‌هایی که با توکن کاربر استاندارد اجرا می‌شوند، فقط می‌توانند کارهایی را انجام دهند که همان سطح دسترسی استاندارد برایشان مجاز کرده است. برای مثال، Windows Explorer به‌طور خودکار با سطح دسترسی یک کاربر استاندارد اجرا می‌شود. هر برنامه‌ای که از طریق Windows Explorer اجرا شود نیز با همان سطح دسترسی استاندارد اجرا خواهد شد. زمانی که یک کاربر تلاش می‌کند کاری انجام دهد که به سطح دسترسی مدیریتی نیاز دارد، UAC یک پنجره درخواست رضایت (Consent Prompt) نمایش می‌دهد، این پیام به کاربر اطلاع می‌دهد که تغییری در شرف انجام است و از او اجازه می‌خواهد.
- اگر کاربر با انجام تغییر موافقت کند، عمل موردنظر با بالاترین سطح دسترسی موجود انجام می‌شود.
- اگر کاربر اجازه ندهد، عمل انجام نمی‌شود و برنامه‌ای که درخواست دسترسی داده بود، از اجرای آن کار منع می‌شود.
هنگامی که یک برنامه برای اجرا به دسترسی‌هایی بیشتر از سطح کاربر استاندارد نیاز داشته باشد، UAC به کاربران اجازه می‌دهد آن برنامه را با توکن Administrator Token اجرا کنند، یعنی با حقوق و مجوزهای مدیریتی به جای توکن پیش‌فرض استاندارد کاربر. به این ترتیب، کاربران همچنان در زمینه امنیتی کاربر استاندارد به کار خود ادامه می‌دهند، اما در صورت نیاز می‌توانند به برخی برنامه‌ها اجازه دهند با دسترسی‌های ارتقا یافته (Elevated Privilages) اجرا شوند.
۱.۳.۱.۳ جریان اجرایی در معماری کنترل حساب کاربری
در تصویر زیر می‌توانید معماری UAC را مشاهده کنید:
زمانی که کاربر یک برنامه را اجرا می‌کند، زنجیره زیر به ترتیب طی می‌شود:
- ShellExecute: Windows Explorer درخواست اجرا را از طریق ShellExecute به سیستم‌عامل ارسال می‌کند. ShellExecute، CreateProcess را فراخوانی می‌کند تا پروسه جدید را ایجاد کند.
- CreateProcess و بررسی مانیفست: در این مرحله، CreateProcess فایل اجرایی را بررسی می‌کند و سطح دسترسی درخواست شده آن را از مانیفست برنامه (Application Manifest) می‌خواند. مانیفست برنامه یک فایل XML است که درون باینری تعبیه شده و مشخص می‌کند برنامه برای اجرا به چه سطح دسترسی نیازد دارد. اگر سطح دسترسی درخواست‌شده بیشتر از توکن جاری کاربر باشد، CreateProcess خطای ERROR_ELEVATION_REQUIRED را باز می‌گرداند.
- سرویس اطلاعات برنامه (Application Information Service): پس از دریافت خطای ERROR_ELEVATION_REQUIRED پروسه ShellExecute درخواست را به سرویس Application Information ارجاع می‌دهد. این سرویس سیستمی مسئول راه‌اندازی برنامه‌هایی است که به سطح دسترسی بالاتر نیاز دارند. سرویس Application Information یک پروسه جدید با Full Adminstrator Token می‌سازد، اما نه قبل از اینکه از کاربر رضایت بگیرد.
- UAC Prompt و Secure Desktop: اگر سیاست Secure Desktop فعال باشد (که به‌صورت پیش‌فرض فعال است)، تمام درخواست‌های Elevation بدون استثنا به Secure Desktop منتقل می‌شوند و UAC Prompt در آنجا نمایش داده می‌شود. Secure Desktop یک محیط ایزوله است که در آن تنها پروسه‌های SYSTEM اجرا می‌شوند و هیچ برنامه User-mode نمی‌تواند با آن تعامل داشته باشد.
- exe و بررسی در Secure Desktop: پس از انتقال درخواست به Secure Desktop، سرویس Application Information فایل اجرایی consent.exe را در همین محیط ایزوله راه‌اندازی می‌کند. consent.exe که خود با سطح SYSTEM اجرا می‌شود، سه وظیفه اصلی را به ترتیب انجام می‌دهد:
- ابتدا امضای دیجیتال Authenticode فایل اجرایی درخواست‌کننده را اعتبار سنجی می‌کند. اگر فایل باینری فاقد امضا یا دارای امضای نامعتبر باشد، UAC Prompt با رنگ هشدار (نارنجی یا قرمز) نمایش داده می‌شود.
- سپس اطلاعات مربوط به برنامه را از مانیفست برنامه استخراج می‌کند تا در پنجره UAC Prompt به کاربر نمایش دهد، از جمله نام ناشر (Publisher)، آیکون و سطح دسترسی درخواست شده.
- در نهایت UAC Prompt را برای کاربر نمایش می‌دهد و منتظر تایید یا رد می‌ماند. پس از تایید کاربر، exe نتیجه را به AppInfo برمی‌گرداند. AppInfo از توابع کرنل می‌خواهد تا یک Elevated Access Token یعنی Full Adminstrator Token شامل تمام گروه‌های ادمین و Privilageهایی مثل SeDebugPrivilage و SeTakeOwnershipPrivilage برای پروسه هدف بسازد.
نکته: در این جریان معمولی، مرز اعتماد به درستی رعایت می‌شود، هیچ داده‌ای از سطح کاربر بدون بررسی به سطح SYSTEM منتقل نمی‌شود. این دقیقا همان دلیل اصلی است که در CVE-2026-24291 نقض شده است.
۱.۳.۱.۴ UIAccess Flag استثنای طراحی‌شده برای ابزارهای Accessibility
مایکروسافت در طراحی UAC با یک تناقض مواجه شد. جداسازی خصوصی رابط کاربری (User Interface Privilage Isolation (UIPI)) به عنوان مکانیزمی از مدل امنیتی ویندوز، از ارسال پیام و نصب Hook در پروسه‌هایی با یکپارچگی (Integrity) پایین‌تر به پروسه‌هایی با یکپارچگی بالاتر جلوگیری می‌کند. این محدودیت در حالت عادی همان چیزی است که باید باشد، زیرا یک برنامه معمولی نباید بتواند با یک پنجره ادمین (Admin) تعامل داشته باشد. اما ابزارهای Accessibilty دقیقا برای همین تعامل طراحی شده بودند. On-Screen Keyboard باید بتواند کلیدهای ورودی را به پنجره‌های یکپارچگی بالا (High Integrity) بفرستد و Narrator باید بتواند محتوای برنامه‌های Elevated را بخواند. نمی‌توان هربار که کاربر صفحه کلید مجازی را باز می‌کند یک UAC Prompt نمایش داد، این‌کار تجربه کاربری را به صورت کامل مختل می‌کند، به ویژه برای افرادی که دارای محدویت جسمانی هستند که این ابزارها برایشان طراحی شده‌است. راه‌حل مایکروسافت، معرفی فلگ uiAccess=”true” در مانیفست برنامه بود، یک استثنای کنترل‌شده که به برنامه‌های واجد شرایط اجازه می‌دهد محدودیت‌های UIPI را دور بزنند و با پنجره‌های سطوح بالاتر تعامل داشته باشند، بدون اینکه کاربر با UAC Prompt مواجه شود.
۱.۳.۲ فایل‌های مانیفست ویندوز چیست؟
فایل‌های مانیفست ویندوز (Windows Manifest Files) نوعی فایل متنی مبتنی بر XML هستند که برای توصیف ویژگی‌ها، نیازمندی‌ها و نحوه اجرای یک برنامه در سیستم‌عامل ویندوز به کار می‌روند. این فایل‌ها در واقع مجموعه‌ای از متادیتاها (Metadata) را در اختیار سیستم‌عامل قرار می‌دهند تا بتواند برنامه را به‌درستی شناسایی، بارگذاری و مدیریت کند. مفهوم کلی فایل مانیفست را می‌توان به این صورت بیان کرد که فایلی است که اطلاعاتی درباره ساختار، اجزا و وابستگی‌های یک نرم‌افزار ارائه را می‌دهد. در ویندوز، مانیفست نقش مهمی در تعیین هویت برنامه دارد.
از دیگر وظایف مهم فایل‌های مانیفست می‌توان به کنترل نحوه اجرای برنامه اشاره کرد. برای مثال، از طریق این فایل می‌توان تعیین کرد که یک برنامه نیاز به سطح دسترسی Administrator دارد یا خیر، آیا از نمایشگرهای با وضوح بالا (High DPI) پشتیبانی می‌کند و چه تنظیمات امنیتی باید در زمان اجرا اعمال شوند. همچنین، بخشی از اطلاعاتی که در گذشته در رجیستری ویندوز ذخیره می‌شد، امروزه در مانیفست قرار می‌گیرد که این موضوع باعث کاهش وابستگی به رجیستری و افزایش قابلیت قابل حمل بودن (Portability) برنامه‌ها می‌شود. به‌طور کلی، فایل‌های مانیفست ویندوز را می‌توان به عنوان یک لایه واسط میان برنامه و سیستم‌عامل در نظر گرفت که با ارائه اطلاعات دقیق درباره ساختار و نیازهای نرم‌افزار، به اجرای پایدارتر، ایمن‌تر و سازگارتر آن کمک می‌کند.
در معماری ویندوز، فایل‌های مانیفست در قالب‌های مختلفی مورد استفاده قرار می‌گیرند که هر یک نقش مشخصی در مدیریت اجرای برنامه‌ها دارند. از مهم‌ترین آن‌ها می‌توان به مانیفست اسمبلی (Assembly Manifest) اشاره کرد که برای توصیف کتابخانه‌ها و وابستگی‌های آن‌ها استفاده می‌شود و مانیفست برنامه (Application Manifest) که مشخص‌کننده نحوه اجرای یک برنامه و وابستگی‌های آن است. علاوه بر این، فایل‌های پیکربندی برنامه (Application Configuration) و پیکربندی ناشر (Publisher Configuration) نیز برای تغییر یا هدایت نسخه وابستگی‌ها به نسخه‌های سازگار دیگر به کار می‌روند. این دسته‌بندی‌ها در مجموع بخشی از مکانیزم Side-by-Side در ویندوز را تشکیل می‌دهند که هدف آن مدیریت دقیق نسخه‌ها و جلوگیری از تداخل میان کتابخانه‌ها است.
۱.۳.۲.۱ نقش اصلی مانیفست برنامه
مهم‌ترین وظیفه مانیفست برنامه، مدیریت وابستگی‌های برنامه به اسمبلی‌ها و کتابخانه‌های موردنیاز است. این فایل مشخص می‌کند که برنامه باید دقیقا از چه نسخه‌ای از DLLها یا کامپوننت‌ها استفاده کند. به همین دلیل نقش مهمی در مدیریت معماری Side-by-Side در ویندوز دارد. این ویژگی از آنجایی که به سیستم‌عامل اجازه می‌دهد چندین نسخه از یک کتابخانه را به‌صورت هم‌زمان مدیریت کرده و هر برنامه را به نسخه صحیح متصل کند مشکل DLL Hell را حل می‌کند. علاوه بر این، مانیفست برنامه وظایف مهم دیگری نیز بر عهده دارد، از جمله:
- تعیین نسخه و هویت برنامه
- مشخص‌کردن معماری پردازنده (x86، x64، ARM)
- تعریف سطح دسترسی برنامه در UAC
- تعیین سازگاری برنامه با نسخه‌های مختلف ویندوز
- فعال‌سازی قابلیت‌هایی مانند High DPI Awareness
- فعال‌سازی پشتیبانی از مسیرهای طولانی (Long Path)
- تنظیم Code Page و پشتیبانی UTF-8
- تعریف تنظیمات امنیتی و ایزوله‌سازی
۱.۳.۲.۲ ساختار کلی مانیفست برنامه
همانطور که گفته شد، فایل مانیفست دارای ساختار XML است و عنصر اصلی آن <assembly> می‌باشد. درون این عنصر، بخش‌های مختلفی قرار می‌گیرند که هرکدام وظیفه مشخصی دارند. مهم‌ترین عناصر مانیفست برنامه در ادامه آورده شده است.
۱.۳.۲.۲.۱ عضو assemblyIdentity
عنصر assemblyIdentity مهم‌ترین بخش مانیفست است و هویت برنامه را مشخص می‌کند. این بخش شامل اطلاعاتی مانند نام برنامه، نوع اسمبلی، نسخه، معماری پردازنده، زبان و Public Key Token می‌باشد. در زیر می‌توانید نمونه‌ای از آن را مشاهده کنید:
<assemblyIdentity
type="win32"
name="MyApplication"
version="1.0.0.0"
processorArchitecture="amd64" />
۱.۳.۲.۲.۲ عضو dependency
عنصر dependeny مشخص می‌کند برنامه برای اجرا به چه اسمبلی‌ها یا DLLهایی نیاز دارد. ویندوز با استفاده از این اطلاعات نسخه مناسب کتابخانه‌ها را بارگذاری می‌کند. در زیر می‌توانید نمونه‌ای از آن را مشاهده کنید، که باعث فعال شدن نسخه جدید Visual Styles در ویندوز می‌شود:
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="*"
publicKeyToken="6595b64144ccf1df"
language="*" />
</dependentAssembly>
</dependency>
۱.۳.۲.۲.۳ عضو compatibility
عنصر compatibility مشخص می‌کند برنامه با چه نسخه‌هایی از ویندوز سازگار است. این قسمت از GUIDهای مخصوص برای هر نسخه ویندوز استفاده می‌کند. در زیر می‌توانید نمونه‌ای از آن را مشاهده کنید، که مقدار GUID آن نشان‌دهنده این است که برنامه با ویندوز 10 سازگار است:
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
...
<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
<application>
<!-- Windows 10, version 1903 -->
<maxversiontested Id="10.0.18362.1"/>
<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" />
</application>
</compatibility>
...
</assembly>
