اختراق حسابات GitHub: حملة wfx-loot تسرق أسرار CI

ما هي حملة wfx-loot على GitHub؟

wfx-loot حملة يستخدم فيها مهاجم بيانات اعتماد GitHub مسروقة لدفع سير عمل خبيث إلى المستودعات التي تستطيع تلك الحسابات الكتابة فيها، فيسرق أسرار GitHub Actions وبيانات اعتماد السحابة ^[1]. وسمّتها Aikido Security، التي أبلغت عنها أولاً، تيمناً بتسمية المهاجم نفسه للبرمجية الخبيثة («wfx») والكلمة التي يستخدمها للأسرار المسروقة («loot») ^[1]. وتنسب SafeDep أيضاً إلى Aikido أول تقرير ^[5].

وتسمّي StepSecurity أداة السرقة نفسها «wfx» وتشدد على نقطة جوهرية: المهاجم لا يستغل خللاً في GitHub Actions ^[2]. بل يستخدم رموزاً صالحة لحسابات مطورين وروبوتات حقيقية، فيفتح طلبات سحب ويدفع إيداعات كما يفعل المطور ^[2][4].

وترى Aikido أن الهدف الرئيسي هو أسرار CI لا الانتشار عبر حزم البرمجيات، وإن وصلت الحمولة إلى حزمة واحدة على الأقل في Packagist وأخرى في Go عبر مشغّلات النشر الآلي ^[1]. وتفيد BleepingComputer، اعتماداً على تحليل Aikido، بأن بعض الحسابات المخترَقة تعود إلى مؤسسات كبيرة ^[3].

ما حجم هجوم wfx-loot؟

تحصي Aikido 4,837 حساباً مخترَقاً فتحت طلبات سحب استكشافية في 61,764 مستودعاً، وعملت أداة السرقة في 1,806 مستودعات على الأقل ^[1]. وتختلف الأرقام قليلاً بين الباحثين لأن كلاً منهم بحث في GitHub في وقت مختلف والحملة ما زالت نشطة.

• Aikido: 4,837 حساباً و61,764 مستودعاً؛ و10,431 طلب سحب دخلت مستودعات لا يملكها الحساب؛ و92% منها لا يزال مفتوحاً؛ وما لا يقل عن 50 مستخدماً مخترَقاً ينشرون حزماً على npm وGo وPackagist وPyPI وcrates ^[1].
• Aikido (الرقم الملخّص): شغّلت 1,835 مستودعاً على الأقل الحمولة وسُرقت بيانات اعتماد منها؛ وتستخدم BleepingComputer هذا الرقم ^[1][3].
• StepSecurity: أكثر من 63,000 طلب سحب استكشافي حتى الساعة 07:40 بالتوقيت العالمي المنسق في 12 نوفمبر، نحو 90% منها لا يزال مفتوحاً ^[2].
• SafeDep: تلقت 8,093 مستودعاً إيداعات خبيثة بين 10 و12 نوفمبر، وهو رقم لا يعني بالضرورة، كما تلاحظ SecurityWeek، أن أداة السرقة نُفّذت ^[5][4].

وتحذّر Aikido من أن عدد عمليات التنفيذ لديها قد يقلل من حجم الأثر، لأن سجلات التشغيل حُذفت في المستودعات المتضررة ^[1].

كيف تعمل أداة سرقة wfx-loot؟

في كل مستودع يستطيع رمز مسروق الكتابة فيه، يفحص المهاجم ثم يدفع الحمولة ثم ينظّف الآثار خلال دقيقة تقريباً ^[1].

1. الفحص: طلب سحب بعنوان «docs: dependency audit notes» من فرع باسم wfx-docs يضيف ملف ملاحظات صغيراً. وتقول StepSecurity: «طلب السحب لا يفعل شيئاً بمفرده»؛ فهو يبيّن فقط أن الرمز يملك صلاحية الكتابة ^[2][4].
2. الحمولة: يصل سكربت شل من نحو 1,500 سطر بإحدى ثلاث طرق: حقنه في سير عمل قائم («ci: refresh build cache»)، أو كسكربت مع خطاف postinstall في npm («chore: add ci helper»)، أو كسير عمل جديد على فرع chore/ مؤقت («chore: add dependency audit workflow») ^[1].
3. التنظيف: يتراجع المهاجم عن التغيير ويحذف تشغيل سير العمل وسجلاته ^[1]. وغالباً ما يكون رقم التشغيل المفقود الأثر الوحيد ^[1].

يجمع السكربت أسرار GitHub Actions ورموزه، وبيئة المشغّل (runner) كاملة، وملفات بيانات الاعتماد الخاصة بـAWS وAzure وGoogle Cloud وDocker وKubernetes وnpm وPyPI وSSH وغيرها، وسجلات أوامر الشل، ومفاتيح مزوّدي الذكاء الاصطناعي وأدوات المطورين ^[1][3]. بل ويقرأ ذاكرة العمليات الجارية على المشغّل ^[1][4]. ووجدت Aikido أن النسخ التي حلّلتها أرسلت البيانات المسروقة عبر HTTP POST فقط إلى خوادم يتحكم بها المهاجم ^[1]. ولاحظت StepSecurity لاحقاً تغيراً: فمنذ نحو الساعة 05:30 بالتوقيت العالمي المنسق في 12 نوفمبر، صارت النسخ الجديدة ترسل البيانات عبر Telegram فقط، ولذلك لم يعد حظر عناوين الخوادم المنشورة وحده كافياً لإيقافها ^[2].

لماذا لا يكفي تبديل الأسرار؟

لأن أداة السرقة تحاول زرع أبواب خلفية تصمد أمام تبديل بيانات الاعتماد ^[1][2]. وتصف Aikido ثلاث حيل للبقاء ^[1]:

• فحوص حالة مزوّرة: تقول Aikido إنها تنشر فحوص «نجاح» مزيفة بأسماء الفحوص المطلوبة في المستودع، وقد يتجاوز ذلك بوابات الدمج في حماية الفروع ^[1]. ووجدت StepSecurity هذه الميزة معطّلة في جميع العينات الـ101 التي فحصتها ^[2].
• إعادة كتابة سياسة الثقة في AWS: يمكنها ضبط سياسة الثقة لدور بحيث تسمح لأي حساب AWS ^[1].
• حقن هوية موحّدة في Azure: يمكنها إضافة بيانات اعتماد موحّدة تحمل أسماء wfx-ci-… إلى تطبيقات Azure AD، فتتيح لسير العمل في المستودع المخترَق أن يصادق دون سر مخزّن ^[1].

ويمكنها أيضاً إنشاء رموز GitHub OIDC وتبديلها بجلسات AWS وGoogle Cloud وAzure، والتسلسل إلى أدوار IAM أخرى، وإنشاء مفاتيح وصول AWS طويلة الأمد ^[1][3]. ولهذا تقول StepSecurity: «أزيلوا آليات البقاء، لأن التبديل وحده لا يفعل ذلك» ^[2].

كيف أتحقق مما إذا كانت مستودعات GitHub لديّ قد أُصيبت؟

ابحث عن طلب السحب الاستكشافي ورسائل إيداعات المهاجم منذ 10 نوفمبر، ثم ابحث عن فجوات في أرقام تشغيل سير العمل ^[2][1].

1. ابحث في طلبات السحب عن «docs: dependency audit notes» وعن فروع باسم wfx-docs أو chore/ متبوعة بثمانية أحرف ^[1][2].
2. ابحث في الإيداعات منذ 10 نوفمبر عن «ci: refresh build cache» و«ci: restore» و«ci: cleanup» و«chore: add ci helper» و«chore: add dependency audit workflow» ^[2].
3. لكل نتيجة، افتح تبويب Actions وابحث عن رقم تشغيل مفقود مباشرة بعد الإيداع؛ وتصف StepSecurity هذا بأنه العلامة الأوثق على أن الأداة عملت ^[2].
4. دوّن الحساب الذي دفع الإيداعات: فرموز ذلك الحساب مسروقة ^[2]. وإذا وُجد طلب سحب استكشافي فالحساب مخترَق حتى لو لم تعمل أي حمولة ^[1].

لا تعتمد على غياب الآثار. تقول Aikido إن غياب مخرجات wfx-loot أو مدخلات ذاكرة التخزين المؤقت wfx- أو ملخصات الخطوات الخاصة لا يعني أن البيانات لم تؤخذ، لأن هذه القنوات عُطّلت في هذه الحملة ^[1]. وتشير Aikido أيضاً إلى أن الحمولة قد تُنشر في مستودعات خاصة كما في العامة ^[1].

ماذا أفعل إذا عملت أداة السرقة؟

افترض أن كل سر ودور سحابي كان متاحاً لسير العمل المتضرر قد اختُرق، وبدّلها، ثم ابحث عن آليات البقاء ^[1][2].

• بدّل: كل أسرار المستودع والبيئة والمؤسسة التي كان بوسع المهمة الوصول إليها، لا تلك التي يذكرها سير العمل فقط؛ ورموز النشر في npm وPyPI وغيرهما؛ ومفاتيح السحابة المخزّنة كأسرار ^[2].
• افحص الحزم: ابحث عن إصدارات حزم نُشرت بعد الإيداع الخبيث ^[2].
• AWS: ابحث عن سياسات ثقة تسمح لأي جهة في AWS، ومفاتيح وصول IAM أُنشئت منذ 10 نوفمبر، وجلسات CloudTrail تبدأ بـwfx- ^[2].
• Azure: احذف بيانات الاعتماد الموحّدة للهوية التي تحمل أسماء wfx-ci-* في تسجيلات التطبيقات ^[2].
• Google Cloud وVault وKubernetes: راجع توليد الرموز وعمليات تسجيل الدخول التي جرت برموز تسجيل الدخول الخاصة بـGitHub Actions ^[2].
• GitHub: احذف الفروع المتبقية، وأغلق طلبات السحب الاستكشافية، وتأكد من أنه لم يُدمج شيء بناءً على فحص مزوّر، وألغِ رموز الحساب ومنح OAuth ومفاتيح SSH ^[2].
• الرموز، بحسب وثائق GitHub: راجع رموز الوصول الشخصية في الإعدادات (Settings) ثم إعدادات المطور (Developer settings) واحذف ما لا تعرفه أو لا تحتاج إليه؛ وتوصي GitHub بالرموز الدقيقة الصلاحيات، وبأقل الصلاحيات الضرورية فقط، وبتاريخ انتهاء، لأن الرمز الكلاسيكي يستطيع الوصول إلى كل مستودع تستطيع الوصول إليه ^[6].

ويعمل خطاف npm أيضاً على أجهزة المطورين: فكل من شغّل npm install خلال النافذة القصيرة شغّل أداة السرقة محلياً وعليه تبديل بيانات اعتماده هو أيضاً ^[2]. وتلخّص SecurityWeek النصيحة المشتركة من عدة شركات أمنية: ألغوا الرموز المخترَقة، وبدّلوا الأسرار المنكشفة، وتحققوا من وجود تغييرات غير مصرّح بها في السحابة ^[4]. وبالنسبة إلى حسابات الروبوتات، تقترح StepSecurity أيضاً مراجعة ما إذا كانت تحتاج أصلاً إلى إذن لتجاوز حماية الفروع ^[2]. وتجعل حماية تسجيل الدخول القوية حملات الحسابات المسروقة أصعب؛ راجع المصادقة الثنائية: أي طريقة 2FA هي الأكثر أماناً؟.

ما الحزم التي تأثرت؟

تذكر Aikido حزمة في Packagist ووحدة Go التقطتا الحمولة عبر النشر الآلي ^[1].

• Packagist: digitalelvis/neuronai-studio الإصدار 3.14.3؛ وتقول Aikido إن أي جهاز ثبّتها أو فتحها يجب اعتباره مخترَقاً ^[1].
• Go: github.com/onuragtas/docker-env الإصداران v1.0.278 وv1.0.280؛ والحمولة موجودة في ملف سير عمل GitHub Actions فقط، أما شيفرة Go المصدرية والملفات الثنائية فلم تتغير، ولا تشغّل عمليات بناء Go ملفات سير العمل، لكن Aikido توصي مع ذلك بإزالة هذه الإصدارات ^[1].

وتختلف الأعداد: فتقول SafeDep إن ثلاث حزم في Packagist وفي وكيل وحدات Go تحمل الحمولة، وتذكر SecurityWeek إصدارات من وحدتي Go ^[5][4]. وتضيف SafeDep أن الحمولة لم تعمل لدى المستهلكين المعتادين الذين يثبّتون هذه الحزم بـcomposer require أو go get ^[5]. تحقق من القائمة الحالية لكل باحث قبل الاعتماد على أي منها.

من وراء wfx-loot وكيف حصلوا على الرموز؟

لا يحدد أي من التقارير المذكورة هنا هوية المهاجم، وتقول StepSecurity إنها لم تتوصل إلى كيفية الحصول على الرموز ^[2][4].

وجدت StepSecurity 173 طلب سحب استكشافياً، من 19 حساباً، جرت عبر رموز صادرة لتطبيق Fly.io GitHub App؛ وقالت إنها لم تستطع تحديد كيفية الحصول عليها وليس لديها دليل على اختراق بنية Fly.io التحتية ^[2][4].

ووجدت Aikido تداخلاً مع حسابات أصابتها موجة GhostAction في أكتوبر، ورأت wfx-loot محقونة في ملفات سير عمل GhostAction في أكثر من 100 مستودع، لكنها قدّرت أنهما حملتان مختلفتان على الأرجح يديرهما فاعلون مختلفون، لأن بيانات الاعتماد المسروقة كثيراً ما تنتهي لدى عدة مجموعات ^[1]. ولاحظت أيضاً تعليقات بالإندونيسية في بعض إصدارات البرمجية الخبيثة الأحدث ^[1]. ويهم هنا تخزين الرموز بعناية؛ ويتناول مديرو كلمات المرور: كيف يعملون وهل هم آمنون الأساسيات.