تحليل لهجوم تغيير ملكية حسابات Solana وطرق الوقاية

ملخص المقال

• شرح خلفية هجوم تغيير ملكية حسابات Solana.
• تحليل آلية عمل الهجوم واستغلال الثغرات.
• عرض تفصيلي لمسار الأموال المسروقة عبر البلوك تشين.
• تقديم استراتيجيات عملية للوقاية من هجمات التصيد والاحتيال.
• التأكيد على أهمية الحذر والتحقق قبل التوقيع على أي معاملات.

مقدمة

في الآونة الأخيرة، تلقينا طلب مساعدة من أحد المستخدمين الذي تعرض لهجوم تصيد في ذلك اليوم. اكتشف المستخدم وجود سجلات تفويض غير طبيعية في محفظته، وحاول إلغاء التفويض ولكنه لم يتمكن من ذلك، وقدم عنوان المحفظة المتضررة 9w2e3kpt5XUQXLdGb51nRWZoh4JFs6FL7TdEYsvKq6Wb. من خلال التحليل على السلسلة، وجدنا أن صلاحية المالك لحساب المستخدم قد تم نقلها إلى العنوان GKJBELftW5Rjg24wP88NRaKGsEBtrPLgMiv3DhbJwbzQ. بالإضافة إلى ذلك، سُرقت أصول المستخدم التي تزيد قيمتها عن 3 ملايين دولار أمريكي، بينما كانت أصول أخرى بقيمة حوالي 2 مليون دولار أمريكي مخزنة في بروتوكول DeFi ولكن لم يكن من الممكن نقلها (في الوقت الحالي، تم إنقاذ جزء الأصول الذي تبلغ قيمته حوالي 2 مليون دولار أمريكي بنجاح بمساعدة DeFi ذات الصلة). حاول الضحية بدء تحويل من هذا الحساب إلى عنوانه الخاص للتحقق من الأذونات، لكن جميع المعاملات فشلت. يتشابه هذا الوضع بدرجة كبيرة مع هجوم "التوقيع المتعدد الضار" الذي يظهر بشكل متكرر في نظام TRON البيئي. بمعنى آخر، هذا الهجوم ليس "سرقة تفويض" بالمعنى التقليدي، ولكن الصلاحية الأساسية (صلاحية المالك) تم استبدالها بواسطة المهاجم، مما أدى إلى عدم تمكن الضحية من التحويل أو إلغاء التفويض أو تشغيل أصول DeFi، حتى لو أراد ذلك. الأموال "مرئية"، ولكن لا يمكن السيطرة عليها.

آلية تعديل مالك Solana

استغل المهاجمون سيناريوهين غير بديهيين لخداع المستخدمين بنجاح للنقر:

1. عادةً ما تقوم المحفظة بتشغيل نتائج تنفيذ المعاملة عند توقيع المعاملة، وإذا كان هناك أي تغيير في الأموال، فسيظهر في واجهة التفاعل، بينما المعاملة المصممة بعناية من قبل المهاجم ليس لديها تغيير في الأموال.
2. حساب Ethereum EOA التقليدي يتحكم فيه المفتاح الخاص، وليس من الواضح بشكل موضوعي أن Solana لديها خاصية يمكنها تعديل ملكية الحساب.

دعنا نحلل نوع عملية تعديل مالك Solana. عادةً ما يكون مالك الحساب هو حساب النظام (11111111111111111111111111111111) عندما نقوم بإنشاء حساب باستخدام المحفظة، وفي المعاملات، يجب أن يتحقق النظام مما إذا كان توقيع المعاملة موقعًا بواسطة المفتاح العام المقابل. يمكنك استخدام أمر Solana Account لعرض المعلومات الأساسية للحساب: هناك أيضًا حساب يسمى حساب PDA، وهو حساب مشتق من عقد ذكي ويستخدم بشكل أساسي لتخزين بيانات العقد الذكي. مالكه هو العقد الذكي الذي اشتق منه. على سبيل المثال، الحساب المستخدم لتخزين معلومات إصدار الرمز المميز وحيازته هو نوع من حساب PDA. عندما تستخدم Solana Account لعرض المعلومات الأساسية للحساب، يمكنك أن ترى أن مالكه هو عقد Token الذكي TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA: يمكن تعديل مالك هذين النوعين من الحسابات، ولكن هناك قواعد وقيود مختلفة: لا يمكن تعديل الحسابات العادية مباشرة من الخارج من خلال الأوامر أو البرامج النصية، ولكن يمكن تعديلها من خلال استدعاءات العقد الذكي. الأمر الرئيسي هو: assign الأمر يغير مالك الحساب من القيمة الحالية إلى new_owner. بعد نشر البرنامج، استخدم Solana CLI أو عميل (مثل Solana Web3.js) لاستدعاء هذا الأمر. استخدمت حادثة التصيد هذه الخاصية لإغراء الضحية بالتوقيع بشكل استباقي على معاملة تحتوي على أمر assign، وبالتالي إكمال نقل مالك عنوان محفظة الضحية بصمت. ببساطة، يمكن لحساب PDA تعديل المالك، ولكنه يتطلب أن تكون بيانات الحساب فارغة. وبالمثل، يتم تنفيذه من خلال أمر assign. لقد اختبرنا ببساطة ردود الفعل لتعديل المالك في عدة سيناريوهات:

1. يمكن لحساب PDA الذي تم إنشاؤه حديثًا تعيين أي مالك بشكل تعسفي. إذا لم يكن المالك هو البرنامج الذي أنشأه، فلن يكون للبرنامج حقوق الكتابة.
2. عندما يحاول حساب PDA الذي تم إنشاؤه تعديل المالك، فإنه يبلغ عن خطأ: instruction illegally modified the program id of an account.
3. محاولة كتابة البيانات قبل تعيين PDA النهائي: instruction modified data of an account it does not own.

بعد تعديل مالك الحساب، يفقد المستخدم السيطرة على الحساب، ويمكن للمهاجم تحويل أصول الحساب من خلال استدعاء CPI. هناك أيضًا تغيير شائع في الملكية، وهو ملكية حساب الرمز المميز. هذا في الأساس ملكية يتم التحكم فيها بواسطة المنطق داخل العقد الذكي، وليس بواسطة المنطق الأساسي لـ Solana، ولكنه غالبًا ما يستخدم أيضًا في هجمات التصيد. يجب أن يكون المستخدمون على دراية بهذا النوع من طرق هجوم التصيد.

تحليل MistTrack

وفقًا لأداة التتبع ومكافحة غسيل الأموال MistTrack، تم تحليل عنوان الضحية 9w2e3kpt5XUQXLdGb51nRWZoh4JFs6FL7TdEYsvKq6Wb. مسار تحويل الأموال لهذا الهجوم معقد، ويستخدم المهاجمون بشكل أساسي عنوانين أساسيين للأصول: BaBcXDg... BaBcXDg... التدفق 1: BaBcXDgbPgn85XtEQK7TZV8kZuFpT4iWVAs4QJoyNSmd يتضمن المسار الرئيسي الأول أصولًا مكافئة تبلغ حوالي 2.38 مليون دولار أمريكي، والسمة الأساسية هي "انتشار متعدد المستويات + إيداع الأموال اللامركزي CEX + تحويل متعدد العناوين". يقوم المهاجم بتحويل الرموز المتعددة المستلمة (بما في ذلك PAYAI و CASH و CARDS و JitoSOL و POLYFACTS و PUMP و PYUSD و CAP) إلى SOL من خلال هذا العنوان. من بينها، يتم تحويل PUMP إلى 7E4eNkK... ثم يتم تحويله إلى SOL. تتدفق SOL المحولة بشكل أساسي على النحو التالي:

1. يتم تحويل 717.5 SOL إلى YDrMfsB...، ويتم تحويل بعض SOL إلى منصة Binance، ويتم تشتيت الأموال المتبقية والبقاء في حوالي 4 عناوين تحويل.
2. يتم تجميع 7,556.89 SOL + 2,218 SOL (من تحويل PUMP) بشكل موحد في 7E4eNkK...، ثم يتم تحويل بعض SOL إلى منصة Letsexchange، ويتم تحويل 5,050.93 SOL إلى FyB2jDJbTdmW...، ويتم تشتيت الأموال المتبقية والبقاء في حوالي 13 عنوانًا.
3. يتم تشتيت 2,161.88 SOL + 5,050.93 SOL المذكورة أعلاه بشكل أكبر في FyB2jD...، ويتم تحويلها إلى منصات متعددة (HTX، Binance، Kucoin، ChangeNOW، Changelly)، ويتدفق جزء منها إلى عنوان غير معروف (25nULbv)، ويتم تشتيت الأموال المتبقية والبقاء في حوالي 25 عنوانًا.
4. يتم تحويل 2,053 SOL إلى 6qdtH5D...، ويتم تحويل بعض SOL إلى منصة Letsexchange، ويتم تشتيت الأموال المتبقية والبقاء في حوالي 15 عنوان تحويل.
5. يتم تحويل 20 SOL إلى 5rJdvkp...، ثم يتم تحويله والبقاء في العنوان 2etvjZH....
6. يتم تحويل 2,142 SOL إلى 2xFzAda...، ويتم تحويل 352 SOL إلى منصة Binance، ويتم تحويل 200 SOL إلى منصة Letsexchange، ويتم تشتيت الأموال المتبقية والبقاء في حوالي 11 عنوان تحويل.

التدفق 2: 7pSj1RxHf77G3XeisvnNAtbyx5AFjYPcChswWhZe9bM8 يتضمن المسار الرئيسي الثاني أصولًا مكافئة تبلغ حوالي 790,000 دولار أمريكي، والسمة الأساسية هي "التبادل عبر السلاسل والدوران متعدد السلاسل". يقوم المهاجم أيضًا بتحويل الرموز المتعددة المستلمة إلى SOL، حيث يمثل JitoSOL و PUMP و POLYFACTS نسبة كبيرة. تتدفق SOL المحولة بشكل أساسي على النحو التالي: يتم تحويل 5,742 SOL إلى FiywJZ2Z...، ويتلقى هذا العنوان أيضًا 2772.8 SOL من عناوين أحداث التصيد الأخرى التي تم وضع علامة "Phishing" عليها بواسطة MistTrack. من بينها، يقوم المهاجم بتحويل 8,579.92 SOL إلى ETH عبر Relay.link وعبوره إلى عنوان Arbitrum 0xDCFa6f...، ثم تحويل الأموال إلى SOL عبر 1inch وعبورها إلى عناوين Solana متعددة، ثم استخدام 1inch للعبور المتكرر، لن نخوض في التفاصيل هنا. يقوم FiywJZ2Z... بتحويل 215.89 SOL المتبقية إلى Ah5Rs916...، ثم تحويلها إلى 29,875 USDC. يتم تحويل USDC إلى DAI عبر Relay.link بقيم 5000 و 5000 و 5000 و 5000 و 19,875.38 وعبورها إلى عناوين Base و Ethereum 0xd2c1c2A...، حيث تم إرجاع دفعتين من 5000 USDC، وتم إرجاعها حاليًا. لم يتم تحويل USDAIDC حاليًا، ولم يتم تحويل USDAIDC حاليًا، ولم يتم تحويل USDAIDC حاليًا.

إنقاذ أصول DeFi

بالإضافة إلى ذلك، تم استخراج الأصول المتبقية للضحية في DeFi بنجاح بمساعدة أطراف متعددة، وتم تحويلها عبر العنوان fgR5PJF...، بما في ذلك حوالي 2.17 مليون PYUSD و 4548 USDC: يوضح تدفق الأموال هذا بوضوح نمط سلوك المهاجم: التشتت السريع، والتحويل متعدد العناوين، والخلط متعدد المنصات، والدوران عبر السلاسل، وإيداع الأموال في CEX وإعادة استخدام أصول DeFi في نفس الوقت، وبناء شبكة غسيل أموال متعددة المستويات وعبر النظم البيئية، مما يزيد بشكل كبير من صعوبة التتبع، وقد قامت MistTrack حاليًا بوضع علامة على جميع العناوين ذات الصلة.

كيفية منع الهجمات المماثلة؟

بالنسبة للمستخدمين العاديين، فإن هذا النوع من الهجمات هو في الأساس "هجوم تصيد". سيستخدم المهاجمون طرقًا مختلفة لتعبئة الروابط، مثل الإنزالات الجوية والمكافآت والمهام والمؤهلات للاختبار المسبق وحتى التظاهر بأنهم إعلانات رسمية، مما يجعل الناس يعتقدون أنها مجرد عملية بسيطة، لكن التوقيع المنبثق يخفي في الواقع أذونات عالية الخطورة مثل تعديل المالك. بمجرد التوقيع، يتم الاستيلاء على المحفظة بشكل أساسي. لذلك، فإن أهم طريقة للوقاية هي التفكير مليًا قبل النقر على الروابط والنقر على "توقيع": هل المصدر موثوق؟ هل هذه الصفحة رسمية؟ ماذا يفعل هذا التوقيع بالضبط؟ إذا كان المحتوى المنبثق من المحفظة غير مفهوم تمامًا، أو إذا ظهرت فجأة بعض الأذونات الغريبة أو العناوين غير المألوفة أو الأماكن التي تحتاج إلى تفويضها بشكل غير مفهوم، فيجب التوقف وعدم الضغط على "تأكيد" بشكل قسري. في الأوقات العادية، حاول أيضًا عدم استخدام محفظة ذات أصول كبيرة للتفاعل في كل مكان. يمكنك إعداد رقم صغير خصيصًا "برصيد منخفض، يُستخدم فقط للتفاعل" للقيام بالمهام ولعب المشاريع وتلقي الإنزالات الجوية، ووضع الأصول المهمة حقًا في محفظة مستقلة أو حتى محفظة باردة، حتى إذا قمت بالتوقيع عن طريق الخطأ، يمكنك تقليل الخسائر إلى الحد الأدنى. بالإضافة إلى ذلك، حاول تقليل منح "تفويض غير محدود"، وتقييد النطاق وتقييد المبلغ إذا استطعت، مما يقلل المساحة التي يمكن للمهاجمين إساءة استخدامها على المدى الطويل. باختصار، انظر أكثر، وتحقق مرة أخرى، ولا تنقر بشكل عشوائي، ولا توقع بشكل عشوائي، واترك لنفسك طبقة حماية. قم بتخزين الأصول الكبيرة بشكل منفصل، ويتحمل الرقم الصغير مسؤولية التفاعل، ويتحمل الرقم الكبير مسؤولية الحفظ فقط. توقف فورًا إذا واجهت أي شذوذ، ولا تحتفظ بعقلية محظوظة. طالما أنك تفعل ذلك، يمكن تقليل خطر التعرض لهجوم التصيد هذا بشكل كبير. أخيرًا، يوصى بشدة بقراءة "دليل الإنقاذ الذاتي لغابة الظلام Blockchain" (https://darkhandbook.io/).