Orca Security، شرکت تحلیل امنیت ابری، اعلام کرده است که پیکربندی‌های Visual Studio Code که به‌طور خودکار در محیط توسعه ابری GitHub Codespaces اجرا می‌شوند، می‌توانند بردار سوءاستفاده قابل توجهی برای مهاجمان فراهم کنند و توسعه‌دهندگان، سازمان‌ها و زنجیرهٔ تأمین نرم‌افزار را در معرض حملات قرار دهند. این رفتار در طراحی Codespaces تعبیه شده و اکنون به‌عنوان یک تهدید بالقوه امنیتی برجسته شناخته شده است.

---

پیش زمینه: GitHub Codespaces چیست؟

GitHub Codespaces یک محیط توسعه یکپارچه مبتنی بر ابر است که به توسعه‌دهندگان امکان می‌دهد با استفاده از Visual Studio Code در فضای ابری و بدون پیکربندی محلی، روی پروژه‌ها کار کنند. Codespaces بر پایه‌ی کانتینرهای لینوکسی (معمولاً Ubuntu) اجرا می‌شود و ادغام عمیقی با GitHub دارد، از جمله دسترسی به ریپازیتوری‌ها، بررسی Pull Requestها و مدیریت توسعه.

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

---

سناریوی حمله قدم‌به‌قدم

طبق تحلیل Orca، حمله می‌تواند به این شکل رخ دهد:

1. فورسک و مخرب‌سازی ریپازیتوری: مهاجم یک ریپازیتوری عمومی یا فورک‌شده ایجاد می‌کند و در مسیر .vscode/ یا در فایل‌های پیکربندی Dev Container (devcontainer.json) دستورات مخرب قرار می‌دهد.

2. پوشه‌های پیکربندی اجرا می‌شوند: زمانی که یک توسعه‌دهنده یا نگه‌دارنده (maintainer) این ریپازیتوری یا یک Pull Request را در Codespaces باز می‌کند، پیکربندی‌های VS Code به‌طور خودکار اجرا می‌شوند، بدون اینکه کاربر به‌صورت صریح اجازه اجرا را بدهد.

3. اجرای دستورات مخرب در کانتینر: فایل‌های JSON می‌توانند متغیرهای ترمینال تنظیم کنند تا دستورات (shell commands) در محیط Bash اجرا شوند. بدین ترتیب مهاجم می‌تواند کد دلخواه را روی کانتینر اجرا کند.

4. دست‌یابی به توکن‌ها و Secrets: این دستورات مخرب می‌توانند منجر به سرقت توکن‌های GitHub، پنهان‌سازی Secrets و دیگر داده‌های حساس شوند.

5. بهره‌برداری از توکن‌های سرقت‌شده: مهاجم قادر خواهد بود با توکن‌های لو رفته به عملیات خواندن/نوشتن در ریپازیتوری‌ها بپردازد، Pull Requestهای مخرب ارسال کند، یا حتی در حملات زنجیره‌تأمین نرم‌افزار به‌عنوان نگه‌دارنده مشروع وارد شود.

---

تحلیل فنی عمیق‌تر: چرا این اتفاق می‌افتد؟

در محیط‌های توسعه سنتی، پیکربندی‌های IDE فقط روی سیستم محلی توسعه‌دهنده اجرا می‌شوند و باید تایید کاربر را بگیرند. اما در Codespaces، ادغام پیش‌فرض با ریپازیتوری و اجرای خودکار پیکربندی‌ها به‌منظور سرعت‌بخشی به کار توسعه، باعث می‌شود که مهاجم بتواند پیکربندی مخرب را از راه دور اعمال کند – بدون هیچ تعامل مستقیم انسانی (zero-click or minimal interaction).

Use of configuration files like .vscode/settings.json و devcontainer.json به‌گونه‌ای است که به‌طور خودکار اعمال می‌شوند تا محیط توسعه برای توسعه‌دهنده آماده شود، اما همین سازوکار بردار اجرای کد مخرب از راه دور (RCE) را فراهم می‌آورد.

---

پیامدهای عملیاتی برای سازمان‌ها

توسعه‌دهندگان، تیم‌های DevOps و امنیت باید بدانند که این آسیب‌پذیری می‌تواند در قالب‌های مختلف مورد سوءاستفاده قرار گیرد:

• زنجیره‌تأمین نرم‌افزار (Software Supply Chain): مهاجم می‌تواند با استفاده از ریپازیتوری‌های عمومی یا فورک‌ها، کد مخرب را وارد چرخه توسعه نرم‌افزار کند، به‌گونه‌ای که نگه‌دارندگان اصلی آن را اجرا کنند و سپس کنترل ریپازیتوری را به دست بگیرند.

• استفاده از APIهای مخفی (undocumented APIs): Orca اشاره کرده است که مهاجم می‌تواند از توکن‌های لو رفته برای استفاده از APIهای مخفی GitHub جهت فراخوانی مدل‌های هوش مصنوعی پولی به نام‌های غیرمستند استفاده کند، که می‌تواند هزینه‌های مالی غیرمنتظره ایجاد کند.

• پیشنهاد توسعهٔ مخرب (Malicious Pull Requests): مهاجم می‌تواند با توکن سرقت‌شده، به‌عنوان نگه‌دارنده مشروع تغییرات را اعمال کند یا Pull Requestهای مخرب ایجاد نماید که به سرعت در جامعه انتشار یابند.

---

چه کسانی در بیشترین خطر هستند؟

گروه‌های زیر باید در اولویت رسیدگی به این آسیب‌پذیری قرار بگیرند:

???? توسعه‌دهندگان و نگه‌دارندگان ریپازیتوری‌های عمومی – به‌ویژه آنهایی که از Codespaces برای مرج Pull Requestها استفاده می‌کنند.
???? تیم‌های DevOps و SRE – باید سیاست‌های جدید برای بازبینی پیکربندی‌های VS Code تدوین کنند.
???? مدیران امنیت (Security Architects / SOC) – باید پایش دقیق (monitoring) و هشداردهی برای هر اجرای کانتینرهای مخرب در Codespaces را راه‌اندازی کنند.
???? سازمان‌های متن باز با مشارکت بالا – چون Pull Requestهای فراوان و مشارکت‌های متعدد می‌تواند سطح حمله را افزایش دهد.

---

راهکارهای کاهش ریسک (Immediate Mitigations)

در شرایطی که GitHub اعلام کرده این رفتار به‌طور طراحی انجام شده است، راهکارهای زیر می‌تواند ریسک را کاهش دهد:

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

2. پایش و هشداردهی (Monitoring & EDR): راه‌اندازی ابزارهای نظارتی که اجرای JSONهای پیکربندی را بررسی و لاگ‌های مشکوک را برجسته کنند.

3. اجبار به بررسی دستی Pull Requestها: به‌ویژه برای پروژه‌های حساس، قبل از باز کردن آن در Codespaces، کد پیکربندی باید مرور شود.

4. محدود کردن استفاده از توکن‌های با دسترسی بالا: استفاده از توکن‌های Scoped و کوتاه‌مدت که در صورت سرقت فایدهٔ کمتری برای مهاجم دارند.

5. آموزش توسعه‌دهندگان: آگاه‌سازی تیم Dev دربارهٔ اینکه فایل‌های پیکربندی می‌توانند بردار حمله باشند و چگونه آنها را امن مدیریت کنند.