التحديث الذي لا يمكنك تجاهله: انتهاء دعم Office 2016 و Office 2019

اقرأ الآن
نستخدمُ الذكاء الاصطناعي في ترجمات الموقع، ومع أننا نسعى جاهدين لبلوغ الدقة قد لا تكون هذه الترجمات دقيقةً بنسبة 100% دائمًا. تفهّمك لهذا الأمر هو موضع تقدير لدينا.

CVE-2025-50154: المصادقة NTLM القسرية عبر معالجة اختصارات مستكشف Windows

ب OPSWAT
شارك هذا المنشور

ملخص

CVE-2025-50154 هي ثغرة أمنية في مستكشف ملفات Windows يمكن أن تعرض مواد المصادقة الحساسة عبر الشبكة. تصنف Microsoft هذه المشكلة على أنها انتحال، مع ربط الضعف الأساسي بـ CWE-200 (كشف المعلومات الحساسة).

في التكوينات المتأثرة، قد يبدأ Windows Explorer مصادقة الشبكة أثناء معالجة البيانات الوصفية المتعلقة بالاختصارات. إذا كانت الوجهة البعيدة المشار إليها خاضعة لسيطرة المهاجم، فقد يتمكن المهاجم من التقاط مواد التحدي والاستجابة NTLM. والتي، اعتمادًا على ضوابط الأمان في المؤسسة، يمكن أن تتيح إساءة الاستخدام اللاحقة مثل ترحيل NTLM أو تخمين كلمة المرور في وضع عدم الاتصال.

في هذا المدونة، نستكشف CVE-2025-50154 استنادًا إلى الأبحاث التي أجراها طلاب الدراسات العليا المشاركون في برنامج زمالة OPSWAT ، ونقدم إرشادات عملية للتخفيف من مخاطر المصادقة NTLM القسرية.

التأثير والمخاطر

تم الكشف عن CVE-2025-50154 في 12 أغسطس 2025، ويؤثر على العديد من إصدارات عملاء وخوادم Windows المدعومة ( Server Windows 10/11 و Windows Server ) قبل مستويات البنية الثابتة. تم تصنيف الثغرة الأمنية CVSS v3.1 6.5 (متوسطة).

النتيجة الأمنية الأساسية هي كشف بيانات الاعتماد: قد يحصل المهاجم على مواد التحدي والاستجابة NTLM عن طريق جعل Explorer يقوم بالمصادقة على نقطة نهاية يسيطر عليها المهاجم. اعتمادًا على البيئة، يمكن استخدام هذا في:

ترحيل NTLM (التزوير): المصادقة على الخدمات الأخرى الخدمات الضحية في حالة عدم وجود حماية الترحيل أو في حالة تكوينها بشكل خاطئ.

تخمين/اختراق كلمات المرور دون اتصال بالإنترنت: محاولة استعادة كلمات المرور الضعيفة من مواد التحدي والاستجابة الملتقطة.

تعتمد الجدوى بشكل كبير على ضوابط المؤسسة مثل توقيع SMB وقيود NTLM وتجزئة الشبكة وتقوية جانب الخدمة.

سيناريو الهجوم

CVE-2025-50154 هي مشكلة تتعلق بالمصادقة القسرية. عندما يعالج Windows Explorer اختصارًا يشير إلى موقع SMB/UNC بعيد، فقد يبدأ اتصال SMB أثناء العرض العادي أو التحقق من صحة المسار. ونتيجة لذلك، يمكن أن تتلقى نقطة النهاية البعيدة مواد تبادل المصادقة NTLM التي تم إنشاؤها أثناء إعداد الجلسة.

فيما يلي سيناريو هجوم نموذجي:

  1. تجهيز المهاجم: يتحكم الخصم في خادم SMB ويجهز مشاركة مشار إليها بواسطة الاختصار.
  2. وضع الاختصار: يتم تسليم ملف .lnk يشير إلى مسار SMB الذي يتحكم فيه المهاجم إلى بيئة الضحية عبر قنوات شائعة (على سبيل المثال، مرفقات التصيد الاحتيالي، المجلدات المتزامنة، مستودعات الملفات المشتركة، أو موطئ قدم موجود).
  3. الوصول الذي يتم تشغيله بواسطة المستكشف: عندما يتصفح الضحية دليلًا يحتوي على الاختصار، يقوم مستكشف Windows بتحليل بيانات الاختصار وقد يحاول حل الهدف البعيد كجزء من معالجة واجهة المستخدم الروتينية.
  4. المصادقة الضمنية: أثناء إعداد جلسة SMB، يقوم Windows بالمصادقة في سياق المستخدم (غالبًا عبر NTLM). لا يحتاج الضحية إلى تنفيذ هدف الاختصار حتى تتم عملية تبادل المصادقة.
  5. نتائج ما بعد الاستيلاء (تعتمد على البيئة): اعتمادًا على ضوابط البيئة، يمكن الاستفادة من المواد NTLM التي تم الاستيلاء عليها في ترحيل NTLM أو فك تشفير كلمات المرور في وضع عدم الاتصال. تتأثر الجدوى العملية بعوامل مثل توقيع SMB وقيود NTLM وتجزئة الشبكة.

الخلفية التقنية

مستكشف Windows وعرض الاختصارات

Windows Explorer (explorer.exe) هو عملية Windows shell التي تقوم بتعداد محتويات الدليل وعرض واجهة مستخدم File Explorer، واستدعاء مكونات Shell (مثل معالجات الرموز/التراكب/الصور المصغرة) للحصول على الرموز والتراكبات والصور المصغرة وعرضها.

اختصار Windows (.lnk) ليس مجرد مؤشر نصي بسيط؛ إنه تنسيق بيانات وصفية منظم يمكنه تخزين مسار الهدف (مسار محلي أو مسار UNC/SMB) وحجج اختيارية ودليل عمل ومرجع رمز منفصل. أثناء تصفح المجلدات العادي، يقوم Explorer بتحليل بيانات الاختصار الوصفية لعرض الاختصار في واجهة المستخدم (على سبيل المثال، تحديد الرمز والتحقق من صحة الهدف). اعتمادًا على الهدف المشار إليه والبيانات الوصفية ذات الصلة، قد تؤدي هذه المعالجة إلى محاولة Explorer الوصول إلى الشبكة كجزء من العرض الروتيني أو التحقق من المسار.

مصادقة NTLM عبر SMB

في مشاركة الملفات في Windows، تفضل مصادقة SMB عادةً Kerberos في بيئات المجال، ولكن لا يزال من الممكن التفاوض على NTLM عندما يكون Kerberos غير متاح أو غير محدد. NTLM هو بروتوكول التحدي والاستجابة: يقوم العميل أولاً بالإعلان عن القدرات، ثم يرد الخادم بتحدي (nonce)، ويستجيب العميل برسالة مصادقة مشتقة من التحدي وسر المستخدم - دون إرسال كلمة المرور النصية العادية.

متغيرات NTLM وموقف الأمان (NTLMv1 مقابل NTLMv2)

يوجد العديد من المتغيرات لـ NTLM. تعتمد بيئات Windows الحديثة بشكل عام على NTLMv2 ويجب تجنب استخدام LM/NTLMv1 القديم حيثما أمكن ذلك.

أصبح NTLMv1 معروفًا على نطاق واسع باعتباره غير آمن لعدة أسباب رئيسية (تشفير ضعيف، مفاتيح إنتروبيا منخفضة، ضعف الترحيل، خطر الاختراق دون اتصال بالإنترنت، إلخ). 

لتحسين هذا الأمر، قدمت Microsoft NTLMv2، الذي يعزز حساب الاستجابة. في الممارسة العملية، يستبدل NTLMv2 بناء الاستجابة القديم من نوع DES بنظام قائم على HMAC-MD5 ويدمج سياقًا إضافيًا في الاستجابة، مما يجعله أكثر قوة بكثير من NTLMv1 في مواجهة عدة فئات من تقنيات الاسترداد دون اتصال.

حتى مع NTLMv2، يجب على المؤسسات أن تعامل NTLM كبروتوكول مصادقة عالي المخاطر مقارنة بـ Kerberos وتطبق ضوابط دفاعية متعمقة (مثل توقيع SMB والتجزئة) لتقليل نطاق تأثير سيناريوهات المصادقة القسرية.

لماذا يظل NTLM هدفًا متكررًا

على الرغم من أن NTLM هو بروتوكول تحدي-استجابة، إلا أنه لا يزال جذابًا للمهاجمين لأن تبادل المصادقة قابل للاستخدام مباشرة في ظروف الشبكة المعادية. أثناء إعداد جلسة SMB، تتلقى نقطة النهاية البعيدة بيانات التعريف الخاصة بالمصادقة وقيم التحدي والاستجابة المطلوبة لمصادقة العميل. إذا تمكن الخصم من تشغيل نقطة النهاية الوجهة (على سبيل المثال، خادم SMB يتحكم فيه المهاجم) أو تمكن من اعتراض/إنهاء الاتصال أثناء النقل، فقد يتمكن من التقاط مواد تبادل NTLM ومحاولة إساءة الاستخدام اللاحقة مثل ترحيل NTLM أو تخمين كلمة المرور دون اتصال، اعتمادًا على حماية البيئة.

كما يدمج Windows NTLM في تجربة تسجيل الدخول الأحادي (SSO). تدير LSASS بيانات الاعتماد المستمدة من سر المستخدم ويمكن استخدامها للمصادقة على موارد الشبكة (على سبيل المثال، مشاركات SMB) دون مطالبة المستخدم بشكل متكرر. في حين أن هذا يحسن قابلية الاستخدام، إلا أنه يوسع نطاق الهجوم لسيناريوهات المصادقة القسرية: عندما يشير اختصار .lnk إلى مسار SMB بعيد، قد يبدأ Windows Explorer اتصال SMB أثناء معالجة الاختصار الروتينية ويتفاوض تلقائيًا على المصادقة.

في سياق CVE-2025-50154، هذا يعني أن مواد تبادل المصادقة NTLM قد يتم إرسالها إلى نقطة نهاية SMB يسيطر عليها المهاجم دون أن يقوم الضحية بتنفيذ الهدف المشار إليه، مما يخلق مسارًا صامتًا لكشف بيانات الاعتماد أثناء تصفح المجلدات العادي.

التحليل الفني

عرض رمز المستكشف ومعالجة الاختصارات

عندما يتم فتح مجلد في مستكشف الملفات، يقوم المستكشف بتعداد محتويات الدليل وتحديد نوع كل عنصر بناءً على ارتباط الملف المسجل (عادةً ما يتم تحديده بواسطة امتداد الملف). ثم يستخدم Windows تسجيل فئة shell المقابلة (على سبيل المثال، عبر تعيينات CLSID/ProgID المرتبطة في السجل) لتحديد موقع معالج shell المناسب - وهو عادةً مكون COM مسؤول عن استخراج الرمز وعرضه. يستدعي المستكشف الواجهات ذات الصلة لاسترداد الرمز وعرضه.

بالنسبة لملفات .lnk (Shell Link)، لا يعرض Explorer عادةً رمز اختصار عام بشكل افتراضي. بدلاً من ذلك، يقوم بتحليل بيانات الاختصار، ويحاول تحديد الهدف المشار إليه (ومعلومات الرمز ذات الصلة)، ثم يعرض الرمز المرتبط بهذا الهدف المحدد.

عندما يقوم Explorer بعرض ملف .lnk، فإنه يحدد الرمز عن طريق استدعاء CShellLink::GetIconLocation، الذي يحدد المكان الذي يجب تحميل الرمز منه (على سبيل المثال، الثنائي الهدف، أو مسار رمز صريح، أو رمز نظام افتراضي). كجزء من هذا التدفق، يقوم Explorer بتهيئة استخراج الرمز (_InitExtractIcon) ثم ينفذ منطق الدقة الأساسي (_GetExtractIcon)، الذي يقيّم مصدر الرمز (عبر _CheckExtractLocation).

• إذا كان الاختصار يحدد موقع رمز محلي (على سبيل المثال، ملف قابل للتنفيذ أو مكتبة DLL على القرص)، يقوم Explorer بتحميل الرمز مباشرة من هذا المورد.

• إذا كان موقع الرمز هو عنوان URL بعيد، فقد يقوم Explorer بتنزيل الرمز إلى ذاكرة التخزين المؤقتة المحلية (على سبيل المثال، باستخدام URLDownloadToCacheFileW) ثم تحميل الرمز من النسخة المخزنة في ذاكرة التخزين المؤقتة.

• إذا لم يتوفر مصدر أيقونة صالح، يعود Explorer إلى أيقونة افتراضية مقدمة من معالج النظام.

بعد حل البيانات الوصفية المتعلقة بالرموز، ينتقل Explorer إلى CShellLink::Extract، الذي يتعامل مع هدف الاختصار ويكمل سير عمل الاستخراج. كجزء من هذا المسار، يستدعي Explorer CShellLink::_ShortNetTimeout لتطبيق مهلة شبكة أقصر عندما يشير الاختصار إلى موقع بعيد، مما يقلل من تأخيرات واجهة المستخدم إذا كان هدف الشبكة بطيئًا أو غير قابل للوصول.

عندما يتم تحديد الهدف على أنه مسار شبكة (UNC)، يقوم Explorer بتنفيذ التحقق من صحة الهدف بشكل غير متزامن. ويقوم بإنشاء مؤشر ترابط عامل يقوم بتشغيل CShellLink::_VerifyPathThreadProc، الذي يتحقق من وجود الهدف المشار إليه.

ضمن هذا الروتين، يستدعي Explorer PathFileExistsAndAttributesW للاستعلام عن وجود الهدف وسماته الأساسية (مثل الملف مقابل الدليل)، الأمر الذي يتطلب بدوره محاولة الوصول إلى الشبكة لأهداف SMB/UNC.

السبب الجذري للضعف

في سياق عملية عرض الاختصارات الموضحة أعلاه، هناك عمليتان خارجيتان ذاتا صلة:

• استرداد الرمز عبر URLDownloadToCacheFileW (عندما يكون مصدر رمز الاختصار هو عنوان URL بعيد).

• التحقق من صحة الهدف عبر PathFileExistsAndAttributesW (عندما يكون هدف الاختصار مسار UNC/SMB).

للتحقق من صحة سلوك URLDownloadToCacheFileW، قمنا بتجربة واجهة API اختبار بسيط ومستقل.

تألف نشاط الشبكة من عملية جلب HTTP تقليدية، ولم تكشف في ملاحظاتنا عن أي معلومات اعتمادية ذات صلة بهذه الثغرة الأمنية.

يحدث السلوك الأكثر أهمية مع PathFileExistsAndAttributesW عندما يكون المسار الذي تم تقييمه هدف UNC/SMB. أثناء التصحيح، لاحظنا أن هذا الفحص يمكن أن يبدأ إعداد جلسة SMB ويتفاوض على المصادقة في سياق المستخدم الحالي.

نظرًا لأن Explorer قد يستدعي هذا التحقق تلقائيًا أثناء معالجة ملف .lnk، يمكن لنقطة نهاية SMB التي يتحكم فيها المهاجم أن تتلقى مواد تبادل مصادقة NTLM دون أن يقوم الضحية بتنفيذ الملف المشار إليه، مما يخلق مسارًا صامتًا لكشف بيانات الاعتماد أثناء تصفح المجلدات الروتيني.

إثبات المفهوم

في مختبر معزول، قام المشاركون في برنامج OPSWAT Fellowship بالتحقق من صحة CVE-2025-50154 باستخدام اختصار (.lnk) يشير إلى مسار SMB/UNC بعيد. على نظام Windows عرضة للخطر، أدى مجرد تصفح المجلد في Windows Explorer إلى تشغيل اتصال SMB أثناء المعالجة العادية للاختصار، مما تسبب في إرسال مواد تبادل المصادقة NTLM إلى نقطة النهاية البعيدة — دون أن يقوم الضحية بتنفيذ هدف الاختصار.

الاصلاح

يجب على المؤسسات التأكد من أن أنظمة التشغيل والتطبيقات الخاصة بها يتم تحديثها بانتظام ومواكبة أحدث الإصدارات لتقليل الثغرات الأمنية المعروفة. ويشمل ذلك تطبيق جميع تحديثات الأمان ذات الصلة من Microsoft والتحقق من أن جميع النقاط الطرفية تعمل بأحدث إصدارات Windows المصححة. وبالتوازي مع ذلك، يجب على المؤسسات تقليل سطح الهجوم من خلال تشديد الوصول إلى SMB الصادر عند الاقتضاء وتعزيز ضوابط تقوية NTLM/SMB بما يتماشى مع بيئتها.

يدعم MetaDefender هذه الجهود ويساعد على تفعيلها على نطاق واسع من خلال توفير رؤية واضحة للمخاطر واستعدادات التصحيحات. بفضل قدراته القوية في إدارة الثغرات الأمنية والتصحيحات التي تدعم أكثر من 1100 تطبيق، يحدد MetaDefender Endpoint نقاط النهاية التي تعمل بإصدارات Windows غير مصححة أو قديمة بالإضافة إلى تطبيقات الجهات الخارجية ويقدم الإصلاحات الموصى بها.

بالإضافة إلى ذلك، من خلال وحدة التحكم الإدارية في My OPSWAT Central Management، يحصل المسؤولون على عرض مركزي وموحد لحالة أمان النقاط الطرفية، والتعرض للثغرات الأمنية، وإدارة التصحيحات، كل ذلك ضمن منصة واحدة لتعريف سياسات الأمان وتطبيقها في جميع أنحاء المؤسسة. يمكن للمسؤولين أيضًا إنشاء ونشر نصوص برمجية مخصصة على نقاط النهايةEndpoint MetaDefender Endpoint لأتمتة إجراءات التعزيز المتعلقة بالوصول إلى SMB واستخدام NTLM. يعمل هذا النهج على تبسيط تطبيق الأمان مع توفير ملاحظات واضحة حول نتائج التنفيذ، مما يسمح للمسؤولين بتحديد نقاط النهاية التي قد تتطلب مزيدًا من التحقيق أو التدخل اليدوي بسرعة.

Endpoint MetaDefender Endpoint لفرق الأمن وتكنولوجيا المعلومات إعطاء الأولوية لعمليات النشر، وتسريع الإصلاح، ومراقبة الوضع الأمني للمؤسسة باستمرار، وفي النهاية تقليل التعرض للثغرات الأمنية الشائعة (CVE) مثل CVE-2025-50154 والتهديدات المماثلة التي تستهدف نقاط النهاية.

العلامات:

ابق على اطلاع دائم OPSWAT!

اشترك اليوم لتلقي آخر تحديثات الشركة, والقصص ومعلومات عن الفعاليات والمزيد.