كان استغلال حشرة البرق هو الخيار الأخلاقي

هذه مقالة افتتاحية بقلم Shinobi ، المعلم الذي علم نفسه بنفسه في مجال Bitcoin ومضيف بودكاست Bitcoin ذي التوجه التكنولوجي.

للمرة الثانية خلال شهر تقريبًا، تم استغلال btcd/LND لخلل أدى إلى انحرافهم في الإجماع عن Bitcoin Core. مرة أخرى، كان بوراك هو المطور الذي أطلق هذه الثغرة الأمنية – هذه المرة كان الأمر متعمدًا بشكل واضح – ومرة ​​أخرى، كانت هناك مشكلة في التعليمات البرمجية لتحليل معاملات البيتكوين فوق طبقة الإجماع. كما ناقشت في بلدي قطعة على الخطأ السابق الذي أطلقه Burak ، قبل Taproot كانت هناك قيود على حجم البرنامج النصي وبيانات الشهود في المعاملة. مع تفعيل Taproot ، تمت إزالة هذه الحدود تاركًا فقط القيود المفروضة على حجم الكتلة تحد نفسها لتقييد هذه الأجزاء من المعاملات الفردية. كانت مشكلة الخطأ الأخير هي أنه على الرغم من حقيقة أن رمز الإجماع في btcd قد تمت ترقيته بشكل صحيح ليعكس هذا التغيير ، فإن الكود الذي يتعامل مع الإرسال من نظير إلى نظير - بما في ذلك تحليل البيانات قبل الإرسال أو عند الاستلام - لم تتم ترقيته بشكل صحيح. لذا ، فإن كتل ومعاملات معالجة الكود قبل أن يتم تمريرها بالفعل ليتم التحقق من صحتها من أجل الإجماع ، فشلت في البيانات ، ولم تمررها إلى منطق التحقق من صحة الإجماع ، وفشل التحقق من صحة الكتلة المعنية على الإطلاق.

حدث شيء مشابه للغاية هذه المرة. كان هناك حد آخر في قسم نظير إلى نظير من قاعدة الشفرة يفرض قيودًا على بيانات الشاهد بشكل غير صحيح ، مما يقيدها بحد أقصى 1/8 من حجم الكتلة بدلاً من حجم الكتلة الكامل. صاغ بوراك أ صفقة مع بيانات الشهود ، وحدة وزن واحدة فقط فوق الحد الصارم وتوقفت مرة أخرى عقدتي btcd و LND عند ارتفاع الكتلة هذا. كانت هذه المعاملة معاملة غير قياسية ، مما يعني أنه على الرغم من أنها صالحة تمامًا وفقًا لقواعد الإجماع ، إلا أنها غير صالحة وفقًا لسياسة mempool الافتراضية وبالتالي لن تقوم العقد بترحيلها عبر الشبكة. من الممكن تمامًا استخراجها في كتلة ، ولكن الطريقة الوحيدة للقيام بذلك هي توفيرها مباشرة إلى عامل منجم ، وهو ما فعله بوراك بمساعدة F2Pool.

وهذا يقودنا حقًا إلى نقطة مفادها أن أي جزء من التعليمات البرمجية الذي يهدف إلى تحليل بيانات Bitcoin والتحقق من صحتها يجب أن يخضع لمراجعة مكثفة للتأكد من أنه يتماشى مع ما ستفعله Bitcoin Core. لا يهم إذا كان هذا الرمز هو المحرك المتفق عليه لتنفيذ العقدة أو مجرد جزء من التعليمات البرمجية لتمرير المعاملات لعقدة Lightning. وكان هذا الخطأ الثاني حرفيا أعلى واحد من الشهر الماضي في قاعدة البيانات. لم يكتشفه أي شخص في Lightning Labs. أبلغت AJ Towns عن ذلك في 11 أكتوبر ، بعد يومين من بدء الخطأ الأصلي بواسطة صفقة بوراك 998 من 999 multisig. تم نشره علنًا على Github لمدة 10 ساعات قبل حذفه. تم بعد ذلك إجراء إصلاح ، ولكن لم يتم إصداره ، بهدف تصحيح المشكلة بهدوء في الإصدار التالي من LND.

الآن، يعد هذا إجراءً قياسيًا جدًا للثغرة الأمنية الخطيرة، خاصة مع مشروع مثل Bitcoin Core حيث يمكن أن تسبب مثل هذه الثغرة الأمنية ضررًا جسيمًا لشبكة/بروتوكول الطبقة الأساسية. ولكن في هذه الحالة تحديدًا، فقد شكل خطرًا جسيمًا على أموال مستخدمي LND، ونظرًا لحقيقة أنه كان بجوار الخطأ السابق الذي كان له نفس المخاطر، كانت فرص العثور عليه واستغلاله عالية جدًا. كما أظهر بوراك. وهذا يطرح سؤالاً حول ما إذا كان نهج التصحيح الهادئ هو الحل الأمثل عندما يتعلق الأمر بنقاط الضعف مثل هذه التي يمكن أن تترك المستخدمين عرضة لسرقة الأموال (لأن العقدة الخاصة بهم تُركت غير قادرة على اكتشاف حالات القناة القديمة ومعاقبتهم بشكل صحيح).

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

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

لم يكن LND أيضًا هو الشيء الوحيد الذي تأثر. السائل كما تم كسر عملية الربط، التي تتطلب تحديثات لموظفي الاتحاد لإصلاحها. الإصدارات الأقدم من Rust Bitcoin تأثرت أيضًا، مما تسبب في تأثير التوقف على بعض مستكشفات الكتل ومثيلات Electros (تطبيق خادم الواجهة الخلفية لـ Electrum Wallet). الآن، باستثناء ربط Liquid الذي يؤدي في النهاية إلى تعريض الأموال لمفاتيح الاسترداد في حالات الطوارئ التي تحتفظ بها Blockstream بعد انتهاء صلاحية القفل الزمني - وبشكل واقعي في حبكة الفيلم ذات أسلوب السرقة حيث سرق Blockstream هذه الأموال، يعرف الجميع بالضبط من سيلاحقون - هذه الأموال الأخرى لا تعرض المشكلات أبدًا أموال أي شخص للخطر في أي وقت. أيضًا، قامت Rust Bitcoin بالفعل بتصحيح هذا الخطأ المحدد في الإصدارات الأحدث، والذي يبدو أنه لم يؤدي إلى أي اتصال مع المشرفين على قواعد التعليمات البرمجية الأخرى لتسليط الضوء على احتمالية حدوث مثل هذه المشكلات. لقد كان الاستغلال النشط للخلل المباشر على الشبكة هو الذي كشف على نطاق واسع عن وجود المشكلة في قواعد تعليمات برمجية متعددة.

وهذا يثير بعض المشكلات الكبيرة عندما يتعلق الأمر بنقاط الضعف مثل هذه الموجودة في برنامج الطبقة الثانية على Bitcoin. أولاً، مدى الجدية التي يتم بها تدقيق قواعد التعليمات البرمجية هذه بحثًا عن الأخطاء الأمنية وكيفية تحديد أولويات ذلك مقابل تكامل الميزات الجديدة. أعتقد أنه من المهم للغاية أن الأمن لا يحظى دائمًا بالأولوية نظرًا لأن هذا الخطأ الثاني لم يتم العثور عليه حتى من قبل مشرفي قاعدة التعليمات البرمجية حيث كان موجودًا، على الرغم من أنه كان بجوار الخطأ الأولي الذي تم اكتشافه الشهر الماضي. بعد حدوث خطأ كبير أدى إلى تعريض أموال المستخدمين للخطر، هل لم يتم إجراء تدقيق داخلي لقاعدة التعليمات البرمجية هذه؟ هل استغرق الأمر شخصًا من خارج المشروع لاكتشافه؟ وهذا لا يوضح إعطاء الأولوية لحماية أموال المستخدمين على حساب إنشاء ميزات جديدة لجذب المزيد من المستخدمين. ثانيًا، توضح حقيقة أن هذه المشكلة قد تم تصحيحها بالفعل في Rust Bitcoin عدم وجود اتصال بين المشرفين على قواعد التعليمات البرمجية المختلفة فيما يتعلق بأخطاء مثل هذه. وهذا أمر مفهوم إلى حد كبير، نظرًا لأن اختلاف قواعد التعليمات البرمجية المختلفة تمامًا لا يجعل الشخص الذي وجد خطأً في أحدها يفكر على الفور، "يجب أن أتصل بالفرق الأخرى التي تكتب برامج مماثلة بلغات برمجة مختلفة تمامًا لتحذيرهم من احتمال وجود مثل هذا الخطأ." لا تجد خطأً في نظام التشغيل Windows ثم تفكر على الفور في الإبلاغ عن الخطأ إلى مشرفي Linux kernel. ومع ذلك، فإن البيتكوين كبروتوكول للإجماع الموزع عبر شبكة عالمية هو وحش مختلف تمامًا؛ ربما يجب على مطوري Bitcoin البدء في التفكير بهذه الطريقة عندما يتعلق الأمر بنقاط الضعف في برامج Bitcoin. خاصة عندما يتعلق الأمر بتحليل وتفسير البيانات المرتبطة بالإجماع.

أخيرًا، ربما عندما يتعلق الأمر ببروتوكولات مثل Lightning، والتي تعتمد على مراقبة blockchain في جميع الأوقات لتكون قادرًا على الاستجابة لحالات القناة القديمة من أجل الحفاظ على الأمان، يجب الحفاظ على التحليل المستقل والتحقق من البيانات عند الحد الأدنى المطلق - إذا لم تتم إزالتها بالكامل وتفويضها إلى Bitcoin Core أو البيانات المشتقة منها مباشرة. تم تصميم Core Lightning بهذه الطريقة، بحيث يتصل بمثيل Bitcoin Core ويعتمد عليه كليًا للتحقق من صحة الكتل والمعاملات. إذا عملت LND بنفس الطريقة، فلن تؤثر أي من هذه الأخطاء في btcd على مستخدمي LND بطريقة تعرض أموالهم للخطر.

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

يجب أن يركز المطورون والمستخدمون على تحسين العمليات لمنع حدوث مثل هذه الحوادث مرة أخرى ، وعدم ممارسة لعبة إلقاء اللوم مثل البطاطس الساخنة.

هذا منشور ضيف بواسطة Shinobi. الآراء المعبر عنها خاصة بها تمامًا ولا تعكس بالضرورة آراء BTC Inc أو Bitcoin Magazine.