최근 Microsoft의 "골든 키" 유출과 디버그 모드 존재로 인해 Windows 장치에서 보안 부팅이 비활성화되었습니다. 읽어!
Windows 기반 OS는 더 이상 모바일 환경에서 기본이자 최고의 선택이 아닙니다. Android의 오픈 소스 특성은 OEM에서 많은 팬을 확보했으며 그 결과 요즘에는 Windows를 사용하는 휴대폰이 점점 줄어들고 있습니다.
하지만 여전히 일상 생활에서 Windows 장치를 계속 사용하고 계시다면 몇 가지 소식이 있습니다. 좋든 나쁘든 그것은 이 뉴스의 사용 사례에 대한 귀하의 입장과 해석에 달려 있습니다.
보고된 바와 같이 아르스 테크니카 그리고 등록 한 곳에서 나온 소식으로 당신에게 두통을 줄 가능성이 있는 웹사이트 (농담 아님) 몇몇 개발자(@never_released 그리고 @TheWack0lian)는 Microsoft가 디버그 목적으로 구운 백도어로 인해 Windows 장치에서 보안 부팅을 비활성화할 가능성이 있다는 사실을 발견했습니다.
보안 부팅이란 무엇입니까?
Windows 장치를 처음 부팅할 때 부팅 절차는 다음과 같은 일반적인 순서로 진행됩니다. UEFI (BIOS를 대체하는 통합 확장 가능 펌웨어 인터페이스) -> 부트 관리자 -> 부트 로더 -> 윈도우. UEFI에는 보안 부팅 기능이 있습니다. 이름에서 알 수 있듯이 보안 부트, 디지털 서명을 요구하여 보안을 향상시키는 것을 목표로 합니다. 다음 단계에서. 기본적으로 부트로더가 UEFI에서 사용할 것으로 예상하는 키로 서명되지 않은 경우 장치 부팅 절차가 완료되지 않습니다.
보안 부팅은 선택적인 기능이지만 Microsoft는 Windows 8 이상에서 Windows 인증을 받기 위해 이를 필수로 활성화했습니다. 그 이유는 Secure Boot로 인해 맬웨어 작성자가 부팅 절차에 코드를 삽입하기가 어려워지기 때문입니다. 그러나 보안 부팅의 부작용은 Windows 시스템에서 이중 부팅을 하기가 약간 복잡하다는 것입니다. 두 번째 OS와 모든 사전 요구 사항도 디지털 서명이 필요하거나 보안 부팅이 필요합니다. 장애가 있는. 여기에는 다른 많은 문제가 있으며 노련한 듀얼 부팅 사용자는 내가 한 단락에서 설명할 수 있는 것보다 더 많은 문제에 대해 알고 있을 것입니다.
이제 사용자가 원하더라도 보안 부팅을 비활성화할 수 없는 일부 장치가 있습니다. 이는 우리의 주제가 모든 Windows 장치(포함)에서 대폭 좁아지는 영역입니다. 데스크톱)을 Windows Phone 장치, Windows RT 장치, 일부 Surface 장치와 같은 특정 Windows 장치에 연결합니다. 홀로렌즈. 이러한 최종 사용자 장치에는 보안 부팅이 켜져 있음, 즉 최종 사용자는 보안 부팅과 관련된 측면을 수정하거나 비활성화할 수 없습니다., 더 나아가 최종 사용자에 대해 Microsoft가 승인하지 않은 방식으로 OS를 건드릴 수 없습니다.
그러나 지속적인 공식 개발을 위해서는 보안 부팅을 약간 느슨하게 해야 합니다. 보안 부팅이 잠겨 있는 장치에는 보안 부팅을 비활성화할 필요 없이 승인된 개발에 도움이 될 수 있는 보안 부팅 정책이 존재합니다. 연구 사용자가 언급했듯이 이 보안 부팅 정책 파일은 Windows 부팅 프로세스 초기에 부팅 관리자에 의해 로드됩니다. 정책 파일에는 무엇보다도 정책 자체에 대한 구성을 포함할 수 있는 레지스트리 규칙이 포함될 수도 있습니다. 다시 말하지만, 정책 파일에 서명해야 하며 Microsoft만이 이러한 변경 사항을 제공할 수 있도록 보장하는 다른 조항이 마련되어 있습니다.
서명 요소는 적용 시 사용되는 DeviceID에도 의존합니다. 여기에서는 명확하지 않은 부분이 몇 가지 있기 때문에 블로그 게시물에서 설명하도록 하겠습니다.
또한 DeviceID라는 것이 있습니다. 일부 UEFI PRNG 출력 중 솔트 처리된 SHA-256 해시의 첫 번째 64비트입니다. 이는 Windows Phone 및 Windows RT에서 정책을 적용할 때 사용됩니다(mobilestartup은 이를 Phone에 설정하고 RT에서 처음 실행될 때 SecureBootDebug.efi를 설정합니다). 전화에서 정책은 DeviceID의 16진수 형식을 포함하는 파일 이름을 사용하여 EFIESP 파티션의 특정 위치에 있어야 합니다. (Redstone을 사용하면 이는 bootmgr에 의해 설정되고 원시 UEFI PRNG 출력인 UnlockID로 변경되었습니다.)
기본적으로 bootmgr은 정책이 로드될 때 정책을 확인하며, bootmgr이 실행 중인 장치의 DeviceID와 일치하지 않는 DeviceID가 포함되어 있으면 정책이 로드되지 않습니다. 테스트 서명 활성화를 허용하는 모든 정책(MS는 이러한 소매 장치 잠금 해제/RDU 정책이라고 함) 설치하면 장치 잠금이 해제됨) DeviceID(Redstone의 UnlockID 및 위에). 실제로 이와 같은 여러 정책(Windows Phone 프로덕션 인증서로 서명됨)이 있는데 유일한 차이점은 포함된 DeviceID와 서명뿐입니다. 유효한 정책이 설치되어 있지 않으면 bootmgr은 해당 리소스에 있는 기본 정책을 사용하도록 대체됩니다. 이 정책은 BCD 규칙을 사용하여 테스트 서명 등을 활성화하는 것을 차단하는 정책입니다.
이것은 일이 흥미로워지는 부분입니다. Windows 10 v1607을 개발하는 동안 Microsoft는 내부 테스트 및 디버깅 목적으로 새로운 유형의 보안 부팅 정책(이하 간략화를 위해 SBP라고 함)을 만들었습니다. 정책은 본질적으로 DeviceID가 없는 "보충" 정책이므로 해당 설정이 기존 부팅 정책에 병합됩니다. 부팅 관리자는 이전 유형의 SBP를 로드한 다음 서명 및 신뢰성을 확인한 다음 이러한 보충 부팅 정책을 로드합니다. 여기서 문제는 보완정책 자체에 대한 추가 검증이 없다는 점이다. 또한 Windows 10 v1511 이전의 부팅 관리자는 이러한 정책의 보완적인 성격이 존재하는지 알지 못합니다. 완벽하게 유효하고 서명된 정책을 로드한 것처럼 반응합니다.. 다시 말하지만, 이 동작은 내부 개발을 위한 것일 가능성이 높으므로 개발자는 장치에서 수행해야 하는 모든 OS 버전과 사소한 변경 사항에 각각 서명할 필요가 없었습니다.
이 SBP는 기본적으로 서명 확인의 목적을 무효화하므로 "골든 키"라고 합니다. 이 SBP는 비활성화된 상태이기는 하지만 의도치 않게 소매 장치에 배송되었습니다. 개발자들은 이 SBP를 발견하고 그 결과를 공개했습니다. 이제 SBP는 다음과 같습니다. 인터넷에 떠돌다가 발견한, 이 특정 zip은 Windows RT 장치에 SBP를 설치하는 데 사용됩니다.
이것은 무엇을 의미 하는가?
추가 SBP를 로드한 경우 Windows용 테스트 서명을 활성화하여 서명되지 않은 드라이버를 로드할 수 있습니다. 또한 이러한 정책은 부팅 절차의 부팅 관리자 단계 이전에 적용되므로 전체 주문의 보안을 손상시키고 무단(자체 서명 읽기) 코드를 실행할 수 있습니다. 이는 인증을 넘어서 Windows의 일부를 수정하려는 사용자와 맬웨어 제작자 모두에게 많은 가능성을 열어줍니다.
이 발견의 저자는 전체 실패의 아이러니에 중점을 둡니다. Microsoft는 승인되지 않은 변경 사항을 멀리 유지하기 위해 특정 장치에서 보안 부팅을 잠갔지만 개발 및 디버깅을 계속할 수 있도록 백도어를 내장했습니다. 그러나 바로 이 백도어는 Windows를 실행하는 모든 장치에서 보안 부팅을 비활성화하여 전체 시련을 무의미하게 만드는 길을 열어줍니다.
이제 기꺼이 사용자가 Windows 전용 태블릿에 Linux 배포판(및 가능하면 Android)을 설치할 수 있을 뿐만 아니라 휴대폰, 원하지 않는 사용자는 휴대폰에 대한 물리적 액세스를 손상시키는 경우 악성 부트킷을 설치할 수도 있습니다. 장치. 전자는 우리가 공중으로 뛰어오를 수 있는 반면, 후자는 실제로 많은 자신감을 심어주지는 않습니다. 양방향으로 진행되며 보안이 양날의 검인 이유를 보여줍니다. 또한 SBP는 본질적으로 보편적이므로 아키텍처에 관계없이 모든 장치에서 사용할 수 있습니다. 보안 부팅을 쉽게 끌 수 있는 데스크톱의 경우에는 특히 유용하지 않지만, 보안 부팅을 사용할 수 없는 장치에는 엄청난 범위를 제공합니다.
그렇다면 해결책은 무엇입니까?
Microsoft는 일부 패치를 출시했지만 개발자는 문제가 완전히 해결되지 않았다고 주장합니다. 이 패치를 확인할 수 있습니다(MS16-094 그리고 MS16-100) 그런 다음 다음 내용을 읽어보세요. 블로그 게시물 문제를 해결하지 못하는 이유에 대해 스스로 설명합니다. 그것이 맞다면 이 문제에는 수정이나 패치가 보이지 않지만 Microsoft가 더 많은 장애물을 배치하는 것을 막지는 못할 것입니다.
다음은 무엇입니까?
가능성의 세계는 무궁무진하며 그 중 일부는 Windows 포럼에서 논의되고 있습니다. 다음에서 포럼을 확인하실 수 있습니다. Windows Phone 8 개발 및 해킹 그리고 우리의 포럼 Windows 8, Windows RT 및 Surface 개발 및 해킹. 당신은 또한 찾을 수 있습니다 일부 장치에 대한 명령 스레드, 다른 사용자가 동일한 내용을 논의하고 있습니다.
이 디버그 백도어의 존재와 SBP 유출은 제3자에게만 중요한 것이 아닙니다. 잠긴 Windows 장치의 개발은 의도적인 경우 어떤 일이 발생할 수 있는지에 대한 암울한 알림도 보여줍니다. 백도어가 남았습니다. 최근 보안에 대한 초점은 법적 수사 목적을 지원하기 위해 이러한 백도어의 존재를 요구하는 수사 기관으로 바뀌었습니다. 그러나 조만간 이러한 방법은 ~ 할 것이다 잘못된 손에 넘어갑니다. 범죄와 싸우고 정의를 돕는 도구로 사용되도록 의도된 것이 언젠가는 범죄 자체의 도구가 될 것입니다.
Debug SBP 유출에 대해 어떻게 생각하시나요? 이런 "황금 열쇠"가 존재해야 한다고 생각하시나요? 아래 댓글로 알려주세요!