Teku وBesu يعالجان ثغرة في إيثيريوم (ETH) مرتبطة بثماني جهات شهادة من eMudhra

Teku 26.10.3 وBesu 26.10.2

أصدر مطوّرو Teku 26.10.3 النسخة الجديدة من عميلهم يوم الثلاثاء، وتبعهم فريق Besu 26.10.2 يوم الاثنين، وذلك في تحديثين يسحبان الثقة من الشهادات المرتبطة بالشركة الهندية eMudhra من صور Docker تمامًا. ويُسجَّل التغييران في ملاحظات الإصدار الرسمية لكلا المشروعين، ويعالجان مسارًا كان يمكن، في أكثر ترتيبات التشغيل عرضة للخطر، أن يتيح لمهاجم صامت توجيه جزء من مكافآت المدقّق إلى عنوان يختاره بنفسه. ولم يقع أي إخلال بقواعد الإجماع، ويؤكد فريق Teku في ملاحظاته أنه لم يرد حتى الآن أي بلاغ عن استغلال فعلي للثغرة.

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

اكتشف الباحثون يوم السبت 17 أكتوبر أن المفاتيح الخاصة الكامنة خلف ثماني جهات شهادة وسيطة تابعة لـeMudhra قد وُلّدت بدرجة عشوائية غير كافية. ولأن الشهادات وثائق متاحة للعموم، أمكن استعادة المفاتيح من الشهادات ذاتها، وبهذا يستطيع أي حائز عليها تزوير شهادات تتقبلها البرمجيات غير المحدّثة على أنها صحيحة. وحرك المتصفحون أولًا ووقفوا قبولها، ثم سحبت eMudhra الشهادات في اليوم التالي وأعلنت لاحقًا نيتها الخروج من قطاع الشهادات الرقمية كليًا. وكان فريق Consensys Diligence، وهو الشريك الأمني الذي يشرف على تدقيق Teku، أول من رفع الاشتباه في الخلل. وتكمن قناة التوزيع المتأثرة في الحالتين ضمن صور Docker، وهي البنيات الجاهزة التي ينشرها كثير من المشغّلين، كما أن منظومة عملاء إيثيريوم الأوسع تشغّل أدوات مدقّقيها على لغة Java، وهي تفصيل شكّل شكل الانكشاف وشكل الإصلاح معًا.

لماذا العقد الافتراضية على الشبكة الرئيسية آمنة

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

هذه الثغرة في الافتراضات هي التي تفسّر ترتيب الاستجابة كذلك: فالمتصفحات تتحقق من سحب الشهادات، ولذلك قطعتها خلال يوم واحد، بينما الأدوات المبنية على Java لم تفعل، فأعادت فرق العملاء بناء صور Docker الخاصة بها بعد إخراج eMudhra من مجموعة الثقة، بدل انتظار إصلاح على مستوى بيئة التشغيل. ولدى معظم المشغّلين الخبر أبسط من ذلك: العقدة التي تعمل بتركيبة افتراضية غير معدّلة على الشبكة الرئيسية غير متأثرة ولا تحتاج إلى أي إجراء، والسجل حتى الآن لا يشير إلى مكافآت مسروقة. أما العلاج فتتوزع صورته بحسب التجهيز: فمن يشغّل صور Docker الجاهزة عليه سحب أحدث بنية من Teku أو Besu، ومن يشغّل البرمجيات مباشرة على أجهزته يواجه عملًا أكبر، لأن تحديث عميل إيثيريوم لا يمسّ تنصيب Java الموجود على الجهاز، والصور الجديدة لا تصلح ذلك أيضًا. وأصعب الحالات يقع على من بقي على Java 26، وهي نسخة وصلت إلى نهاية عمرها الافتراضي ولن تصدر لها بنية معالجة، فلا يبقى أمامها سوى الانتقال إلى Java 25.

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