‏NomShub؛ وقتی باز کردن یه مخزن، کنترل سیستمت رو دست مهاجم می‌ده

تیم Straiker توی مقاله‌ای یه زنجیرهٔ آسیب‌پذیری بحرانی توی ادیتور کدنویسی هوش مصنوعی Cursor رو معرفی می‌کنه که اسمش رو گذاشتن NomShub. به گفتهٔ نویسنده‌ها، توی این حمله یه مخزن مخرب می‌تونه فقط با باز شدن، عامل هوش مصنوعی Cursor رو فریب بده تا خودش یه در پشتی پایدار روی دستگاه توسعه‌دهنده نصب کنه و به مهاجم دسترسی شل مخفی و دائمی بده. این زنجیره سه ضعف رو به هم وصل می‌کنه: تزریق غیرمستقیم پرامپت، فرار از سندباکس، و سوءاستفاده از قابلیت تونل از راه دور.

نقطهٔ شروع، تزریق غیرمستقیم پرامپت (indirect prompt injection) ـه. مهاجم دستورهای مخربش رو لای محتوای مخزن — مثلاً ته فایل README.md — قایم می‌کنه و شبیه یه راهنمای راه‌اندازی معمولی نشونش می‌ده. وقتی کاربر مخزن رو باز می‌کنه و یه درخواست ساده مثل «این تمپلیت رو راه‌اندازی کن» می‌ده، عامل README رو می‌خونه و اون دستورهای تزریق‌شده رو به‌عنوان نیازمندی واقعی پروژه اجرا می‌کنه. نکتهٔ کلیدی به گفتهٔ نویسنده‌ها اینه که عامل‌های کدنویسی مرز بین «خوندن» و «اجرا کردن» رو محو می‌کنن.

قدم بعدی فرار از سندباکس ـه. Cursor دو لایه دفاعی داره: سندباکس seatbelt در سطح هستهٔ مک‌اواس، و یه پارسر دستور در سطح اپلیکیشن به اسم shouldBlockShellCommand که قبل از اجرا تصمیم می‌گیره دستور نیاز به تأیید کاربر داره یا نه. مشکل اینجاست که این پارسر فقط فایل‌های اجرایی خارجی رو دنبال می‌کنه و نسبت به دستورهای داخلیِ خود شل (shell builtins) مثل export، cd، source و eval کوره. برای همین نمی‌بینه که دایرکتوری کاری کِی عوض می‌شه یا متغیرهای محیطی کِی دستکاری می‌شن.

با همین نقطه‌کور، عامل می‌تونه با یه دستور ساده دایرکتوری کاری رو از پوشهٔ پروژه به پوشهٔ خانگی کاربر منتقل کنه و بیرون از محدودهٔ ورک‌اسپیس بنویسه. چون محدودهٔ نوشتنیِ سندباکس seatbelt هم کل پوشهٔ خانگی (~/) رو شامل می‌شه، هر دو لایه همزمان شکست می‌خورن. هدف نهایی فایل ~/.zshenv ـه که با هر بار باز شدن یه شل Zsh — تعاملی یا غیرتعاملی — اجرا می‌شه؛ پس با بازنویسی اون، payload مهاجم روی هر ترمینال جدید به‌طور خودکار اجرا می‌شه و پایداری (persistence) برقرار می‌مونه.

تیکهٔ آخر، سوءاستفاده از تونل ـه. Cursor مثل VS Code یه باینری به اسم cursor-tunnel رو همراه خودش می‌فرسته که دسترسی شل کامل به دستگاه میزبان می‌ده و از زیرساخت Dev Tunnels مایکروسافت رد می‌شه. عامل می‌تونه این تونل رو راه بندازه و با سوءاستفاده از جریان احراز هویت device code گیت‌هاب، کد مجوز رو به سرور مهاجم بفرسته تا حساب گیت‌هاب مهاجم به تونل قربانی دسترسی پیدا کنه. نویسنده‌ها می‌گن این یه حملهٔ Living-Off-The-Land ـه: چون cursor-tunnel رسماً امضا و توسط اپل تأیید شده، آنتی‌ویروس و ابزارهای EDR بهش گیر نمی‌دن و ترافیکش هم از Azure روی HTTPS استاندارد رد می‌شه و عین فعالیت عادی توسعه‌دهنده به نظر می‌رسه.

به گفتهٔ مقاله، این حمله نشون‌دهندهٔ یه دستهٔ جدید از مشکلات امنیتی با ظهور سیستم‌های هوش مصنوعی عامل‌محوره: تزریق پرامپت سنتی شاید فقط باعث می‌شد مدل یه چیز نامناسب بگه، ولی تزریق پرامپت عامل‌محور می‌تونه کل سیستم رو به خطر بندازه. خود Cursor/Anysphere بخش فرار از سندباکس رو از طریق HackerOne با شدت High ارزیابی کرده، جایزه داده، و وصله‌ش رو توی Cursor 3.0 منتشر کرده. توصیه‌ها هم اینه که کاربرها مخازن ناشناس رو محتاطانه باز کنن، اقدام‌های عامل (مخصوصاً کارهای مربوط به تونل یا شبکه) رو قبل از تأیید بررسی کنن، و فایل‌های راه‌انداز شل مثل .zshenv و .zshrc و .bashrc رو زیر نظر داشته باشن.

نکات کلیدی:

• NomShub یه زنجیرهٔ آسیب‌پذیری بحرانیه که توی Cursor فقط با باز کردن یه مخزن مخرب، بدون تعامل بیشترِ کاربر، فعال می‌شه.
• پارسر دستور Cursor نسبت به دستورهای داخلی شل (export، cd، source) کوره و همین باعث فرار از سندباکس می‌شه.
• پایداری با بازنویسی فایل ~/.zshenv برقرار می‌مونه که با هر شل جدید اجرا می‌شه.
• مهاجم با سوءاستفاده از باینری امضاشدهٔ cursor-tunnel و جریان device code گیت‌هاب، دسترسی شل پایدار و مخفی می‌گیره.
• چون باینری تونل قانونی و امضاشده‌ست و ترافیکش از Azure رد می‌شه، تشخیصش با آنتی‌ویروس و ابزارهای شبکه تقریباً غیرممکنه.
• این ضعف توی Cursor 3.0 وصله شده و توصیه شده مخازن ناشناس محتاطانه باز بشن و اقدام‌های عامل قبل از تأیید بررسی بشن.