สรุปสั้น

Roundcube ปล่อยเวอร์ชัน 1.6.18 และ 1.7.3 ออกมาเพื่ออุดช่องโหว่ความปลอดภัยรวม 11 รายการที่กระทบแพลตฟอร์มเว็บเมลของตัวเอง โดยชุดอัปเดตนี้แก้ทั้งช่องโหว่รันโค้ดจากระยะไกล การบายพาสการปลอมคำขอฝั่งเซิร์ฟเวอร์หรือ SSRF ช่องโหว่ประเภทการ inject คำสั่ง และปัญหา stored cross-site scripting ผู้ดูแลระบบที่ใช้ Roundcube สาย 1.6.x หรือ 1.7.x ควรอัปเดตโดยเร็วที่สุด

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

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

รายละเอียดข่าว

เว็บไซต์ Cyber Security News รายงานเมื่อวันที่ 17 สิงหาคม 2569 ว่า Roundcube ได้ปล่อยเวอร์ชัน 1.6.18 และ 1.7.3 เพื่อแก้ไขช่องโหว่ความปลอดภัย 11 รายการ โดยเวอร์ชันที่ได้รับผลกระทบคือสาย 1.6.x ที่เก่ากว่า 1.6.18 และสาย 1.7.x ที่เก่ากว่า 1.7.3 ผู้ดูแลระบบจึงต้องเลือกอัปเดตให้ตรงกับสายที่ตัวเองใช้อยู่

นอกจากช่องโหว่รันโค้ดจากระยะไกลในปลั๊กอิน markasjunk แล้ว ชุดอัปเดตนี้ยังแก้การบายพาสตัวกรอง SSRF ในตรรกะตรวจสอบ URL ภายในของ Roundcube ด้วย โดย SSRF คือกรณีที่ผู้โจมตีสามารถบังคับให้แอปพลิเคชันส่งคำขอไปยังตำแหน่งที่ผู้โจมตีเลือกได้ รวมถึงบริการภายในที่ไม่ได้เปิดสู่สาธารณะ การบายพาสรายการหนึ่งอาศัยช่วงที่อยู่ภายในแบบพิเศษ ได้แก่ 100.64.0.0/10 และ fe80::/10 ส่วนอีกรายการใช้ชื่อโฮสต์ที่ประดิษฐ์ขึ้นบนบริการ nip.io และ sslip.io ซึ่งหลบการตรวจของฟังก์ชัน is_local_url() ได้ โดยนาย Dmytro Ivanenko และนาย Milan Hoppe เป็นผู้รายงานปัญหาเหล่านี้

การแก้ไขอื่น ๆ ในสองเวอร์ชันนี้ประกอบด้วยช่องโหว่การ inject ตัวกรอง LDAP การ inject สคริปต์ Sieve ตามอำเภอใจ การ inject คำสั่ง IMAP ช่องโหว่ stored XSS ในการทำงาน “Add to address book” และการบายพาสการทำความสะอาด HTML และ CSS นอกจากนี้ Roundcube ยังแก้ปัญหาในไดรเวอร์รหัสผ่านที่อาจทำให้โทเคนยืนยันตัวตนรั่วไปยังโฮสต์ที่ผู้ใช้ควบคุมได้ นักวิจัยที่ได้รับเครดิตในชุดการค้นพบที่กว้างขึ้นนี้ ได้แก่ นาย Zach Hanley จากบริษัท Horizon3.ai, นาย Paulos Yibelo จาก pwn.ai รวมถึงผู้ใช้ชื่อ vectrain และ meifukun

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

รายละเอียดช่องโหว่

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

สำหรับช่องโหว่ SSRF สิ่งที่น่าสนใจคือวิธีการบายพาสทั้งสองแบบ แบบแรกอาศัยช่วงที่อยู่ที่ตัวกรองมักลืมครอบคลุม คือ 100.64.0.0/10 ซึ่งเป็นช่วงที่สงวนไว้สำหรับ carrier-grade NAT และ fe80::/10 ซึ่งเป็นช่วง link-local ของ IPv6 แบบที่สองใช้บริการอย่าง nip.io และ sslip.io ที่แปลงชื่อโฮสต์ให้เป็นที่อยู่ไอพีตามรูปแบบของชื่อ ทำให้ชื่อโฮสต์ที่ดูเหมือนโดเมนภายนอกกลับชี้กลับมายังที่อยู่ภายใน และเล็ดลอดการตรวจของ is_local_url() ไปได้

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

ช่องโหว่ที่เหลือแม้จะไม่ใช่การรันโค้ดโดยตรง แต่ก็ครอบคลุมเส้นทางโจมตีที่หลากหลาย ทั้งการ inject ตัวกรอง LDAP ที่อาจเปลี่ยนผลการค้นหาไดเรกทอรี การ inject สคริปต์ Sieve ที่เปลี่ยนพฤติกรรมการกรองอีเมลของเหยื่อ การ inject คำสั่ง IMAP ที่แทรกแซงการสื่อสารกับเซิร์ฟเวอร์อีเมล และ stored XSS ในฟังก์ชันเพิ่มรายชื่อลงสมุดที่อยู่ ซึ่งเป็นจุดที่ผู้ใช้กดโดยไม่คิดมาก ส่วนการบายพาสการทำความสะอาด HTML และ CSS ก็เป็นเส้นทางเดียวกับที่งานวิจัยเรื่อง CSS ในอีเมลเคยชี้ให้เห็นมาก่อน

ผลกระทบ

ผู้ที่รับความเสี่ยงตรงที่สุดคือองค์กรที่โฮสต์ Roundcube ด้วยตัวเองและเปิดให้เข้าถึงจากอินเทอร์เน็ต ซึ่งเป็นรูปแบบการติดตั้งที่พบมากในผู้ให้บริการโฮสติง สถาบันการศึกษา และองค์กรที่ต้องการควบคุมระบบอีเมลเอง เมื่อเซิร์ฟเวอร์เว็บเมลถูกยึด ผู้โจมตีไม่ได้แค่อ่านอีเมล แต่ได้เข้าถึงจุดที่เชื่อมกับ IMAP, LDAP และเครื่องมือจัดการสแปมพร้อมกันในที่เดียว

สำหรับปลั๊กอิน markasjunk ประเด็นที่ควรนำไปคิดต่อคือมันไม่ใช่ส่วนที่ทุกองค์กรจำเป็นต้องใช้ องค์กรจำนวนไม่น้อยเปิดปลั๊กอินไว้ตามค่าที่ติดตั้งมาโดยไม่เคยใช้งานจริง ซึ่งหมายความว่ากำลังแบกความเสี่ยงของโค้ดที่ไม่ได้ให้ประโยชน์กับตัวเองเลย

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

ข้อจำกัดของข้อมูลที่ต้องระบุคือรายงานต้นทางไม่ได้ระบุหมายเลข CVE ของช่องโหว่แต่ละรายการ ไม่ได้ให้คะแนน CVSS และไม่ได้ระบุว่าช่องโหว่รันโค้ดจากระยะไกลต้องอาศัยการยืนยันตัวตนก่อนหรือไม่ ซึ่งเป็นรายละเอียดที่มีผลต่อการจัดลำดับความเร่งด่วนอย่างมาก ผู้ดูแลระบบจึงควรอ่านคำแนะนำอย่างเป็นทางการของ Roundcube ประกอบก่อนตัดสินใจว่าจะอัปเดตแบบเร่งด่วนนอกรอบหรือไม่

คำแนะนำ

  • อัปเกรดเป็น Roundcube 1.6.18 หรือ 1.7.3 ตามสายเวอร์ชันที่ใช้อยู่ และตรวจสอบว่าอินสแตนซ์ทั้งหมดในองค์กรได้รับการอัปเดตครบ ไม่ใช่เฉพาะเครื่องหลัก
  • ตรวจสอบว่าปลั๊กอิน markasjunk จำเป็นต่อการใช้งานจริงหรือไม่ ถ้าไม่ได้ใช้ให้ปิดทิ้ง เพราะเป็นจุดที่ช่องโหว่ร้ายแรงที่สุดของชุดนี้อยู่
  • จำกัดการเชื่อมต่อขาออกจากเครื่องที่รัน Roundcube และตัดการเข้าถึงบริการภายในที่อ่อนไหวออกไป เพื่อลดผลกระทบของช่องโหว่ SSRF ที่อาจถูกค้นพบเพิ่มในอนาคต
  • บล็อกการเข้าถึงจุดปลายทางเมทาดาทาของคลาวด์จากเครื่องเว็บเมลโดยเฉพาะ หากรันบนผู้ให้บริการคลาวด์ เพราะเป็นเป้าหมายมาตรฐานของการโจมตี SSRF
  • ทบทวนรายการปลั๊กอินทั้งหมดที่เปิดใช้งานอยู่ และปิดตัวที่ไม่ได้ใช้ เพื่อลดพื้นที่โจมตีของระบบเว็บเมลโดยรวม
  • ตรวจล็อกของเซิร์ฟเวอร์เว็บเมลย้อนหลังหาคำขอที่ผิดปกติไปยังที่อยู่ภายใน ชื่อโฮสต์ที่ลงท้ายด้วย nip.io หรือ sslip.io และการเรียกใช้ปลั๊กอิน markasjunk ที่มาจากบัญชีหรือช่วงเวลาที่ไม่สมเหตุสมผล
  • แยกเซิร์ฟเวอร์เว็บเมลออกจากเครือข่ายที่มีระบบสำคัญ และใช้หลักการให้สิทธิ์เท่าที่จำเป็นกับบัญชีที่มันใช้เชื่อมต่อ IMAP และ LDAP

แหล่งอ้างอิง