ثغرة واحدة كادت تحول مساعد Meta الذكي إلى بوابة كاملة للسيطرة على جهاز Mac

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

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

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

#لماذا كانت Muse هدفًا ذا قيمة مرتفعة؟

قدّمت Meta مساعد Muse بوصفه وكيلًا ذكيًا قادرًا على تنفيذ مجموعة واسعة من المهام نيابةً عن المستخدم. ووفقًا لوصف الخدمة، يستطيع المساعد التعامل مع مواعيد ونماذج وخدمات عملاء، وتنفيذ عمليات شراء، وإنشاء مستندات وصور، والاتصال بخدمات وتطبيقات مختلفة.

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

• الوصول إلى الملفات والكتابة على القرص.
• استخدام الكاميرا والميكروفون.
• التعامل مع التقويم وبعض بيانات الحسابات.
• التفاعل مع خدمات وتطبيقات خارجية سبق للمستخدم ربطها بالمساعد.

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

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

#كيف عملت الثغرة؟

اكتشف الباحث الأمني المتخصص في macOS باتريك واردل Patrick Wardle أن تطبيق Muse كان يتيح لتطبيقات محلية أو أوامر منفذة من الطرفية تعديل مجموعة من الإعدادات الداخلية غير الموثقة.

بعض هذه الإعدادات كان محدود التأثير، مثل خيارات واجهة المستخدم. لكن إعدادًا واحدًا كان أكثر خطورة بكثير: عنوان الوجهة المستخدمة في عملية النسخ الصوتي Transcription Endpoint.

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

يمكن تبسيط مسار الخطر بهذه الصورة:

Local Process / Terminal Command
        |
        v
Modify Muse Configuration
        |
        v
Replace Transcription Endpoint
        |
        v
Attacker-Controlled Server
        |
        v
Muse Authentication Token Exposure
        |
        v
Abuse Muse Privileges and Connected Services

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

#لماذا يمثل هذا كسرًا مهمًا لنموذج حماية macOS؟

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

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

هو ببساطة يستفيد من التطبيق ذي الامتيازات الأعلى كوسيط.

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

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

#من تعديل إعداد إلى السيطرة على الوكيل

بحسب واردل، كان من الممكن استغلال الثغرة عبر خادم يتحكم به المهاجم يعمل كوسيط بين مستخدم Muse والخدمة الأصلية.

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

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

هذا يغير اقتصاديات الهجوم بالكامل. فبدل أن يحتاج المهاجم إلى:

Privilege Escalation
+ Credential Theft
+ Camera Access
+ File Access
+ Session Hijacking
+ Persistence Logic

يمكنه محاولة استغلال وكيل موثوق سبق أن حصل على معظم هذه القدرات بطريقة شرعية من المستخدم.

#ClickFix: عندما لا يكون الاستغلال المحلي حاجزًا فعليًا

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

لكن هذا لا يعني أن السيناريو عديم الخطورة.

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

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

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

#لماذا أثار النسخ الصوتي السحابي انتقادًا إضافيًا؟

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

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

لو كانت عملية النسخ تتم محليًا بالكامل، فإن سيناريو تغيير عنوان الخادم الخارجي لم يكن سيظهر بالطريقة نفسها.

يمكن مقارنة النموذجين بهذا الشكل:

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

#أين أخفقت حدود الثقة؟

توضح الحالة أن الخلل لم يكن مجرد Input Validation تقليدي، بل مزيجًا من قرارات تصميمية سمحت بتمرير الثقة بين مكونات لا يفترض أن تملك الدرجة نفسها من النفوذ.

أبرز هذه النقاط:

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

#من منظور GRC: الوكيل الذكي أصل عالي الحساسية

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

الوكيل الذي يستطيع الوصول إلى البريد والملفات والتقويم والخدمات الخارجية وموارد النظام يجب التعامل معه كأصل عالي الحساسية High-Privilege Asset، لا كتطبيق مكتبي عادي.

وهذا يغيّر طريقة تقييمه في عدة جوانب:

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

#Amazon تمنع Muse من التسوق على منصتها

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

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

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

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

#ما الذي يجعل هذه الثغرة مهمة لما بعد Muse؟

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

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

كلما اقترب الوكيل من تنفيذ المهام الكاملة بدلًا من مجرد تقديم إجابة نصية، أصبحت الأسئلة التالية أكثر أهمية:

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

هذه ليست أسئلة تحسين إضافية، بل جزء من نموذج الأمان الأساسي لأي وكيل يعمل بصلاحيات مرتفعة.

#إصلاح الثغرة لا ينهي النقاش

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

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

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

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

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

#المصادر

• WIRED: Meta’s Muse AI Assistant Rolled Out With a Serious Security Flaw
• Ars Technica: Muse, Meta’s extraordinarily privileged AI assistant, has a serious 0-day
• Meta AI: Muse
• Objective-See / Patrick Wardle