وفقًا لبيانات منصة Beosin Alert، بلغ إجمالي الخسائر الناتجة عن各种 أحداث أمنية في أغسطس 2026 حوالي 76.15 مليون دولار أمريكي، وحدثت 『29』 حادثة أمنية كبيرة، وكان السبب الرئيسي هو ثغرات العقود. من بينها، حدثت 18 حادثة أمنية بسبب ثغرات العقود/الشبكة، وحدثت حادثتان أمنيتان بسبب تسريب المفاتيح الخاصة، ولا تزال أمان العقود الذكية وإدارة المفاتيح الخاصة تمثل نقاط ضعف في الأمن الويب3.
أكبر 10 خسائر في أغسطس
في 13 أغسطس، تم سرقة أصول رقمية مثل WBTC و cbBTC و LDO و USDS و CRV من عنوان المستخدم الفردي 0x13e3....179e بسببتسريب المفتاح الخاص، بخسارة إجمالية تقدر بحوالي 25.6 مليون دولار، وهي أكبر حادثة أمنية من حيث الخسارة الفعلية. في 30 أغسطس،Cronos تعرض بروتوكول الإقراض على شبكة Cronos، Tectonic، لهجوم إلكتروني بسبب ثغرة في العقد الذكي، وتُقدّر الخسائر بحوالي 74 مليون دولار. وأدى هذا الهجوم إلى اتخاذ شبكة Cronos إجراءات طارئة، حيث أوقفت الشبكة وأجرت عكس المعاملات، وتمكن القراصنة في النهاية من نقل حوالي 6 ملايين دولار عبر معاملات عبر السلسلة إلىEthereumالشبكة.
بالإضافة إلى ذلك، تم إنشاء حوالي 4 مليارات من رموز ONE إضافية على سلسلة Harmony بسبب ثغرة أمنية، بخسارة اسمية تزيد عن 4 ملايين دولار أمريكي، لكن تم التخلص من حالة الرموز المزيفة في النهاية من خلال عكس المعاملات، وبالتالي لا تُحسب ضمن الخسائر.
أنواع المشاريع المهاجمة وحالات الخسائر في كل سلسلة
شملت الضحايا هذا الشهر سلاسل عامة، بروتوكولات إقراض، تطبيقات محفظة، عقود رموز، جسور عبر السلسلة، ومستخدمين عاديين، حيث شهدت مشاريع DeFi أكبر خسائر بقيمة 33.09 مليون دولار أمريكي؛ بينما خسرت العناوين الشخصية حوالي 28.40 مليون دولار أمريكي بسبب تسريب المفاتيح الخاصة أو الهجمات التصيدية. كان عقود الرموز هي الأكثر استهدافًا، بواقع 10 هجمات؛ بينما جاءت عقود DeFi في المرتبة الثانية بـ 9 هجمات.
كان Ethereum هو السلسلة الأكثر خسارة في مايو، بخسائر تجاوزت 48.58 مليون دولار أمريكي، وشملت 15 حادثة أمنية، ولا تزال معظم بروتوكولات DeFi وهجمات التصيد المستهدفة للضخامة تتركز على Ethereum. وكانت BNB Chain هي السلسلة الثانية من حيث عدد الحوادث الأمنية، لكن الأهداف الرئيسية كانت عقود الرموز، وكانت الخسائر أقل. بالإضافة إلى ذلك، حدثت حوادث أمنية على سلاسل عامة أخرى مثل Cronos وBase وHarmony وBitcoin وSolana، مما يدل على طابع متعدد السلاسل للهجمات على السلسلة.
تحليل الحدث الأمني الرئيسي
1. تيكتونيك و مونويل: تلاعب في الأسعار
Tectonic و Moonwell هما بروتوكولات إقراض على السلسلة، وتم استهدافهما بسبب تلاعب بأسعار أصول ضمانية ذات سيولة ضعيفة، مما سمح باقتراض كميات زائدة من الأصول بناءً على قيمة أصول مبالغ فيها. في هجوم Tectonic، قام المهاجم بدفع سعر رمز الحوكمة الخاص ببروتوكول Tectonic، $TONIC، إلى أعلى بـ 100 مرة، مما مكنه من الحصول على قرض بقيمة حوالي 74 مليون دولار أمريكي، ثم اقتراض أصول مثل USDT. بعد وقوع الحادث، تم تعليق مؤقت للكتل على شبكة Cronos، وقام المهاجم بنقل حوالي 6 ملايين دولار أمريكي عبر السلسلة إلى إيثريوم قبل تعليق الشبكة. بعد ذلك، تم تنفيذ عملية تراجع على شبكة Cronos لاستعادة الخسائر.
عنوان ربح القراصنة بالإيثيريوم: 0xc404160B79BD8905061a1cAecBeCa2EEab3f72DD مع تدفق الأموال المسروقة:
يُحتفظ حاليًا بحوالي 2659 ETH في 0xc4041، وتم نقل 140.1 ETH إلى 0x6df89c42f0abdfaa2b5b77edcdafbc945ed6ee6c، ثم تم توزيعها لاحقًا على عناوين جديدة متعددة.
خسر Moonwell حوالي 8.7 مليون دولار بسبب قيام المهاجمين بمناورة أسعار رمز MAMO ذو السيولة المنخفضة لاستعارة cbBTC:
لم تكن هاتان الهجمتان ناتجتين عن ثغرات في العقد الذكي، بل بسبب أن البروتوكول يُقيّم الضمانات بناءً على سيولة فورية ضعيفة، مما يؤدي إلى حساب خاطئ لقيمة الضمانات. لتجنب مثل هذه الهجمات، يمكن للبروتوكول أن يحصل على بيانات من مصادر متعددة عبر وسطاء أسعار، ويتخذ قرارات إضافية في حالات التقلبات الحادة في الأسعار.
2. Harmony: هجوم إعادة التشغيل
Harmony هي طبقة 1 تدعم التجزئة، وتعمل على أربعة أجزاء، وتنقل الأصول بينها عبر آلية غير متزامنة تعتمد على الإيصالات. يُنشئ الجزء المصدر إيصالات مشفرة للمعاملات الصادرة، ويقوم الجزء الهدف بالتحقق من أن الإيصال وإثبات ميركل الخاص به يتطابقان مع رأس الكتلة المصدر الموقّع، قبل تسجيل المعاملة، وكل إيصال يمكن استخدامه مرة واحدة فقط.
الثغرة المستغلة في هذا الهجوم موجودة في الأجزاء الموروثة من نظام الشريحة في Harmony. سابقًا، كانت Harmony تتحقق مما إذا كان إيصال الشريحة قد استُخدم بالفعل من خلال مراجعة حقلين: CXMerkleProof.ShardID و BlockNum،
بما أن هذين الحقلين يقعان خارج رأس الكتلة الموقعة، يمكن للمهاجم تعديلهما دون إلحاق ضرر بأي وظيفة موجودة. في هذه الهجوم، حصل المهاجم على إيصال عبر الشريحة وغيّر ShardID و BlockNum فيه، مما جعل برنامج التحقق يُعرّفه كإيصال جديد تمامًا. وقبلت الشريحة المستهدفة الإيصال المعدل وأعادت تسجيله، بينما لم تخصم الشريحة الأصلية الأصول المقابلة.
هذا هجوم إعادة تشغيل نموذجي جدًا. يجب أن يكون أي حقل مستخدم كـ "علامة للاستخدام الواحد" جزءًا من رأس موقّع. عند التحقق من الإيصال، يجب قراءة معرف الشريحة ورقم الكتلة مباشرة من رأس الكتلة الموثوق به، وليس من الحقول غير الموثوقة في بنية الإثبات.
3. Term Finance: هجوم الحوكمة
Term Finance هو بروتوكول إقراض بأسعار فائدة ثابتة مبني على DeFi، وكل خزنة (Vault) فيه هي خزنة ERC-4626 مبنية على كود Yearn V3. ولا تتم حوكمة خزائن Term Finance عبر التصويت بالموافقة، بل عبر التصويت بالاعتراض. عندما يقترح المُنظِّم تغييرًا في المعلمات، يفتح المُحكم نافذة تطلب من حاملي رموز LP تقديم اعتراضات. وهناك ثغرة خطيرة في عتبة التصويت الحوكمي:
● عدم وجود حد أدنى مطلق للأصوات أو رأس المال: شروط اعتماد المقترح، isSupportThresholdReached() و isMinParticipationReached()، تتحقق فقط من النسب النسبية، وليس من الأصوات المطلقة. هذا يعني أنه بمجرد تحقيق الأغلبية النسبية، يمكن اعتماد المقترح، بغض النظر عن العدد الإجمالي للمشاركين أو إجمالي رأس المال المُستثمر.
● انخفاض مشاركة شديد: لم يُحَوِّل تقريبًا أي مودع حصة الخزينة (tmvETH) إلى رمز حوكمة (gtmvETH) للمشاركة في التصويت. وهذا أدى إلى انخفاض شديد في العرض الإجمالي لرموز الحوكمة الخاصة بالخزينة ذات الصلة.
استغل المهاجمون العيب التصميمي المذكور أعلاه لتنفيذ هجوم حوكمة على الخزينة بتكلفة منخفضة جدًا:
(1) الحصول على حق التصويت: استخدم المهاجم حوالي 0.5 ETH للحصول على حوالي 0.485 حصة من صندوق tmvETH، ثم قام بتحويلها 1:1 إلى 0.485 رمز حوكمة gtmvETH للحصول على حق التصويت.
(2) تقديم اقتراح ضار: عند إنشاء المُهاجم للProposal، سجّل العقد إجمالي كمية رموز الحوكمة وقتها بـ 0.535 gtmvETH فقط. وهذا يعني أن持有的 0.485 gtmvETH من المُهاجم تمثل 90.66% من الإجمالي.
(3) التصويت والتنفيذ: المهاجم، كمُصوّت الوحيد، ألقى صوتًا مؤيدًا. وبما أنه لا توجد أصوات معارضة، فإن نسبة الدعم تجاوزت بكثير عتبة 50٪؛ في الوقت نفسه، تجاوزت سلطته التصويتية الفردية الحد الأدنى المطلوب للمشاركة (minVotingPower) المحسوب بناءً على كمية العرض الإجمالية المنخفضة جدًا.
(4) سحب الأصول: بعد مرور الاقتراح، تم تنفيذ عملية ضارة لسحب الأصول من الخزنة (WETH)
استخدم المهاجمون نفس الأسلوب لاختراق 6 خزائن من Term Finance، مما تسبب في خسائر بلغت حوالي 8.5 مليون دولار أمريكي.
كما أن هذا الهجوم هو مثال نموذجي جدًا على هجوم حوكمة بروتوكول على السلسلة. بالنسبة للحوكمة على السلسلة، يجب على فرق المشاريع تحديد نقاط تحقق التالية للوقاية:
● تحديد عدد أصوات مطلق أو حد أدنى من رأس المال: لا يمكن أن تعتمد مقترحات الحوكمة فقط على النسب النسبية للمرور. يجب تحديد عتبة صارمة قائمة على عدد مطلق، مثل متطلبات أن تصل الأصوات المؤيدة إلى مبلغ معين (مثل مليون دولار أمريكي) أو عدد عناوين مستقلة.
● تعيين وصي أو مسار إلغاء لقفل الوقت: على الرغم من أن تنفيذ الحوكمة يحتوي عادةً على تأخير، إلا أن هذا يوفر فقط وقتًا ردّيًا محددًا. يجب على فريق المشروع تزويد فترة التأخير بآلية وصاية فعالة (Guardian) أو مسار لإلغاء المقترح. في حال اكتشاف مقترح ضار خلال فترة التأخير، يمكن للوصي التدخل فورًا وإلغاؤه.
● مراقبة مشاركة الحوكمة: يجب على البروتوكول إنشاء مراقبة مباشرة لمستوى مشاركة الحوكمة في الخزائن المختلفة. عند اكتشاف انخفاض غير طبيعي في إجمالي عرض رموز الحوكمة أو معدل المشاركة في التصويت لخزانة معينة، يجب إرسال تنبيه فوري، بل وتفعيل تدابير حماية تلقائية.
اتجاهات التهديدات الأمنية لـ Web3
أعمق الاتجاهات التي تطرحها أمان Web3 في عام 2026 هي التوسيع المنهجي لسطح الهجوم. تظهر الثغرات في آنٍ واحد على مستوى الكود، والعمليات اليومية، والتفاعلات، ولا يمكن تغطية أمان العمليات، والحوكمة على السلسلة، وثغرات المنطق التجاري فقط من خلال مراجعات أمان أو أدوات متعددة. هذا يطرح تحديات جديدة على مشاريع Web3 لبناء أنظمة دفاع أمني.
بالإضافة إلى ذلك، تزداد الهجمات على عقود DeFi ومستخدمي الأفراد. يمكن للمهاجمين استغلال ثغرات العقد أو التفويضات بسهولة، ويجب على مطوري العقود أو مشغليها إعادة فحص أمان العقد، وينبغي إجراء تدقيقات أمنية متعددة ومتعددة الأطراف للعقود التي تتعامل مع الأعمال الأساسية. بالنسبة للمستخدمين الأفراد، يجب التحقق بانتظام من خلال متصفح البلوكشين أو أدوات إلغاء التفويض لإلغاء التفويضات الخاصة بالعقود التي لم تعد مستخدمة، كما ينبغي زيادة الوعي بالأساليب الخادعة الشائعة والجديدة لتعزيز الأمان.
تم إعداد هذا المقال من قبل فريق الأمان في Beosin بالاعتماد على نظام إنذار الأمان Beosin Alert، وبيانات السلسلة، وتحليلات ما بعد الحدث التي نشرها فريق المشروع. لا تتردد في التواصل معنا أو تقديم ملاحظاتك في حال وجود أي أسئلة.