حملة

كيف يعمل الاستغلال: لا حاجة لثغرات أمنية

كلا المنصتين، Salesforce وServiceNow، تحتويان على حسابات مستخدم ضيف دائمة للزوار غير الموثّقين. لا يمكن حذف حسابات الضيوف هذه. صلاحياتهم — أي السجلات والكائنات التي يمكنهم قراءتها — يتم تكوينها من قبل كل مؤسسة. إذا كان ملف الضيف لديه صلاحية قراءة لسجل ما، فيمكن لأي شخص على الإنترنت استرداده من خلال نقاط نهاية API مشروعة تمامًا.

في Salesforce (إطار Aura):

• ترسل الأداة طلبات POST إلى نقطة النهاية /aura أو /s/sfsites/aura.
• أولاً، تستدعي HostConfigController.getConfigData لتعداد الكائنات (Account، Contact، Case، Lead، User، ContentDocument، إلخ) التي يمكن للمستخدم الضيف الوصول إليها.
• ثم تستخدم SelectableListDataProviderController.getItems للتنقل عبر جميع السجلات في كل كائن يمكن الوصول إليه.
• الهدف الأكثر انشغالاً سجل أكثر من 560,000 حدث من عنوان IP الخاص بالمهاجم، جميعها تقريبًا كانت تعداد Aura للضيوف.

في Salesforce (إطار LWR — Lightning Web Runtime):

• هذه هي أول مرة يتم فيها رصد استغلال في العالم الحقيقي لواجهة المستخدم API للضيوف في مواقع LWR.
• تستهدف الأداة نقطة نهاية GraphQL عند

  POST /webruntime/api/services/data/{version}/graphql?asGuest=true

  ، حيث تقوم أولاً بتعداد المخطط عبر EntityDefinition، ثم قراءة السجلات باستخدام التصفح القائم على المؤشر.
• تمسح الأداة إصدارات API من v56.0 إلى v66.0 بالتسلسل ضد كل موقع LWR تكتشفه.

في ServiceNow:

• تستهدف الأداة نقطة النهاية /api/now/sp/search — وهي واجهة برمجة بحث أصلية لمنافذ Service Portal غير موثقة إلى حد كبير ولا تحتوي على أي وثائق عبر الإنترنت أو أدوات مفتوحة المصدر تشير إليها.
• هذه النقطة عامة بطبيعتها. تعتمد البيانات التي تعيدها كليًا على مصادر البحث المرفقة بالمنفذ الموجه للضيوف وما إذا كانت هذه المصادر تفرض ضوابط الوصول.

استقصاء التسجيل الذاتي (Salesforce):

• تقوم الأداة بإلحاق /SiteRegister و/CommunitiesSelfReg بكل مسار موقع تجربة تكتشفه لاختبار ما إذا كان التسجيل الذاتي مفعّلاً. إذا كان مفعّلاً، يمكن للمستخدم الضيف ترقية نفسه إلى مستخدم خارجي موثّق، مما يمنحه إمكانية الوصول إلى بيانات أكثر بكثير.

مجموعة الأدوات المخصصة والبنية التحتية

• عنوان IP المصدر: 158.220.87.79، مستضاف على خادم VPS من Contabo (مزود استضافة ألماني)، مرتبط بالنطاق city-forum.com (نطاق تم تسجيله في عام 2002، تم التخلي عنه، ثم إعادة استخدامه).
• استخدم نفس عنوان IP نفس النطاق منذ مارس 2025 دون تغيير — لمدة 17 شهرًا على الأقل من عنوان واحد.
• أداة Go مخصصة: أداة واحدة مكتوبة بلغة Go وتستهدف Salesforce عبر إطاري عمل Aura وLWR، وتستهدف أيضًا ServiceNow — كل ذلك من نفس الخادم. هذه مجموعة أدوات مخصصة متعددة المنصات، وليست أداة جاهزة مثل AuraInspector.
• تستخدم الأداة سلسلة User-Agent الافتراضية لـ Go وهي Go-http-client، مما يجعل التعرف عليها سهلاً في السجلات.

الجهات المستهدفة

تشير تقارير Reco إلى أن الأهداف الرئيسية تشمل:

• مشغلي الاتصالات
• البنوك وشركات الخدمات المالية
• موفري البرامج المؤسسية (بما في ذلك شركات الأمن وخصوصية البيانات)
• البوابات الحكومية

لماذا لا تستطيع سجلات التدقيق القياسية كشف البيانات المسروقة

بالنسبة لـ ServiceNow: سجلات المعاملات (syslog_transaction) في المنصة لا تسجل نص POST لطلبات /api/now/sp/search. يمكن للمدافعين رؤية أن عمليات البحث الآلية قد حدثت وكمية البيانات التي تم إرجاعها (عبر عمود طول المخرجات)، ولكن لا يمكنهم تحديد مصطلحات البحث الدقيقة أو السجلات المحددة التي تم استردادها.

بالنسبة لـ Salesforce: حركة تعداد الضيوف تتكون من استدعاءات API شرعية تتوافق مع البروتوكول وتبدو كحركة مرور عادية للموقع. بينما يمكن لمراقبة الأحداث إظهار حجم أحداث AuraRequest وSites من المستخدمين الضيوف، تظهر السجلات أن البيانات قد طُلبت ولكن لا تظهر المحتوى المحدد لما تم إرجاعه في استجابات GraphQL أو Aura.

بمعنى آخر، يمكنك رؤية أن المهاجم كان موجودًا وكمية البيانات التي سحبها، لكن لا يمكنك إعادة بناء السجلات أو الحقول المحددة التي استخرجها.

خطوات الإصلاح الموصى بها

لـ Salesforce (توصيات Reco):

1. تشديد قواعد مشاركة الضيف — التحكم الأكثر تأثيرًا. قم بإزالة أي قاعدة مشاركة تشارك السجلات مع المستخدم الضيف بما يتجاوز ما يحتاجه الموقع حقًا للخدمة العامة.
2. إزالة صلاحيات مستوى الكائن والحقل من ملف الضيف. قم بإزالة صلاحية القراءة للكائنات التي لا يحتاجها الموقع للزوار المجهولين.
3. إزالة صلاحية "الوصول إلى الأنشطة" من ملف الضيف (يعرض المهام والأحداث).
4. تعطيل "API Enabled" على المستخدم الضيف.
5. تعطيل التسجيل الذاتي ما لم يكن الموقع يحتاجه حقًا.
6. تعطيل وصول الضيف إلى الملفات ورؤية الأعضاء حتى لا يتمكن الضيوف من استرداد ملفات ContentDocument أو تعداد أعضاء الموقع الآخرين.
7. لمواقع LWR فقط: في Experience Builder ← Workspaces ← Administration ← Preferences، قم بإلغاء تحديد "السماح للمستخدمين الضيوف بالوصول إلى واجهات برمجة التطبيقات العامة." يؤدي هذا إلى إغلاق GraphQL ونقاط نهاية UI-API REST في خطوة واحدة.

لـ ServiceNow (توصيات Reco):

1. ربط المنافذ الموجهة للضيوف بمصادر البحث الخاصة بها. تحقق من جداول sp_portal وm2m_sp_portal_search_source وsp_search_source. افصل أي مصدر بحث لا يحتاجه المنفذ العام.
2. مراجعة منطق كل مصدر بحث — خاصة is_scripted_source وdata_fetch_script وما إذا كان يستخدم GlideRecordSecure (يفرض قوائم ACL) مقابل GlideRecord العادي (الذي لا يفرضها).
3. مراجعة معايير المستخدم "يمكن القراءة" لقاعدة المعرفة — ابحث عن وصول غير مقيد لأي مستخدم يعرض قواعد المعرفة الحساسة من خلال بحث الضيف.
4. افصل روابط kb_uc_can_read_mtom السيئة بدلاً من تحرير قواعد المشاركة بشكل عشوائي.

إرشادات الكشف:

• مراقبة أحداث Salesforce: ابحث عن كميات كبيرة من getItems وgetConfigData من

  USER_TYPE = 'Guest'

  ، وعمليات مسح إصدارات /webruntime/.../vNN.0/graphql، وطلبات إلى /SiteRegister و/CommunitiesSelfReg.
• سجلات معاملات ServiceNow: ابحث عن طلبات /api/now/sp/search المقدمة كمستخدم ضيف. قم بالفرز حسب طول المخرجات — الصفوف التي تعيد كمية أكبر بكثير من خط الأساس الصغير للنتيجة الفارغة تشير إلى عمليات بحث أعادت محتوى.