Các kẻ tấn công đang khai thác một lỗ hổng unpatched mới trong Magento Open Source và Adobe Commerce, cho phép chúng thực thi malicious code trên máy chủ của cửa hàng trực tuyến mà không cần đăng nhập. Công ty bảo mật thương mại điện tử Hà Lan Sansec đã đưa ra cảnh báo này trong một advisory công bố vào ngày 5 tháng 9.
Sansec, đơn vị phát hiện ra lỗi này và đặt tên là StyleSmuggler, cho biết các cuộc tấn công đã bắt đầu từ ngày 4 tháng 9. "Sansec công bố sớm vì các cửa hàng đang bị compromised ngay lúc này," công ty cho biết.
Tính đến ngày 6 tháng 9, Adobe vẫn chưa công bố advisory, mã định danh CVE, bản patch hay workaround nào. Danh mục bản tin bảo mật của Adobe Commerce cũng không liệt kê thêm thông tin gì sau bản cập nhật ngày 11 tháng 8.
Một cuộc tấn công thành công sẽ mang lại cho kẻ tấn công khả năng code execution trên máy chủ cửa hàng và cài đặt một backdoor dai dẳng. Sansec cho biết tất cả các phiên bản hiện tại đều bị ảnh hưởng, bao gồm cả 2.4.9, và họ đã tái hiện thành công chuỗi unauthenticated đầy đủ trên các bản cài đặt sạch của Magento Open Source 2.4.7, 2.4.8 và 2.4.9.
Nạn nhân đầu tiên của cuộc tấn công này đang chạy phiên bản 2.4.6-p15 đã áp dụng các bản cập nhật bảo mật tháng 7 và tháng 8 của Adobe, vốn là cấp độ patch mới nhất mà Adobe cung cấp cho dòng phiên bản đó.
Sansec vẫn chưa công bố cách tái hiện trên Adobe Commerce hoặc Adobe Commerce on Cloud, và Adobe cũng chưa xác nhận các phiên bản cụ thể bị ảnh hưởng. Sansec cũng không tiết lộ có bao nhiêu cửa hàng đã bị compromised.
Lời khuyên tạm thời của các nhà nghiên cứu cho các cửa hàng không sử dụng sản phẩm Shield của họ là vô hiệu hóa GraphQL cho đến khi Adobe phát hành bản sửa lỗi tạm thời.
Disrex Group, một công ty lưu trữ và phát triển Magento, lưu ý rằng các cửa hàng sử dụng headless và progressive web app (PWA) yêu cầu GraphQL, trong khi hầu hết các cửa hàng kiểu cổ điển và Hyvä thì không cần.
Bằng chứng độc lập về việc khai thác thực tế
Adobe dự kiến phát hành bản bảo mật tiếp theo vào ngày 8 tháng 9, nhưng vẫn chưa rõ liệu bản phát hành đó có khắc phục được lỗi này hay không.
Các phát hiện của Disrex là bằng chứng độc lập về việc exploit từ bên ngoài Sansec. Trong một incident-response repository công bố ngày 5 tháng 9, công ty cho biết họ đã xử lý hai cửa hàng bị compromised và một cửa hàng khác bị tấn công nhưng không bị xâm nhập thành công.
Cửa hàng bị xâm nhập đang chạy Magento 2.4.7-p2, một cấp độ security patch từ tháng 8 năm 2024. Một trong những cửa hàng bị tấn công đã được ghi nhận bị xâm nhập vào lúc 23:10 UTC ngày 4 tháng 9, chỉ vài giờ trước khi các quy tắc chặn đầu tiên của Sansec Shield có hiệu lực.
Đặc điểm của mã độc và Backdoor
Các indicators từ Sansec mô tả implant (mã cấy) là một background process ngụy trang dưới tên [kworker/u:8:0], một cái tên thuộc về Linux kernel thread. Binary được cài đặt tại ~/.local/share/.gvfsd/gvfsd-user và có một mục cron tự khởi động lại sau mỗi 5 phút.
Disrex mô tả binary này là một chương trình Rust được liên kết tĩnh, có dung lượng khoảng 1.9 MB, được xây dựng cho kiến trúc x86-64 và arm64. Mục cron được ghi trực tiếp vào file spool, vì vậy nhật ký hệ thống không hiển thị việc thay thế crontab.
Tại một cửa hàng, implant không tạo kết nối ra ngoài mà duy trì 28 kết nối tới thực thể Redis của chính cửa hàng đó để đọc dữ liệu session storage của Magento. Sansec khuyến nghị nên xoay vòng (rotate) các credentials của Magento ở bất kỳ nơi nào quy trình này được xác định.
Cơ chế tấn công StyleSmuggler
Theo Sansec, cuộc tấn công diễn ra qua hai giai đoạn:
- Giai đoạn 1: Đưa mã PHP vào một file mà chính Magento tạo ra (ví dụ: khi tạo báo cáo lỗi).
- Giai đoạn 2: Kích hoạt Magento thực thi file đó bằng cách gửi email "Payment Transaction Failed Reminder" tiêu chuẩn của nền tảng. Mã sẽ chạy khi Magento dựng (render) tin nhắn, vì vậy không cần ai phải mở email, và cuộc tấn công vẫn thành công ngay cả khi việc gửi email thất bại.
Disrex cho biết chuỗi exploit kết thúc bằng việc bao gồm (include) một đường dẫn file mà kẻ tấn công đã chọn. PHP dropper được thực thi sẽ thử 6 hàm PHP khác nhau để bắt đầu một tiến trình, sau đó tải xuống và khởi chạy implant.
Các chỉ số nhận diện (Indicators of Compromise - IoC)
- Process:
[kworker/u:8:0]thuộc sở hữu của người dùng không phải root. - File:
~/.local/share/.gvfsd/gvfsd-user - File:
~/.local/share/.gvfsd/.gvfsd_<8hex>.lock - Cron:
*/5 * * * * exec <home>/.local/share/.gvfsd/gvfsd-user - SHA-256:
e315687a1dfe61ef4a5a5642214db6d3b2b05d81391285eebc2af664641a26a7 - Domain:
247.cdnflare[.]xyz(máy chủ tải malware) - IP:
99.84.67[.]186:443(C2 qua WebSocket và TLS) - IP:
88.216.72[.]181(nguồn tấn công)
Khuyến nghị phòng ngừa và xử lý
Trong khi chờ đợi bản vá chính thức từ Adobe, các quản trị viên có thể xem xét các phương án sau:
- Vô hiệu hóa GraphQL nếu không cần thiết.
- Sử dụng các quy tắc nginx và Apache để chặn các yêu cầu mang theo tham số exploit trong chuỗi truy vấn URL.
- Thêm
proc_openvào danh sáchdisable_functionscủa PHP. - Gắn kết (mount)
/tmp,/var/tmpvà/dev/shmvới tùy chọnnoexecđể ngăn binary được tải xuống có thể thực thi.
Đối với các cửa hàng đã bị nhiễm, quy trình dọn dẹp cần ưu tiên bảo tồn bằng chứng, xóa mục cron trước khi dừng tiến trình (vì tiến trình sẽ tự khôi phục cron), và xoay vòng toàn bộ mật khẩu quản trị, API key và các thông tin tích hợp khác.
