#بحث فلسفی روز تعطیل

وقتی مایکروسافت برای EDR تصمیم می‌گیرد!

📝روزبه نوروزی

قابلیت PatchGuard برای محافظت از کرنل ویندوز طراحی شد، اما همزمان آزادی عمل بسیاری از ابزارهای امنیتی را نیز محدود کرد. این موضوع یک پرسش مهم ایجاد می‌کند: آیا باید معماری دفاع را فروشنده پلتفرم تعیین کند یا جامعه امنیت؟ حادثه CrowdStrike در سال ۲۰۲۴ نیز نشان داد که دسترسی سطح کرنل، علاوه بر قدرت دفاعی، می‌تواند به یک ریسک زیرساختی گسترده تبدیل شود. شاید PatchGuard بیش از آنکه یک قابلیت فنی باشد، آغاز یک بحث عمیق درباره آینده حکمرانی امنیت سایبری است.

مقوله PatchGuard امنیت integrity کرنل را بالا برد، اما روش مداخله‌ی سنتی EDR/AVها در کرنل را محدود کرد. این نکته‌ی مهم نیاز به دقت دارد: PatchGuard مانع حضور درایور EDR در سطح کرنل نشد - همه‌ی EDRهای بزرگ امروز (CrowdStrike, Defender, SentinelOne) همچنان درایور kernel-mode دارند و در Ring 0 می‌بینند. آنچه PatchGuard گرفت، امکان دستکاری مستقیم و غیررسمی ساختارهای داخلی کرنل بود (مثل SSDT hooking قدیمی). یعنی مسیر دفاع از "دیدن و دخالت بدون اجازه" به "دیدن از طریق API رسمی، ETW، callbacks و driver signing" منتقل شد ، نه اینکه دید عمیق به‌کلی گرفته شده باشد.

از نگاه مایکروسافت، حتی یک ابزار امنیتی با نیت خوب اگر کد یا ساختارهای حیاتی کرنل را patch کند، معماری مشابه رفتار rootkit دارد. هدف رسمی، حفظ integrity، reliability و resiliency ویندوز بوده.

اما نقد صنعت امنیت هم جدی است. وقتی vendor پلتفرم می‌گوید از این نقطه به بعد فقط از مسیرهایی که من تعریف کرده‌ام دخالت کن، عملاً قدرت تعریف معماری امنیت از بازار دفاعی به مالک سیستم‌عامل منتقل می‌شود ، حتی اگر دید نهایی (visibility) آسیب نبیند.

حادثه CrowdStrike در ۱۹ ژوئیه ۲۰۲۴ سمت دیگر ماجرا را نشان داد، و در واقع نکته را قوی‌تر می‌کند نه ضعیف‌تر: مشکل از کد جدید درایور نبود، بلکه از یک فایل پیکربندی (Channel File 291) بود که نحوه‌ی ارزیابی named pipe execution را در سطح کرنل کنترل می‌کرد . ریشه‌ی فنی، عدم تطابق بین ۲۱ ورودی که توسط Content Validator تایید می‌شد و ۲۰ ورودی که به Content Interpreter داده می‌شد بود ، که منجر به خواندن خارج از محدوده‌ی حافظه (out-of-bounds read) و کرش سیستم شد . نکته‌ی کلیدی: این فایل‌های Channel خودشان درایور کرنل نیستند، اما توسط کد سطح کرنل CrowdStrike پردازش می‌شوند. یعنی حتی یک فایل تنظیمات (نه کد جدید) توانست با دسترسی کرنل کل ویندوز را از کار بیندازد ، این argument برای ریسک "دسترسی عمیق" قوی‌تر از نسخه‌ی قبلی است.

جالب اینجاست که خود CrowdStrike در RCA رسمی‌اش متعهد شد با مایکروسافت روی دسترسی امن‌تر و مطمئن‌تر به کرنل ویندوز کار کند و اشاره کرد با معرفی نسخه‌های جدید ویندوز که امکان انجام بیشتر این توابع امنیتی در user space را فراهم می‌کنند، عامل خود را برای استفاده از این قابلیت به‌روزرسانی می‌کند . این دقیقاً همان جهتی است که بحث فلسفی من درباره‌اش است: صنعت خودش هم دارد به سمت کاهش وابستگی به دسترسی کرنل حرکت می‌کند، نه فقط به فشار مایکروسافت.

پس مسئله این نیست که PatchGuard خوب است یا بد. مسئله این است که امنیت کرنل سه خطر هم‌زمان دارد: اگر مسیر تغییر کرنل باز باشد، EDR قدرت مداخله‌ی بیشتری دارد ولی malware و driver مخرب هم همان میدان را می‌گیرند؛ اگر بسته باشد، integrity و پایداری بهتر می‌شود ولی vendor lock-in و تمرکز قدرت در دست مالک پلتفرم بالا می‌رود؛ و اگر امنیت کاملاً به API رسمی مایکروسافت وابسته شود، اکوسیستم دفاعی ممکن است خلاقیت و استقلال کمتری داشته باشد.

از نگاه معماری امنیت، بهترین پاسخ یک مدل میانه است: کرنل نباید محل مداخله‌ی بی‌قاعده‌ی فروشندگان امنیتی باشد، اما مایکروسافت هم نباید تنها مرجع انحصاری تعریف visibility و control باشد. باید APIهای رسمی، غنی، قابل audit، با SLA شفاف، telemetry سطح پایین، staged rollout اجباری برای content update ها (نه فقط کد)، و امکان رقابت برابر برای vendorها وجود داشته باشد.

جمع‌بندی فلسفی: PatchGuard دفاع را ضعیف نکرد؛ مسیر تغییر دادن کرنل را محدود کرد، نه مسیر دیدن آن. اما حادثه‌ی CrowdStrike نشان داد حتی دیدن و پردازش در سطح کرنل - بدون هیچ patch غیررسمی - به‌خودی‌خود ریسک سیستمیک ایجاد می‌کند. وقتی امنیت از اکوسیستم دفاعی متنوع به حاکمیت متمرکز چند vendor با دسترسی کرنل تبدیل می‌شود، این همان single point of failure خطرناک است ، صرف‌نظر از اینکه آن دسترسی از طریق patch غیررسمی باشد یا API کاملاً رسمی و مجاز.