بحث ديال Material Security كيبين بلي توكنز ديال OAuth اللي مامراقبينش كيشكلو مسار هجوم نشط
The Back Door Attackers Know About — and Most Security Teams Still Haven’t Closed
بحث ديال Material Security كيبين بلي توكنز ديال OAuth اللي مامراقبينش كيشكلو مسار هجوم نشط
خلاصة — أغلبية الشركات ماعندهومش رؤية واضحة على توكنز ديال OAuth اللي تعطاو لتطبيقات طرف ثالث وتطبيقات الذكاء الاصطناعي المرتبطة ببيئات Google Workspace و Microsoft. الأبحاث كتشير بلي 80% من قادة الأمن كيشوفو بلي صلاحيات OAuth اللي مامداراش كتشكل خطر كبير، ولكن 45% ماديروش حتى شي مراقبة بمرة. حادثة Drift، فين فاعل التهديد UNC6395 استغل بيانات اعتماد شرعية ديال OAuth باش يخترق كثر من 700 بيئة ديال Salesforce، كتبين بلي هاد التوكنز كيعطيو وصول مستمر مستقل على كلمات المرور و MFA.
شنو وقع
واحد فاعل التهديد، اللي متبعاه Palo Alto Unit 42 باسم UNC6395، قدر يحصل على توكنز إعادة التنشيط (refresh tokens) صحيحة ديال OAuth — غالبا من خلال حملات ديال تصيد (phishing) سابقة — واستعملها باش يوصل لبيئات Salesforce تابعة لكثر من 700 شركة. المهاجم استغل بيانات اعتماد من Drift، اللي هي منصة تفاعل مبيعات شراتها Salesloft، واللي كانت عندها ربط بـ OAuth مع المئات من منصات Salesforce ديال الكليان.
غير تم الدخول، UNC6395 بدا كيخرج البيانات بشكل منهجي، بحال مفاتيح الوصول لـ AWS، وتوكنز ديال Snowflake، وكلمات المرور. شركات بحال Cloudflare، PagerDuty، والعشرات من الشركات الأخرى تقاسو. النطاق الكامل ديال هاد الاختراق ديال Drift مازال قيد التقييم.
هاد الهجوم تجاوز أنظمة الحماية المعيارية والمصادقة متعددة العوامل (MFA) بالكامل. من منظور سجلات الوصول (access logs)، حتى حاجة مابانت غالطة: التوكنز كانو شرعيين، والربط كان شرعي، وطلبات API كانت مصرح بيها. المهاجم مادخلش گاع ببيانات اعتماد مسروقة — هوما قدمو غير توكنز ديال OAuth اللي Drift ديجا عندها صلاحية تستعملهم.
علاش هادشي مهم
صلاحيات OAuth كتخدم بحال شي باب خلفي (backdoor) مستمر اللي فرق الأمن مايقدرش يشوفوه غير بأنظمة التحكم في الوصول التقليدية. على عكس المصادقة اللي مبنية على كلمات المرور، توكنز ديال OAuth:
- ماكيساليش الصلاحية ديالها بشكل أوتوماتيكي
- ماكتجددش ملي كتبدل كلمة المرور ديال الموظف
- ماكتطلبش المصادقة متعددة العوامل (MFA) ملي كتستعمل
- كتبقى مستمرة فالأغلب ديال البيئات بلا حتى شي رؤية مركزية للمراقبة
- كتبقى صالحة حتى مورا ماكيغادرو الموظفين الشركة
بالنسبة لفرق التطوير والبنية التحتية، هادشي كيعني بلي الوصول غير المصرح بيه عبر API للأنظمة الحساسة ممكن يوقع بلا مايتم الاكتشاف ديالو من خلال عمليات التسجيل المعيارية. بالنسبة لمحللي SOC، توكنز ديال OAuth كتمثل نقطة عمياء: النشاط ديال API اللي كيبان شرعي من تطبيقات معروفة يقدر يخبي سرقة بيانات اعتماد والتحرك الجانبي داخل الشبكة. بالنسبة للمسؤولين على الأنظمة (sysadmins) اللي كيگيريو البيئات السحابية، غير توكن واحد مخترق مرتبط بكونط عندو صلاحيات كبار يقدر يعطي لـ المهاجم وصول لمفاتيح AWS، وبيانات اعتماد قواعد البيانات، وبيانات الإعدادات فالشركة كاملة.
البحث ديال Material Security كيوضح هاد النقص فالقدرات بالأرقام: 80% من قادة الأمن كيعتابرو صلاحيات OAuth اللي مامداراش خطر كبير للشركة. ولكن، 45% من الشركات ماديرين والو باش يراقبو هاد الصلاحيات ديال OAuth على نطاق واسع. و 33% خرين كيعتامدو على عمليات يدوية — بحال جداول البيانات، المراجعات العشوائية، وتبليغات الموظفين — وهادشي ماكيعتبرش قدرة حقيقية للاستجابة للتهديدات.
الأنظمة المتأثرة و CVEs
المنتجات اللي مذكورة فالمصدر:
- Google Workspace
- Microsoft environments (منتجات غير محددة)
- Salesforce
- Drift (Salesloft)
- AWS
- Snowflake
- Cloudflare
- PagerDuty
ماكاينش شي CVE محدد فوقت النشر. المصدر ماكيذكرش شي CVEs محددين. هاد ثغرة متعلقة بخاصية معمارية ديال استمرارية توكن OAuth، ماشي خلل برمجي فشي نسخة معينة من شي منتج.
شنو خاص يندار
المصدر كيحدد خطوات التخفيف التالية باش نواجهو هاد الخطر:
- خاصنا نطبقو مراقبة سلوكية مستمرة للتطبيقات المرتبطة بـ OAuth، ومابقاوش نعتامدو غير على تقييم المخاطر فلحظة التثبيت فقط.
- مراقبة طلبات API الفعلية اللي كديرها التطبيقات المرتبطة بـ OAuth مع مرور الوقت باش نكتشفو الحوايج الغير طبيعية — بحال الارتفاع المفاجئ فالوصول للبيانات، ولا أنواع بيانات غريبة، ولا محاولات الوصول فوقت ماشي متوقع.
- نديرو تقييم لقطر الانفجار (blast radius) ديال كل صلاحية OAuth: نحددو مستويات الوصول والبيانات المعرضة للخطر بالنسبة للحسابات اللي مرتبط بيها كل تطبيق، حيت توكن خبيث مرتبط بكونط عندو صلاحيات كبار كيشكل خطر كبر بزااف من نفس التوكن إلا كان مكونيكطي مع كونط بصلاحيات محدودة.
- نطبقو قدرات استجابة متدرجة بناءً على تحمل الشركة للمخاطر: الصلاحيات اللي باينة خبيثة (مزود مجهول، طلبات صلاحيات واسعة، سلوك غير طبيعي) خاصها تطلق عملية إلغاء (revocation) أوتوماتيكية؛ أما التطبيقات الحساسة والمهمة اللي كتبين سلوك ماشي طبيعي شي شوية، خاص يتم رفع التنبيه لفريق الأمن مع السياق كامل قبل مايتاخد أي إجراء.
- نحددو عتبات (thresholds) للمعالجة الأوتوماتيكية، مع الاحتفاظ ببوابات ديال المراجعة البشرية بالنسبة للتطبيقات اللي كتعتابر حاسمة لسير العمل (mission-critical).
أسئلة مفتوحة
- شنو هو النطاق الكامل ديال الشركات اللي تقاست فاختراق Drift؟ المصدر كيقول بلي التقييم مازال مستمر.
- شحال ديال الشركات حاليا مطبقة مراقبة أوطوماتيكية ديال OAuth؟ المصدر ماكيحددش معدلات الاعتماد فهاد المجال.
- شنو هي المؤشرات المحددة ولا أنماط ديال طلبات API اللي كتعرف السلوك الغير طبيعي ديال OAuth؟ المصدر كيعطي أمثلة ولكن ماكيحددش العتبات (thresholds).
- إمتى وقعت حادثة Drift بالضبط؟ المصدر ماعطاش حتى شي تاريخ محدد.
- شنو هو مسار الهجوم اللي تخدم فحملات ديال تصيد (phishing) الأولية اللي جابت اختراق بيانات اعتماد OAuth اللي استغلها UNC6395؟ المصدر كيشير للتصيد ولكن ماكيعطيش تفاصيل كثر.
Source
The Back Door Attackers Know About — and Most Security Teams Still Haven't Closed

مجموعة UAT-8302 المرتبطة بالصين كتستعمل برمجيات خبيثة مشتركة باش تهاجم حكومات في أمريكا الجنوبية وأوروبا الشرقية

ثغرة أمنية CVE-2026-23918 فـ Apache HTTP Server: مشكل Double-free فـ mod_http2 كيسمح بـ DoS و RCE
