الخلفية
Solidity Pro هي إضافة لـ VS Code موجهة لمطوري Solidity/Web3، وتُقدَّم للجمهور كأداة مساعدة للتطوير. توفر ميزات مثل الاستعلام عن الغاز وأسعار الرموز ومقاطع التعليمات البرمجية وإشعارات الترجمة وغيرها. كما أن مستودع GitHub الخاص بها سبق أن روّج لميزات أمان مثل AI Audit وSecurity Scanner.
في الفعاليات العامة، استخدمت Solidity Pro على التوالي ناشرين (هويات الناشر) هما helper-beeps وweb3devtoolsx، وكانت Extension ID (المعرّف الفريد للإضافة) لكلٍ منهما: helper-beeps.solidity-pro وweb3devtoolsx.solidity-pro. ورغم أن هوية النشر قد تغيّرت، إلا أن ناتج البناء اللاحق احتفظ بالناشر القديم وعنوان المستودع ومعلومات حقوق النشر، ما يشير إلى وجود علاقة وراثة هندسية مباشرة بينهما.
في 6 و7 أغسطس 2026، أُضيف هذان Extension ID تباعًا إلى قائمة التحكم في الإضافات الخبيثة المستخدمة من Open VSX. ومن حيث المبدأ، كان من المفترض أن يُظهر الفحص اللاحق عبر الإصدارات القدرات الخبيثة نفسها، لكن Solidity Pro 4.0.0 (publisher: web3devtoolsx) الذي حصلنا عليه أظهر نتيجة مختلفة تمامًا: فالـ bundle النهائي (شيفرة التنفيذ بعد الحزم) لم يبقَ فيه سوى وظائف عادية مثل Gas وأسعار الرموز والسجلات، بينما اختفت جميع الوحدات التي ظهرت في الإصدارات الخبيثة السابقة، مثل جمع الاعتمادات، وتنزيل الحمولة البعيدة، وتشغيل العمليات الفرعية، وتحديث VSIX البعيد.
إذن يصبح السؤال: لماذا تحوّل مكوّن سبق أن امتلك تاريخًا خبيثًا واضحًا إلى "نظيف" في الإصدارات اللاحقة؟
سيراجع هذا المقال Solidity Pro من 4.0.0 إلى الخلف، متتبعًا تغيّر الإصدارات وهويات النشر، ومحللًا نسختين تاريخيتين خبيثتين، وGitHub Clean commit، وانتقال publisher، والجدول الزمني للنشاط العلني، مع مناقشة كيف يمكن أن يؤدي الحكم على خطر إضافة IDE اعتمادًا على الإصدار الحالي فقط إلى بقع عمياء في الكشف.
يعتمد هذا التحليل على أدلة ساكنة، ولم يتم تشغيل العينة أو الاتصال بالبنية التحتية البعيدة.
استجابة MistEye
MistEye هي منصة استخبارات تهديدات Web3 ومراقبة أمنية ديناميكية طورتها SlowMist بشكل مستقل، وتدمج قدرات الرصد الأمني وتجميع الاستخبارات لتوفير تنبيهات مخاطر فورية وحماية للأصول.
قامت MistEye بإجراء تجميع ترابطي لهويتي النشر helper-beeps.solidity-pro وweb3devtoolsx.solidity-pro والعينات المرتبطة بهما. وبالاستناد إلى إزالة التشويش الساكن، والتحقق المتقاطع من القدرات الخبيثة، والجدول الزمني العلني على المنصات، جرى استخراج تجزئات العينات، وExtension ID، ومسارات الطلبات الخطرة، وسلوك التحديث البعيد، وذلك لاستخدامها في الإنذار المبكر بمخاطر سلسلة توريد إضافات IDE.
أولًا: الإصدار الحالي
لتحديد سبب عدم تطابق 4.0.0 مع الشيفرة الخبيثة، يجب فحص عنصرين معًا: عينة 4.0.0 التي حصلنا عليها في هذا المقال، وحالة مستودع GitHub المطابقة للـ bundle الخاص بها.
ماذا يوجد داخل حزمة VSIX. تضم bundle النهائية لإعادة البناء محليًا للإصدار 4.0.0 أساسًا ApiClient وGasTracker وPriceMonitor وLogger، ويتركز الوصول الشبكي على Etherscan وCoinGecko. بعد تفعيل الإضافة عند onStartupFinished أو عند وجود مساحة عمل تحتوي على Solidity، تُشغّل فقط Gas tracker وPrice monitor وlogger، وتُسجل ثلاثة أوامر عامة؛ أما أمر compile فلا يعرض إلا تلميحًا واحدًا عبر Hardhat/Foundry من دون استدعاء المترجم فعليًا. وفي الملفات التي جرى فحصها والمسارات الثابتة القابلة للوصول، لم يُعثر على أربع قدرات خبيثة كانت في الإصدارات التاريخية: جمع الاعتمادات، وتنزيل الحمولة البعيدة، وتشغيل العمليات الفرعية، وتحديث VSIX البعيد.
ماذا يوجد أيضًا في مستودع GitHub؟ الحزمة 4.0.0 نفسها لا تحمل الشيفرة المصدرية، لذا عدنا إلى الوراء نحو المشروع العلني في GitHub. في المستودع يوجد التزام عاد فيه إصدار package.json إلى v1.0.0، بتجزئة commit 95dce4f، ورسالة التزام "Clean release"؛ ويطابق out/extension.js فيه حزمة 4.0.0 من حيث الحجم 10,633 بايت وSHA-256.
يحتوي out/extension.js الخاص بهذا الالتزام أيضًا فقط على ApiClient وGasTracker وPriceMonitor وLogger، ولا تقوم دالتا التفعيل والإيقاف إلا بالتهيئة والتنظيف. لكن src/ داخل الالتزام نفسه يروي قصة أخرى: فـ src/telemetry/Web3Analytics.ts ما زال موجودًا، ويبدأ رأس الملف بعبارة "Sends install ping immediately, then scans for secrets"، وداخله BIP39 wordlist، والتعرف على اعتمادات المحافظ، وإعدادات الإرسال إلى WORKERS، وحدود واسعة لجمع الملفات؛ كما بقي src/services/AutoUpdater.ts، معرّفًا منطق فحص الإصدار كل 30 دقيقة وتثبيت VSIX عن بُعد.
مستودع GitHub (Clean commit 95dce4f)
├── src/telemetry/Web3Analytics.ts # لا يزال مصدر مشروع الجمع الخبيث موجودًا
├── src/services/AutoUpdater.ts # لا يزال مصدر تحديث VSIX البعيد موجودًا
├── .vscodeignore # يستبعد src/** وscripts/** و*.ts
└── out/extension.js # bundle نظيف ظاهر وقت الحزم
لماذا لم تدخل الشيفرة الخبيثة إلى حزمة VSIX؟ توجد هنا حديان فاصلان.
الحد الأول هو نقطة التنفيذ: أزال src/extension.ts في التزام Clean استيراد Web3Analytics وAutoUpdater ومنطق تشغيلهما، وعند بناء esbuild لشجرة الاعتماد من هذه النقطة، لم يعد يدرج هاتين الوحدتين داخل out/extension.js.
الحدّ الثاني هو الرؤية داخل الحزمة: استبعدت .vscodeignore كلًا من src/** وscripts/** و*.ts، مع الإبقاء على out/**، ولذلك فإن ملفات TypeScript المصدرية المتبقية لن تدخل بصيغتها الأصلية في VSIX المُنشأ وفقًا لذلك الإعداد. رسالة التزام v1.0.0 كانت "Clean release"، لكن ملف المصدر الخاص بالوحدة الخبيثة لم يُحذف أو يُعدّل في ذلك الالتزام — فالمخرج النهائي أصبح نظيفًا، بينما بقيت الوحدة الخبيثة داخل المشروع ويمكن إعادة إدراجها لاحقًا عبر تغييرات في الشيفرة المصدرية أو إعدادات البناء.
ثانيًا: الإصدارات الخبيثة التاريخية
وبما أن الإصدار الحالي وbundle التزام Clean كلاهما لا يظهران الوحدة الخبيثة الأصلية، فيجب أن يستمر التحقيق بتتبع الإصدارات التاريخية لـ Solidity Pro تحت هوية النشرين معًا.
Solidity Pro لا يستخدم دائمًا التنفيذ الخبيث نفسه. فالإصداران 2.4.1 في هوية النشر helper-beeps و3.4.0 في هوية النشر web3devtoolsx يقدمان طريقتين مختلفتين بوضوح: الأولى تعتمد على التأخير المحلي والتنزيل البعيد وتنفيذ الشيفرة عن بعد، بينما الثانية تركز على جمع الاعتمادات المضمّن وقناة التحديث البعيدة.
2.4.1: تسليم مؤجل
في عينة Solidity Pro 2.4.1 التي حصلنا عليها في هذا المقال (publisher: helper-beeps)، تُفعّل الإضافة عند فتح ملف Solidity أو مساحة عمل Hardhat/Foundry، وتكون telemetry مفعلة افتراضيًا. بعد التفعيل لا تنتقل الشيفرة مباشرة إلى مرحلة التنزيل، بل تضبط نافذة انتظار عشوائية تتراوح بين 24 و48 ساعة:
MIN_DELAY_MS: 86400000,
MAX_DELAY_MS: 172800000
بعد انتهاء الانتظار، يفحص الكود وجود متغيرات البيئة الخاصة بـ CI وGITHUB_ACTIONS وJENKINS_HOME وGITPOD_WORKSPACE_ID وغيرها؛ فإن وُجدت يخرج مباشرة. ثم تُفحص تباعًا ستة مسارات نسبية مشفرة داخل المجلد الرئيسي عبر fs.existsSync، ولا يُستخدم هذا في تلك المرحلة إلا للتأكد من الوجود.
بعد التصفية، يحاول الكود بالتتابع نقطتي نهاية مشفرتين، ويطلب من كل نقطة المسار الثابت /firmware. وبعد الحصول على الاستجابة، يتحقق من الطول، ثم يستخدم crypto.createDecipheriv لفك التشفير بخوارزمية AES-GCM، ويكتب النص المفكوك بصلاحيات محدودة في ملف .py داخل المجلد المؤقت، ثم يشغله عبر child_process.spawn بوضع detached. وبعد نحو 60 ثانية يُستخدم unlinkSync لتنظيف الملف المؤقت. لم يتم الحصول على استجابة فعلية من /firmware، لذا تبقى وظيفة المرحلة الثانية غير معروفة.
3.4.0: جمع الاعتمادات
Solidity Pro 3.4.0 (publisher: web3devtoolsx) يعلن في package.json ضمن activationEvents عن workspaceContains:*.sol و onStartupFinished معًا. يمكن للإضافة أن تدخل activate() تلقائيًا بعد اكتمال تشغيل VS Code، من دون حاجة إلى أن ينفذ المستخدم أمرًا عامًا من أوامرها.
الإعداد الافتراضي solidity-pro.telemetry.enabled=true ينشئ Web3Analytics ويشغّله. يزعم README أنه لا يجمع إلا بيانات استخدام مجهولة ولا يخزن مفاتيح خاصة أو شيفرة مصدرية، لكن الوحدة تنفذ فعليًا مسحًا يمتد إلى الأصول الأساسية داخل نطاق ثقة المطور:
المحافظ ومواد التوقيع: مفاتيح EVM الخاصة، وعبارات BIP39 التذكارية، وkeystore، وSolana id.json، وبيانات إضافات محافظ المتصفح (MetaMask وPhantom وCoinbase Wallet وRabby).
الشيفرة المصدرية وبيانات الاعتماد الخاصة بالنشر: رموز GitHub من نوع ghp_/gho_/github_pat_، ورموز GitLab من نوع glpat-، و.npmrc، ورمز PyPI، و.netrc، وبيانات اعتماد Git.
السحابة والبنية التحتية: مفاتيح AWS access/secret/session، وKubernetes config، وDocker authentication، وAzure، وGCP configuration.
آثار المشاريع والتفاعل: .env ومتغيراته، وAPI key، ورموز خدمات الذكاء الاصطناعي (sk-، sk-proj-، sk-ant-)، وسجل shell ومعلومات المضيف.
يغطي التطابق النمطي لمفاتيح EVM الخاصة أسماء المتغيرات الشائعة مثل privateKey وPRIVATE_KEY وWALLET_KEY وDEPLOYER_KEY، بالإضافة إلى القيم السداسية العشرية بطول 64 خانة:
var _0x4e0bcc = [
/["']privateKey["']\s*:\s*["'](?:0x)?([0-9a-fA-F]{64})["']/g,
/(?:PRIVATE_KEY|PRIVATEKEY|ETH_KEY|ETHKEY|WALLET_KEY|WALLETKEY|DEPLOYER_KEY|OWNER_KEY)\s*=\s*["']?(?:0x)?([0-9a-fA-F]{64})["']?/gi,
/(?:privateKey|private_key|ethKey|eth_key|walletKey|wallet_key)\s*[:=]\s*["'](?:0x)?([0-9a-fA-F]{64})["']/gi,
/(?:priv(?:ate)?[ _-]?key|secret)[:=]\s*["']?(0x[0-9a-fA-F]{64})["']?/gi
];
منطق جمع مجلد SSH يقوم بسرد ملفات المفاتيح الخاصة المرشحة ضمن ~/.ssh/، ثم قراءة المحتوى وتمريره إلى أداة extractSecrets. وتُرسل نتائج الجمع إلى الخارج عبر مساري طلبين HTTP: JSON نصي يُرسل عبر HTTPS إلى المضيف المشوش CFG.WORKERS باستخدام POST /x، وتقرير كامل يُرسل بصيغة multipart/form-data إلى المجموعة نفسها باستخدام POST /y.
ويعمل إلى جانب سلسلة الجمع هذه AutoUpdater. فهو يُنشأ ويُشغّل داخل activate() من دون أي شرط، ولا يعتمد على إعداد telemetry. وبعد التشغيل مباشرة يطلب /version مرة واحدة، ثم يستقصي كل 30 دقيقة خادمين عاملين hard-coded؛ وكلما احتوت الاستجابة على version وurl، يقارن الكود رقم الإصدار، وينزّل VSIX، ويستدعي أمر تثبيت VS Code، ثم يحذف الملف المؤقت.
ولا تحتوي سلسلة التحديث كلها على أي تحقق من السلامة — فلا يطبق المحدث نفسه أي hash أو توقيع أو تثبيت لـ publisher أو للشهادة. وهذا يعني أن الخادم يمكنه في أي استقصاء أن يعيد نسخة أعلى وعنوان تنزيل، ويقرر بنفسه متى يُفعّل التحديث، وأي VSIX يرسله. والأهم من ذلك أن التحديث يسبق فقط بإشعار لا يضم سوى زر "OK"، وبعد انتهاء تدفق الإشعار تتابع الشيفرة التثبيت، من دون أي خيار حقيقي للإلغاء، ومن دون قراءة اختيار المستخدم.
تكمن خطورة هذا النوع من أهداف الجمع في أن IDE Extension Host يقع أصلًا داخل نطاق ثقة المطور. فعادةً ما تحتفظ أجهزة تطوير Web3 في الوقت نفسه بمواد المحافظ، واعتمادات المستودعات المصدرية، ورموز النشر الخاصة بالحزم، وإعدادات CI/CD والسحابة، وبالتالي قد يتجاوز هجوم واحد على سلسلة توريد إضافة واحدة عدة حدود أمنية في آن واحد.
مقابلة أدوار العينات أو الإصدارات الأربعة:
ثالثًا: انتقال publisher
الإصداران 2.4.1 و3.4.0 من Solidity Pro لا ينتميان إلى Extension ID نفسه. الأول صدر عن helper-beeps، بينما استخدم الثاني publisher جديدًا هو web3devtoolsx. فلماذا يمكن وضعهما معًا على خط تحقيق واحد؟
إن البيانات الوصفية الداخلية في التزام v3.4.0 الأولي fe794a2 تجيب عن هذا السؤال مباشرة. يعلن package.json: publisher: web3devtoolsx، والإصدار 3.4.0، وrepository يشير إلى github.com/web3devtoolsx/solidity-pro. أما out/package.json في الالتزام نفسه فيحتفظ بـ publisher: helper-beeps، والإصدار 3.3.0، وrepository يشير إلى github.com/helper-beeps/solidity-pro. وما يزال ملف LICENSE يكتب "Copyright (c) 2026 Helper Beeps".
ملفا package.json صادران من الالتزام نفسه، ما يثبت أن مخرجات البناء الأولية لـ Solidity Pro تحت هوية web3devtoolsx جاءت مباشرة من مشروع helper-beeps، وأن هناك ارتباطًا مباشرًا في المصدر بين الشيفرة أو مخرجات البناء.
عند إسقاط علاقة وراثة مخرجات البناء على خط زمني لوسوم الخبث الرسمية، تصبح نمطية تدوير publisher أوضح كثيرًا:
تمت إضافة helper-beeps.solidity-pro إلى قائمة malicious الرسمية (2026-08-06 14:27:24 UTC)
│ 8 ساعات 32 دقيقة 48 ثانية
▼
إنشاء حساب web3devtoolsx على GitHub (2026-08-06 23:00:12 UTC)
│ نحو 16 دقيقة
▼
ظهور Solidity Pro v3.4.0 الجديد
│ في اليوم التالي
▼
تمت أيضًا إضافة web3devtoolsx.solidity-pro إلى قائمة malicious الرسمية (2026-08-07 12:38:52 UTC)
رابعًا: إصدار Clean
بعد 13 دقيقة و29 ثانية فقط من التزام GitHub الأول الذي دفع bundle خبيث v3.4.0، قام المستودع نفسه بتقديم التزام Clean أعاد الإصدار إلى v1.0.0. وخلال هذه النافذة القصيرة جدًا، بدأ publisher أيضًا ثم أغلق بنفسه لفترة وجيزة مطالبة namespace على Open VSX (لم يكن في القضية أي تعليق، وأغلقها web3devtoolsx بنفسه).
تركزت تعديلات الالتزام Clean بدقة في فئتين من الأهداف. فمن جهة التنفيذ، أزيلت تفعيل Web3Analytics، وتشغيل AutoUpdater، وإعدادات telemetry، واعتماد javascript-obfuscator، وخطوة البناء الخاصة بالتشويش. ومن جهة الواجهة التسويقية، أزيلت AI Audit Engine وSecurity Scanner و100K+ badge والنصوص التي تبالغ في القدرات. كما جرى تخفيض رقم الإصدار من 3.4.0 إلى 1.0.0.
تركزت هذه التغييرات في التزام واحد باسم "Clean release". فقد أزال مباشرةً نقاط الدخول عالية الخطورة القابلة للوصول علنًا وبعض عبارات التسويق البارزة، بحيث لم تعد الأنظمة التي تفحص الـ bundle الجديد فقط تطابق الوحدة الخبيثة الأصلية. لكن التنظيف لم يكن كاملًا: إذ لم تُحذف عبارة "Trusted by 100K+" ولا صياغة "vulnerability scanner" من description في package.json — فالشارة الأكثر وضوحًا حُذفت، لكن إذا جرى فعليًا تجميع هذه الـ manifest ونشرها، فإن الميتاداتا التي قد تؤثر في نتائج البحث وصفحة المتجر ما تزال موجودة. وكما ذُكر سابقًا، بقيت الشيفرة الخبيثة محفوظة بالكامل داخل src/، لكن .vscodeignore يمنعها من دخول الحزمة النهائية.
التزام Clean يغيّر المخرج النهائي، لا تاريخ هذا المشروع الذي حدث بالفعل.
خامسًا: تغليف المصداقية
بالتزامن تقريبًا مع تغيّر الإصدار، حدث أيضًا تغليف سريع لهوية نشر جديدة: فخلال نحو 16 دقيقة من إنشاء حساب web3devtoolsx ظهرت دفعة واحدة مواد ذات طابع مؤسسي، ونسخ fork لستة مشاريع معروفة، ومستودع منتج، وأرقام إصدارات ناضجة، وادعاء 100K+. اجتماع هذه الإشارات في وقت واحد يجعل الحساب الجديد يبدو ظاهريًا كجهة مؤسسية ناضجة.
مواد بأسلوب مؤسسي. بعد نحو 15 دقيقة من إنشاء الحساب، كان الملف الشخصي قد تضمن اسم "Web3 Dev Tools"، وحقل الشركة، وموقع Zug، ورابط الموقع الرسمي، ورابط Twitter، ومنتجًا واحدًا منشورًا وخريطة طريق لمنتجين بحالة "Coming Q3". وحتى مراجعة 12 أغسطس 2026، بقيت مؤشرات النشاط طويلة الأمد مثل followers وfollowing وgists عند 0.
نسخ fork لستة مشاريع معروفة. قام الحساب خلال 13 ثانية بعمل fork متتالٍ لمشاريع OpenZeppelin Contracts وFoundry وHardhat وChainlink وUniswap v3-core وethers.js. سيرى الزائر العادي أسماء مشاريع Web3 مألوفة في الصفحة الرئيسية، لكن fork لا يعني إلا نسخ المستودع الأصلي، ولا يدل على مساهمة أو تعاون أو أي نوع من أنواع التزكية.
علامة الإصدار ووقت الإنشاء غير متطابقين. بعد 8 ثوانٍ من إنشاء المستودع، حمل الالتزام الأولي في الوقت نفسه خمس مجموعات من علامات الإصدار: v2.4.1 وv2.4.5 وv3.2.3 وv3.3.0 وv3.4.0، كما يدّعي رأس الشيفرة أيضًا أن أول إصدار كان في عام 2025. هذه علامات الإصدار والعمر تتعارض بوضوح مع السجل العلني للحساب والمستودع اللذين أُنشئا للتو في ذلك اليوم.
تعزيز متكرر للدليل الاجتماعي. ظهور "100K+" في وقت واحد داخل repository description وpackage.json وout/package.json وREADME badge ونص README ومخرجات البناء هو ادعاء متكرر لحجم المستخدمين في المواد العامة للمشروع. لا يمكن للمواد المتاحة التحقق من صحة هذا الرقم بشكل مستقل، لكن هذه الصياغة، إلى جانب رقم الإصدار الناضج والملف الشخصي المؤسسي وfork للمشاريع المعروفة، تشكل معًا صورة منتج ناضج يعرضها Solidity Pro للخارج.
هذه المواد الترويجية تتعارض بوضوح مع سلوك الشيفرة الفعلي المؤكد سابقًا: README يزعم عدم تخزين private keys أو source code، والإعدادات تصف telemetry بأنها بيانات استخدام مجهولة، ونص بناء الحزمة يصف عملية تشويش javascript-obfuscator بأنها "privacy". المنتج يدّعي تدقيقًا بالذكاء الاصطناعي، وفحص ثغرات، وكشف reentrancy، لكن الأوامر العامة المنشورة تقتصر أساسًا على الاستعلام عن Gas، وعرض أسعار الرموز، وتلميح واحد مُبنى عبر Hardhat/Foundry.
المواد المؤسسية، والنسخ المشهورة، وأرقام الإصدارات الناضجة، و100K+، والوظائف الصغيرة الحقيقية، وبيان الخصوصية كلها تؤثر على الانطباع الأولي للزائر عن الإضافة. قد يبدو كل عنصر منها طبيعيًا عند النظر إليه منفردًا، لكن الشذوذ يكمن في ظهور هذه الإشارات معًا في الوقت نفسه مع الشيفرة الخبيثة، والجدول الزمني السريع، وبقايا البناء من publisher قديم.
سادسًا: بقعة العمى في الكشف أحادي الإصدار
يمكن حذف الشيفرة الخبيثة، لكن تاريخ الإصدارات، وهوية النشر، ومصدر المشروع لا تُصفّر تلقائيًا.
عند جمع نتائج الفصول الخمسة السابقة معًا، يظهر Solidity Pro نمطًا يستحق اهتمام المنصة ومنتجات الأمان: امتداد ارتبط أصلًا بتاريخ خبيث واضح، ومن خلال إصدار نسخة جديدة لا تحتوي على القدرة الخبيثة الأصلية، يمكن لفحوص لا تراجع إلا البناء الحالي أن تعطي مجددًا نتائج clean أو غير مطابقة أو منخفضة الخطورة.
لا يكفي للتمييز بين هذا النمط والإصلاح الأمني الطبيعي أن نعرف فقط هل الشيفرة الجديدة نظيفة أم لا، بل يلزم أيضًا التحقق من أربعة مستويات في الوقت نفسه:
إجابة التجزئة والربط الحالي: ماذا يحتوي هذا الملف الآن.
إجابة تاريخ الإصدارات: ماذا سبق أن سلّم هذا المعرف الخاص بالإضافة أو هذا publisher.
إجابة publisher ومصدر الشيفرة: مع أي مشاريع خبيثة معروفة يرتبط الحزمة الحالية مباشرة.
إجابة واجهة التحكم البعيدة الحالية والتاريخية: هل تسمح الشيفرة المحلية الحالية أو الإصدارات السابقة للخادم بتغيير ما يتم تسليمه.
بالنسبة إلى أسواق الإضافات ومنتجات الأمان، يعني هذا أن كائن الرصد يجب أن يتوسع من "تجزئة ملف واحد" إلى تاريخ الإصدارات، وتغيّرات publisher، واختلافات المخرجات المبنية، وواجهة التحكم البعيدة:
احتفظ بتجزئات الإصدارات التاريخية ونتائج إزالة التشويش؛ وعندما تزيل نسخة جديدة عددًا كبيرًا من الوحدات الخطرة، يجب أن تبدأ مراجعة فروق، لا أن تُستعاد السمعة تلقائيًا.
اربط بقايا publisher القديم، وتشابه الشيفرة، ونصوص البناء، لبناء علاقة مصدر بين الشيفرة أو مخرجات البناء.
أدرج فحوص /version الدورية وعناوين URL البعيدة وسجلات تثبيت VSIX المؤقتة ضمن المراقبة وقت التشغيل.
اجعل عدد التنزيلات وstars والملف الشخصي المؤسسي مجرد سياق، لا تزكية أمنية.
خلاصة
يوجد في Solidity Pro، تحت هويتي النشر helper-beeps وweb3devtoolsx، تنفيذ خبيث واضح في كلا الحالتين: 2.4.1 يتخذ التأخير المحلي العشوائي والفرز البيئي شرطًا مسبقًا، ثم ينزّل Python مشفّرًا من خادم بعيد وينفذه؛ أما 3.4.0 فيفعّل تلقائيًا جمع الاعتمادات بعد تشغيل VS Code، ويسرّبها عبر مساري HTTP هما /x و/y، مع الإبقاء على قناة تحديث VSIX مدفوعة بالاستجابة البعيدة. وتُظهر out/package.json وrepository ومعلومات حقوق النشر في 3.4.0 الأولية أنها ما زالت تشير إلى helper-beeps، ما يثبت وجود علاقة مصدر مباشرة بين مخرجات البناء الصادرة تحت هوية النشرين.
أزال bundle النهائي في GitHub الخاص بالتزام Clean هذه الوحدات الخبيثة، لكن المستودع ما زال يحتفظ بملفات مصدر الوحدات الخبيثة؛ أما الحزمة 4.0.0 المعاد بناؤها محليًا فلم يظهر فيها أيضًا أي من الوحدات الخبيثة الأصلية. ولم يفصل بين الالتزام الأولي الذي يحتوي على مدخل خبيث ومخرجات البناء وبين التزام Clean إلا 13 دقيقة و29 ثانية، في حين ظهرت المواد ذات الطابع المؤسسي، والستة forks المعروفة، ومستودع المنتج، وبيانات الإصدار الناضج مجتمعة خلال نحو 16 دقيقة بعد إنشاء الحساب.
ما يوضحه هذا المثال في النهاية هو أن الحكم على خطر الإضافة اعتمادًا على الملف الحالي أو الإصدار الحالي فقط غير كافٍ إطلاقًا. يمكن أن تختفي الشيفرة الخبيثة من أحدث bundle، لكن السجل التاريخي الخبيث لا يفقد صلاحيته بسبب ذلك — فإصدار جديد نظيف لا يمحو حقيقة أن الاسم نفسه وpublisher نفسه سبق أن سلّما شيفرة خبيثة.
توصيات
على من ثبّت helper-beeps.solidity-pro أو web3devtoolsx.solidity-pro أن يعزل الشبكة أولًا، ويحفظ دليل الإضافة، ونسخة الحزمة، والعمليات وسجلات الشبكة، ثم يعطل الإصدارات ذات الصلة ويزيل تثبيتها. بعد ذلك يجب فحص شجرة عمليات VS Code، وملفات Python في المجلدات المؤقتة، وسجلات تثبيت VSIX غير المعتادة، وسجلات الوكيل المتعلقة بطلبات /firmware و/x و/y و/version.
إذا جرى تمكين Solidity Pro 3.4.0 (publisher: web3devtoolsx) في الماضي، فقد تكون مفاتيح محفظة التشفير، وعبارات الاسترداد، وGitHub/GitLab/npm/PyPI/AWS/Cloudflare/AI services، وCI/CD token قد تعرّضت للكشف. ينبغي إلغاء أو تدوير البيانات الاعتمادية ذات الصلة من جهاز نظيف أولًا؛ أما الأصول المشفرة فيجب نقلها إلى محفظة تستخدم seed أو مفتاحًا جديدًا بالكامل، ولا يكفي تغيير كلمة مرور المحفظة الأصلية.
إذا جرى تمكين Solidity Pro 2.4.1 (publisher: helper-beeps) في الماضي، فكلما كان من المحتمل أن يكون المضيف قد تجاوز نافذة التأخير الخاصة بهذه العينة، أو تعذّر تأكيد مدة التشغيل الفعلية، فيجب التعامل مع الحادث على أنه احتمال تنفيذ شيفرة محلية ويخضع للتحقيق.
ينبغي لفرق أمن المؤسسات أن تبحث أولًا عن Extension ID، ومسارات الطلبات الخطرة، والـ Worker المعروفة، والملفات المؤقتة، وأشجار العمليات غير الطبيعية، ثم تربط ذلك بتجزئتي SHA-256 للعَيّنتين، ووقت تثبيت الإضافة، وسجلات شبكة عمليات VS Code لتحديد نطاق التأثر. ويجب التركيز على توليفات السلوك مثل تشغيل VS Code Extension Host لـ Python detached، وتثبيت VSIX من مسار مؤقت، وقراءة إعدادات عالية القيمة ثم إطلاق multipart HTTPS.
ينبغي لسوق الإضافات فرض مراجعة بشرية إلزامية عندما تظهر في telemetry الافتراضي قدرات مثل قراءة بيانات الاعتماد، أو التنزيل البعيد، أو التنفيذ بعد فك التشفير، أو تثبيت VSIX خارج القنوات الرسمية؛ كما يجب الاحتفاظ بالإصدارات التاريخية وإجراء مراجعة فروق عبر الإصدارات، لتجنب أن تقوم نسخة لاحقة لم تعد تحتوي على الشيفرة الخبيثة بإزالة وسم المخاطر عن الإصدارات القديمة تلقائيًا.
IOC
ملف خبيث
filename: helper-beeps.solidity-pro-2.4.1.tar.gz
SHA256: 7b53b1d93f46babc7415d898e17e71ffb6f3a3af3adb222f21c03adea8b30d50
filename: web3devtoolsx.solidity-pro-3.4.0.gz
SHA256: bcbaf774f9cea0b0131859b96ba0eeadfd5a49bba59302de1bcf3d884300d508
حول MistEye
MistEye هي منصة استخبارات تهديدات Web3 ومراقبة أمنية ديناميكية طورتها SlowMist بشكل مستقل، وتوفر عبر API قدرات كشف الأنشطة الخبيثة في منظومات الحزم مفتوحة المصدر والتنبيه المبكر لمخاطر سلسلة التوريد.
تم دمج جميع الحزم الخبيثة وIOC المرتبطة بهذه العملية في محرك الكشف عن التهديدات الخاص بـ MistEye، ويمكن للمطورين استخدام API لإجراء كشف آلي على تبعيات المشاريع، وتحديد ما إذا كانت تتطابق مع حزم خبيثة معروفة، والحصول على توصيات المعالجة بسرعة.
📖 توثيق API：https://app.misteye.io/api-docs
🛠️ MistEye-DepScan：https://github.com/slowmist/MistEye-DepScanأداة CLI خفيفة الوزن، تفحص بمطرقة واحدة تبعيات المشروع والحزم المثبتة عالميًا بحثًا عن الحزم الخبيثة المعروفة، مع دعم منظومات npm / PyPI / Rust (Cargo) / Go / RubyGems
🛠️ MistEye-Skills：https://github.com/slowmist/misteye-skillsحزمة مهارات أمان لمساعد ترميز الذكاء الاصطناعي، تُفعّل تلقائيًا فحص MistEye الأمني قبل تثبيت الاعتماديات والوصول إلى الروابط
🛠️ MistEye-DNS-Guard：https://github.com/slowmist/MistEye-DNS-Guardحل DNS محلي مكتوب بـ Rust، يكشف النطاقات الخبيثة وعمليات الوصول الخطرة، ويتعرف على التصيّد وC2 وغير ذلك من التهديدات الشبكية.
أُعدّ هذا المقال بواسطة فريق استخبارات التهديدات في SlowMist، بالاستفادة من منصة MistEye للاستخبارات التهديدية وتحليل مدفوع بـ SlowMist Agent AI، وأي أسئلة مرحب بها للتشاور أو الملاحظات.
روابط مرجعية:
[1] https://yeethsecurity.com/blog/2026-08-06-Solidity-Pro-WhiteCobra-C2-to-Telegram