الأسبوع الماضي، كشف باحث أمني عن حالة مروعة: في تحديث محفظة في 24 ديسمبر، تم زرع رمز خلفي، مما أدى إلى تسريب بيانات المستخدمين الخاصة (بما في ذلك كلمات المساعدة)، وتعرض المستخدمين لخسائر تزيد عن 2 مليون دولار أمريكي.
قد يبدو هذا الحدث جديدًا للوهلة الأولى، لكن عند التفكير فيه بعمق، فإنه يعكس مشكلة قديمة في منتجات المحافظ الرقمية — وهي أن المستخدمين لا يملكون السيطرة على حدود الأمان بشكل أساسي.
**ما هو الخطر الحقيقي في محافظ الإضافات**
عند مناقشة مثل هذه الأحداث، يعتاد الكثيرون على إلقاء اللوم على المستخدمين: "هل استوردت كلمات المساعدة؟ هل قمت بعملية خاطئة؟" لكن من منظور تصميم المنتج، المشكلة ليست هنا. الخطر الحقيقي يكمن في آلية التحديث التلقائي نفسها.
هناك واقع لا مفر منه في محافظ الإضافات:
كل تحديث تلقائي هو في جوهره تفويض كامل لأصولك بالكامل.
طالما أن الكود في حزمة التحديث تم التلاعب به — سواء كان ذلك مشكلة داخلية، أو هجوم على سلسلة التوريد (مثل اختراق عمليات CI/CD، بيئة البناء، قنوات النشر) — فإن المنطق الخبيث سينفذ دون أن يلاحظ المستخدمون، وحتى أن المستخدمين لن يدركوا ذلك.
الأمر الأكثر إيلامًا هو أن هذا الخطر لا يهدد فقط سيناريو المحافظ الساخنة. حتى لو كنت تستخدم الإضافة فقط للاتصال بمحفظة الأجهزة، فإن الأمر لا يختلف. لأن الإضافة تسيطر على:
- محتوى المعاملات التي تراها - عناوين الاستلام التي تؤكد عليها - جميع المعلومات المعروضة قبل وبعد التوقيع
محفظة الأجهزة تضمن أن "المفتاح الخاص لن يترك الشريحة أبدًا"، لكنها لا تضمن أن التوقيع هو على المعاملة التي تعتقد أنك وقعت عليها. إذا كانت الإضافة ذات نية خبيثة، يمكنها أن تجعلك توقع على شيء، وفي النهاية يتم تنفيذ شيء آخر على السلسلة.
**لماذا أصبح هذا مشكلة نظامية**
جذر المشكلة يكمن في: صلاحيات التحديث المركزية. بعد أن يقوم المستخدم بتثبيت الإضافة، فإنه يمنح فريق التطوير السيطرة الكاملة على أمانه. الفريق قد يكون موثوقًا، لكن البنية التحتية، وعمليات النشر، وأجهزة كمبيوتر الموظفين — أي جزء من هذه الحلقة يمكن أن يُخترق، مما يؤدي إلى خسائر واسعة في الأصول.
أما من جهة المستخدم، فهو وضع سلبي تمامًا — لا يمكنك رؤية ما تم تحديثه، ولا يمكنك رفض إصدار معين من التحديث.
لهذا السبب، بدأ مجتمع Web3 يعيد النظر في تصميم بنية المحافظ. بعض المشاريع تستكشف آليات تحديث تعتمد على فصل المفاتيح، وتتيح للمستخدمين التحقق من التحديثات، وحتى بنية تعتمد على الأولوية المحلية — الهدف هو تمكين المستخدمين من السيطرة الفعلية على أمان أصولهم، بدلاً من الاعتماد الأعمى.
شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 13
أعجبني
13
5
إعادة النشر
مشاركة
تعليق
0/400
DAOdreamer
· منذ 3 س
هذه المرة لا يوجد مكان للهروب، التحديث التلقائي هو الباب الخلفي الذي يفتحه للقراصنة
شاهد النسخة الأصليةرد0
down_only_larry
· منذ 3 س
يا إلهي... التحديث التلقائي يعني تسليم المفتاح، فكر في هذا المنطق، إنه حقًا غريب
حقًا، الآن أي شيء تستخدمه يجب أن تكون حذرًا، إذا تم اختراق سلسلة التوريد فستنتهي الأمور
انتظر، هل لا يزال يمكن خداعك للتوقيع عند استخدام محفظة الأجهزة مع الإضافة؟ إذن أنا اشتريتها بلا فائدة
لماذا لا يزال الكثيرون يستخدمون هذا القمامة المركزي... إنه أمر غير معقول
لا تستطيع حماية أصولك بنفسك، أليس هذا بمقام مقامرة على نزاهة فريق التطوير؟
الأسبوع الماضي، كشف باحث أمني عن حالة مروعة: في تحديث محفظة في 24 ديسمبر، تم زرع رمز خلفي، مما أدى إلى تسريب بيانات المستخدمين الخاصة (بما في ذلك كلمات المساعدة)، وتعرض المستخدمين لخسائر تزيد عن 2 مليون دولار أمريكي.
قد يبدو هذا الحدث جديدًا للوهلة الأولى، لكن عند التفكير فيه بعمق، فإنه يعكس مشكلة قديمة في منتجات المحافظ الرقمية — وهي أن المستخدمين لا يملكون السيطرة على حدود الأمان بشكل أساسي.
**ما هو الخطر الحقيقي في محافظ الإضافات**
عند مناقشة مثل هذه الأحداث، يعتاد الكثيرون على إلقاء اللوم على المستخدمين: "هل استوردت كلمات المساعدة؟ هل قمت بعملية خاطئة؟" لكن من منظور تصميم المنتج، المشكلة ليست هنا. الخطر الحقيقي يكمن في آلية التحديث التلقائي نفسها.
هناك واقع لا مفر منه في محافظ الإضافات:
كل تحديث تلقائي هو في جوهره تفويض كامل لأصولك بالكامل.
طالما أن الكود في حزمة التحديث تم التلاعب به — سواء كان ذلك مشكلة داخلية، أو هجوم على سلسلة التوريد (مثل اختراق عمليات CI/CD، بيئة البناء، قنوات النشر) — فإن المنطق الخبيث سينفذ دون أن يلاحظ المستخدمون، وحتى أن المستخدمين لن يدركوا ذلك.
الأمر الأكثر إيلامًا هو أن هذا الخطر لا يهدد فقط سيناريو المحافظ الساخنة. حتى لو كنت تستخدم الإضافة فقط للاتصال بمحفظة الأجهزة، فإن الأمر لا يختلف. لأن الإضافة تسيطر على:
- محتوى المعاملات التي تراها
- عناوين الاستلام التي تؤكد عليها
- جميع المعلومات المعروضة قبل وبعد التوقيع
محفظة الأجهزة تضمن أن "المفتاح الخاص لن يترك الشريحة أبدًا"، لكنها لا تضمن أن التوقيع هو على المعاملة التي تعتقد أنك وقعت عليها. إذا كانت الإضافة ذات نية خبيثة، يمكنها أن تجعلك توقع على شيء، وفي النهاية يتم تنفيذ شيء آخر على السلسلة.
**لماذا أصبح هذا مشكلة نظامية**
جذر المشكلة يكمن في: صلاحيات التحديث المركزية. بعد أن يقوم المستخدم بتثبيت الإضافة، فإنه يمنح فريق التطوير السيطرة الكاملة على أمانه. الفريق قد يكون موثوقًا، لكن البنية التحتية، وعمليات النشر، وأجهزة كمبيوتر الموظفين — أي جزء من هذه الحلقة يمكن أن يُخترق، مما يؤدي إلى خسائر واسعة في الأصول.
أما من جهة المستخدم، فهو وضع سلبي تمامًا — لا يمكنك رؤية ما تم تحديثه، ولا يمكنك رفض إصدار معين من التحديث.
لهذا السبب، بدأ مجتمع Web3 يعيد النظر في تصميم بنية المحافظ. بعض المشاريع تستكشف آليات تحديث تعتمد على فصل المفاتيح، وتتيح للمستخدمين التحقق من التحديثات، وحتى بنية تعتمد على الأولوية المحلية — الهدف هو تمكين المستخدمين من السيطرة الفعلية على أمان أصولهم، بدلاً من الاعتماد الأعمى.