BTCPay Server تدعو إلى إيقاف تشغيل الخوادم بعد تقارير عن سحب غير مصرح به من المحافظ الساخنة

أمر بالإيقاف بعد عمليات سحب غير مصرح بها

دعت منصة BTCPay Server، وهي برمجيات مفتوحة المصدر يستخدمها التجار لقبول مدفوعات البيتكوين على خوادمهم الخاصة، المشغلين يوم 2 نوفمبر إلى إيقاف تشغيل خوادمهم بعد ورود تقارير عن اختفاء أموال محفوظة في المحافظ الساخنة دون تصريح على عدة خوادم. أكد الفريق التقارير في منشور رسمي على منصة X، وطالب كل من يشغّل نسخة من البرنامج بإبقائها متوقفة حتى انتهاء التحقيق، موجهاً إياهم إلى الأمر “./btcpay-down.sh”.

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

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

ترقيع أكتوبر واختراق Lightning في أغسطس

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

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

للحادثة سابقة أيضاً. ففي أغسطس، مكّن استغلال لثغرة في الإصدارات السابقة من 2.4.2 مهاجماً من سرقة بيانات اعتماد LND، البرنامج الذي يشغّل عقد الدفع عبر شبكة Lightning، وسحب أموال من عقد Lightning المرتبطة بـBTCPay. وتحتفظ قنوات Lightning بمفاتيحها الخاصة، ما سمح للبيانات المسروقة بإنفاق أرصدة القنوات مباشرة. ذكر الفريق حينها أن المحافظ على السلسلة، بما فيها المحافظ الساخنة المنشأة داخل BTCPay، لم تتأثر بذلك الخلل، وأن عمليات السحب في أغسطس استهدفت مسار Lightning وحده. غير أن المحافظ المذكورة في التقارير الحالية تنتمي بالضبط إلى الفئة التي كانت قد أُخرجت حينها من دائرة الخطر. ولا تنطوي شبكة البيتكوين ذاتها على أي تهمة هنا: فالخسائر تتعلق بتخزين المفاتيح على الخوادم، لا بإجماع إثبات العمل. ولغياب مشغل مركزي يُبلَّغ، يبقى أمر الإيقاف الحماية الوحيدة التي يقدمها الفريق أثناء عمله، ومن يُبقي خوادم عاملة يفعل ذلك على مسؤوليته الخاصة إلى أن يُحدد السبب ويصدر الإصلاح.

يقول شكل الاستجابة الكثير عن حجم المجهول. ففي أغسطس استطاع الفريق حصر تحذيره في الإصدارات السابقة من 2.4.2 وطلب من بقية المستخدمين الترقيع فقط، أما هذه المرة فيغطي أمر الإيقاف جميع الإصدارات، ما يوحي بأن المطورين لا يعرفون بعد أين تقع نقطة الدخول. ولم يُنشر تحليل بعد وقوع الحادثة، ولا معرّفات معاملات المهاجم، ولا جدول زمني للمعالجة، لذا يتعذر التحقق من الخسائر على السلسلة الآن. وقد بلغت اختراقات المحافظ الرعائية أحجاماً أكبر أحياناً، كما حين جادل المدير التنفيذي للاستثمار في Bitwise، مات هوغان، بأن حتى اختراق Binance البالغ 6.3 مليار دولار لا يغيّر المسار طويل الأمد للسوق، لكن أدوات الدفع ذاتية الاستضافة تركّز المخاطر على صغار التجار الذين يديرون مفاتيحهم بأنفسهم. وحتى أنشر الفريق نتائجه، يبقى ما سُحب ومن كم خادم غير معلن.