สรุปสั้น

Roundcube ปล่อยเวอร์ชัน 1.6.18 และ 1.7.3 ออกมาเพื่ออุดช่องโหว่ความปลอดภัยรวม 11 รายการที่กระทบแพลตฟอร์มเว็บเมลของตัวเอง โดยชุดอัปเดตนี้แก้ทั้งช่องโหว่รันโค้ดจากระยะไกล การบายพาสการปลอมคำขอฝั่งเซิร์ฟเวอร์หรือ SSRF ช่องโหว่ประเภทการฉีดคำสั่ง และปัญหา 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 เป็นผู้รายงานปัญหาเหล่านี้

การแก้ไขอื่น ๆ ในสองเวอร์ชันนี้ประกอบด้วยช่องโหว่การฉีดตัวกรอง LDAP การฉีดสคริปต์ Sieve ตามอำเภอใจ การฉีดคำสั่ง 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 เพื่อร้องขอหน้าเว็บสำหรับผู้ดูแลระบบภายใน จุดปลายทางเมทาดาทาของคลาวด์ หรือบริการที่ทำงานอยู่บนอินเทอร์เฟซเครือข่ายส่วนตัวเท่านั้น ผลกระทบจึงขึ้นอยู่กับการออกแบบเครือข่ายและการควบคุมการเชื่อมต่อขาออกเป็นหลัก โดยเซิร์ฟเวอร์เว็บเมลที่เชื่อมต่อไปยังระบบภายในได้กว้างจะเผชิญความเสี่ยงมากกว่า

ช่องโหว่ที่เหลือแม้จะไม่ใช่การรันโค้ดโดยตรง แต่ก็ครอบคลุมเส้นทางโจมตีที่หลากหลาย ทั้งการฉีดตัวกรอง LDAP ที่อาจเปลี่ยนผลการค้นหาไดเรกทอรี การฉีดสคริปต์ Sieve ที่เปลี่ยนพฤติกรรมการกรองอีเมลของเหยื่อ การฉีดคำสั่ง 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

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