من التوقيع المسبق إلى فقدان السلطة، لماذا تعتبر خطوط الدفاع الأمنية في Drift غير فعالة؟

كتبه: Four Pillars

ترجمة: AididiaoJP، أخبار Foresight

النقاط الرئيسية

2026年4月1日16:05（UTC时间），تعرض بروتوكول Drift لهجوم كبير بقيمة حوالي 2.85 مليار دولار. Drift هو بورصة لامركزية لعقود المشتقات الدائمة في نظام Solana البيئي. ينتمي هذا الهجوم إلى خطة معقدة لتلاعب الضمانات: استخدم المهاجمون مفتاح مدير تم تسريبه لإطلاق سوق جديد لرمز عديم القيمة، ثم أغلقوا آلية حماية السحب، وأخيرًا استخرجوا أصولًا حقيقية من خلال قيمة ضمان مزيفة.

يجمع هذا الهجوم بين تقنية توقيع مسبق باستخدام أرقام عشوائية قابلة للتخزين (مستمرة) ووسائل متقدمة من الهندسة الاجتماعية. بدءاً من 23 مارس، أنشأ المهاجم حسابات أرقام عشوائية قابلة للتخزين لكلٍ من اثنين من الموقّعين متعددين (multi-sig) واثنين من الحسابات التي يسيطر عليها المهاجم. حتى بعد أن نفّذ الطرف البروتوكولي في 27 مارس ترحيلاً مشروعاً لعدة توقيعات، نجح المهاجم في استعادة الوصول إلى اثنين من الموقّعين داخل الـ multi-sig الجديد. حصل المهاجم على التوقيعات المسبقة من الموقّعين الشرعيين عبر تضليلهم بمحتوى المعاملة، ثم قام بتخزين هذه التوقيعات المسبقة باستخدام الأرقام العشوائية القابلة للتخزين، وبعدها نفّذها على دفعات في 1 أبريل، لينتهي الأمر بالاستيلاء على صلاحيات الإدارة. لا تتضمن هذه الواقعة تسريب عبارة الاسترداد (seed/mnemonic) أو ثغرات في العقود الذكية.

تُعد هذه الواقعة مرة أخرى مثالاً كبيراً على خطأ أمني تشغيلي جسيم، يفصلها عن حدث هجوم Resolv مجرد 10 أيام. انهيار Resolv نجم عن حقيقة أنه لم يقم بتعيين آلية multi-sig إطلاقاً؛ بينما على الرغم من أن Drift لديه multi-sig، فقد تعرض للهزيمة أيضاً بسبب انخفاض العتبة وقلة وجود آليات أمان إضافية. تُظهر هاتان الواقعتان معاً أن إعادة تصميم جذرية للبنى ذات الامتيازات باتت أمراً ملحاً للغاية.

ملخص الحدث

المصدر: @DriftProtocol

في 1 أبريل 2026 عند الساعة 16:05 (UTC)، تعرّض بروتوكول Drift، وهو بورصة لامركزية للعقود الدائمة من فئة الدرجة الأولى على Solana، لهجوم واسع النطاق. ويُعد Drift بروتوكولاً يوفر تداولاً بالرافعة المالية، وتداولاً فوريّاً، وإقراضاً وخدمات DeFi أخرى متعددة، كما تجمع بنيته بين صانع آلي افتراضي لصناعة السوق وسجل أوامر على السلسلة. وقبل وقوع الهجوم مباشرة، كان البروتوكول قد قام بتأمين إجمالي قيمة بنحو 309 ملايين دولار.

المصدر: @PeckShieldAlert

حوالي الساعة 18:10 (بالتوقيت العالمي UTC)، أي بعد حوالي ساعتين من بدء الهجوم، نشر فريق Drift بياناً على منصة X يطلب من المستخدمين إيقاف الإيداعات. وبعد ذلك أكد الفريق وقوع حادث الهجوم وأوقف جميع ميزات الإيداع والسحب. ووفقاً لتقديرات عدة شركات أمنية وتحليل على السلسلة، بما في ذلك PeckShield وLookonchain، بلغت الخسائر نحو 285 مليون دولار. اتخذت محفظة Phantom إجراءات فورية عبر حجب الوصول إلى هذا البروتوكول.

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

تحليل السبب الجذري

تكمن الحيلة الأساسية في هذا الهجوم في أن المهاجم استغل صلاحيات الإدارة التي تم تسريبها لإجراء تلاعب بالضمان. إذا كان حدث Resolv هو «تسريب مفتاح يمتلك صلاحية الصك (mint)»، فإن حدث Drift هو «تسريب مفتاح يمتلك صلاحية طرح السوق وإعدادات الأمان». تختلف المظاهر بينهما، لكن الجذر واحد. فيما يلي سنقوم بتحليل مسار الهجوم خطوة بخطوة.

المصدر: Dexscreener

الأداة الأكثر مباشرة في هذه الهجمة كانت CarbonVote Token (CVT)، وهي عملة ذات سيولة منخفضة جداً. أحد العناوين التي يسيطر عليها المهاجم (FnYXwy...LpAjjx) قام بإصدار هذه العملة قبل الهجوم بثلاثة أسابيع تقريباً. إجمالي المعروض من CVT يبلغ حوالي 750 مليون وحدة، ويحتفظ المحفظة التابعة للمهاجم بأكثر من 80% منها. أنشأ المهاجم على Raydium حوض سيولة بأدنى قيمة تقارب 500 دولار، ثم نفّذ صفقات متواصلة لرفع حجم التداول.

تسمح دالة initializeSpotMarket في بروتوكول Drift للمسؤول الإداري بتحديد عنوان الأوراكل ومصدر معلماته مباشرةً. وبالرجوع إلى تكوين حزمة أدوات تطوير البرمجيات (SDK) للأسواق الفورية القائمة، يتبين أن كل سوق يعرّف أوراكله ومصدر الأوراكل والحقول المتعلقة بإصدار الرموز بشكل منفصل. وهذا يعني أنه حتى لو كان رمزاً مثل CVT لا يحتوي على تغذية Pyth، فإنه طالما حصل المهاجم على صلاحيات الإدارة، يمكنه استخدام أي مصدر أوراكل لطرحه كـ سوق.

في هذه الهجمة، حدد المهاجم لسوق CVT تغذية (price feed) من Switchboard بوصفها مصدر الأوراكل. يتميز Switchboard بأنه شبكة أوراكل؛ ومن السهل نسبياً إنشاء تغذية مخصصة. قام المهاجم بإعداد تغذية يتحكم بها، وجرى من خلالها تقييم قيمة 785 مليون وحدة من CVT على أنها تساوي عدة مئات من ملايين الدولارات. تُظهر منصات تتبع الأسعار مثل Dexscreener أن سعر CVT يبلغ حوالي 1 دولار، لكن السيولة الفعلية في السوق وقيمته الجوهرية شبه معدومة.

بدأ ظهور محفظة الإفراغ (HkGz4K...ovpZES) المستخدمة في الهجوم قبل حوالي ثمانية أيام، أي لأول مرة في 24 مارس. أرادت هذه المحفظة الحصول على إعادة شحن مسبقة (preload) عبر بروتوكول NEAR، وتوضح السجلات على السلسلة أنه حتى يوم الهجوم، قامت المحفظة بإتمام 325 معاملة.

تستحق كذلك الاهتمام أنشطة الموقّع الإداري المستخدم في يوم الهجوم (H7PiGq...y7ZgL). فقد سجّلت هذه المفاتيح في الإجمالي 29 معاملة فقط. حدثت أول معاملة في 31 مارس الساعة 15:05 (UTC)، أي قبل يوم من الهجوم؛ وحدثت آخر معاملة في 1 أبريل الساعة 18:05 (UTC)، أي في يوم الهجوم نفسه. تشير بيانات السلسلة إلى أن زمن نشاط هذا المفتاح على السلسلة استمر قرابة 27 ساعة. ويمكن فهم السبب بوضوح من السجلات على السلسلة.

لا يتم إدارة صلاحيات الإدارة في بروتوكول Drift بواسطة حساب واحد يمتلكه المستخدمون (EOA) مباشرة، بل عبر آلية multi-sig. ومع ذلك، كشفت عملية التحقيق اللاحقة أن مسار الهجوم كان أعقد بكثير من مجرد اختراق multi-sig. قبل الهجوم بحوالي تسعة أيام، قام المهاجم بإنشاء أربعة حسابات أرقام عشوائية قابلة للتخزين. كان اثنان منها مرتبطين بالموقّعين ضمن multi-sig الخاص بلجنة أمان Drift، بينما كان الاثنان الآخران تحت سيطرة المهاجم. الأرقام العشوائية القابلة للتخزين هي آلية على Solana تتيح تجاوز فترة الصلاحية القصيرة نسبياً لحاش (hash) الكتلة في المعاملات العادية والتي تبلغ حوالي دقيقة واحدة؛ ما يسمح بجمع التواقيع مسبقاً وتنفيذها لاحقاً. ويُعتقد أن المهاجم استغل هذه الآلية للحصول على التواقيعات المسبقة من الموقّعين الشرعيين عبر تضليل محتوى المعاملة.

بعد أربعة أيام، نفّذ فريق Drift ترحيلاً مخططاً للـ multi-sig بسبب تغيير أحد أعضاء لجنة الأمان. كانت هذه عملية ضمن الإجراءات الروتينية، لكن المهاجم تمكن من التكيف مع هذا التغيير بنجاح.

في اليوم السابق للهجوم، أنشأ المهاجم أحد الموقّعين في الـ multi-sig بعد الترحيل (6UJbu9...Pvu924) حساباً جديداً للأرقام العشوائية القابلة للتخزين. وفي تلك اللحظة كان المهاجم قد استعاد بالفعل وصولاً فعالاً إلى اثنين من الموقّعين من أصل خمسة داخل الـ multi-sig المحدث. وهذا يشير إلى أن المهاجم قد تمكن من اختراق عميق للنظام، إلى درجة أنه استطاع التعامل مع تغييرات غير متوقعة مثل ترحيل الـ multi-sig.

في يوم الهجوم، قام فريق Drift بتنفيذ سحب تجريبي روتيني (test withdrawal) من صندوق التأمين. بعد حوالي دقيقة واحدة فقط، نفّذ المهاجم بسرعة معاملة عشوائية قابلة للتخزين سبق توقيعها مرتين على نحو متتالٍ.

المصدر: solscan

تم تنفيذ المعاملة الأولى على Squads multi-sig عبر أوامر VaultTransactionCreate وProposalCreate وProposalApprove، لإنشاء اقتراح تحويل إداري خبيث وتسجيل الموافقة الأولى.

بعد ذلك مباشرة، استخدمت المعاملة الثانية الأرقام العشوائية القابلة للتخزين لتنفيذ أوامر ProposalApprove وVaultTransactionExecute. تم تحقيق عتبة الثلثين (مقياس 5/2) فوراً، وبسبب ضبط قفل زمني على صفر ثانية، تم تنفيذ هذه المعاملة على الفور. عندها تم استدعاء أمر UpdateAdmin داخل برنامج Drift V2، لنقل عنوان المدير إلى المهاجم (H7PiGq...y7ZgL).

تكمن التفاصيل المحورية هنا في أن هاتين المعاملتين تم إنجاز جميع التواقيع لهما مسبقاً، ثم تم تقديمهما على دفعات في يوم الهجوم. ومن المرجح أن الموقّعين لم يفهموا بشكل كافٍ محتوى المعاملة التي قاموا بتوقيعها. إن استخدام مصطلح «misstated transaction» لدى فريق Drift يشير إلى أن الموقّعين تم خداعهم للتوقيع على معاملات تحويل إدارية خبيثة تم تمويهها على أنها عمليات اعتيادية. أما وظيفة الأرقام العشوائية القابلة للتخزين فتتمثل في تخزين هذه التواقيع المسبقة بشكل غير محدود، ما يسمح للمهاجم بتنفيذها في الوقت الذي يختاره.

بعد استبدال الموقّع الإداري، قام الموقّع الجديد باستدعاء برنامج Drift V2 (dRifty...cn33UH) لتنفيذ عمليتين.

المصدر: solscan

أولاً، قام المهاجم عبر أمر initializeSpotMarket بتسجيل CVT على Drift كسوق فوري جديد. وخلال هذه العملية، تم إنشاء حساب سوق فوري جديد (BY3WYn...FVU1Cf) وحسابين لرموز CVT، وتم ضبط عنوان مشتق خزان Drift (PDA, JCNCMF...XXJfrw) ليكون مالكاً للرموز.

يعمل Drift على نظام ضمان متعدد الأصول؛ وهذا يعني أنه يمكن استخدام الرموز المسجّلة في سوق فوري جديد فوراً كضمان. ومع ذلك، لكي تُعتبر ضماناً مؤهلاً، يجب أن تكون قيمة المعامل initial_asset_weight وقيمة المعامل maintenance_asset_weight في هذا السوق مُضبوطة على عدد موجب أكبر من صفر، بينما تكون القيمة الافتراضية منخفضة جداً أو قريبة من الصفر. تُظهر مراجعة معاملات الهجوم (4a5962R...st82X) أن updateSpotMarketMarginWeights (أو تحديث مكافئ لمعاملات المخاطر) و initializeSpotMarket تم تنفيذهما معاً ضمن المعاملة نفسها، حيث قام المهاجم بتعيين أوزان ضمان CVT على القيمة القصوى.

هذا يكشف عن عيب تصميم محوري من منظور الدفاع العميق: عمليات مثل إطلاق السوق، وتحديد مصدر أوراكل، وتكوين أقصى وزن للضمان، وتعطيل حماية السحب—كلها يمكن إنجازها مرة واحدة وبشكل كامل داخل معاملة واحدة فقط. هذه الإضافة تُستخدم لمنع مخاطر تركّز المراكز الكبيرة عبر معامل خصم الوزن (weight discount factor)؛ لكن بعد ضبط الوزن نفسه على القيمة القصوى، يفقد أيضاً فائدته العملية. إذا كان هذا البرنامج يفرض سقفاً لوزن الأسواق المُنشأة حديثاً، أو يضع قفلاً زمنياً مستقلاً عند تغيير الأوزان (time lock)، فلن يكون ممكناً تحقيق هجوم يُفكك جميع إجراءات الدفاع مرة واحدة.

المصدر: solscan

ثانياً، في المعاملة نفسها، قام المهاجم باستدعاء أمر updateWithdrawGuardThreshold خمس مرات، رافعاً بذلك حدّ سحب الأصول الرئيسية إلى مستوى متطرف. تم ضبط حدود جميع الأسواق على قيمة موحّدة تقارب 500 تريليون، ما يدفع عتبة آلية حماية السحب إلى ما يعادل اللانهاية عملياً، وبالتالي إلغاء وظيفة الحماية الأمنية المصممة لمنع عمليات السحب غير الاعتيادية الكبيرة.

دمرت هذه المعاملة (4a5962R...st82X) في الوقت نفسه ثلاث خطوط دفاع رئيسية في Drift.

أولاً، تم اختراق آلية التسعير عبر تعيين تغذية (喂价) من Switchboard يسيطر عليها المهاجم كمرجع للأوراكل. ثانياً، تم ضبط أوزان الضمان على القيمة القصوى، ما يجعل رمزاً بلا قيمة جوهرية يُعتبر ضماناً ذا جودة. ثالثاً، تمت رفع عتبة آلية حماية السحب إلى مستوى يقارب 500 تريليون، وهو ما يلغي فعلياً آلية الحجب الخاصة بعمليات السحب غير الطبيعية.

بما في ذلك تغيير صلاحيات الإدارة، فقد حطّم المهاجم البنية الأمنية الكاملة للبروتوكول عبر معاملتين فقط. ومن منظور تدقيق الكود، يطرح هذا تناقضاً عميقاً: كود العقود في Drift ينفَّذ بالكامل بالطريقة نفسها التي تم تأكيدها أثناء التدقيق. فقد سجّل initializeSpotMarket سوقاً جديداً كما هو مصمّم، وحدد مصدر الأوراكل وضبط معلمات الأوزان؛ كما قام updateWithdrawGuardThreshold بتعديل الحدود كما هو مصمّم. وتكمن المشكلة الجذرية في تصميم النظام نفسه—إذ إن هذا التصميم يسمح بسلسلة هجوم كاملة أن تكتمل داخل معاملة واحدة. وهذا لا يقع ضمن نطاق تدقيق الكود، بل ضمن نطاق تصميم البنية ذات الامتيازات وقيود المعاملات.

في النهاية، قام المهاجم عبر حساب مستخدم جديد تم إنشاؤه على Drift بإيداع حوالي 785 مليون وحدة من CVT بوصفها ضماناً. قامت تغذية أوراكل Switchboard التي يتحكم بها المهاجم بتقييم هذه القيمة على أنها عدة مئات من ملايين الدولارات، كما أن ضبط وزن الضمان على القيمة القصوى اعتبر فعلياً معظم التقييم كضمان فعّال. يعمل نظام الهامش في Drift تماماً وفق التصميم المتوقع. المشكلة هي أن كل معلمة تم إدخالها إلى هذا النظام تم التلاعب بها بشكل خبيث من قبل المهاجم.