آسیبپذیری روز-صفر بدون وصله در Magento و Adobe Commerce، فروشگاههای آنلاین را بکدور میکند
اخبار داغ فناوری اطلاعات و امنیت شبکهمهاجمان در حال سوءاستفاده فعال از یک آسیبپذیری تازه و بدون وصله در Magento Open Source و Adobe Commerce هستند که به آنها اجازه میدهد بدون نیاز به ورود به سیستم، کد مخرب را روی سرور یک فروشگاه آنلاین اجرا کنند. شرکت هلندی امنیت تجارت الکترونیک Sansec که این نقص را کشف کرده، آن را StyleSmuggler نامگذاری کرده و در بیانیهای که در تاریخ پنجم سپتامبر منتشر شده، اعلام کرده حملات از تاریخ چهارم سپتامبر آغاز شدهاند.
به گفته این شرکت، دلیل انتشار زودهنگام این هشدار، این است که فروشگاهها هماکنون و در همین لحظه در حال بهخطر افتادن هستند.
بدون CVE، بدون وصله، بدون راهکار موقت رسمی
تا تاریخ ششم سپتامبر، شرکت ادوبی هیچ بیانیه رسمی، شناسه CVE، وصله یا راهکار موقتی برای این آسیبپذیری منتشر نکرده و فهرست بولتنهای امنیتی Adobe Commerce نیز پس از بهروزرسانی ۱۱ اوت، هیچ موردی را نشان نمیدهد.
بر اساس اعلام Sansec، یک حمله موفق به مهاجم اجازه اجرای کد روی سرور فروشگاه را میدهد و یک بکدور پایدار (Persistent Backdoor) روی سیستم نصب میکند. این شرکت اعلام کرده تمام نسخههای فعلی، از جمله نسخه ۲.۴.۹، تحت تأثیر این نقص قرار دارند و زنجیره کامل حمله بدون نیاز به احراز هویت را روی نصبهای تمیز Magento Open Source نسخههای ۲.۴.۷، ۲.۴.۸ و ۲.۴.۹ بازتولید کرده است.
نخستین قربانی شناساییشده، نسخه ۲.۴.۶-p15 را اجرا میکرده که با بهروزرسانیهای امنیتی ژوئیه و اوت ۲۰۲۶ ادوبی بهروزرسانی شده بود؛ یعنی جدیدترین سطح وصلهای که ادوبی برای این خط نسخه ارائه میدهد. Sansec هنوز بازتولیدی از این آسیبپذیری روی Adobe Commerce یا نسخه ابری آن منتشر نکرده و ادوبی نیز مشخص نکرده کدام نسخهها را تحت تأثیر میداند. تعداد فروشگاههای بهخطرافتاده نیز تاکنون اعلام نشده است.
توصیه موقت پژوهشگران به فروشگاههایی که از محصول Shield این شرکت استفاده نمیکنند، غیرفعالسازی GraphQL تا زمان انتشار یک راهحل موقت از سوی ادوبی است. شرکت Disrex Group، شرکت میزبانی و توسعه Magento که به دو مورد از فروشگاههای بهخطرافتاده رسیدگی کرده، توضیح داده فروشگاههای هدلس (Headless) و اپلیکیشنهای وب پیشرونده (PWA) به GraphQL نیاز دارند، در حالی که بیشتر فروشگاههای کلاسیک و مبتنی بر Hyvä به آن نیازی ندارند.
بر اساس اعلام Sansec، بسته امنیتی بعدی ادوبی در تاریخ ۸ سپتامبر منتشر میشود، اما هنوز مشخص نیست آیا این نسخه، این نقص را نیز پوشش خواهد داد یا خیر.
شواهد مستقل از بهرهبرداری؛ گزارش Disrex Group
یافتههای Disrex، شواهدی مستقل و خارج از گزارش Sansec از بهرهبرداری فعال این آسیبپذیری ارائه میدهند. این شرکت در مخزنی برای پاسخ به حادثه که در تاریخ پنجم سپتامبر منتشر کرده، اعلام کرده به دو فروشگاه بهخطرافتاده در تاریخ پنجم سپتامبر و یک فروشگاه سوم که مورد حمله قرار گرفته اما نفوذ نکرده، رسیدگی کرده است. قوانین وبسرور منتشرشده توسط این شرکت نیز بر اساس ترافیک حمله ثبتشده روی یکی از فروشگاههای بهخطرافتاده تنظیم شدهاند.
آن فروشگاه، نسخه Magento 2.4.7-p2 را اجرا میکرده؛ سطح وصلهای که بر اساس تاریخچه نسخههای رسمی ادوبی به آگوست ۲۰۲۴ بازمیگردد و هشت سطح از نسخه فعلی ۲.۴.۷-p10 عقبتر است. فروشگاهی که Disrex آن را «فروشگاه A» نامگذاری کرده، مشتری محصول Shield سانسک بوده و در ساعت ۲۳:۱۰ به وقت جهانی در تاریخ چهارم سپتامبر، یعنی چند ساعت پیش از فعال شدن نخستین قوانین مسدودسازی Sansec، مورد حمله قرار گرفته است.
این مخزن هشدار قابلتوجهی نیز درباره خود دارد؛ در فایل README آن آمده که این مخزن با کمک هوش مصنوعی، در جریان یک حادثه زنده، و در عرض چند ساعت نوشته شده، هنوز بازبینی نشده، قوانین Apache آن هرگز روی یک سرور Apache واقعی اجرا نشدهاند و بیشتر دستورات پاکسازی آن نوشته شدهاند، نه اجرا.
ایمپلنت پنهان زیر پوشش یک فرایند هسته لینوکس
بر اساس شاخصهای منتشرشده توسط Sansec، این ایمپلنت به شکل یک فرایند پسزمینه پنهانشده زیر نام [kworker/u:8:0] — نامی که متعلق به یک نخ هسته لینوکس (Kernel Thread) است — ظاهر میشود. فایل باینری آن در مسیر ~/.local/share/.gvfsd/gvfsd-user درون پوشه خانگی کاربر سایت (نه ریشه وب) نصب میشود و یک ورودی Cron هر پنج دقیقه یکبار آن را مجدداً راهاندازی میکند.
Disrex این باینری را برنامهای نوشتهشده به زبان Rust، از نوع Stripped و پیوند ایستا (Statically Linked)، با حجم تقریبی ۱.۹ مگابایت و ساختهشده برای معماریهای x86-64 و arm64 توصیف کرده است. به گفته این شرکت، ورودی Cron مستقیماً درون فایل Spool در مسیر /var/spool/cron/crontabs/ نوشته میشود؛ به همین دلیل، لاگ سیستم هیچ نشانهای از جایگزینی Crontab نشان نمیدهد.
در یکی از فروشگاهها، همین یک خط Cron ۱,۷۲۸ بار تکرار شده بود و ایمپلنت، ظرف کمتر از یک ثانیه پس از حذف، آن را دوباره اضافه میکرد.
در یکی از دو فروشگاه بررسیشده، این ایمپلنت هیچ اتصال خروجی برقرار نکرده بود. در عوض، ۲۸ اتصال به نمونه Redis خود همان فروشگاه روی پورت ۶۳۷۹ برقرار کرده و طبق اعلام Disrex، ذخیرهسازی نشست (Session Storage) Magento را از طریق آن خوانده بود. در همان بازه زمانی که ایمپلنت فعال بوده، هیچکدام از دو ضبط بسته شبکه (هرکدام بیش از ۲۰۰ مگابایت) این شرکت، حتی یک بسته به سمت میزبان دانلود یا آدرس فرماندهی و کنترل اعلامشده توسط Sansec ثبت نکرده بودند.
Sansec اعلام کرده برای مشتریان Shield که پیش از فعال شدن قوانین این شرکت مورد حمله قرار گرفتهاند، هیچ نشانهای مبنی بر استفاده واقعی از بکدور مشاهده نشده و توصیه کرده اعتبارنامههای Magento را در هر جایی که این فرایند شناسایی شده، چرخانده شود.
زنجیره حمله دو مرحلهای: از یک لاگ ساده تا اجرای کد کامل
بر اساس تشریح Sansec، این حمله در دو مرحله اجرا میشود:
نخست، مهاجم کد PHP خود را درون فایلی میکارد که خود Magento آن را مینویسد؛ برای نمونه هنگام تولید یک گزارش خطا. سپس، مهاجم Magento را وادار میکند آن فایل را اجرا کند؛ کاری که با فعالسازی ایمیل استاندارد پلتفرم با عنوان «یادآوری تراکنش پرداخت ناموفق» (Payment Transaction Failed Reminder) انجام میشود. این کد در حین رندر شدن پیام توسط Magento اجرا میشود، بنابراین هیچکس نیازی به باز کردن آن ایمیل ندارد و حتی اگر تحویل ایمیل با شکست مواجه شود، حمله همچنان میتواند موفق شود.
Sansec هنوز زنجیره کامل بهرهبرداری را منتشر نکرده و اعلام کرده جزئیات کامل زنجیره، بارگذار (Dropper) و ایمپلنت، در بهروزرسانیهای بعدی منتشر خواهد شد.
تحلیل مستقل Disrex از مکانیزم حمله
Disrex در توضیح مکانیزمی که همراه با قوانین خود منتشر کرده، توضیح داده یک دستورالعمل درون متن تزریقشده، توالیای از کلاسهای خود Magento را به سمت کدی هدایت میکند که صرفاً برای خدمترسانی به کامپایلر تزریق وابستگی خط فرمان (CLI Dependency-Injection Compiler) وجود دارد.
این کد در نهایت با شامل کردن یک مسیر فایل که مهاجم انتخاب کرده — همان لاگی که لحظاتی پیش مسموم شده — به پایان میرسد. بارگذار PHP اجراشده، شش تابع مختلف PHP را بهترتیب برای آغاز یک فرایند امتحان میکند و سپس ایمپلنت را دانلود و اجرا میکند. Disrex سه فایل را در مسیر setup/src/Magento/Setup/Module/Di/Code/ بهعنوان نقطه پایانی این زنجیره معرفی کرده است. Sansec این تحلیل را تأیید نکرده و Disrex نیز درخواست کامل مونتاژشده را منتشر نکرده است.
دو محل کلیدی برای شناسایی مرحله اول حمله
بررسی Sansec، پوشه var/report/ را برای یافتن نشانه X_TRACE_ جستوجو میکند. اما Disrex اعلام کرده هر دو مورد آلودگی که این شرکت بررسی کرده، از طریق فایل var/log/system.log مسموم شده بودند و توسط این بررسی شناسایی نمیشدند؛ بنابراین هر دو مسیر باید جستوجو شوند.
این نشانه (Marker) نیز از قبل تغییر کرده است: Disrex در صبح پنجم سپتامبر، هدری به شکل X-TRACE- بههمراه ده کاراکتر هگزادسیمال مشاهده کرده و در بعدازظهر همان روز، همان هدر بدون کلمه TRACE دیده شده است؛ بنابراین جستوجو باید بر اساس الگو باشد، نه رشته دقیق.
بر اساس گفته Disrex، بروز خطای TypeError ناشی از تابع array_merge() با یک آرگومان عددی صحیح در فایل system.log، بلافاصله پس از عملیات Include، نشانهای از موفقیت بهرهبرداری است. با این حال، یک نسخه پنهانکارانهتر از این حمله، یک آرایه خالی بازمیگرداند و هیچ اثری در لاگ باقی نمیگذارد.
درباره شناسایی فرایند مخرب نیز Disrex توضیح داده یک نخ هسته واقعی، متعلق به کاربر root است و هیچ حافظه مقیم (Resident Memory) ندارد؛ بنابراین یک نام داخل کروشه که تحت کاربر سایت و با مصرف واقعی حافظه اجرا میشود، همان ایمپلنت است. این ایمپلنت خط فرمان خود را دقیقاً همان رشته داخل کروشه تنظیم میکند؛ به همین دلیل، بررسی مبتنی بر فیلد comm فرایند، هیچ نتیجهای پیدا نمیکند.
Disrex همچنین دریافته باینری در حال اجرا در حافظه یکی از فروشگاهها، نسخهای متفاوت از فایل روی دیسک بوده و توصیه کرده علاوه بر فایل روی دیسک، فرایند در حال اجرا از مسیر /proc/<pid>/exe نیز هش شود. Sansec نیز اعلام کرده افزایش ناگهانی در ارسال ایمیلهای «یادآوری تراکنش پرداخت ناموفق» میتواند دلیلی برای بررسی باشد، هرچند پرداختهای ناموفق واقعی نیز همین اعلان را تولید میکنند.
شاخصهای نفوذ (IOC) منتشرشده
بر اساس دادههای منتشرشده توسط Sansec و فهرست شاخصهای Disrex، موارد زیر شناسایی شدهاند:
- فرایند:
[kworker/u:8:0]متعلق به کاربری غیر از root - فایل:
~/.local/share/.gvfsd/gvfsd-user - فایل:
~/.local/share/.gvfsd/.gvfsd_<8hex>.lock - فایل:
/tmp/.gvfsd_<8hex>.lock - فایل:
/tmp/.kw_<random><random> - Cron:
*/5 * * * * exec <home>/.local/share/.gvfsd/gvfsd-user(با نسخهای که به/tmp/.kw_اشاره میکند) - دامنه:
247.cdnflare[.]xyz(میزبان دانلود بدافزار) - آدرس IP:
99.84.67[.]186:443(فرماندهی و کنترل از طریق WebSocket و TLS، بر اساس اعلام Sansec) - آدرس IP:
88.216.72[.]181(منبع مهاجم، بر اساس اعلام Sansec) - آدرس IP:
5.181.86[.]133(منبع مهاجم با ارسال انبوه، بر اساس اعلام Disrex)
اسکنرهای امنیتی؛ نتایج متناقض
Sansec استفاده از اسکنر اختصاصی خود با نام eComscan را برای شناسایی این ایمپلنت توصیه کرده و اعلام کرده نسخه ۱.۹.۷ این ابزار، فرایند مخرب را برای مشتریان Shield متوقف خواهد کرد.
با این حال، Disrex نتیجهای متناقض برای یکی از فروشگاهها گزارش کرده است: eComscan با فعال بودن بررسیهای فرایند پسزمینه و وظایف زمانبندیشده، در حالی که ایمپلنت فعال بود و ۱,۷۲۸ خط Cron مخرب وجود داشت، اجرا شده و فروشگاه را «تمیز» گزارش کرده بود. Disrex مشخص نکرده کدام نسخه eComscan و چه زمانی اجرا شده است.
راهکارهای موقت غیررسمی؛ بدون وصله رسمی از سوی سازنده
تا زمان انتشار وصله رسمی توسط ادوبی، گزینههای موجود شامل غیرفعالسازی موقت GraphQL پیشنهادی Sansec، سه راهکار کاهش ریسک غیررسمی منتشرشده توسط Disrex، ProxiBlue و Graycore، و دو تنظیم سطح سرور مستقل از جزئیات این آسیبپذیری هستند.
Disrex قوانینی برای Nginx و Apache منتشر کرده که درخواستهای حامل پارامترهای بهرهبرداری در رشته Query URL را مسدود میکنند. آزمایش این شرکت روی یک فروشگاه فعال، محدودیت این روش را نشان داده است: همان پارامترها در صورت ارسال از طریق بدنه POST یا یک بدنه JSON، همچنان به PHP میرسند، چراکه Nginx و Apache تنها رشته Query را بررسی میکنند. Disrex این قوانین را بیشتر متوقفکننده کمپین فعلی توصیف کرده تا رفع کامل خود آسیبپذیری.
راهکار اصلی Disrex، بررسیای را به سه متد در اسکنرهای کد تزریق وابستگی Magento اضافه میکند که مانع اجرای آنها خارج از خط فرمان میشود. از آنجا که این ویرایش دستی با هر بار اجرای composer install بازگردانده میشود، Disrex آن را در قالب یک پچ رسمی Composer نیز منتشر کرده که در هر بار استقرار مجدداً اعمال میشود و به گفته این شرکت، بدون تغییر از نسخه ۲.۴.۶ تا ۲.۴.۹ کاربرد دارد.
یکی از سه فایل مذکور، یعنی ClassesScanner.php، توسط دستکم یک ماژول شخص ثالث با نام mageplaza/module-admin-permissions از طریق HTTP فراخوانی میشود و محافظت از آن، صفحه مدیریتی این ماژول را دچار اختلال میکند؛ به همین دلیل Disrex به مدیران توصیه کرده پیش از اعمال این تغییر، پوشه Vendor خود را بررسی کنند.
یک کاربر گیتهاب با نام مستعار ProxiBlue نیز همین محافظت را در تاریخ پنجم سپتامبر، همراه با سه پچ غیررسمی دیگر منتشر کرده است. شرکت Graycore، LLC نیز یک ماژول Magento در گیتهاب و Packagist منتشر کرده که بر اساس اعلام این شرکت، سه نقطه از زنجیره حمله را سختتر میکند. هیچکدام از Sansec یا ادوبی تأیید نکردهاند که این اسکنرها دقیقاً همان نقطه پایانی زنجیره حمله هستند.
دو تنظیم سطح سرور، مستقل از جزئیات زنجیره حمله
به گفته Disrex، دو تنظیم سرور وجود دارند که نیازی به دانستن جزئیات کامل زنجیره حمله ندارند: در یکی از دو فروشگاه بررسیشده، چهار مورد از شش تابع PHP که بارگذار مخرب امتحان کرده بود، غیرفعال شده بودند؛ اما تابع proc_open غیرفعال نبود و بارگذار از آن برای اجرای ایمپلنت استفاده کرد، در حالی که تنظیم open_basedir هیچ نقشی در مهار فرایند فرزند نداشت.
افزودن proc_open به فهرست disable_functions در PHP، و مانت کردن مسیرهای /tmp، /var/tmp و /dev/shm با گزینه noexec تا یک باینری دانلودشده نتواند اجرا شود، دو لایه دفاعی هستند که Disrex آنها را مقدم بر تمام قوانین دیگر مخزن خود قرار میدهد.
راهنمای پاکسازی فروشگاههای آلوده
برای فروشگاههایی که از قبل آلوده شدهاند، راهنمای پاکسازی Disrex ترتیب زیر را توصیه میکند:
- ابتدا شواهد را حفظ کنید.
- پیش از متوقف کردن فرایند مخرب، ورودی Cron را حذف کنید؛ چراکه خود فرایند، این ورودی را بازسازی میکند.
- سیستم را ریاستارت نکنید، چراکه نسخه باینری موجود در
/procممکن است تنها نسخه باقیمانده از آن باشد. - برای پاکسازی، دستور
composer installرا اجرا نکنید، چراکه این کار Timestampهایی را که نشاندهنده محل دستکاریشده هستند، بازنویسی میکند.
پس از این مراحل، توصیه شده ذخیرهسازی نشست (Session Storage) — که ایمپلنت آن را خوانده — پاکسازی شود و کلید رمزنگاری crypt/key در فایل app/etc/env.php، بههمراه تمام رمزهای عبور مدیریتی، کلیدهای API درگاههای پرداخت و سایر اعتبارنامههای یکپارچهسازی موجود در آن فایل، چرخانده شوند.
واکنش شرکتهای میزبانی و ابعاد واقعی حمله
شرکتهای میزبانی Nexcess و Liquid Web در تاریخ پنجم سپتامبر، اطلاعیههای یکسانی درباره این حادثه منتشر کرده و اعلام کردهاند در حال بررسی محیطهای سرور خود و اجرای اقدامات پیشگیرانه هستند؛ هرچند هیچکدام مورد تأییدشدهای از بهخطر افتادن مشتری یا بازتولید مستقل خود از این نقص گزارش نکردهاند.
Disrex در بررسی دو فروشگاه خود، ۲۶ آدرس منبع متفاوت را ثبت کرده که دو مورد از آنها زیرساخت میزبانی با ارسال انبوه بودند و باقی، از یک استخر پروکسی خانگی (Residential Proxy Pool) با ارسال دو تا شش درخواست از هر آدرس. این شرکت اعلام کرده مسدودسازی تنها آدرس مهاجم منتشرشده در بیانیه Sansec، کمتر از یکچهارم ترافیکی را که این شرکت مشاهده کرده متوقف میکرد. تاکنون هیچ منبعی هویت مهاجمان را افشا نکرده است.
چرا این آسیبپذیری اهمیت دارد؟
این حادثه از چند جهت نگرانکننده است. نخست، فقدان کامل هرگونه وصله، راهکار موقت رسمی یا حتی شناسه CVE از سوی ادوبی، به این معناست که سازمانها در حال حاضر تنها به راهکارهای کاهش ریسک غیررسمی و آزمایشنشده جامعه متنباز متکی هستند. دوم، مقیاس گسترش این حملات — از جمله استفاده از یک استخر بزرگ پروکسی خانگی برای پراکنده کردن منبع ترافیک — نشان میدهد این کمپین از قبل بهخوبی سازماندهی شده است. سوم، طراحی هوشمندانه ایمپلنت برای پنهان شدن زیر نام یک فرایند هسته لینوکس و بازسازی خودکار ورودی Cron، شناسایی آن را برای مدیران سیستم بدون ابزارهای تخصصی بسیار دشوار میکند.
از سوی دیگر، ناهماهنگی مشاهدهشده میان یافتههای Sansec و Disrex — از جمله محل دقیق مسمومسازی لاگ و عملکرد ناقص اسکنر eComscan در برخی موارد — نشان میدهد حتی ابزارهای تخصصی امنیت Magento نیز ممکن است در شرایط فعلی این حمله را بهطور کامل شناسایی نکنند.
توصیههای امنیتی فوری
- در صورت عدم استفاده از فروشگاه هدلس یا PWA، غیرفعالسازی موقت GraphQL تا انتشار وصله رسمی ادوبی را در نظر بگیرید.
- هر دو مسیر
var/report/وvar/log/system.logرا برای یافتن نشانههای مسمومسازی (با جستوجوی الگو، نه رشته دقیق) بررسی کنید. - فرایندهای در حال اجرا را برای یافتن نامهای مشکوک مانند
[kworker/u:8:0]که تحت کاربری غیر از root اجرا میشوند، بررسی کنید و علاوه بر فایل روی دیسک، فرایند در حال اجرا را نیز از مسیر/proc/<pid>/exeهش کنید. - تابع
proc_openرا به فهرستdisable_functionsدر PHP اضافه کرده و مسیرهای/tmp،/var/tmpو/dev/shmرا با گزینهnoexecمانت کنید. - در صورت شناسایی آلودگی، ترتیب پاکسازی توصیهشده توسط Disrex (حفظ شواهد، حذف Cron پیش از توقف فرایند، عدم ریاستارت، عدم اجرای composer install) را دنبال کنید.
- در صورت آلودگی، ذخیرهسازی نشست را پاکسازی کرده و کلید
crypt/key، تمام رمزهای عبور مدیریتی و کلیدهای API درگاههای پرداخت را چرخانده شوند. - در جریان بولتن امنیتی بعدی ادوبی (۸ سپتامبر) و بهروزرسانیهای بعدی Sansec درباره جزئیات کامل زنجیره حمله باقی بمانید.
جمعبندی
آسیبپذیری StyleSmuggler، نمونهای فوری و در حال وقوع از خطرات یک روز-صفر بدون وصله در یکی از پرکاربردترین پلتفرمهای تجارت الکترونیک جهان است. غیبت هرگونه واکنش رسمی از سوی ادوبی، جامعه امنیتی و توسعهدهندگان مستقل را وادار کرده در کمترین زمان ممکن، راهکارهای کاهش ریسک موقت و غیررسمی ارائه دهند؛ راهکارهایی که بهگفته سازندگان خودشان، کامل یا کاملاً آزمایششده نیستند. برای مالکان فروشگاههای آنلاین مبتنی بر Magento و Adobe Commerce، نظارت فوری بر نشانههای نفوذ، اعمال لایههای دفاعی مستقل از جزئیات دقیق حمله (مانند غیرفعالسازی proc_open)، و آمادگی برای واکنش سریع به حادثه، در حال حاضر تنها خط دفاعی واقعی در برابر این تهدید در حال گسترش است.
برچسب ها: Magento Open Source, Adobe Commerce, امنیت_اطلاعات, امنیت_سایبری, Cyberattack, cybersecurity, steganography, news, StyleSmuggler