DigiCert ถูกโจมตีผ่านไฟล์สกรีนเซฟเวอร์: บทเรียนสำคัญของ Code Signing และการกันมัลแวร์

BleepingComputer อธิบายขอบเขตว่าอยู่ในวงจำกัด แต่ระบุชัดว่าการเข้าถึงดังกล่าวเปิดให้เห็น initialization codes ของใบรับรอง EV Code Signing ที่ผ่านการอนุมัติแล้วแต่ยังไม่ได้ส่งมอบ

ทำไม EV Code Signing จึงเป็นเป้าหมายที่มีค่า

Code Signing คือการลงลายเซ็นดิจิทัลให้ซอฟต์แวร์ เพื่อช่วยประเมินว่าไฟล์มาจากผู้เผยแพร่รายใดและถูกแก้ไขระหว่างทางหรือไม่ ส่วน EV หรือ Extended Validation เป็นรูปแบบที่โดยทั่วไปให้สัญญาณความน่าเชื่อถือสูงกว่าใบรับรองทั่วไปในสายตาของระบบและกระบวนการตรวจสอบบางประเภท

DigiCert เป็น Certificate Authority หรือ CA รายใหญ่ที่เบราว์เซอร์และระบบปฏิบัติการทั่วโลกไว้วางใจ และมีบทบาทสำคัญทั้งกับการสื่อสารบนอินเทอร์เน็ตและการกระจายซอฟต์แวร์ ใบรับรอง Code Signing ของบริษัทถูกใช้โดยนักพัฒนาซอฟต์แวร์จำนวนมาก

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

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

สิ่งที่รายงานไม่ได้ชี้ว่าเกิดขึ้น

จุดสำคัญคือ ต้องแยกเหตุการณ์นี้ออกจากการยึดโครงสร้าง CA ทั้งหมด แหล่งข้อมูลที่มีอยู่พูดถึงเครื่องซัพพอร์ตที่ถูกบุกรุก ฟังก์ชันพอร์ทัลซัพพอร์ตภายใน และการเข้าถึง initialization codes แต่ไม่ได้ยืนยันว่าคีย์รากของ DigiCert หรือคีย์ CA ถูก compromise

ดังนั้น จากรายงานที่มี เหตุการณ์นี้ควรถูกมองว่าเป็นการละเมิดกระบวนการซัพพอร์ตและกระบวนการออกใบรับรองรอบ Code Signing มากกว่าจะเป็นการยึด Certificate Authority ทั้งระบบ อย่างไรก็ตาม คำว่า จำกัด ไม่ได้แปลว่าไม่ร้ายแรง เพราะใบรับรองที่ดูถูกต้องเพียงไม่กี่ใบก็อาจช่วยให้มัลแวร์ผ่านด่านความเชื่อใจบางชั้นได้

ตัวเลขความเสียหาย: ต้องดูว่ากำลังนับอะไร

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

• ThreatNoir ระบุว่าเป็น Code Signing certificate จำนวนจำกัด และมีบางใบถูกนำไปใช้เซ็นมัลแวร์
• Risky Business รายงานว่ามี Code Signing certificate 27 ใบที่ถูกขโมยและถูกนำไปใช้เซ็นมัลแวร์ในภายหลัง
• ThreatLocker ระบุว่ามี Code Signing certificate รวม 60 ใบที่ถูกเพิกถอน

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

การจำกัดความเสียหาย: เพิกถอนและยกเลิกคำขอที่ค้างอยู่

DigiCert เพิกถอนใบรับรองที่ระบุได้ภายใน 24 ชั่วโมงหลังค้นพบเหตุ ตามรายงานของ BleepingComputer และกำหนดวันที่เพิกถอนย้อนหลังให้ตรงกับวันที่ออกใบรับรอง นอกจากนี้ คำสั่งซื้อหรือคำขอที่ค้างอยู่ในช่วงเวลาที่เกี่ยวข้องก็ถูกยกเลิกเป็นมาตรการป้องกัน ThreatNoir รายงานสอดคล้องกันว่าใบรับรองที่ได้รับผลกระทบถูกเพิกถอนภายใน 24 ชั่วโมง และคำสั่งซื้อที่รอดำเนินการในกรอบเวลาที่เกี่ยวข้องถูกยกเลิก

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

ผลข้างเคียงจาก Microsoft Defender: มีทั้งเหตุจริงและ false positive

ความสับสนเพิ่มขึ้นเมื่อมีรายงานเกี่ยวกับ Microsoft Defender ด้วย BleepingComputer รายงานว่า Microsoft Defender ตรวจจับใบรับรอง DigiCert ผิดพลาดเป็น Trojan:Win32/Cerdigent.A!dha ส่วน Daily.dev สรุปว่า หลังอัปเดต signature เมื่อวันที่ 30 เมษายน Defender ทำเครื่องหมายใบรับรอง root ของ DigiCert ที่ถูกต้องตามกฎหมายอย่างผิดพลาด Microsoft ออกการแก้ไขใน Security Intelligence update 1.449.430.0 และกู้คืนใบรับรองที่ถูกลบออก

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

บทเรียนสำหรับทีมความปลอดภัย

บทเรียนหลักไม่ใช่ว่า Code Signing หมดความหมาย แต่คือ Code Signing ไม่ควรเป็นสัญญาณเดียวที่ใช้ตัดสินความปลอดภัย

• ตรวจลายเซ็น แต่อย่าเชื่อแบบอัตโนมัติ ไฟล์ที่มีลายเซ็นถูกต้อง หรือแม้แต่ลายเซ็น EV ก็ไม่ควรถูกถือว่าปลอดภัยทันที เพราะผู้โจมตีสามารถใช้ใบรับรอง EV เซ็นไฟล์อันตรายและอาศัยความเชื่อใจที่มากับลายเซ็นนั้นได้
• ดูรายละเอียดของใบรับรองให้ครบ ผู้ออกใบรับรอง serial number สาย chain ของใบรับรอง timestamp และสถานะการเพิกถอน ล้วนสำคัญเมื่อไฟล์ที่เซ็นแล้วมีพฤติกรรมน่าสงสัย ในกรณี DigiCert การเพิกถอนและการกำหนดวันที่เพิกถอนย้อนหลังเป็นมาตรการสำคัญในการจำกัดผลกระทบ
• ให้พฤติกรรมของไฟล์มีน้ำหนักมากขึ้น hash การสร้างโปรเซส การเชื่อมต่อเครือข่าย กลไก persistence และผล sandbox ควรถูกนำมาประเมินร่วมกับลายเซ็น เพราะมัลแวร์ที่เซ็นแล้วถูกออกแบบมาเพื่อใช้ความเชื่อใจเป็นช่องทางผ่านด่าน
• มองพอร์ทัลซัพพอร์ตและแอดมินเป็นพื้นที่เสี่ยงสูง เหตุการณ์นี้แสดงให้เห็นว่า แม้ฟังก์ชันซัพพอร์ตที่ถูกจำกัดก็อาจกลายเป็นจุดวิกฤตได้ หากมันเปิดทางไปยังบัญชีลูกค้าหรือรหัสเริ่มต้นของใบรับรอง
• จัดการ false positive อย่างเป็นระบบ กรณี Defender ชี้ว่า การแจ้งเตือนเกี่ยวกับใบรับรองไม่ได้แปลว่ามีการติดมัลแวร์จริงเสมอไป เพราะมีรายงานว่าใบรับรอง root ของ DigiCert ที่ถูกต้องถูกตรวจจับผิดพลาดและได้รับการแก้ไขผ่านอัปเดตของ Microsoft ภายหลัง

สรุป

เหตุ DigiCert ครั้งนี้สำคัญเพราะผู้โจมตีไม่ได้แค่พยายามฝังมัลแวร์ แต่พยายามยืมความน่าเชื่อถือของ EV Code Signing ไปทำให้มัลแวร์ดูถูกต้องขึ้น รายงานที่มีอยู่ชี้ไปที่เหตุจำกัดขอบเขตรอบระบบซัพพอร์ต initialization codes และใบรับรองที่ถูกนำไปใช้ผิด ไม่ใช่การ compromise คีย์รากหรือคีย์ CA

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