สถาบันเปิดเผยช่องโหว่แห่งเนเธอร์แลนด์ (DIVD) กล่าวว่าการละเมิดเครือข่ายของตนเองนั้นเกิดขึ้นได้เพราะผู้โจมตีใช้ประโยชน์จากห่วงโซ่ของช่องโหว่ zero-day สองรายการใน Zammad ระบบ ticketing โอเพนซอร์ส การละเมิด DIVD จาก zero-day ของ Zammad นี้เป็นเครื่องเตือนใจที่ชัดเจนว่าแม้แต่องค์กรที่มีหน้าที่ค้นหาและรายงานข้อบกพร่องด้านความปลอดภัยก็ยังอาจตกเป็นเหยื่อของข้อบกพร่องที่ยังไม่มีใครรู้ได้

รายงานที่มีอยู่ในขณะนี้ยังมีจำกัด ดังนั้นบทความนี้จะยึดตามสิ่งที่ได้รับการระบุไว้และอธิบายว่าทำไมเรื่องนี้จึงสำคัญ

ห่วงโซ่ zero-day ของ Zammad เจาะเครือข่าย DIVD ได้อย่างไร

ตามที่ DIVD ระบุ การบุกรุกเครือข่ายของตนเกิดขึ้นได้จากการเชื่อมโยงช่องโหว่ zero-day สองรายการที่แยกจากกันใน Zammad zero-day คือข้อบกพร่องที่ผู้จำหน่ายไม่รู้จัก หรือไม่มีแพตช์ให้ใช้ในขณะที่มีการโจมตี ซึ่งทำให้ฝ่ายป้องกันไม่มีวิธีแก้ไขที่พร้อมใช้

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

Zammad เป็นแพลตฟอร์ม help desk และ ticketing โอเพนซอร์ส ที่องค์กรต่างๆ มักติดตั้งเองเพื่อจัดการคำขอสนับสนุน สรุปจากแหล่งข่าวไม่ได้ให้รายละเอียดลักษณะทางเทคนิคของช่องโหว่ทั้งสอง และเราไม่จะคาดเดาเกี่ยวกับมัน ผู้อ่านควรจับตาดูคำแนะนำและแพตช์อย่างเป็นทางการจากโครงการ Zammad และจาก DIVD

การโจมตีที่ขับเคลื่อนด้วย AI เปลี่ยนอะไรสำหรับฝ่ายป้องกัน

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

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

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

ไม่มีสิ่งใดในนี้ที่เป็นเหตุให้ตื่นตระหนก มันเป็นเหตุให้มองการจัดการความเสี่ยงจากการเปิดเผยเป็นกระบวนการต่อเนื่อง มากกว่าการตรวจสอบเป็นครั้งคราว

ทำไมระบบ ticketing จึงเก็บข้อมูลอ่อนไหวมากกว่าที่คุณคิด

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

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

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

สิ่งนี้หมายความว่าอย่างไรสำหรับคุณ

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

หากคุณใช้ Zammad หรือเครื่องมือ ticketing ที่ติดตั้งเองคล้ายกัน นี่เป็นจังหวะดีที่จะตรวจสอบความเสี่ยงของคุณ สำหรับคนอื่นๆ บทเรียนอยู่ที่นิสัย รายละเอียดที่คุณมอบให้ฝ่ายสนับสนุนอาจอยู่ในระบบที่คุณไม่รู้อะไรเลย ซึ่งดำเนินการโดยผู้จำหน่ายที่คุณไม่ได้เลือก

สิ่งที่องค์กรและผู้ใช้ควรตรวจสอบตอนนี้

สำหรับองค์กรที่ใช้ Zammad:

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

สำหรับบุคคลทั่วไป:

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

บทสรุป

การละเมิด DIVD จาก zero-day ของ Zammad แสดงให้เห็นว่าแพลตฟอร์มสนับสนุนและ ticketing สมควรได้รับการตรวจสอบอย่างละเอียดเช่นเดียวกับระบบวิกฤตอื่นๆ แพตช์อย่างรวดเร็ว จำกัดการเปิดเผย และล้างข้อมูลที่คุณไม่ต้องการแล้ว ในฐานะผู้อ่าน ใช้เวลาสักครู่เพื่อทบทวนว่าข้อมูลส่วนบุคคลใดที่คุณได้แบ่งปันกับฝ่ายสนับสนุนและผู้จำหน่าย และพิจารณาว่าการละเมิดที่หนึ่งในนั้นอาจส่งผลต่อคุณอย่างไร สำหรับตัวอย่างเทียบเคียงของระบบบริการลูกค้าที่กลายเป็นจุดอ่อน อ่านบทความของเราเกี่ยวกับการละเมิดผ่านผู้จำหน่ายบุคคลที่สามของ Adidas