รายละเอียดเบื้องต้นของสาเหตุการขัดข้องของ CSAgent.sys ของ CrowdStrike

 (twitter.com/patrickwardle)
1 คะแนน โดย GN⁺ 2024-07-22 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-07-22
ความเห็นจาก Hacker News

  • ความเห็นแรก

    • ปัญหา BSOD เกิดจากการผสมกันของข้อมูลไบนารีที่ไม่ถูกต้องกับตัวแยกวิเคราะห์ที่เขียนผิดพลาด
    • จากประสบการณ์ตลอด 10 ปีที่ผ่านมา ปัญหา CVE, การแครช, บั๊ก และความล่าช้าส่วนใหญ่มักเกิดขึ้นในกระบวนการ deserialize ข้อมูลไบนารีให้เป็นโครงสร้างข้อมูลที่เครื่องอ่านได้
    • สิ่งนี้พบได้ในหลายด้าน เช่น อัลกอริทึมการบีบอัด, ตัวอ่านเค้าโครงฟอนต์, ตัวแยกวิเคราะห์ภาพ/วิดีโอ/เสียง, ตัวแยกวิเคราะห์ข้อมูลวิดีโอเกม, ตัวแยกวิเคราะห์ XML/HTML และตัวแยกวิเคราะห์ใบรับรอง/ลายเซ็น/กุญแจของ OpenSSL เป็นต้น
    • ตัวแยกวิเคราะห์คอนเทนต์ของโปรแกรม EDR ของ CrowdStrike ก็ไม่ได้เป็นข้อยกเว้น

  • ความเห็นที่สอง

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

  • ความเห็นที่สาม

    • Microsoft มีส่วนรับผิดชอบต่อเหตุระบบล่มของ CrowdStrike
    • Microsoft ครองสถานะกึ่งผูกขาดโดยพฤตินัยในพื้นที่การประมวลผลเวิร์กสเตชัน และมีหน้าที่ต้องรับประกันความปลอดภัย/ความเชื่อถือได้/ฟังก์ชันการทำงานของผลิตภัณฑ์
    • เนื่องจากไม่มีการแข่งขัน นวัตกรรมของ Windows จึงล่าช้า
    • ตัวอย่างเช่น CrowdStrike ทำงานใน user space บน MacOS และ Linux แต่ไม่ได้เป็นเช่นนั้นบน Windows
    • จำเป็นต้องมีนวัตกรรมด้าน application sandboxing
    • Microsoft กุมกุญแจของโครงสร้างพื้นฐานการประมวลผลของโลกไว้ แต่แทบไม่ได้รับการกำกับดูแล
    • แม้สัดส่วนรายได้จาก Windows จะลดลง แต่เนื่องจากเป็นผลิตภัณฑ์ที่ใช้ขับเคลื่อนโครงสร้างพื้นฐานสำคัญ จึงต้องมีความรับผิดชอบมากกว่านี้
    • รัฐบาลควรส่งเสริมการแข่งขันในตลาด desktop workspace หรือกำกับดูแลผลิตภัณฑ์ Windows ของ Microsoft

  • ความเห็นที่สี่

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

  • ความเห็นที่ห้า

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

  • ความเห็นที่หก

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

  • ความเห็นที่เจ็ด

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

  • ความเห็นที่แปด

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