การรั่วไหลของ "Golden Key" ของ Microsoft ทำให้สามารถปิดการใช้งาน Secure Boot ได้

ระบบปฏิบัติการที่ใช้ Windows ไม่ใช่ตัวเลือกเริ่มต้นและเป็นตัวเลือกอันดับต้นๆ ในวงการมือถืออีกต่อไป ลักษณะโอเพ่นซอร์สของ Android พบว่ามีแฟน ๆ จำนวนมากใน OEM และด้วยเหตุนี้โทรศัพท์จึงใช้ Windows น้อยลงเรื่อยๆ

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

ตามที่รายงานโดย อาท เทคนิคิกา และ การลงทะเบียน โดยมีข่าวมาจากก เว็บไซต์ที่อาจทำให้คุณปวดหัวได้ (ไม่ได้ล้อเล่น) นักพัฒนาบางส่วน (@never_released และ @TheWack0lian) พบว่าแบ็คดอร์ที่ Microsoft สร้างขึ้นเพื่อวัตถุประสงค์ในการแก้ไขข้อบกพร่องได้เปิดโอกาสในการปิดใช้งานการบูตอย่างปลอดภัยบนอุปกรณ์ Windows

Secure Boot และมันคืออะไร?

เมื่อคุณบู๊ตอุปกรณ์ Windows เป็นครั้งแรก ขั้นตอนการบู๊ตจะดำเนินไปตามลำดับทั่วไป: UEFI (Unified Extensible Firmware Interface ซึ่งมาแทนที่ BIOS) -> Boot Manager -> Boot Loader -> หน้าต่าง UEFI เป็นที่ที่มีฟังก์ชัน Secure Boot อยู่ ตามชื่อหมายถึง

บูตอย่างปลอดภัย, มีจุดมุ่งหมายเพื่อปรับปรุงความปลอดภัยโดยกำหนดให้ใช้ลายเซ็นดิจิทัล ในขั้นตอนถัดไป โดยพื้นฐานแล้ว หาก bootloader ไม่ได้ลงนามด้วยคีย์ที่ UEFI คาดว่าจะใช้ ขั้นตอนการบูทอุปกรณ์ของคุณจะไม่สมบูรณ์

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

ขณะนี้มีอุปกรณ์บางอย่างที่ผู้ใช้ไม่สามารถปิดใช้งาน Secure Boot ได้แม้ว่าจะต้องการก็ตาม นี่คือขอบเขตที่เนื้อหาของเราแคบลงอย่างมากจากอุปกรณ์ Windows ทั้งหมด (รวมถึง เดสก์ท็อป) ไปยังอุปกรณ์ Windows เฉพาะ เช่น อุปกรณ์ Windows Phone, อุปกรณ์ Windows RT, อุปกรณ์ Surface บางรุ่น และแม้กระทั่ง โฮโลเลนส์. อุปกรณ์ของผู้ใช้ปลายทางเหล่านี้มี Secure Boot ล็อคอยู่ซึ่งหมายความว่า ผู้ใช้ไม่สามารถแก้ไขหรือปิดใช้งานคุณลักษณะที่เกี่ยวข้องกับ Secure Boot ได้และโดยการขยายเวลา พวกเขาไม่สามารถสัมผัสระบบปฏิบัติการในลักษณะที่ไม่ได้รับอนุญาตจาก Microsoft สำหรับผู้ใช้ปลายทางได้

แต่เพื่อวัตถุประสงค์ในการพัฒนาอย่างเป็นทางการอย่างต่อเนื่อง Secure Boot จำเป็นต้องผ่อนคลายลงเล็กน้อย บนอุปกรณ์ที่มีการล็อค Secure Boot จะมีนโยบาย Secure Boot อยู่ ซึ่งสามารถช่วยในการพัฒนาที่ได้รับอนุญาตโดยไม่จำเป็นต้องปิดการใช้งาน Secure Boot ตามที่ผู้ใช้ที่ทำการวิจัยกล่าวถึง ไฟล์ Secure Boot Policy นี้จะถูกโหลดโดย Boot Manager ในช่วงต้นของกระบวนการบู๊ตสำหรับ windows ไฟล์นโยบายยังสามารถมีกฎรีจิสทรีซึ่งสามารถมีการกำหนดค่าสำหรับนโยบายได้เหนือสิ่งอื่นใด ขอย้ำอีกครั้งว่าไฟล์นโยบายจะต้องได้รับการลงนามและมีข้อกำหนดอื่นๆ ที่มีอยู่เพื่อให้แน่ใจว่ามีเพียง Microsoft เท่านั้นที่สามารถจัดเตรียมการเปลี่ยนแปลงเหล่านี้ได้

องค์ประกอบการลงนามยังขึ้นอยู่กับสิ่งที่เรียกว่า DeviceID ซึ่งใช้เมื่อนำไปใช้ ฉันจะให้โพสต์บนบล็อกอธิบายที่นี่ เนื่องจากมีบางส่วนที่ฉันยังไม่ชัดเจน:

นอกจากนี้ยังมีสิ่งที่เรียกว่า DeviceID เป็นแฮช SHA-256 แบบใส่เกลือ 64 บิตแรกของเอาต์พุต UEFI PRNG บางตัว ใช้เมื่อใช้นโยบายบน Windows Phone และบน Windows RT (mobilestartup จะตั้งค่าไว้บน Phone และ SecureBootDebug.efi เมื่อเปิดตัวเป็นครั้งแรกบน RT) บนโทรศัพท์ นโยบายจะต้องอยู่ในตำแหน่งเฉพาะบนพาร์ติชัน EFIESP พร้อมด้วยชื่อไฟล์ที่มีรูปแบบเลขฐานสิบหกของ DeviceID (ด้วย Redstone สิ่งนี้ได้เปลี่ยนเป็น UnlockID ซึ่งตั้งค่าโดย bootmgr และเป็นเพียงเอาต์พุต UEFI PRNG แบบดิบ)

โดยพื้นฐานแล้ว bootmgr จะตรวจสอบนโยบายเมื่อมีการโหลด หากมี DeviceID ซึ่งไม่ตรงกับ DeviceID ของอุปกรณ์ที่ bootmgr ทำงานอยู่ นโยบายจะไม่สามารถโหลดได้ นโยบายใดๆ ที่อนุญาตให้เปิดใช้งานการทดสอบลายเซ็น (MS เรียกนโยบายการปลดล็อคอุปกรณ์ขายปลีก / RDU เหล่านี้ และ ติดตั้งพวกเขากำลังปลดล็อคอุปกรณ์) ควรจะล็อคไว้ที่ DeviceID (UnlockID บน Redstone และ ข้างบน). อันที่จริงฉันมีนโยบายหลายประการ (ลงนามโดยใบรับรองการผลิต Windows Phone) เช่นนี้ โดยมีความแตกต่างเพียงอย่างเดียวคือ DeviceID ที่รวมอยู่และลายเซ็น หากไม่มีการติดตั้งนโยบายที่ถูกต้อง bootmgr จะกลับไปใช้นโยบายเริ่มต้นที่อยู่ในทรัพยากร นโยบายนี้เป็นนโยบายที่บล็อกการเปิดใช้งานการทดสอบลายเซ็น ฯลฯ โดยใช้กฎ BCD

นี่คือส่วนที่สิ่งต่าง ๆ น่าสนใจ ในระหว่างการพัฒนา Windows 10 v1607 Microsoft ได้สร้าง Secure Boot Policy รูปแบบใหม่ (ต่อไปนี้จะเรียกว่า SBP เพื่อความกระชับ) เพื่อการทดสอบภายในและการแก้ไขจุดบกพร่อง นโยบายนี้มีลักษณะ "เสริม" โดยไม่มี DeviceID และทำให้การตั้งค่ารวมเข้ากับนโยบายการบูตที่มีอยู่ Boot Manager จะโหลด SBP ประเภทเก่า จากนั้นตรวจสอบการลงนามและความถูกต้อง จากนั้นโหลดในนโยบายการบูตเสริมเหล่านี้ ปัญหาคือไม่มีการตรวจสอบเพิ่มเติมเกี่ยวกับนโยบายเสริมเอง นอกจากนี้ Boot Managers ที่เก่ากว่า Windows 10 v1511 ยังไม่ทราบเกี่ยวกับการมีอยู่ของลักษณะเสริมของนโยบายเหล่านี้ และด้วยเหตุนี้ ตอบสนองราวกับว่าพวกเขาโหลดนโยบายที่ถูกต้องและลงนามอย่างสมบูรณ์. ขอย้ำอีกครั้งว่าพฤติกรรมนี้น่าจะเกิดจากการพัฒนาภายใน ดังนั้นนักพัฒนาจึงไม่จำเป็นต้องลงนามระบบปฏิบัติการแต่ละเวอร์ชันและการเปลี่ยนแปลงเล็กๆ น้อยๆ ที่พวกเขาต้องทำบนอุปกรณ์

SBP นี้ถูกเรียกว่า "กุญแจสีทอง" เนื่องจากโดยพื้นฐานแล้วจะทำให้วัตถุประสงค์ของการตรวจสอบลายเซ็นเป็นโมฆะ SBP นี้ถูกจัดส่งบนอุปกรณ์ขายปลีกโดยไม่ได้ตั้งใจ แม้ว่าจะอยู่ในสถานะปิดใช้งานก็ตาม นักพัฒนาพบ SBP นี้และแจ้งให้ทราบถึงการค้นพบนี้ ตอนนี้ SBP ก็สามารถเป็นได้แล้ว พบลอยอยู่ในอินเทอร์เน็ตโดยมีการใช้ zip นี้เพื่อติดตั้ง SBP บนอุปกรณ์ Windows RT

สิ่งนี้หมายความว่า?

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

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

ผู้ใช้ที่เต็มใจไม่เพียงสามารถติดตั้ง Linux distros (และอาจเป็น Android) บนแท็บเล็ตที่ใช้ Windows เท่านั้นและ โทรศัพท์ ผู้ใช้ที่ไม่เต็มใจยังสามารถติดตั้งบูตคิทที่เป็นอันตรายได้ หากพวกเขาประนีประนอมการเข้าถึงทางกายภาพของพวกเขา อุปกรณ์. ในขณะที่อย่างแรกคือสิ่งที่เราสามารถกระโดดขึ้นไปบนอากาศได้ แต่อย่างหลังไม่ได้สร้างความมั่นใจมากนัก มันดำเนินไปทั้งสองทาง และแสดงให้เราเห็นว่าเหตุใดการรักษาความปลอดภัยจึงเป็นดาบสองคม นอกจากนี้ SBP ยังมีลักษณะเป็นสากล ทำให้สามารถใช้งานบนอุปกรณ์ใดก็ได้ โดยไม่คำนึงถึงสถาปัตยกรรม มันไม่มีประโยชน์อย่างยิ่งสำหรับกรณีของเดสก์ท็อปที่สามารถปิด Secure Boot ได้อย่างง่ายดาย แต่มีขอบเขตมากมายสำหรับอุปกรณ์ที่คุณไม่สามารถยุ่งกับ Secure Boot ได้

แล้วแก้ไขอะไรล่ะ?

Microsoft ได้เปิดตัวแพตช์บางส่วนแล้ว แต่นักพัฒนายืนยันว่าปัญหายังไม่ได้รับการแก้ไขทั้งหมด คุณสามารถตรวจสอบแพตช์เหล่านี้ได้ (MS16-094 และ MS16-100) จากนั้นอ่านต่อใน โพสต์บล็อก ว่าทำไมพวกเขาถึงไม่แก้ปัญหา หากถูกต้อง ปัญหานี้ไม่มีการแก้ไขหรือแพตช์ใดๆ ให้เห็น แม้ว่าจะไม่ได้หยุด Microsoft จากการพยายามวางสิ่งกีดขวางบนถนนเพิ่มเติม

อะไรต่อไป?

มีโลกแห่งความเป็นไปได้มากมาย และบางส่วนก็กำลังเกิดขึ้นที่ฟอรัม Windows ของเรา คุณสามารถตรวจสอบฟอรั่มของเราได้ที่ การพัฒนาและการแฮ็ก Windows Phone 8 และฟอรั่มของเราสำหรับ Windows 8, Windows RT และการพัฒนาและการแฮ็ก Surface. คุณยังสามารถค้นหา เธรดคำแนะนำสำหรับอุปกรณ์บางอย่างที่ผู้ใช้รายอื่นกำลังพูดคุยเรื่องเดียวกัน

---

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

คุณคิดอย่างไรกับการรั่วไหลของ Debug SBP คุณรู้สึกว่า "กุญแจทอง" แบบนี้ควรมีอยู่หรือไม่? แจ้งให้เราทราบในความคิดเห็นด้านล่าง!