รายละเอียดเบื้องต้นของสาเหตุการชนของ CrowdStrike CSAgent.sys
(twitter.com/patrickwardle)- การชนของ Windows ทั่วโลกถูกวิเคราะห์เบื้องต้นว่าเกิดจากเส้นทางการทำงานที่ CrowdStrike CSAgent.sys อ้างอิงแอดเดรสหน่วยความจำผิดพลาด
- คำสั่งที่มีปัญหาคือ
mov r9d, [r8]และในR8มี แอดเดรสที่ไม่ได้ถูกแมป ซึ่งดึงออกมาจากอาร์เรย์ของพอยน์เตอร์ด้วยอินเด็กซ์ - ไฟล์
C-00000291-...xxx.sysดูเหมือนไม่ใช่ไดรเวอร์เคอร์เนล แต่เป็นข้อมูลที่ถูกทำให้สับสนซึ่ง CSAgent.sys อ่าน โดย CrowdStrike ยืนยันว่าเป็นไฟล์คอนฟิก Channel Files - CrowdStrike ระบุว่า
C-00000291-ก่อให้เกิด ข้อผิดพลาดทางลอจิก จนนำไปสู่การชนของ OS และปฏิเสธข้อสันนิษฐานที่ว่า null byte ภายใน Channel File เป็นสาเหตุ - การปล่อยครั้งนี้ถูกจัดการเป็น content update ไม่ใช่การอัปเดตเวอร์ชัน จึงมีบางกรณีที่ข้ามการควบคุม staging ของไคลเอนต์บางราย และ crash report กลายเป็นเบาะแสสำคัญในการวิเคราะห์สาเหตุ
เส้นทางการชนของ CSAgent.sys
- การวิเคราะห์เบื้องต้นเป็นการวิเคราะห์แบบสถิตโดย reverse engineering CSAgent.sys ของ CrowdStrike และอ้างอิง crash dump เพียงไฟล์เดียว
- ขณะนั้นมีการแชร์ข้อมูลและขอให้ตรวจสอบเพิ่มเติมโดยไม่มีระบบ Windows หรือ VM
- วิเคราะห์ CSAgent.sys จากไฟล์ที่ถูกอัปโหลดบน VirusTotal: ตัวอย่าง VirusTotal
- จุดที่ชนคือคำสั่ง
mov r9d, [r8]R8เป็นแอดเดรสที่ไม่ได้ถูกแมป- ค่านี้เป็นแอดเดรสที่ดึงจากอาร์เรย์ของพอยน์เตอร์ใน
RAXด้วยอินเด็กซ์RDX(0x14 * 0x8)
- ไฟล์
.sysอื่น ๆ เช่นC-00000291-...32.sysดูเหมือนไม่ใช่ไดรเวอร์จริง แต่เป็น ข้อมูลที่ถูกทำให้สับสน- มีร่องรอยว่า CSAgent.sys อ้างอิงหรืออ่านไฟล์เหล่านี้
- เนื่องจากเมื่อลบไฟล์แล้วอาการชนหายไป จึงมีการตั้งข้อสังเกตว่าเนื้อหาของไฟล์อาจส่งผลต่อการชนของ CSAgent.sys
- มีการเสริมว่าหากดีบักจะตรวจยืนยันได้ง่ายขึ้น
- ไฟล์
.zipที่แชร์มี CSAgent.sys หลายเวอร์ชัน, IDB และไฟล์C-....sysหลายไฟล์- มีคำอธิบายว่าไฟล์ล่าสุดไฟล์หนึ่งดูเหมือนจะมี “fix” อยู่
- ลิงก์ที่แชร์: Google Drive zip
Channel Files และข้อมูลยืนยันจาก CrowdStrike
- Kevin Beaumont เขียนว่าไฟล์
.sysที่ก่อปัญหาเป็น channel update files และรูปแบบที่ผิดพลาดทำให้ไดรเวอร์ CS ชั้นบนชน- ลิงก์: โพสต์ของ Kevin Beaumont
- คำอธิบายทางเทคนิคของ CrowdStrike ยืนยันไปในทิศทางเดียวกับการวิเคราะห์เบื้องต้น
- ไฟล์
C-...sysไม่ใช่ไดรเวอร์เคอร์เนล แต่เป็นไฟล์คอนฟิกที่เรียกว่า Channel Files C-00000291-กระตุ้นข้อผิดพลาดทางลอจิก และส่งผลให้ OS ชนผ่าน CSAgent.sys- ลิงก์: คำอธิบายทางเทคนิคของ CrowdStrike
- ไฟล์
- บางฝ่ายสันนิษฐานว่า Channel File ว่าง
0x0เป็นสาเหตุ แต่ CrowdStrike ปฏิเสธว่าปัญหาไม่ได้เกี่ยวข้องกับ null byte ภายใน Channel File- Malware Utkonos ชี้ถึงการตรวจสอบว่าไฟล์ควรเริ่มด้วย
0xaaaaaaaa: โพสต์ที่เกี่ยวข้อง
- Malware Utkonos ชี้ถึงการตรวจสอบว่าไฟล์ควรเริ่มด้วย
- มีการยืนยันว่า channel update ถูกแจกจ่ายโดยข้าม การควบคุม staging ของไคลเอนต์บางราย
- ผู้ดูแล IT บางรายยืนยันว่าแม้ตั้งค่าในนโยบาย CrowdStrike ให้เพิกเฉยต่อเวอร์ชันล่าสุด แต่การอัปเดตครั้งนี้ถูกข้ามได้ เพราะเป็น content update ไม่ใช่การอัปเดตเวอร์ชัน
- โพสต์ที่เกี่ยวข้อง: เธรด ResetEra
- ในสิทธิบัตรของ CrowdStrike ก็ปรากฏคำว่า channel files หลายครั้ง
- มีการยกตัวอย่าง US11822515B2 และ US11645397B2
- คำค้นคือ
channel file assignee:(Crowdstrike, Inc.)
เบาะแสจาก crash report และ macOS System Extensions
- crash report เป็นเครื่องมือในการทำความเข้าใจการชนของ CrowdStrike และยังถูกใช้ในการเปิดเผย 0day อื่นบน macOS ด้วย
- ชื่อการบรรยายที่เกี่ยวข้องใน Black Hat คือ “The Hidden Treasure of Crash Reports?”
- ลิงก์: หน้าการบรรยาย Black Hat
- การที่ Apple เลิกใช้ kext ของ 3rd-party และย้ายไปใช้ System Extensions แบบ user-mode ถูกประเมินในเชิงบวก
- อย่างไรก็ตาม มีการระบุว่าระหว่างการเปลี่ยนผ่านนี้มีปัญหา kernel panic, การยกระดับสิทธิ์ และการ unload เครื่องมือความปลอดภัย
- โค้ดเคอร์เนลที่รองรับ System Extensions แบบ user-mode บน macOS มีบั๊กจำนวนมาก และเคยมีกรณีที่เครื่องมือความปลอดภัยซึ่งย้ายไปอยู่ user mode ทำให้เกิด kernel panic ใน kext หลักของ Apple เป็นวงกว้าง
- มีการกล่าวถึง CVE-2019-8805 ในฐานะปัญหาการยกระดับสิทธิ์ของเฟรมเวิร์กหลัก macOS System Extension
- การบรรยายที่เกี่ยวข้อง: Endpoint Security and Insecurity
- เนื่องจากข้อบกพร่องในการจัดการ System Extensions โค้ดที่ไม่มีสิทธิ์หรือมัลแวร์อาจทำให้เครื่องมือความปลอดภัยถูก unload ได้
- ยกตัวอย่างว่าสามารถปิด LuLu ซึ่งเป็นไฟร์วอลล์ที่ทำงานเป็น System Extension ที่เชื่อถือได้แม้บน macOS รุ่นล่าสุดได้
- บั๊กนี้ไม่ใช่ปัญหาที่เกิดกับ LuLu เพียงอย่างเดียว
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
ทันทีที่เห็นคำว่า “เป็นการอัปเดตคอนเทนต์ที่ทำให้เกิด BSOD และลบออกแล้วจะแก้ได้” ก็คิดเลยว่าน่าจะเดิมพัน £100 ได้ว่าเป็นการผสมกันระหว่าง ข้อมูลไบนารีที่เสียหาย กับพาร์เซอร์ที่เขียนมาไม่ดี
ผมทำงานคอมพิวติ้งค่อนข้างจริงจังมาราว 10 ปี และไม่ได้ทำไซเบอร์ซีเคียวริตี้เลย แต่ผมมองว่าแทบทุก CVE, แครช, บั๊ก, ประสิทธิภาพตก และความเจ็บปวด ล้วนมาจากกระบวนการ deserialize ข้อมูลไบนารีกลับเป็นโครงสร้างข้อมูลที่เครื่องอ่านได้
เพราะโปรแกรมเมอร์มนุษย์พลาดเคสขอบ และภาษาเชิงคำสั่งก็ปล่อยให้เป็นแบบนั้นได้ ซึ่งรวมไปถึงอัลกอริทึมคลายการบีบอัด, ตัวอ่านเส้นขอบฟอนต์, พาร์เซอร์รูปภาพ/วิดีโอ/เสียง, พาร์เซอร์ข้อมูลเกม, พาร์เซอร์ XML/HTML, พาร์เซอร์ใบรับรอง/ลายเซ็น/คีย์ของ OpenSSL ไปจนถึงพาร์เซอร์คอนเทนต์ของ CrowdStrike EDR ครั้งนี้ทั้งหมด
ถ้ารวมสมมติฐานที่สองด้วย ผมอาจลงเพิ่มอีก £50 ได้
ไฟล์ที่เสียหายอาจผ่านการทดสอบภายใน หรือไม่ก็ไม่มีการทดสอบภายใน และดูเหมือนการตั้งค่ารายบุคคลเกี่ยวกับเวลานำอัปเดตไปใช้ก็ถูกละเลยด้วย อีกทั้งยังปล่อยทั่วโลกพร้อมกันจนจำกัดความเสียหายไม่ได้ และยังไม่รู้ด้วยซ้ำว่าไฟล์เสียหายเกิดขึ้นตั้งแต่แรกได้อย่างไร
การ deserialize ข้อมูลที่ไม่น่าเชื่อถือ (CWE-502) อยู่อันดับ 15 ส่วนอันดับ 1 คือ การเขียนนอกขอบเขต (CWE-787) และอันดับ 4 คือ use-after-free (CWE-416) จุดอ่อนที่ติดรายการทุกครั้งตั้งแต่ปี 2019 ถูกรวบรวมไว้ที่ https://cwe.mitre.org/top25/archive/2023/2023_stubborn_weaknesses.html
อ้างอิงจากที่ทำงานด้านความปลอดภัยสารสนเทศมามากกว่า 30 ปี
ในทางกลับกัน ภาษาตระกูล Scheme แบบหนึ่งที่ผมใช้เมื่อ 20 ปีก่อนเป็นภาษาเชิงฟังก์ชัน แต่ไม่ได้ตรวจว่าครอบคลุมทุกกรณีหรือไม่ และ ghc ของ Haskell เมื่อหลายปีก่อนก็ไม่ได้เปิดการตรวจนั้นเป็นค่าเริ่มต้น ไม่รู้ว่าตอนนี้เปลี่ยนไปหรือยัง
ผู้ดูแล IT บางคนยืนยันว่าแม้ตั้งค่านโยบาย CS ให้ละเว้นเวอร์ชันล่าสุดแล้ว สิ่งนี้ก็ยังเล็ดลอดไปได้ เพราะมันไม่ใช่ “การอัปเดตเวอร์ชัน” แต่เป็น “การอัปเดตคอนเทนต์” ถ้าการอัปเดตคอนเทนต์สามารถทำให้ไคลเอนต์พังได้ ก็ไม่ควรข้ามการควบคุม staging หรือนโยบายได้
แยกจากประเด็นว่าเราจำเป็นต้องมีซอฟต์แวร์เฝ้าระวัง endpoint แบบรูตคิทอย่าง CS จริงหรือไม่ หากจะย้ายวงการนี้ไปสู่มาตรฐานที่มีจริยธรรมมากขึ้น ทางเลือกโอเพนซอร์ส อาจทรงพลังมาก
ถ้าเครื่องมือหลักเป็นโอเพนซอร์ส ก็จะโปร่งใสว่ามันทำอะไรอย่างแน่ชัด และสาธารณะสามารถตรวจสอบได้ว่าไม่มี backdoor หรือบั๊กร้ายแรง ขณะเดียวกัน รูปแบบที่ทีมความปลอดภัยจัดหา signature ของมัลแวร์ให้ก็ยังเป็นโมเดลธุรกิจได้
ในมุมผู้ใช้ ผมไม่อาจวางใจได้ว่ารูตคิทเฝ้าระวังแบบโอเพนซอร์สจะถูกทดสอบและพัฒนาดีกว่า หรือคำนึงถึงผลประโยชน์ของผม ปัญหาคือซอฟต์แวร์เฝ้าระวังทั้งหมวดนี้ต่างหาก มันไม่ควรมีอยู่ บริษัทที่ใช้ของแบบนี้ไม่เข้าใจความปลอดภัย ไม่เชื่อใจพนักงาน และไม่ใช่ที่ทำงานที่ดี
มันอยู่ในอุปกรณ์ไคลเอนต์ทุกเครื่องของ Google
เครื่องมือเหล่านี้ให้การป้องกันที่จำเป็นต่อภัยคุกคามซับซ้อน และจับได้จริง ถ้าการทดสอบมีเครื่อง Windows รวมอยู่ด้วย งานของผมจะง่ายขึ้น 90% เมื่อไม่มี EDR
มี EDR โอเพนซอร์สอย่าง OpenEDR เช่นกัน แต่มันเก่าและคุณภาพ telemetry แย่: https://github.com/ComodoSecurity/openedr การรวบรวมโค้ด proof-of-concept ต่าง ๆ บน GitHub มาทำเป็น EDR สำหรับใช้งานจริงนั้นไม่สมจริงและไม่ปลอดภัย
ตัวเซ็นเซอร์ EDR เองกลายเป็นเป้าหมายการโจมตี จากมุมผู้โจมตี โดยมาก EDR เป็นอุปสรรคเดียว ดังนั้นถ้าเปิดซอร์ส ความเสี่ยงที่การพัฒนาจะถูกถ่วงด้วยการส่งโค้ดอันตราย หรือถูกฝังช่องโหว่ก็จะสูงขึ้น การพัฒนาเซ็นเซอร์ความปลอดภัยเป็นสภาพแวดล้อมที่เป็นปฏิปักษ์อย่างมาก ซึ่งคุณไม่อาจมั่นใจได้ว่าอีกฝ่ายเป็นใคร
ในความเป็นจริงเกือบจะตรงกันข้าม มีกฎ heuristic สำหรับมัลแวร์แบบโอเพนซอร์สอยู่ เช่นกฎตรวจจับของ Elastic Security: https://github.com/elastic/detection-rules Elastic เองก็มี EDR ที่รวมเคอร์เนลไดรเวอร์ด้วย และจากประสบการณ์ถือว่าหลบเลี่ยงยากกว่า ถ้าทำ EDR บน Windows โดยไม่มีไดรเวอร์ งานผมจะง่ายขึ้น
เซ็นเซอร์ EDR ถูก “ตรวจสอบ” โดยนักวิจัยความปลอดภัยและผู้โจมตีอยู่แล้ว มีการทำ reverse engineering และ debugging อย่างต่อเนื่องเพื่อหาจุดอ่อน ถ้าพบปัญหาระดับที่ EDR รับ kernel-mode shellcode แล้วรันตรง ๆ แน่นอนว่าคงเปิดเผยต่อสาธารณะ
มันซับซ้อนกว่าโปรแกรมค้นหา hash ธรรมดามาก
ยากที่จะเข้าใจว่าทำไมการทดสอบการ deploy ถึงจับปัญหานี้ไม่ได้ อยากรู้ว่าความแตกต่างอะไรที่ทำให้เกิดปัญหาเฉพาะตอน deploy ออกไปสู่โลกภายนอกเท่านั้น
ไม่น่าเชื่อว่าจะไม่ได้ทดสอบก่อน deploy และองค์กรต่าง ๆ ก็ควรมี สภาพแวดล้อมทดสอบ ก่อน deploy คอมโพเนนต์ของ third-party เป็นเรื่องปกติที่ระหว่างพัฒนาจะติดตั้งแพ็กเกจแล้วล้มเหลวหรือก่อปัญหา แต่ไม่มีใครคิดว่าการเอาเข้า production โดยไม่ทดสอบเป็นเรื่องดี กรณีนี้ต่างออกไปอย่างไรยังไม่เข้าใจ
ใน pipeline 1 น่าจะมองการอัปเดตโค้ดซอฟต์แวร์เป็นการเปลี่ยนแปลงสำคัญ ผ่านสภาพแวดล้อมที่ไม่ใช่ production และการทดสอบแบบ canary ก่อน deploy “เวอร์ชัน” ใหม่ไปทั่วโลก
ใน pipeline 2 อาจปฏิบัติกับการอัปเดต content/channel ต่างออกไป เส้นทางนี้คงใช้ deploy แค่สิ่งอย่าง signature มัลแวร์ใหม่ ๆ ดังนั้นจึงน่าจะสันนิษฐานว่าไฟล์ใหม่เป็นไฟล์ข้อมูลรูปแบบมาตรฐาน ไม่ได้ถูก “รัน” แต่อ่านอย่างเดียว
pipeline นี้เองตอนแรกคงถูกทดสอบและตัดสินว่าทำงานได้เป็นที่น่าพอใจ แต่คงไม่มีขั้นตอนทดสอบเพื่อยืนยันความถูกต้องสมบูรณ์ของไฟล์ข้อมูลที่สร้างขึ้น หรือที่สำคัญกว่านั้นคือยืนยันว่าเมื่อ deploy ไปยังซอฟต์แวร์เวอร์ชันล่าสุดที่ใช้งานอยู่แล้วจะทำงานได้โดยไม่มีข้อผิดพลาด
ซอฟต์แวร์ agent ที่อ่านไฟล์ channel ทุกวันคงถูกทดสอบ “อย่างละเอียด” ใน pipeline 1 กับขนาดไฟล์ข้อมูลและเนื้อหาจำลองที่เป็นไปได้ทั้งหมด แม้โดยธรรมชาติแล้วไฟล์ข้อมูลที่ผิดรูปควรถูกปฏิเสธพร้อมข้อผิดพลาดก็ตาม
สถานการณ์ที่แน่ชัดในครั้งนี้อาจเป็นว่า pipeline ที่เสียในเส้นทางที่สองสร้างไฟล์ข้อมูลผิดรูปในลักษณะแปลก ๆ และกรณีเฉพาะนั้นไม่เคยถูกจินตนาการหรือทดสอบใน pipeline สำหรับพัฒนา·ทดสอบ·deploy เวอร์ชันซอฟต์แวร์
ถ้าเป็นอย่างนั้นจริง บทเรียนก็ชัดเจน ต่อให้เป็นการ deploy เฉพาะ “ข้อมูล” และ pipeline จะเป็นมาตรฐานและเสถียรแค่ไหน ก็ต้องทดสอบก่อน deploy ในวงกว้างอยู่ดี แม้จะเพิ่มต้นทุนและความล่าช้า แต่ก็ต้องยอมรับ คล้ายกับเหตุผลที่ผู้คนยอมจ่ายเงินให้ซอฟต์แวร์ “ความปลอดภัย” ตั้งแต่แรก
ลูกค้าองค์กรก็เช่นกัน ควรทดสอบสิ่งที่จะ deploy ใหม่ในพื้นที่ที่ไม่ใช่ production ของสภาพแวดล้อม IT หรือมี canary deployment ก่อนอนุญาตให้ไปยัง fleet production ทั้งหมด
ตอนที่บริษัทพยายามเข้าสู่ตลาด endpoint security และการตรวจจับความผิดปกติของเครือข่าย ลูกค้าที่เป็นไปได้หลายรายต้องการ SLA 4 ชั่วโมงสำหรับประเภทและระดับความรุนแรงของ CVE ที่หลากหลาย นั่นหมายถึงต้องมีวิศวกรความปลอดภัย on-call 24/7 และต้องสร้าง·deploy definition ภายในไม่ถึง 4 ชั่วโมง โดย 4 ชั่วโมงนั้นต้องหมายถึง deploy ได้ถึงเป้าหมาย 100%
การเขียนและ deploy definition คุณภาพสูงสำหรับ zero-day ภายใน 4 ชั่วโมงก็ยากแล้ว การให้ผ่าน pipeline ทดสอบยิ่งยากกว่า ยังไม่ต้องพูดถึงการเขียนเทสต์ใหม่ที่ครอบคลุมจริง ๆ ในวงการนั้นเรื่องนี้ถูกมองว่าเป็น “เรื่องปกติ” จึงเลิกทำอย่างรวดเร็ว ถ้า CS ก็ทำงานคล้าย ๆ กันตรงนี้ก็ไม่น่าแปลกใจ
ถึงอย่างไรก็เป็นเรื่องแย่มาก แต่ถ้า release โดยไม่มีการทดสอบใด ๆ เลย นั่นคือความประมาทในระดับที่น่าตกใจจริง ๆ
สิ่งที่ไม่เข้าใจเป็นเรื่องทางเทคนิคน้อยกว่ามาก แต่สำคัญกว่า คือทำไม blast radius ถึงใหญ่ขนาดนี้
เคย deploy บริการที่สำคัญน้อยกว่านี้มาก โดยมี monitoring อัตโนมัติและ rollback และค่อย ๆ deploy ช้ากว่านี้มาก เริ่มจาก deploy ไปยัง beta ที่ไม่มีทราฟฟิกลูกค้า ถ้าไม่มีปัญหาก็ค่อย deploy ไปยัง fleet ส่วนเล็ก ๆ แล้วค่อย ๆ เพิ่มสัดส่วน host ที่ได้รับอัปเดต
ถ้าทำแบบนี้ ปัญหาคงหยุดได้ทันที และเคยคิดว่านี่เป็นแนวปฏิบัติทั่วไป
เมื่อรู้จักไวรัสใหม่ แปลว่ามันแพร่กระจายอยู่ในโลกจริงแล้ว ทุกนาทีจึงสำคัญ ไม่มีใครอยากเลื่อนออกไปหนึ่งวันแล้วมารู้ทีหลังว่าเซิร์ฟเวอร์ถูกเจาะไปตั้งแต่ 20 ชั่วโมงก่อน
ความคาดหวังคงเป็นว่า แม้ไม่ต้องการการเปลี่ยนแปลงที่อาจทำให้พัง แต่ก็ยังต้องการกฎตรวจจับไวรัสล่าสุดต่อไป edge case ที่พลาดไปคือสถานการณ์ที่ config ที่ไม่ได้ทดสอบทำให้โค้ดเดิมพัง
แหล่งที่มาคือการคาดเดาล้วน ๆ ดังนั้นอย่าอ้างในบทความข่าว
มีวิธีมากมายที่จะหลีกเลี่ยงปัญหานี้ หรืออย่างน้อยก็ลดความเสี่ยงที่จะเกิดขึ้น แต่ก็เหมือนทุกครั้ง กำไรมาก่อนผู้คน
เป็นเรื่องน่าประหลาดใจที่แทบไม่มีการพูดถึง บทบาทของ Microsoft ในเหตุการณ์ครั้งนี้ Microsoft ไม่ใช่ผู้รับผิดชอบโดยตรงต่อบั๊กที่ทำให้เครื่องแครช แต่ได้สร้างสภาพแวดล้อมที่ขาดแรงจูงใจ—ทั้งผลประโยชน์และการแข่งขัน—ที่จะทำให้ Windows ทนทานต่อสถานการณ์แบบนี้ได้
Microsoft มีสถานะผูกขาดโดยพฤตินัยในพื้นที่คอมพิวติ้งเวิร์กสเตชัน และตอนนี้มันก็แทบจะเป็นโครงสร้างพื้นฐานแล้ว จึงมีหน้าที่ต้องใช้ความระมัดระวังในการรับประกันความปลอดภัย ความน่าเชื่อถือ และฟังก์ชันของผลิตภัณฑ์
เพราะไม่มีการแข่งขัน Microsoft จึงปล่อยมือจากการสร้างนวัตกรรมให้ Windows และบางส่วนของนวัตกรรมเหล่านั้นอาจช่วยป้องกันเหตุขัดข้องครั้งนี้ได้ ตัวอย่างเช่น CrowdStrike ทำงานใน user space บน macOS และ Linux แต่ Windows ให้ความสามารถที่ทำให้ CrowdStrike ทำงานใน user space ไม่ได้หรือ?
นวัตกรรมด้านแซนด์บ็อกซ์แอปพลิเคชันอาจลดความจำเป็นในการมีสิทธิ์ควบคุมระดับที่ CrowdStrike ต้องการได้ไม่ใช่หรือ?
Microsoft กุมกุญแจของโครงสร้างพื้นฐานคอมพิวติ้งของโลกไว้โดยแทบไม่มีการแข่งขัน และแทบไม่มีการกำกับดูแล Windows เคยคิดเป็นมากกว่า 80% ของรายได้ Microsoft แต่ตอนนี้ลดลงมาอยู่ราว 10%
บริษัทเอกชนจะไล่ตามเงินก็ไม่ใช่ปัญหา แต่ถ้าผลิตภัณฑ์เป็นสิ่งจำเป็นต่อการดำเนินงานของโรงพยาบาล สายการบิน และโครงสร้างพื้นฐานสำคัญ ก็ไม่ควรหมกมุ่นอยู่แต่กับผู้ช่วย AI และโฆษณาเพื่อเพิ่มความสามารถในการทำกำไร
ผมมองว่า Microsoft ละเลยหน้าที่ต้องใช้ความระมัดระวังต่อผู้บริโภค และ CrowdStrike เป็นเพียงอาการของปัญหานั้น รัฐบาลควรส่งเสริมการแข่งขันในตลาดเดสก์ท็อปเวิร์กสเปซอย่างจริงจัง หรือไม่ก็ต้องกำกับดูแลผลิตภัณฑ์ Microsoft Windows
ข้อดีอย่างหนึ่งของสัดส่วนรายได้จาก Windows ที่ลดลงคือ MS อาจไม่ยึด Windows ไว้เป็นเขตศักดิ์สิทธิ์ที่แตะต้องไม่ได้อีกต่อไป
ผมไม่ได้ใช้ CrowdStrike โดยตรง และเท่าที่รู้ก็ไม่เคยติดตั้งมันบนระบบของผม อุปกรณ์บริษัทเครื่องล่าสุดของผมน่าจะมีอะไรคล้าย ๆ กันทำงานอยู่ ดังนั้นถ้าผมเข้าใจผิดก็ช่วยแก้ให้ด้วย
ไดรเวอร์ CS ถูกติดตั้งไว้ก่อนและถอดออกไม่ได้ น่าจะถูกมอนิเตอร์ระยะไกลตรวจจับ และดูเหมือนจะทุ่มเทความพยายามไม่น้อยเพื่อให้ดัดแปลงแก้ไขได้ยาก เพราะเป็นไดรเวอร์ที่ลงลายเซ็นแล้ว
แต่ไดรเวอร์นั้นโหลด ไฟล์ข้อมูลที่ไม่ได้ลงลายเซ็น ซึ่งผู้ใช้ปลายทางสามารถลบได้ตามใจจริงหรือ? ผู้ใช้ปลายทางยังสามารถเพิ่มไฟล์แบบนี้เองเพื่อทำให้ไดรเวอร์ทำงานในแบบที่ไม่ควรทำได้หรือไม่?
ผมสงสัยว่าอะไรจะหยุดยั้งผู้ไม่หวังดีไม่ให้ใช้ไฟล์ข้อมูลอันตรายเพื่อก่อเหตุขัดข้องขนาดใหญ่อีกครั้ง หรือแย่กว่านั้นคือได้สิทธิ์เคอร์เนล
ต้องเมานต์ระบบไฟล์จากระบบปฏิบัติการอื่นเท่านั้นจึงจะทำได้ แต่โดยปกติ BitLocker จะป้องกันสิ่งนั้นไว้
ลูกค้าของ CrowdStrike มีสิทธิ์มีเสียงอะไรบ้างไหมในการปล่อยอัปเดตแบบนี้ หรือแค่ยอมรับว่า CrowdStrike จะมี การรันโค้ดจากระยะไกลแบบเต็มรูปแบบ บนทุกเครื่องขององค์กร
อย่างน้อยก็หวังว่าคนในฝั่งผู้ออกใบรับรองและคริปโตจะสามารถกันสิ่งนี้ออกจากระบบของตัวเองได้
การที่ CrowdStrike ทำส่วนนี้ให้เป็นอัตโนมัตินั่นแหละคือแก่นของผลิตภัณฑ์
บางทีเราอาจไม่ได้เห็นมันก็ได้ เพราะเราอาจเป็นหนึ่งในคนนับล้านนั้น
ผมสงสัยว่ามีใครรู้ไหมว่า “ไฟล์แชนเนล” นี้ถูกลงลายเซ็นและตรวจสอบโดย ไดรเวอร์ CS หรือเปล่า ถ้าไม่ใช่ มันก็ดูเหมือนช่องโหว่ขนาดใหญ่ที่จะนำไปสู่รูทคิต ring 0
การติดตั้งไฟล์แชนเนลต้องใช้สิทธิ์ก็จริง แต่เมื่อทำได้แล้ว ก็สามารถซ่อนตัวในจุดที่ลึกกว่ามากของระบบได้ หากไฟล์แชนเนลทำให้เกิด segmentation fault ได้ ก็น่าจะทำอะไรได้มากกว่านั้นด้วย
อินพุตทุกอย่างที่เข้าไปสู่สิ่งที่ทำงานด้วยสิทธิ์สูงขนาดนั้นควรต้องผ่านการตรวจสอบความสมบูรณ์เป็นอย่างน้อย นี่เป็นเรื่องพื้นฐาน ความจริงที่ว่าสามารถลบไฟล์แชนเนลได้ง่าย ๆ บ่งชี้ว่าไม่มีแม้แต่กลไกป้องกันการดัดแปลง