
معالجة شاملة من البداية إلى النهاية لثغرة CVE-2013-3900 باستخدام PowerShell وTenable. يوضح تحديد الثغرات، وتقوية سجل النظام (Registry)، والتحقق الآلي في بيئة Azure.
يعرض هذا المشروع سير عمل حقيقي لإدارة الثغرات الأمنية. باستخدام جهاز Azure افتراضي، تتبعت ثغرة عالية الخطورة في التحقق من صحة التوقيع، وأكدتها يدوياً عبر PowerShell، ثم طبقت إصلاحاً يعتمد على السجل (Registry) لتحصين النظام ضد تنفيذ تعليمات برمجية غير مصرح بها.
كانت الدالة WinVerifyTrust في ويندوز تحتوي على ثغرة خفية (CVE-2013-3900). يمكن للمهاجمين "التطفل" بتعليمات برمجية خبيثة على ملف موقّع دون كسر التوقيع الرقمي. وهذا يعني أن الملف قد يبدو "موثوقاً" حتى لو كان يحمل تعليمات برمجية خبيثة، مما يسمح له بتجاوز فحوصات الأمان.
بدأت بإجراء فحص Tenable على جهاز Azure الافتراضي الخاص بي (المضيف: Kaddy). أشار الفحص إلى ثغرة بخطورة "عالية" (VPR 9.0) لأن النظام كان يفتقر إلى إعداد أمان محدد يُسمى EnableCertPaddingCheck.

لم أعتمد على كلام الماسح الضوئي فقط. استخدمت PowerShell للتحقق من وجود مفتاح السجل فعلياً
powershell Get-ItemProperty -Path "HKLM:\Software\Microsoft\Cryptography\Wintrust\Config" -Name EnableCertPaddingCheck
النتيجة: فشل الأمر مع خطأ "Path does not exist". أكد هذا أن النظام كان مفتوحاً على مصراعيه أمام هذا الاستغلال المحدد.

بدلاً من تعديل السجل يدوياً (RegEdit)، استخدمت برنامج PowerShell النصي لتطبيق الإصلاح. هذا أسرع وأكثر قابلية للتكرار وأكثر أماناً، خاصةً مع مئات الأجهزة.
طبقت الإصلاح على كليهما:
مسار 32-بت (WoW6432Node)

بعد انتهاء البرنامج النصي، أعدت تشغيل فحص التحقق مرة أخرى. كما هو موضح في السجلات النهائية، أصبحت قيمة EnableCertPaddingCheck الآن مضبوطة على 1. يتحقق النظام الآن بصرامة من حشوة الشهادات، مما يغلق الثغرة الأمنية فعلياً.

ما وراء التحديثات: تعلمت أن بعض الثغرات لا تُصلح بمجرد تشغيل "Windows Update". أحياناً عليك أن تتسخ يديك في السجل لتحصين النظام فعلياً.
تحصين السجل: إتقان التعامل مع HKLM عبر PowerShell أمر ضروري لمحترفي الأمن الذين يديرون الأنظمة على نطاق واسع.