Help desk เป็นหนึ่งในกล่องจดหมายที่ได้รับความไว้วางใจมากที่สุดที่องค์กรใช้งาน ลูกค้าคัดลอกรายละเอียดบัญชี บันทึกข้อผิดพลาด ชื่อ และบางครั้งก็เป็นเอกสาร โดยเชื่อว่าข้อมูลนั้นปลอดภัยอยู่หลังแพลตฟอร์ม ห่วงโซ่ remote code execution ผ่าน zero-day ของ Zammad ที่มีรายงานว่า ถูกใช้โจมตีสถาบัน Dutch Institute for Vulnerability Disclosure (DIVD) เป็นเครื่องเตือนใจว่าความไว้วางใจนี้ขึ้นอยู่กับซอฟต์แวร์ที่เก็บตั๋วทั้งหมด
ตามรายงาน ช่องโหว่ zero-day สองรายการของ Zammad ทำให้เกิดการ hijacking session, การรันคำสั่งจากระยะไกล และการเข้าถึงระดับ root ที่อาจเกิดขึ้นบนเซิร์ฟเวอร์ที่ใช้งานอยู่ Zammad เป็นแพลตฟอร์ม ticketing และ help desk แบบโอเพนซอร์ส รายละเอียดในบทความต้นทางมีจำกัด ดังนั้นโพสต์นี้จึงยึดตามสิ่งที่ได้รับการรายงานและหลีกเลี่ยงการคาดเดารายละเอียดทางเทคนิค
ห่วงโซ่ zero-day ของ Zammad ทำงานอย่างไร
เนื้อหาหลักเป็นเรื่องเกี่ยวกับการเชื่อมโยงช่องโหว่ ไม่จำเป็นที่ช่องโหว่ใดช่องโหว่หนึ่งจะต้องร้ายแรงด้วยตัวมันเองเพื่อให้การรวมกันนั้นเป็นเรื่องร้ายแรง จากรายงาน จุดอ่อนแรกอนุญาตให้ผู้โจมตี hijack session ซึ่งหมายถึงการเข้าควบคุมการเข้าถึงของผู้ใช้ที่ผ่านการยืนยันตัวตนแล้วโดยไม่ต้องรู้รหัสผ่าน จุดที่สองอนุญาตให้รันคำสั่งจากระยะไกล ทำให้ผู้โจมตีรันคำสั่งบนเซิร์ฟเวอร์ที่โฮสต์ Zammad จากจุดนั้น การเข้าถึงระดับ root ถูกอธิบายว่าเป็นผลลัพธ์ที่เป็นไปได้ ซึ่งหมายความว่าผู้โจมตีอาจได้ควบคุมเครื่องทั้งหมด
รูปแบบนี้พบได้ทั่วไปในการบุกรุกที่ร้ายแรง: ช่องโหว่หนึ่งสร้างจุดยึดเหนี่ยว อีกช่องหนึ่งเปลี่ยนจุดยึดนั้นให้กลายเป็นการควบคุม และยังอธิบายว่าทำไมนักป้องกันจึงถูกกระตุ้นให้ให้ความสำคัญกับปัญหาที่มีความรุนแรงระดับปานกลางอย่างจริงจัง เนื่องจากมันสามารถกลายเป็นจุดเชื่อมแรกในห่วงโซ่ได้
สำหรับเรื่องราวการโจมตีแบบเต็ม รวมถึงการบุกรุก DIVD เกิดขึ้นได้อย่างไร โปรดดูการรายงานก่อนหน้าของเรา: AI Agent Chains Two Zammad Zero-Days to Breach DIVD และ DIVD: AI Agent Exploits Two Zammad Zero-Days in Breach
สิ่งที่ help desk ที่ถูกบุกรุกเปิดเผย
เซิร์ฟเวอร์ help desk เก็บข้อมูลมากกว่าที่ผู้คนมักตระหนัก ขึ้นอยู่กับว่าองค์กรใช้งานอย่างไร อินสแตนซ์ที่ถูกบุกรุกอาจเปิดเผย:
- ตั๋วสนับสนุนและประวัติการสนทนาทั้งหมดที่แนบมาด้วย
- ชื่อลูกค้า ที่อยู่อีเมล และรายละเอียดการติดต่ออื่นๆ
- ไฟล์แนบเช่นภาพหน้าจอ บันทึก หรือเอกสารที่ลูกค้าอัปโหลด
- บันทึกภายในที่พนักงานเขียนเกี่ยวกับลูกค้าหรือเหตุการณ์
- ข้อมูลรับรอง API tokens หรือการตั้งค่าการเชื่อมต่อที่เก็บอยู่บนเซิร์ฟเวอร์
การเข้าถึงระดับ root ยิ่งเพิ่มความเสี่ยง ผู้โจมตีที่ควบคุมโฮสต์ไม่ได้จำกัดอยู่แค่ข้อมูลของแอปพลิเคชัน พวกเขาอาจเข้าถึงบริการอื่นบนเครื่องเดียวกัน อ่านไฟล์การกำหนดค่า และใช้เซิร์ฟเวอร์เป็นบันไดไปยังส่วนอื่นในเครือข่าย นั่นคือเหตุผลที่การบุกรุก help desk สามารถกลายเป็นเหตุการณ์ที่กว้างขึ้นแทนที่จะถูกจำกัดวง
กรณี DIVD ก็ notable เช่นกันเพราะ DIVD เองเป็นองค์กรความปลอดภัยที่ช่วยให้ช่องโหว่ได้รับการรายงานและแก้ไข หากกลุ่มที่มุ่งเน้นงานนี้สามารถได้รับผลกระทบได้ องค์กรใดก็ตามที่ใช้งานเครื่องมือ self-hosted ควรสันนิษฐานว่าตนเป็นเป้าหมายที่เป็นไปได้ บทความของเราเกี่ยวกับ ห่วงโซ่ zero-day ของ Zammad ที่เปิดทางให้การบุกรุกที่ขับเคลื่อนด้วย AI ครอบคลุมบริบทนั้น
สิ่งที่ผู้ดูแล Zammad ควรทำตอนนี้
หากคุณใช้งาน Zammad ให้ถือว่านี่เป็นการทบทวนที่มีลำดับความสำคัญสูง而不是งานroutine
- ตรวจสอบการแก้ไขอย่างเป็นทางการ ติดตาม security advisories ของโปรเจกต์ Zammad และใช้แพตช์หรืออัปเดตทันทีที่มี อย่าพึ่งพาสรุปจากบุคคลที่สามสำหรับรายละเอียดเวอร์ชัน
- จำกัดการเปิดเผย หากอินสแตนซ์ของคุณไม่จำเป็นต้องเข้าถึงได้จากอินเทอร์เน็ตสาธารณะ ให้จำกัดการเข้าถึงด้วย VPN, IP allowlist หรือกฎ reverse proxy จนกว่าคุณจะแพตช์
- ยกเลิก session เนื่องจากการ hijacking session เป็นส่วนหนึ่งของห่วงโซ่ที่มีรายงาน ควรพิจารณาบังคับออกจากระบบและหมุน session secrets หลังอัปเดต
- หมุนข้อมูลรับรอง เปลี่ยนรหัสผ่านผู้ดูแล API tokens และ secrets ใดๆ ที่เก็บอยู่บนเซิร์ฟเวอร์ โดยเฉพาะหากคุณสงสัยว่าถูกบุกรุก
- ตรวจสอบบันทึก มองหาการเข้าสู่ระบบของผู้ดูแลที่ผิดปกติ คำสั่งที่ไม่คาดคิด บัญชีใหม่ หรือการเชื่อมต่อขาออกที่แปลก
- รันด้วยสิทธิ์น้อยที่สุด ตรวจสอบให้แน่ใจว่าแอปพลิเคชันไม่ได้รันด้วยสิทธิ์ระบบมากกว่าที่จำเป็น และเก็บสำรองข้อมูลไว้ห่างจากเซิร์ฟเวอร์
สิ่งที่ลูกค้าสามารถทำได้เพื่อจำกัดการเปิดเผย
สิ่งนี้หมายความว่าอย่างไรสำหรับคุณ
คนส่วนใหญ่ไม่สามารถแพตช์ซอฟต์แวร์ help desk ที่องค์กรใช้งานได้ แต่คุณสามารถลดสิ่งที่เสี่ยงหากถูกบุกรุก
- แชร์น้อยลงในตั๋ว หลีกเลี่ยงการส่งรหัสผ่าน หมายเลข ID เต็ม รายละเอียดการชำระเงิน หรือเอกสารอ่อนไหวผ่านตั๋วสนับสนุน หากคำขอจำเป็นต้องใช้จริงๆ ให้ถามว่ามีช่องทางที่ปลอดภัยกว่าหรือไม่
- ปิดข้อมูลก่อนแนบ เบลอหรือลบรายละเอียดส่วนบุคคลออกจากภาพหน้าจอและบันทึก
- ใช้รหัสผ่านที่ไม่ซ้ำ หากแพลตฟอร์มสนับสนุนเคยเก็บข้อมูลรับรองที่คุณส่งไป รหัสผ่านที่ไม่ซ้ำจะจำกัดความเสียหาย
- จับตาดูประกาศการบุกรุก อ่านอีเมลจากบริการที่คุณใช้เกี่ยวกับเหตุการณ์ความปลอดภัย และระวังข้อความติดตามที่ขอให้คุณคลิกลิงก์หรือยืนยันรายละเอียด
- คาดว่าจะมีฟิชชิง รายละเอียดการติดต่อและบริบทของตั๋วสามารถทำให้ข้อความหลอกลวงดูน่าเชื่อถือ ตรวจสอบผ่านเว็บไซต์ทางการขององค์กร
สรุป
ห่วงโซ่ remote code execution ผ่าน zero-day ของ Zammad ที่มีรายงานแสดงให้เห็นว่าแพลตฟอร์ม help desk เดียวสามารถกลายเป็นประตูสู่ข้อมูลลูกค้าและการควบคุมเซิร์ฟเวอร์ได้อย่างไร ผู้ดูแลควรแพตช์ จำกัดการเข้าถึง และหมุน secrets ส่วนคนอื่นๆ สามารถส่งข้อมูลที่ละเอียดอ่อนน้อยลงผ่านตั๋วและเฝ้าระวังประกาศการบุกรุก สำหรับเรื่องราวที่สมบูรณ์ของการโจมตี DIVD ที่เกิดขึ้น โปรดอ่านการรายงานที่มีอยู่ของเราที่ลิงก์ไว้ด้านบน
