BTCPay Server يُصدر تحديثًا عاجلًا لإغلاق ثغرة خطيرة في بيانات اعتماد LND بعد سحب أرصدة محافظ Lightning لتجار

أطلق BTCPay Server الإصدار 2.4.2 لمعالجة ثغرة حرجة سمحت بالوصول عن بُعد إلى ملفات بيانات اعتماد LND دون مصادقة، وذلك بعد أن استغل مهاجمون الخلل لسحب أرصدة محافظ Lightning الخاصة ببعض التجار. ووفق ملاحظات الإصدار، تتمحور المشكلة حول ملفات ‎.macaroon‎ التي يستخدمها LND لإدارة صلاحيات الوصول. عمليًا، تعمل هذه الملفات كمفاتيح: إذا حصل المهاجم على الملف ذي الصلاحيات الحساسة، قد يتمكن من تنفيذ عمليات على عقدة Lightning بما يتجاوز ما قصده المشغّل. وأعلن داعمو BTCPay أيضًا عن مكافأة لاسترداد الأموال تعادل 10% من المبالغ المُعادة، على ألا تتجاوز 3 BTC. وبالأسعار الحالية، يصل الحد الأقصى للمكافأة إلى نحو 190,000 دولار. ويؤكد المشروع أن الحادث لا يتعلق باستغلال في بروتوكول بيتكوين، ولا يمثل فشلًا في محفظة "أون-تشين" أصلية. المسألة هي ثغرة أمنية على مستوى الخادم تمس بعض إعدادات BTCPay Server التي تستخدم LND، وهو فرق جوهري لأن طريقة المعالجة تختلف. لمزيد من التفاصيل، يُرجى الرجوع إلى صفحة المشروع الرسمية على Github. ملخص سريع (TL;DR): - BTCPay Server v2.4.2 يُصلح تسريبًا حرجًا لبيانات اعتماد LND. - تقارير تفيد بسحب أرصدة محافظ Lightning لتجار عبر إعدادات معرضة للخطر. - مكافأة الاسترداد: 10% من الأموال المُعادة بحد أقصى 3 BTC. لماذا تُعد مشكلة بيانات اعتماد LND مهمة؟ يُستخدم BTCPay Server على نطاق واسع لأنه يتيح للتجار قبول مدفوعات بيتكوين دون الاعتماد على معالج مدفوعات مركزي. هذا النموذج "السيادي" يمنح مرونة كبيرة، لكنه يجعل أمن الخادم جزءًا أساسيًا من إدارة المدفوعات. تشغيل البنية التحتية ذاتيًا يعني مسؤولية تحديثها وضبط إعداداتها بالشكل الصحيح. خطورة الثغرة في 2.4.2 تنبع من أن "ماكارون" LND قد تمنح صلاحيات للوصول إلى وظائف العقدة. وبحسب نطاق الأذونات، قد يكون تعرّض ملف macaroon للخطر مكافئًا عمليًا لتعريض مفتاح حرج للخطر. بالنسبة لمشغلي Lightning، حماية بيانات الاعتماد لا تقل أهمية عن حماية المفاتيح الخاصة في الواقع العملي: قد تكون المحفظة سليمة تقنيًا، لكن تسريب بيانات الوصول من الخادم يضع الأموال تحت تهديد مباشر. ليس هجومًا على بيتكوين نفسها قد تُفهم مثل هذه الحوادث بشكل خاطئ. سماع أن "خوادم مدفوعات بيتكوين" تعرضت للسحب قد يدفع البعض للاعتقاد بوجود خلل في بيتكوين. ما حدث هنا مختلف: لم يتم استغلال بروتوكول بيتكوين الأساسي. القضية تخص نشرات BTCPay Server التي تستخدم LND وتعرّض ملفات بيانات اعتماد. لذلك فهي حادثة أمن تطبيقات وبنية تحتية، وليست إخفاقًا في إجماع بيتكوين أو في سلسلة الكتل. لا يقلل هذا من أثرها على المتضررين؛ خسارة أموال Lightning تبقى خسارة. لكن توصيف المشكلة بدقة ضروري لأن الحل مختلف: بيتكوين لا تحتاج إلى تحديث بروتوكولي، بينما يحتاج مشغلو BTCPay Server إلى التحديث الفوري، ومراجعة الإعدادات، وتأمين بيانات اعتماد العقدة. مخاطر مختلفة لبنية Lightning صُممت Lightning لمدفوعات بيتكوين الأسرع والأقل تكلفة، لكنها تضيف تعقيدًا تشغيليًا. مشغلو العقد يتعاملون مع القنوات، والسيولة، والنسخ الاحتياطية، والوصول عن بُعد، والتوجيه، وبيانات الاعتماد، وتعرّض الخادم للإنترنت. وهذا يخلق نموذجًا أمنيًا مختلفًا عن الاحتفاظ بـ BTC في التخزين البارد. التاجر الذي يشغّل Lightning لا "يحفظ بيتكوين" فقط؛ بل يدير برنامج مدفوعات حيًا متصلًا بالإنترنت. يمكن أن يكون ذلك آمنًا عند الإدارة السليمة، لكنه يتطلب انضباطًا: التحديثات، وضبط الصلاحيات، وطريقة تخزين بيانات الاعتماد، والمراقبة المستمرة. مكافأة الاسترداد: محاولة لاستعادة الأموال تضيف مكافأة الاسترداد بُعدًا آخر للحادثة. تخصيص 10% من الأموال المُعادة بحد أقصى 3 BTC يهدف إلى خلق حافز للاسترداد أو لتقديم معلومات. قد يُجدي ذلك إذا رأى المهاجمون أو الوسطاء أو من لديهم معرفة بمسار الأموال أن التعاون أفضل من استمرار المخاطر. لا تضمن المكافآت استعادة الأموال، لكنها قد تفتح قناة للتفاوض أو الإفصاح. غالبًا ما تلجأ مشاريع العملات المشفرة إلى هذا النهج بعد الاختراقات لأن الأموال المسروقة قد تكون قابلة للتتبع، ويمكن مراقبة الإيداعات في منصات التداول، وقد يواجه المهاجمون صعوبة في التسييل دون ترك أثر. ما الذي ينبغي على المشغلين استخلاصه؟ الخلاصة العملية واضحة: تحديث BTCPay Server ومراجعة أي تعرّض لـ LND. لا ينبغي الافتراض أن نظامًا عمل لسنوات سيبقى آمنًا تلقائيًا. بيئة التهديد تتغير باستمرار، والمهاجمون يبحثون عن إصدارات قديمة، وسوء ضبط الإعدادات، وتسريب بيانات اعتماد، وصلاحيات ضعيفة، وخدمات مكشوفة على الإنترنت. يظل BTCPay Server أداة مهمة لتجار بيتكوين، لكن الحفظ الذاتي والاستضافة الذاتية يأتيان بمسؤوليات. الإصدار 2.4.2 هو نقطة الإصلاح لهذه المشكلة، وأي جهة تستخدم إعدادات متأثرة ينبغي أن تتعامل مع التحديث بوصفه أمرًا عاجلًا. مدفوعات بيتكوين يمكن أن تكون سيادية، لكن السيادة تعني أيضًا الصيانة. تستند هذه المادة إلى مواد إصدار BTCPay Server v2.4.2 وتفاصيل مكافأة الاسترداد الخاصة بالمشروع. أعدّها قسم الأخبار وحررها Samuel Rae. يستند هذا التقرير إلى معلومات منشورة على Github.