پشت وعده اعتبار رایگان Claude و Gemini؛ بدافزاری که به دستیار هوش مصنوعی نفوذ می‌کند

وعده خدمات رایگان هوش مصنوعی؛ پوششی برای یک عملیات چندمرحله‌ای

گزارش Elastic Security Labs نشان می‌دهد گروهی که با شناسه REF8801 ردیابی می‌شود، از نام Apex Accelerator برای جلب اعتماد بنیان‌گذاران استارتاپ‌های رمزارزی و توسعه‌دهندگان وب۳ استفاده کرده است. این مجموعه خود را ارائه‌دهنده خدمات سرمایه‌گذاری، اعتبار رایگان هوش مصنوعی، ابزارهای برنامه‌نویسی و حسابرسی امنیتی معرفی می‌کرد؛ اما بررسی فنی بسته‌های منتشرشده نشان داد که کارکرد واقعی آن‌ها با وعده‌های تبلیغاتی‌شان تفاوت اساسی دارد. نکته مهم این پرونده آن است که مهاجم صرفاً به توزیع یک فایل آلوده بسنده نکرده بود. بسته‌های نرم‌افزاری، ارتباطات دستیار هوش مصنوعی و ابزارهای موسوم به حسابرسی امنیتی، همگی بخشی از یک زنجیره واحد بودند. در نتیجه، اعتماد به یک ابزار ظاهراً تخصصی می‌توانست هم اطلاعات رایانه را در معرض خطر قرار دهد و هم محرمانگی فرایند توسعه نرم‌افزار را تهدید کند.

دو بسته npm که خدمات وعده‌داده‌شده را ارائه نمی‌کردند

پژوهشگران دو بسته اصلی را شناسایی کردند:

• @apexacc/cli که به‌عنوان دستیار هوش مصنوعی برای بنیان‌گذاران پروژه‌های وب۳ تبلیغ می‌شد.

• @apexacc/audit که خود را سرور MCP با ۱۸ ابزار برای بررسی توکن‌ها، کیف پول‌ها و قراردادهای هوشمند معرفی می‌کرد.

npm یکی از مخازن پرکاربرد برای انتشار و دریافت بسته‌های نرم‌افزاری در اکوسیستم جاوااسکریپت است. انتشار یک بسته در چنین مخزنی، به‌خودی‌خود به معنای تأیید امنیت یا قابل‌اعتمادبودن ناشر آن نیست.

طبق بررسی Elastic، هر ۱۸ ابزار امنیتی بسته @apexacc/audit به‌جای اجرای اسکن واقعی، یافته‌های ساختگی تولید می‌کردند. در آزمایش دیگری نیز سرویس امتیازدهی مرتبط با @apexacc/cli برای یک پروژه کاملاً فرضی امتیاز ۵۱ از ۱۰۰ برگرداند، درحالی‌که اطلاعات کافی برای ارزیابی واقعی آن پروژه ارائه نشده بود و سرویس امتیازدهی هوش مصنوعی نیز در دسترس نبود. این رفتار اهمیت ویژه‌ای دارد: یک گزارش امنیتی با ظاهر حرفه‌ای لزوماً حاصل بررسی فنی واقعی نیست. اگر تیم توسعه بر اساس چنین گزارشی تصمیم بگیرد، ممکن است آسیب‌پذیری‌های واقعی را نادیده بگیرد یا برای اصلاح مشکلاتی هزینه کند که اساساً وجود ندارند.

بدافزارها چگونه به ویندوز و مک راه پیدا می‌کردند؟

بر اساس گزارش Elastic، بسته‌های مورد بررسی پس از اجرا، فایل‌های اجرایی متناسب با سیستم‌عامل را از انتشارهای مخازن گیت‌هاب دریافت می‌کردند. مسیر آلودگی در ویندوز و macOS یکسان نبود، اما هدف مشترک آن‌ها اجرای کد مخرب و فراهم‌کردن امکان جمع‌آوری اطلاعات یا دسترسی بعدی بود.

ویندوز؛ سرقت اطلاعات و تلاش برای تضعیف دفاع امنیتی

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

خطر متفاوت این کارزار؛ هدایت ترافیک دستیار هوش مصنوعی به سرور مهاجم

یکی از مهم‌ترین یافته‌های گزارش، دست‌کاری مسیر ارتباطی یک ابزار برنامه‌نویسی هوش مصنوعی است. در این روش، نرم‌افزار طوری پیکربندی می‌شد که درخواست‌های مدل زبانی را به‌جای مسیر مورد انتظار، به یک سرویس تحت کنترل مهاجم ارسال کند. گزارش Elastic این رفتار را در ارتباط با OpenRouter و یک نسخه بازبسته‌بندی‌شده از ابزار برنامه‌نویسی بررسی کرده است.

این موضوع از نظر امنیت اطلاعات اهمیت دارد، زیرا درخواست‌های دستیار هوش مصنوعی همیشه فقط شامل یک پرسش ساده نیستند. بسته به کاری که کاربر انجام می‌دهد، محتوای ارسالی ممکن است شامل موارد زیر باشد:

• متن پرسش‌ها و سابقه مکالمه با دستیار؛

• بخش‌هایی از کد منبع و اطلاعات پروژه؛

• خروجی ابزارهایی که دستیار در محیط توسعه فراخوانی می‌کند؛

• توضیحات فنی درباره زیرساخت یا معماری نرم‌افزار؛

• اطلاعات محرمانه‌ای که کاربر ناخواسته در متن درخواست قرار داده است.

در چنین شرایطی، مسئله فقط احتمال افشای داده نیست. اگر پاسخ مدل نیز از مسیر مهاجم دریافت شود، امکان دست‌کاری محتوای برگشتی مطرح خواهد بود. در گزارش Elastic، پژوهشگران نشان دادند که سرور کنترل‌شده توسط مهاجم می‌تواند پاسخ‌هایی را جایگزین کند که در قالب خروجی مدل تفسیر می‌شوند؛ از جمله پاسخ‌هایی که فراخوانی ابزارها را پیشنهاد می‌کنند.

با این حال، باید میان قابلیت فنی و سوءاستفاده مشاهده‌شده تفاوت گذاشت. پژوهشگران امکان هدایت ترافیک و کنترل پاسخ‌های دریافتی را بررسی کردند، اما در آزمایش گزارش‌شده، جایگزینی مخرب پاسخ‌های مدل را مشاهده نکردند. بنابراین، وجود قابلیت بالقوه دست‌کاری به‌تنهایی اثبات نمی‌کند که تمام این امکانات علیه قربانیان واقعی به کار گرفته شده‌اند.

سرور MCP چگونه می‌تواند بر رفتار دستیار اثر بگذارد؟

MCP یا Model Context Protocol پروتکلی برای اتصال مدل‌های هوش مصنوعی به ابزارها و منابع خارجی است. برای مثال، یک دستیار برنامه‌نویسی ممکن است از طریق یک سرور MCP به فایل‌ها، ابزارهای توسعه یا خدمات تخصصی دسترسی پیدا کند. این اتصال می‌تواند بهره‌وری را افزایش دهد، اما اعتماد به سرور متصل‌شده اهمیت زیادی دارد. بر اساس گزارش Elastic، بسته‌های مورد بررسی می‌توانستند یک سرور MCP تحت کنترل مهاجم را در پیکربندی عامل هوش مصنوعی ثبت کنند. این سرور قادر بود دستورالعمل‌ها، نام ابزارها، توضیحات و ورودی‌های پذیرفته‌شده آن‌ها را در اختیار دستیار قرار دهد.

در نتیجه، خطر در دو سطح شکل می‌گیرد:

1. محرمانگی: اطلاعات ارسالی به مدل یا ابزارهای متصل ممکن است از مسیر ناامن عبور کند یا به سرور نامطمئن برسد.

2. یکپارچگی و کنترل: ابزار یا پاسخ غیرقابل‌اعتماد ممکن است بر تصمیم بعدی عامل هوش مصنوعی اثر بگذارد؛ به‌ویژه زمانی که اجرای ابزارها بدون تأیید مناسب مجاز باشد.

این به معنای آن نیست که هر سرور MCP خطرناک است یا هر دستیار هوش مصنوعی مستعد چنین حمله‌ای است. خطر به منشأ نرم‌افزار، تنظیمات اتصال، سطح دسترسی ابزارها و سیاست‌های تأیید عملیات بستگی دارد.

این کارزار از چه زمانی فعال بود؟

گزارش Elastic در ۱۲ اکتبر ۲۰۲۶ منتشر شد و به عملیاتی اشاره دارد که پیش از شناسایی دو بسته اصلی نیز فعالیت داشته است. در گزارش، سه بسته مرتبط دیگر که در بررسی پیشین SafeDep مطرح شده بودند، معرفی شده‌اند:

• @apexfdn/apex

• @copilot-mcp/apex

• @apexfdn/copilot-mcp

این ارتباط نشان می‌دهد که بررسی امنیتی نباید تنها به دو نام جدید محدود شود. با این حال، وجود ارتباط میان بسته‌ها به‌معنای آن نیست که هر نسخه از تمام بسته‌های مرتبط الزاماً رفتار یکسانی داشته است؛ برای چنین نتیجه‌ای باید نسخه و محتوای هر بسته جداگانه بررسی شود.همچنین گزارش‌های پیشین از استفاده از نام Apex Foundation، وب‌سایت‌های مرتبط و حضور در رویدادهای حضوری برای ایجاد اعتبار ظاهری حکایت دارند. این جزئیات بخشی از روش جلب اعتماد بوده‌اند؛ اما حضور در یک رویداد یا داشتن وب‌سایت به‌تنهایی نشانه فعالیت مخرب نیست. آنچه در این پرونده اهمیت دارد، پیوند میان هویت تبلیغاتی و رفتار فنی مشاهده‌شده در بسته‌های نرم‌افزاری است.

بااین‌حال، درس‌های امنیتی آن برای گروه‌های زیر قابل استفاده است:

• توسعه‌دهندگان نرم‌افزار: نصب بسته‌های npm و ابزارهای توسعه باید بر اساس ارزیابی اعتماد و بررسی رفتار واقعی آن‌ها انجام شود.

• استارتاپ‌های فناوری و رمزارز: پیشنهاد سرمایه‌گذاری، اعتبار رایگان مدل‌های هوش مصنوعی یا حسابرسی رایگان نباید به‌تنهایی مبنای اعتماد به نرم‌افزار طرف مقابل باشد.

• تیم‌های امنیت اطلاعات: ابزارهای حسابرسی باید با نتایج قابل بازتولید و شواهد فنی ارزیابی شوند، نه صرفاً با امتیاز یا گزارش ظاهراً حرفه‌ای.

• کاربران حرفه‌ای هوش مصنوعی: ارسال کد محرمانه، اطلاعات مشتریان یا داده‌های احراز هویت به سرویس‌هایی که هویت و سیاست‌های پردازش داده آن‌ها مشخص نیست، ریسک غیرضروری ایجاد می‌کند.

برای کسب‌وکارهایی که از دستیارهای برنامه‌نویسی در توسعه محصولات استفاده می‌کنند، این پرونده یک مسئله مشخص را برجسته می‌کند: امنیت ابزارهای هوش مصنوعی باید در کنار امنیت وابستگی‌های نرم‌افزاری بررسی شود، نه جدا از آن.

کاربران چه اقداماتی انجام دهند؟

اقدامات زیر توصیه‌های دفاعی عمومی متناسب با سازوکار این تهدید هستند. این فهرست به معنای تأیید آلودگی دستگاه یا حساب هیچ کاربر خاصی نیست.

اگر یکی از بسته‌های معرفی‌شده را نصب کرده‌اید

1. اجرای ابزار را متوقف کنید. اگر بسته روی دستگاه نصب است، استفاده از آن را متوقف و دسترسی آن را محدود کنید. صرف حذف بسته، در صورت اجرای قبلی کد مخرب، برای اثبات پاک‌بودن سیستم کافی نیست.

2. دستگاه را از نظر آلودگی بررسی کنید. در رایانه‌های سازمانی، موضوع را با مسئول امنیت فناوری اطلاعات در میان بگذارید. در صورت احتمال اجرای بدافزار، بررسی فرایندهای فعال، ارتباطات شبکه و هشدارهای ابزار امنیتی باید با روش مناسب سیستم‌عامل انجام شود.

3. پیکربندی دستیار هوش مصنوعی را بازبینی کنید. نشانی سرویس‌های مدل، متغیرهای محیطی مرتبط با API و سرورهای MCP ثبت‌شده را با تنظیمات مورد تأیید خود مقایسه کنید. اگر تغییری را نمی‌شناسید، تا زمان بررسی آن را قابل‌اعتماد فرض نکنید.

4. اعتبارنامه‌های در معرض خطر را از دستگاهی مطمئن تعویض کنید. اگر احتمال می‌دهید رمز عبور، کلید API یا نشست حساب شما در اختیار بدافزار قرار گرفته باشد، اعتبارنامه مربوط را باطل یا تعویض کنید. در صورت احتمال سرقت نشست، از گزینه خروج از همه نشست‌های فعال نیز استفاده کنید.

5. در صورت احتمال آلودگی مک یا ویندوز، بررسی تخصصی را در اولویت قرار دهید. پاک‌سازی ناقص ممکن است دسترسی باقی‌مانده مهاجم را برطرف نکند. در محیط سازمانی، تصمیم درباره قرنطینه، بازسازی سیستم و بازیابی داده باید بر اساس شواهد بررسی اتخاذ شود.

برای پیشگیری از تکرار چنین رخدادی

• نام ناشر، مخزن اصلی، سابقه انتشار و کد بسته را پیش از نصب بررسی کنید.

• برای وابستگی‌های پروژه، نسخه‌های مشخص و مورد تأیید را تثبیت کنید و تغییرات جدید را پیش از ورود به محیط اصلی بازبینی کنید.

• دستیار هوش مصنوعی را به سرورهای MCP ناشناس متصل نکنید.

• دسترسی ابزارهای عامل هوش مصنوعی به فایل‌ها، شبکه و اجرای فرمان را به حداقل لازم محدود کنید.

• اجرای عملیات حساس را به تأیید صریح کاربر یا سیاست‌های کنترل‌شده وابسته کنید.

• نتایج ابزارهای حسابرسی را با شواهد فنی قابل بررسی تطبیق دهید؛ امتیاز امنیتی به‌تنهایی اثبات‌کننده صحت ارزیابی نیست.

جمع‌بندی

پرونده Apex Accelerator نمونه‌ای از ترکیب مهندسی اجتماعی، توزیع نرم‌افزار مخرب و سوءاستفاده از اعتماد به ابزارهای هوش مصنوعی است. بخش مهم ماجرا این است که مهاجم می‌تواند از ظاهر حرفه‌ای یک ابزار تخصصی برای عبور از مرحله اعتماد اولیه استفاده کند و سپس به اطلاعات دستگاه یا مسیر ارتباطی دستیار هوش مصنوعی دسترسی پیدا کند.برای تیم‌های توسعه، بررسی منشأ بسته‌ها و محدودکردن دسترسی عامل‌های هوش مصنوعی باید بخشی از فرایند معمول امنیت نرم‌افزار باشد. برای سایر کاربران نیز اصل ساده‌ای مطرح است: ابزاری که وعده خدمات رایگان یا گزارش امنیتی حرفه‌ای می‌دهد، پیش از بررسی فنی نباید قابل‌اعتماد تلقی شود.