ليدجر تسد ثغرة في تطبيق إيثريوم تتيح توقيع معاملات ببيانات غير مطابقة

ملخص سوق AI
أصلحت Ledger ثغرة أمنية في تطبيق Ethereum الخاص بها (تم إصلاحها في الإصدار v1.22.2) كان يمكن أن تسمح لتطبيق ويب خبيث باستغلال حالة تسابق لاستبدال بيانات المعاملة بعد المراجعة، ما قد يحوّل إجراءات حميدة إلى موافقات ضارة. وبينما لم يتم اختراق أي مفاتيح خاصة أو البرنامج الثابت ولم يتم الإبلاغ عن أي خسائر مؤكدة، تسلط الحادثة الضوء على المخاطر التشغيلية لمستخدمي Ethereum/ERC-20 الذين يتفاعلون مع dApps عبر WebHID وقد تُضعف شهية المخاطرة على المدى القريب للنشاط المرتبط بـ ETH.
مستوى التأثير
● متوسط
الأصول المتأثرة
ETH/USDT-1.32%
رؤية AI · ETH/USDTرؤية AI
▼ هابط
تداول الآن
⚠️ الرؤى التي يُنشئها AI مبنية على محتوى الأخبار، وتُقدَّم لأغراض معلوماتية فقط. لا تُشكّل نصيحة استثمارية، ولا تعبّر عن آراء BingX. ينطوي الاستثمار على مخاطر. يُرجى التداول بمسؤولية.
على كل من يملك محفظة Ledger ويستخدمها لإدارة Ether أو رموز ERC20 أن يفتح Ledger Live ويتحقق من إصدار تطبيق Ethereum المثبّت على الجهاز. أي إصدار أقدم من 1.22.2 يفتقد لتحديث أمني مهم. هذا التحديث يعالج خللاً مسّ جوهر فكرة المحافظ الصلبة: أن الشاشة تعرض بدقة ما سيوقّعه الجهاز فعلاً. أصبحت القضية علنية في 24 أغسطس 2026 بعد أن نشرت شركة الأمن TestMachine تحليلاً فنياً. التحديث كان موجوداً عندها بالفعل، لكن الجدل دار حول من اكتشف العيب أولاً ومتى قامت Ledger بشحن الإصلاح. بالنسبة لمالك الجهاز، الأهم هو رقم الإصدار على جهازك وما إذا كنت قد منحت موافقات (Approvals) سابقاً دون أن تنتبه. ما الذي حدث فعلياً؟ المشكلة لم تكن في Firmware الخاص بالجهاز ولم تمس حفظ المفتاح الخاص. موضع الخلل كان داخل تطبيق Ethereum نفسه، وهو التطبيق الذي يُثبَّت على الجهاز للتعامل مع Ether ورموز ERC20، ويقوم بتحضير المعاملة وعرضها على الشاشة ثم أخذ تأكيد المستخدم. في الإصدارات المعيبة، كان يمكن العبث بتسلسل العرض والتوقيع. تطبيق ويب خبيث لديه وصول إلى الجهاز المتصل يستطيع إرسال أمر توقيع ثانٍ بينما لا تزال المعاملة الأولى معروضة على الشاشة بانتظار المراجعة. عندها يستبدل التطبيق البيانات في الذاكرة دون إظهار شاشة مراجعة جديدة. تظل تفاصيل التحويل "الآمن" التي راجعتها ظاهرة على الشاشة، لكن موافقتك تُطبَّق على البيانات التي تم تبديلها. ووفقاً للباحثين، جرى إثبات النمط عملياً على Ledger Flex. وبما أن أجهزة Ledger تشترك إلى حد كبير في شيفرة تطبيق Ethereum، يُنظر إلى Nano X وNano S Plus وStax وApex على أنها قد تكون عرضة أيضاً. لم تكشف Ledger عن أول إصدار تضمن الخطأ؛ مقارنة الباحثين تبدأ من 1.22.1، وهو إصدار مؤشّر بتاريخ 27 مايو 2026. "التوقيع الواضح" (Clear Signing): لماذا الشاشة هي وعد الأمان الأساسي يقصد بـ Clear Signing عرض بيانات المعاملة كاملة بصيغة مقروءة على شاشة المحفظة قبل التأكيد: عنوان المستلم، المبلغ، وفي استدعاءات العقود الذكية، الإجراء الذي سيقوم به العقد. هذا هو السبب الذي يجعل المحفظة الصلبة منطقية أساساً: حتى لو كان الكمبيوتر مخترقاً أو واجهة المتصفح مُتلاعباً بها أو الموقع مزيفاً، تظل شاشة الجهاز المستقلة هي المرجع الذي يكشف التلاعب قبل الضغط على التأكيد. الثغرة أصابت هذه السلسلة في الحلقة الأضعف: المفتاح بقي آمناً والـFirmware لم يتغير، لكن قد ينتهي الأمر بتأكيد مختلف عن الذي قرأته. وعندما لا تعود الشاشة مرجعاً مُلزِماً، تفقد المحفظة الصلبة إحدى أهم ميزاتها مقارنة بمحفظة برمجية على جهاز مصاب. جوهر الثغرة: Race Condition وأوامر APDU "Race Condition" هو خلل يعتمد فيه الناتج على أي أمرين متزامنين تقريباً تتم معالجته أولاً. هذا النوع خادع لأن الشيفرة تبدو صحيحة غالباً، ولا يظهر الخلل إلا عندما يتعمد مهاجم ترتيب التوقيت. APDU هو تنسيق الأوامر الذي تستخدمه البطاقات الذكية والمحافظ الصلبة للتخاطب مع الكمبيوتر. التوقيع يمر عبر عدة أوامر، وكان تطبيق Ethereum يحتفظ "بحالة" تحدد أي معاملة قيد المراجعة. هذه الحالة أمكن الكتابة فوقها أثناء استمرار المراجعة، ما يفتح الباب لاستبدال بيانات المعاملة دون فتح شاشة مراجعة جديدة. WebHID داخل المتصفح: لماذا يمكن لموقع أن يتواصل مع جهازك؟ WebHID واجهة في المتصفح تتيح لموقع الويب الاتصال مباشرة بجهاز USB متصل بعد أن تمنحه إذناً صريحاً. من دونها يصعب استخدام المحفظة الصلبة بسلاسة داخل تطبيقات لامركزية (dApps)، ومعها يصبح الموقع أقرب إلى الجهاز مما يتصوره كثيرون. الهجوم الموصوف يتطلب أن تكون قد منحت هذا الوصول مسبقاً لموقع خبيث أو تم الاستيلاء عليه، وأن تبادر بتنفيذ معاملة من خلاله. لا يمكن تنفيذه عن بُعد على جهاز غير متصل وموجود في درج، ما يحد من دائرة المتأثرين، لكنه لا يقلل من أهمية الخلل، خصوصاً لمن يستخدم باستمرار منصات تداول لامركزية أو الجسور أو واجهات التخزين (Staking). موافقات الرموز بدل التحويل: لماذا تعد الموافقات غير المحدودة خطرة؟ الضرر الأكبر في مثل هذا الاستبدال لا يأتي عادةً من التحويل نفسه، بل مما يمكن تمريره بدلاً منه. "Token Approval" هو إذن يمنح عقداً ذكياً صلاحية التصرف بكمية من رموزك لاحقاً دون طلب موافقة لكل عملية خصم. كثير من التطبيقات تطلب موافقات غير محدودة لتسهيل الاستخدام. الموافقة لا تنتهي تلقائياً وتظل سارية حتى تقوم بإلغائها صراحة. الفرق بين تحويل وموافقة التحويل يخصم فقط المبلغ الذي تؤكده. أما الموافقة غير المحدودة فقد تكلّفك، في أسوأ السيناريوهات، كامل رصيد ذلك الرمز وفي وقت يحدده الطرف المخوّل. لذلك يُعد استبدال تحويل صغير بموافقة واسعة النطاق من أكثر الهجمات ربحية على مسار التوقيع. تحديث تطبيق Ethereum إلى 1.22.2 عبر Ledger Live الإصدار 1.22.2 يغلق المسار الموصوف عبر آليتين: رفض بدء جلسة توقيع جديدة أثناء وجود مراجعة جارية، ورفض تأكيد وارد إذا لم تعد "الحالة" مطابقة لما تم عرضه على الشاشة. معلومة الإصدار مدرجة في سجل إصدارات تطبيق Ethereum لدى Ledger، لكنها تذكر فقط إصلاحات أمنية دون شرح للثغرة. التحديث بحد ذاته بسيط: صِل الجهاز، افتح مدير التطبيقات في Ledger Live، ثم حدّث تطبيق Ethereum. الأرصدة لا تتأثر، لأن المفاتيح مشتقة من عبارة الاستعادة (Recovery Phrase) وليست مخزنة داخل التطبيق. حتى إزالة التطبيق وإعادة تثبيته لا تعني فقدان أموال. كيف تتأكد من الإصدار المثبّت يعرض Ledger Live رقم الإصدار لكل تطبيق داخل مدير الجهاز. إذا كان 1.22.2 أو أعلى فالإصلاح موجود. إذا كان 1.22.1 أو أقدم فالجهاز ما زال يفتقده. ولا يكفي النظر إلى إصدار Ledger Live نفسه. لماذا لا يحدّث تحديث الـFirmware تطبيق Ethereum تلقائياً؟ هنا يقع كثيرون في الخطأ: الـFirmware وLedger Live وتطبيقات العملات تُدار وتُحدّث بشكل منفصل. قد تحدّث الـFirmware وتشعر بالاطمئنان بينما يظل تطبيق Ethereum قديماً على الجهاز. هذا يفسّر أيضاً اختلاف طبيعة حوادث محافظ أخرى: في حالة Coldcard كان الخلل في توليد البذرة (Seed) ما استلزم بذرة جديدة. ثغرات BitBox كانت في الـFirmware. هنا الخلل ضمن تطبيق قابل للاستبدال، لذا يكفي تحديث التطبيق ولا حاجة لإعادة توليد عبارة الاستعادة. خطوة ثانية بعد التحديث: مراجعة وإلغاء موافقات الرموز القديمة التحديث يحمي التوقيعات المستقبلية، لكنه لا يمحو ما مُنح سابقاً. إذا كنت تستخدم تطبيقات لامركزية خلال الأشهر الماضية، فمن المفيد مراجعة الموافقات المفتوحة على عنوانك. مستكشفات البلوك تشين وواجهات متخصصة تعرض لأي عنوان: ما العقود المصرح لها بالتصرف بأي رموز. يمكنك إلغاء الموافقات التي لم تعد تحتاجها واحدة تلو الأخرى. الإلغاء معاملة عادية وتستلزم رسوم شبكة، لذا يفضّل تنفيذ التنظيف في فترات الرسوم المنخفضة. أثر جانبي يغفل عنه كثيرون: كل عملية إلغاء تظهر في سجل معاملاتك وتولّد رسوماً. من يوثق تحركاته أولاً بأول يسهل عليه الأمر في الإقرار الضريبي؛ أدوات الضرائب وتتبع المحافظ تقرأ هذه الأحداث عادةً بشكل تلقائي. خلاف الإفصاح بين Ledger وTestMachine هناك روايتان لتسلسل الأحداث ولا تتطابقان. تُذكر هنا كرواية كل طرف دون تحقق مستقل. قال المدير التقني لدى Ledger، شارل غيّوميه (Charles Guillemet)، إن مختبر الأمان الداخلي Ledger Donjon هو من اكتشف الخطأ، وإن الإصلاح شُحن قبل النشر بنحو أسبوعين، وإن TestMachine تواصلت مع برنامج مكافآت الثغرات لاحقاً. ووصف تصريحات الشركة الأمنية بأنها تهدف لإثارة الخوف لجذب الانتباه. ترد TestMachine بأن نظام الاختبار الآلي لديها، المسمى Azimuth، اكتشف الضعف خلال تشغيل تلقائي على Ledger Flex، وأن النتائج شاركتها مع Ledger. وبحسب تقييمها لم يكن هناك إصلاح متاح وقت النشر. الوقائع التي يمكن التحقق منها تقع بينهما: سجل التغييرات لإصدار 1.22.2 يحمل تاريخ 12 أغسطس 2026، ووسم المصدر الموقّع بتاريخ 13 أغسطس. لكنه لم يظهر كإصدار منشور بشكل واضح إلا قرابة 24 أغسطس، بالتزامن مع تحليل الشركة الأمنية. المستخدم الذي أراد التحقق في تلك الفترة عن وجود إصلاح لم يكن ليجده في صفحة الإصدارات. هل فُقدت أموال؟ ما المعروف حتى الآن استناداً إلى ما أعلنه الطرفان حتى الآن، لا توجد حالة مؤكدة لاستغلال الثغرة. لا خسائر موثقة، كما أن استخراج المفاتيح الخاصة لم يكن ممكناً عبر هذا المسار أصلاً. هذه نقطة إيجابية، مع تنبيه مهم: التوقيع الناتج عن هذا السيناريو سيبدو على السلسلة كأي توقيع طوعي عادي. المستخدم قد لا يلاحظ إلا لاحقاً عندما تبدأ الرموز بالخروج، وقد يعزو ذلك إلى تصيّد تقليدي. لذلك لا يعني غياب الحالات المؤكدة بالضرورة أنه لم تقع أي حالات. ما الذي تعنيه القضية لمحافظ العتاد والحفظ الذاتي الاستنتاج الخاطئ هو رفض المحافظ الصلبة. الهجوم يتطلب إذن وصول مُسبق وتطبيقاً خبيثاً، لم يمس المفتاح، وقد تم إصلاحه. الاستنتاج العملي: المحفظة الصلبة تنقل الثقة من الكمبيوتر إلى جهاز صغير بشاشة خاصة، لكن هذا الجهاز يتكون من Firmware وتطبيقات وبرمجيات مرافقة تُحدّث كلٌ على حدة. الأمان هنا ليس حالة تُكتسب بالشراء، بل صيانة مستمرة: تحديث التطبيقات، ترتيب الموافقات دورياً، وللحيازات الكبيرة إضافة طبقة تأكيد ثانية. الخلاصة العملية 1) تحقّق من الإصدار وحدّثه: داخل Ledger Live، افتح مدير الجهاز وراجع تطبيق Ethereum. أي إصدار أقل من 1.22.2 يحتاج تحديثاً، وتحديث الـFirmware وحده لا يكفي. 2) نظّف موافقات الرموز: راجع العقود المخوّلة على عنوانك وألغِ كل ما لا تحتاجه. 3) وثّق التحركات: الإلغاءات وإعادة توزيع الأرصدة تولّد رسوماً وتظهر في السجل؛ سجّلها أثناء التنفيذ لتسهيل المتابعة الضريبية. (حتى 25 أغسطس 2026. هذه المادة ليست نصيحة استثمارية. الأسعار والرسوم تتغير؛ راجع شروط المزوّد قبل الشراء.)