Giới thiệu
Gần đây có một chiến dịch lớn nhắm vào các site chạy WordPress với biểu hiện khi truy cập bằng mobile sẽ bị chuyển hướng sang các website “scam”, còn trên giao diện desktop thì vẫn bình thường. Hiện ở Việt Nam cũng đang có rất nhiều site bị và các admin chưa xác định được nguyên nhân.
Tình trạng này nghe có vẻ giống với các cuộc tấn công bằng mã độc (web shell) lần trước, tuy nhiên lần này không tấn công bằng mã độc PHP mà sử dụng Javascript với nhiều điểm thú vị. Hãy cùng đọc hết bài phân tích case study này nhé!
Tình trạng
Website truy cập bình thường trên desktop nhưng khi truy cập bằng mobile thì bị chuyển hướng sang các web khác, truy cập trực tiếp hay truy cập về từ Google đều bị chuyển hướng. Tình trạng này xảy ra chập chờn, lúc bị lúc không nên khó debug.
Truy vết
Đợt tấn công lần này không giống với những Case Study trước đó mình chia sẻ. Thao tác chuyển hướng xảy ra “sau khi” website vừa load xong giao diện. Điểm này cực kỳ quan trọng giúp khoanh vùng và lựa chọn cách tiếp cận phân tích. Vì sao?
- Việc thực hiện Redirect nếu được config trên web server (nginx, apache), .htaccess hoặc bằng code thì truy cập sẽ bị redirect ngay lập tức.
- Việc redirect “sau khi” ta thấy được giao diện website cho thấy khả năng rất lớn redirect bằng cách sử dụng Javascript.
Do đó, thay vì scan mã độc ở server, mình tiến hành bật Developer Tools, truy cập vào website và soi kỹ vào các file Javascript. Chọn qua tab “Initator” và tập trung vào những “Request chain” đi ra khỏi website của mình. Qua đó, khoanh vùng được vài file JS cùng domain khả nghi (code của chúng bị mã hoá).
View-page source thì xác nhận file “sold.js” đang được chèn vào nội dung do server trả về cho người dùng. File này cũng xác nhận là file js độc hại => Cần tìm coi được chèn vào bằng cách nào.
Nhảy lên server tìm hết trong code => không phát hiện ra file nào liên quan dùng để chèn nội dung này. Quét mã độc cũng ko thấy gì (imunify cũng scan không thấy). Tìm những file có thay đổi gần đây cũng ko thấy gì. Đến đây thì lại có 2 khả năng xảy ra:
- Chuỗi được chèn vào đã bị mã hoá trong source trước khi chèn nên tìm không ra => nếu vậy thì sẽ rất khó để tìm ra
- Không lưu trong source mà lưu trong DB => cái này dễ hơn nên làm trước
Vào phpMyadmin search chuỗi “sold.js” => Xuất hiện record trong wp_options.
Giờ thấy chèn rồi mà cũng chưa biết sao nó chèn được, bèn cầm cái option_name “td_live_css_local_storage” đi research thì thấy 1 loạt bài phân tích chi tiết liên quan đến chiến dịch tấn công vào lỗ hổng này.
Phân tích
Đợt tấn công lần này chủ đích nhắm vào các website bị lỗi XSS (Cross Site Scripting) – đặc biệt là Stored XSS.
XSS là lỗi bảo mật cho phép attacker có thể chèn javascript và thực thi trên Trình duyệt người dùng. Có 2 loại XSS (Stored và Reflected), trong đó Stored XSS là các mã Javscript độc hại sẽ được lưu lại trên server, nên bất kì người dùng nào truy cập vào cũng sẽ bị thực thi các mã độc hại này trên chính Trình duyệt của họ (chứ ko phải thực thi trên server).
Hiện tại có khá nhiều plugin đang bị dính lỗi Stored XSS. Trong case này, website sử dụng theme Newspaper, và theme này đi kèm với plugin “tagDiv Composer”, plugin này có tồn tại lỗi Stored XSS và attacker đã lợi dụng để chèn đoạn javascript độc hại phía trên vào. Vì là theme, nên đoạn javascript trên được chèn trên tất cả các trang của website.
Do XSS thực thi javascript ở phía trình duyệt của user – không phải thực thi trên server nên thường được dùng để ăn cắp cookie chiếm quyền admin. Tuy nhiên, nhóm hacker lần này đã khôn khéo tận dụng chính trình duyệt của admin để cài mã độc lên server. Nghe tò mò lắm đúng không?
Attacker đã thiết kế 1 đoạn code để check xem người truy cập có phải đang là admin hay không? Nếu đúng là admin thì dùng chính trình duyệt họ đang truy cập và đã đăng nhập với quyền admin để gọi lên URL cài đặt plugin (đoạn /wp-admin/plugin/plugin-install.php) để đẩy mã độc lên server và kích hoạt chúng. Mã độc sau khi được cài đặt sẽ kết nối về C&C (server điều khiển) để ghi log và sẵn sàng nhận mệnh lệnh tiếp theo. Đây là điểm khá thú vị và khác biệt hoàn toàn so với các cuộc tấn công trước, vốn dựa nhiều vào lỗi RCE (Remote Code Execution) để tải mã độc về.
Ngoài ra cài mã độc, đoạn javascript còn dùng chính trình duyệt của admin để tự động tạo thêm user admin khác, phòng cho trường hợp cài đặt plugin & kích hoạt thất bại.
Đến đây, quá trình khai thác lỗ hổng, chiếm quyền điều khiển và duy trì quyền kiểm soát đã thành công. Attacker lúc này đã toàn quyền kiểm soát website và thực hiện các hành động chúng mong muốn (hãy cầu nguyện là chúng mã hoá hết source và xoá database)
Xử lý
- Xoá các dữ liệu do XSS chèn vào
- Rà quét toàn bộ website để loại bỏ các mã độc PHP bị chèn vào (nếu có)
- Xoá các plugin lạ ko rõ chức năng, nguồn gốc. Đặc biệt lưu ý, trong chiến dịch tấn công lần này attacker thường cài đặt thêm plugin Custom JS and CSS. Đây cũng có thể xem là dấu hiệu nhận biết site bạn đã bị thịt.
- Reinstall WordPress core files
- Kiểm tra các file index.php, 404.php, wp-blog-header.php, header.php và footer.php xem có bị inject mã độc không.
- Xoá các file js sau (backup trước khi xoá): /wp-includes/js/jquery/jquery-migrate.min.js, /wp-includes/js/jquery/jquery.min.js và /wp-includes/js/wp-emoji-release.min.js.
- Update toàn bộ theme và plugin lên bản mới nhất để và lỗ hổng. Mà tốt hơn hết là gỡ ra rồi cài lại bản mới hết để phòng trường hợp backdoor bị chèn vào plugin/theme.
- Xoá các user admin lạ.
- Đổi toàn bộ password, bao gồm password admin, database, cpanel, email
- Secure khu vực admin (captcha, 2fa, change path…)
- Monitor danh sách file mới hoặc bị chỉnh sửa mỗi ngày.
Trích: Nguyễn Hưng (Bo) – Admin Vietnix
