افزونه مخرب Solidity Pro؛ سرقت کلیدها در VS Code

Visual Studio Code یکی از پرکاربردترین محیط های ویرایش و توسعه نرم افزار قدرتمند و انعطاف پذیر است که بخش مهمی از انعطاف پذیری آن به افزونه های داخلی آن برمی گردد. توسعه دهندگان نرم افزار می توانند با نصب افزونه های مختلف قابلیت هایی مانند پشتیبانی از یک زبان برنامه نویسی، ابزارهای تست و بررسی، امکانات هوش مصنوعی، Git، مدیریت Cloud و ده ها قابلیت دیگر را مستقیماً به محیط کاری خود اضافه کنند. همین امکانات و دسترسی ها باعث می شود که یک افزونه مخرب، پتانسیل آن را داشته باشد که در صورت نصب روی سیستم توسعه دهنده، به یک تهدید بسیار جدی تبدیل شود. ضریب نفوذ VS Code در جامعه برنامه نویسی فارسی زبان نسبتا زیاد است و این موضوع را می توان از تعدد دوره ها، آموزش ها و منابع دانلود ایرانی آن متوجه شد.

Solidity نیز زبان اصلی توسعه بسیاری از قراردادهای هوشمند مبتنی بر شبکه Ethereum است. توسعه دهندگان این حوزه معمولاً با کیف پول ها، کلیدهای دسترسی، مخازن کد و سرویس های مختلف توسعه سروکار دارندو این سطح و گستردگی استفاده باعث شده است که سیستم های مورد استفاده آنها به اهداف ارزشمندی برای هکرها و سارقین اطلاعات تبدیل شود. در ایران نیز برای Solidity دوره دانشگاهی، کتاب و محتوای تخصصی فارسی وجود دارد.

حالا پژوهشگران امنیتی دو افزونه با نام Solidity Pro را بررسی کرده اند که به جای ارائه یک ابزار عادی برای توسعه قراردادهای هوشمند، در نسخه های مخرب خود برای اجرای کد، جمع آوری اطلاعات حساس و سرقت کلیدها و اطلاعات کیف پول طراحی شده اند. شناسه دو افزونه اصلی عبارت اند از helper-beeps.solidity-pro و web3devtoolsx.solidity-pro.

بر اساس بررسی تیم امنیتی هوش سپید از گزارش فنی Yeeth Security و گزارش تکمیلی منتشرشده امروز، دامنه اطلاعات هدف این بدافزار از رمزارز فراتر می رود. توکن های مخازن کد، کلیدهای سرویس های ابری، کلیدهای SSH، کلیدهای رابط برنامه نویسی و اطلاعات مرورگر نیز در فهرست داده هایی قرار دارند که نمونه های جدیدتر برای پیدا کردن آنها طراحی شده اند.

خلاصه خبر

• چه اتفاقی افتاده است؟ چند افزونه با ظاهر ابزار توسعه Solidity در Open VSX دارای رفتار مخرب شناسایی شده اند.
• چه افرادی باید نگران باشند؟ توسعه دهندگانی که یکی از شناسه های مخرب گزارش شده را نصب کرده اند، به ویژه افرادی که روی همان سیستم به Git، سرویس های ابری، SSH یا کیف پول رمزارز دسترسی داشته اند.
• وضعیت فعلی چیست؟ دو افزونه اصلی دیگر در Open VSX در دسترس نیستند؛ اما حذف افزونه از Marketplace به معنی پاک شدن سیستم هایی نیست که قبلاً آن را اجرا کرده اند. مخزن مرتبط GitHub نیز هنگام بررسی امروز همچنان قابل دسترسی بود.
• اقدام فوری چیست؟ اگر یکی از این افزونه ها نصب شده است، آن را حذف کنید و فقط به حذف افزونه اکتفا نکنید؛ Credentialها و کلیدهای حساسی که روی سیستم در دسترس بوده اند نیز باید بررسی و در صورت احتمال افشا تعویض شوند.

ماجرای Solidity Pro از کجا شروع شد؟

گزارش فنی Yeeth Security در ۶ آگوست منتشر شد و رفتار چند نسخه از افزونه هایی با نام Solidity Pro را بررسی کرد. امروز، ۱۰ آگوست، وب سایت The Hacker News یافته ها را با تمرکز بر سرقت اطلاعات احراز هویت کاربران و کیف پول ها پوشش داد. بنابراین تاریخ امروز، تاریخ انتشار پوشش خبری جدید است و نباید آن را با تاریخ شروع فعالیت مهاجمان یکی دانست.

پژوهشگران دو ناشر با نام های helper-beeps و web3devtoolsx را شناسایی کردند که بسته هایی با نام مشابه solidity-pro منتشر کرده بودند. نام، توضیحات ظاهراً حرفه ای و ادعای ارائه امکاناتی مانند تحلیل امنیت قرارداد هوشمند یا بهینه سازی هزینه اجرا می توانست برای یک توسعه دهنده کاملاً طبیعی به نظر برسد.

موضوع مهم این است که مهاجمان فقط به انتشار یک نسخه ثابت مخرب اکتفا نکرده بودند. در میان نسخه ها، نمونه های تمیز و ظاهراً بی خطر نیز دیده شده است؛ رفتاری که می تواند تشخیص بر اساس بررسی یک نسخه خاص یا اعتماد به سابقه ناشر را دشوارتر کند.

افزونه مخرب Solidity Pro تاکنون چگونه کار می کرده است؟

رفتار افزونه در طول زمان ثابت نبوده و به مرور تغییراتی را تجربه کرده است.در نسخه های اولیه بررسی شده، از نسخه 1.0.0 تا شاخه 2.4.x، افزونه پس از فعال شدن مدتی صبر می کرد و سپس با زیرساخت مبتنی بر Cloudflare Workers ارتباط برقرار می کرد. پاسخ رمزگذاری شده دریافت، روی سیستم به یک Payload پایتون تبدیل و خارج از فرایند اصلی افزونه اجرا می شد. پژوهشگران همچنین مکانیزم هایی برای تشخیص برخی محیط های CI و Sandbox مشاهده کرده اند.تأخیر در اجرای رفتار مخرب تصادفی بود و در نمونه های بررسی شده می توانست چندین ساعت تا چند روز طول بکشد. چنین روشی باعث می شود کاربری که افزونه را نصب کرده است در نگاه اول رفتار غیرعادی مشاهده نکند و Sandboxهایی که فقط چند دقیقه نرم افزار را بررسی می کنند نیز ممکن است مرحله مخرب را نبینند.در نمونه های جدیدتر شاخه 3.x، مهاجمان به سرقت مستقیم اطلاعات روی سیستم حرکت کرده اند. در این نسخه ها، افزونه به دنبال مجموعه وسیعی از Credentialها و اسرار توسعه می گردد و داده های جمع آوری شده می توانند از طریق زیرساخت مبتنی بر ربات تلگرام به خارج منتقل شوند.

چه اطلاعاتی در معرض خطر سرقت قرار دارند؟

دامنه اطلاعات هدف یکی از مهم ترین دلایل اهمیت این خبر است.تحلیل Yeeth نشان می دهد نمونه های بررسی شده الگوهای مربوط به توکن های GitHub و GitLab، کلیدهای AWS، توکن های Cloudflare، کلیدهای API مرتبط با OpenAI، توکن های ربات تلگرام، کلیدهای خصوصی SSH و اطلاعات ذخیره شده مرتبط با مرورگر را جستجو می کنند. اطلاعات مربوط به کیف پول نیز هدف مستقیم بدافزار است. فهرست بررسی شده شامل عبارت های بازیابی یا Seed Phrase و داده های مرتبط با کیف پول هایی مانند MetaMask، Phantom، Rabby، Coinbase، Trust و Keplr است. بنابراین خطر فقط این نیست که یک توسعه دهنده مقداری رمزارز از دست بدهد. سرقت یک توکن GitHub می تواند دسترسی به Repository خصوصی را ایجاد کند؛ سرقت کلید Cloud یا SSH ممکن است به زیرساخت دیگری راه باز کند و افشای یک کلید API نیز می تواند پیامد مالی یا امنیتی مستقل داشته باشد. از همین رو، یک Workstation توسعه دهنده باید دارایی امنیتی مهمی در نظر گرفته شود؛ زیرا معمولاً مجموعه ای از دسترسی هایی در آن جمع می شوند که مهاجم برای حرکت به سیستم های دیگر به آنها نیاز دارد.

کدام افزونه ها و نسخه ها درگیر هستند؟

در این رویداد امنیتی مسئله صرفا یک باگ نرم افزاری نیست بنابراین بهتر است به جای عبارت «نسخه آسیب پذیر» از عبارت «بسته های مخرب یا مشکوک» استفاده کنیم.

Yeeth رفتار این خانواده را دست کم در بازه نسخه های 1.0.0 تا 4.0.0 دنبال کرده است؛ اما نکته بسیار مهم این است که تمام نسخه های این بازه الزاماً حاوی کد مخرب نبوده اند. برای نمونه، برخی نسخه های ظاهراً تمیز نیز میان انتشارهای مخرب مشاهده شده اند. بنابراین اگر یکی از شناسه های بالا روی سیستم نصب شده است، اعتماد کردن به یک شماره نسخه خاص رویکرد مطمئنی نیست.

آیا حمله فعال و قربانی واقعی گزارش شده است؟

وجود بسته های مخرب و قابلیت های سرقت اطلاعات آنها توسط پژوهشگران تایید شده است. اما در منابعی که امروز بررسی کردم، آمار قابل اتکایی از تعداد نصب واقعی یا تعداد قربانیان دو بسته اصلی فعلی منتشر نشده است. Yeeth این فعالیت را از نظر روش کار با کمپین های منتسب به WhiteCobra مقایسه کرده است و به شباهت هایی مانند استفاده از نام های مرتبط با Solidity، تغییر مداوم Publisher، Obfuscation و روش های چندمرحله ای اشاره می کند. با این حال، خود پژوهشگران هشدار می دهند که شباهت TTPها به تنهایی برای انتساب قطعی کافی نیست. بنابراین در این خبر WhiteCobra را عامل قطعی این دو افزونه معرفی نمی کنیم.همچنین ماجرای سرقت حدود ۵۰۰ هزار دلار از یک توسعه دهنده که پیش تر در گزارش های امنیتی مطرح شده بود، مربوط به یک کمپین قبلی افزونه جعلی Solidity در سال ۲۰۲۵ است و نباید آن خسارت را به دو بسته امروز نسبت داد.

چه افرادی باید نگران باشند؟

اولویت نخست با افرادی است که یکی از شناسه های گزارش شده را نصب کرده اند.ریسک برای توسعه دهندگانی بالاتر است که روی همان سیستم به مخازن خصوصی Git، حساب های Cloud، کلیدهای SSH، API Keyها یا کیف پول های رمزارزی دسترسی داشته اند؛ زیرا همین اطلاعات مستقیماً در فهرست اهداف نمونه های بررسی شده قرار دارند. تیم های DevOps و توسعه نیز باید موضوع را جدی بگیرند. یک توسعه دهنده آلوده ممکن است Credentialهایی در اختیار داشته باشد که به Pipeline، Repository، محیط Cloud یا سرورهای سازمان دسترسی ایجاد می کنند. در این حالت Incident دیگر صرفاً «آلودگی لپ تاپ یک برنامه نویس» نیست و باید دامنه دسترسی های آن کاربر نیز بررسی شود. برای مخاطب ایرانی نیز این سناریو قابل توجه است. وجود دوره ها، منابع فارسی و محتوای فعال درباره VS Code و Solidity نشان می دهد هر دو فناوری در جامعه توسعه ایران شناخته شده اند، هرچند هیچ شاهدی از هدف قرار گرفتن مشخص کاربران ایرانی در این کمپین فعلی وجود ندارد.

اگر این افزونه را نصب کرده ایم چه کاری انجام دهیم؟

اولویت اول: افزونه را حذف کنید. The Hacker News نیز به کاربرانی که این افزونه ها را نصب کرده اند توصیه کرده است آنها را حذف و سیستم را از نظر آثار مرتبط بررسی کنند. اما حذف افزونه نباید پایان کار باشد. اگر نسخه مخرب اجرا شده باشد، اطلاعات ممکن است پیش از حذف از سیستم خارج شده باشند. بر اساس ماهیت Infostealer و فهرست Credentialهای هدف، جمع بندی دفاعی تیم امنیتی هوش سپید این است که دستگاه باید حداقل تا زمان بررسی، سیستمی با احتمال Compromise در نظر گرفته شود.

در مراحل بعدی کارهای زیر را به ترتیب اولویت انجام دهید:

1. توکن های GitHub و GitLab، کلیدهای API، دسترسی های AWS و Cloudflare، توکن های ربات، کلیدهای SSH و سایر Secretهایی را که روی آن سیستم در دسترس بوده اند بررسی و در صورت احتمال افشا از یک سیستم سالم Rotate یا Revoke کنید. فهرست اهداف بدافزار نشان می دهد این Credentialها مستقیماً جستجو می شده اند.
2. لاگ های سرویس های مهم را برای ورود، استفاده از Token یا فعالیت غیرعادی پس از زمان نصب افزونه بررسی کنید.
3. شاخص های منتشر شده توسط Yeeth، شامل شناسه افزونه ها، Hashها و رفتارهای شبکه ای را در EDR، SIEM یا Endpointهای توسعه جستجو کنید.
4. اگر Seed Phrase یا Private Key کیف پول روی سیستم وجود داشته یا احتمال دسترسی بدافزار به آن وجود دارد، آن Wallet را دیگر قابل اعتماد تلقی نکنید. MetaMask نیز در راهنمای رسمی خود برای Seed Phrase مشکوک به افشا، ایجاد کیف پول جدید با کلیدهای تازه و انتقال دارایی های باقی مانده را توصیه می کند. این کار باید از یک دستگاه سالم انجام شود.
5. در سازمان ها، فقط سیستم یک کاربر بررسی نشود؛ Inventory افزونه های نصب شده روی سیستم توسعه دهندگان و سیاست نصب Extension نیز بازبینی شود.

چرا تعداد دانلود یا ظاهر حرفه ای کافی نیست؟

یکی از آموزنده ترین بخش های این رخداد، نحوه ساخت احساس اعتماد در کاربر است. Yeeth نمونه هایی را مشاهده کرده که در میان نسخه های مخرب، نسخه های ظاهراً سالم نیز منتشر شده بودند. علاوه بر این، گزارش این شرکت به استفاده از نام های حرفه ای، توضیحات متقاعدکننده و الگوهای افزایش مصنوعی اعتبار در کمپین های مشابه اشاره می کند. بنابراین تعداد دانلود بالا، README حرفه ای یا حتی این واقعیت که یک نسخه فعلی رفتار واضحاً مخربی ندارد، نباید به تنهایی معیار اعتماد به یک Publisher ناشناس باشد. این مسئله به ویژه در محیط توسعه اهمیت دارد، چون افزونه ها برخلاف بسیاری از برنامه های معمولی می توانند در بستری اجرا شوند که توسعه دهنده همزمان به Source Code، Terminal، Git، فایل های Configuration و Secretهای مختلف دسترسی دارد.

تحلیل تیم امنیتی هوش سپید؛ چرا این خبر فراتر از رمزارز است؟

بر اساس بررسی تیم امنیتی هوش سپید از گزارش های فنی منتشرشده، مهم ترین نکته این رخداد «سرقت کیف پول» نیست؛ بلکه تبدیل محیط توسعه به نقطه ورود به زنجیره اعتماد نرم افزار و زیرساخت سازمان است. وقتی یک برنامه نویس افزونه ای را نصب می کند، معمولاً آن را ابزاری جانبی می بیند. اما همین افزونه در بستری اجرا می شود که ممکن است Credentialهای Git، Cloud، SSH و ابزارهای توسعه در آن وجود داشته باشند. به همین دلیل امنیت افزونه ها باید بخشی از امنیت زنجیره تامین نرم افزار تلقی شود، نه صرفاً مسئله امنیت شخصی توسعه دهنده. هوش سپید پیش تر در مطلب مربوط به تغییرات امنیتی npm 12 نیز به همین مفهوم پرداخته بود: مسئله اصلی این است که ابزارها، Packageها و Extensionهایی که وارد فرایند توسعه می شوند، بخشی از Trusted Computing Base تیم نرم افزاری هستند. درس دوم این است که Allowlist کردن افزونه های مورد تایید، بررسی Publisher، محدود کردن Secretهای دائمی روی Workstation و استفاده از Credentialهای کوتاه عمر می تواند اثر چنین رخدادهایی را کاهش دهد.

و شاید مهم ترین درس برای توسعه دهنده این باشد:

محیط کدنویسی فقط یک ویرایشگر متن نیست؛ در بسیاری از سازمان ها یکی از پرامتیازترین نقاط دسترسی به کل زنجیره توسعه است.

جمع بندی

افزونه های مخرب Solidity Pro نشان می دهند که حملات زنجیره تامین الزاماً از یک Package معروف، Update رسمی یا Repository اصلی شروع نمی شوند. گاهی مهاجم فقط کافی است ابزاری بسازد که درست شبیه چیزی باشد که توسعه دهنده به دنبال آن می گردد. در این مورد، خطر از کیف پول رمزارزی فراتر می رود و می تواند شامل Tokenهای توسعه، Cloud Credentialها، SSH Keyها و سایر اطلاعات حساس باشد. دو افزونه اصلی اکنون از Open VSX حذف شده اند، اما اگر قبلاً روی یک سیستم نصب و اجرا شده باشند، حذف امروز Marketplace چیزی را که احتمالاً قبلاً سرقت شده بازنمی گرداند. اگر یکی از شناسه های گزارش شده روی سیستم شما وجود داشته است، اقدام درست فقط Uninstall نیست؛ بررسی سیستم، چرخش Credentialهای در معرض خطر و ارزیابی دامنه دسترسی توسعه دهنده باید در اولویت قرار گیرد.

منابع

Yeeth Security — تحلیل فنی افزونه‌های مخرب Solidity Pro
منبع اصلی بررسی رفتار بدافزار و شاخص‌های شناسایی.

The Hacker News — گزارش افزونه‌های مخرب Solidity Pro
پوشش مستقل و تکمیلی رخداد.

MetaMask — راهنمای رسمی واکنش به افشای اطلاعات کیف پول
مرجع اقدامات امنیتی در صورت احتمال افشای کلید خصوصی یا عبارت بازیابی.