Bởi ITCuli

CVE-2026-73570 trên Zimbra: kiểm tra ngay máy chủ mail có bật SNMP

Cảnh báo Zimbra Vulnerability Exploited Wild: rủi ro cần kiểm tra ngay

CVE-2026-73570 trên Zimbra: vá khẩn cấp và kiểm tra dấu hiệu xâm nhập

Quản trị viên mail server cần xem CVE-2026-73570 là việc vừa phải vá lỗi, vừa phải điều tra an ninh. SecurityWeek cho biết lỗ hổng mức độ cao này ảnh hưởng Zimbra Collaboration Suite (ZCS) trước phiên bản 10.1.20, có điểm CVSS 8.9. Đây là lỗi chèn lệnh hệ điều hành trong quá trình xử lý thông báo SNMP: dữ liệu đầu vào không đáng tin cậy không được làm sạch đúng cách. Khi hội đủ điều kiện cấu hình, kẻ tấn công từ xa không cần xác thực có thể chạy lệnh với quyền của người dùng Zimbra.

Tổng quan CVE-2026-73570 trên Zimbra
CVE-2026-73570 tác động các hệ thống Zimbra có cấu hình SNMP liên quan.

Hệ thống nào có nguy cơ?

Đường khai thác không chỉ phụ thuộc vào việc máy chủ đang chạy Zimbra. Theo nguồn, gói tùy chọn zimbra-snmp phải được cài và thông báo SNMP phải được bật. Khi đó, yêu cầu SMTP được tạo đặc biệt có thể chạm đến luồng xử lý không an toàn. Điều kiện này hữu ích cho việc phân loại ưu tiên, nhưng không nên dùng để trì hoãn kiểm tra: SMTP thường mở ra Internet, cấu hình giữa các mailbox node có thể khác nhau, còn máy dự phòng, máy thử nghiệm hoặc bản khôi phục cũ có thể bị bỏ quên.

Zimbra phát hành bản sửa trong ZCS 10.1.20 ngày 20/7/2026. Lỗ hổng được công bố công khai ngày 13/8. Microsoft quan sát hai công cụ quét out-of-band khác nhau dò điểm chèn lệnh từ 28/7 đến 7/8, tức sau khi có bản vá nhưng trước khi công bố. CERT Polska sau đó xác nhận khai thác thực tế và phát hành chỉ dấu xâm nhập ngày 17/8. Dòng thời gian này có nghĩa là một máy chưa được vá có thể đã bị dò quét hoặc xâm nhập trước khi đội vận hành biết đến CVE.

Phân tích ứng phó sự cố Zimbra
Bản vá đóng điểm vào; điều tra cần tìm cả hoạt động sau khai thác.

Hoạt động sau khi có quyền truy cập

Microsoft mô tả giai đoạn trinh sát dùng các probe out-of-band nhẹ để xác nhận khả năng thực thi lệnh mà chưa cần đưa payload. Hoạt động tiếp theo nghiêm trọng hơn: đối tượng đặt webshell JSP vào các đường dẫn Jetty và mailboxd có thể truy cập công khai, tải thêm nội dung bằng wget hoặc curl, chạy tiến trình nền và mở reverse shell tương tác. Nhiều bản sao JSP được đặt tại các mailbox node khác nhau, tạo đường truy cập thay thế trong cụm Zimbra.

Những hành động được ghi nhận gồm lập bản đồ cluster, nhận diện môi trường, kiểm tra Zimbra SSH identity và dùng công cụ Zimbra hợp pháp để leo thang lên root. Một dịch vụ systemd tên zimlog.service được dùng để duy trì truy cập. Kẻ tấn công còn nhắm đến bí mật dịch vụ tập trung cùng dữ liệu xác thực, sau đó dùng thông tin đăng nhập thu được để thực hiện LDAP query đã xác thực nhằm lấy bí mật giá trị cao. SSH identity sẵn có của Zimbra cũng có thể hỗ trợ di chuyển sang node khác. Vì vậy, nâng phiên bản không phải bằng chứng rằng môi trường đã sạch.

Checklist cần thực hiện ngay

  • Kiểm kê toàn bộ vai trò Zimbra, xác nhận phiên bản ZCS thực tế trên mailbox, proxy, dự phòng, lab và máy khôi phục.
  • Nâng cấp các instance bị ảnh hưởng lên ZCS 10.1.20 hoặc bản được hỗ trợ mới hơn theo quy trình backup và maintenance đã phê duyệt.
  • Kiểm tra sự hiện diện của zimbra-snmp. Gỡ gói này nếu không cần; nếu bắt buộc, tắt cấu hình thông báo dễ tổn thương.
  • Chỉ cho phép mạng và host cần thiết truy cập SMTP, SNMP. Rà lại firewall, relay và mạng quản trị.
  • Rà log từ cuối tháng 7/2026 để tìm SMTP bất thường, callback HTTP/HTTPS, tải xuống lạ, tiến trình nền và hành vi reverse shell.
  • Săn tìm file JSP không mong đợi trong đường dẫn Jetty, mailboxd và trên các mailbox node cùng cụm.
  • Kiểm tra systemd, cron, tài khoản, SSH key và thay đổi quyền; điều tra ngay zimlog.service nếu không có giải thích nội bộ đã xác minh.
Checklist xử lý CVE-2026-73570 Zimbra
Xác nhận kết quả vá và threat hunting trên từng node.

Khôi phục và xác minh

Nếu có chỉ dấu truy cập trái phép, hãy cô lập máy theo kế hoạch ứng phó sự cố và lưu giữ log, thông tin tiến trình, bằng chứng ổ đĩa trước khi xóa artefact hoặc khởi động lại. Luân chuyển có kiểm soát các thông tin xác thực Zimbra, quản trị, LDAP, dịch vụ và SSH có thể đã lộ. Sau maintenance, xác minh độc lập từng node: phiên bản đang chạy, luồng mail, xác thực, mobile client, backup, monitoring, danh sách dịch vụ và kết nối outbound. So sánh thư mục ứng dụng cùng systemd unit với baseline tin cậy.

Mục tiêu không phải là một bảng điều khiển ghi “đã vá”. Mục tiêu là kết luận có tài liệu: mọi hệ thống Zimbra liên quan đã được kiểm tra, bề mặt tấn công đã giảm, điểm duy trì truy cập đã được rà soát và thông tin xác thực vẫn đáng tin. Nếu đội nội bộ không thể lập timeline hoặc baseline sạch đáng tin cậy, cần huy động đơn vị ứng phó sự cố.

Nguồn

Bài viết được biên soạn từ báo cáo của SecurityWeek về CVE-2026-73570, gồm thông tin quan sát của Microsoft và hướng dẫn khắc phục được trích dẫn.