ثغرات Ledger وإعادة اختبار OneKey: ما الذي حدث فعلاً؟

أعادت وحدة Anzen الأمنية التابعة لشركة OneKey إنتاج ثغرة حقيقية في الإصدار القديم 1.22.1 من تطبيق إيثريوم لدى Ledger، لكن الاختبار جرى في بيئة مختبرية خاضعة للسيطرة. وتقول Ledger إن الثغرة كانت قد أُصلحت بالفعل في الإصدار 1.22.2، قبل نشر العرض، وإنها لم تجد دليلاً على تعرض أي مستخدم لهجوم. 31731

ومع ذلك، كشفت الواقعة عن نقطة أوسع في أمن المحافظ hardware wallets: عزل المفاتيح الخاصة عن الحاسوب ليس كافياً وحده؛ إذ يجب أيضاً أن يعرض الجهاز المعاملة التي سيوقّعها فعلاً، لا معاملة مختلفة عنها.

ماذا أعادت OneKey إنتاجه؟

تحمل الثغرة اسم LSB-023 لدى Ledger، وترتبط بتداخل الأوامر أثناء مراجعة المعاملة على شاشة الجهاز. كان بإمكان المضيف إرسال أمر APDU جديد بينما لا يزال أمر سابق بانتظار رد المستخدم. وبما أن معلمات التوقيع كانت محفوظة في حالة مشتركة خلال مرحلة المراجعة، كان من المحتمل تغييرها بعد ظهورها على الشاشة وقبل إنشاء التوقيع. 3

عملياً، كان يمكن للشاشة أن تعرض المعاملة «أ»، بينما يوقّع الجهاز المعاملة «ب». وقد أعاد فريق OneKey Anzen إنتاج هذا السلوك باستخدام الإصدار القديم 1.22.1 من تطبيق إيثريوم داخل المختبر. وهذا يثبت قابلية استغلال المسار البرمجي في النسخة القديمة، لكنه لا يثبت اختراق أنظمة Ledger أو مستخدميها في الواقع. 172332

وتقول Ledger إن فرقها الأمنية كانت قد اكتشفت المشكلة ضمن إجراءاتها الداخلية، وأطلقت وسائل حماية في الإصدار 1.22.2 من تطبيق إيثريوم. كما أشارت التقارير إلى معالجة أصل المشكلة في Secure SDK 26.6.1، وهي حزمة التطوير التي تُستخدم لبناء تطبيقات Ledger. 172124

هل تعرض أي شخص للاختراق؟

كان رد Ledger واضحاً: «لم يتعرض أي مستخدم لـ Ledger للاختراق». ولا تتحدث التقارير المتاحة عن خسائر معروفة مرتبطة بإعادة إنتاج OneKey للثغرة، لكن ينبغي فهم هذا التصريح باعتباره إفادة بعدم رصد استغلال فعلي، لا دليلاً على استحالة الاستغلال في الإصدارات المتأثرة. 172031

وهنا تكمن أهمية التمييز: الاختبار المخبري يمكن أن يثبت أن مساراً برمجياً ضعيفاً يعمل في ظروف محددة، من دون أن يثبت أن مجرمين استخدموه ضد المستخدمين في العالم الحقيقي.

الثغرتان الإضافيتان في الإصدار 1.22.3

عالج الإصدار 1.22.3 ثغرتين أخريين في تطبيق إيثريوم، ظلتا قائمتين بعد تحديث 1.22.2. وتدرجهما نشرات Ledger الأمنية تحت الاسمين LSB-024 وLSB-025. 46

LSB-024: دفعة من المعاملات قد تخفي العمليات

تتعلق LSB-024 بخلل في التعامل مع عدد العمليات ضمن ميزة التوقيع الواضح (clear signing). فقد تؤدي دفعة مصممة خصيصاً وتضم 257 عملية إلى عرض العملية الأخيرة فقط على الجهاز، مع توقيع الدفعة كاملة.

وهذا يمثل فشلاً في سلامة مراجعة المعاملة. فقد يظل الجهاز يطلب تأكيد المستخدم، لكن المعلومات المعروضة للمراجعة لن تصف كامل البيانات التي سيجري توقيعها. وتصف Ledger المشكلة بأنها «تجاوز للتوقيع الواضح عبر اقتطاع عدد عناصر المصفوفة». 46

LSB-025: تحويل دفعة المبادلة إلى موافقة على رمز

أثرت LSB-025 في مسار مبادلة الأصول. إذ كان بإمكان مزود مبادلة مخترق استبدال دفعة متوقعة بطلب موافقة على رمز (token approval)، من دون ظهور مطالبة جديدة على جهاز Ledger. وتصف Ledger المشكلة بأنها قبول موافقة على رمز بدلاً من دفعة في مسار المبادلة. 46

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

لماذا لم تتضمن النسخة 1.22.2 إصلاحَي LSB-024 وLSB-025؟

تشير المواد المتاحة إلى أن التغييرات المرتبطة بالثغرتين اللاحقتين كانت قد أُعدت أو دُمجت قبل أشهر من إطلاق الإصدار 1.22.2، لكنها ظهرت في الإصدار 1.22.3 بدلاً منه. ووُصف عدم إدراجها بأنه سؤال لم يُحسم علناً بشأن عملية الإصدار أو الدمج. 37

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

ماذا تكشف الواقعة عن نموذج Ledger القابل للتحديث؟

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

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

ماذا ينبغي لمستخدمي Ledger أن يفعلوا؟

1. حدّث تطبيق إيثريوم إلى الإصدار 1.22.3 أو أحدث. عالج الإصدار 1.22.2 المشكلة الخاصة بـ LSB-023، بينما يتضمن الإصدار 1.22.3 إصلاحَي LSB-024 وLSB-025. 1737
2. استخدم Ledger Live ومدير الجهاز وقنوات Ledger الرسمية لتثبيت تحديثات التطبيقات. وتوجه إرشادات Ledger المستخدمين إلى تثبيت تطبيق إيثريوم عبر Ledger Live. 7
3. راجع كل مطالبة تظهر على شاشة الجهاز، ولا سيما أثناء عمليات المبادلة. إذا طلب الجهاز موافقة على رمز بينما كنت تتوقع دفعة، فتوقف وارفض العملية.
4. كن حذراً من الدفعات الكبيرة أو غير الواضحة. تجنب التوقيع الأعمى كلما أمكن، خصوصاً عندما يتعذر فحص كامل البيانات على الجهاز.
5. اعتبر الحاسوب والمتصفح والمواقع اللامركزية ومزودي المبادلة جزءاً من نموذج التهديد. فالمحفظة hardware wallet تقلل بعض المخاطر، لكنها لا تلغي مخاطر البرمجيات الخبيثة أو صفحات الويب المعادية أو التطبيقات اللامركزية ومزودي المبادلة المخترقين. 328
6. راجع صلاحيات الرموز بعد استخدام نسخة متأثرة. إذا أجريت عمليات مبادلة أو وقّعت موافقات أثناء تشغيل إصدار ضعيف، فتحقق من الصلاحيات غير الضرورية وألغها عبر واجهة موثوقة.

الخلاصة: أعادت OneKey إثبات وجود خلل حقيقي في إصدار قديم من تطبيق إيثريوم لدى Ledger، لكن الأدلة المتاحة لا تثبت وقوع اختراق مباشر لمستخدمي Ledger. ومع ذلك، لا ينبغي تجاهل الحادثة؛ فالثغرتان LSB-024 وLSB-025 توضحان أن الانتقال إلى أول تحديث متاح لم يكن بالضرورة نهاية قصة التصحيح الأمني.