هجوم BadgerDAO على الواجهة الأمامية: 120 مليون دولار اتسرّبت بسبب سكريبت واحد مُدرج

كان التدقيق نظيفًا. العقود كانت سليمة. والفلوس راحت على أي حال.

في الأيام المحيطة بالثاني من ديسمبر 2021، خسر BadgerDAO — مشروع DeFi بُني حول إدخال البيتكوين في التمويل اللامركزي — ما يقارب 120 مليون دولار من أموال مستخدميه. مفيش حيلة Flash Loan، مفيش ثغرة Reentrancy، مفيش استغلال رياضي ذكي على الخزائن. العقود الذكية نفّذت بالضبط اللي اتكتبت عشانه. المهاجم محتاجش يكسرها، لأنه في الأساس ماهاجمهاش.

هو هاجم الموقع الإلكتروني.

حد ما دسّ سكريبت خبيث في الواجهة الأمامية لـ app.badger.com بهدوء تام. لكل مستخدم فتح الصفحة، كانت تبدو زي نفس الـ dApp الموثوق اللي بيستخدمه كل يوم. لكن لما بدأوا يتعاملوا معها، الصفحة طلبت من محفظتهم إذنًا واحدًا إضافيًا وغير مرئي — وبمجرد ما ضغطوا "موافق"، التوكنات بتاعتهم بقت مش ملكهم.

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

الكذبة المريحة: "العقود مُدققة"

ثقافة الكريبتو علّمت المستخدمين يسألوا سؤال واحد قبل ما يثقوا في بروتوكول: هل اتدقق؟ التدقيق مهم. بيكتشف ثغرات حقيقية. بس في نقطة ما، "العقود مُدققة" تحوّلت لإحساس بالأمان الكامل — كأن تقرير التدقيق النظيف ده حاجز حماية حول كل حاجة عليها اسم المشروع.

هو مش كده.

التدقيق بيفحص الكود اللي على السلسلة: الخزائن، ومنطق التوكن، وضوابط الوصول. بيقول لا حاجة عن اللاب توب اللي المطوّر سيّبه متسجّل دخوله، ولا سجلات DNS اللي بتوجّه متصفحك لمكان ما، ولا الـ CDN اللي واقف قدام الموقع، ولا JavaScript اللي متصفحك بينزله ويشغّله لما تزور الـ dApp. الحاجات دي موجودة في Web2 — في حسابات السحابة، ومفاتيح API، والبنية التحتية للدومين — وهي زي ما هي بتحمل نفس الثقل اللي بتحمله Solidity.

BadgerDAO هو أوضح إثبات لهذه الفجوة على الإطلاق. زي ما وصفه تحليل تقني مباشر للحادثة: من منظور العقود الذكية للمشروع، لم يحدث شيء خاطئ، والمهاجم كان بس بيستخدم الموافقات اللي منحها المستخدمون. السلسلة تصرّفت بشكل مثالي. الموقع كذب.

الهجوم: واجهة متجر متلاعب بها مع إيصال نظيف

تخيل إنك دخلت متجر زرته مية مرة. نفس اللافتة، نفس الموظفين، نفس الكاونتر. اشتريت حاجة صغيرة، الكاشير حسبها، لمست بطاقتك. كل حاجة بانت روتينية. اللي مش قادر تشوفه إن حد استبدل قارئ البطاقة بواحد تاني بيعمل بهدوء تصريح بتحميلة تانية غير محدودة على حسابك — لغريب، متى ما أراد.

ده في الأساس اللي حصل لمستخدمي BadgerDAO.

التصنيف مهم هنا، لأنه اللي بيخلي الحادثة دي قيّمة جدًا للاستيعاب. زي ما لخّصته Vice، الاختراق لم يتضمن استغلالات عقود ذكية معقدة. بدلًا من ذلك، كان هجومًا على الواجهة الأمامية يستهدف البنية التحتية لموقع BadgerDAO على الويب — وبالتحديد حساب Cloudflare الخاص به. كان، بتعبيرهم، هجوم قديم الطراز اتوجّه لهدف Web3.

الآلية كانت أنيقة وهادية. السكريبت الخبيث كان بيطلب من محفظة المستخدم منح إذن إنفاق توكن لعنوان المهاجم. بكلام Vice، السكريبت الخبيث في الأساس خدع الناس عشان يعطوا العنوان حق إرسال التوكنات لعنوان المستغل. المستخدم كان فاكر إنه بيعمل أعمال dApp عادية. هو كان بيوقّع على مفاتيح توكناته.

باحثو الأمن بيسمّوا النمط ده تصيد الجليد (Ice Phishing): بدل ما تسرق مفتاحك الخاص، بيتخدع عشان توافق طوعًا على مُنفق خبيث. التوقيع حقيقي. الموافقة حقيقية. معاملة على السلسلة صالحة. ده بالضبط سبب خطورته الشديدة — وسبب عدم قدرة أي تدقيق في عقد على إيقافه.

اللي خسره المستخدمون: ~120 مليون دولار، توقيع ورا توقيع

الأرقام مذهلة لهجوم ما لمسش سطرًا واحدًا من كود الخزينة.

شركة تدقيق العقود الذكية PeckShield قدّرت إجمالي الخسائر بحوالي 120 مليون دولار. تقرير ما بعد الحادثة الخاص بـ BadgerDAO، المُعاد إنتاجه في دراسات الحالة، وضع الخسارة عند ما يقارب 2076.54 BTC (~116.3 مليون دولار أمريكي وقت الاختراق) بعد تحويل جميع الأصول المسروقة لمقياس مشترك.

الألم مكانش موزعًا بالتساوي. ضحية واحدة — مُبلّغ عنها إنها حساب مؤسسي — خسرت النصيب الأكبر في معاملة واحدة: دراسات الحالة بتذكر إن ما يقارب 900 BTC اتسُحبت من خزينة Yearn wBTC، وطرف واحد بس خسر أكتر من 50 مليون دولار من Bitcoin المُلفوف. الباقي كان مئات المستخدمين العاديين.

والحجم كان نتيجة مباشرة للصبر. المهاجم ماضربش بدافع الذعر. زي ما بيوصف تحليل Forta، جمع الهاكر بهدوء موافقات من ما يقارب 200 حساب، ثم في الساعة 12:48 صباحًا من الثاني من ديسمبر 2021، سحب الهاكر محافظ الضحايا في أقل من 10 ساعات. الموافقات الخبيثة كانت بتتجمع بهدوء لأيام — فخ جاهز، انطلق كله دفعة واحدة. إعادة تركيب تانية عدّت 500 محفظة أعطت موافقات غير محدودة على مدار الحملة.

التفصيلة الأكتر قسوة: مكانش في حاجة يقدر المستخدم الحذر يتحققها. الـ URL كان صح. شهادة TLS كانت صالحة. الواجهة كانت أصيلة. الحاجة الوحيدة الغلط كانت مقطع JavaScript الموقع الشرعي نفسه كان بيقدّمه.

إزاي حصل: مفتاح Cloudflare API وموافقة مُدرجة

الباب الأمامي اللي استخدمه المهاجم مكانش عقدًا ذكيًا. كان حساب سحابة.

BadgerDAO، زي جزء ضخم من الويب الحديث، كان واقف ورا Cloudflare — طبقة توصيل المحتوى والحوسبة الحافّية اللي بتقدّم وبتسرّع المواقع. السيطرة على الحساب ده معناها السيطرة على الكود اللي موقع BadgerDAO كان بيقدّمه للزوار. والمهاجم حصل على السيطرة دي من خلال مفتاح مسروق.

في رواية BadgerDAO الرسمية، نقلًا عن CoinDesk، الهاكر استخدم مفتاح API مخترقًا اتعمل بدون علم أو تفويض من مهندسي Badger عشان يُدرج بشكل دوري الكود الخبيث اللي أثّر على جزء من عملائه. العبارة دي — جزء من عملائه — هي جزء من سبب ظلت مخفية طول الفترة دي. السكريبت ماشتغلش مع الكل، في كل مرة. كان بيتناوب، بيضرب بعض المستخدمين بس، مما جعل السلوك الخبيث صعب الإعادة أو الملاحظة بشكل مُحبط.

إزاي مفتاح API غير مُصرّح به وُجد من الأساس؟ السبب الجذري كان ثغرة في حساب Cloudflare. دراسات الحالة بتذكر إن مستخدمين غير مُصرّح لهم كانوا قادرين على إنشاء حسابات وكانوا قادرين أيضًا على إنشاء ومشاهدة مفاتيح API العالمية (اللي مش ممكن حذفها أو تعطيلها) قبل اكتمال التحقق من البريد الإلكتروني. المهاجم يقدر يغرس مفتاحًا في حساب، ثم ينتظر بس لحين انتهاء المالك الحقيقي من التحقق وتفعيله — وفي اللحظة دي، المهاجم بيمتلك بهدوء وصولًا صالحًا لـ API.

بالمفتاح ده، استخدم المهاجم Cloudflare Workers — منصة الحوسبة الحافّية لـ Cloudflare — لإعادة كتابة الصفحة في طريقها للمستخدم. تقرير ما بعد الحادثة لـ BadgerDAO، المُعدّ مع شركة الأمن السيبراني Mandiant، خلص لأن حادثة التصيد في الثاني من ديسمبر كانت نتيجة مقطع خبيث مُدرج من خلال Cloudflare Workers. الكود المُدرج عمل حاجة واحدة بس مهمة: أضاف طلب موافقة توكن إضافي في التدفق العادي للـ dApp.

حتى في أي استدعاء موافقة استخدمه كانت فيه براعة مقصودة. CryptoBriefing أفادت بأن الهاكر أدرج على ما يُزعم سكريبتًا خبيثًا على موقع Badger قدّم للمستخدمين معاملة لـ "زيادة السماح". الاختيار ده مكانش عشوائيًا. مقارنة باستدعاء approve العادي، نافذة increaseAllowance بتظهر عادةً بمؤشرات بصرية أضعف وأقل إثارة للقلق في نوافذ المحفظة — أقل رايات حمراء، وأقل تحذيرات من نوع "أنت على وشك منح قدرة الإنفاق". المهاجم حسّن تجربة المستخدم للسرقة.

فالسلسلة الكاملة بانت كده: ثغرة التحقق من حساب Cloudflare سمحت بوجود مفتاح API غير مُصرّح به ← المهاجم استخدم المفتاح ده لنشر Worker ← الـ Worker دسّ سكريبت في app.badger.com ← السكريبت طلب من المحافظ سماحًا بتوكن لصالح المهاجم ← المستخدمون وافقوا ← المهاجم سرقهم. ولا خطوة واحدة من دول مسّت العقود المُدققة.

الاستجابة: إيقاف السلسلة لوقف جرح Web2

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

الفريق اعترف بالحادثة علنًا، وبحسب CryptoBriefing، أكدوا إن جميع العقود الذكية اتوقّفت لمنع المزيد من عمليات السحب. لأن خزائن Badger كانت بها قدرة الإيقاف المؤقت، تجميد التحويلات قطع قدرة المهاجم على الاستمرار في تحريك الأموال المُوافق عليها حديثًا. تحليل تقني واحد يصف التوقف بأنه الفريق يمارس قوته لتجميد جميع الاستدعاءات لوظيفة transferFrom — آلية ERC-20 عينها اللي كانت الموافقات الخبيثة تستغلها. الإيقاف ده هو أيضًا سبب إمكانية استرداد جزء ذو قيمة نظريًا من الخسائر: بعض الأصول كانت المهاجم نقلها لكن لم يسحبها بالكامل من خزائن Badger قبل نزول التجميد.

على صعيد البنية التحتية، كان التنظيف هو قائمة Web2 الكئيبة لاختراق بيانات الاعتماد: تدوير مفاتيح Cloudflare API، وتغيير كلمة سر الحساب، وتقوية المصادقة متعددة العوامل، ومراجعة كل مفتاح مفروض مكانش موجود. BadgerDAO بعدين تعاون مع Mandiant للتحقيق ونشر تقرير فني بعد الحادثة يعيد تركيب الجدول الزمني — ثغرات حساب Cloudflare، والمفاتيح غير المُصرّح بها اللي اتعملت في الأشهر السابقة، وحقن السكريبت في نوفمبر، وسحب ديسمبر.

لكن مهما كان رد الفعل على الحادثة، مش قادر يلغي الموافقات اللي المستخدمون كانوا وقّعوا عليها. التوقيعات كانت صالحة. المعالجة تقدر توقف السرقة المستقبلية وتلاحق الاسترداد؛ مش تقدر تعكس موافقة اتمنحت على السلسلة.

إيه اللي بيعلّمنا: الموقع الإلكتروني جزء من نطاق أمانك

الدرس الأكتر أهمية في BadgerDAO هو تصحيح حدود. معظم الفرق — ومعظم المستخدمين — بيرسموا حدود الأمان حوالين العقود الذكية. BadgerDAO بيُثبت إن الحدود أكبر بكتير.

1. الواجهة الأمامية بتاعتك في النطاق. دايمًا. الكود اللي متصفح المستخدم بيشغّله جزء من بروتوكولك، سواء موجود على السلسلة أو لا. لو مهاجم تحكّم في الـ JavaScript اللي موقعك بيقدّمه، هو بيتحكّم في محافظ مستخدميك — سواء كانت العقود مُدققة أو لا. الموقع مش "بس UI". ده المكان اللي فيه الموافقة بتتسجّل.

2. البنية التحتية السحابية والدومين بتاعتك جزء من العقد. حساب Cloudflare، وتسجيل دخول لمزوّد DNS، وحساب في سجل الدومين، ومفتاح CI/CD — كل واحد منهم طريق لإعادة كتابة اللي مستخدميك شايفينه. BadgerDAO ماتاختُرقتش في الخزينة؛ اتاختُرقت في الحساب اللي كان بيتحكّم في الموقع. عامل بيانات الاعتماد دي بنفس جنون الحذر اللي بتحتفظ بيه لمفتاح خاص لنشر العقود.

3. مفاتيح API وتدفقات إنشاء الحساب سطح هجوم حقيقي. الكارثة كلها اتعلّقت بمفتاح API غير مُصرّح به مكانش المفروض يتوجد، أصبح ممكن بسبب فجوة في التحقق. اعمل جرد لكل مفتاح. قيّده بدقة. دوّره. نبّه على أي مفاتيح جديدة. المفتاح اللي نسيت فيه هو مفتاح المهاجم ممكن يستخدمه.

4. "مُدقَّق" ضروري، لكنه مش كافي. التدقيق النظيف له قيمة حقيقية وتكمّل تعمله. لكنه بيغطي العقود، مش حساب السحابة، ولا الـ DNS، ولا الـ CDN، ولا خط أنابيب بناء الواجهة الأمامية. الأمان هو المسار الكامل من متصفح المستخدم لسلسلتك — والحلقة الأضعف، مش الأقوى، هي اللي بتحدد المستوى.

5. المستخدمون مش قادرين يتحققوا من طريق مسح واجهة أمامية متلاعب بها. "دايمًا تحقق من الـ URL" نصيحة كويسة كانت مش هتعمل حاجة هنا. الـ URL كان صح. الدرس للمستخدمين أصعب: اشكّ بعمق في طلبات الموافقة وincreaseAllowance، وفضّل المحافظ والأدوات اللي بتفكّك وتحذّر من موافقات التوكن، والغِ السماحات القديمة بانتظام. اللي بتوافق عليه أهم من الصفحة اللي أنت عليها.

زاوية Namefi

لو اختزلنا BadgerDAO لجوهره، هو مشكلة ملكية وتحكّم. المهاجم مكانش يملك موقع BadgerDAO — لكن لأسابيع، كان يقدر يغيّر اللي بيقدّمه. الناس اللي فعلًا كانوا بيملكوا المشروع معندهمش طريقة موثوقة وواضحة للتلاعب عشان يعرفوا إن سلسلة التحكّم على حضورهم على الويب — الحساب، والمفاتيح، وإعداد الحافة، والـ DNS — اتاختُرقت بهدوء.

دي الفجوة اللي Namefi بيهتم بيها. Namefi بيعامل الدومينات وملكية الويب كأصول من الدرجة الأولى، أصيلة في الإنترنت: تحكّم قابل للتحقق، وقابل للمراجعة، وأصعب في الاختطاف بصمت، مع الحفاظ على التوافق مع DNS. سطح هجوم الواجهة الأمامية — من يتحكّم في الاسم، وأين يُحلّ، وما هي البنية التحتية الواقفة وراه — مش حاجة ثانوية للعقود الذكية. زي ما BadgerDAO أثبت بأغلى طريقة ممكنة، ده جزء من نموذج الأمان.

تقدر تدقق عقودك لحد ما تبقى مثالية. لكن لو مفتاح غير مُصرّح به يقدر يعيد كتابة موقعك وسكريبت مُدرج يقدر يحصد موافقات مستخدميك، التدقيق مكانش القصة كلها قط. الدومين، والـ DNS، والبنية التحتية للويب اللي بتوصّل تطبيقك للناس الحقيقيين هي جزء من سطح أمانك. عاملها كده — لأن المهاجمين بيعملوا كده بالفعل.

المصادر وقراءات إضافية

• CoinDesk — BadgerDAO Reveals Details of How It Was Hacked for $120M
• Vice (Motherboard) — Hackers Steal $119M From 'Web3' Crypto Project With Old School Attack
• Halborn — Explained: The BadgerDAO Hack (December 2021)
• Forta — How to Derail a 120-Million-Dollar Hack
• CryptoBriefing — $120M Lost in BadgerDAO DeFi Hack
• Quadriga Initiative — Dec 2021 — BadgerDAO Malicious Code Injected — $116.3m
• Chainalysis — Behind The Scenes of The BadgerDAO Hack
• BadgerDAO / Mandiant — BadgerDAO Exploit Technical Post Mortem