کد خبر: ۱۱۰۹

۰۸:۳۷

۱۴۰۵/۰۶/۳۰

هک زنجیره تأمین Brevo؛ یک کلید API قدیمی چگونه بیش از ۱۰۰ هزار سایت را در معرض بدافزار قرار داد؟

حمله زنجیره تأمین Brevo با سوءاستفاده از یک Cloudflare API Key، کد مخرب را به سایت‌های مشتریان تزریق کرد؛ بررسی Sansec از تأثیر احتمالی بر بیش از ۱۰۰ هزار سایت خبر می‌دهد.

نویسنده:

بهراد یوسفی

Brevo، پلتفرم ارسال ایمیل و تعامل با مشتری، در ماه سپتامبر هدف یک حمله زنجیره تأمین قرار گرفت؛ حمله‌ای که در آن مهاجمان با استفاده از یک Cloudflare API Key قدیمی و دارای دسترسی گسترده، یک Cloudflare Worker مخرب را روی زیرساخت این شرکت مستقر کردند.

این Worker برای حدود پنج ساعت و نیم، محتوای برخی صفحات Brevo و فایل‌های JavaScript مورد استفاده مشتریان را در لایه CDN تغییر داد و کد مخربی را به بازدیدکنندگان نمایش داد.

بررسی شرکت امنیتی Sansec نشان می‌دهد دامنه این حمله بسیار بزرگ‌تر از یک نفوذ معمول به حساب یک شرکت بوده و بیش از ۱۰۰ هزار وب‌سایت ممکن است در معرض این حمله قرار گرفته باشند. در این حمله، علاوه بر نمایش صفحات جعلی ClickFix به بازدیدکنندگان، تلاش‌هایی برای نصب مخفیانه افزونه مخرب روی برخی سایت‌های WordPress نیز انجام شد.

در این مقاله می‌خوانید

حمله به Brevo دقیقاً چگونه اتفاق افتاد؟
Cloudflare Worker چه نقشی در حمله داشت؟
یک API Key قدیمی چگونه به نقطه ورود مهاجمان تبدیل شد؟
ClickFix چگونه کاربران را به اجرای بدافزار فریب می‌دهد؟
چرا سایت‌های WordPress در معرض خطر بیشتری قرار گرفتند؟
آیا سرورهای اصلی Brevo هک شده بودند؟
کاربران و مدیران سایت‌های استفاده‌کننده از Brevo چه کاری باید انجام دهند؟

حمله به Brevo چه زمانی اتفاق افتاد؟

طبق گزارش رسمی Brevo، مهاجم در ۱۴ سپتامبر ۲۰۲۶ از یک Cloudflare API Key به خطر افتاده برای ایجاد یک Cloudflare Worker استفاده کرد.

این Worker ابتدا روی دامنه‌های کم‌ترافیک آزمایش شد و سپس روی بخش‌هایی از زیرساخت Brevo قرار گرفت. عملیات تزریق محتوای مخرب از حدود ۱۵:۰۱ UTC آغاز شد و تا ساعت ۲۰:۳۰ UTC ادامه داشت؛ یعنی تقریباً پنج ساعت و نیم.

Sansec نیز بازه فعالیت بدافزار را حدود ۱۶:۰۵ تا ۲۰:۱۲ UTC ثبت کرده است. این شرکت پس از بررسی فایل‌های JavaScript و دامنه‌های مورد استفاده مهاجمان، ابعاد حمله را بیش از آنچه در ابتدا تصور می‌شد ارزیابی کرد.

مهاجمان چگونه وارد زیرساخت Brevo شدند؟

نقطه کلیدی این حمله یک Cloudflare API Key طولانی‌مدت با سطح دسترسی کامل بود.

Brevo اعلام کرده این کلید در کد منبع برنامه ذخیره شده بود و مهاجم توانست آن را به دست آورد. مشکل فقط افشای کلید نبود؛ سطح دسترسی بالای این Credential به مهاجم اجازه داد روی حساب Cloudflare عملیات مختلفی انجام دهد.

مهاجم با استفاده از این کلید می‌توانست:

Cloudflare Worker ایجاد کند؛
Routeهای جدید تعریف کند؛
رکوردهای DNS را تغییر دهد؛
رفتار محتوای وب‌سایت را در لایه Edge تغییر دهد.

به این ترتیب، مهاجم لزوماً مجبور نبود فایل‌های اصلی روی سرور Brevo را تغییر دهد.

Cloudflare Worker چگونه حمله را ممکن کرد؟

نکته فنی مهم این حادثه همین‌جاست.

مهاجمان یک Cloudflare Worker ایجاد کردند؛ Worker کدی است که می‌تواند در لایه Edge و پیش از رسیدن محتوای نهایی به کاربر اجرا شود.

در این حادثه، Worker پاسخ‌های وب را در مسیر تحویل محتوا تغییر می‌داد.

یعنی:

کاربر → Cloudflare Edge → Worker مخرب → محتوای دستکاری‌شده → کاربر

در نتیجه، مهاجم می‌توانست بدون تغییر مستقیم فایل اصلی روی Origin Server، چیزی متفاوت به بازدیدکننده تحویل دهد.

Brevo نیز تأکید کرده است که در این حادثه، Origin Serverها و فایل‌های اصلی آن دستکاری نشده بودند و تغییرات در مسیر تحویل محتوا و در لایه CDN اتفاق افتاده بود.

این موضوع اهمیت زیادی دارد؛ زیرا نشان می‌دهد سالم بودن فایل‌های اصلی یک وب‌سایت لزوماً به معنی سالم بودن چیزی نیست که در نهایت به مرورگر کاربر تحویل داده می‌شود.

بیش از ۱۰۰ هزار سایت چگونه درگیر شدند؟

Brevo خدمات مختلفی را به وب‌سایت‌های مشتریان ارائه می‌کند و بخشی از این خدمات از طریق فایل‌های JavaScript و Widgetهای قابل قراردادن در سایت مشتریان اجرا می‌شوند.

از جمله این موارد می‌توان به:

Brevo SDK Loader
Brevo Conversations
فرم‌های Brevo
برخی اسکریپت‌های مرتبط با سرویس‌های Brevo

اشاره کرد.

مهاجمان با تغییر برخی از این منابع JavaScript، عملاً یک مسیر انتشار برای کد مخرب ایجاد کردند.

Sansec اعلام کرده که این حمله می‌توانست بیش از ۱۰۰ هزار وب‌سایت مشتری Brevo را تحت تأثیر قرار دهد. این شرکت نمونه‌هایی از فایل‌های JavaScript دستکاری‌شده و دامنه‌های مورد استفاده مهاجمان را نیز منتشر کرده است.

بنابراین ماجرا صرفاً «هک Brevo» نبود؛ بلکه یک نمونه کلاسیک از Supply Chain Attack بود.

ClickFix وارد ماجرا شد

یکی از مهم‌ترین بخش‌های حمله استفاده از تکنیک ClickFix بود.

در این روش، مهاجم به‌جای اینکه صرفاً فایل مخرب را به‌صورت مستقیم روی سیستم قربانی دانلود کند، تلاش می‌کند خود کاربر را به اجرای آن وادار کند.

در حمله Brevo، برخی بازدیدکنندگان با صفحه‌ای جعلی مواجه می‌شدند که ظاهر آن به صفحه تأیید Cloudflare شباهت داشت.

صفحه از کاربر می‌خواست مراحلی مانند:

Win + R → Ctrl + V → Enter

را انجام دهد.

مشکل این بود که دستوری که در Clipboard قرار گرفته بود، فرمان مخربی بود که پس از اجرا می‌توانست بدافزار را روی سیستم Windows قربانی دانلود کند.

Brevo این روش را نمونه‌ای از ClickFix Social Engineering معرفی کرده است.

چرا ClickFix خطرناک است؟

در حملات سنتی، مهاجم ممکن است تلاش کند کاربر را متقاعد کند یک فایل EXE دانلود کند یا روی یک لینک مشکوک کلیک کند.

اما ClickFix از یک ترفند متفاوت استفاده می‌کند:

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

به همین دلیل حتی وجود صفحه‌ای با ظاهر معتبر و برندهایی مانند Cloudflare نیز نباید باعث اعتماد کاربر شود.

WordPress هم هدف قرار گرفت

حمله Brevo یک مسیر دیگر نیز داشت.

اگر کاربری در یک سایت WordPress با سطح دسترسی Administrator وارد شده بود و سایت از برخی اسکریپت‌های Brevo استفاده می‌کرد، payload حمله می‌توانست تلاش کند یک Plugin مخرب را به‌صورت مخفیانه نصب و فعال کند.

این بخش از حمله اهمیت ویژه‌ای دارد؛ زیرا در این سناریو، قربانی صرفاً یک کاربر عادی نیست.

یک مدیر سایت می‌تواند دسترسی‌هایی داشته باشد که در صورت سوءاستفاده، مهاجم را قادر به ایجاد Persistence روی وب‌سایت کند.

Sansec اعلام کرده است که در جریان بررسی خود نمونه‌هایی از تلاش برای نصب Backdoor روی سایت‌های WordPress را مشاهده کرده است.

آیا خود Brevo به‌طور کامل هک شده بود؟

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

Brevo اعلام کرده:

اپلیکیشن app.brevo.com تحت تأثیر این حمله قرار نگرفت؛
API شرکت تحت تأثیر این حادثه قرار نگرفت؛
سرویس ارسال ایمیل تحت تأثیر قرار نگرفت؛
اطلاعات حساب مشتریان در Brevo در این حادثه تغییر نکرد؛
فایل‌های اصلی روی Origin Server دستکاری نشده بودند.

اما مهاجم توانسته بود در لایه Edge/CDN محتوای تحویلی را تغییر دهد.

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

چرا این حمله یک Supply Chain Attack است؟

در یک حمله مستقیم، مهاجم ممکن است مستقیماً یک سایت را هدف قرار دهد.

اما در حمله زنجیره تأمین، مهاجم یک نقطه واسط مورد اعتماد را هدف می‌گیرد.

در اینجا زنجیره تقریباً چنین بود:

مهاجم

↓

Cloudflare API Key به خطر افتاده

↓

Cloudflare Worker مخرب

↓

زیرساخت Brevo

↓

JavaScript / Widgetهای Brevo

↓

وب‌سایت‌های مشتریان

↓

بازدیدکنندگان

این ساختار باعث می‌شود یک نقطه نفوذ بتواند دامنه بسیار بزرگ‌تری از قربانیان را تحت تأثیر قرار دهد.

چرا سالم بودن فایل اصلی کافی نبود؟

یکی از نکات مهم این حادثه برای تیم‌های امنیتی، تفاوت بین Origin Integrity و Delivery Integrity است.

اگر فایل اصلی روی سرور دستکاری نشده باشد، ابزارهای Integrity Monitoring ممکن است هیچ تغییری مشاهده نکنند.

اما اگر مهاجم بتواند در CDN یا Edge یک Worker اجرا کند، محتوایی که کاربر دریافت می‌کند می‌تواند با فایل موجود روی Origin متفاوت باشد.

Brevo اعلام کرده Worker مهاجم حتی برخی Security Headerها مانند Content-Security-Policy را نیز حذف می‌کرد تا امکان اجرای محتوای مخرب فراهم شود.

این موضوع نشان می‌دهد امنیت زنجیره تحویل نرم‌افزار و محتوای وب باید فراتر از بررسی فایل‌های روی سرور اصلی باشد.

Brevo پس از شناسایی حمله چه کرد؟

Brevo پس از شناسایی حادثه:

Worker مخرب را حذف کرد؛
Routeهای ایجادشده توسط مهاجم را حذف کرد؛
API Key به خطر افتاده را لغو کرد؛
Credentialهای ایجادشده توسط مهاجم را Revocation کرد؛
Cacheهای Edge را پاک‌سازی کرد؛
فایل‌ها و صفحات تحت تأثیر را بررسی کرد؛
Credential ذخیره‌شده در Source Code را حذف کرد؛
استفاده از Tokenهای کوتاه‌مدت و محدود را جایگزین کرد.

این شرکت همچنین اعلام کرده قصد دارد مدیریت کلیدهای Cloudflare را با HashiCorp Vault متمرکز کند و رویدادهای مربوط به تغییر Worker، Route، DNS و دسترسی حساب را به سیستم مانیتورینگ امنیتی منتقل کند.

اگر از Brevo استفاده می‌کنید چه کار کنید؟

اگر وب‌سایت شما از سرویس‌ها یا Scriptهای Brevo استفاده می‌کند، بررسی امنیتی همچنان اهمیت دارد.

Brevo توصیه کرده است:

اگر دستور ClickFix را اجرا کرده‌اید

سیستم را Compromised در نظر بگیرید و:

اتصال سیستم را در صورت امکان قطع کنید؛
اسکن کامل آنتی‌ویروس انجام دهید؛
رمزهای عبوری که روی آن سیستم استفاده شده‌اند را تغییر دهید؛
ابتدا حساب‌های حساس و Brevo را بررسی کنید.

اگر سایت WordPress دارید

اگر در ۱۴ سپتامبر هنگام بازدید از سایت، با حساب Administrator وارد WordPress بوده‌اید:

افزونه‌های نصب‌شده در همان روز را بررسی کنید؛
Plugin ناشناس یا مشکوک را حذف کنید؛
زمان نصب و فعال‌سازی افزونه‌ها را بررسی کنید؛
رمز عبور حساب Administrator را تغییر دهید؛
لاگ‌های WordPress و Web Server را بررسی کنید.

Brevo به‌طور مشخص از مدیران سایت‌هایی که در آن بازه از Scriptهای این شرکت استفاده می‌کردند خواسته است وضعیت Pluginهای نصب‌شده را بررسی کنند.

اتاق تحلیل ۲۴ نیوز | دیدگاه تحلیلی بهراد یوسفی

حمله Brevo یک نمونه مهم از تغییری است که در سال‌های اخیر در حملات زنجیره تأمین دیده می‌شود: مهاجم همیشه لازم نیست سرور نهایی قربانی را هک کند.

گاهی کافی است یک سرویس واسط، Credential، CDN، ابزار Analytics، SDK یا JavaScript مورد اعتماد را هدف قرار دهد.

در این حادثه، مهاجم از یک API Key با سطح دسترسی بالا استفاده کرد و سپس از قابلیت قانونی Cloudflare برای اجرای Worker بهره گرفت. به بیان دیگر، بخش مهمی از زنجیره حمله از ابزارهای کاملاً legitimate تشکیل شده بود؛ مشکل در این بود که چه کسی کنترل آنها را در اختیار داشت.

برای کسب‌وکارها، پیام مهم این حادثه فقط «کلید API را لو ندهید» نیست.

مسئله بزرگ‌تر، مدیریت چرخه عمر Credentialها است.

یک API Key که ماه‌ها یا سال‌ها معتبر باقی بماند، در Source Code ذخیره شود و دسترسی کامل داشته باشد، در صورت افشا می‌تواند به یک نقطه شکست بسیار بزرگ تبدیل شود.

اصل مهم این است:

کلیدهای دسترسی باید کوتاه‌عمر، محدود و قابل ردیابی باشند و هیچ Credential حساسی نباید در Source Code باقی بماند.

از طرف دیگر، سازمان‌ها نباید فقط Origin Server خود را مانیتور کنند. CDN، DNS، Edge Functionها، Third-Party Scriptها و سرویس‌های SaaS نیز بخشی از سطح حمله هستند.

حمله Brevo نشان می‌دهد که یک تغییر کوچک در یک سرویس مورد اعتماد می‌تواند زنجیره‌ای از حملات را به تعداد بسیار زیادی از کاربران منتقل کند.

آیا کاربران ایرانی هم باید نگران باشند؟

Brevo یک سرویس بین‌المللی است و این حادثه به‌طور مشخص حمله‌ای علیه کاربران ایرانی اعلام نشده است.

اما از نظر فنی، هر کاربر یا سازمانی که در بازه حمله از وب‌سایت‌های تحت تأثیر بازدید کرده یا سایتی داشته که Scriptهای Brevo را بارگذاری می‌کرده، می‌توانست در معرض یکی از مسیرهای حمله قرار گیرد.

برای کاربران ایرانی، مهم‌ترین درس عملی این حادثه ساده است:

اگر یک صفحه اینترنتی از شما خواست برای عبور از Cloudflare، رفع Captcha یا تأیید انسان بودن، یک دستور را با Win+R اجرا کنید، آن را اجرا نکنید.

Cloudflare واقعی برای اثبات انسان بودن شما نباید از شما بخواهد یک فرمان ناشناس را در Windows Run اجرا کنید.

جمع‌بندی

حمله به Brevo نشان داد یک Cloudflare API Key قدیمی و دارای دسترسی گسترده چگونه می‌تواند از یک Credential فراموش‌شده به نقطه ورود یک حمله زنجیره تأمین تبدیل شود.

مهاجمان با ایجاد یک Cloudflare Worker توانستند محتوای تحویلی را در Edge تغییر دهند و از زیرساخت یک سرویس معتبر برای توزیع حملات ClickFix و تلاش برای نصب Backdoor روی برخی سایت‌های WordPress استفاده کنند.

Sansec دامنه احتمالی این حمله را بیش از ۱۰۰ هزار وب‌سایت برآورد کرده است؛ رقمی که اهمیت امنیت سرویس‌های واسط و Third-Party Scriptها را بیش از پیش نشان می‌دهد.

این حادثه یک هشدار مهم برای سازمان‌ها دارد:

امنیت فقط به معنای محافظت از سرور اصلی نیست؛ هر Credential، CDN، DNS، API، SDK و سرویس شخص ثالثی که در مسیر رسیدن محتوا به کاربر قرار دارد، بخشی از سطح حمله سازمان است.