Grok Build كشف بيانات 35 ألف تطبيق بسبب سرّ وُضع في النطاق الفرعي

تخيّل أنك بنيت خلال عشر دقائق لوحة معلومات داخلية بمساعدة وكيل ذكاء اصطناعي، ثم ضغطت «مشاركة» وأرسلت الرابط إلى زميل. العنوان طويل ويحتوي على كلمات عشوائية، لذا يستحيل تخمينه. ثم يتبيّن أن أي شخص يعرف كيف يستخدم قاعدة بيانات عامة لاستعلامات DNS يستطيع رؤيته. وبحسب باحثي Claroc، هذا بالضبط ما حدث مع Grok Build، وكيل البرمجة بالـ vibe من SpaceXSI (الاسم الذي تحمله الآن الشركة الموحّدة من SpaceX وxAI).

ما الذي انكسر تحديدًا

فكرة المخطط سليمة. تسمى capability-based access control: معرفة الـ URL تساوي حق الوصول. المطلوب فقط ألا يمكن تخمين العنوان أو العثور عليه. ثلاث كلمات عشوائية تعطي نحو 38 بت من الإنتروبيا، أي مليارات التركيبات. تفعل Google شيئًا مشابهًا في Docs، لكن السلسلة العشوائية توضع في المسار، بعد النطاق.

وضع Grok Build الكلمات العشوائية على يسار النطاق، في النطاق الفرعي: cinder-crane-sand-frost.grok.me. وأسماء النطاقات الفرعية تتسرب. فعندما يطلب أحدهم لأول مرة عنوان IP لمضيف جديد، يستقر السجل في قواعد بيانات passive DNS العامة. ثم يكفي البحث عن كل ما ينتهي بـ grok.me. لا حاجة إلى تخمين شيء، يكفي قراءة قائمة جاهزة. أما مسار الـ URL فلا يدخل في استعلام DNS، ولهذا لا تنجح هذه الحيلة مع روابط Google.

عثرت Claroc على 43,601 رابط grok.me. أكثر من 35 ألفًا منها، أي نحو 95%، فتحت التطبيق مع جميع بياناته. ومن بين ما وُجد: 3,784 فحصًا طبيًا لعمال شركة إنشاءات بيروفية، وقائمة بـ 3,565 موظفًا في مستشفى، وجدول بـ 22 فنيًا في Tesla مع الإنتاجية والمكافآت، ونحو 4,000 طلب لشركة نقل سيارات مع الأسعار والهوامش. ووُجد أيضًا 24 تطبيقًا تخص SpaceXSI نفسها: خطة تأهيل لمندوب مبيعات مصنّفة confidential وخريطة تضم 594 حسابًا لعملاء.

الإعداد الافتراضي في مواجهة الواقع

وفق اختبارات آساف أبروزبر، المدير التقني لـ Claroc، يضبط Grok Build الوصول افتراضيًا على «Anyone with the link». ولإغلاق التطبيق، يجب على المستخدم أن يختار بنفسه «المدعوون» أو «أنت فقط». وأكد ممثل Cursor (التي اشترتها SpaceXSI مؤخرًا) أن التطبيقات خاصة افتراضيًا. لكن اختبارات Claroc تنفي ذلك. ولم يصل أي رد على الأسئلة اللاحقة من Ars Technica.

والتسلسل الزمني دالّ أيضًا. أبلغت Claroc عن التسرب يوم الأحد، ولم تتلقَّ ردًا، فأشارت في X إلى ماسك ومدير Grok. ولم تختفِ الروابط المؤدية إلى 24 تطبيقًا داخليًا إلا بعد ساعات عدة من طلب الصحفيين. أما بقية البيانات فبقيت متاحة.

المشكلة أوسع من Grok وحده. فـ Lovable وBolt وReplit تمنح بدورها كل تطبيق عنوانًا خاصًا، لذا فإن آثار DNS لديها هي نفسها. غير أن Grok احتوى على أكبر قدر من البيانات المؤسسية الحساسة. وقد علّقت Meta Muse مؤخرًا ميزة المشاركة بعد تسرب مشابه. أما Claude artifacts وChatGPT share وGemini share فمصممة بشكل صحيح: السرّ في المسار، وDNS لا يراه.

ماذا تفعل عمليًا

إذا بنيتَ أنت أو فريقك شيئًا في Grok Build، فادخل أولًا إلى إعدادات جميع التطبيقات وغيّر الوصول إلى «المدعوون» أو «أنت فقط». وينبغي التحقق من الأمر نفسه في Lovable وBolt وReplit. وتذكّر أن الرابط الذي وصل مرة إلى passive DNS ربما دخل بالفعل في قواعد بيانات أطراف أخرى. وإذا كانت بداخله بيانات شخصية أو عروض تجارية، فأغلق الوصول وقيّم ما إذا كان يجب إخطار الأشخاص والعملاء.

أما لمن يبنون منصات بروابط مشاركة، فالدرس هو التالي. لا يجوز وضع سرّ الـ capability في اسم المضيف، بل في المسار أو في رمز مميّز بعد النطاق فقط. وللأدوات الداخلية من الأفضل تفعيل المصادقة أصلًا، وجعل الوصول العام اختيارًا واعيًا لا قيمة افتراضية.

وهناك تحفظات أيضًا. الأرقام مأخوذة من دراسة Claroc، ولا يوجد حتى الآن تحقق مستقل. والتطبيق العام لا يحتوي بالضرورة على بيانات حساسة، وقد يكون كثير من الـ 35 ألفًا مجرد عروض تجريبية. ولم توضح SpaceXSI كيف وصلت الوثائق الداخلية إلى تطبيقات مفتوحة، ولا إن كانت ستُخطر عملاءها. لكن الاستنتاج الرئيسي لا يتغير: البرمجة بالـ vibe تسرّع الإطلاق، ومعه أخطاء إعدادات الوصول. ويجب أن تشمل عادة «ولّدت وشاركت» التحقق من هوية من يستطيع فتح الرابط.