ช่องโหว่ Zimbra แค่รับอีเมลก็รันคำสั่งได้ แพตช์อย่างเดียวอาจไม่พอ

เมื่อ 30 กันยายน 2026 Microsoft Security Research เปิดเผยรายละเอียดการโจมตี CVE-2026-73570 บนเซิร์ฟเวอร์ Zimbra Collaboration Suite ที่รับอีเมลจากอินเทอร์เน็ต อีเมลที่สร้างขึ้นเฉพาะสามารถนำข้อมูลของผู้โจมตีเข้าสู่ระบบแจ้งเตือน SNMP และทำให้เซิร์ฟเวอร์รันคำสั่งได้โดยไม่ต้องเข้าสู่ระบบหรือให้ผู้รับเปิดอีเมล แต่เส้นทางนี้ใช้ได้เมื่อเครื่องติดตั้งแพ็กเกจเสริม zimbra-snmp และเปิด SNMP notifications การสืบสวนพบทั้ง web shell, reverse shell, การยกระดับสิทธิ์ และการเก็บข้อมูลยืนยันตัวตนกับข้อมูลกล่องจดหมาย

The Hacker News รายงานในวันเดียวกันว่าช่องโหว่นี้มีคะแนน CVSS 8.9 และ Zimbra แก้ไขแล้วในรุ่น 10.1.20 คำตอบสำหรับผู้ดูแลจึงมีสองส่วนที่ต้องทำต่อเนื่องกัน: ตรวจว่าเครื่องเคยครบเงื่อนไขเสี่ยงหรือไม่ แล้วอัปเดตพร้อมค้นหาหลักฐานการบุกรุกย้อนหลัง เครื่องที่แสดงรุ่นใหม่ในวันนี้ยังอาจมี web shell หรือข้อมูลรับรองที่ถูกคัดลอกไว้ตั้งแต่ก่อนอัปเดต

ตรวจเงื่อนไขเสี่ยงจากเครื่องที่รับเมลจริง

จุดเริ่มต้นคือรายชื่อโหนด Zimbra ที่รับคำขอ SMTP จากภายนอก ไม่ใช่รายชื่อบัญชีผู้ใช้หรือผู้ที่เปิดอีเมล หากโหนดใดใช้รุ่นก่อนแก้ไข ติดตั้ง zimbra-snmp และเปิด SNMP notifications พร้อมกัน ให้จัดโหนดนั้นอยู่ในกลุ่มที่ต้องตรวจการโจมตีย้อนหลัง การพบเพียงชื่อแพ็กเกจในรายการที่ดาวน์โหลดไว้ยังบอกไม่ได้ว่ามีการติดตั้งและใช้งานจริง จึงต้องดูสถานะบนเครื่องและประวัติการตั้งค่าประกอบกัน

ลำดับตัดสินใจสำหรับแต่ละโหนดควรเป็นดังนี้

1. ระบุรุ่น Zimbra ที่ทำงานอยู่ และช่วงเวลาที่เครื่องรับ SMTP จากอินเทอร์เน็ต หากมีการอัปเดตแล้ว ให้เก็บเวลาที่อัปเดตไว้เพื่อกำหนดช่วงค้นบันทึกย้อนหลัง
2. ตรวจว่า zimbra-snmp ติดตั้งอยู่หรือเคยติดตั้งในช่วงที่ใช้รุ่นเสี่ยง พร้อมตรวจว่า SNMP notifications เปิดอยู่ในช่วงเดียวกันหรือไม่ การปิดฟังก์ชันในปัจจุบันไม่ได้ลบความเสี่ยงในอดีต
3. หากครบเงื่อนไขในช่วงใด ให้แพตช์และตรวจร่องรอยของช่วงนั้น หากตรวจประวัติแพ็กเกจหรือการตั้งค่าไม่ได้ ให้บันทึกส่วนที่ยังไม่ทราบและตรวจเครื่องด้วยขอบเขตเดียวกับเครื่องที่อาจเคยเสี่ยง

กลไกเกิดขึ้นบนเซิร์ฟเวอร์ เมื่อการเปลี่ยนสถานะบริการกระตุ้นการตรวจสุขภาพ swatchdog สามารถนำค่าที่ผู้โจมตีควบคุมจากคำขอ SMTP ไปประกอบคำสั่ง snmptrap ได้ หากค่านั้นมีอักขระควบคุม shell คำสั่งที่แทรกอยู่จะทำงานด้วยสิทธิ์ของบัญชีบริการ zimbra ดังนั้นการไม่พบผู้ใช้คลิกลิงก์หรือเปิดไฟล์แนบไม่ได้ช่วยตัดเหตุการณ์นี้ออกจากการสอบสวน

ในระบบที่แยกโหนดรับเมลกับโหนดเก็บกล่องจดหมาย ให้ตรวจรุ่น แพ็กเกจ และการตั้งค่าของแต่ละเครื่องแยกกัน ผู้โจมตีที่เข้าถึงโหนดหนึ่งอาจใช้ความไว้วางใจภายในคลัสเตอร์ไปยังโหนดอื่นได้ การคัดกรองเฉพาะเครื่องที่มีพอร์ต SMTP เปิดสู่ภายนอกจึงใช้ระบุทางเข้า ส่วนการค้นหาสิ่งที่ผู้โจมตีทิ้งไว้ต้องครอบคลุมโหนด mailbox ที่เกี่ยวข้องด้วย

อัปเดตขั้นต่ำ แล้วกำหนดช่วงตรวจย้อนหลัง

ตารางคำแนะนำความปลอดภัยของ Zimbra ระบุว่ารุ่น 10.1.20 แก้ command injection ในส่วน SNMP monitoring เมื่อเปิด SNMP notifications รุ่นนี้จึงเป็นขั้นต่ำสำหรับการแก้ช่องโหว่ดังกล่าว และรุ่นที่ใหม่กว่าต้องมีการแก้ไขนี้รวมอยู่ด้วย หลังอัปเดตให้ตรวจรุ่นที่กำลังทำงานบนทุกโหนด แทนการดูเพียงว่าเครื่องดาวน์โหลดแพ็กเกจหรือเริ่มกระบวนการอัปเดตแล้ว

หากยังอัปเดตไม่ได้ มาตรการลดความเสี่ยงที่เผยแพร่ไว้คือถอนแพ็กเกจเสริม zimbra-snmp ปิด SNMP notifications และจำกัดการเข้าถึง SNMP กับ SMTP ให้สอดคล้องกับโฮสต์ที่องค์กรเชื่อถือ การจำกัด SMTP ต้องคำนึงถึงเส้นทางรับเมลจริง มิฉะนั้นอาจทำให้บริการรับจดหมายหยุดชะงัก มาตรการเหล่านี้ใช้ลดช่องทางที่ยังเปิดอยู่ระหว่างรออัปเดต ส่วนเครื่องที่เคยครบเงื่อนไขต้องตรวจเหตุการณ์ก่อนเปลี่ยนการตั้งค่าด้วย

จุดเริ่มของการค้นย้อนหลังควรอิงวันที่เครื่องเข้าสู่สภาพเสี่ยงและช่วงเวลาที่องค์กรยังเก็บบันทึกได้ ไม่ใช่วันที่ติดตั้งแพตช์เพียงวันเดียว มีการพบการทดสอบเส้นทางรันคำสั่งในช่วงที่แพตช์ออกแล้วแต่ช่องโหว่ยังไม่เปิดเผยต่อสาธารณะ การมีรุ่นเก่าในช่วงนั้นเป็นเหตุให้ตรวจหลักฐานเพิ่มเติม แต่ยังไม่ใช่หลักฐานว่าเครื่องถูกเจาะ

ก่อนลบไฟล์หรือเปลี่ยนบริการบนเครื่องที่พบสิ่งผิดปกติ ควรเก็บบันทึก เหตุการณ์ของกระบวนการ และข้อมูลไฟล์ที่เกี่ยวข้องไว้เพื่อเรียงลำดับเวลา หลักฐานที่ใช้แยกการสแกนออกจากการเข้าควบคุมเครื่องอยู่ที่เหตุการณ์ต่อเนื่อง เช่น คำสั่งที่รันหลังการทดสอบ การเขียนไฟล์ในเว็บแอปพลิเคชัน หรือการเชื่อมต่อออกไปยังระบบภายนอก หากบันทึกบนเครื่องถูกหมุนทิ้งแล้ว ให้ใช้ข้อมูลจากระบบรวมบันทึกหรือสำเนาเก็บถาวรขององค์กรแทน

ล่าร่องรอยจากคำสั่งแรกไปถึง web shell

สัญญาณที่ชี้ตรงไปยังช่องโหว่นี้คือสายกระบวนการที่ Perl เรียกสคริปต์ swatchdog แล้วเปิด shell เพื่อรัน snmptrap ซึ่งมีอักขระควบคุม shell ปะปนในค่าบริการ คำสั่ง wget หรือ curl ที่ตามมาอาจบอกว่ามีการดึงเนื้อหาภายนอกมารัน แต่การพบ snmptrap ตามปกติเพียงรายการเดียวไม่มีน้ำหนักเท่ากัน การตรวจควรเชื่อมเวลา บัญชีที่รัน คำสั่งลูก และการเชื่อมต่อเครือข่ายไว้ในเหตุการณ์เดียว

การทดสอบครั้งแรกอาจจบลงเพียงคำสั่งตรวจตัวตนของเครื่องหรือการติดต่อกลับผ่าน DNS และ HTTP โดยยังไม่มีไฟล์อันตรายหลงเหลืออยู่ ในการสืบสวนมีการพบ User-Agent ชื่อ ZB73570 และการเรียกกลับไปยังโดเมนสำหรับทดสอบการโต้ตอบ รวมทั้งคำสั่งอย่าง nslookup, ping, curl และ wget จากสายกระบวนการเดียวกัน ตัวบ่งชี้เหล่านี้ช่วยกำหนดจุดค้น แต่ชื่อโดเมนหรือ User-Agent เปลี่ยนได้ง่าย จึงควรให้น้ำหนักกับความสัมพันธ์ของกระบวนการและเวลามากกว่าใช้รายการชื่อเพียงอย่างเดียว

หากผู้โจมตีติดตั้ง web shell จุดตรวจสำคัญคือไฟล์ JSP ที่เพิ่มหรือเปลี่ยนในไดเรกทอรีเว็บแอปพลิเคชันของ Jetty และ mailboxd รวมถึงพื้นที่ทำงานของ servlet ให้เทียบไฟล์เหล่านั้นกับชุดไฟล์ที่องค์กรอนุมัติ และตรวจไฟล์ต้นทางที่สร้างจาก JSP หรือไฟล์ที่คอมไพล์ตามมา การสืบสวนพบการวาง web shell หลายตำแหน่งและมีสำเนาบนโหนด mailbox อื่น การลบไฟล์ที่แจ้งเตือนเพียงไฟล์เดียวจึงอาจเหลือช่องทางเข้าถึงอีกตำแหน่ง

ผู้โจมตีบางรายเปิดสิทธิ์เขียนในไดเรกทอรีที่ให้บริการผ่านเว็บเพียงชั่วคราว วางไฟล์ แล้วคืนสิทธิ์เดิม การตรวจสิทธิ์ ณ เวลาปัจจุบันจึงควบคู่กับประวัติการเปลี่ยนสิทธิ์และเวลาที่ไฟล์ถูกสร้าง หากพบ Java หรือ jspawnhelper ของ Zimbra เรียก shell, mkfifo หรือ OpenSSL ในช่วงหลังไฟล์ JSP ปรากฏ ให้ตรวจว่ามีการเรียก web shell เพื่อรันคำสั่งหรือเปิด reverse shell หรือไม่

ช่องทางคงอยู่บนระบบปฏิบัติการต้องตรวจแยกจากไฟล์เว็บด้วย ในเหตุการณ์ที่เปิดเผย มีบริการ systemd ชื่อ zimlog.service ถูกติดตั้งในไดเรกทอรีบริการของระบบและตั้งให้เริ่มพร้อมเครื่อง พร้อมการแก้ไข PAM และสิทธิ์ sudo เพื่อให้บัญชี zimbra ยกระดับเป็น root ควรดูเจ้าของไฟล์ เวลาแก้ไข การเปิดใช้งานบริการ และบันทึกการรันจริงร่วมกัน เพราะชื่อที่ดูคล้ายส่วนประกอบของ Zimbra อาจเป็นส่วนหนึ่งของการปลอมตัว

การสำรวจคลัสเตอร์และการย้ายไฟล์เป็นอีกเหตุผลที่ต้องขยายการค้น ผู้โจมตีใช้เครื่องมือจัดการของ Zimbra เพื่อระบุบทบาทโหนด แล้วอาศัยตัวตน SSH ที่ระบบใช้เชื่อมโหนดกับ rsync เพื่อส่งชิ้นส่วนไฟล์และ web shell ไปยังเครื่องที่เชื่อถือกัน หากพบเหตุการณ์ลักษณะนี้ ให้ตรวจทั้งต้นทางและปลายทาง รวมถึงเว็บแอปพลิเคชันบนโหนดที่ไม่ได้รับ SMTP จากอินเทอร์เน็ตโดยตรง

เมื่อพบการบุกรุก ต้องประเมินข้อมูลรับรองชุดใด

หลังยืนยันว่ามีการรันคำสั่งหรือวางช่องทางคงอยู่ ให้ประเมินข้อมูลที่บัญชี zimbra เข้าถึงได้จากหลักฐานบนเครื่อง การโจมตีที่ตรวจพบใช้ zmlocalconfig -s อ่านข้อมูลรับรองของบริการ LDAP, MySQL, Postfix, Amavis และบริการจำลองข้อมูล จากนั้นใช้ข้อมูลที่ได้สอบถาม LDAP เพื่อดึง zimbraPreAuthKey, zimbraAuthTokenKey และ zimbraTwoFactorAuthSecret การเปลี่ยนรหัสผ่านกล่องจดหมายของผู้ใช้เพียงอย่างเดียวจึงไม่ครอบคลุมความลับระดับบริการและระบบยืนยันตัวตนเหล่านี้

ให้แยกการตอบสนองตามหลักฐานที่พบ: หากมีการอ่านค่าตั้งค่าของบริการ ให้เปลี่ยนข้อมูลรับรองที่อาจถูกเปิดเผยและตรวจระบบที่ใช้ค่าชุดเดียวกัน หากพบการดึงค่าใน LDAP ให้หมุน zimbraPreAuthKey ของทุกโดเมน และประเมินวิธีเปลี่ยนวัสดุลงนามโทเคนกับความลับการยืนยันตัวตนตามขั้นตอนที่ระบบรองรับ การเปลี่ยนค่าที่ใช้ร่วมกันอาจกระทบเซสชันและบริการอื่น จึงต้องวางลำดับการตัดสิทธิ์เดิมกับการออกค่าใหม่ให้สัมพันธ์กัน

หากพบการใช้ตัวตน SSH ของ Zimbra ข้ามโหนด ให้ตรวจความไว้วางใจระหว่างเครื่องและจัดการกุญแจที่อาจถูกเข้าถึงด้วย หากพบการแก้ PAM, sudo หรือบริการ systemd ให้ถือว่าการเปลี่ยนรหัสผ่านอย่างเดียวไม่ตัดสิทธิ์ที่ผู้โจมตีสร้างไว้ ต้องตรวจและนำช่องทางคงอยู่ที่ยืนยันแล้วออก พร้อมพิจารณาความน่าเชื่อถือของเครื่องก่อนนำกลับให้บริการ

ด้านข้อมูลเมล การสืบสวนพบการรวบรวมข้อมูลสำรองกล่องจดหมาย สร้างแฟ้มเก็บข้อมูล และพยายามส่งออกผ่านเครื่องมือถ่ายโอนข้อมูล แต่หลักฐานที่เผยแพร่สำหรับกรณีนั้นยังไม่ยืนยันว่าการส่งออกเสร็จสมบูรณ์ การประเมินผลกระทบจึงควรแยกการเข้าถึงข้อมูล การสร้างแฟ้ม การเริ่มส่ง และการส่งสำเร็จตามบันทึกที่มีจริง สำหรับเครื่องที่บันทึกช่วงก่อนแพตช์สูญหาย ขอบเขตการบุกรุกอาจยังสรุปไม่ได้แม้จะไม่พบการแจ้งเตือนใหม่หลังอัปเดต