ثغرة Writer AI الخطيرة: تسريب رموز الجلسات بين الشركات

تكشف ثغرة Writer AI الخطيرة عن خلل عزل جلسات قد يسمح بالاستيلاء على حسابات مؤسسية وتسريب بيانات حساسة عبر رابط معاينة واحد فقط.

ما هي ثغرة Writer AI ولماذا أثارت كل هذا القلق؟

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

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

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

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

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

لماذا يعد الخلل حرجاً إلى هذا الحد؟

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

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

كيف عملت WriteOut خطوة بخطوة داخل Writer؟

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

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

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

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

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

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

ماذا كان يحتاج المهاجم لتنفيذ الهجوم؟

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

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

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

ما البيانات التي كانت معرضة للخطر بسبب ثغرة Writer AI؟

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

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

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

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

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

إذا حصل المهاجم على مثل هذه المعلومات، فإن الخطر لم يعد محصوراً داخل Writer فقط، بل قد يمتد إلى أنظمة أخرى مرتبطة به. ولهذا السبب تنظر المؤسسات الحديثة إلى الثغرات السحابية باعتبارها نقاط ارتكاز محتملة لهجمات أوسع من التطبيق الأساسي ذاته.

ما نوع الأصول الحساسة التي قد تتأثر؟

• المحادثات الخاصة بين المستخدمين ووكلاء الذكاء الاصطناعي.
• الوثائق الداخلية والملفات المرفوعة أو المتصلة بالمنصة.
• إعدادات الوكلاء والتطبيقات المبنية عبر Writer Framework.
• التكوينات الإدارية والسياسات المرتبطة بالعمل المؤسسي.
• النماذج الخاصة أو المخصصة داخل بيئة العمل.
• الموصلات التي تربط Writer بخدمات أو قواعد بيانات أخرى.
• بيانات اعتماد النماذج اللغوية الكبيرة ومفاتيح الربط.

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

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

كيف كسرت الثغرة نموذج المسؤولية المشتركة وعزل المستأجرين؟

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

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

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

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

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

لماذا يعتبر هذا السيناريو معقداً في بيئات الذكاء الاصطناعي؟

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

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

كيف أصلحت Writer المشكلة ولماذا فشلت الحواجز السابقة؟

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

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

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

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

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

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

ما الذي نتعلمه من طريقة التجاوز؟

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

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

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

ماذا تعني ثغرة Writer AI للشركات ومستخدمي المنصات التوليدية؟

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

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

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

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

• هل توجد بيئات معاينة أو تنفيذ منفصلة فعلاً عن جلسات الإنتاج؟
• هل تنتقل ملفات تعريف الارتباط أو الرموز إلى بيئات غير موثوقة؟
• هل تراقب المنصة السلوك وقت التشغيل أم تكتفي بفحص التعليمات؟
• كيف تُدار الصلاحيات إذا سُرقت جلسة مستخدم إداري؟
• هل توجد حدود واضحة بين بيانات كل مؤسسة وأي مؤسسة أخرى؟

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

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