۱. مقدمه
در دسامبر 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>
۱.۳.۲.۲.۴ عضو trustInfo
عنصر trustInfo تعیین می‌کند برنامه با چه سطح دسترسی اجرا شود. سه سطح اصلی عبارت‌اند از:
جدول ۳: انواع سطوح دسترسی
توضیح | مقدار |
برنامه با همان سطح دسترسی پروسه فراخواننده اجرا می‌شود، هیچ Elevation انجام نمی‌شود. | asInvoker |
برنامه با بالاترین سطح دسترسی که کاربر جاری می‌تواند داشته باشد اجرا می‌شود، برای حساب‌های Admin بدون Prompt، برای کاربران عادی بدون تغییر. | highestAvailable |
برنامه حتماً به دسترسی Administrator نیاز دارد، UAC Prompt نمایش داده می‌شود و در صورت رد کردن توسط کاربر، برنامه اجرا نمی‌شود. | requireAdministrator |
در زیر می‌توانید نمونه‌ای از آن را مشاهده کنید:
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3">
<requestedExecutionLevel level="asInvoker" uiAccess="false" />
</requestedPrivileges>
</security>
</trustInfo>
۱.۳.۲.۲.۵ محل ذخیره‌سازی مانیفست برنامه
مایکروسافت توصیه می‌کند فایل مانیفست به‌صورت مستقیم داخل فایل اجرایی .exe یا DLL قرار بگیرد. همچنین می‌توان آن را به‌صورت جداگانه در کنار فایل اجرایی قرار داد. در این حالت نام فایل به صورت زیر است:
example.exe.manifest
۱.۳.۲.۲.۵.۱ تنظیمات فایل مانیفست در Visual Studio
به منظور پیکربندی تنظیمات مربوط به فایل مانیفست، به مسیر Configuration Properties و سپس سربرگ Linker و Manifest File بروید. در این بخش گزینه‌های زیر قابل تنظیم هستند:
۱.۴ مرزهای اعتماد (Trust Boundaries)
هنگامی که دو یا چند جزء یک سیستم باهم تعامل می‌کنند، رابطهای بین آن‌ها شکل می‌گیرد. اما این رابطه همیشه خنثی نیست، هر تعامل به‌صورت طبیعی سطحی از اعتماد را به همراه دارد. در یک سیستم نرم‌افزاری، اجزای مختلف لزوما در یک سطح اعتماد نسبت به یکدیگر قرار ندارند. هر مولفه ممکن است میزان متفاوتی از اعتماد را برای مولفه‌های دیگر قائل شود و همین موضوع است که در تحلیل امنیتی اهمیت اساسی دارد.
روابط اعتماد همیشه همراه با جریان داده مطرح می‌شوند، زیرا این سطح اعتماد است که تعیین می‌کند داده‌های ردوبدل شده تا چه اندازه باید اعتبارسنجی شوند. در بسیاری از طراحی‌ها، توسعه‌دهندگان یک رابط یا مولفه دیگر را مورد اعتماد در نظر می‌گیرند، به این معنا که فرض می‌کنند داده‌هایی که از آن مولفه دریافت می‌شود سالم است و رفتار مولفه قابل پیش‌بینی و کنترل‌شده است و مهاجمان نمی‌توانند آن مولفه را مستقیما دستکاری کنند. اما اگر این اعتماد نابجا باشد و مهاجم بتواند به مولفه مورد اعتماد دسترسی پیدا کند، تمام فرضیات امنیتی سیستم از بین می‌رود.
۱.۴.۱ مرز اعتماد
مرز اعتماد مرزی است که مشخص می‌کند تا کجا می‌توان به یک مولفه اعتماد کرد و چه زمانی باید محدودیت اعمال شود. این مرزها نواحی مختلف با سطوح اعتماد متفاوت را از هم جدا می‌کنند. در امنیت نرم‌افزار، مهم‌ترین بخش ماجرا جایی است که اعتماد باید محدود باشد، یعنی هر مولفه فقط اجازه می‌دهند بخش کوچکی از توانمندی‌ها یا داده‌های آن‌ها توسط دیگری دیده یا استفاده شود. هرجا که این محدودیت به درستی اعمال نشود، یک نقص امنیتی شکل می‌گیرد.
۱.۴.۲ حوزه اعتماد
به هر منطقه‌ای از سیستم که در آن سطح اعتماد یکسانی برقرار است، حوزه اعتماد یا Trust Domain گفته می‌شود. برای مثال:
- کد داخلی یک برنامه: یک حوزه اعتماد
- داده‌های بیرونی، ورودی کاربر: حوزه‌ای دیگر با سطح اعتماد پایین‌تر
چون سطح اعتماد بین این دو متفاوت است، بین آن‌ها یک مرز اعتماد وجود دارد. هربار که داده از یک حوزه به حوزه دیگر منتقل می‌شود، باید اعتبارسنجی انجام شود، به ویژه وقتی که داده از سطح اعتماد پایین‌تر به سطح بالاتر می‌رود. مجموعه تصمیم‌های مربوط به تعریف حوزه‌های اعتماد و روابط بین آن‌ها به نام مدل اعتماد شناخته می‌شود که یکی از ارکان اصلی سیاست امنیتی سیستم است. در عمل، مرزهای اعتماد معمولا همان مرزهای ماژول هستند، یعنی هرجا اعتماد تغییر کند، معمولا یک ماژول مستقل نیز شکل می‌گیرد.
۱.۴.۳ سطوح دسترسی
اعتماد همیشه صفر و صد نیست. در بسیاری از سیستم‌ها اعتماد مطلق وجود ندارد، بلکه درجه‌بندی می‌شود. به این درجه‌بندی‌ها سطوح دسترسی گفته می‌شود. ویندوز این مفهوم را از طریق کنترل یکپارچگی اجباری (MIC- Mandatory Integrity Control) پیاده‌سازی کرده است. هر پروسه و هر آبجکت (Object) یک سطح یکپارچگی (Integrity Level) دارد:
جدول ۴: سطوح مختلف Integrity Level
معنا | مقدار عددی | سطح |
پروسه‌های کاملا محدود | 0x0000 | Untrusted |
حالت محافظت‌شده اینترنت اکسپلورر | 0x1000 | Low |
برنامه‌های معمول کاربر | 0x2000 | Medium |
پروسه‌های Elevated (با UAC تایید شده) | 0x3000 | High |
سرویس‌های سیستم‌عامل | 0x4000 | System |
قانون اصلی MIC این است که یک پروسه نمی‌تواند به آبجکت با سطح یکپارچگی بالاتر از خود بنویسد، مگر اینکه یک استثنا به صورت مشخص تعریف شده باشد.
۱.۴.۴ مرجع مورد اعتماد
در هر سیستم، همیشه یک مرجع کاملا مورد اعتماد وجود دارد که خارج از تمام مرزهای اعتماد دیگر قرار دارد، این موضوع انتخاب نیست و یک الزام در معماری است. این مرجع مورد اعتماد در سیستم‌های یونیکس حساب Root و در ویندوز حساب SYSTEM است. این مرجع باید سیستم را مدیریت کند، مشکلات را رفع کند و کنترل کاملی بر روی سیستم داشته باشد.
۱.۴.۵ زنجیره اعتماد
در یک سیستم واقعی، مولفه‌ها به‌صورت مستقیم با همه اجزا ارتباط ندارند. بسیاری از اعتمادها از طریق واسطه‌ها منتقل می‌شوند. به این صورت که مولفه A به مولفه B اعتماد دارد، مولفه B نیز به مولفه C اعتماد دارد. در نتیجه مولفه A به صورت غیرمستقیم به مولفه C نیز اعتماد کرده است. این خاصیت هم مفید است و هم خطرناک، زیرا اگر یک حلقه از زنجیره دچار نقص شود، کل زنجیره شکسته می‌شود.
۱.۴.۶ فرضیات نادرست
یکی از روش‌های کارآمد برای تحلیل نقض‌های امنیتی، بررسی فرضیات نادرستی است که توسعه‌دهندگان در زمان طراحی داشته‌اند. بسیاری از آسیب‌پذیری‌ها از جایی ناشی می‌شوند که توسعه‌دهنده تصور می‌کند شرایط همیشه به شکل مشخصی پیش خواهد رفت، درحالی که مهاجمان دقیقا به‌دنبال شکستن همین فرضیات هستند. این فرضیات نادرست ممکن است درباره موارد زیر باشند:
- اعتبار و قالب داده‌های ورودی
- امنیت و رفتار مولفه‌های وابسته
- محیط اجرا
- توانایی و خلاقیت مهاجم
۱.۵ توکن دسترسی چیست؟
هر کاربری که وارد سیستم می‌شود، یک توکن دسترسی (Access Token) دارد که اطلاعات امنیتی مربوط به آن نشست یا سشن (Session) ورود را در خود نگه می‌دارد. سیستم این توکن دسترسی را هنگام ورود کاربر می‌سازد. هر پروسه‌ای که از طرف کاربر اجرا می‌شود، یک کپی از این توکن دسترسی را دارد. توکن هویت کاربر، گروه‌های کاربر و سطوح دسترسی کاربر را مشخص می‌کند. یک توکن همچنین شامل یک logon SID (شناسه امنیتی) است که سشن ورود فعلی را شناسایی می‌کند.
با استفاده از دستور whoami /all می‌توانید این اطلاعات را مشاهده کنید:
همچنین می‌توانید با استفاده از برنامه Process Explorer نیز پروسه مورد نظر را انتخاب کرده و به سربرگ Security بروید تا این اطلاعات را مشاهده کنید:
- عضو User SID :User SID شناسه امنیتی (Security Identifier) منحصر به فرد هر کاربر است. هر حساب کاربری در ویندوز یک SID دارد که تغییر نمی‌کند، حتی اگر نام حساب عوض شود. سیستم‌عامل هنگام بررسی دسترسی به یک فایل یا کلید ریجستری این SUD را با ACL مقایسه می‌کند.
- عضو Group SID :Group SID نمایانگر فهرست گروه‌هایی است که کاربر عضو آن‌ها است، به عنوان مثال:
- BUILTIN\Users
- BUILTIN\Administrators
- NT AUTHORITY\Authenticated Users
هر گروه یک Attribute دارد که مشخص می‌کند آیا این عضویت در حال حاضر فعال است یا غیر فعال، همچنین این Attrubute در Token Splitting ویندوز نقش مهمی دارد.
- عضو Privileges :Privileges فهرست توانایی‌های ویژه‌ای است که به یک Token اعطا شده است. برخی از Privilegesهای مهم عبارت اند از:
توضیح | Privilege | سطح |
دسترسی مستقیم به حافظه هر پروسه از جمله lsass | SeDebugPrivilege | Administrator |
گرفتن مالکیت هر Object | SeTakeOwnershipPrivilege | Administrator |
برنامه‌های معمول کاربر | SeImpersonatePrivilege | سرویس‌ها |
پروسه‌های Elevated (با UAC تایید شده) | SeAssignPrimaryTokenPrivilege | SYSTEM |
سرویس‌های سیستم‌عامل | SeTcbPrivilege | SYSTEM |
- عضو Integrity Level: سطح یکپارچگی توکن که قبلا در بخش سطوح دسترسی توضیح داده شده‌است. این مقدار مستقیما تعیین می‌کند که یک پروسه می‌تواند با چه پروسه‌ها و Objectهایی تعامل داشته باشد.
- عضو Session ID: نمایانگر شماره سشن کاربری که توکن به آن تعلق دارد.
۱.۵.۱ انواع Tokenها
به‌طور کلی دو نوع Token وجود دارد:
- Primary Token: که توکنی است که هنگام ایجاد یک پروسه توسط سیستم‌عامل به آن اختصاص داده می‌شود. این توکن هویت و سطح دسترسی اصلی پروسه را تعریف می‌کند. هر پروسه دقیقا یک Primary Token دارد و تمام تردهای (Thread) آن پروسه به صورت پیش‌فرض با همین توکن اجرا می‌شوند. Primary Token از پروسه والد به ارث می‌رسد.
- Impersonation Token: که یک توکن موقت است که به یک ترد اجازه می‌دهد برای مدت کوتاهی با هویت دیگری فعالیت کند، بدون اینکه Primary Token پروسه تغییر کند. این توکن هنگامی استفاده می‌شود که یک سرویس باید درخواست‌های کاربران مختلف را با هویت هر کدام از آن‌ها پردازش کند.
به عنوان مثال، IIS Web Server از Impersonation Token استفاده می‌کند تا هر درخواست HTTP را با توکن کاربری که آن درخواست را ارسال کرده پردازش کند، بدون اینکه کل پروسه IIS با آن هویت اجرا شود.
۱.۵.۲ تقسیم توکن (Token Splitting) در UAC
هنگامی که یک Local Administrator وارد سیستم می‌شود، فرآیند ورود مراحلی را به ترتیب طی می‌کند که شامل ایجاد توکن دسترسی (Access Token) هنگام ورود کاربر به کامپیوتر، احرازهویت هنگام ورود کاربر به سیستم با بررسی صحت رمز عبور و همچنین بررسی جزئیات کاربر در پایگاه‌داده SAM می‌شود. در این بررسی مشخص می‌شود که آیا کاربر عضو گروه Administrator است یا خیر:
- اگر عضو نباشد: فقط یک Standard Token ساخته می‌شود
- اگر عضو باشد: سیستم دو Token مجزا می‌سازد:
- توکن دسترسی کامل مدیر (Full Administrator Access Token)
- توکن دسترسی کاربر استاندارد (Standard User Access Token)
ویندوز توکن دسترسی کامل مدیر را مستقیما در اختیار کاربر قرار نمی‌دهد. در عوض دو نوع توکن تقسیم شده (Split Token) ایجاد می‌کند:
- توکن Filtered Token
- توکن Elevated Token
هنگامی که یک Filtered Token به کاربر اختصاص داده می‌شود، فرایند مربوطه با سطح Medium Integrity اجرا می‌شود. در این حالت، کاربر ممکن است عضو گروه مدیران باشد، اما دسترسی‌های مدیریتی او به‌صورت کامل فعال نیستند و SIDهای مرتبط با گروه Administrator در حالت محدودشده قرار می‌گیرند و کاربر نمی‌تواند مستقیما هیچ کار مدیریتی را انجام دهد. برای انجام کارهایی که نیازمند دسترسی بالاتر هستند، کاربر باید UAC را تایید یا پسورد کاربر Admin را وارد کند.
پس از آنکه کاربر تایید یا پسورد را ارائه کرد، توکن Elevated به او اختصاص داده می‌شود و می‌تواند کارهای مدیریتی را انجام دهد. توکن Elevated توکنی با سطح High Integrity است که شامل SIDها و Privileges کامل گروه Administrators می‌باشد.
