حمله به Cadence؛ جتبرینز سرورش را بهموقع وصله نکرد
مهاجمان با بهرهجویی از آسیبپذیری بحرانی CVE-2026-63077 در TeamCity به سرور سرویس ابری Cadence نفوذ کردند. نتیجه این نفوذ: استخراج پشتیبان کامل، اعتبارنامهها و دادههای حساس. کاربران باید کلیدها را تعویض کرده و هر اجرای قبلی در بازهٔ متاثر را غیرقابلاعتماد بدانند.
جریان زمانی حمله
- 27 ژوئیه: جتبرینز عمومیسازی آسیبپذیری CVE-2026-63077 در TeamCity را اعلام کرد. این نقص امکان اجرای دستور دلخواه از طریق HTTP/HTTPS را بدون احراز هویت با امتیازات فرآیند TeamCity فراهم میکرد (TeamCity - ویکیپدیا).
- 7 اوت: گزارشهایی منتشر شد که مهاجمان در حال بهرهبرداری از سرورهای وصلهنشده TeamCity هستند.
- 8 اوت تا 24 اوت: بررسیهای داخلی جتبرینز نشان داد فعالیت مخرب روی سرور
api.cadence.jetbrains.comاز 8 اوت آغاز و تا 24 اوت ادامه داشته است. - 23 اوت: جتبرینز تشخیص نفوذ را اعلام کرد؛ سرور روز بعد آفلاین شد اما مهاجمان پیش از آن دادهها را استخراج کرده بودند.
اطلاعات افشا شده
جتبرینز میگوید مهاجمان به یک پشتیبان کامل Cadence از سال 2024 دسترسی یافتهاند که شامل اعتبارنامهها، فایلهای پیکربندی، آرشیوها و لاگها بوده است. موارد قابلتأمل عبارتاند از:
- دسترسی به چندین کاربر IAM و کلیدهای مرتبط در حسابهای AWS متعلق به جتبرینز.
- فایلها در باکتهای S3 مورد دسترسی قرار گرفتهاند؛ بررسی ادامه دارد تا مشخص شود آیا باکتهای مشتریان نیز تحت تأثیر بودهاند یا خیر.
- توسعهدهندگانی که از پلاگین Cadence در PyCharm استفاده کردهاند ممکن است پیش از اجرا فایلهای پروژه را همگامسازی کرده باشند؛ بنابراین کد منبع، پیکربندیها و هرگونه اعتبارنامه داخل پروژهها احتمالاً افشا شدهاند.
- اطلاعات هویتی شامل نامکاربری، نام واقعی، ایمیل، زمان آخرین ورود و آدرس IP آخرین دسترسی نیز در دسترس مهاجمان قرار گرفته است.
پیامدها برای زنجیره تأمین نرمافزار
دسترسی به اعتبارنامههای رجیستری و توکنهای انتشار میتواند منجر به انتشار بستههای مخرب و آلودهسازی زنجیرهٔ تأمین شود؛ سناریویی که قبلاً در حملات حوزه npm و دیگر اکوسیستمها دیده شده است. باید بررسی کرد آیا بستهها یا ایمیجهای کانتینری با استفاده از اعتبارنامههای افشا شده منتشر شدهاند.
دستورالعمل فوری برای کاربران Cadence
جتبرینز توصیه کرده هر اجرای متاثر یا هر چیزی که در پشتیبانها وجود دارد را بهعنوان بهخطر افتاده در نظر بگیرید. اقدامات عملی و ضروری به شرح زیر است:
- تعویض فوری کلیدها و توکنهای AWS، Azure، Google Cloud و کلیدهای IAM مرتبط.
- بازنشانی و ریویوک توکنهای GitHub، GitLab، Bitbucket و توکنهای CI/CD.
- تعویض اعتبارنامههای رجیستری بستهها (npm، Maven، NuGet، PyPI) و رجیستریهای کانتینر (Docker Hub، ECR، GCR، ACR).
- بررسی لاگهای CI/CD و حسابرسی مخازن برای دانلودها یا کلونهای غیرمعمول، تغییرات در وبهوکها و نشت اسرار.
- بازبینی دقیق دسترسیهای IAM، شناسایی حسابهای سرویس جدید و کنترل تغییرات سطح دسترسی به باکتهای S3 و سایر منابع ذخیرهسازی.
- کنترل انتشار بستهها: بررسی انتشارهای اخیر با اعتبارنامههای مربوطه و واکنش سریع برای حذف یا بازگردانی نسخههای مخرب.
چرا این حادثه هشداردهنده است؟
حادثه هنگامی خطرناکتر میشود که خود ارائهدهندهٔ ابزار توسعه نتواند زیرساختهایش را بهسرعت وصله کند. سیستمهای CI/CD و سرویسهای اجرای از راه دور به اسرار دسترسی دارند و در صورت نفوذ میتوانند سکوی حرکت جانبی برای دسترسی به منابع دیگر شوند.
اقدامات پیشگیرانه بلندمدت
- پایدارسازی سیاستهای مدیریت وصله و پیادهسازی فرآیندهای خودکار برای بهروزرسانی سرویسهای حیاتی.
- اجرای اصل حداقل امتیاز، جداسازی محیطها و محدودسازی دسترسی سرویسها به منابع فقط در موارد ضروری.
- نهادینهسازی بررسیهای زنجیرهتأمین نرمافزار و استفاده از امضای انتشار برای بستهها و ایمیجهای کانتینر.
- راهاندازی روالهای منظم تست و بازیابی (DR) و سناریوهای واکنش به رخداد برای محیطهای CI/CD و سرویسهای ابری.
نتیجهگیری روشن است: حتی ارائهدهندگان ابزار توسعه نباید به امنیت زیرساختهای خود اعتماد مطلق کنند. تیمهای توسعه و امنیت باید فرض کنند هر محیط اجرای از راه دور ممکن است دستکاری شده باشد و برنامههای واکنش، تعویض کلید و بازیابی را همواره آماده نگه دارند.





