13,000 لقطة شاشة داخلية انتهى بها المطاف على GitHub العام، ولم يضعها أي مهاجم هناك

وجد باحثون أمنيون أكثر من 13,000 لقطة شاشة داخلية من أكثر من 300 مؤسسة موجودة في مستودعات GitHub العامة. لم تُسرق لقطات الشاشة هذه. بل نشرها وكلاء البرمجة الذين كانت المؤسسات تستخدمهم، أثناء العمل العادي.

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

كيف تنتهي لقطة شاشة في مستودع عام

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

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

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

لماذا هذا ليس خطأً صغيراً

غالباً ما تكون لقطة الشاشة الداخلية أكثر كشفاً مما يتوقع الناس. قد تُظهر لوحة معلومات بأسماء العملاء، أو لوحة إدارة بالتسعير، أو بيئة staging، أو متعقب أخطاء، أو نافذة محادثة في زاوية الشاشة. وقد تُظهر حالة منتج لم يُطلق بعد. وإجمالاً، فإن 13,000 صورة من 300 مؤسسة تشكّل خريطة لما كانت تلك الشركات تعمل عليه.

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

لماذا يزيد الوكلاء الأمر سوءاً

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

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

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

كيف يبدو الحل

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

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

لماذا تستمر الأعداد في النمو

عدد 13,000 صورة من 300 مؤسسة ليس رقماً ثابتاً. إنه صورة آنية للمستودعات التي كانت عامة وقت الفحص، وسيرتفع العدد مع تبنّي مزيد من الفرق للوكلاء ومع رفع مزيد من المستودعات. فحص الباحثون المستودعات العامة، ما يعني أن الإجمالي الحقيقي، بما يشمل المستودعات الخاصة حيث حدث الخطأ نفسه، غير قابل للمعرفة من الخارج.

ما لا يقوله التقرير

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

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

النمط الكامن وراء ذلك

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

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

ما ينبغي فعله هذا الأسبوع

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

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