حمله زنجیره ای از Gainsight به Salesforce و نشت داده ها

تحلیل مفصل حمله زنجیره‌ای که از طریق Gainsight به Salesforce انجام شد؛ نحوه سوءاستفاده از توکن‌ها، واکنش شرکت‌ها، پیامدهای فنی و اقدام‌های پیشنهادی برای کاهش ریسک و جلوگیری از نشت داده‌های سازمانی.

5 نظرات
حمله زنجیره ای از Gainsight به Salesforce و نشت داده ها

8 دقیقه

گوگل تأیید کرده آن‌چه پژوهشگران امنیتی نگرانش بودند: یک حمله زنجیره‌ای که از طریق اپلیکیشن‌های Gainsight آغاز شد، منجر به سرقت گسترده داده‌ها از سامانه‌های Salesforce شده است و بیش از 200 شرکت جهانی احتمالاً تحت تأثیر قرار گرفته‌اند. اکنون جزئیات جدیدی دربارهٔ نحوه انتقال مهاجمان از یک اپلیکیشن ثالث به سوابق سازمانی در حال آشکار شدن است.

چگونه حمله رخ داد

بر اساس گزارش‌ها و بیانیه‌های منتشرشده توسط فروشندگان آسیب‌دیده، نفوذ از طریق Gainsight — ابزار محبوب مدیریت موفقیت مشتری و یکپارچه‌سازی — آغاز شد و به مهاجمان اجازه داد به داده‌هایی که در نمونه‌های (instances) Salesforce ذخیره شده بود دسترسی پیدا کنند. به نظر می‌رسد مهاجمان از توکن‌های احراز هویتی که در نقض‌های قبلی در اختیار گرفته بودند سوءاستفاده کرده و به این ترتیب توانسته‌اند خود را به‌عنوان یکپارچگی‌ها (integrations) جا بزنند و داده‌ها را از سازمان‌های متصل Salesforce دانلود کنند.

مکانیزم اولیه نفوذ

طبق تحلیل‌های اولیه، سناریوی حمله یک مسیر چند مرحله‌ای داشته است: ابتدا از طریق نقض امنیتی در یک یا چند مشتری ثالث، توکن‌های دسترسی یا اطلاعات جلسه به سرقت رفته است. سپس مهاجمان با استفاده از آن توکن‌ها به سرویس‌های یکپارچه‌ساز مانند Gainsight وارد شده‌اند و از دیدگاه یکپارچه‌ها به سازمان‌های متصل Salesforce دسترسی پیدا کرده‌اند. این مدل نشان می‌دهد که حملات زنجیره‌ای (supply-chain attacks) چگونه می‌توانند از یک نقطه ضعف در اکوسیستم نرم‌افزاری به نفوذهای گسترده‌تر در سطح سازمان‌ها منجر شوند، حتی اگر خود پلتفرم مرکزی مانند Salesforce در هستهٔ سرویس خود آسیب‌پذیر نباشد.

نقش توکن‌های احراز هویت و مجوزها

توکن‌های احراز هویت (authentication tokens) در بسیاری از سناریوهای یکپارچه‌سازی و API محور نقش کلیدی دارند. اگر این توکن‌ها به دست افراد مخرب بیفتد یا مدت‌های طولانی بدون گردش (rotate) باقی بمانند، مهاجمان می‌توانند از آن‌ها برای impersonation (جایگزینی هویت) استفاده کنند و درخواست‌های معتبر به APIها ارسال کنند. در این حادثه، گزارش‌ها اشاره دارند که توکن‌هایی که از نقض‌های قبلی به‌دست آمده بودند — از جمله موارد مرتبط با Salesloft و Drift — به مهاجمان کمک کرد تا به Gainsight و سپس به سازمان‌های متصل در Salesforce دسترسی پیدا کنند.

تحلیل زنجیره‌ای و پیامدهای فنی

تحلیل تکنیکی این حادثه نشان می‌دهد که هرگاه یک اپلیکیشن ثالث با سطوح دسترسی گسترده به داده‌های مشتریان متصل می‌شود، نبود مدیریت چرخهٔ عمر توکن، عدم محدودسازی مجوزها (least privilege)، و فقدان مانیتورینگ دقیق فعالیت API می‌تواند موجب افزایش شعاع آسیب (blast radius) شود. نکات فنی مهم برای تحلیلگران و تیم‌های امنیتی عبارت‌اند از:

  • بررسی تاریخچهٔ صدور و استفاده از توکن‌ها و کلیدهای API برای شناسایی استفاده‌های غیرمعمول.
  • اعمال اصل حداقلی‌سازی دسترسی (least-privilege) برای اتصالات یکپارچه‌سازها.
  • راه‌اندازی سیستم‌های تشخیص رفتار غیرعادی در سطح API و دانلودهای حجیم یا الگوهای درخواست غیرعادی.
  • پیاده‌سازی گردش منظم توکن‌ها و لغو (revoke) دسترسی‌های قدیمی یا نامستخدم.

این رویکردها بخشی از بهترین شیوه‌های امنیتی برای کاهش ریسک نشت داده‌ها در اکوسیستم‌های SaaS و بخصوص برای پلتفرم‌هایی مانند Salesforce هستند.

TechCrunch و برخی رسانه‌های دیگر گزارش داده‌اند که گروهی با نام Scattered Lapsus$ Hunters که شامل اعضایی از ShinyHunters و تیم‌های دیگر است، مسئولیت این نفوذ را بر عهده گرفته‌اند. در گفتگوهایی که با رسانه‌ها انجام شده، ShinyHunters گفته‌اند آن‌ها از دسترسی‌هایی که در نتیجهٔ نقض قبلی مشتریان Salesloft به‌دست آمده و همچنین توکن‌های سرقت‌شده از Drift استفاده کرده‌اند تا به Gainsight و از آنجا به Salesforce دسترسی پیدا کنند.

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

چه شرکت‌هایی نام برده شدند و چه کسانی آن را تکذیب کردند

گروه Scattered Lapsus$ Hunters فهرستی از شرکت‌های برجسته را به‌عنوان قربانیان احتمالی منتشر کرده که در میان آن‌ها نام‌هایی چون Atlassian, CrowdStrike, DocuSign و LinkedIn دیده می‌شود. برخی از این شرکت‌ها بلافاصله واکنش نشان داده و اعلام کرده‌اند که شواهدی از خارج راندن داده‌ها (data exfiltration) از سیستم‌های خود نیافته‌اند.

واکنش شرکت‌ها و تکذیب‌ها

به‌عنوان مثال، CrowdStrike و DocuSign اعلام کرده‌اند که تاکنون مدرکی دال بر خروج داده‌ها از زیرساخت‌هایشان پیدا نکرده‌اند. CrowdStrike همچنین فاش کرد که یک کارمند را که گمان می‌رفت با مهاجمان همکاری داشته، اخراج کرده است. این نوع واکنش‌ها نشان‌دهندهٔ این است که سازمان‌ها باید هم به جنبه‌های فنی و هم به مدیریت داخلی و بررسی همکاری‌های احتمالی کارکنان با خارج توجه کنند.

تحقیقات جاری و پاسخ‌های متغیر

سایر سازمان‌ها مانند Verizon, Malwarebytes و Thomson Reuters اعلام کرده‌اند که ادعاها را مورد بررسی قرار می‌دهند اما نتایج قطعی را هنوز منتشر نکرده‌اند. پاسخ‌های متفاوت و گاهی متناقض شرکت‌ها بر عدم قطعیت پس از وقوع نقض‌هایی با ماهیت زنجیرهٔ تأمین دلالت دارد؛ جایی که ادعاهای عمومی ممکن است سریع‌تر از نتایج تحقیقات forensic منتشر شوند.

Gainsight در همکاری با تیم‌های پاسخ به حادثه از جمله Mandiant در حال ردیابی ریشهٔ مشکل است و Salesforce به عنوان اقدامی احتیاطی توکن‌های یکپارچه‌سازی مرتبط با Gainsight را موقتاً غیرفعال کرده تا تحقیقات ادامه پیدا کند.

پیامدها برای سازمان‌ها و اقدامات پیشنهادی

برای شرکت‌ها و سازمان‌های بزرگ، این رویداد یادآور نیاز به بازبینی دقیق اتصال اپلیکیشن‌های ثالث، گردش (rotate) و لغو توکن‌های قدیمی، و پایش الگوهای دسترسی برای شناسایی دانلودهای غیرمعمول یا رفتارهای نابهنجار در API است. در ادامه فهرستی از اقدامات عملی و دقیق‌تر ارائه شده که تیم‌های امنیتی و مهندسی باید مد نظر داشته باشند:

  1. بازبینی کامل لیست اپلیکیشن‌های ثالث متصل به مثلاً Salesforce و ارزیابی سطح دسترسی هر یک.
  2. اعمال سیاست گردش کلید و توکن به‌صورت خودکار و تعریف عمر مفید (TTL) برای توکن‌ها.
  3. اجرای مانیتورینگ و هشداردهی بر مبنای رفتار (behavioral analytics) برای شناسایی الگوهای غیرعادی دانلود یا درخواست API.
  4. اجرای اصل حداقل دسترسی (RBAC یا policy-based access control) و جلوگیری از صدور مجوزهای بیش از حد به اپلیکیشن‌ها.
  5. انجام تست‌های نفوذ ترکیبی و بررسی راه‌های حمله زنجیره‌ای (supply-chain penetration testing).
  6. هماهنگی با تیم‌های پاسخ به حادثه و داشتن برنامه‌های آماده برای واکنش سریع و اطلاع‌رسانی دقیق به مشتریان در صورت مشاهدهٔ نشتی.

وقتی یکپارچگی‌ها (integrations) تحت تأثیر قرار می‌گیرند، شعاع آسیب می‌تواند بسیار فراتر از یک فروشنده باشد و اغلب لازم است که تأییدیه از چند تیم مستقل و تحقیق forensic قبل از روشن شدن کامل دامنهٔ حادثه دریافت شود.

در نهایت، این رخداد تأکید می‌کند که محافظت از زنجیرهٔ تأمین نرم‌افزاری، مدیریت توکن و تحلیل رفتاری API از عناصر حیاتی امنیت در محیط‌های مبتنی بر سرویس‌های ابری (cloud services) و پلتفرم‌های CRM مانند Salesforce است.

نکات پایانی در زمینهٔ امنیت و آمادگی

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

همچنین توصیه می‌شود تیم‌های امنیتی از اطلاعات تهدید (threat intelligence) استفاده کنند تا گروه‌های مهاجم، زیرساخت‌های مرتبط و شاخص‌های سازگاری (IOCs) را شناسایی و به‌روزرسانی نمایند. ترکیب تحلیل داخلی با خدمات پاسخ‌دهی مستقل مانند Mandiant می‌تواند سرعت و دقت واکنش به حادثه را به‌طور قابل‌ملاحظه‌ای افزایش دهد.

منبع: smarti

ارسال نظر

نظرات

سیتی‌لین

خلاصه: از اپ ها شروع میشه، بعد زنجیره می‌سوزه. شرکتا لطفا گردش توکن، least privilege و فورنسیک رو جدی بگیرن 😬

لابکور

شاید رسانه‌ها دارن بزرگش میکنن، ولی نکته حقه: مدیریت توکن واقعا حیاته، آموزش داخلی لازمه

توربو

تو کارم دیدم یکی از این اینتگریشن‌ها باعث فاجعه شد مانیتورینگ ضعیف بود، عجله نکنید

کوینپایل

این ادعاها رو کی تایید کرده؟ بعضی شرکت‌ها تکذیب کردن، هنوز خیلی چیزها نامعلومه

دیتاپالس

وای، یعنی از یه اپ ثالث همه‌چیز می‌پره؟ توکن‌ها رو باید هر ماه بچرخونن، واقعاً نگران‌کننده‌ست.

مطالب مرتبط