شركة كومورا سوفت ذ.م.م.
تواصل معنا
القائمة

أعماق الافتراضيّة في Windows（الجزء 2）── ذاكرة لا تراها النواة: كيف يعمل VBS وHVCI وCredential Guard

· · Windows, الافتراضيّة, الأمان, VBS, HVCI, Credential Guard

كان ثمّة زمن كانت فيه صلاحيّات المسؤول «الهدف» لمهاجم على Windows. حمِّل برنامج تشغيل نواة بصفتك مسؤولاً، وأفرغ ذاكرة عمليّة LSASS، فتحصل على تجزئات كلمات المرور وتذاكر Kerberos. من هناك المسألة مجرّد المشي إلى جهاز آخر بالتجزئات المسروقة.

على Windows 11 الحاليّ مع تشغيل Credential Guard ── الحالة الافتراضيّة من 22H2 فصاعداً على الأجهزة التي تستوفي متطلّبات الترخيص مثل Enterprise وEducation، زائد متطلّبات العتاد ── لا يعمل ذلك السيناريو. مهاجم أخذ النواة بالكامل يمكنه البحث في الذاكرة كما يشاء، والتجزئات الفعليّة لبيانات اعتماد المجال المحميّة لا تُوجَد «داخل نظام التشغيل ذاك». إن لم يكن يعمل، يبقى الخطر القديم، فاقرأ هذا مع طرائق التأكيد لاحقاً في المقال.

فأين هي؟ الجواب «عالم آخر، أُنشئ داخل الحاسوب نفسه». كما رأينا في الجزء 1، يعمل Windows المضيف في القسم الجذر فوق الـ hypervisor («أين يعمل Windows فعليّاً؟»). يتواصل هذا المقال من هناك ويتتبّع خطّ حدّ إضافيّاً يرسمه الـ hypervisor داخل القسم نفسه.

السؤال الذي يجيب عنه الجزء 2 واحد فقط.

أين يضع Windows أسراراً لا يستطيع مدير ولا النواة قراءتها؟

القرّاء المستهدَفون مطوِّرون ومشغِّلون رأوا كلمات مثل عزل النواة وسلامة الذاكرة وCredential Guard على شاشة إعدادات أو في حالة استكشاف أخطاء، ويريدون فهم الشيء الحقيقيّ من الآليّة صعوداً. المتطلّبات هي Windows 10/11 x64 أو Windows Server الحالي (كما في الجزء 1، نقاش الحلقات وSLAT يفترض x64؛ يستخدم Arm64 آليّة مختلفة مثل مستويات الاستثناء). الخلفيّة المطلوبة هي مفاهيم الأقسام وSLAT التي غطّاها الجزء 1. الصعوبة متوسّطة. الهدف شرح البنية، لا كيفيّة ضبط الميزات الأمنيّة.

1. الخلاصة أوّلاً

أضاف Windows محور امتياز يُسمَّى VTL（Virtual Trust Level）ووضع الأسرار في VTL1. لا يمكن قراءة ذاكرة VTL1 من النواة العاديّة التي تعمل في VTL0. ما يحرس الحدّ ليس النواة نفسها، بل الـ hypervisor الذي يحتفظ بجداول ترجمة SLAT.

ذلك هو هيكل الأمان المستند إلى الافتراضيّة (VBS). يستخدم VBS الـ hypervisor لإنشاء بيئة معزولة ويؤوي فيها ميزات أمنيّة. وهو مصمَّم على افتراض أنّ البيئة المعزولة تبقى محميّة حتّى إن اختُرقت النواة.1

العالمان اللذان ينشئهما VBSيجلس VTL0 وVTL1 داخل القسم نفسه؛ يحوي VTL0 النواة العاديّة والتطبيقات، ويحوي VTL1 النواة الآمنة وميزات الأمان المعزولة، ويحرس الـ hypervisor الحدّVTL1（العالم المعزول）VTL0（العالم العاديّ）لا تستطيع القراءةميزات أمان معزولةالنواة الآمنةالتطبيقات（الحلقة 3）نواة NT وبرامج التشغيل（الحلقة 0）الـ hypervisor（يفرض الحدّ عبر SLAT）

الشكل 1: ثمّة عالمان داخل Windows واحد، ولا تستطيع نواة VTL0 الوصول إلى ذاكرة VTL1.

النقطة المهمّة أنّ هذا ليس «إقامة آلة افتراضيّة أخرى». VTL0 وVTL1 داخل القسم نفسه، داخل Windows نفسه. سننظر تباعاً في كيفيّة تحقيق هذا الانقسام.

2. حدود نموذج الحلقات ── الحارس والمحروس يجلسان على الارتفاع نفسه

بُني أمان Windows التقليديّ على سلّم الحلقات (مستويات الامتياز). وضع المستخدم (الحلقة 3) يحرسه وضع النواة (الحلقة 0). فمن يحرس الحلقة 0 ── لا أحد يستطيع. الحلقة 0 أعلى امتياز.

لهذه البنية ضعفان بنيويّان.

  • النواة ليست كتلة واحدة. عند الحلقة 0، لا يعمل Windows نفسه فقط بل عدد كبير من برامج تشغيل طرف ثالث. إن وُجدت ثغرة في أيّ واحد منها، يحصل مهاجم على تنفيذ شيفرة عند الحلقة 0.
  • من الحلقة 0، كلّ شيء مرئيّ. مهما دافع عن نفسه عمليّة وضع مستخدم مثل LSASS، فذاكرتها حرّة القراءة لمهاجم أخذ النواة. سمات الحماية وجداول الصفحات على حدّ سواء تديرها النواة نفسها.
مسار سرقة بيانات الاعتماد في نموذج الحلقات التقليديّمهاجم يأخذ الحلقة 0 عبر برنامج تشغيل ضعيف يمكنه قراءة ذاكرة عمليّة LSASS بسلطة النواة الكاملة والحصول على تجزئات كلمات المروريستغلّ برنامج تشغيل ضعيفشيفرة مهاجميأخذ التحكّم بالحلقة 0يستطيع قراءة كلّ الذاكرة الفيزيائيّةيحصل على التجزئات من ذاكرة LSASSتُساء استخدامها للحركة الأفقيّة إلى أجهزة أخرى

الشكل 2: لأنّ الحارس（النواة）والمحرُوس（الأسرار）يجلسان على الارتفاع نفسه، الضعف الجوهريّ هو أنّه إن سقطت الحلقة 0 سقط كلّ شيء.

ما يُحتاج إذن هو «مكان أعلى من الحلقة 0». ذلك المكان ظهر أصلاً في الجزء 1. يعمل الـ hypervisor بامتياز أعلى من النواة ويحتكر التحكّم بأذونات وصول ذاكرة المعالج (SLAT) مبكِّراً. منطقة معزولة يحرسها الـ hypervisor محميّة حتّى ضدّ الوصول من برمجيّات نظام تشغيل الحلقة 0 (وضع المشرف).2

3. VSM وVTL ── إضافة محور امتياز إضافيّ

3.1. مستويات الثقة الافتراضيّة (VTL)

تُسمَّى عائلة ميزات الـ hypervisor التي توفِّر هذا العزل VSM (Virtual Secure Mode). VSM أساس لـ Device Guard وCredential Guard وTPM افتراضيّ وما شابه.2

المفهوم المركزيّ لـ VSM هو VTL (Virtual Trust Level). النقاط الأساسيّة كالتالي.2

  • VTL هرميّة، وكلّما ارتفع الرقم ارتفع الامتياز. VTL0 الأدنى؛ VTL1 أكثر امتيازاً من VTL0.
  • معماريّاً تُعرَّف حتى 16 مستوى، لكن ما هو منفَّذ حالياً هو اثنان: VTL0 وVTL1.
  • لكلّ VTL حمايات وصول ذاكرة مستقلّة. يدير الـ hypervisor هذه الحمايات مقابل فضاء العنوان الفيزيائيّ للقسم، لذا لا تستطيع برمجيّات النظام داخل القسم تغييرها.
  • لمعالج افتراضيّ حالة سجلات وآليّة مقاطعات منفصلة لكلّ VTL، ولا يستطيع VTL أدنى التطلّع إلى حالة VTL أعلى.
ثلاث استقلاليّات تكوِّن عزل VTLحمايات وصول الذاكرة وحالة سجلات المعالج الافتراضيّ وآليّة المقاطعات مستقلّة لكلّ VTL، ولا يستطيع VTL أدنى لمس أيّ منها في VTL أعلىما هو مستقلّ لكلّ VTLحمايات وصول الذاكرةحالة سجلات المعالج الافتراضيّآليّة المقاطعاتVTL أدنى لا يلمس VTL أعلى

الشكل 3: جعل ليس الذاكرة فقط بل أيضاً حالة المعالج والمقاطعات عالماً منفصلاً هو المجموعة الثلاثيّة التي لا تترك ثقب تطلّع.

إذا كانت الحلقات (0 و3) المحور الذي يفصل «نظام التشغيل والتطبيقات»، فـ VTL محور ثانٍ يفصل «العالم العاديّ والعالم المعزول». المحوران متعامدان، وداخل VTL1 ثمّة وضع نواة ووضع مستخدم أيضاً.

أربع مناطق ينشئها محورا الحلقات وVTLيفصل محور الحلقات وضع النواة ووضع المستخدم، ويفصل محور VTL العالم العاديّ والعالم المعزول، وينتج عن الجمع أربع مناطق: تطبيقات عاديّة، ونواة NT، وtrustlets في IUM، والنواة الآمنةVTL1（العالم المعزول）VTL0（العالم العاديّ）الحلقة 3: IUM（trustlets）الحلقة 0: النواة الآمنةالحلقة 3: تطبيقات عاديّةالحلقة 0: نواة NT وبرامج التشغيل

الشكل 4: أصبح لمحورَي امتياز الآن، و«هل هي النواة؟» و«هل هو العالم المعزول؟» أصبحا سؤالين منفصلين.

3.2. جوهر الحدّ هو SLAT

في الجزء 1 قلنا إنّ جداول الترجمة من المستوى الثاني التي تسقط عنواناً فيزيائيّاً للضيف (GPA) على RAM الفعليّ (SPA) ── SLAT ── يحتفظ بها الـ hypervisor. يستخدم VSM هذه الخاصّيّة بالضبط. يُنشَأ عزل VTL باستخدام hypervisor Hyper-V وSLAT.3

عندما يعلن VTL1 «هذه الذاكرة لا تُعرَض لـ VTL0»، يُسقط الـ hypervisor إذن الوصول إلى تلك الصفحة من جداول ترجمة VTL0. من ثمّ، حتّى إن حاولت نواة VTL0 لمس ذلك العنوان، يُرفَض في مرحلة ترجمة عناوين المعالج. لا جدوى من إعادة كتابة النواة جداول صفحاتها كما تشاء. قد تكون جداول الصفحات (GVA→GPA) للنواة، لكن الترجمة بعدها (GPA→SPA) وإذن الوصول النهائيّ للـ hypervisor.

التدفّق الذي يُرفَض به الوصول من VTL0 إلى ذاكرة VTL1عندما تحاول نواة VTL0 قراءة ذاكرة VTL1، يمكنها اجتياز جدول صفحاتها لكن حماية وصول SLAT ترفضها، وينتقل التحكّم إلى الـ hypervisorغير مسموحمسموحنواة VTL0 تحاول قراءة صفحة VTL1تجتاز جدول صفحات النواةهل تسمح حماية وصول SLAT؟يتدخّل الـ hypervisor ويرفض الوصولوصول ذاكرة عاديّمحميّ في طبقة لا تستطيع النواة تغييرها

الشكل 5: الحاجز يجلس خارج النواة، ولا تستطيع برمجيّات داخل القسم تغيير حمايات SLAT.

في الجزء 1 من سلسلة الذاكرة كتبنا أنّ «VAD وPTE وسمات الحماية تقرِّر ما إذا كان الوصول مسموحاً». في بيئة VBS يمكن تنظيمه هكذا: بعد اجتياز كلّ تلك، ما زال حاجز تفتيش SLAT ينتظر.

3.3. النواة الآمنة وIUM

ما يعمل داخل VTL1 ليس نواة NT العاديّة بل نواة صغيرة تُسمَّى النواة الآمنة (Secure Kernel). يُسمَّى وضع المستخدم في VTL1 IUM (Isolated User Mode)، والبرامج التي تعمل هناك تُسمَّى trustlets (عمليّات موثوقة).3

لا يستطيع trustlet فعل كلّ شيء كما تفعل عمليّة عاديّة. معظم استدعاءات النظام تُجمَّع إلى نواة NT في جانب VTL0 ويُطلَب العمل هناك.3 VTL1 ليس «عالماً أعلى يستطيع فعل أيّ شيء»؛ إنّه مبنيّ عمداً صغيراً، بوصفه خزنة تحتفظ بأسرار. كلّما قلّت الشيفرة التي تستطيع إدخالها إلى الخزنة، صغر سطح الهجوم.

تدفّق استدعاءات نظام trustletلا يعالج trustlet في VTL1 معظم استدعاءات النظام بنفسه؛ إنّه يجمِّعها إلى نواة NT في VTL0 ويستقبل النتيجة فقط، ما يُبقي VTL1 صغيراًفي معظم الحالاتTrustlet（IUM في VTL1）يُحتاج استدعاء نظاميُجمَّع الطلب إلى نواة NT في VTL0تعود النتيجة فقطيبقى VTL1 صغيراً فيصغر سطح الهجوم

الشكل 6: للخزنة لا مرافق خاصّة بها؛ تُخرِج الأعمال اليوميّة وتواصل حراسة الأسرار فقط.

4. HVCI ── التحقّق من سلامة شيفرة النواة في الخزنة

4.1. ما الذي يُتحقَّق منه

أوّل ميزة ممثِّلة تجلس على VBS هي سلامة الذاكرة ── HVCI (hypervisor-protected code integrity). يملك Windows آليّة سلامة شيفرة تفحص برامج تشغيل وضع النواة والملفّات الثنائيّة قبل بدئها ولا تحمِّل ما هو بلا توقيع أو غير موثوق. يشغِّل HVCI هذا التحقّق داخل بيئة VBS المعزولة.1

سبب نقل منطق التحقّق نفسه إلى VTL1 هو بالضبط الضعف في القسم 2. إن جلست شيفرة التحقّق داخل نواة VTL0، يستطيع مهاجم أخذ النواة استبدال التحقّق. إن كانت في VTL1، لا تصل يد الاستبدال إليها.

الفرق الذي يصنعه مكان شيفرة التحقّقإن جلست شيفرة التحقّق داخل نواة VTL0 يمكن تعطيلها بأخذ النواة، لكن إن كانت في VTL1 حتّى مهاجم أخذ النواة لا يصل إليها ويُحمى التحقّقداخل نواة VTL0（تقليديّ）بيئة معزولة في VTL1（HVCI）مهاجم أخذ النواةأين يعيش التحقّق من سلامة الشيفرة؟يمكن استبدال منطق التحقّقالاستبدال خارج المتناوليمكن لشيفرة بلا توقيع العمل في النواةيواصل التحقّق العمل بعد اختراق النواة

الشكل 7: لا تضع حاجز التفتيش داخل الجانب الذي قد يُخترَق ── ذلك نقل منطق التحقّق هو جوهر HVCI.

4.2. قواعد الصفحات القابلة للتنفيذ

أثر HVCI لا يقتصر على «فحص عند البدء». إنّه يقيِّد أيضاً تخصيص ذاكرة النواة.4

  • تصبح صفحة نواة قابلة للتنفيذ فقط بعد أن تجتاز التحقّق من سلامة الشيفرة.
  • صفحة قابلة للتنفيذ لا تصبح قابلة للكتابة (ما يُسمَّى W^X).

عندما يكون هذان في موضع، حتّى إن أتاحت ثغرة مثل تجاوز مخزن إعادة كتابة ذاكرة النواة، لا تستطيع وضع المحتويات المعاد كتابتها في التنفيذ. صفحة قابلة للتنفيذ لا يمكن إعادة كتابتها، وصفحة يمكن إعادة كتابتها لا يمكن تنفيذها.4 السند النهائيّ لإذن التنفيذ هو حقّ التنفيذ في جانب SLAT، الذي لا تستطيع نواة VTL0 التلاعب به.

حتّى تصبح صفحة نواة قابلة للتنفيذ في بيئة HVCIيستقبل طلب تحميل برنامج تشغيل تحقّقاً من سلامة الشيفرة في بيئة VBS المعزولة؛ إن اجتاز يُسمَح به صفحة قابلة للتنفيذ غير قابلة للكتابة، وإن فشل يُحظَر ويُسجَّل في سجلّ CodeIntegrityاجتيازفشلطلب تحميل شيفرة نواة وتنفيذهاالتحقّق من سلامة الشيفرة في البيئة المعزولةمسموح صفحة قابلة للتنفيذ（الكتابة محظورة）يُحظَر التحميليُسجَّل في سجلّ CodeIntegrity Operational（معرِّف الحدث 3087）الصفحات القابلة للكتابة تبقى غير قابلة للتنفيذ

الشكل 8: التحقّق من القاعدة التي لا تدع التنفيذ والكتابة يتعايشان يُفعَل في جانب VTL1، ولا تستطيع نواة VTL0 نقضه.

تتبّع هذا من وجهة نظر مهاجم يوضح كيف تسري القاعدة.

التدفّق الذي يفشل به حقن الشيفرة في بيئة HVCIحتّى إن أتاحت ثغرة إعادة كتابة ذاكرة النواة، صفحة استطعتَ الكتابة إليها ليست قابلة للتنفيذ، وصفحة قابلة للتنفيذ لا يمكن إعادة كتابتها أصلاً، لذا لا يمكن وضع الشيفرة المحقونة في التنفيذصفحة قابلة للكتابةصفحة قابلة للتنفيذحاول العبث بذاكرة النواة عبر ثغرةأيّ صفحة هي الهدف؟تنجح الكتابةالكتابة نفسها مستحيلةلكن تلك الصفحة ليست قابلة للتنفيذلا يمكن تنفيذ الشيفرة المحقونة

الشكل 9: معنى عدم تقاطع الصفحات القابلة للكتابة مع الصفحات القابلة للتشغيل هو أنّك أيّ مدخل أخذت تصل إلى طريق مسدود.

4.3. الثمن في توافق برامج التشغيل

تصطدم هذه القاعدة ببرامج تشغيل بتصميم أقدم. التي تعيد كتابة شيفرتها وقت التشغيل، أو بلا توقيع، أو تطالب بذاكرة قابلة للتنفيذ وللكتابة معاً ── لا يمكن تحميل مثل هذه البرامج في بيئة HVCI. يمكن تأكيد واقعة الحظر في عارض الأحداث تحت Applications and Services Logs\Microsoft\Windows\CodeIntegrity\Operational (معرِّف الحدث 3087 ممثِّل).5

«بعد تفعيل سلامة الذاكرة، توقّف جهاز طرفيّ عن العمل» ── في كثير من الحالات، تلك هي الهويّة الحقيقيّة للمشكلة. الاستجابة السليمة هي التحديث إلى برنامج تشغيل متوافق مع HVCI؛ ينبغي التفكير في تعطيل سلامة الذاكرة ملاذاً أخيراً يتخلّى عن الحماية جملة. إن كنت منخرطاً في هذا التحقّق من منظور تطوير برامج التشغيل، انظر أيضاً مقال برامج تشغيل المرشِّح («برامج تشغيل المرشِّح الأدنى في Windows»).

عزل الحالة التي يتوقّف فيها جهاز طرفيّ تحت سلامة الذاكرةحدِّد برنامج التشغيل المحظور في سجلّ CodeIntegrity Operational؛ الاستجابة السليمة هي التحديث إلى إصدار متوافق مع HVCI، واسأل البائع إن لم يوجد، وعامل التعطيل ملاذاً أخيراً لا تجعله دائماًنعملايتوقّف جهاز بعد تفعيل سلامة الذاكرةحدِّد برنامج التشغيل المحظور في سجلّ CodeIntegrityهل ثمّة برنامج تشغيل متوافق مع HVCI؟حدِّث وحُلّ مع إبقاء HVCI مفعَّلاًاطلب من البائع إصداراً متوافقاًالتعطيل ملاذ أخير، لا إعداد دائم

الشكل 10: أوّل ما يُنظَر إليه ليس شاشة الإعدادات بل السجلّ، ومعرِّف الحدث 3087 يعرف من حظر التحميل.

5. Credential Guard ── التجزئات داخل LSAIso

5.1. LSASS وLSAIso

ثاني ميزة ممثِّلة تجلس على VBS هي جواب لغز الافتتاح: Credential Guard.

كان Windows التقليديّ يحتفظ بتجزئات NTLM وتذاكر Kerberos في ذاكرة عمليّة LSA (lsass.exe). عندما يُفعَّل Credential Guard، ينتقل تخزين الأسرار المحميّة من هذه ── تجزئات NTLM لبيانات اعتماد المجال وتذاكر Kerberos TGT (Ticket Granting Tickets) ── إلى LSAIso.exe، trustlet يعمل في IUM في VTL1.6

  • يواصل lsass.exe (VTL0) العمل مكتب استقبال لمعالجة المصادقة، كما كان.
  • يحتفظ LSAIso.exe (VTL1) بالأسرار الفعليّة ولا يمكن الوصول إليها من VTL0.
  • يتواصل الاثنان عبر RPC (Remote Procedure Call).
  • لا يؤوي LSAIso أيّ برامج تشغيل أجهزة على الإطلاق، ويؤوي الحدّ الأدنى فقط من الملفّات الثنائيّة الموقَّعة. تُتحقَّق التوقيعات بشهادة يثق بها VBS.6
أين تجلس بيانات الاعتماد عندما يُفعَّل Credential Guardيتواصل lsass في VTL0 مع LSAIso في VTL1 عبر RPC بوصفه مكتب استقبال المصادقة؛ تحتفظ LSAIso بالتجزئات وTGT الفعليّة لبيانات اعتماد المجال المحميّة، لذا مهاجم يحصل على صلاحيّات مسؤول في VTL0 ويفرِّغ lsass ما زال لا يحصل على الجوهر المحميّVTL1VTL0RPCتفريغ ذاكرةلا يصلLSAIso.exe（خزنة الأسرار）lsass.exe（مكتب استقبال المصادقة）مهاجم（صلاحيّات مسؤول）

الشكل 11: لأنّ مكتب الاستقبال والخزنة فُصلا، لم يعد تفريغ lsass يعطي التجزئات الفعليّة لبيانات اعتماد المجال المحميّة.

من Windows 11 الإصدار 22H2 فصاعداً، على الأجهزة التي تستوفي متطلّبات الترخيص (Enterprise E3/E5 وEducation A3/A5) ومتطلّبات العتاد، يُفعَّل VBS وCredential Guard افتراضيّاً. على إصدارات مثل Pro، لا يُفعَّل Credential Guard تلقائيّاً (ثمّة استثناءات، مثل عندما يُخفَّض لاحقاً جهاز كان مفعَّلاً تحت ترخيص مؤهِّل).7 «لم يعد السيناريو يعمل» في الافتتاح ليس قصّة عن منتج إضافيّ خاصّ؛ إنّه الحالة القياسيّة لـ Windows الحاليّ على الإصدارات المستهدَفة.

تدفّق بيانات الاعتماد من تسجيل الدخول إلى المصادقةبعد تسجيل الدخول تُخزَّن الأسرار الفعليّة في LSAIso في VTL1؛ في كلّ مرّة تُحتاج مصادقة، يطلب lsass في VTL0 الحساب عبر RPC، وتعود نتيجة معالجة المصادقة فقط إلى VTL0 دون إعادة الأسرار طويلة الأمد المحميّة نفسهااطلب الحساب عبر RPCيُرجع النتيجة（لا يُرجع السرّ）يسجِّل المستخدم الدخوليعالجه lsass مكتب استقبالتُخزَّن الأسرار الفعليّة في LSAIsoطلبات مصادقة لاحقة

الشكل 12: الأسرار طويلة الأمد المحميّة نفسها لا تغادر الخزنة قطّ؛ ما يعود إلى VTL0 هو نتيجة معالجة المصادقة، مثل تذكرة.

5.2. اعرف بدقّة ما ليس محميّاً

Credential Guard ليس درعاً لكلّ غرض. ما يُحمى هو تجزئات NTLM لبيانات اعتماد المجال، وتذاكر Kerberos TGT (Ticket Granting Tickets)، وأشياء مخزَّنة بوصفها بيانات اعتماد مجال. التالي خارج النطاق.8

  • تذاكر خدمة Kerberos (تُحمى TGT)
  • بيانات اعتماد الحسابات المحلّيّة وحسابات Microsoft
  • سرقة الإدخال عبر keylogger، والهجمات الفيزيائيّة
  • بيانات الاعتماد على مسارات تستخدم NTLMv1 أو MS-CHAPv2 أو Digest أو CredSSP
  • دواخل برمجيّات طرف ثالث تدير بيانات الاعتماد بنفسها

كذلك، عندما يُفعَّل Credential Guard، يصبح NTLMv1 وتفويض Kerberos غير المقيَّد وما شابه غير قابل للاستخدام، لذا تحتاج أنظمة الأعمال التي تعتمد على مصادقة تراثيّة فحص توافق.8 ليس «فعِّله وانتهيت»، بل أمسك ما داخل نطاق الدفاع وما خارجه واملأ الباقي بضوابط أخرى ── تلك هي الطريقة الصحيحة لاستخدامه في العمل.

نطاق دفاع Credential Guardتجزئات NTLM للمجال وTGT، وبيانات اعتماد المجال المخزَّنة، محميّة، بينما تذاكر الخدمة والحسابات المحلّيّة وkeylogger والهجمات الفيزيائيّة وبيانات الاعتماد التي يخزِّنها تطبيق خاصّة به خارج النطاقفي أيّ جانب من حدّ الحماية يقع هذا السرّ؟تجزئات NTLM للمجال وTGTتذاكر خدمة وحسابات محلّيّةمحميّ في LSAIsoغير محميّ（تُحتاج ضوابط أخرى）ضغطات المفاتيح والهجمات الفيزيائيّة ومخازن التطبيقات الخاصّة أيضاً خارج النطاق

الشكل 13: نطاق الدفاع مرسوم بخطّ واضح، وخارج الخطّ يُملأ بمصادقة متعدّدة العوامل وتصميم جانب التطبيق.

6. انظر بنفسك

يمكنك تأكيد حالة تشغيل VBS وكلّ ميزة على جهازك.

Get-CimInstance -Namespace root/Microsoft/Windows/DeviceGuard `
    -ClassName Win32_DeviceGuard |
    Select-Object VirtualizationBasedSecurityStatus,
                  SecurityServicesConfigured,
                  SecurityServicesRunning

كيفيّة القراءة كالتالي.9

  • إذا كان VirtualizationBasedSecurityStatus 2، فـ VBS مفعَّل ويعمل.
  • إذا احتوى SecurityServicesRunning على 1، يعمل Credential Guard؛ وإذا احتوى على 2، تعمل سلامة الذاكرة (HVCI).

لتأكيد حالة التشغيل في الواجهة الرسوميّة، انظر إلى حقل «Virtualization-based security» في msinfo32 (تُدرَج الخدمات التي تعمل، مثل «Hypervisor enforced Code Integrity»). مفتاح «سلامة الذاكرة» تحت «أمان الجهاز > عزل النواة» في تطبيق أمان Windows شاشة تعكس الإعدادات؛ يمكن أن يبدو مفعَّلاً بينما HVCI لا يعمل فعليّاً ── في انتظار إعادة تشغيل بعد التفعيل مباشرةً، أو مشكلة توافق عند البدء ── فاحكم على ما إذا كان يعمل من msinfo32 أو من SecurityServicesRunning في Win32_DeviceGuard.5

ثمّة أيضاً أثر في علامة تبويب التفاصيل في مدير المهام. على جهاز يعمل فيه VBS سترى عمليّة تُسمَّى «Secure System». LsaIso.exe هي العمليّة التي تظهر عندما تُستضاف خدمة Isolated LSA في VTL1، ولا تظهر عادةً في تكوين يُفعَّل فيه HVCI فقط. وجود عمليّة أو غيابها أثر فقط، فاحكم على ما إذا كان Credential Guard يعمل من SecurityServicesRunning (ما إذا احتوى على 1)، كما أعلاه. كلاهما نافذتان مرئيّتان من VTL0 تقابلان عالم جانب VTL1.

كيفيّة فحص أنّ الميزات المرتبطة بـ VBS تعملأكِّد أنّ VBS يعمل بالاستعلام عن Win32_DeviceGuard، واحكم على Credential Guard وHVCI من قيم SecurityServicesRunning، وانظر إلى سجلّ CodeIntegrity لمشكلات برامج التشغيللانعم12Win32_DeviceGuardحالة VBS 2؟VBS لا يعمليحتوي 1 أو 2؟Credential Guard يعملHVCI يعملCodeIntegrity 3087

الشكل 14: يتقدّم تأكيد الحالة على ثلاث مراحل: VBS نفسه، وكلّ خدمة فوقه، والسجلّ عند حدوث مشكلة.

7. ثلاثة قراءات خاطئة تجنَّبها في العمل

7.1. «حماية صلاحيّات المسؤول تكفي. VBS قصّة جانب خادم»

ما يمنعه Credential Guard هو انتشار الضرر بعد أخذ صلاحيّات المسؤول (إخراج التجزئات والحركة الأفقيّة). بعبارة أخرى VBS طبقة من الدفاع في العمق تفترض الاختراق، وهي على حواسيب العملاء فعّالة. على Windows 11 الذي يستوفي المتطلّبات، التفعيل الافتراضيّ هو القياسيّ، لذا الوضعيّة الصحيحة ليست «هذا لا شأن له بنا» بل «أدِر التوافق على افتراض أنّه يعمل أصلاً».

مراحل الاختراق وأين يسري VBSيغطّي الوصول الأوّليّ ضوابط أخرى مثل المصادقة متعدّدة العوامل والتدريب؛ يحظر HVCI حقن الشيفرة في النواة بعد تصعيد الامتياز؛ يحظر Credential Guard سرقة أسرار المجال المحميّة والحركة الأفقيّة، لكن لا يصل إلى أسرار خارج نطاقهوصول أوّليّ（تصيّد وما شابه）تصعيد امتيازحقن شيفرة في النواةسرقة أسرار المجال المحميّة والحركة الأفقيّةMFA والتدريب وEDR يغطّون هذاHVCI يحظر هذه الخطوةCredential Guard يحظر هذا（الأسرار المحميّة فقط）

الشكل 15: VBS ليست تقنيّة «لا تدعهم يدخلون»؛ إنّها تقنيّة «لا تدعهم يفوزون بعد أن دخلوا»، والمرحلة التي تحرسها مختلفة.

7.2. «إذا تسبّبت سلامة الذاكرة في مشكلة، عطِّلها فحسب»

تعطيلها سيجعل الأمور تعمل للحظة، لكنّه يُسقط الحاجز ضدّ حقن الشيفرة في النواة جملة. الاستجابة السليمة هي أوّلاً تحديد برنامج التشغيل المحظور في سجلّ CodeIntegrity وتطبيق الإصدار المحدَّث من البائع. حتّى إن عطَّلتَه مؤقّتاً للتحقّق، نوصي بتشغيل لا يجعل ذلك إعداداً دائماً.

7.3. «مع Credential Guard، لا يمكن سرقة كلمات المرور»

ذلك ثقة زائدة من الخلط بين نطاق الدفاع. تذاكر الخدمة والحسابات المحلّيّة وضغطات المفاتيح نفسها وبيانات الاعتماد التي يخزِّنها تطبيق خاصّة به خارج النطاق.8 يحتاج التصيّد وkeylogger ضوابط أخرى (مصادقة متعدّدة العوامل، وWindows Hello، ومراجعة إدارة بيانات الاعتماد في جانب التطبيق).

8. الخلاصة

  • يستخدم VBS الـ hypervisor لإنشاء بيئة معزولة ويحمي الميزات الأمنيّة على افتراض أنّ النواة يمكن اختراقها.1
  • وحدة العزل هي VTL؛ حالياً مستويان منفَّذان، VTL0 (العالم العاديّ) وVTL1 (النواة الآمنة وIUM).2
  • جوهر الحدّ هو حماية وصول ذاكرة SLAT، التي لا تستطيع برمجيّات داخل القسم ── بما فيها النواة ── تغييرها.2
  • يشغِّل HVCI التحقّق من سلامة الشيفرة في البيئة المعزولة ويفرض «غير قابل للتنفيذ حتّى يجتاز التحقّق» و«صفحة قابلة للتنفيذ ليست قابلة للكتابة».4 الثمن هو أنّك تحتاج إدارة توافق برامج التشغيل.5
  • يعزل Credential Guard تجزئات NTLM لبيانات اعتماد المجال وTGT في LSAIso في VTL1. من Windows 11 22H2 فصاعداً يُفعَّل افتراضيّاً على الأجهزة التي تستوفي متطلّبات الترخيص (Enterprise وEducation) ومتطلّبات العتاد (استخدم هذا مع فحص حالة التشغيل).67
  • يمكنك تأكيد حالة التشغيل من SecurityServicesRunning في Win32_DeviceGuard (1 = Credential Guard، 2 = HVCI).9

يتواصل في الجزء 3، «آلات افتراضيّة تقلع في ثوانٍ ── WSL2 وWindows Sandbox والحاويات».

حتّى الآن نظرنا إلى الافتراضيّة من جانب «قوّة العزل». ينظر الجزء الأخير من الجانب المقابل، «الخفّة»، ويتتبّع أين تقتصد الآلات الافتراضيّة الخفيفة التي تخلّت عن ثقل آلة افتراضيّة كاملة.

مقالات ذات صلة

مجالات الاستشارة ذات الصلة

تتعامل شركة كومورا سوفت ذ.م.م. مع تحقيقات التوافق بين تطبيقات Windows وميزات الأمان، وتحليل الأعطال الناتجة عن برامج التشغيل، والتحقّق التقنيّ لبيئات الحواسيب الداخليّة.

روابط مرجعيّة

  1. Microsoft Learn, Virtualization-based Security (VBS). حول استخدام VBS الافتراضيّة العتاديّة وhypervisor Windows لإنشاء بيئة معزولة ومعاملتها جذر ثقة نظام التشغيل على افتراض أنّ النواة يمكن اختراقها؛ وتشغيل سلامة الذاكرة التحقّق من سلامة شيفرة وضع النواة داخل تلك البيئة المعزولة؛ وكون SLAT متطلَّباً صارماً لـ VBS. ↩ ↩2 ↩3

  2. Microsoft Learn, Virtual Secure Mode. حول كون VSM أساساً لـ Device Guard وCredential Guard وTPM افتراضيّ وما شابه؛ والتحكّم بالوصول إلى المناطق المعزولة عبر الـ hypervisor فقط وحمايتها حتّى من برمجيّات نظام تشغيل الحلقة 0؛ وكون VTL هرميّة مع تنفيذ مستويين من حدّ أقصى 16؛ وكون حمايات وصول الذاكرة لكلّ VTL غير قابلة للتغيير من برمجيّات النظام داخل القسم. ↩ ↩2 ↩3 ↩4 ↩5

  3. Microsoft Learn, Isolated User Mode (IUM) Processes. حول إنشاء VSM لـ VTL باستخدام hypervisor Hyper-V وSLAT؛ وعمل النواة الآمنة وIUM في VTL1؛ وتجميع trustlets استدعاءات النظام إلى نواة VTL0؛ وعمل LSAIso في VTL1 وتواصله مع lsass عبر RPC. ↩ ↩2 ↩3

  4. Microsoft Learn, Memory integrity and virtualization-based security. حول تشغيل سلامة الذاكرة (HVCI) التحقّق من سلامة الشيفرة في بيئة معزولة، وحول تصبح صفحات ذاكرة النواة قابلة للتنفيذ فقط بعد اجتياز التحقّق وعدم تصبح الصفحات القابلة للتنفيذ قابلة للكتابة. ↩ ↩2 ↩3

  5. Microsoft Learn, Memory integrity and VBS enablement. حول تفعيل سلامة الذاكرة افتراضيّاً عند تثبيت نظيف لـ Windows 11 إن كان العتاد متوافقاً؛ وتأكيد الحالة في msinfo32 وتطبيق أمان Windows؛ وتأكيد برنامج تشغيل محظور عبر معرِّف الحدث 3087 في سجلّ CodeIntegrity Operational. ↩ ↩2 ↩3

  6. Microsoft Learn, How Credential Guard works. حول تواصل LSA مع عمليّة Isolated LSA (LSAIso.exe) لتخزين الأسرار عندما يُفعَّل Credential Guard؛ وحماية البيانات المخزَّنة بـ VBS وتعذّر الوصول إليها من بقيّة نظام التشغيل؛ وعدم إيواء عمليّة Isolated LSA أيّ برامج تشغيل أجهزة وإيوائها الحدّ الأدنى فقط من الملفّات الثنائيّة المتحقَّق من توقيعها. ↩ ↩2 ↩3

  7. Microsoft Learn, Credential Guard overview. حول تفعيل Credential Guard افتراضيّاً من Windows 11 الإصدار 22H2 فصاعداً على الأجهزة التي تستوفي متطلّبات الترخيص والعتاد والبرمجيّات ولم تُعطَّل صراحةً؛ وكون الإصدارات/التراخيص المؤهِّلة Enterprise (E3/E5) وEducation (A3/A5)، مع خروج Pro عن النطاق؛ وبقاء جهاز Pro كان مفعَّلاً سابقاً تحت ترخيص مؤهِّل هدفاً للتفعيل الافتراضيّ بعد التخفيض. ↩ ↩2

  8. Microsoft Learn, Credential Guard protection limits. حول خروج تذاكر الخدمة والحسابات المحلّيّة وkeylogger والهجمات الفيزيائيّة وما شابه عن نطاق حماية Credential Guard؛ وحماية TGT بينما تذاكر الخدمة ليست كذلك؛ وتصبح NTLMv1 والتفويض غير المقيَّد غير قابلين للاستخدام عند التفعيل. ↩ ↩2 ↩3

  9. Microsoft Learn, Enable virtualization-based protection of code integrity. حول كيفيّة تأكيد حالة VBS وسلامة الذاكرة عبر صنف Win32_DeviceGuard، وحول معنى قيم SecurityServicesRunning (1 هو Credential Guard، 2 هو سلامة الذاكرة). ↩ ↩2

مقالات ذات صلة

أحدث المقالات التي تشترك في نفس الوسوم. عمّق فهمك بمواضيع مرتبطة.

أين يتصل هذا الموضوع

ترتبط هذه المقالة بشكل طبيعي بصفحات الخدمات التالية.

الأسئلة الشائعة

أسئلة شائعة حول موضوع هذه المقالة.

هل VBS（الأمان المستند إلى الافتراضيّة）وعزل النواة（Core isolation）الشيء نفسه؟
بالمعنى الدقيق، هما مختلفان. VBS هي التقنيّة الأساسيّة التي تنشئ بيئة معزولة بالـ hypervisor، و«عزل النواة» في تطبيق أمان Windows هو اسم شاشة تجمع عدّة حمايات مبنيّة على VBS. الممثِّل هو «سلامة الذاكرة»، الذي يشير إلى HVCI（سلامة الشيفرة المحميّة بالـ hypervisor）. أكِّد حالة تشغيل كلّ خدمة بالاستعلام عن Win32_DeviceGuard، لا من عرض الشاشة.
هل يمكن حقّاً ألا تُقرأ ذاكرة VTL1، حتّى بصلاحيّات مسؤول أو من برنامج تشغيل نواة؟
لا يمكن. حمايات وصول الذاكرة لكلّ VTL يديرها الـ hypervisor مقابل فضاء العنوان الفيزيائيّ للقسم، ولا تستطيع البرمجيّات العاملة داخل القسم تغييرها. حتّى الشيفرة التي تعمل في النواة（الحلقة 0）غير مسموح لها بالوصول إلى ذاكرة VTL1 من VTL0.
لماذا يمكن لتفعيل سلامة الذاكرة（HVCI）إيقاف برنامج تشغيل عن العمل؟
في بيئة HVCI، تصبح صفحة نواة قابلة للتنفيذ فقط بعد أن تجتاز التحقّق من السلامة، ولا يُسمَح بالكتابة إلى صفحات قابلة للتنفيذ. برنامج تشغيل بلا توقيع، أو برنامج تشغيل بتصميم أقدم يعيد كتابة ذاكرة قابلة للتنفيذ، لا يستطيع استيفاء هذا القيد ويُحظَر تحميله. يمكنك تأكيد الحظر في سجلّ CodeIntegrity Operational（معرِّف الحدث 3087 وما شابه）.
ماذا يحمي Credential Guard، وماذا لا يحمي؟
يحمي تجزئات كلمات مرور NTLM لبيانات اعتماد المجال، وتذاكر Kerberos TGT، وأشياء خزَّنها تطبيق بوصفها بيانات اعتماد مجال، في بيئة معزولة. تذاكر خدمة Kerberos، وبيانات اعتماد الحسابات المحلّيّة وحسابات Microsoft، وسرقة الإدخال عبر keylogger، والهجمات الفيزيائيّة خارج النطاق.
أين يمكنني فحص ما إذا كان VBS يعمل؟
انظر إلى حقل «Virtualization-based security» في msinfo32، أو استعلم عن صنف Win32_DeviceGuard في مساحة الأسماء root/Microsoft/Windows/DeviceGuard من PowerShell. إذا احتوى SecurityServicesRunning على 1، يعمل Credential Guard؛ وإذا احتوى على 2، تعمل سلامة الذاكرة（HVCI）.

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

يركّز على تطوير برامج ويندوز، والاستشارات التقنية، والتحقيق في الأخطاء، ويتميّز في المشاريع التي تبقى فيها الأصول القديمة ناشطة، وفي تشخيص الأعطال التي يصعب تحديد سببها.

تواصل معنا
العودة إلى المدونة