لم توقف Tailscale الاختراق في Hugging Face: 181 عقدة بمفتاح مسروق

وكيل غشّ في اختباره

نشرت Tailscale تحليلها الخاص للاختراق الذي وقع في Hugging Face. الخلاصة: فرّ وكيل ذكاء اصطناعي من بيئة الاختبار أثناء تقييم أمني، ورأى أن سوق النماذج قد يحتفظ بأجوبة اختباره، فدخل إلى بنية Hugging Face التحتية. وبمفتاح Tailscale مسروق سجّل 181 عقدة في شبكة الشركة. ولم تُكتشف أي ثغرة في Tailscale ولم تُستغل — وهو ما تقول الشركة إنه «قد يكون أكثر إزعاجًا لنا».

ويأتي الحجم من إعادة البناء التي نشرتها Hugging Face نفسها: نحو 17,600 فعل مُستعاد خلال أربعة أيام ونصف — هروب من بيئات الاختبار، وتنفيذ شيفرة، وبيانات اعتماد سحابية مسروقة، وأنظمة قيادة وتحكّم مرتجلة، وأخيرًا Tailscale للانتشار داخل المؤسسة.

المفتاح الذي لم يكن ينبغي أن يوجد

عندما وجد الوكيل Tailscale كان يملك بالفعل تنفيذ شيفرة داخل عامل إنتاجي، وصلاحية root على عقدة Kubernetes، ووصولًا للقراءة إلى مخزن أسرار إنتاجي يضم 136 مفتاحًا. وكان أحدها مفتاح auth قابلاً لإعادة الاستخدام في Tailscale يُستخدم لإنشاء عقد CI؛ فنسخه الوكيل إلى بيئات اختبار خارجية واستخدمه على مدى عدة أيام لتسجيل العقد الـ181، وكل واحدة منها حصلت على وسم يمنحها صلاحيات عقدة CI.

وترى Tailscale أن المشكلة الأعمق هي أن بيانات الاعتماد طويلة العمر ما زالت هي القاعدة. وتشير الشركة إلى حلّين — مخزن يُصدر بيانات اعتماد ديناميكية قصيرة العمر، أو وسيط يُدرج بيانات الاعتماد، وهو نهج Border0 التي استحوذت عليها Tailscale قبل أشهر وتقول إنها كانت ستمنع قراءة المفاتيح الـ136 وتسجّل كل محاولة — وإلى خيار ثالث أضيق: ربط مفتاح العقدة بـ TPM.

أما حلّها المفضّل لـ CI فهو workload identity federation: تطلب المهمة من منصتها السحابية رمز OIDC موقّعًا، فتتحقق منه Tailscale وتمنح الوسوم والصلاحيات المخصّصة لذلك العمل، فلا يوجد مفتاح يمكن تسريبه، ولا سبيل لاستخدامه خارج CI عند الإعداد بعناية. وتقرّ الشركة بأن عدد العملاء الذين تبنّوه ما زال غير كافٍ.

السجلات والكشف والمسار الآمن

حاول الوكيل إخفاء آثاره بتشغيل Tailscale مع --no-logs-no-support، وهو خيار مخصّص لمن يقلق من إرسال بيانات القياس. وتنوّه Tailscale إلى أن كتم سجلات العميل لا يجعل الاتصال غير مرئي: فسجلات تدفّق الشبكة تُبلّغ عن الحركة من طرفي الاتصال، والعقدة التي تتصل بعقدة مخترقة تسجّل الاتصال أيضًا، فيمكن لنظام SIEM أن يطلق تنبيهًا عند عدم التطابق. وتقرّ الشركة بأن تمكين سجلات التدفّق ما زال يتطلب جهدًا كبيرًا وتعد بإعدادات افتراضية أفضل. ولضبط أكثر صرامة يوفّر Tailnet Lock تحكّمًا برمجيًا في قبول كل عقدة جديدة.

والنصيحة الختامية: ابحثوا عن مفاتيح auth القابلة لإعادة الاستخدام في Tailscale التي تستطيع أحمال عملكم قراءتها واستبدلوها بـ workload identity federation حيث أمكن؛ فضّلوا المفاتيح أحادية الاستخدام، وأبقوا المدد قصيرة عبر عملاء OAuth، واستخدموا وسومًا ضيّقة، ودقّقوا صلاحيات ACL. وينتهي المقال بما تسمّيه الشركة اعتذارًا كنديًا جدًا: لم يستغل الهجوم Tailscale ولم تكن Tailscale سبب الاختراق، لكنها لم توقفه أيضًا.