IPImen ، Firewall ، NGFirewall-UTM، آیپی ایمن، فایروال ایرانی ، فایروال بومی، یوتی ام بومی، یوتی ام ایرانی، فایروال نسل بعدی ایرانی، فایروال نسل بعدی بومی

نقص در GitHub Actions اسنوفلیک؛ یک Issue ساختگی می‌توانست به تزریق دستور منجر شود

اخبار داغ فناوری اطلاعات و امنیت شبکه

پژوهشگران امنیتی از افشای یک آسیب‌پذیری تازه در مخزن عمومی کانکتور دات‌نت شرکت اسنوفلیک روی گیت‌هاب خبر داده‌اند؛ نقصی از نوع تزریق ورک‌فلو (Workflow Injection) در GitHub Actions که به مهاجم امکان می‌داد صرفاً با ثبت یک Issue ساختگی، دستورات دلخواه خود را در محیط اجرای یک ورک‌فلو داخلی به اجرا درآورد و در نهایت به یک توکن معتبر Jira دسترسی پیدا کند.

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

این آسیب‌پذیری در فایل پیکربندی .github/workflows/jira_issue.yml از مخزن snowflakedb/snowflake-connector-net وجود داشت؛ ورک‌فلویی که با هر بار باز شدن یک Issue عمومی روی این مخزن، به‌طور خودکار اجرا می‌شد. مشکل اصلی اینجا بود که این ورک‌فلو، در همان مرحله‌ای که مقادیر حساسی مانند JIRA_BASE_URL، JIRA_USER_EMAIL و به‌ویژه JIRA_API_TOKEN را در اختیار داشت، عنوان و متن Issue را که کاملاً توسط کاربر (و در نتیجه مهاجم بالقوه) قابل کنترل بود، بدون هیچ پالایشی، مستقیماً درون یک بلوک اجرای شل (run:) قرار می‌داد.

به بیان ساده‌تر، هر کسی که می‌توانست یک Issue روی این مخزن عمومی باز کند، عملاً می‌توانست محتوای دلخواه خود را به‌عنوان بخشی از یک اسکریپت اجرایی با دسترسی به اطلاعات حساس، به سیستم تزریق کند.

نکته جالب‌توجه دیگر این بود که این ورک‌فلو تلاش کرده بود با بررسی مقدار github.event.pull_request.user.login جلوی اجرای غیرمجاز را بگیرد؛ اما از آنجا که رویداد محرک، از نوع «Issue» بود نه «Pull Request»، این ویژگی اساساً وجود خارجی نداشت. طبق مستندات رسمی گیت‌هاب، در چنین حالتی سیستم به‌جای بروز خطا، مقدار یک رشته خالی را بازمی‌گرداند. نتیجه این‌که مقایسه این مقدار خالی با نام حساب کاربری ربات مشخص‌شده (whitesource-for-github-com[bot]) هرگز برقرار نمی‌شد و همین موضوع باعث می‌شد یک Issue کاملاً عادی و بدون هیچ محدودیتی به مرحله اجرای دستورات برسد؛ درست برخلاف هدف اصلی این بررسی که قرار بود دسترسی را محدود کند.

نحوه کشف: از خطای نحوی تا یک Callback موفق

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

در نهایت، پژوهشگران یک Callback خارج از باند (Out-of-Band) از اجراکننده (Runner) گیت‌هاب اکشنز دریافت کردند و از این طریق موفق به دریافت توکن API سرویس Jira مورد استفاده در آن ورک‌فلو شدند.

به گفته Wiz، این توکن متعلق به یک حساب سرویس با آدرس این آدرس ایمیل توسط spambots حفاظت می شود. برای دیدن شما نیاز به جاوا اسکریپت دارید بود و دسترسی خواندن (Read) به چندین پروژه حساس در فضای Jira شرکت اسنوفلیک را فراهم می‌کرد؛ از جمله پروژه‌های مرتبط با تیم مهندسی، انطباق و امنیت (Security Compliance) و همچنین ردیابی گزارش‌های برنامه شکار باگ (Bug Bounty). جزئیات دقیق سطح دسترسی این توکن، گزارش کامل اجرای ورک‌فلو و لاگ‌های حسابرسی داخلی اسنوفلیک به‌صورت عمومی منتشر نشده‌اند.

واکنش اسنوفلیک و زمان‌بندی رفع مشکل

Wiz اعلام کرده این آسیب‌پذیری را در تاریخ ۲۳ ژوئن ۲۰۲۶ از طریق پلتفرم HackerOne و تحت شماره گزارش #3819931 به اسنوفلیک اطلاع داده است. شرکت اسنوفلیک نیز همان روز با ادغام یک Pull Request اصلاحی (شماره ۱۴۰۲)، مشکل را برطرف کرد؛ راهکاری که در آن به‌جای بسط مستقیم عبارات گیت‌هاب داخل اسکریپت شل، از متغیرهای محیطی (Environment Variables) استفاده شد که پیش از پردازش، به‌عنوان آرگومان به ابزار jq ارسال می‌شوند — روشی استاندارد برای جلوگیری از این دسته حملات.

بررسی تاریخچه مخزن نشان می‌دهد نسخه آسیب‌پذیر این ورک‌فلو، پنج روز پیش از افشا و کشف مشکل، یعنی در تاریخ ۱۸ ژوئن ۲۰۲۶، با ادغام Pull Request شماره ۱۲۱۸ وارد شاخه اصلی (Default Branch) مخزن شده بود. به این ترتیب، پنجره زمانی واقعی که این نقص روی شاخه اصلی و در معرض بهره‌برداری احتمالی قرار داشت، حدود پنج روز تخمین زده می‌شود.

اسنوفلیک در بیانیه‌ای که توسط Wiz بازنشر شده، اعلام کرده بررسی‌های داخلی این شرکت هیچ نشانه‌ای از دسترسی غیرمجاز پیدا نکرده است. Wiz نیز تأیید کرده توکن Jira مذکور در تاریخ ۲۴ ژوئن چرخانده (Rotate) شده و بررسی‌های اسنوفلیک نشان داده در طول پنجره پنج‌روزه افشا، هیچ استفاده خارجی و نامرتبطی از این توکن ثبت نشده است. با این حال، لاگ‌های حسابرسی زیربنایی اسنوفلیک همچنان به‌صورت عمومی در دسترس نیستند و تنها بر اساس اظهارات این شرکت قابل استناد است.

نقش مبهم Copilot در ماجرا

یکی از جنبه‌های بحث‌برانگیز این گزارش، ادعای Wiz درباره نقش ابزار GitHub Copilot Autofix در ایجاد این آسیب‌پذیری است. Wiz این نقص را ناشی از یک تغییر اعمال‌شده توسط Copilot Autofix توصیف کرده، هرچند بررسی دقیق‌تر تاریخچه کامیت‌های گیت‌هاب چنین ادعایی را به‌طور قطعی تأیید نمی‌کند.

بررسی‌ها نشان می‌دهد یک کامیت مشخص که به‌صراحت Copilot را به‌عنوان یکی از نویسندگان مشترک آن معرفی می‌کند، در واقع فایل دیگری به نام jira_close.yml را تغییر داده، نه فایل آسیب‌پذیر jira_issue.yml. بازنویسی ناامن این فایل اخیر، در یک کامیت جداگانه مربوط به ۲۵ اوت ۲۰۲۵ رخ داده که توسط سیستم گیت‌هاب به یک توسعه‌دهنده انسانی با نام کاربری sfc-gh-hpathak نسبت داده شده است.

با این حال، هر دو این تغییرات در نهایت طی یک عملیات ادغام فشرده (Squash Merge) در تاریخ ۱۸ ژوئن، در قالب یک کامیت واحد با یکدیگر ترکیب شدند؛ کامیتی که در فهرست نویسندگان مشترک خود، نام Copilot Autofix را نیز شامل می‌شود. به این ترتیب، تاریخچه کامیت‌ها تنها می‌تواند مشارکت کلی Copilot در کل فرایند Pull Request شماره ۱۲۱۸ را تأیید کند، اما اثبات نمی‌کند که این ابزار هوش مصنوعی، نویسنده مستقیم خطوط کد آسیب‌پذیر بوده است.

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

این نوع حمله تازه نیست

جالب اینجاست که گیت‌هاب از مدت‌ها پیش، دقیقاً همین دسته از آسیب‌پذیری‌های تزریق ورک‌فلو را به‌طور رسمی مستندسازی کرده است. این شرکت در جولای ۲۰۲۵ (بیش از یک سال پیش از این حادثه) طی مقاله‌ای هشدار داده بود که بسط مستقیم داده‌های غیرقابل‌اعتماد ورودی کاربر (مانند عنوان یا متن Issue) در داخل بلوک‌های run: می‌تواند خطرناک باشد و توصیه کرده بود توسعه‌دهندگان از متغیرهای محیطی میانی برای جداسازی داده‌های ورودی از منطق اجرایی اسکریپت استفاده کنند؛ دقیقاً همان راهکاری که اسنوفلیک در نهایت برای رفع این مشکل به کار برد.

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

وضعیت فعلی: بدون CVE رسمی و بدون شواهد بهره‌برداری مخرب

تا تاریخ ۱۷ اوت ۲۰۲۶، هیچ شناسه CVE، امتیاز CVSS یا ثبت در فهرست آسیب‌پذیری‌های شناخته‌شده مورد بهره‌برداری آژانس امنیت سایبری آمریکا (CISA KEV) برای این مشکل یافت نشده است. همچنین هیچ نسخه به‌روزرسانی‌شده‌ای از کانکتور دات‌نت اسنوفلیک که مستقیماً به این آسیب‌پذیری مرتبط باشد شناسایی نشده، چراکه این نقص صرفاً محدود به زیرساخت CI/CD و اتوماسیون داخلی مخزن بوده و هیچ نسخه منتشرشده‌ای از خود کانکتور Snowflake for .NET را تحت تأثیر قرار نداده است.

الگوی تزریق آسیب‌پذیر نیز دیگر در شاخه اصلی (Master) این مخزن وجود ندارد و مواد اولیه در دسترس عموم، هیچ شاهدی مبنی بر بهره‌برداری مخرب واقعی در دنیای بیرون یا نفوذ به سامانه‌های مشتریان اسنوفلیک ارائه نمی‌دهد. به بیان دیگر، این مورد تا این لحظه صرفاً در چارچوب یک آزمون امنیتی مجاز شناسایی و گزارش شده است.

چرا این حادثه اهمیت دارد؟

این ماجرا نمونه‌ای روشن از خطرات پنهان در خطوط لوله CI/CD مدرن است؛ جایی که ورک‌فلوهای خودکار اغلب به منابع بسیار حساسی مانند توکن‌های API، اطلاعات ورود سرویس‌های داخلی و کلیدهای رمزنگاری دسترسی دارند، اما گاهی بدون بررسی کافی، همان ورک‌فلوها به داده‌های کاملاً غیرقابل‌اعتماد و کنترل‌شده توسط کاربران خارجی (مانند عنوان یک Issue عمومی) نیز واکنش نشان می‌دهند.

این حادثه همچنین بار دیگر بر اهمیت جداسازی دقیق داده‌های ورودی کاربر از منطق اجرایی اسکریپت‌ها در محیط‌های CI/CD تأکید می‌کند؛ اصلی ساده اما حیاتی که نادیده گرفتن آن، حتی در پروژه‌های متن‌باز شرکت‌های بزرگ فناوری، می‌تواند به افشای اطلاعات حساس داخلی منجر شود.

توصیه‌های امنیتی برای تیم‌های توسعه

  • هرگز داده‌های ورودی کاربر (مانند عنوان یا متن Issue، نام شاخه، یا پیام Commit) را به‌طور مستقیم درون بلوک‌های run: در فایل‌های ورک‌فلو گیت‌هاب اکشنز قرار ندهید.
  • برای انتقال داده‌های بالقوه غیرقابل‌اعتماد، همواره از متغیرهای محیطی میانی استفاده کنید تا از تفسیر ناخواسته این داده‌ها به‌عنوان بخشی از دستورات اجرایی جلوگیری شود.
  • در بررسی شرایط اجرای ورک‌فلوها، از صحت وجود واقعی فیلدهای رویداد (Event Payload) که مورد استناد قرار می‌گیرند اطمینان حاصل کنید؛ ارجاع به فیلدی که در نوع رویداد فعلی وجود ندارد، می‌تواند به‌جای بروز خطا، به‌سادگی نادیده گرفته شود.
  • سطح دسترسی توکن‌ها و اسرار (Secrets) مورد استفاده در ورک‌فلوهای خودکار را به حداقل ممکن محدود کنید و در صورت افشای احتمالی، بلافاصله نسبت به چرخاندن (Rotation) آن‌ها اقدام کنید.
  • پروژه‌های متن‌باز و مخازن عمومی را به‌طور دوره‌ای از منظر امنیت پیکربندی گیت‌هاب اکشنز بازبینی کنید، به‌ویژه ورک‌فلوهایی که با رویدادهای قابل‌کنترل توسط کاربران خارجی (مانند باز شدن Issue یا ارسال Pull Request) فعال می‌شوند.

جمع‌بندی

این حادثه یک نمونه گویا از تهدیدات روزافزون در حوزه امنیت زنجیره تأمین نرم‌افزار و اتوماسیون CI/CD است؛ حوزه‌ای که با گسترش استفاده از ابزارهای هوش مصنوعی برای کدنویسی و رفع خودکار باگ‌ها، پیچیدگی‌های امنیتی تازه‌ای نیز به همراه آورده است. هرچند در این مورد خاص، شواهدی از بهره‌برداری مخرب یا نفوذ واقعی گزارش نشده و اسنوفلیک به‌سرعت نسبت به رفع مشکل و چرخاندن توکن افشاشده اقدام کرده، اما این ماجرا یادآوری مهمی است برای تمام تیم‌های توسعه: حتی یک خط پیکربندی ساده در یک فایل ورک‌فلو خودکار، در صورت طراحی نادرست، می‌تواند دروازه‌ای به‌سوی اطلاعات حساس‌ترین بخش‌های یک سازمان باز کند.

برچسب ها: Workflow Injection, امنیت_اطلاعات, امنیت_سایبری, Cyberattack, cybersecurity, news

نوشته شده توسط تیم خبر.

چاپ ایمیل