ملخص
- إزالة ثقة جذور الشهادات المرتبطة بـ eMudhra في Teku 26.10.3 وBesu 26.10.2 بعد كشف المفاتيح الوسيطة المخترقة عن بعض تكوينات المُحقق القائمة على HTTPS لمخاطر التزييف.
- لم تتأثر عقدات Teku الرئيسية الافتراضية، ولم يُبلغ عن أي استغلال، بينما كان الخطر يعتمد على المُحققين المتصلين بخدمات خارجية عبر HTTPS.
- يجب على مستخدمي Docker تحديث صور العميل، بينما يجب على المشغلين المستقلين تطبيق التصحيحات بشكل منفصل على Java؛ يحتاج مستخدمو Java 26 إلى التحول إلى إصدارات Java 25 المدعومة.
أصدر Teku و Besu تحديثات أمنية بعد أن تركت مفاتيح سلطة الشهادة المخترقة eMudhra تكوينات عقد Ethereum عرضة لاتصالات HTTPS مزورة. ملاحظات إصدار Teku توصي بالإصدار 26.10.3، الذي يزيل الثقة في أربع جذور شهادات متأثرة من صور Docker، بينما أصدر Besu الإصدار 26.10.2. تعالج التحديثات ثقة الشهادة على مستوى طبقة توزيع البرنامج وليس عيبًا في قواعد التوافق في Ethereum. لم تتأثر عقدات Teku الرئيسية الافتراضية، مما يجعل الحادثة منفصلة عن الثغرات في بروتوكول Ethereum.
تم إنشاء مفاتيح شهادات مخترقة وشكلت خطر انتحال الهوية
وجد الباحثون أن المفاتيح الخاصة لثمانية سلطات شهادات وسيطة من eMudhra يمكن استردادها لأنها تم إنشاؤها باستخدام عشوائية غير كافية. على الرغم من إلغاء الشهادات، فإن جافا لا تتحقق من الإلغاء افتراضيًا، مما يترك البيئات التشغيلية قادرة على قبول شهادات مزورة. وبالتالي، يمكن لمهاجم يقع بين عقدة وخدمة HTTPS أن يتقمص هوية تلك النقطة النهائية ضمن التكوينات الضعيفة. هذه الحادثة تعزز السبب الذي يجعل تنوع عميل إيثريوم والأمان التشغيلي يتجاوز كود التوافق.
كانت السيناريوهات الأعلى خطورة تشمل المُحققين المتصلين بخدمات خارجية عبر HTTPS. يمكن لendpoint مزور أن يُغيّر معلومات بناء الكتلة، أو يعيد توجيه مستلمي الرسوم، أو يحصل على التوقيعات من خلال مُوقّع خارجي مُزيف. وقالت Teku إن المهاجم يمكنه التسبب في اقتراح عقد من قبل عميل مُحقق يستخدم عقدًا بعثيًا عن بُعد يدفع الرسوم إلى عنوان المهاجم. يعتمد الخطر على موقع الشبكة وتكوينات الخدمة عن بُعد، وليس فقط على تشغيل Teku أو Besu. لم يتم الإبلاغ عن أي استغلال.
يُزيل Teku 26.10.3 الثقة في emSign ECC Root CA G3 وemSign Root CA G1 وemSign Root CA G2 وAAA Certificate Services في صور Docker. ويُطبّق تحديث Besu نفس النهج. يجب على المشغلين الذين يشغّلون الملفات التنفيذية مباشرةً تحديث Java بشكل منفصل، لأن ترقيات العميل لا تستبدل مخزن الشهادات الخاص ببيئة التشغيل. وبالتالي، تتطلب النشرات عبر Docker والنشرات المستقلة مسارات إصلاح مختلفة. هذا التمييز مهم بعد حوادث بنية تحتية لمحرّك Ethereum التي أظهرت كيف يمكن للاعتمادات خارج البروتوكول أن تؤثر على عمليات التخزين.
يُنشئ Java 26 تعقيدًا لأنه وصل إلى نهاية دورة حياته ولن يتلقى بناءً مُصلحًا مطلوبًا، مما يعني أن المشغلين المتأثرين بحاجة إلى الانتقال إلى Java 25. لم يتم كشف شبكة Ethereum النظير إلى النظير لأنها لا تعتمد على هذه سلطات الشهادات. تقلل الإصلاحات من خطر مخزن الثقة التابع لطرف ثالث دون إصلاح استغلال نشط على الشبكة الرئيسية أو تغيير بروتوكول Ethereum. تتبع هذه الحادثة أعمال أمنية أخرى، بما في ذلك تصحيح توجيه إيداع Glamsterdam، مما يؤكد كيف يعتمد سلامة المُحققين على كود البروتوكول والبنية التحتية الداعمة.