رجوع

2026/11/03

توقيع واحد ظل يستنزف المحفظة الساخنة لـ Binance: تفويض EIP-7702 وراء الاختراق

50 تفويضًا من نوع EIP-7702 موقّعة مسبقًا، تطابق منها واحد، وتفويض بقي بعد إفراغ المحفظة. كيف حدث ذلك، وما الذي يجب على مشغلي المحافظ الساخنة مراقبته.

في مقالنا الأول عن اختراق Binance، تناولنا كيف بدأ الهجوم بحسب التقارير: جهاز محمول لأحد فريق DevOps تعرّض للاختراق، ومهاجمون تمكّنوا من الوصول إلى الأنظمة التي تعتمد الإجراءات الحساسة. وقد أظهر تحليل على السلسلة (on-chain) أجرته شركة الأمن Blockaid لاحقًا كيف جرت المرحلة الأخيرة على Ethereum. فقد استُخدمت فيها EIP-7702، وهي ميزة أُضيفت إلى Ethereum في مايو 2025، وتكشف عن خطر لم يستعد له كثير من مشغلي المحافظ الساخنة بعد.

باختصار: حوّل تفويض واحد موقَّع أكبرَ محفظة ساخنة لـ Binance على Ethereum إلى حساب يستطيع المهاجم التحكم فيه. ولم ينتهِ هذا التحكم عندما أصبحت المحفظة فارغة، ولم يكن لينتهي بتدوير المفتاح أيضًا.

أبرز النقاط

  • جمع المهاجم 50 تفويضًا من نوع EIP-7702 موقّعة مسبقًا، تغطي 50 قيمة nonce متتالية، في معاملة واحدة؛ وتطابق منها تفويض واحد بالضبط سلّم تنفيذ المحفظة إلى عقد المهاجم.
  • يبقى تفويض EIP-7702 قائمًا إلى أن يستبدله الحساب أو يلغيه. وقد أُخذت الإيداعات التي وصلت بعد عملية السحب الأولى، والتي تجاوزت في إحدى المرات 200 مليون دولار، دون أي توقيع جديد.
  • تدوير المفتاح الخاص (private key) لا يزيل التفويض، لأن التفويض مرتبط بالعنوان. ولا يزيله إلا إلغاء صريح.
  • لا يزال السؤال مفتوحًا حول كيفية حصول المهاجم على 50 توقيعًا صالحًا. وتقول Binance إنها لم تجد أي دليل على تسريب مفتاح خاص.
  • ينبغي لمشغلي المحافظ الساخنة مراقبة حالة التفويض، ورفض توقيع أي تفويض لم يقصدوه، وإدراج الإلغاء الصريح في أدلة الاستجابة للحوادث لديهم.

مقدمة سريعة عن EIP-7702

تتيح EIP-7702 لحساب Ethereum عادي (حساب مملوك خارجيًا، أو EOA) أن يفوّض تنفيذه إلى عقد ذكي. يوقّع مالك الحساب تفويضًا يحدد عنوان العقد والسلسلة وقيمة nonce الحالية للحساب. وبمجرد معالجة معاملة تحمل هذا التفويض، تُنفَّذ الاستدعاءات الموجهة إلى الحساب بكود العقد، كما لو كان الحساب محفظة عقد ذكي. وتوجد هذه الميزة لأسباب مشروعة، مثل تجميع المعاملات ودفع الرسوم نيابةً عن المستخدم.

ثلاث تفاصيل من المواصفة مهمة لهذه الحادثة:

  • تُنقل التفويضات في نوع جديد من المعاملات هو type 4 (0x04)، ويمكنه أن يحمل قائمة منها. ويستطيع أي شخص إرسال المعاملة؛ فكل ما يحتاجه التفويض هو توقيع صالح من الحساب.
  • لا يكون كل تفويض صالحًا إلا إذا تساوت قيمة nonce فيه مع قيمة nonce الحالية للحساب. وإذا لم تتطابق، يُتجاوز ذلك التفويض وحده، وتستمر المعاملة مع التفويض التالي.
  • التفويض دائم. فهو يبقى إلى أن يوقّع الحساب تفويضًا جديدًا يشير إلى عنوان آخر، أو إلى العنوان الصفري (zero address)، وهو ما يلغيه.

كيف استُولي على محفظة Binance 14

ترسل المحفظة الساخنة لمنصة تداول نشطة المعاملات باستمرار، فتتغير قيمة nonce الخاصة بها دائمًا. ولا يستطيع مهاجم يُعدّ تفويضًا موقّعًا مسبقًا أن يعرف أي قيمة nonce ستكون الحالية عند تنفيذ المعاملة. ووفقًا لتحليل Blockaid، حلّ المهاجم هذه المشكلة بتوقيع نطاق من القيم بدلًا من قيمة واحدة.

الوقت (UTC، 29 أكتوبر)ما حدث
15:59ينشر المهاجم عقد “sweeper” (كانس). العقد غير موثّق، ولا يستطيع استدعاءه سوى عنوان المشغّل التابع للمهاجم.
20:20:59تحمل معاملة واحدة من type 4 خمسين تفويضًا من نوع EIP-7702، جميعها موقّعة بمفتاح المحفظة الساخنة Binance 14، لخمسين قيمة nonce متتالية. يتطابق تفويض واحد بالضبط مع قيمة nonce الحالية للمحفظة، فتصبح المحفظة مفوَّضة إلى الكانس.
20:24:23ينقل استدعاء واحد للكانس نحو 167,464 ETH و1.615 مليار USDT وعشرات الرموز الأخرى إلى خارج المحفظة، تاركًا 1 ETH للرسوم.
20:41وهي لا تزال مفوَّضة، تُستخدم المحفظة لنقل نحو 823 مليون USDC من حساب ذكي منفصل كانت Binance 14 تتحكم فيه.
من 21:04 إلى 23:56تُكنس المحفظة أربع مرات أخرى مع وصول أموال جديدة. وفي الساعة 21:44 وحدها، أُخذ أكثر من 200 مليون دولار من الإيداعات الجديدة دون أي توقيع جديد.
00:10 (30 أكتوبر)يُلغى التفويض، وفقًا للتسلسل الزمني الذي نشرته Hypernative.

تكشف خطوة USDC عن أثر ثانٍ. فالحساب المفوَّض يحتفظ بكل دور يشغله في العقود الأخرى: مالك، أو منفّذ، أو منفِق معتمد. ومن يتحكم في تنفيذه يستطيع استخدامها جميعًا.

لماذا ظلت المحفظة الفارغة خطرة

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

وهذا ما حدث هنا. فقد واصلت الأموال الوصول إلى Binance 14 بعد عملية الكنس الأولى، ثم كُنست مجددًا. ولم يكن تدوير المفتاح ليفيد: فكما تشير Blockaid، يتطلب إلغاء التفويض تفويضًا جديدًا من الحساب نفسه يشير إلى العنوان الصفري. وإلى أن يُعالَج هذا الإلغاء، ينبغي التعامل مع العنوان على أنه تحت سيطرة المهاجم.

نصيحة: عند وقوع حادثة، ألغِ التفويض أولًا، ثم دوِّر المفاتيح وأعد تمويل المحفظة. وأوقف كل عملية آلية ترسل أموالًا إلى العنوان المتأثر إلى أن تتأكد من زوال التفويض.

ما الذي لم يُحسم بعد

حملت التفويضات الخمسون جميعها توقيعات صالحة من مفتاح Binance 14. وهناك تفسيران عامان، ولا تحسم الأدلة المتاحة علنًا بينهما حتى الآن:

  • تسرّب المفتاح، ووقّع المهاجم التفويضات مباشرة.
  • أسيء استخدام بنية التوقيع: إذ جعل المهاجم أنظمة التوقيع الخاصة بـ Binance نفسها توقّع بيانات من اختياره دون أن يستخرج المفتاح قط.

قالت Binance إنها لم تجد أي دليل على تسريب المفتاح الخاص للمحفظة، وإن تحقيقها لا يزال جاريًا. وصرّح الرئيس التنفيذي لـ Blockaid لموقع Cointelegraph بأن النشاط يبدو اختراقًا لبنية التوقيع أكثر منه تسريبًا للمفتاح، لكن هذا تقييم أولي من جهة خارجية. وإلى أن تنشر Binance تقرير ما بعد الحادثة، نعتبر هذا السؤال مفتوحًا.

ما الذي ينبغي فعله إذا كنت تشغّل محافظ ساخنة

1. راقب حالة التفويض

الحساب المفوَّض يمتلك كودًا. ووفقًا لـ EIP-7702، يكون كوده هو مؤشر التفويض 0xef0100 متبوعًا بعنوان العقد المفوَّض إليه المكوّن من 20 بايت. أما الحساب EOA العادي فلا يمتلك أي كود. ويمكنك فحص أي عنوان باستدعاء JSON-RPC قياسي:

curl -s -X POST -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","id":1,"method":"eth_getCode","params":["0xYOUR_HOT_WALLET","latest"]}' \
  https://YOUR_RPC_ENDPOINT

النتيجة 0x تعني عدم وجود تفويض. والنتيجة التي تبدأ بـ 0xef0100 تعني أن العنوان مفوَّض. افحص ذلك لكل محفظة ساخنة في كل كتلة أو على فترات قصيرة، وأطلق تنبيهًا فوريًا عند أي تغيير لم تخطط له.

2. راقب معاملات type 4 التي تخص عناوينك

المعاملة التي تفوّض محفظتك لا يلزم أن تصدر من محفظتك. إذ يستطيع أي شخص إرسالها، ما دامت تحمل تفويضًا صالحًا موقّعًا بمفتاحك. راقب معاملات type 4 التي تتضمن قائمة تفويضاتها توقيعًا من أحد عناوينك، لا المعاملات المرسَلة منها فقط.

3. احتفظ بسجل للتفويضات

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

4. ارفض التفويضات غير المتوقعة عند جهة التوقيع

لتفويض EIP-7702 صيغة توقيع خاصة به: تجزئة (hash) البايت 0x05 متبوعًا بمعرّف السلسلة (chain ID) وعنوان العقد وقيمة nonce بعد ترميزها. وتستطيع خدمات التوقيع وسياسات HSM التعرف على هذه الصيغة. إذا كنت لا تستخدم التفويضات، فاحظر هذه البيانات تمامًا؛ وإذا كنت تستخدمها، فاسمح فقط بعناوين العقود المعروفة. ولاحظ أيضًا أن التفويض الذي يكون فيه chain ID مساويًا لـ 0 صالح على جميع السلاسل.

5. أدرج الإلغاء الصريح في دليل الاستجابة للحوادث

دوّن كيفية إلغاء التفويض لكل محفظة: من يوقّع التفويض الموجّه إلى العنوان الصفري، ومن أي نظام، وكيف تتأكد من سريانه (يعود كود العنوان إلى 0x). وأدرج إيقاف التحويلات الواردة إلى العنوان المتأثر، وتدرّب على الإجراء قبل أن تحتاج إليه.

نصيحة: تنطبق الفكرة نفسها خارج عالم العملات المشفرة. فأي صلاحية تدوم أطول من بيانات الاعتماد التي أنشأتها، مثل OAuth refresh token أو دور سحابي مفوَّض أو رمز CI/CD طويل الأمد، تحتاج إلى خطوة إلغاء صريحة خاصة بها ضمن الاستجابة للحوادث.

كيف يمكن أن تساعدك LOGIQ

تساعد LOGIQ المؤسسات على مراجعة من يملك صلاحية التصرف، وما الذي يملكها، عبر خوادم Linux والحسابات السحابية وخطوط الإنتاج (pipelines) لديها، وعلى بناء مراقبة وخطوات استجابة للحوادث تشمل الوصول المفوَّض، لا كلمات المرور والمفاتيح فقط. إذا رغبت في نظرة ثانية على ضوابطك، فاقرأ مقالنا الأول عن الاختراق أعلاه أو تواصل معنا عبر موقعنا الإلكتروني.

المصادر