اختراق Fireworks AI: قائمة تحقق لمخاطر مزوّدي الاستدلال بعد حادثة LLMjacking

يُعدّ اختراق Fireworks AI من أوضح الحالات الحديثة التي انتقلت فيها المخاطر عبر مزوّد استدلال مستضاف لتصل إلى عملائه. ففي أكتوبر 2026، أعلنت Fireworks AI عن حادثة أمنية، ثم وصف تحديث لاحق عملية تسلل ثانية وتأثيرًا أوسع نطاقًا.

نعرض فيما يلي ما نشرته Fireworks فعليًا، تليه خطة استجابة نسمّيها دليل «الأسرار والبيانات والإنفاق». وبعد ذلك تأتي قائمة تحقق للعناية الواجبة تستعين بها في مراجعات المورّدين مستقبلًا.

ما كشفته Fireworks: عمليتا تسلل بالترتيب

نشرت Fireworks نشرة أمنية أولية وتحديثًا لاحقًا. وعند قراءتهما جنبًا إلى جنب، يتبيّن أنهما تصفان عمليتي تسلل منفصلتين.

الحادثة الأولى، التي اكتُشفت في 6 أكتوبر، تضمّنت استخدامًا غير مصرّح به لبيانات اعتماد داخلية خاصة بـFireworks. ووفقًا للنشرة الأولية، وصل طرف ثالث غير مصرّح له إلى متغيرات البيئة المستخدمة في مهام التقييم ضمن عدد محدود من حسابات العملاء.

أما الثانية فجاءت عبر أحد المورّدين. إذ تعرّض مزوّد سحابي خارجي يستضيف أجهزة البحث والتطوير لدى Fireworks لحادثة أمنية في 23 أكتوبر. وبعد يوم واحد، في 24 أكتوبر، استغلّ المهاجم هذا الوصول لبلوغ أجهزة التطوير لدى Fireworks وتشغيل عبء عمل غير مصرّح به، ما أدى إلى تأثير إضافي على بيانات العملاء.

كما غيّر التحديث الصورة بشأن ما سُرق. فعند صدور النشرة الأولى، كان المعروف فقط أن الأسرار المخزّنة لدى Fireworks قد جرى الوصول إليها. لكن التحقيقات اللاحقة كشفت تأثيرات على معلومات الحسابات والفوترة، وبالنسبة إلى مجموعة محدودة من الحسابات، تأثيرات على الأسرار ومجموعات البيانات والنماذج غير المكتملة.

وفيما يخص نسب الهجوم، تستشهد الشركة بأدلة تربط النشاط بمجموعة إجرامية إلكترونية ذات دوافع مالية تبيع رموزًا (tokens) مصدرها وصول غير مصرّح به إلى النماذج اللغوية الكبيرة لصالح بوابات توجيه غير مشروعة، وهي ممارسة تسمّيها «LLMJacking».

ولا تزال هناك فجوة في السجل. فبحسب The Register، لم يذكر التحديث عدد العملاء المتأثرين بأيٍّ من الهجومين. وإلى أن تكشف Fireworks المزيد، تحقّق من مدى تعرّضك مباشرةً مع المورّد.

ما الذي كُشف، وما الذي لم يُكشف، وما الذي غيّرته Fireworks

في الحادثة الأولى، تعتقد Fireworks أن متغيرات البيئة، بما فيها مفاتيح API والرموز المخزّنة كأسرار، قد التُقطت في بعض الحسابات المتأثرة. ونادرًا ما يكون السرّ الموجود في بيئة مهمة ما مثيرًا للاهتمام بحد ذاته؛ فقيمته تكمن فيما يفتحه من أبواب في أماكن أخرى.

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

وبشأن أوزان النماذج، وبحسب تصريحات لين تشياو، الرئيس التنفيذي لـFireworks، لموقع The Register، لم يبدُ أن المهاجمين كانوا يستهدفون الأوزان، وكانت معظم عمليات التنزيل جزئية وتوقفت. تعامل مع ذلك على أنه تقييم المورّد نفسه، لا نتيجة توصّلت إليها جهة مستقلة.

ويمتد التأثير إلى الأطراف اللاحقة في السلسلة أيضًا. فقد أبلغت Notion، وهي من عملاء Fireworks، المستخدمين المتأثرين بأن مساحات عملهم كانت ضمن أقل من 1 بالمئة من مساحات عمل Notion التي ربما تأثرت بحادثة Fireworks.

وقد تغيّر المنتج استجابةً لذلك. إذ عُطّلت ميزات رفع مجموعات البيانات وتنزيلها بالخدمة الذاتية، المستخدمة في الاستدلال الدفعي (Batch Inference) والتدريب القائم على مجموعات البيانات، طوال فترة التحقيق. وتنص وثائق الضبط الدقيق الآن على أن المقيّمات ومهام التقييم قد أُزيلت. وهي الميزة نفسها التي كُشفت متغيرات بيئتها في الحادثة الأولى.

لماذا يحوّل LLMjacking مفتاحًا مسرّبًا إلى فاتورة ضخمة

LLMjacking هو سرقة الوصول إلى استدلال النماذج وإعادة بيعه.

تفيد مجموعة Google لاستخبارات التهديدات بأنه عبر تحقيقات متعددة فيما تسمّيه «LLMJacking»، كان ناقل الوصول الأولي السائد هو رموز الهوية السحابية المكشوفة أو المسروقة. وتشمل هذه بيانات اعتماد IAM، ومفاتيح حسابات الخدمة، ورموز الوصول الشخصية في GitHub، ورموز الجلسات النشطة. لاحظ كم أن هذه القائمة أوسع بكثير من مفاتيح API الخاصة بالنماذج. وهذه هي النقطة الأساسية بالنسبة إلى المدافعين.

وتصف Google ما يُعرف بـ«LLM Mixers» بأنها بوابات توجيه غير مشروعة تعمل وسيطًا لتجميع الوصول غير المصرّح به إلى النماذج اللغوية الكبيرة وإعادة بيعه لمشتركين في السوق السرية. وتقدّم إحدى هذه الخدمات، وهي Jet Night، خطة رموز غير محدودة مقابل نحو $60 شهريًا مع وصول مزعوم إلى النماذج الرائدة، في حين أن هذا المستوى من الخدمة الاستهلاكية يكلّف عادةً ما بين $100 و$250 شهريًا.

وهناك من يدفع الفارق، وهو الضحية. ففي الحوادث التي تصفها Google، تجاوزت الرسوم الاحتيالية $100,000 في يوم واحد، وبلغت الرسوم التراكمية لدى بعض المؤسسات $1 مليون قبل إلغاء الوصول. وفي إحدى الحالات، أجرت جهة تهديد أكثر من 500,000 استدعاء لواجهات API الخاصة بالنماذج اللغوية الكبيرة في أقل من ثماني ساعات، مستخدمةً مفاتيح API مسروقة من أطراف خارجية لتشغيل Jet Night، وحمّلت الخدمة المؤسسة الضحية تكاليف رموز قاربت $1 مليون.

وتشير الأبحاث السابقة إلى الاتجاه نفسه. فقد قدّر التحليل الأصلي لـSysdig في 2024 أن الهجوم غير المكتشف قد يكلّف الضحية أكثر من $46,000 يوميًا في استهلاك النماذج اللغوية الكبيرة. ثم ذكرت أبحاث لاحقة لـSysdig أن هذا الرقم ارتفع إلى ما يقارب ثلاثة أضعاف ليتجاوز $100,000 يوميًا مع النماذج من الفئة العليا مثل Claude 3 Opus.

دليل «الأسرار والبيانات والإنفاق» لعملاء الاستدلال المستضاف

تنطبق هذه الخطوات السبع على هذه الحادثة وعلى أي حادثة مماثلة لاحقة، أيًّا كان المزوّد.

الأسرار: ما سلّمته للمزوّد

الخطوة 1: جرد كل سرّ مخزّن. أعدّ قائمة بكل سرّ مخزّن لدى المزوّد، مع إيلاء اهتمام خاص لمتغيرات البيئة المرتبطة بمهام التقييم أو المعالجة الدفعية أو التدريب. وبما أن مفاتيح API والرموز المخزّنة كأسرار قد التُقطت في بعض الحسابات المتأثرة، فتعامل مع أي سرّ ضمن النطاق على أنه مخترق إلى أن يثبت العكس.

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

الخطوة 3: تحديد نطاق الضرر. لكل مفتاح جرى تدويره، دوّن ما كان بإمكانه الوصول إليه (الحسابات السحابية، والمستودعات، وقواعد البيانات، وواجهات API لنماذج أخرى) وراجع سجلات تلك الأنظمة بحثًا عن أي نشاط بعد نافذة التعرّض. وامنح رموز الهوية السحابية ورموز GitHub الأولوية نفسها الممنوحة لمفاتيح النماذج؛ ففي تحقيقات Google كانت هي طريق الدخول الأكثر شيوعًا.

البيانات: ما رفعته

الخطوة 4: مراجعة مجموعات البيانات والنماذج. حدّد مجموعات البيانات ومهام الضبط الدقيق والنماذج غير المكتملة التي كانت موجودة على المنصة. ثم قرّر ما إذا كانت أي من تلك البيانات تستوجب إخطار العملاء أو إخطارًا تعاقديًا أو تنظيميًا. وأشرِك المستشار القانوني مبكرًا.

الخطوة 5: تعديل سير العمل المتأثر. خطّط للتعامل مع ميزات مجموعات البيانات المعلّقة الخاصة بالاستدلال الدفعي والتدريب القائم على مجموعات البيانات. وقرّر ما إذا كنت ستعيد رفع البيانات بعد عودة الميزات أم ستحتفظ بها في بيئتك الخاصة من الآن فصاعدًا.

الإنفاق: ما تراقبه

الخطوة 6: إطلاع فريق المالية على التعرّض في بيانات الفوترة. تمنح العناوين المسرّبة وسجل الفواتير والأرصدة المحتالَ تفاصيل مفيدة لصياغة رسالة تصيّد مقنعة أو فاتورة مزيفة. اطلب من فريقي المالية والحسابات الدائنة التحقق من أي طلب دفع غير متوقع أو تغيير في البيانات المصرفية عبر قناة يثقون بها مسبقًا.

الخطوة 7: وضع حدود قصوى وتنبيهات لكل مفتاح متبقٍّ. اضبط تنبيهات إنفاق وحدودًا قصوى صارمة لكل مفتاح، سواء لدى المزوّد أو في فوترة السحابة الخاصة بك. ووجّهها إلى قناة المناوبة، لا إلى صندوق بريد مشترك لا يقرؤه أحد ليلًا. ويتناول قسم المراقبة أدناه الإشارات التي ينبغي متابعتها.

وأيًّا كانت المجموعة، سجّل كل قرار مع طابع زمني واسم المسؤول عنه.

مَن المسؤول عن كل خطوة

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

أين ينطبق انعدام الاحتفاظ بالبيانات وأين لا ينطبق

وفقًا لـوثائق التعامل مع البيانات لدى Fireworks، تعتمد Fireworks افتراضيًا سياسة انعدام الاحتفاظ بالبيانات (ZDR)، ما يعني أنها لا تسجّل بيانات الطلبات أو المخرجات المولَّدة ولا تخزّنها لأي نماذج مفتوحة من دون موافقة صريحة من المستخدم. وتضيف صفحة سياسة ZDR تحفّظًا: فبعض الميزات تخزّن محتوى العملاء فعلًا، مثل الاستجابات المخزّنة والمهام الدفعية والتدريب.

انظر إلى ما طاله الاختراق فعليًا: المحتوى المخزّن، في صورة مجموعات بيانات ونماذج غير مكتملة، إضافةً إلى الأسرار التي لم يكن المقصود من ZDR تغطيتها أصلًا. إن اعتماد ZDR افتراضيًا أمر جدير بالحصول عليه في الاستدلال الفوري، لكنه ليس وعدًا يشمل كل ما ترسله. ونقترح التحقق من إعدادات الاحتفاظ لدى كل مزوّد تستخدمه بدلًا من افتراض تطابقها؛ ويُعدّ دليلنا حول تخزين طلبات Gemini API قراءة ذات صلة.

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

قائمة تحقق العناية الواجبة تجاه المورّدين: أسئلة توجّهها لأي مزوّد استدلال

اطرح هذه الأسئلة في مراجعات المشتريات وتجديد العقود واستبيانات الأمن. فكل سؤال منها مستمد من الجدول الزمني لحادثة Fireworks أو من النمط الأوسع لهجمات LLMjacking.

• [ ] التعامل مع الأسرار: أين تُخزَّن أسرار العملاء، ومن يمكنه قراءتها، وهل تتلقاها بيئات تشغيل المهام كمتغيرات بيئة بنص صريح؟
• [ ] سلسلة التوريد: ما السحابات الخارجية التي تستضيف أجهزة البحث والتطوير أو أجهزة التطوير، وكيف تُعزل عن بيانات العملاء؟
• [ ] خريطة الاحتفاظ: ما الميزات التي تخزّن محتوى العملاء؟ كما يوضح القسم أعلاه، يختلف ذلك من ميزة إلى أخرى، فاحصل على الإجابة كتابيًا.
• [ ] التواصل بشأن الحوادث: هل سيكشف المزوّد عن عدد العملاء المتأثرين، وكيف ستصلك التحديثات؟
• [ ] دورة حياة الميزات: عند إيقاف ميزة ما، كما حدث هنا مع المقيّمات ومهام التقييم، كيف تُمحى أسرارها وبياناتها؟
• [ ] ضوابط الفوترة: هل يمكنك ضبط حدود قصوى للإنفاق وحصص لكل مفتاح وتنبيهات للحالات الشاذة تصل إلى قناة المناوبة؟
• [ ] نطاق بيانات الاعتماد: هل يمكن قصر المفاتيح على نماذج أو مشاريع أو بيئات محددة، وتدويرها دون توقف الخدمة؟
• [ ] الوصول إلى السجلات: هل يمكنك معرفة من قرأ أسرارك ومتى؟

لن تُزيل الإجابات الجيدة الخطر. وقد ترغب الفرق التي توجّه حركة البيانات عبر عدة مزوّدين أيضًا في ضوابط للتوجيه والميزانية على مستوى البوابة؛ راجع دليلنا لبوابات الذكاء الاصطناعي.

مراقبة هجمات LLMjacking: إشارات قد تظهر قبل وصول الفاتورة

تميل هجمات LLMjacking إلى أن تكون صاخبة. فإشاراتها تظهر غالبًا في بيانات الاستخدام قبل وصول الفاتورة بوقت طويل، شرط أن يكون هناك من يراقب.

• طفرات الحجم. رصدت Sysdig أكثر من 85,000 طلب إلى Bedrock API في حملة واحدة، وصل 61,000 منها خلال نافذة مدتها ثلاث ساعات في 11 يوليو 2024. ومثل هذه الطفرة يجب أن تستدعي تنبيه أحد المناوبين فورًا.
• شذوذ المعدلات. حالة Jet Night، التي تجاوزت 500,000 استدعاء في أقل من ثماني ساعات، تفوق على الأرجح بكثير أي شيء تفعله مفاتيحك عادةً. اضبط التنبيهات على الانحرافات الكبيرة عن المعدل المعتاد لكل مفتاح. ويُعدّ تتبّع OpenTelemetry GenAI إحدى الطرق لجمع بيانات الاستخدام التي تحتاجها لبناء هذا الخط الأساسي.
• عتبات الإنفاق. تحدّ الحدود القصوى بالساعة أو اليومية الواردة في الخطوة 7 من الضرر على النطاق اليومي الذي أبلغت عنه Google، وهو ما لا تستطيعه المراجعة الشهرية.
• الأنماط غير المعتادة. راقب الاستدعاءات لنماذج لا تستخدمها عادةً، والمناطق الجديدة، وعناوين IP المصدرية غير المألوفة، والنشاط في ساعات غير معتادة.
• الهوية، لا المفاتيح فقط. تعامل مع أي رمز هوية سحابية مسروق على أنه نقطة دخول محتملة لهجوم LLMjacking.

ولم يبدأ هذا الاتجاه مع Fireworks. فقد أفادت Sysdig بزيادة بمقدار 10 أضعاف في طلبات LLMjacking خلال يوليو 2024، وبتضاعف عدد عناوين IP الفريدة المشاركة في هذه الهجمات خلال النصف الأول من 2024.

أخطاء شائعة ترتكبها الفرق بعد اختراق مزوّد استدلال

• اعتبار الحذف إلغاءً. مسح سرّ من لوحة التحكم مجرد إجراء تنظيمي، وليس تدويرًا (راجع الخطوة 2).
• المبالغة في تفسير شارة ZDR. راجع جدول الاحتفاظ قبل افتراض أن عبء عمل ما لم يُخزَّن قط.
• تدوير المفتاح الواضح فقط. مفاتيح IAM ومفاتيح حسابات الخدمة ورموز GitHub المخزّنة بجوار مفتاح النموذج مهمة بالقدر نفسه. ففي تحقيقات Google، كانت رموز الهوية السحابية هي نقطة الدخول الأكثر شيوعًا.
• اعتبار النشرة الأولى نهائية. هنا اتسع النطاق من الأسرار المخزّنة إلى معلومات الفوترة ومجموعات البيانات والنماذج غير المكتملة. أعد التحقق من مدى تعرّضك مع كل تحديث.
• انتظار الفاتورة الشهرية. بمعدلات الخسارة اليومية الموصوفة أعلاه، تصل الفاتورة بعد فوات الأوان بكثير.

تحفّظات: ما لا يزال مجهولًا وكيف تقرأ الأرقام

• لم تكشف Fireworks عن عدد العملاء المتأثرين.
• الادعاء بأن المهاجمين لم يكونوا يستهدفون أوزان النماذج صادر عن الرئيس التنفيذي لـFireworks ولم يُتحقَّق منه بشكل مستقل.
• أرقام تكاليف LLMjacking مصدرها تحقيقات مجموعة Google لاستخبارات التهديدات وSysdig بشأن ضحايا آخرين، لا هذه الحادثة. وهي تُظهر ما هو ممكن، لا ما خسره عملاء Fireworks.
• تعود أرقام Sysdig إلى 2024 وتعكس أسعار النماذج وأحجام الهجمات في تلك الفترة.
• ينطبق رقم «أقل من 1 بالمئة» الخاص بـNotion على مساحات عمل Notion فقط.
• تعتمد التزامات الإخطار على ولايتك القضائية وعقودك، لذا استعن بمشورة قانونية حيثما انطبقت.