استخراج اطلاعات هویتی از حافظه دارای حفاظت LSA

سرقت اطلاعات هویتی

نویسنده: سالار بختیاری

در این مقاله قصد دارم نحوه کار حفاظت LSA یا «Protected Process Light»، و نحوه دورزدن آن برای دامپ‌کردن اطلاعات هویتی کش‌شده در حافظه را توضیح دهم. قبل از این که وارد مبحث دامپ‌کردن اطلاعات هویتی کش‌شده یا بحث درباره حفاظت LSA شویم، لازم است با دسترسی‌های اختصاص‌یافته (assigned rights) و سطوح یکپارچگی پروسس (process integrity levels) آشنا شویم که بخشی از توکن‌های دسترسی در سیستم‌عامل ویندوز هستند.

سطح یکپارچگی پروسس

در ویندوز ویستا و نسخه‌های بعدی ویندوز، پروسس‌ها در سه سطح مختلف از یکپارچگی اجرا می‌‌‌شوند: سیستم (System)، بالا (high)، متوسط (medium) و پایین (low). یکپارچگی پایین برای پروسس‌های سندباکس‌شده مانند مرورگرهای وب استفاده می‌شود. اپلیکیشن‌هایی که در فضای کاری یک کاربر معمولی شروع به کار کنند با یکپارچگی متوسط اجرا می‌شوند، و ادمین‌ها می‌توانند اپلیکیشن‌ها را با یکپارچگی بالا اجرا کنند. یکپارچگی سطح سیستم معمولا فقط برای سرویس‌های SYSTEM استفاده می‌شود. اگر می‌خواهید سطح یکپارچگی یک پروسس خاص را ببینید، می‌توانید از پروسس اکسپلورر (procexp.exe) استفاده کنید که بخشی از ابزار Sysinternals است. به صورت پیش‌فرض، امکان مشاهده سطح یکپارچگی پروسس‌های در حال اجرا وجود ندارد و برای این کار ابتدا باید به تب «View» رفته و سپس «select columns» را انتخاب کرده و سپس تیک «Integrity Level» را بزنید.

نمایش process integrity level
مثالی از integrity level

دسترسی‌های اختصاص‌یافته

دسترسی‌های اختصاص‌یافته (یا privileges) هم در توکن دسترسی گنجانده شده‌اند و مجموعه‌ای از مجوزهای دسترسی ازپیش‌تعریف‌شده در سیستم‌عامل‌ هستند که تعیین می‌کنند یک پروسس اجازه‌ی انجام چه اقداماتی را دارد. با تایپ دستور whoami/priv در پاورشل یا ترمینال می‌توان دسترسی‌های کاربر فعلی را مشاهده کرد.

نمایش دسترسی های کاربر

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

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

  • استفاده از تابع LsaAddAccountRights متعلق به Advapi32 API
  • استفاده از secpol.msc

من در این مقاله از پنجره گرافیکی secpol.msc استفاده خواهم کرد که از روش دیگر ساده‌تر است. پس از تایپ secpol.msc در ترمینال، پاورشل یا پنجره Run، یک پنجره جدید باز می‌شود. در این پنجره باید به بخش Security Settings و سپس به بخش User Rights Assignment برویم.

تغییر دسترسی های کاربر

دامپ‌کردن اطلاعات هویتی از پروسس LSASS

پروسس LSASS یک پروسس سیستمی است و به همین خاطر برای دسترسی به هش‌های ذخیره‌شده روی ماشین هدف، به مجوزهای ادمین لوکال (دسترسی شل با یکپارچگی بالا یا سیستم) نیاز داریم. از طرف دیگر، اگر کاربر فعلی دسترسی SubDebugPrivilege را داشته باشد، می‌توانیم پروسسی را بخوانیم یا تغییر دهیم که تحت مالکیت یک کاربر دیگر است (یعنی پروسسی که owner آن کاربر دیگری باشد). حالا با دانستن این موضوع، از mimikatz استفاده کرده و سعی می‌کنیم اطلاعات هویتی کش‌شده را به صورت زیر دامپ کنیم:

privilege::debug
sekurlsa::logonpasswords

دامپ کردن اطلاعات هویتی کش‌شده

در شرایط معمولی با اجرای این دستورات هش NTLM و حتی گاهی اوقات متن خام پسوردهای کاربرانی را دریافت می‌کردیم که روی سیستم فعلی لاگ‌این کرده بودند؛ ولی به خاطر حفاظت LSA که با نام Protected Process Light (PPL) هم شناخته می‌شود، متوقف شدیم.

چرا موفق نشدیم؟ 

در گذشته، دامپ‌کردن پسورد طرفداران زیادی پیدا کرده بود و پروژه mimikatz نیز به همین علت شهرت زیادی یافته بود. به همین خاطر مایکروسافت تصمیم گرفت با انتشار حفاظت LSA و Credential Guard (که بخشی از ویندوز دیفندر است) این مشکل را برطرف کند. ما در بخش‌های بعدی این مقاله از این مانع عبور خواهیم کرد، ولی پیش از آن باید بدانیم حفاظت LSA چیست و چگونه کار می‌کند. حفاظت LSA به طور پیشفرض فعال نیست و دستورات بالا کار می‌کنند، اما من حفاظت LSA را از عمد روشن کردم تا با ارور بالا مواجه شده و پس از آن با حفاظت LSA آشنا شویم و نحوه‌ی دورزدن آن را بیاموزیم.

Protected Process Light 

مایکروسافت به همراه ویندوز 8.1 قابلیتی به نام Protected Process Light یا به اختصار PPL را معرفی کرد که می‌تواند یک لایه اضافی بالای سطوح یکپارچگی فعلی ایجاد کند؛ یعنی یک پروسس با سطح یکپارچگی سیستم، نمی‌تواند به فضای حافظه یک پروسس با سطح یکپارچگی سیستم و با PPL فعال دسترسی داشته یا آن را دستکاری کند. LSASS از PPL هم پشتیبانی می‌کند.

چگونه حفاظت LSA را فعال کنیم؟

ابتدا باید در برنامه رجیستری، و در آدرس زیر یک کلید DWORD جدید تعریف کنیم:

“HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa”

نام کلید RunAsPPL و مقدار آن باید برابر 1 باشد. در گام آخر باید کامپیوتر را ری‌استارت کنیم تا اجرای تغییرات کامل شود.

فعال‌کردن حفاظت LSA

دور زدن حفاظت LSA 

سه راه برای دور زدن حفاظت LSA و دامپ‌کردن اطلاعات هویتی کش‌شده وجود دارد:

  1. حذف کلید رجیستری RunAsPPL و ری‌استارت‌کردن مجدد سیستم. البته این روش عملی نیست، چون به محض این که سیستم را ری‌استارت کنیم، تمام اطلاعات هویتی را که روی حافظه کش شده بودند از دست می‌دهیم.
  2. غیرفعال‌کردن فلگ‌های PPL در پروسس LSASS با پچ‌کردن ساختار EPROCESS در کرنل. فعال یا فعال‌نبودن حفاظت PPL توسط یک بیت کنترل می‌شود که در آبجکت کرنل EPROCESS مربوط به پروسس هدف قرار دارد. اگر بتوانیم دسترسی اجرای کد را در فضای کرنل به دست آوریم، می‌توانیم حفاظت LSA را غیرفعال کرده و اطلاعات هویتی را دامپ کنیم.
  3. خواندن مستقیم محتوای پروسس LSASS در حافظه به جای استفاده از پروسس‌فانکشن‌های باز

ما روش دوم را استفاده می‌کنیم. خوشبختانه چندین ابزار وجود دارند که به صورت تخصصی برای پچ‌کردن ساختار EPROCESS در کرنل و غیرفعال‌کردن فلگ‌های PPL روی پروسس LSASS نوشته شده‌اند.

پروژه اول: mimidrv.sys از mimikatz 

خوشبختانه توسعه‌دهنده mimikatz یک درایور کرنل به نام mimidrv.sys برای آن منتشر کرده است که همان‌طور که قبلا گفتم، به ما اجازه می‌دهد حفاظت LSA را دور بزنیم. برای استفاده از این درایور لازم است دسترسی SeLoadDriverPrivilege را داشته باشیم و بتوانیم هر درایوری را با هر امضای دیجیتالی لود کنیم، و از آن‌جایی که ما از قبل یک دسترسی ادمین یا سیستم برای دامپ‌کردن اطلاعات هویتی داریم، پس این دسترسی را نیز داریم. باید با تایپ‌کردن +! در محیط mimikatz فایل mimidrv.sys را لود کنیم. پس از آن حفاظت را از روی پروسس lsass.exe برمی‌داریم. پس از این که فلگ حفاظت را از lsass.exe برداشتیم، سعی می‌کنیم اطلاعات هویتی را دامپ کنیم:

!+
!processprotect /process:lsass.exe /remove
sekurlsa::logonpasswords

دامپ موفق اطلاعات هویتی ویندوز

این بار موفق شدیم و توانستیم اطلاعات هویتی را دامپ کنیم. البته استفاده از mimidrv.sys یک عیب دارد و آن هم این است که لازم است دیسک را دستکاری کنیم (برای کپی‌کردن mimidrv.sys به سیستم هدف) که به سرعت توسط راهکارهای آنتی‌ویروس شناسایی می‌شود.

پروژه دوم: PPLKiller 

از آن‌جایی که روش اول به سرعت توسط آنتی‌‎ویروس شناسایی می‌شود، می‌توانیم از یک درایور رسمی ولی آسیب‌پذیر برای اجرای کد از راه دور استفاده کنیم تا در نهایت بتوانیم دستورات خود را در فضای کرنل اجرا کنیم. PPLKiller یک مثال از این روش است.

جمع‌بندی 

به طور خلاصه، PPL در فضای کاربر (userland) کار می‌کند و دلیل کارکردن تمام تکنیک‌های ذکرشده در این مقاله، این است که ما سعی می‌کنیم کد خود را در فضای کرنل اجرا کنیم. هرگاه بتوانیم کد دلخواه خود را در فضای کرنل اجرا کنیم، می‌توانیم تمام پروسس‌هایی را که به همراه PPL در حال اجرا هستند، به طور کامل غیرفعال کنیم.

از این که تا انتهای این مقاله با من همراه بودید متشکرم. 

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *