CVE-2025-61757: تنفيذ التعليمات البرمجية عن بُعد قبل المصادقة المسبقة في Oracle Identity Manager (خدمات ويب REST WebServices)

يعد نظام Oracle Identity Manager (OIM) نوعًا من الأنظمة التي لا تلاحظها حتى تتعطل. إنه يوفر الهويات، ويدير الاستحقاقات، ويصدر أو يتوسط في الوصول، وغالبًا ما يكون موجودًا في كل تطبيق مؤسسي جاد. عندما تقع ثغرة أمنية في نظام OIM، فإنها نادراً ما تكون "مجرد ثغرة أمنية أخرى". يعد CVE-2025-61757 مثالاً خطيرًا على ذلك: ثغرة في إعادة الإنفاذ غير المصادق عليه والقابل للوصول إلى الشبكة في مكوّن REST WebServices الخاص بـ OIM والذي يمكن أن يؤدي إلى الاستيلاء الكامل على مستوى الهوية. يلخصها NVD بوضوح: الإصدارات المدعومة المتأثرة هي 12.2.2.1.1.4.0 و14.1.2.1.0يتطلب الاستغلال لا توجد مصادقةيحدث على HTTPوالعوائد تسوية عالية التأثير عبر السرية، والنزاهة، والتوافر، مع درجة CVSS 3.1 9.8 (حرجة). (NVD)

ما يجعل هذا CVE يستحق قراءة أعمق من الناحية الهندسية ليس فقط نتيجته ولكن حيث يعيش. منصات الهوية هي جذر الثقة للمؤسسات الحديثة. فالمهاجم عن بُعد الذي ينفذ التعليمات البرمجية على OIM هو على بعد خطوة واحدة من تزوير الهويات، أو التلاعب بتعيينات الأدوار، أو التمحور في مستويات البرامج الوسيطة والتطبيقات المجاورة. بعبارة أخرى, CVE-2025-61757 هو استيلاء بدائي على الهوية، وليس خطأ في التطبيق الضيق.

التحليل العام الأكثر استشهاداً به: سبب نجاح هذه السلسلة

من بين التدوينات المتاحة للجمهور، يُعدّ منشور بحث Searchlight Cyber ("اختراق مدير الهوية من Oracle: استيلاء على المصادقة المسبقة") هو التحليل الأكثر تفصيلاً والأكثر إشارةً إلى CVE-2025-61757، والذي تم ترديده من قبل SANS ومُتتبّعين آخرين. (سايبر البحث في السايبر) إن ادعاءهم الأساسي هو أن الثغرة الأمنية هي سلسلة من مرحلتين:

1. a تجاوز المصادقة المسبقة في مرشح أمان جافا المركزي التي تحمي سطح إدارة REST، و
2. إساءة استخدام وظيفة إدارة إدارية/برمجية ذات امتيازات عالية تعرضها واجهات برمجة تطبيقات REST تلك، وبلغت ذروتها في تنفيذ التعليمات البرمجية عن بُعد. (سايبر البحث في السايبر)

إن آليات الحمولة الدقيقة ليست هي ما يهم المدافعين (ولا ينبغي تكرارها خارج المختبر المعتمد). ما يهم هو النمط: النمط الكلاسيكي "مرشح مركزي + قائمة السماح الهش" تصميم، حيث يتم فرض المصادقة عن طريق مطابقة طلبات URIs مع قائمة بيضاء متساهلة. هذا أمر شائع في تطبيقات Java للمؤسسات في المدرسة القديمة؛ أما من ناحية الأمان، فهو أمر متكرر. إذا كان التحكم في الوصول الخاص بك يعتمد على مطابقة السلسلة أو إعادة التعبير عبر قواعد تحليل URI المعقدة، فأنت تراهن على أن كل يقوم مكون المنبع بتطبيع المسارات بنفس الطريقة. يميل هذا الرهان إلى الخسارة.

تتمثل الطريقة الآمنة لالتقاط شكل السبب الجذري في النظر إلى نسخة مجردة من المنطق:

// كود زائف يوضح النمط المضاد (وليس كود المنتج)
إذا (إذا كان (request.uri.uri.matches(ALLOWLIST_PATTERN) || request.query.equalsIgnoreCase("SPECIAL_CASE")) {
    chain.doFilter(طلب، استجابة)؛ // يتخطى المصادقة
} آخر {
    فرض المصادقة();
}

فبمجرد أن يتمكن المهاجمون من الالتفاف حول بوابة المصادقة، تصبح أي نقطة نهاية قوية للمسؤولين نقطة تنفيذ محتملة. الخلاصة الرئيسية التي توصلت إليها شركة Searchlight ليست "نقطة النهاية المحددة هذه خطيرة"، ولكن "غالبًا ما تتضمن أسطح إدارة REST داخل منتجات IAM تجميع البرامج النصية أو إدارة الموصلات أو خطافات سير العمل مع الثقة الضمنية." عندما يتم كشفها بدون مصادقة، فإنك تحصل على RCE عن طريق التصميم وليس عن طريق الصدفة. (سايبر البحث في السايبر)

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

الإصدارات المتأثرة وسياق التصحيح

قامت Oracle بإصلاح CVE-2025-61757 في تحديث التصحيح الحرج لشهر أكتوبر 2025 (وحدة المعالجة المركزية)صدر في 2025-10-21. (أوراكل) الإصدارات المتأثرة المدعومة التي تم استدعاؤها في متتبعات متعددة هي

يتماشى هذا عبر NVD، وWiz's Wiz's vulnerability DB، وكتابة التعرض لـ runZero. (NVD)

نقطة تشغيلية دقيقة ولكنها مهمة: وحدات المعالجة المركزية من Oracle كل ثلاثة أشهر. تميل الشركات التي ليس لديها وحدة معالجة مركزية محكمة وعضلات طرح وحدات المعالجة المركزية إلى تراكم "ديون التصحيح" في مكدسات الهوية والبرامج الوسيطة لأنه يُنظر إليها على أنها أنظمة مستقرة ومنخفضة التغيير. يكسر CVE-2025-61757 هذا الافتراض. إنه ليس خطأً يمكنك تركه "للربع التالي" إذا كان يمكن الوصول إلى مستوى إدارة REST الخاص بك من شبكات غير موثوق بها.

واقع سطح الهجوم: لماذا سيتم فحص هذا الفيروس المضاد لمكافح التطرف العنيف بسرعة

حتى بدون مناقشة تفاصيل الاستغلال، فإن شكل متجه CVSS يخبرك لماذا تهتم الجهات الفاعلة في مجال التهديدات الآلية. تدرجها NVD وWiz على النحو التالي:

• أ:ن (يمكن الوصول إلى الشبكة),
• ت: ل (منخفضة التعقيد),
• العلاقات العامة: N/UI: N (بدون امتيازات، بدون تفاعل المستخدم),
• C:H/I:H/A:H (تأثير كامل). (NVD)

هذا المزيج هو "الضوء الأخضر" للماسحات الضوئية للسلع. في اللحظة التي يهبط فيها جهاز PoC في القنوات العامة، يصبح بصمة الطلب الواحد + سلسلة المتابعة في شبكات الروبوتات. تميل خوادم الهوية المكشوفة بهدوء من خلال موازنات التحميل التي تم تكوينها بشكل خاطئ أو قواعد NAT القديمة أو ثغرات الدعم عن بُعد لدى البائعين إلى الظهور في عمليات الفحص هذه بسرعة.

لديك أيضًا مشكلة سياق أكبر: لقد كانت البرمجيات الوسيطة من Oracle هدفًا عالي القيمة في عام 2025، مع وجود العديد من الأخطاء الحرجة غير المصادق عليها في المنتجات المجاورة (WebLogic وEBS ووحدات التسويق) التي جعلتها في حملات نشطة. تسلط مراجعة وحدة المعالجة المركزية لشهر أكتوبر من Qualys الضوء صراحةً على أخطاء Fusion Middleware الحرجة باعتبارها مجموعة عالية المخاطر. (كواليس) وهذا يزيد من احتمالية أن يقوم المهاجمون بربط اختراق OIM في عمليات أوراكل العقارية الأوسع نطاقًا.

التحقق الدفاعي دون تحويل الكشف إلى استغلال

بالنسبة لمعظم الفرق، تكون المهمة الأولى بسيطة: تحديد التعرضوليس محاكاة المهاجمين. يبدو سير العمل الآمن والمصرح به كالتالي:

1. جرد إصدارات OIM عبر البيئات ومقارنتها بالخطوط المتأثرة.
2. تقييد وصول الإدارة المقيدة على الفور (ACLs الشبكة، بوابة VPN، ZTNA)، حتى قبل نوافذ التصحيح.
3. مطاردة حالات الشذوذ الإداري لـ REST في سجلات الوصول: عناوين URI للطلبات عالية الخصائص، أو الطلبات المتدفقة من عناوين IP غير مألوفة، أو نقاط نهاية من فئة المسؤول التي يتم استدعاؤها في غير ساعات التغيير.

لإبقاء هذا الأمر ملموسًا، إليك مطابقة نسخة دفاعية فقط يمكنك دمجها في مهام جرد الأصول الخاصة بك:

# دفاعي فقط: مطابقة إصدارات OIM المكتشفة مع المجموعة المتأثرة
من إصدار استيراد العبوات

المتأثر = [
    ("12.2.1.4.0", "12.2.1.4.0"),
    ("14.1.2.1.0", "14.1.2.1.0"),
]

def is_affected(v: str) -> bool:
    v = الإصدار.parse(v)
    إرجاع أي(الإصدار.parse(lo) <= v <= الإصدار.parse(hi) ل lo, hi في AFFECTED)

بالنسبة إلى v في ["12.2.1.1.4.0", "14.1.2.1.1.0", "14.1.2.2.2.0"]:
    طباعة(v, "متأثر؟" ، is_affected(v))

إذا لم تتمكن من استخراج الإصدارات من اللافتات بشكل موثوق، فقم بإعطاء الأولوية لبيانات CMDB الداخلية أو بيانات حزمة المضيف أو البيانات الوصفية الرئيسية من Oracle. المفتاح هو تجنب "سبر" طبقة الهوية الخاصة بك بطرق تزيد من المخاطر التشغيلية.

صيد ما بعد التصحيح: كيف سيبدو شكل التسوية

تشير سلسلة أضواء البحث إلى فئة محددة من السلوكيات التي يجب أن تراقبها، حتى بعد الترقية:

• نقاط نهاية إدارة REST التي يتم ضربها من قبل مصادر غير معروفة، خاصة من نطاقات IP العامة.
• أفعال الإدارة المستخدمة خارج نوافذ التغييرلا سيما أي شيء يقوم بالتجميع أو التحميل أو تغيير سير العمل/الموصلات.
• حسابات خدمة جديدة أو تغييرات في الأدوار التي لا تتماشى مع العمليات التي يتم الحصول على تذاكر لها.

ينصح كلٌ من RunZero وWiz بمراجعة السجلات بحثًا عن نشاط REST غير اعتيادي وتضييق إمكانية الوصول إلى الإدارة كجزء من التقوية، وليس فقط الإصلاح. (رن زيرو)

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

التخفيف الذي يقلل بالفعل من المخاطر

إرشادات أوراكل الرسمية هي تطبيق تحديثات وحدة المعالجة المركزية لشهر أكتوبر 2025، والتي تتضمن الإصلاح. (أوراكل) من وجهة نظر هندسية، تتراكم إجراءات الحد من المخاطر على هذا النحو:

• التصحيح فوراً على أي إصدار مدعوم متأثر.
• إزالة إمكانية الوصول العامة لخطط إدارة REST. لا ينبغي أن تكون واجهات برمجة تطبيقات إدارة الهوية موجهة إلى الإنترنت.
• تدوير بيانات الاعتماد المميزة وتطلب MFA حيثما كان ذلك ممكنًا من الناحية التشغيلية.
• خط الأساس والرصد انجراف تكوين OIM (الأدوار، والموصلات، وسير العمل).
• تقسيم فئة IAM بحيث أنه حتى إذا تم اختراق OIM، تتباطأ الحركة الجانبية.

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

أهمية مكافحة التطرف العنيف لمهندسي أمن الذكاء الاصطناعي

إذا كنت تعمل في مجال تقاطع أنظمة الذكاء الاصطناعي والأمان، فإن إدارة معلومات العمليات هي تبعية متزايدة الأهمية في المنبع. فغالباً ما ترث مجموعات خدمة النماذج، ومنصات البيانات، و CI/CD، وحتى أدوات إدارة التعلم الآلي الداخلية قرارات الوصول من إدارة الهوية المؤسسية. إن الاستيلاء المسبق على البنية التحتية للهوية هو الطريقة التي "يضفي بها المهاجمون "الشرعية" على اختراق مكدس الذكاء الاصطناعي في وقت لاحق: فهم لا يحتاجون إلى تحطيم خادم النموذج إذا كان بإمكانهم صك الهوية المسموح لهم بتغييرها.

من من منظور الذكاء الاصطناعي الدفاعي، فإن CVE-2025-61757 هو تذكير بالتعامل مع القياس عن بُعد للهوية كإشارة من الدرجة الأولى في خطوط أنابيب الكشف الخاصة بك. إذا كنت تقوم ببناء أدوات أمنية عميلية، فإن "الأتمتة عالية التأثير" الأكثر واقعية ليست توليد الثغرات التخمينية - بل هي المخزون عالي الدقة، ونمذجة نصف قطر الانفجار، وتنسيق التصحيح لممتلكات الهوية والبرمجيات الوسيطة.

ملاحظة هادئة حول الأتمتة (عندما يكون ذلك مناسباً)

في مجمّعات Oracle الكبيرة، يكون امتداد الإصدارات حقيقيًا: غالبًا ما يتأخر المستأجرون المطورون وضمان الجودة والتعويضات والمستأجرون القدامى بأرباع. يمكن أن تساعد منصات الأتمتة البشرية داخل الحلقة مثل Penligent في جرد إصدارات نظام إدارة معلومات العمليات على مستوى الأسطول، والتحقق من صحة التعرض، وتتبع العلاجدون دفع الفرق إلى الاستغلال المحفوف بالمخاطر. عندما تكون الثغرة الأمنية حرجة من مستوى الهوية، فإن السرعة والدقة في حلقة "العثور على ← تحديد الأولوية ← الإصلاح" أكثر أهمية من أي شيء آخر.

الإغلاق

إن CVE-2025-61757 ليس مجرد خطأ؛ إنه مسار اختراق عالي النفوذ لمستوى الهوية ناتج عن نمط معروف مضاد لنمط جافا الخاص بالمؤسسات. الطلب الفوري واضح - تصحيح إصدارات OIM المتأثرة وتأمين الوصول إلى إدارة REST. أما على المدى الطويل فهو أكبر: إذا كان يمكن الوصول إلى مستوى تحكم IAM الخاص بك، فسيتم مهاجمته - وسيتم تجاوز مرشحات قائمة السماح المركزية. تعامل مع مكافحة التطرف العنيف هذه كوظيفة إجبارية للتدقيق في كيفية تعرض أنظمة الهوية الخاصة بك، والمصادقة عليها، ومراقبتها.