NỘI DUNG
CVE-2026-73570 là lỗ hổng Remote Code Execution (RCE) trong Zimbra Collaboration Suite (ZCS), liên quan đến cơ chế SNMP notification/logwatch. Lỗ hổng này cho phép attacker chưa xác thực gửi SMTP request được tạo đặc biệt để thực thi lệnh hệ điều hành dưới quyền user zimbra.
Theo mô tả từ NVD, lỗ hổng ảnh hưởng đến Zimbra trước phiên bản 10.1.20 khi hệ thống có cài package SNMP và bật SNMP notification. The Hacker News cũng ghi nhận lỗ hổng này đã bị khai thác thực tế để chạy mã độc trên máy chủ Zimbra.
Nói ngắn gọn, chuỗi tấn công có thể hiểu như sau:
Attacker gửi SMTP request độc hại
→ Zimbra xử lý SNMP notification không an toàn
→ attacker chạy được lệnh dưới user zimbra
→ tải malware vào /dev/shm
→ thêm cron để tự chạy lại
→ chạy miner hoặc backdoorCVE-2026-73570 là gì?
CVE-2026-73570 là lỗi OS Command Injection trong Zimbra Collaboration Suite. Lỗi nằm ở phần xử lý SNMP notification, khi dữ liệu đầu vào không được làm sạch đúng cách trước khi được truyền vào luồng xử lý thông báo.
Điểm nguy hiểm là attacker có thể khai thác từ xa qua SMTP mà không cần tài khoản hợp lệ. Lệnh được chạy dưới quyền zimbra. Đây không phải quyền root, nhưng vẫn rất nguy hiểm vì user zimbra là user vận hành chính của hệ thống Zimbra.
Điều kiện máy chủ có nguy cơ
Máy chủ Zimbra có nguy cơ cao nếu có các điều kiện sau:
- Đang chạy Zimbra Collaboration Suite.
- Phiên bản chưa được vá theo khuyến nghị của Zimbra.
- Có package
zimbra-snmphoặczimbra-net-snmp. - SNMP service đang được enable trong Zimbra.
zmlogswatchhoặczmswatchđang hoạt động.
Kiểm tra nhanh:
su - zimbra -c 'zmcontrol -v'
dpkg -l | grep -E 'zimbra-snmp|zimbra-net-snmp'
su - zimbra -c 'zmprov gs $(zmhostname) zimbraServiceEnabled | grep snmp'
su - zimbra -c 'zmlogswatchctl status'
su - zimbra -c 'zmswatchctl status'Nếu thấy zimbraServiceEnabled: snmp và zmlogswatch is running, cần kiểm tra dấu hiệu compromise ngay.
Dấu hiệu Zimbra đã bị khai thác
Trong các case bị khai thác, malware thường được đặt trong /dev/shm vì đây là tmpfs, có thể ghi nhanh và dễ bị admin bỏ sót.
Kiểm tra:
ls -la /dev/shm
crontab -l -u zimbra
ps aux | grep -E 'khp|rguard|javab|idle|ksmd' | grep -v grep
Các file đáng nghi thường gặp:
/dev/shm/.khp
/dev/shm/.khp_ts
/dev/shm/.rguard
/dev/shm/idle
/dev/shm/javab
/dev/shm/ksmd
Nếu crontab user zimbra có dòng sau thì gần như chắc chắn đã có persistence:
* * * * * /dev/shm/.khp
Vì sao mã độc cứ tự tạo lại?
Chỉ xoá file trong /dev/shm thường không đủ. Malware có thể quay lại vì nhiều nguyên nhân:
- Process malware vẫn còn chạy trong RAM.
- Cron user
zimbrachạy lại/dev/shm/.khpmỗi phút. - Script
.rguardhoặcidletự bảo vệ payload. - SNMP/logwatch vẫn bật nên attacker có thể khai thác lại CVE.
Vì vậy thứ tự xử lý đúng phải là:
Chặn nguồn tái nhiễm
→ Backup evidence
→ Kill process malware
→ Xoá cron độc
→ Quarantine file malware
→ Verify sạch
→ Recovery dịch vụ Zimbra nếu cần
→ Patch/upgrade ZimbraCách xử lý CVE-2026-73570 và malware Zimbra
Các lệnh dưới đây nên chạy bằng user root. Trước khi thao tác trên server production, nên backup và hiểu rõ tác động của từng bước.
Bước 1: Dừng nguồn tái nhiễm
systemctl stop cron
su - zimbra -c 'zmlogswatchctl stop'
su - zimbra -c 'zmswatchctl stop'
su - zimbra -c 'zmprov ms $(zmhostname) -zimbraServiceEnabled snmp'
Việc disable SNMP/logwatch là điểm quan trọng nhất trong quá trình containment. Nếu chưa patch Zimbra, không nên bật lại các thành phần này.
Bước 2: Backup lại thông tin mã độc
mkdir -p /root/incident-zimbra
cp -a /dev/shm/.khp \
/dev/shm/.khp_ts \
/dev/shm/.rguard \
/dev/shm/idle \
/dev/shm/javab \
/dev/shm/ksmd \
/root/incident-zimbra/ 2>/dev/null
crontab -l -u zimbra > /root/incident-zimbra/zimbra-cron-before.txt 2>&1
ps auxf > /root/incident-zimbra/ps-before.txt
ss -tunap > /root/incident-zimbra/ss-before.txt
sha256sum /root/incident-zimbra/* > /root/incident-zimbra/sha256.txt 2>/dev/nullBước 3: Kill process malware
pkill -9 -u zimbra -f 'khp|rguard|javab|idle|ksmd'Bước 4: Xoá cron độc
crontab -l -u zimbra | grep -v '/dev/shm/.khp' | crontab -u zimbra -Bước 5: Quarantine file malware
mkdir -p /root/quarantine-zimbra
mv /dev/shm/.khp \
/dev/shm/.khp_ts \
/dev/shm/.rguard \
/dev/shm/idle \
/dev/shm/javab \
/dev/shm/ksmd \
/root/quarantine-zimbra/ 2>/dev/nullBước 6: Bật lại cron
systemctl start cron
systemctl is-active cronChỉ bật lại cron. Không bật lại zmlogswatch, zmswatch hoặc SNMP nếu chưa patch Zimbra.
Kiểm tra sau khi dọn
ls -la /dev/shm
crontab -l -u zimbra | grep /dev/shm
ps aux | grep -E 'khp|rguard|javab|idle|ksmd' | grep -v grep
su - zimbra -c 'zmprov gs $(zmhostname) zimbraServiceEnabled | grep snmp || echo SNMP_DISABLED'Kết quả mong muốn:
/dev/shmtrống.- Không còn cron gọi
/dev/shm/.khp. - Không còn process
javab,rguard,idle. - SNMP đã disabled.
Nếu Zimbra MySQL hoặc mailbox bị lỗi
Sau khi bị malware hoặc reboot đột ngột, Zimbra có thể gặp lỗi:
mailbox Stopped
mysql.server is not running
service webapp Stopped
zimbra webapp Stopped
zimbraAdmin webapp Stopped
zimlet webapp StoppedKiểm tra MySQL:
su - zimbra -c 'zmcontrol status'
su - zimbra -c 'mysql.server status'
ss -ltnp | grep 7306
tail -n 200 /opt/zimbra/log/mysql_error.logNếu MySQL bị kẹt ở crash recovery hoặc còn stale socket, có thể recovery nhẹ theo hướng backup trước rồi cho MySQL tự tạo lại socket và tc.log.
Backup trước khi recovery
mkdir -p /root/zimbra-mysql-backup
cp -a /opt/zimbra/log/mysql_error.log /root/zimbra-mysql-backup/ 2>/dev/null
cp -a /opt/zimbra/db/data/tc.log /root/zimbra-mysql-backup/ 2>/dev/null
cp -a /opt/zimbra/data/tmp/mysql/mysql.sock /root/zimbra-mysql-backup/ 2>/dev/null
cp -a /opt/zimbra/db/data/ibdata1 /root/zimbra-mysql-backup/ 2>/dev/null
cp -a /opt/zimbra/db/data/ib_logfile* /root/zimbra-mysql-backup/ 2>/dev/nullRecovery MySQL nhẹ
su - zimbra -c 'zmmailboxdctl stop'
mv /opt/zimbra/data/tmp/mysql/mysql.sock /root/zimbra-mysql-backup/mysql.sock.bak 2>/dev/null
mv /opt/zimbra/db/data/tc.log /root/zimbra-mysql-backup/tc.log.bak 2>/dev/null
su - zimbra -c 'mysql.server start'
sleep 20
su - zimbra -c 'mysql.server status'
su - zimbra -c 'zmmailboxdctl start'
sleep 40
su - zimbra -c 'zmcontrol status'Kết quả mong muốn:
mysql is running
mailbox Running
service webapp Running
zimbra webapp Running
zimbraAdmin webapp Running
zimlet webapp Running
Có mất dữ liệu mail không?
Các bước dọn malware, disable SNMP/logwatch, kill process và quarantine file trong /dev/shm không đụng đến dữ liệu mail.
Dữ liệu mail Zimbra thường nằm tại:
/opt/zimbra/store/Database Zimbra nằm tại:
/opt/zimbra/db/data/Riêng bước recovery MySQL có thao tác với tc.log và mysql.sock, vì vậy cần backup trước. Đây không phải thao tác xoá mailbox, nhưng vẫn cần cẩn thận vì liên quan database metadata.
Kiểm tra các file JSP
Sau khi xử lý xong các phần trên cũng nên xem xét các tệp được tạo bởi người dùng Zimbra trong 30 ngày qua. Các thư mục quan trọng nhất cần điều tra là /opt/zimbra/jetty/webapps/, /opt/zimbra/jetty_base/webapps/ và /tmp/. Các tệp JSP không mong muốn, tập lệnh thực thi, kho lưu trữ hoặc nội dung ứng dụng được sửa đổi gần đây tại các vị trí này có thể cho thấy việc dàn dựng payload hoặc thiết lập quyền truy cập.
find /opt/zimbra/jetty/webapps -type f \( -name "*.jsp" -o -name "*.jspx" \) -printf '%TY-%Tm-%Td %TH:%TM:%TS %p\n' | sort
Các file JSP này là backdoor hiện vẫn còn trong jetty webapps. Nên cần backup evidence rồi quarantine/xoá các JSP độc khỏi cả 2 path:
/opt/zimbra/jetty/webapps/zimbra/
/opt/zimbra/jetty_base/webapps/zimbra/TS=$(date +%Y%m%d_%H%M%S)
INC=/root/incident-zmmail-jsp-webshell-$TS
QUA=/root/quarantine-zmmail-jsp-webshell-$TS
mkdir -p "$INC" "$QUA"
# Lưu danh sách + hash
find /opt/zimbra/jetty/webapps/zimbra /opt/zimbra/jetty_base/webapps/zimbra \
-xdev -type f \( -iname '*.jsp' -o -iname '*.jspx' \) -mtime -30 \
-print > "$INC/suspicious-jsp-list.txt"
xargs -a "$INC/suspicious-jsp-list.txt" sha256sum > "$INC/suspicious-jsp-sha256.txt"
# Backup mẫu
while read f; do
mkdir -p "$INC/files$(dirname "$f")"
cp -a "$f" "$INC/files$f"
done < "$INC/suspicious-jsp-list.txt"
# Quarantine khỏi webroot
while read f; do
mkdir -p "$QUA$(dirname "$f")"
mv "$f" "$QUA$f"
done < "$INC/suspicious-jsp-list.txt"
# Verify
find /opt/zimbra/jetty/webapps/zimbra /opt/zimbra/jetty_base/webapps/zimbra \
-xdev -type f \( -iname '*.jsp' -o -iname '*.jspx' \) -mtime -30 -printRủi ro có thể gặp
- Nếu file nào là JSP hợp lệ/custom thì có thể ảnh hưởng chức năng webmail custom.
- Nhưng các tên random và nội dung exec/base64/AES cho thấy gần như chắc là webshell.
- Không ảnh hưởng dữ liệu mail.
- Không cần restart ngay, nhưng sau quarantine nên verify webmail.
Việc cần làm sau khi hệ thống chạy lại
- Giữ SNMP/logwatch tắt nếu chưa patch.
- Theo dõi
/dev/shmtrong 30-60 phút. - Theo dõi crontab user
zimbra. - Theo dõi CPU/load và outbound connection.
- Kiểm tra mail queue.
- Update/patch Zimbra lên bản đã vá CVE.
- Chỉ bật lại SNMP/logwatch sau khi đã patch và kiểm tra an toàn.
Kiểm tra queue:
/opt/zimbra/common/sbin/postqueue -p | tail -n 40Lưu ý quan trọng
Một điểm cần lưu ý sau khi tắt SNMP/logwatch để giảm thiểu CVE-2026-73570 là zmlogswatch và zmswatch có thể tự chạy lại sau thời điểm logrotate hằng ngày hoặc sau khi zmcontrol restart.
Nguyên nhân là trong cấu hình logrotate của Zimbra thường có các dòng postrotate tự gọi zmlogswatchctl restart và zmswatchctl restart; đồng thời service logger vẫn nằm trong zimbraServiceEnabled. Vì vậy, sau khi tắt tạm thời, quản trị viên nên kiểm tra lại trạng thái các dịch vụ này định kỳ, đặc biệt sau 00:00 hoặc sau khi restart Zimbra.
Nếu cần chặn triệt để trong giai đoạn chưa vá, có thể backup rồi comment các dòng restart trong /etc/logrotate.d/zimbra và /opt/zimbra/conf/zmlogrotate, đồng thời cân nhắc remove logger khỏi zimbraServiceEnabled. Việc này giúp tránh logwatch tự bật lại và tái mở vector khai thác, nhưng có thể làm Admin Console mất một phần thống kê/monitoring.
Cách tắt zmlogswatch/zmswatch để tránh tự bật lại:
Lưu ý: Việc tắt logger, zmlogswatch và zmswatch có thể khiến Admin Console hiển thị trạng thái logger/monitoring màu đỏ hoặc mất một phần biểu đồ thống kê. Tuy nhiên trong giai đoạn chưa vá CVE-2026-73570, đây là biện pháp cần thiết để tránh logwatch tự bật lại và tái mở vector khai thác. Sau khi nâng cấp lên bản đã vá, quản trị viên có thể khôi phục cấu hình từ file backup và bật lại logger nếu cần.
Trước tiên backup cấu hình logrotate của Zimbra:
cp -a /etc/logrotate.d/zimbra /etc/logrotate.d/zimbra.bak.$(date +%F-%H%M%S)
cp -a /opt/zimbra/conf/zmlogrotate /opt/zimbra/conf/zmlogrotate.bak.$(date +%F-%H%M%S)Sau đó mở 2 file:
/etc/logrotate.d/zimbra
/opt/zimbra/conf/zmlogrotateTìm 2 dòng: (Thường nằm dòng thứ 85 và 99)
su - zimbra -c "/opt/zimbra/bin/zmlogswatchctl restart" > /dev/null 2>&1 || true
su - zimbra -c "/opt/zimbra/bin/zmswatchctl restart" > /dev/null 2>&1 || true
Comment lại thành:
# su - zimbra -c "/opt/zimbra/bin/zmlogswatchctl restart" > /dev/null 2>&1 || true
# su - zimbra -c "/opt/zimbra/bin/zmswatchctl restart" > /dev/null 2>&1 || trueTiếp theo tắt logger service khỏi danh sách service enabled:
su - zimbra -c 'zmprov ms $(zmhostname) -zimbraServiceEnabled logger'Sau đó tắt các process logwatch/swatch hiện tại:
su - zimbra -c 'zmlogswatchctl stop'
su - zimbra -c 'zmswatchctl stop'
su - zimbra -c 'zmlocalconfig -e snmp_notify=no'Kiểm tra lại:
su - zimbra -c 'zmlogswatchctl status'
su - zimbra -c 'zmswatchctl status'
su - zimbra -c 'zmlocalconfig snmp_notify'
su - zimbra -c 'zmprov gs $(zmhostname) zimbraServiceEnabled | egrep "logger|snmp" || echo "LOGGER_SNMP_DISABLED"'Kết quả
zmlogswatch is not running.
zmswatch is not running.
snmp_notify = no
LOGGER_SNMP_DISABLEDTrường hợp đã fix CVE và muốn bật lại monitoring/logger
su - zimbra -c 'zmprov ms $(zmhostname) +zimbraServiceEnabled logger'
su - zimbra -c 'zmlogswatchctl start'
su - zimbra -c 'zmswatchctl start'Nếu trước đó đã comment logrotate, thì mở lại 2 file:
/etc/logrotate.d/zimbra
/opt/zimbra/conf/zmlogrotateBỏ dấu # ở 2 dòng:
su - zimbra -c "/opt/zimbra/bin/zmlogswatchctl restart" > /dev/null 2>&1 || true
su - zimbra -c "/opt/zimbra/bin/zmswatchctl restart" > /dev/null 2>&1 || true
Nếu muốn bật lại SNMP Chỉ bật lại khi đã vá/nâng cấp an toàn:
su - zimbra -c 'zmprov ms $(zmhostname) +zimbraServiceEnabled snmp'
su - zimbra -c 'zmlocalconfig -e snmp_notify=yes'
su - zimbra -c 'zmswatchctl start'Verify sau khi bật
su - zimbra -c 'zmcontrol status'
su - zimbra -c 'zmlogswatchctl status'
su - zimbra -c 'zmswatchctl status'
su - zimbra -c 'zmlocalconfig snmp_notify'
su - zimbra -c 'zmprov gs $(zmhostname) zimbraServiceEnabled | egrep "logger|snmp"'Tóm tắt quy trình xử lý
1. Kiểm tra /dev/shm, process và crontab.
2. Dừng cron, zmlogswatch, zmswatch.
3. Disable SNMP trong Zimbra.
4. Backup evidence.
5. Kill process malware.
6. Xoá cron độc.
7. Quarantine file malware.
8. Bật lại cron.
9. Verify malware không tái tạo.
10. Recovery MySQL/mailbox nếu cần.
11. Theo dõi queue và service.
12. Patch/upgrade Zimbra.Nguồn tham khảo
- NVD – CVE-2026-73570
- The Hacker News – Attackers Exploit Zimbra SNMP Flaw
- Zimbra Security Center
- Zimbra Security Advisories
- Lỗ hổng CVE-2026-73570
Kết luận
CVE-2026-73570 là lỗ hổng nghiêm trọng vì có thể cho phép attacker thực thi lệnh từ xa dưới quyền user zimbra thông qua cơ chế SNMP notification/logwatch.
Khi bị khai thác, attacker thường cài malware vào /dev/shm, thêm cron để tự chạy lại và chạy miner gây tải cao cho server. Điểm quan trọng khi xử lý là không chỉ xoá file malware, mà phải chặn nguồn tái nhiễm trước.
Thứ tự xử lý đúng là:
Tắt cron + SNMP/logwatch → backup evidence → kill malware → xoá cron độc → quarantine file → verify sạch → recovery Zimbra nếu cần → patch/upgrade Zimbra.
Quan trọng nhất: không bật lại SNMP/logwatch khi chưa vá Zimbra, vì đây có thể là nguồn làm mã độc tái xuất hiện.
Với kinh nghiệm thực chiến từ việc tiếp xúc hàng ngày với vô vàn vấn đề về Website, Hosting, VPS, Server tại Phòng Kỹ thuật AZDIGI, mình luôn ấp ủ niềm đam mê chia sẻ kiến thức.
Mình xây dựng các blog không chỉ để tự trau dồi kỹ năng mà còn để cung cấp những tài liệu, hướng dẫn hữu ích nhất đến cộng đồng. Rất mong nhận được sự quan tâm của các bạn!
Để lại thông tin, mình sẽ phản hồi ngay.
wpDiscuz