روابط عمومی شرکت ایدکو (توزیع‌کننده‌ی محصولات کسپرسکی در ایران)؛ حدود ۲۴ سال از کشف آسیب‌پذیری null session گذشته است. در آن زمان، امکان دسترسی بهلوله‌ها‌ی نامگذاریشده[1][2]SMB با استفاده از اطلاعات کاربری خالی (بدون نیاز به نام کاربری و رمز عبور) وجود داشت و مهاجمان از این طریق اطلاعات دامنه را جمع‌آوری می‌کردند. یکی از روش‌های رایج، استفاده از تکنیک‌های RID (شناسه نسبی) بود. RIDs به طور منحصر به فردی کاربران، گروه‌ها، کامپیوترها و دیگر موجودیت‌های دامنه را مشخص می‌کنند. برای انجام این شمارش، مهاجم از رابط‌های MS-RPC استفاده می‌کرد تا با فراخوانی برخی توابع از میزبان هدف، اطلاعات مورد نظر را به دست آورد.
برای جلوگیری از این نوع حملات، مایکروسافت سطح دسترسی null session را محدود کرد و سیاست‌های امنیتی‌ای ارائه داد که امکان اجرای چنین فعالیت‌هایی را به طور کامل مسدود می‌کردند. امروزه، اگرچه null sessionها هنوز هم در کنترلرهای دامنه به‌صورت پیش‌فرض فعال هستند (احتمالاً به دلیل حفظ سازگاری با نسخه‌های قدیمی‌تر)، اغلب مدیران سیستم با تقویت تنظیمات امنیتی و پایش فعالیت‌های کنترلر دامنه، ازجمله دسترسی‌های ناشناس از طریق SMB، این قابلیت را غیرفعال می‌کنند. اما به عنوان کارشناسان تست نفوذ، همیشه این سؤال را مطرح می‌کنیم: آیا واقعاً به همان اندازه که تصور می‌شود، ایمن است؟ در این تحقیق بررسی شده که آیا امروز، پس از گذشت ۲۴ سال، همچنان می‌توان این سیاست‌ها و محدودیت‌ها را دور زد و دوباره دسترسی ناشناس را زنده کرد؟ این تحقیق ویژه‌ی پژوهشگران امنیت و تسترهای نفوذ است که به دنبال درک عمیق‌تر از رابط‌های MS-RPC و بهبود تکنیک‌های تحقیقاتی خود هستند. لازم به ذکر است که تمامی اطلاعات این مقاله صرفاً برای اهداف تحقیقاتی قانونی ارائه شده و استفاده غیرقانونی از آن ممنوع است.
تحقیق در دو بخش انجام شده است. در این بخش نخست، روش تحقیق بر روی رابط‌های MS-RPC توضیح داده شده که پس از مشاهده‌ی رفتار جالب یکی از این رابط‌ها تدوین شده است. همچنین بررسی شده که چطور می‌توان این رفتار را به null session مرتبط کرد و اطلاعاتی مانند کاربران دامنه را بدون احراز هویت و بدون شناسایی توسط سیستم‌های امنیتی، از کنترلر دامنه استخراج کرد.
درباره null session
null session به یکی از مباحث مهم و بحث‌برانگیز در حوزه امنیت سایبری تبدیل شده است. این نوع دسترسی زمانی رخ می‌دهد که به یک منبع شبکهمعمولاً به اشتراک‌گذاری مخفی IPC$ با اطلاعات کاربری خالی دسترسی داده شود. IPC$ نوعی اشتراک است که برای ارتباط بین پردازش‌ها در کامپیوترهای مختلف استفاده می‌شود. پس از به‌دست‌آوردن این دسترسی ناشناس، مهاجم می‌تواند به یکی از رابط‌های MS-RPC که از طریق named pipe در داخل IPC$ ارائه می‌شوند متصل شده و اطلاعاتی مانند لیست اشتراک‌ها، کاربران، گروه‌ها، کلیدهای رجیستری و... را استخراج کند.
در نسخه‌های جدیدتر ویندوز، امکان null session محدود شده و فقط در ویندوز سرورهایی که نقش کنترلر دامنه دارند، فعال است. زمانی که سروری به عنوان کنترلر دامنه پیکربندی می‌شود، به‌صورت پیش‌فرض دسترسی null session به named pipeهای زیر فعال است:
- \pipe\netlogon
- \pipe\samr
- \pipe\lsarpc
برای جلوگیری از این دسترسی‌ها، دو سیاست امنیتی معرفی شده‌اند:
- "Restrict anonymous access to Named Pipes and Shares" (محدود کردن دسترسی ناشناس به named pipeها و اشتراک‌ها) – این گزینه به‌صورت پیش‌فرض فعال است.
- "Network access: Named Pipes that can be accessed anonymously" (دسترسی شبکه‌ای به لوله‌های نامگذاریشده که می‌توان به‌صورت ناشناس به آنها دست یافت) – این گزینه در صورتی که خالی باشد، حتی دسترسی به لوله‌های netlogon، samr و lsarpc نیز قطع می‌شود.
شمارش رابط‌های شبکه بدون احراز هویت
در زمان بررسی ترافیک شبکه، متوجه تعداد زیادی بسته مربوط به ارتباطات DCOM بین کنترلر دامنه و سایر نقاط شدم که در Wireshark با برچسب IOXIDResolver RPC و تابع ServerAlive2 مشخص شده بودند. در واقع، رابط IOXIDResolver همان IObjectExporter است. طبق مستندات مایکروسافت، این رابط برای حل OXIDها، تست زنده‌بودن سرورها و گرفتن آدرس‌های شبکه اشیاء در معماری DCOM استفاده می‌شود.
یکی از متدهای مهم این رابط، تابع ServerAlive2 با OPNUM 5 است. این تابع در نسخه 5.6 از پروتکل DCOM معرفی شده و در پاسخ خود اطلاعاتی مانند بایندینگ‌های امنیتی و رشته‌ای را برمی‌گرداند که به کلاینت کمک می‌کند بهترین تنظیمات ارتباطی را انتخاب کند. این رابط از TCP پورت 135 برای ارتباط استفاده می‌کند.
در هر stream TCP مربوط به این ارتباطات، چهار بسته مشاهده شد:
- درخواست bind به رابط IObjectExporter
- پاسخ bind از سرور
- فراخوانی تابع ServerAlive2
- پاسخ شامل اطلاعات رابط‌های شبکه‌ی کنترلر دامنه
در بسته‌ی درخواست bind می‌توان دید که فیلد Auth Length برابر با صفر است، به این معنا که سطح احراز هویت Noneاست و نیازی به احراز هویت وجود ندارد. فقط با دو بسته از سمت کلاینت، می‌توان اطلاعات رابط‌های شبکه را از میزبان مقصد استخراج کرد.
اما این نکته: آیا رابط‌های MS-RPC دیگری هم وجود دارند که بدون احراز هویت قابل استفاده باشند؟ چه اطلاعاتی می‌توان از آنها استخراج کرد؟ آیا می‌توان این مسیر را به null session کلاسیک نسبت داد؟ و چه راهبردی برای کشف چنین مواردی باید در پیش گرفت؟
بخش اول: مرور قسمت اول تحقیق
در بخش اول تحقیق، نشان دادیم چگونه توانستیم مفهوم دسترسی بدون احراز هویت (Null Session)را پس از سال‌ها دوباره احیا کنیم. این کار شامل استخراج اطلاعات دامنه (مانند لیست کاربران) بدون نیاز به احراز هویت می‌شد. در آن بخش، کل فرآیند مرحله به مرحله توضیح داده شد؛ از تفاوت میان دسترسی بدون احراز هویت در رابط‌های MS-RPCبا Null Session معروف گرفته تا روش‌شناسی دقیق رسیدن به هدف.
بخش دوم: چرا این اتفاق هنوز ممکن است؟
همانطور که قول داده شده بود، در این بخش دوم به بررسی عمیق‌تر مسئله می‌پردازیم. در اینجا بررسی خواهیم کرد که چرا سیستم‌عامل ویندوز اجازه می‌دهد اطلاعات دامنه بدون احراز هویت قابل استخراج باشد، و همچنین اینکه چرا جلوگیری یا شناسایی این فعالیت‌ها دشوار است.
بررسی اولیه: چرا توقف این فعالیت‌ها سخت است؟
در ابتدا، بررسی می‌کنیم که چرا جلوگیری از این نوع دسترسی مشکل است. برای این منظور، نحوه عملکرد WMI [3] را بررسی خواهیم کرد. همچنین روش‌هایی برای شناسایی و مقابله با این موضوع مورد بحث قرار می‌گیرند.
امنیت در MS-RPC و روش‌های دفاعی
در ادامه، اصول پایه‌ای امنیت در MS-RPC را توضیح می‌دهیم و بررسی می‌کنیم چگونه می‌توان یک RPC Server ایمن ایجاد کرد. سپس رابط معروف MS-NRPC را از دو دیدگاه تحلیل می‌کنیم:
- تحلیل تئوریک
- مهندسی معکوس
هدف از این تحلیل‌ها، رسیدن به درک عمیق‌تری از این رابط و نقاط ضعف آن است.
سیاست گروهی‌ای که "دامنه شما را به زانو در می‌آورد"
وقتی صحبت از متوقف کردن برخی رفتارهای ناخواسته در ویندوز می‌شود، Group Policyها معمولاً اولین ابزار دفاعی محسوب می‌شوند. در مورد ما نیز این موضوع صدق می‌کند. همانطور که در بخش اول اشاره شد، سیاستی به نام Restrict Unauthenticated RPC Clients برای محدود کردن فعالیت‌های بدون احراز هویت در رابط‌ها قابل استفاده است.
این سیاست شامل سه حالت می‌شود:
- None -بدون محدودیت
- Authenticated - فقط کاربران احراز هویت شده
- Authenticated without exceptions - احراز هویت اجباری بدون استثنا
مشکل بزرگ: چرا تنظیم شدید باعث خرابی می‌شود؟
در تست‌های ما، حتی زمانی که این سیاست روی حالت Authenticated تنظیم شده بود، همچنان امکان استخراج اطلاعات دامنه از طریق رابط MS-NRPC و همچنین رابط IObjectExporter (برای استخراج اطلاعات شبکه) وجود داشت.
گام منطقی بعدی استفاده از گزینه Authenticated without exceptions بود تا به‌طور کامل این نوع فعالیت‌ها را مسدود کنیم. در ابتدا، به نظر می‌رسید این تنظیم همه‌چیز را درست کرده است و دسترسی‌های بدون احراز هویت به‌طور کامل مسدود شده‌اند. اما پس از مدتی، با مشکلات جدی مواجه شدیم: بسیاری از قابلیت‌های کلیدی Domain Controllerبه‌درستی کار نمی‌کردند. این مسئله تعجب‌برانگیز نیست، چون خود مایکروسافت هشدار داده که این تنظیم می‌تواند به‌طور جدی عملکرد کنترلر دامنه را مختل کند. حتی در برخی منابع از این تنظیم به عنوان:
"Group policy که دامنه شما را نابود می‌کند"
یاد شده است، زیرا ممکن است باعث از کار افتادن کامل کنترلر دامنه شود.
بررسی بیشتر با WMI
برای درک بهتر این مشکل، مثال WMI به‌عنوان یک شیء DCOMرا بررسی می‌کنیم.
WMIزیرساختی برای مدیریت اطلاعات و عملیات در سیستم‌عامل‌های ویندوز است و در بسیاری از وظایف مدیریتی روزانه مورد استفاده قرار می‌گیرد، به‌ویژه برای مدیریت از راه دور سیستم‌ها.
آزمایش عملی
برای آزمایش تأثیر این تنظیم، فرض کنید سیاست Restrict Unauthenticated RPC Clientsرا روی حالت Authenticated without exceptions قرار داده‌ایم. حال می‌خواهیم از طریق ابزار wmicروی یک دستگاه دیگر (با استفاده از نام کاربری و رمز عبور ادمین) فرآیندهای در حال اجرا را لیست کنیم. با وجود اینکه اعتبارنامه ادمین معتبر است، به دلیل سیاست فوق، ممکن است دسترسی به WMI از راه دور قطع شود، که نشان می‌دهد این سیاست نه‌تنها دسترسی‌های مشکوک را مسدود می‌کند، بلکه عملیات قانونی و ضروری را هم مختل می‌کند.
شکست در فهرست کردن پردازش‌های راه‌دور
زمانی که تلاش می‌کنیم با استفاده از ابزار WMICپردازش‌های سیستم مقصد را لیست کنیم، با خطای Access Denied (دسترسی رد شد)مواجه می‌شویم، حتی اگر از اعتبارنامه‌های معتبر مدیر سیستم استفاده کنیم. اما چرا چنین اتفاقی می‌افتد؟
ارتباط WMI و معماری DCOM
WMIبرای عملکرد خود در محیط‌های راه‌دور به معماری DCOMمتکی است. برای تعامل با سرور WMI در یک دستگاه دیگر، ابتدا باید یک شیء DCOMروی سیستم مقصد ایجاد شود.
همانطور که در بخش اول توضیح داده شد، رابط‌هایی مانند IObjectExporterیا همان IOXIDResolverمسئول شناسایی و اتصال به این اشیاء DCOM هستند.
به زبان ساده‌تر:
کتابخانه‌های بومی ویندوز (مثل wmic, PowerShell, MMC و ...) در مراحل اولیه ایجاد یک شیء DCOM، به صورت پیش‌فرض از رابط IObjectExporterاستفاده می‌کنند؛ اگرچه این کار از نظر فنی الزامی نیست.
در حین اتصال به این رابط، سطح احراز هویت روی "بدون احراز هویت" سطح1تنظیم می‌شود. سپس تابع ServerAlive2 فراخوانی می‌گردد تا اتصال بررسی شود.
نقش سیاست Group Policy در بروز خطا
زمانی که سیاست Group Policyمربوط به Restrict Unauthenticated RPC Clientsروی حالت احراز هویت بدون استثناتنظیم می‌شود، تمام فعالیت‌های بدون احراز هویتاز جمله اتصال به IObjectExporter مسدود می‌گردد. در نتیجه، فرآیند ایجاد شیء DCOM متوقف می‌شود و اجرای دستور wmicیا هر ابزار دیگری که بر پایه DCOM کار می‌کند، با خطای Access Deniedمواجه می‌شود — حتی اگر کاربر دارای دسترسی ادمین باشد.
تأثیر بر عملکرد دامنه
از آنجایی که ایجاد اشیاء DCOM در بسیاری از عملیات‌های حیاتی کنترلر دامنه نقش دارد، مسدودسازی این فرآیند می‌تواند باعث اختلال گسترده در عملکرد دامنه شود.
خلاصه:
تنظیم این سیاست روی گزینه Authenticated without exceptions فقط باعث از کار افتادن WMI نمی‌شود، بلکه می‌تواند عملکرد کل دامنه را با مشکل مواجه کند.
بررسی رفتار سیستم در سطوح دیگر سیاست
برای درک بهتر رفتار سیستم، بیایید بررسی کنیم وقتی این سیاست روی حالت Authenticated یا Noneقرار می‌گیرد، چه اتفاقی رخ می‌دهد.
تحلیل ترافیک با Wireshark
برای این منظور، با استفاده از ابزار Wireshark ترافیک شبکه را در حین اجرای یک دستورپاورشلمشابه WMIC ضبط می‌کنیم.
در این ترافیک ضبط‌شده، مشاهده می‌کنیم که:
- قبل از اینکه شیء DCOM ایجاد شود، ابتدا رابط بایدبایندشود.
- سپس تابع ServerAlive2فراخوانی می‌شود (بسته‌های شماره ۲۱ تا ۲۴ در Wireshark).
اگر بسته شماره ۲۱ را که شامل درخواست bind است بررسی کنیم، می‌بینیم که:
- کتابخانه‌های بومی ویندوز این رابط را بدون احراز هویت بایندمی‌کنند.
- این موضوع از طریق فیلد Auth Lengthکه مقدار آن صفر است، قابل تشخیص است.
بررسی ترافیک شبکه هنگام اعمال سیاست «احراز بدون استثناء»
ترافیک شبکه مرتبط با WMI
وقتی سیاست Group Policyرا روی حالت احراز بدون استثناء قرار می‌دهیم و دوباره اقدام به اجرای دستور WMI می‌کنیم، در ترافیک شبکه چندین پاسخ با وضعیت "Access Denied"مشاهده می‌شود.
این پیام‌ها مربوط به تلاش برای فراخوانی تابع ServerAlive2 هستند، حتی با وجود استفاده از اعتبارنامه‌های معتبر. دلیل این اتفاق، مسدود شدن رفتار پیش‌فرض بدون احراز هویت در مرحله bind اولیه به رابط IOXIDResolverاست.
نتیجه‌گیری:
دلیل خطا نه در خود WMI، بلکه در عدم موفقیت در باینداولیه رابط IOXIDResolver بدون احراز هویت است.
رویدادی که هرگز رخ نمی‌دهد
در بخش‌های قبل دیدیم که جلوگیری کامل از شمردن اطلاعات دامنه تقریباً غیرممکن است. اما شناسایی این فعالیت ممکن است.
بررسی Event ID 5712
اولین گزینه برای تشخیص، سیاست‌های حسابرسی ویندوزاست. رویدادی با شناسه 5712 وجود دارد که باید پیام زیر را ثبت کند:
“Audit RPC Events 5712(S): A Remote Procedure Call (RPC) was attempted.”
اما مایکروسافت اعلام کرده که این رویداد در عمل هرگز تولید نمی‌شود. این موضوع پس از فعال‌سازی این سیاست و بررسی Event Viewer تأیید شد — هیچ رویدادی برای فراخوان‌های RPC ثبت نشد.
دو راه‌کار جایگزین برای شناسایی فعالیت‌های RPC
با وجود بن‌بست در سیاست‌های بومی ویندوز، دو راه‌کار دیگر برای شناسایی فعالیت‌های RPC وجود دارد:
Event Tracing for Windows (ETW)
- این ابزار می‌تواند رویدادهای مرتبط با RPC را ثبت کند.
- اما فاقد اطلاعات مهمی مانند آدرس IP کلاینت است.
- همچنین، تعداد بسیار زیادی رویداد ثبت می‌کند (حتی فعالیت‌های محلی)، که تحلیل آن را دشوار می‌سازد.
ابزار متن‌باز RPC-Firewall
- ابزاری قدرتمند برای ممیزی تمام تماس‌های راه‌دور RPC.
- قابلیت ثبت و فیلتر بر اساس UUID، opnumو آدرس مبدا را دارد.
- امکان مسدودسازی یا اجازه‌دادن به فراخوان‌های خاص.
- با Event Viewer ادغام شده و خروجی خوانا تولید می‌کند.
چالش اصلی
با وجود این ابزارها، به‌دلیل نبود پشتیبانی بومی در ویندوز، شناسایی چنین فعالیت‌هایی هنوز هم دشوار و پیچیده است.
برای موفقیت در این حوزه، باید بتوان مشخص کرد که کدام ماشین‌ها در دامنه در حال ارسال درخواست‌های RPC بدون احراز هویت هستند و با چه فراوانی.
امنیت MS-RPC
اکنون به بررسی این موضوع می‌پردازیم که چرا ویندوز چنین رفتارهایی دارد، مشکلات موجود در سیاست‌ها از کجا نشأت می‌گیرند و منظور از استثناها چیست. اما پیش از آن، باید با امنیت MS-RPCآشنا شویم — یعنی روش‌هایی برای ایمن‌سازی سرورهای RPC.
سرور RPC چیست؟
- در اینجا منظور از سرور RPC، سیستمی است که منطق عملکرد یک یا چند رابط RPC در آن پیاده‌سازی شده است.
- یک سرور می‌تواند شامل چندین رابط باشد.
پیچیدگی در ایمن‌سازی سرور RPC
دلایل:
- تنوع روش‌های دسترسی مانند لوله‌های نامگذاریشده و TCP endpoints.
- تکامل روش‌های امنیتی در طول زمان.
ما فقط به آن دسته از روش‌ها خواهیم پرداخت که مستقیماً با تحقیق ما مرتبط هستند.
پرچم‌های ثبت‌نام
هنگام ثبت یک رابط در سرور RPC، با استفاده از تابع RpcServerRegisterIf2 می‌توان پرچم‌های خاصی را تنظیم کرد:
پرچم‌های مهم:
- RPC_IF_ALLOW_LOCAL_ONLY
فقط درخواست‌های محلی را قبول می‌کند و درخواست‌های راه‌دور را رد می‌کند.
- RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH
امکان تعریف یک تابع امنیتی برای بررسی احراز هویت فراهم می‌سازد.
- RPC_IF_ALLOW_SECURE_ONLY
فقط به کلاینت‌هایی اجازه اتصال می‌دهد که سطح احراز هویت‌شان بالاتر از هیچباشد.
تابع امنیتی
در صورت استفاده از پرچم RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH، یک تابع مانند MySecurityCallback تعریف می‌شود. این تابع بررسی‌های امنیتی را به‌جای سیستم، انجام می‌دهد.
منطق عملکرد:
- اگر RPC_S_OKکد 0 برگردانده شود، اتصال مجاز است.
- در غیر این‌صورت، اتصال رد می‌شود.
تعامل بین سیاست ویندوز و پرچم‌ها
رفتار پیش‌فرض احراز هویت توسط کتابخانه rpcrt4.dllو با استفاده از مکانیسم‌هایی مانند NTLMیا Kerberosانجام می‌شود.
اما دو عامل بر این رفتار تأثیرگذارند:
- سیاست Restrict Unauthenticated RPC Clients:
o مقدار "None": کلاینت‌های بدون احراز هویت مجازند.
o مقدار "Authenticated": فقط کلاینت‌های احراز هویت‌شده مجازند.
- پرچم RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH:
o حتی در حالت "احراز"، این پرچم اجازه می‌دهد کلاینت بدون احراز هویت وارد شود — به شرطی که توسط تابع امنیتی تایید شود.
o اما در حالت "احراز بدون استثنا"، این پرچم بی‌اثر می‌شود و همه کلاینت‌های بدون احراز هویت رد می‌شوند.
نتیجه‌گیری درباره "استثناها"
استثناهایی که در عملکرد سیاست‌ها دیده می‌شود ناشی از همین پرچم‌ها هستند — مخصوصاً زمانی که یک رابط RPC با RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTHثبت شده باشد.
اکنون مشخص است که منشأ این استثناها چیست و چگونه عمل می‌کنند.
امنیت اندپوینت
همانطور که قبلاً اشاره شد، سرورهای RPC می‌توانند از طریق لایه‌های مختلف حمل و نقل به کانکشن‌های راه‌دور فراهم کنند. برای اتصالات راه‌دور، معمولاً از پورت‌های TCPو لوله‌های نامگذاریشده استفاده می‌شود.
در هنگام ثبت یک نقطه‌انتهایی برای یک سرور RPC با استفاده از تابع RpcServerUseProtseqEp، می‌توانید یک توصیفگر امنیتی را شامل کنید که کنترل می‌کند چه کسی می‌تواند به نقطه‌انتهایی متصل شود. نکته‌ای که باید به آن توجه داشت این است که این SDتنها برای پایپ‌های نام‌دار اعمال می‌شود و نه برای پورت‌های TCP.همچنین، این توصیفگر می‌تواند برای اتصالات محلی با استفاده از پورت‌های ALPCبه عنوان نقطه‌انتهایی استفاده شود.
ایمن‌سازی رابط
مایکروسافت نسخه جدیدی از تابع RpcServerRegisterIf2 به نام RpcServerRegisterIf3معرفی کرده است که به شما امکان می‌دهد یک توصیفگر امنیتی اختیاری (SD)را هنگام ثبت رابط خود اضافه کنید. این امر به شما اجازه می‌دهد کنترل کنید چه کسی می‌تواند به طور مستقیم به رابط متصل شود.
این مکانیزم امنیتی یک سؤال مهم را مطرح می‌کند: اگر یک رابط یک SDثبت کرده باشد و یک کلاینت از طریق TCP بدون احراز هویت (سطح احراز هویت = 1) متصل شود، چگونه بررسی امنیت انجام می‌شود؟ به طور خاص، چه توکنی برای بررسی SD به کلاینت اختصاص داده می‌شود؟
برای پاسخ به این سؤال، لازم است که مهارت‌های مهندسی معکوس را بر روی کتابخانه RPC runtime (rpcrt4.dll) به کار ببریم.
در واقع یک کلاینت که از طریق یک نقطه‌انتهایی TCP بدون احراز هویت متصل می‌شود، به عنوان یک کاربر ناشناس شناخته می‌شود.
پس از آن، بررسی دسترسی با استفاده از تابع AccessCheck انجام می‌شود.
احراز هویت اتصال
آخرین مسئله امنیتی RPC که باید مورد بحث قرار گیرد، احراز هویت اتصال است. همانطور که به یاد دارید، روش احراز هویت در بسته‌اتصال اینگونه بود که بسته اول در یک ارتباطمشخص می‌شود. اما این به چه معنی است؟ سرور RPC می‌تواند روش احراز هویت مورد نظر خود را برای کلاینت‌ها با استفاده از تابع RpcServerRegisterAuthInfo ثبت کند. به عنوان مثال، در مثال زیر، احراز هویت NTLM به عنوان روش انتخابی ثبت می‌شود.
پس از آن، کلاینت می‌تواند با استفاده از RPCBindSetAuthInfoExو تعیین سرویس احراز هویت صحیح و سطح احراز هویت متصل شود.
حالا که امنیت RPC را بررسی کردیم، وقت آن است که به سوالات مربوط به رابط خود (MS-NRPC) پاسخ دهیم: چه نوع امنیتی در سروری که این رابط را تعریف می‌کند اعمال شده و چرا توانستیم بدون احراز هویت به آن دسترسی پیدا کنیم؟
برای این کار از دو رویکرد استفاده کردم:
- تحلیل سطحی
o بررسی امنیت داخلی سرور RPC با استفاده از یک چارت جریان از یک مجموعه ابزار عالی RPC. این چارت به ما کمک می‌کند تا جزئیات بیشتری از امنیت اعمال‌شده توسط سرور RPC به دست آوریم. در اینجا، من گام به گام مسیر را بررسی می‌کنم تا تحقیق را انجام دهم.
- تحلیل عمقی
o در این روش، با استفاده از مهندسی معکوس با سرور RPC به طور مستقیم تعامل می‌کنم تا درک بیشتری از امنیت فعال‌شده در سرور RPC به دست آورم.
تحلیل سطحی
در اینجا قصد دارم مکانیزم امنیتی که سرور RPC در ارتباط با رابط MS-NRPC استفاده می‌کند را تعیین کنم. فرض می‌کنیم که ما کلاینت RPC هستیم که قصد داریم بدون استفاده از هیچ‌گونه احراز هویت، تابعی از رابط MS-NRPC را فراخوانی کنیم تا اطلاعات دامنه را شمارش کنیم.
در این مرحله با سیاست Restrict Unauthenticated RPC Clientsمواجه می‌شویم که دو مقدار ممکن «هیچ» یا «احرازشده» را دارد. اگر مقدار آن "هیچ" باشد، به مرحله بعدی می‌رویم. اما اگر مقدار آن "احرازشده" باشد، بررسی می‌شود که آیا کلاینت احراز هویت شده است یا خیر. اگر احراز هویت شده باشد، جریان ادامه می‌یابد؛ اما اگر کلاینت بدون احراز هویت متصل شود (همانطور که در اینجا اتفاق می‌افتد)، کتابخانه RPC برای بررسی وضعیت پرچم RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTHرا بررسی و بر اساس وجود یا عدم وجود آن، اتصال را می‌پذیرد یا رد می‌کند.
تحلیل ادامه‌دار فرآیند احراز هویت RPC
از آنجا که سیاست روی "احرازشده" تنظیم شده است و کلاینت ما احراز هویت را انجام نمی‌دهد، برای ادامه دادن به مرحله بعدی نیاز داریم که پرچم RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTHثبت شده باشد تا استثنایی برای این سیاست ایجاد کند. وجود این پرچم به ما این امکان را می‌دهد که نتیجه‌گیری کنیم که یک نیز ثبت شده است.
بررسی مراحل بعدی
- بررسی ثبت سرویس احراز هویت:
o پس از این مرحله، یک بررسی دیگر انجام می‌شود تا مشاهده شود آیا سرور سرویسی برای احراز هویت ثبت کرده است یا خیر. اگر سرور هیچ‌گونه سرویسی برای احراز هویت ثبت نکرده باشد و کلاینت سعی کند احراز هویت کند، این اقدام با خطای "Authentication service unknown"رد خواهد شد. اما اگر کلاینت هیچ تلاشی برای احراز هویت نکند، فرآیند ادامه می‌یابد.
- بررسی امنیت اندپوینت
o اگر سرور یک سرویس احراز هویت ثبت کرده باشد، بررسی امنیت اندپوینت که با استفاده از RpcServerUseProtseqEpثبت می‌شود انجام می‌شود. اگر کلاینت این بررسی را پشت سر بگذارد، بررسی دیگری بر روی SD رابط که با استفاده از RpcServerRegisterIf3ثبت می‌شود صورت می‌گیرد. عدم موفقیت در هر یک از این مراحل، منجر به رد دسترسی خواهد شد.
- بررسی وجود SD رابط
o در اینجا، می‌دانیم که سرور در حال حاضر سرویس احراز هویت ثبت کرده است، زیرا پروتکلی است که به طور عمومی توسط مایکروسافت شناخته‌شده است. همچنین نیازی به نگرانی در مورد بررسی نقطه‌انتهایی نداریم، زیرا این برای کلاینت‌هایی است که از طریق پایپ‌های نام‌دار متصل می‌شوند. در مورد توصیفگر امنیتی رابط، یا این بررسی را عبور می‌کنیم اگر SD اصلاً وجود نداشته باشد، یا اینکه SD وجود داشته باشد و اجازه دسترسی به کاربران ناشناس را بدهد (که نمایانگر کلاینت‌های بدون احراز هویت است).
- بررسی پرچم‌ها:
o در این مرحله، دو پرچم را بررسی می‌کنیم: اولی RPC_IF_ALLOW_LOCAL_ONLYاست که تعیین می‌کند آیا رابط می‌تواند از راه‌دور به آن دسترسی پیدا کرد یا خیر، و دومی RPC_IF_ALLOW_SECURE_ONLYاست. اگر پرچم دوم موجود باشد، اطمینان حاصل می‌شود که از یک سطح احراز هویت بالاتر از "هیچ" استفاده می‌کنیم، که بر اساس سطح احراز هویت دسترسی اجازه یا رد می‌شود.
- بررسی کال‌بک امنیتی
o در نهایت، بررسی می‌کنیم که آیا کال‌بک امنیتی وجود دارد یا خیر. اگر اینکال‌بکوجود نداشته باشد، می‌توانیم بلافاصله به سرور دسترسی پیدا کنیم. اما اگرکال‌بک امنیتی وجود داشته باشد، باید از طریق چک‌های سفارشی درون اینکال‌بکعبور کنیم تا به سرور دسترسی پیدا کنیم.
نتیجه‌گیری
در مورد ما، می‌دانیم که پرچم RPC_IF_ALLOW_LOCAL_ONLYوجود ندارد زیرا می‌توانیم به رابط دسترسی از راه‌دور داشته باشیم. همچنین می‌دانیم که پرچم RPC_IF_ALLOW_SECURE_ONLYوجود ندارد زیرا ما از سطح احراز هویت "None" استفاده می‌کنیم. در نهایت، با توجه به استفاده قبلی از RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTHنتیجه می‌گیریم که یککال‌بکامنیتی ثبت شده است و ما با موفقیت از این چککال‌بکعبور کرده و به سرور دسترسی پیدا می‌کنیم.
این فرآیند نشان می‌دهد که چگونه عملکردهای امنیتی مختلف در پروتکل RPC برای کنترل دسترسی بدون احراز هویت یا با احراز هویت به کار گرفته می‌شوند و چطور برخی از سیاست‌ها و تنظیمات می‌توانند استثنائاتی برای دسترسی ایجاد کنند.
خلاصه تحلیل سطحی و عمیق امنیت RPC
تحلیل سطحی: در این بخش، ویژگی‌های سرور RPC مربوط به رابط MS-NRPC بررسی شد. نتایج به دست آمده عبارتند از:
- پرچم‌های ثبت شده:
- RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH - این پرچم نشان‌دهنده وجود یک کال‌بک امنیتی است.
- RPC_IF_ALLOW_LOCAL_ONLYو RPC_IF_ALLOW_SECURE_ONLYوجود ندارند.
- رابط:
- نمی‌توانیم اطمینان حاصل کنیم که آیا توصیفگر امنیتی (SD) برای رابط ثبت شده یا خیر.
- احراز هویت ثبت‌شده در اتصال:
- سرور RPC احراز هویت را ثبت کرده است.
تحلیل سطحی قادر به ارائه یک دید کلی از امنیت MS-NRPC نبود، بنابراین تصمیم به انجام تحلیل عمیق گرفته شد.
تحلیل عمقی:در اینجا، از مهندسی معکوس برای بررسی امنیت رابط MS-NRPC استفاده شد:
- ابزارهای خودکار:
o استفاده از PE RPC Scraper اطلاعاتی درباره پرچم‌ها و توابع RPC سرور به دست آورد. این ابزار نشان داد که رابط MS-NRPC دارای RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTHاست و یککال‌بک امنیتی دارد، اما SD (توصیفگر امنیتی) برای رابط وجود ندارد.
- استفاده از IDA:
o در IDA، ثبت رابط و اندپوینتبررسی شد. سرور از توابعی مانند RpcServerUseProtseqEpW برای ثبت سه نقطه‌انتهایی استفاده کرده است.
o همچنین RpcServerRegisterIf3 برای ثبت رابط MS-NRPC به کار رفته است.
- کال‌بک امنیتی
o کال‌بک امنیتی بررسی شد که شامل چک‌هایی برای بررسی نوع کلاینت (محلی یا از راه دور) و تطابق با ماتریس دسترسی است. اگر دسترسی به یک تابع مجاز باشد، دسترسی فراهم می‌شود.
- توصیفگر امنیتی:
o امنیت رابط از طریق RpcServerRegisterIf3و یک توصیفگر امنیتی ثبت می‌شود که به گروه‌های مختلفی اجازه دسترسی می‌دهد، از جمله "Anonymous Logon". این توضیح می‌دهد که چرا دسترسی بدون احراز هویت به رابط امکان‌پذیر است.
نتیجه‌گیری: با استفاده از اطلاعات به دست آمده از تحلیل عمیق، توانستیم توضیح دهیم که چرا و چگونه امکان دسترسی به رابط MS-NRPC بدون احراز هویت وجود دارد، حتی زمانی که سیاست RPC روی «احرازشده»تنظیم شده است.
دلایل عبور از چک‌های امنیتی
- پرچم‌ها: وجود RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH اجازه عبور از سیاست‌های امنیتی را می‌دهد.
- کال‌بکامنیتی: بررسی با استفاده از یک ماتریس دسترسی و اجازه دسترسی به توابع خاص.
- توصیفگر امنیتی: گروه‌های مختلف از جمله "Anonymous Logon" اجازه دسترسی دارند، که به ما این امکان را می‌دهد که بدون احراز هویت به رابط دسترسی پیدا کنیم.
این تحقیق به درک بهتر نحوه نفوذ به سیستم‌های مشابه کمک می‌کند و روش‌هایی برای شناسایی چنین فعالیت‌هایی را ارائه می‌دهد.
[1] Named Pipes: مکانیزم ارتباطی که بین دو برنامه (process) امکان انتقال داده‌ها را فراهم می‌کند.
[2]یک پروتکل شبکه‌ای است که در ویندوز استفاده می‌شود.
[3]Windows Management Instrumentation
کسپرسکی آنلاین (ایدکو)
کسپرسکی اسم یکی از بزرگترین شرکتهای امنیتی و سازنده آنتی ویروس است که برخی از کاربران اشتباهاً این شرکت و محصولات آنتی ویروس آن را با عناوینی نظیر کسپرسکای،کاسپرسکی، کسپراسکای، کسپراسکای، و یا کاسپراسکای نیز می‌شناسد. همچنین لازم به ذکر است مدیرعامل این شرکت نیز یوجین کسپرسکی نام دارد.
