آسیب پذیری Rovo شرکت Atlassian؛ هکرها می توانند داده های Jira و Confluence را به سرقت ببرند

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

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

Rovo چگونه می تواند اطلاعات Jira و Confluence را افشا کند؟

شرکت امنیت هوش مصنوعی PromptArmor نشان داده است که مهاجم می تواند دستورهای مخرب را در محتوایی قرار دهد که Rovo آن را می خواند. در این سناریو، حتی یک فایل آپلودشده می تواند حاوی دستورهای مخفی باشد که دستیار را وادار می کند اطلاعات داخلی را جمع آوری کرده و از طریق یک درخواست URL به سرور مهاجم ارسال کند.

PromptArmor اعلام کرده است که این زنجیره در تاریخ ۵ اوت ۲۰۲۶ همچنان با غیرفعال بودن قابلیت جستجوی وب Rovo نیز قابل اجرا بوده است. با این حال، این بخش از یافته ها تنها توسط همین شرکت گزارش شده و وضعیت آن پس از این تاریخ به طور مستقل تایید نشده است.

در روش دیگری، Varonis Threat Labs دستورهای مخرب را داخل یک لینک قرار داده بود. این شرکت دریافت که پارامتر rovoChatPrompt می توانست دستور مهاجم را از طریق URL به Rovo Chat منتقل کند. در نتیجه، تنها با یک کلیک کاربر احراز هویت شده، Rovo می توانست دستور را با سطح دسترسی همان کاربر اجرا کرده و نتیجه را به سرور تحت کنترل مهاجم ارسال کند.

آسیب پذیری RovoBlast چگونه عمل می کرد؟

Varonis این آسیب پذیری را RovoBlast نامگذاری کرده و آن را از طریق Bugcrowd به Atlassian گزارش داده است. بر اساس سوابق منتشرشده، Atlassian این مشکل را در تاریخ ۸ ژوئیه ۲۰۲۶ در سمت سرور برطرف کرده و پژوهشگر نیز رفع مشکل را تایید کرده است.

در این حمله، پارامتر rovoChatPrompt می توانست یک دستور کامل را داخل URL مربوط به Rovo قرار دهد. نمونه آزمایشی به Rovo دستور می داد اطلاعاتی را که کاربر اجازه دسترسی به آن ها را دارد پیدا کرده، آن ها را در مسیر یک URL متعلق به مهاجم قرار داده و سپس یک تصویر از آن URL دریافت کند.

همین درخواست باعث می شد اطلاعات مورد نظر به سرور مهاجم منتقل شود.

پژوهشگر موفق شده بود با این روش یک کلید خصوصی API را از Confluence استخراج کند. آزمایش های انجام شده همچنین Jira و داده های قابل دسترسی از طریق اتصال های SharePoint و Outlook را نیز شامل می شد.

حمله از طریق فایل و Prompt Injection غیرمستقیم

روش شناسایی شده توسط PromptArmor نمونه ای از حمله Indirect Prompt Injection است. در این نوع حمله، مهاجم مستقیما دستور مخرب را به کاربر نمی دهد، بلکه آن را در محتوایی قرار می دهد که دستیار هوش مصنوعی قرار است آن را پردازش کند.

برای مثال، کاربر ممکن است یک فایل آلوده را در Rovo آپلود کرده و از آن بخواهد تیکت های Jira خود را مرتب کند. Rovo در جریان انجام این کار، محتوای مخفی موجود در فایل را نیز پردازش می کند.

در سناریوی آزمایش شده، Rovo اطلاعات Jira و Confluence را جمع آوری کرده، آن ها را به یک URL متعلق به مهاجم اضافه و درخواست را ارسال کرده است. در نتیجه، مهاجم می توانست اطلاعات سرقت شده را از طریق گزارش های سرور خود مشاهده کند.

نکته مهم این است که این حمله دقیقا یک حمله بدون تعامل کاربر محسوب نمی شود. قربانی همچنان باید محتوای آلوده را در اختیار Rovo قرار دهد و یک درخواست عادی از دستیار بخواهد. با این حال، مرحله ارسال اطلاعات به مهاجم نیازمند تایید جداگانه کاربر نیست.

غیرفعال کردن جستجوی وب نیز لزوما کافی نیست

یکی از نکات مهم یافته PromptArmor این است که غیرفعال کردن قابلیت Web Search در Rovo مانع اجرای کامل زنجیره حمله نمی شود.

دلیل این موضوع آن است که درخواست خروجی مهاجم از قابلیت دیگری برای دریافت URL استفاده می کند. بنابراین، حتی اگر سازمانی جستجوی وب Rovo را غیرفعال کرده باشد، این اقدام به تنهایی نمی تواند به عنوان یک مرز امنیتی کامل در برابر این نوع حمله در نظر گرفته شود.

ریشه مشکل این است که بررسی کافی انجام نمی شود تا مشخص شود URL مورد درخواست توسط چه کسی ساخته شده و آیا این URL بخشی از یک دستور مخرب است یا خیر.

Rovo چه سطحی از دسترسی به اطلاعات دارد؟

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

در واقع، مهاجم می تواند Rovo را وادار کند اطلاعاتی را که کاربر قربانی از قبل اجازه دسترسی به آن ها را دارد، جمع آوری و به خارج از سازمان ارسال کند.

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

سازمان ها چگونه می توانند دسترسی Rovo را محدود کنند؟

بر اساس مستندات Atlassian، Rovo به صورت پیش فرض برای برخی اپلیکیشن ها در پلن های Standard، Premium و Enterprise فعال است و کاربران سازمان می توانند از قابلیت های آن استفاده کنند.

با این حال، مدیران سازمان می توانند دسترسی Rovo را برای اپلیکیشن ها و گروه های کاربری محدود کنند. همچنین در محیط های Enterprise امکان مدیریت دسترسی Rovo بر اساس اپلیکیشن و گروه کاربری وجود دارد.

این موضوع به سازمان ها اجازه می دهد به جای فعال یا غیرفعال کردن کامل Rovo، دسترسی آن را برای بخش هایی که واقعا به این قابلیت نیاز دارند محدود کنند.

یک مشکل مهم در مدیریت دسترسی Rovo

Atlassian یک نکته مهم را نیز درباره محدود کردن Rovo در سایت هایی که چند اپلیکیشن Jira در آن ها فعال است مطرح کرده است. غیرفعال کردن Rovo برای تنها یکی از این اپلیکیشن ها لزوما تمام قابلیت های مشترک آن را از بین نمی برد.

قابلیت هایی مانند Rovo Search، Rovo Chat و Rovo Create تا زمانی که حداقل یکی از اپلیکیشن های Jira در همان سایت Rovo را فعال داشته باشد، می توانند در دسترس باقی بمانند.

آیا این آسیب پذیری ها CVE دارند؟

هیچ یک از دو آسیب پذیری گزارش شده دارای شناسه CVE نیستند. همچنین تا تاریخ ۸ اوت ۲۰۲۶، شناسه ای برای این مشکلات در پایگاه NVD یا فهرست آسیب پذیری های مورد سوءاستفاده شناخته شده CISA ثبت نشده است.

آسیب پذیری RovoBlast که از طریق پارامتر rovoChatPrompt مورد سوءاستفاده قرار می گرفت، در تاریخ ۸ ژوئیه توسط Atlassian در سمت سرور برطرف شده است و گزارش آن نیز به عنوان رفع شده ثبت شده است.

وضعیت مسیر حمله مبتنی بر محتوای آلوده

وضعیت مسیر دیگری که PromptArmor از طریق محتوای آلوده و Prompt Injection شناسایی کرده، همچنان کاملا مشخص نیست. PromptArmor هنگام انتشار گزارش خود در ۵ اوت اعلام کرده بود که این مسیر همچنان قابل استفاده است.

با این حال، از آنجا که یک ماه قبل از انتشار این گزارش، Atlassian یک اصلاحیه سمت سرور برای آسیب پذیری RovoBlast منتشر کرده بود، مشخص نیست این تغییر تا چه اندازه مسیر حمله مبتنی بر محتوای آلوده را نیز تحت تاثیر قرار داده است.

همچنین تاکنون هیچ مدرکی منتشر نشده است که نشان دهد این دو روش علیه یک سازمان واقعی مورد استفاده قرار گرفته اند. این موضوع به معنای غیرممکن بودن چنین حملاتی نیست، بلکه تنها نشان می دهد گزارش های منتشرشده تاکنون شواهدی از سوءاستفاده واقعی ارائه نکرده اند.

چگونه خطر سرقت اطلاعات از Rovo را کاهش دهیم؟

سازمان هایی که از Rovo استفاده می کنند باید مشخص کنند کدام اپلیکیشن ها و گروه های کاربری واقعا به این دستیار نیاز دارند و دسترسی آن را تا حد امکان محدود کنند.

همچنین باید مجوزهای کاربران و دامنه دسترسی اتصال های شخص ثالث به دقت بررسی شود. صرفا غیرفعال کردن قابلیت جستجوی وب نیز نباید به عنوان یک راهکار امنیتی کامل در نظر گرفته شود.

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