حذف سه ورک فلو هوش مصنوعی گوگل پس از کشف حفره خطرناک در گیت هاب؛ آیا ایجنت های هوشمند دسترسی های امنیتی شما را تهدید می کنند؟

مداخله گوگل و حذف جریان های کاری هوش مصنوعی از ریپازیتوری ADK

به گزارش زوم تک از هکر نیوز، شرکت گوگل به تازگی سه جریان کاری (Workflow) مربوط به ایجنت های هوش مصنوعی را از مخزن گیت هاب کیت توسعه ایجنت (ADK) پایتون خود حذف کرده است. این اقدام پس از آن صورت گرفت که پژوهشگران شرکت امنیتی پیلار (Pillar Security) نشان دادند چگونه یک ایشوی (Issue) عمومی و عادی در گیت هاب می تواند یک ایجنت بررسی کننده و مرتب ساز را دستکاری کرده و در نهایت باعث تحریک و اجرای یک ایجنت ارشد و دارای دسترسی های ویژه برای اصلاح کدها شود.

مکانیزم حمله و نحوه سوءاستفاده از هویت ربات های مورد اعتماد

پژوهشگران امنیتی توضیح دادند که ایجنت عمومی موجود در این سیستم می توانست از طریق تزریق پرامپت (Prompt Injection) ترغیب شود تا دستوری مانند adk-issue-fix/ را از طرف حساب ربات adk-bot ارسال کند. از آنجایی که این ربات به عنوان یک همکار (Collaborator) در سیستم شناسایی شده بود، کامنت ارسال شده توسط آن توانست دروازه های امنیتی مربوط به مالک، عضو یا همکار در جریان کاری دارای دسترسی بالا را رد کند. به این ترتیب، هویت مورد اعتماد ربات به یک پل عبور برای احراز هویت و سوءاستفاده تبدیل شد.

اجرای کد مخرب و افشای کلیدهای حساس گوگل کلود

تیم تحقیقاتی پیلار موفق شد اجرای کد خودخواهانه (Arbitrary Code Execution) را روی رانر ادغام مداوم (CI) به اثبات برساند و توکن دسترسی شخصی (PAT) ربات را استخراج کند. نکته نگران کننده تر این است که وظیفه کاری دارای دسترسی بالا، کلید API گوگل و همچنین اعتبارنامه حساب سرویس گوگل کلود را نیز در اختیار داشت. البته حملات اثبات مفهوم ارائه شده توسط پژوهشگران، هیچ گونه سوءاستفاده فعال در دنیای واقعی یا آلوده شدن نسخه های رسمی ADK را نشان نمی دهد.

تشخیص منشاء آسیب پذیری و توصیه های امنیتی به توسعه دهندگان

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

پیگیری های رسانه ای و پاسخ مبهم طرفین پرونده

رسانه هکر نیوز برای دریافت جزئیات بیشتر درباره دامنه دسترسی های توکن ربات، مجوزهای حساب سرویس و شواهد سوءاستفاده، با گوگل تماس گرفته است. همچنین این رسانه سوالاتی را از شرکت پیلار سکوریتی درباره محیط اثبات مفهوم و نحوه دسترسی به اعتبارنامه ها مطرح کرده است. تا زمان انتشار این خبر، پاسخ رسمی هر دو طرف معلق بوده است.

جزییات مسیر حمله در پرونده های یمل گیت هاب

مسیر این حمله از جریان کاری عمومی issue-analyze.yml آغاز می شد که به صورت خودکار با باز شدن هر ایشوی جدید اجرا می گردید. این فایل با کلید ADK_GCP_SA_KEY احراز هویت کرده و متغیرهای ADK_TRIAGE_AGENT و GOOGLE_API_KEY را به ایجنت کدنویسی آنتی گراویتی گوگل ارائه می داد و سپس تحلیل تولید شده را با حساب ربات کامنت می کرد. در سوی دیگر، یک جریان کاری جداگانه به نام issue-fix.yml منتظر کامنت های adk-issue-fix/ می ماند و اجرای آن را تنها به مالک، عضو یا همکار محدود می کرد. اشکال اصلی اینجا بود که دروازه امنیتی فقط فرد ارسال کننده دستور را بررسی می کرد، نه اینکه آیا یک فرد خارجی حساب مورد اعتماد را دستکاری کرده است یا خیر.

اختیارات کامل فایل های ادغام و تفاوت توکن ها

وظیفه دارای دسترسی بالا، مجوز دسترسی نوشتن برای ایشوها، محتوای مخزن و درخواست های pull را اعلام کرده بود. البته این تنظیمات روی توکن خودکار گیت هاب (GITHUB_TOKEN) اعمال می شد، نه روی توکن دسترسی شخصی ADK_TRIAGE_AGENT که این وظیفه عملاً از آن استفاده می نمود.

سناریوی تغییر کدهای مخزن و ساخت شاخه های جدید

پژوهشگران پیلار اعلام کردند که دامنه دقیق توکن دسترسی شخصی به صورت عمومی مشخص نیست. این وظیفه کاری، مخزن را با توکن دسترسی فراخوانی می کرد، در گوگل کلود احراز هویت می شد و ایجنت را با توکن و کلید API در محیط خود اجرا می نمود. طراحی این جریان کاری به گونه ای بود که می توانست کدها را ویرایش کند، یک فورک از adk-bot بسازد، شاخه ای را پوش کند و یک pull request ایجاد نماید. یک درخواست pull ثبت شده از ۴ ژوئن نشان می دهد که این اتوماسیون در مخزن فعال بوده است.

دور زدن محدودیت های متادیتا و اجرای دستورات گیت

سیستم رانر کاراکترهای ویژه شل را رد می کرد و تنها به دستوراتی اجازه اجرا می داد که اولین توکن آن ها gh یا git باشد. اما اسکریپت مربوطه گزینه CapabilitiesConfig() را فعال کرده بود که طبق مستندات نرم افزاری آنتی گراویتی گوگل، تمام ابزارها از جمله ابزارهای نوشتن را روشن می کرد. بنابراین ایجنت می توانست یک بارهسته (Payload) بنویسد و باعث شود یک دستور مجاز گیت آن را از طریق مسیر قلاب (Hook) سفارشی اجرا کند. مستندات گیت تایید می کند که قلاب ها برنامه های قابل اجرا هستند و core.hooksPath می تواند گیت را به دایرکتوری دیگری هدایت کند. محدودسازی دستورات اگرچه ساختار را تنگ تر کرد، اما نوشتن فایل همچنان راه را برای اجرای کد باز می گذاشت.

ابهام در میزان دسترسی های عمیق تر به پروژه های ابری

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

آسیب پذیری های گذشته و بررسی نهایی حذف فایل ها

این گزارش همچنین به یک زنجیره قبلی اشاره کرد که می توانست از طریق جریان های کاری دارای دسترسی جمینای، یک مسیر بررسی کاذب ایجاد کند، اما در آن حالت نیز یک نگهبان مخزن باید درخواست ادغام را تایید می کرد. در نهایت، کامیت حذف گوگل بیان می کند که این جریان های کاری محتوای غیرقابل اعتماد ایشو و pull request را با اعتبارنامه های گسترده پردازش می کردند. گوگل فایل های issue-analyze.yml، issue-fix.yml و pr-analyze.yml را در پچی با متادیتای ۹ ژوئن ۲۰۲۶ حذف کرد. پیلار تایید کرد که عدم وجود این فایل ها را در ۲ ژوئیه راستی آزمایی کرده و گوگل نیز در ۲۱ ژوئیه اصلاح مشکل را تایید نموده است. بررسی هکر نیوز در ۴ اوت ۲۰۲۶ نشان داد که هیچ یک از این سه فایل در دایرکتوری فعال شاخه اصلی مخزن وجود ندارند.