أول هجوم فدية ذكاء اصطناعي (Agentic) يستغل ثغرة Langflow

تفترض معظم الدفاعات ضد برامج الفدية (Ransomware) وجود عنصر بشري يقود الهجوم. لكن تقرير شركة Sysdig حول JADEPUFFER يغير هذه الفرضية تماماً؛ حيث يُعتقد أن عميلاً ذكياً (Agentic AI) أدار عملية فدية كاملة من البداية إلى النهاية بعد استغلال ثغرة في نسخة من أداة Langflow كانت متصلة بالإنترنت. يوضح هذا الدليل التغييرات التي يجب على المدافعين إجراؤها في البنية التحتية، وإدارة الأسرار الرقمية (Secrets)، والمراقبة، والاستجابة للحوادث لمواجهة اختراقات تتم بـ "سرعة الآلة".

ما الذي حدث في هجوم الفدية عبر وكيل Langflow؟

يصف باحثو Sysdig هذا الهجوم بأنه أول سلسلة "فدية وكيلة بالكامل" (Fully Agentic) يتم رصدها: من الاختراق إلى التأثير بأقل تدخل بشري أو بدون تدخل على الإطلاق. تشير التقارير إلى أن نقطة الدخول كانت عبر نشر Langflow بشكل مكشوف على الإنترنت واستغلال ثغرة CVE-2025-3248. بعد ذلك، انتقل المهاجم نحو Nacos وMySQL باستخدام نقاط ضعف معروفة، بما في ذلك نمط قديم لتجاوز المصادقة يعود لعام 2021. يمكنك العثور على التغطية الكاملة في The Register و SC World.

قائمة فحص فورية إذا كان Langflow مكشوفاً

bashCopy
## 1) تحديد التعرض للإنترنت (يُنفذ من جهاز مسؤول موثوق)
curl -s https://api.ipify.org && echo

# 2) البحث عن منافذ Langflow المفتوحة على المضيف
sudo ss -lntp | grep -Ei 'langflow|:7860|:3000|:8000' || true

# 3) التأكد مما إذا كان هناك وكيل عكسي (Reverse Proxy) ينشر الخدمة
sudo nginx -T 2>/dev/null | grep -Ei 'server_name|proxy_pass|langflow' || true
sudo caddy list-modules 2>/dev/null | head -n 20 || true

# 4) أخذ لقطة لعمليات Python المشبوهة (إشارة سريعة للاستجابة للحوادث)
ps auxww | grep -E 'python|langflow' | grep -v grep

تجيب هذه الأوامر على سؤال واحد بسرعة: هل يمكن للمهاجم الوصول إلى Langflow؟ وهل تعمل لغة Python بطرق غير متوقعة؟ رقم المنفذ (Port) بحد ذاته ليس المشكلة، بل المهم هو إمكانية الوصول إلى Langflow من الإنترنت العام، وما إذا كان المضيف يعمل كمركز لتخزين مفاتيح السحابة، أو رموز مزودي النماذج، أو مفاتيح API الداخلية.

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

لماذا يعد Langflow هدفاً ثميناً لمشغلي برامج الفدية؟

أداة Langflow ليست مجرد "واجهة مستخدم للذكاء الاصطناعي". في معظم الفرق، تقع هذه الأداة في قلب العمليات؛ حيث تتصل بمفاتيح مزودي النماذج، وبيانات اعتماد قواعد البيانات المتجهة (Vector DB)، وأدوات HTTP الداخلية، وأحياناً رموز إدارة السحابة. هذا يجعل من عقدة واحدة مكشوفة مركزاً ضخماً لتجميع بيانات الاعتماد.

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

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

بالنسبة للفرق التي تبني أنظمة وكيلة أكثر تعقيداً، يتداخل هذا مع مخاطر تصميم الأنظمة متعددة الوكلاء (Multi-agent) مثل صلاحيات الأدوات والذاكرة المشتركة. لمزيد من التفاصيل حول هذه الأنماط، راجع فرق الذكاء الاصطناعي متعددة الوكلاء في 2026: نجاح أم فشل؟.

ثغرة CVE-2025-3248 من منظور عملي: ما الذي يجب أن يفترضه المدافعون؟

تصف التقارير ثغرة CVE-2025-3248 بأنها حالة فقدان للمصادقة تسمح بـ تنفيذ كود برمجبي عن بُعد دون مصادقة في Langflow. ببساطة، هي تنفيذ كود Python عشوائي على المضيف. وهذا يعني أن المهاجم لا يحتاج حتى إلى بيانات اعتماد صالحة لتشغيل كوده.

بمجرد تشغيل كود Python، يمكن للمهاجم قراءة متغيرات البيئة env وذاكرة العمليات للحصول على مفاتيح API، وطلب بيانات الاعتماد من نقاط نهاية السحابة (Metadata)، وفحص الشبكات الداخلية من موطئ قدم موثوق، وتثبيت وجوده في النظام عبر مهام cron أو محاولات الهروب من الحاويات (Container Escape).

تتوفر بالفعل مراجع لإثبات المفهوم (PoC) علناً في أرشيف GitHub: intelseclab/poc-archive CVE-2025-3248 Langflow unauth RCE. حتى لو لم يستخدم فريقك هذا الـ PoC، اعتبر توفره إشارة إلى أن عمليات الفحص والاستغلال ستصبح شائعة وسريعة جداً.

مخطط التحصين: تشغيل Langflow كخدمة إنتاج

ضع Langflow خلف نظام هوية، وليس مجرد جدار حماية

yamlCopy
# نمط الوكيل العكسي: يتطلب تسجيل الدخول الموحد (SSO) قبل الوصول إلى Langflow
# هذه قائمة فحص مفاهيمية وليست إعدادات جاهزة للتطبيق.
controls:
  - enforce_sso: true
  - require_mfa: true
  - restrict_by_group: "ai-platform-admins"
  - block_all_public_routes: true
  - rate_limit:
      requests_per_minute: 60
  - geo_allowlist: ["[YOUR_COUNTRY]"]

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

إذا كان لا بد من وصول الشركاء إلى Langflow، فاعزله في قطاع شبكة مخصص (Segment) بدون مسار افتراضي لقواعد بياناتك. تعامل معه كجهاز قفز (Jump Host) بقواعد صارمة لحركة المرور الخارجة.

اجعل حركة المرور الخارجة محدودة: المنع هو الأصل

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

النمط العملي هو استخدام قائمة بيضاء لحركة المرور الخارجة على مستوى الشبكة الفرعية. إذا كان سير عمل الذكاء الاصطناعي يحتاج api.openai.com أو بوابة خاصة، اسمح لهما فقط وامنع باقي الإنترنت.

توقف عن تخزين الأسرار طويلة الأمد على مضيف Langflow

إذا كان المضيف يحتوي على مفاتيح سحابة طويلة الأمد، فإن "المرحلة الثانية" للمهاجم ستكون تلقائية تقريباً. من الأفضل استخدام بيانات اعتماد قصيرة الأجل من هوية العمل (Workload Identity) وحفظ مفاتيح مزودي النماذج في مدير أسرار (Secrets Manager) مع سياسات قراءة صارمة.

لا تسمح بانتشار الأسرار بشكل عشوائي. تجنب ملفات .env في المجلدات الرئيسية، وأبعد الأسرار عن ملفات JSON الخاصة بسير العمل، أو السجلات، أو آثار الأخطاء (Exception traces). هذا أمر حيوي لأدوات الذكاء الاصطناعي لأن إعدادات الموصلات (Connectors) تميل لجمع بيانات الاعتماد بهدوء مع مرور الوقت.

مسار التحرك الجانبي: من Langflow إلى Nacos ثم MySQL

تشير التقارير إلى أن المهاجم انتقل من Langflow إلى Alibaba Nacos، ثم إلى MySQL. يعد Nacos مستوى تحكم شائع لاكتشاف الخدمات والإعدادات. إذا تم اختراقه، يمكنه كشف نقاط نهاية قواعد البيانات ورموز الخدمات.

الدرس المستفاد هو أن خدمات الإعدادات هي "مضاعفات للامتيازات". إذا كان Nacos يخزن بيانات اعتماد قاعدة البيانات، فإنه يصبح حجر زاوية مثالي للوصول إلى أثمن بياناتك.

ما الذي يجب تغييره في تصميم الشبكة؟

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

إذا كان بإمكان Langflow التحدث مباشرة إلى MySQL عبر المنفذ 3306 ، فالمهاجم يحتاج فقط لموطئ قدم واحد. أما إذا كان لا يمكنه الوصول إلا إلى API داخلي ضيق، فسيضطر المهاجم لاختراق ذلك أيضاً، مما يزيد بشكل كبير من فرص كشفه.

ما الذي يجب تغييره في ضوابط قواعد البيانات؟

يجب أن تفترض MySQL أن التهديد موجود بالفعل في الداخل. فرض مبدأ "الأقل صلاحية" لكل خدمة وتقييد امتياز FILE. يجب عليك أيضاً تفعيل التنبيهات عند قراءة المخططات (Schema) بشكل مكثف أو عمليات الكتابة الضخمة التي تشبه التشفير.

عادة ما تظهر برامج الفدية التي تستهدف قواعد البيانات نمطاً يتمثل في "قراءة الكثير، ثم كتابة الكثير". هذا النمط يسهل اكتشافه جداً إذا كان لديك خط أساس لحجم الاستعلامات الطبيعي.

الكشف الفعال ضد سرعة الوكلاء

التنبيه عند قيام Python بتشغيل أدوات الشبكة أو Shell

في مضيف Langflow، نادراً ما يكون قيام Python بتشغيل curl أو wget أو bash أو ssh سلوكاً طبيعياً. حتى لو كانت بعض سير العمل تستدعي أدوات خارجية، يجب أن يكون هذا النشاط صريحاً وقابلاً للتدقيق. قواعد EDR التي تضع علامة على python كعملية أب لها أبناء غير عاديين فعالة للغاية هنا.

مراقبة أنماط الوصول إلى الأسرار، وليس فقط تسريبها

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

شذوذ الوقت: سلسلة قتل مضغوطة

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

الاستجابة للحوادث: الاحتواء أولاً، ثم التحقيق

نمط الاحتواء السريع لمواطئ أقدام Langflow

اعزل المضيف أو مساحة الاسم (Namespace) فوراً. بعد ذلك، قم بتغيير كل بيانات الاعتماد التي يمكن أن تكون قد قُرئت: رموز الوصول للسحابة، مفاتيح IAM، مفاتيح API لمزودي LLM، وبيانات اعتماد قواعد البيانات المخزنة في الموصلات. الاحتواء أمر ملح لأن الأدوات الوكيلة لا تنام؛ ستستمر في محاولة التحرك الجانبي تلقائياً.

التحقيق الجنائي الذي يجيب على "ما الذي لمسه؟"

ركز على الأسرار التي كانت موجودة على المضيف وعناوين IP الداخلية التي اتصل بها المضيف بعد الاستغلال. انظر إلى خدمات الإعدادات التي تم الاستعلام عنها وقواعد البيانات التي شهدت اتصالات جديدة من شبكة Langflow الفرعية. إذا كنت تسجل سجلات DNS الخارجة وسجلات التدفق (Flow logs)، فسيصبح رسم الخريطة أسهل بكثير.

حواجز حماية عملية للفرق التي تبني تطبيقات وكيلة

افصل بين "الأدوات" و "التنفيذ"

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

اجعل الموصلات صريحة وقابلة للمراجعة

تفشل الأنظمة الوكيلة بأمان عندما يكون الوصول إلى الأدوات محدوداً. إذا كان بإمكان أي سير عمل استدعاء HTTP عشوائي أو تشغيل Python عشوائي، فإن النظام يصبح ملعباً للمهاجمين. افرض قوائم الموصلات المعتمدة وسياسات الشبكة لكل سير عمل لتقليص مساحة العمل المتاحة للمهاجم.

فضل "المحلي أولاً" للتجارب الحساسة

بالنسبة للنماذج الأولية الحساسة، تقلل الإعدادات التي تعمل دون اتصال بالإنترنت (Offline-first) من نطاق الانفجار بشكل كبير. إذا كان سير العمل لا يحتاج لأن يكون عاماً، فلا تستضيفه بشكل عام. لمزيد من المعلومات حول هذه المقايضات، راجع نماذج LLM المحلية: هل هي الثورة الحقيقية للذكاء الاصطناعي؟.

نقاط بيانات من دراسات حالة ترتبط بهذا التهديد

حافظت Stripe على توفر عالٍ للخدمة باستخدام عزل صارم للخدمات، وهو بالضبط العقلية المطلوبة لإبعاد أدوات الذكاء الاصطناعي عن قواعد البيانات. وبالمثل، تستخدم Netflix وShopify مبدأ "الأقل صلاحية" والاحتواء الآلي للحد من نطاق الانفجار أثناء الأحداث الأمنية.

هذه ليست مجرد قصص عن "أمن الذكاء الاصطناعي"، بل هي ممارسات أساسية للبنية التحتية تصبح ضرورية بمجرد أن يزيل المهاجمون الوكلاء العقبات البشرية من المعادلة.

خطوات عملية

ابدأ من هنا

قم بجرد كل عمليات نشر Langflow. تأكد من عدم وجود أي منها مكشوف للإنترنت عن طريق تشغيل ss -lntp والتحقق من إعدادات الوكيل العكسي. افعل ذلك خلال الـ 30 دقيقة القادمة.

مكاسب سريعة

قم بتحديث نسخ Langflow المتأثرة بثغرة CVE-2025-3248 وأعد نشرها خلال 24 ساعة. تأكد من أن الخدمة تتطلب مصادقة. قم بتغيير جميع مفاتيح API الخاصة بـ LLM وبيانات اعتماد السحابة المستخدمة في موصلات Langflow خلال 4 ساعات.

تعمق أكثر

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

موارد مفيدة

• تغطية The Register لهجوم JADEPUFFER - ملخص لنقطة دخول Langflow.
• تقرير SC World حول سلسلة الهجوم - تفاصيل حول التقدم بـ "سرعة الآلة".
• تحليل Security Affairs - سياق حول استقلالية العملية.
• مرجع أرشيف PoC لثغرة CVE-2025-3248 - مؤشرات المعالجة ومعلومات إثبات المفهوم.

النقاط الجوهرية

هجوم JADEPUFFER هو تحذير بشأن السرعة التشغيلية، وليس مجرد برمجيات خبيثة من وحي الخيال العلمي. عندما يُترك Langflow مكشوفاً، يمكن للمهاجم ربط تقنيات معروفة لتنفيذ هجوم فدية بشكل أسرع مما يستغرقه فريق SOC لإنهاء عملية الفرز الأولي. الدفاع واضح: أزل التعرض العام، وحدث ثغرة CVE-2025-3248، واعزل أدوات الذكاء الاصطناعي، وغير الأسرار فوراً. الفرق التي تعامل منصات الذكاء الاصطناعي كبوابات دخول لبيئة الإنتاج هي التي ستمنع الهجمات "الوكيلة" من التحول إلى انقطاعات "تلقائية".