Microsoft Windows UEFI CA 인증서 만료 및 CVE-2023-24932 대응

Juhwan Song·2025년 7월 14일
0
post-thumbnail

들어가며

Microsoft는 최근 2026년 6월 25일에 만료되는 UEFI KEK CA 2011 인증서를 업데이트 하는 방법을 안내하기 시작했습니다.
이 인증서를 대체하는 새 CA 인증서는 2023년 6월 14일부터 2035년 6월 14일까지 유효합니다.

그러나 UEFI의 보안 부팅 인증 구조가 복잡하고, 이 문제와 더불어 BlackLotus에서 악용된 CVE-2023-24932의 완화 가이드가 혼용되어 시스템 운영자들에게 적지 않은 혼란을 주고 있는 모양새입니다.

이번 포스팅은 현재 상황을 정리하고, 시스템 운영자들이 케이스 별로 취해야 하는 조치에 대한 가이드를 제공합니다.

Secure Boot, KEK와 DB/DBX

UEFI의 Secure Boot 메커니즘의 구현은 간단 명료합니다. 모든 바이너리는 UEFI 롬에 사전 기록된 CA Cert를 이용해 서명되며, 서명되지 않은 바이너리는 부트 과정에서 실행이 차단됩니다.

업계에서 표준적으로 사용중인 X.509 인증서는 인증서 관리를 위한 체인과 사용자 성숙도 측면에서 큰 오버헤드 없이 보안 계층을 추가할 수 있는 방법입니다. 하지만, 라이프사이클 관리 측면에서는 그렇게 간단한 일이 아닙니다. 모든 인증서는 언젠가 만료되기 때문입니다.

그래서 MS와 인텔 등의 업계 리더들은 UEFI 표준을 만들면서 UEFI의 CA Cert를 업데이트하고, 관리할 수 있는 도구와 절차를 만드는 일에 상당한 노력을 기울였습니다[1]

사용자들은 필요하다면 자신의 CA와 서명된 바이너리를 UEFI에 통합할 수 있으며, 특히 MS는 Windows의 부트로더를 인증하기 위한 CA 인증서를 OEM이 장비를 제조할 때 내장하도록 권장 (사실상 강제)하였습니다.

그리고, 2026년에 MS의 CA 인증서가 만료되면서, 이 인증서를 새로운 인증서로 교체해야 할 필요성이 생겼습니다.

워크어라운드를 다루기에 앞서, 이 KEK CA라는 것이 하는 역할이 무엇이며, 어떻게 Secure Boot에서 바이너리의 유효성을 인증하는지 살펴보겠습니다.

UEFI의 인증 계층

UEFI는 Platform Key (PK) -> Key Exchange Key (KEK) -> DB/DBX 의 인증 계층 구조를 가지고 있습니다.

PK는 KEK를 추가하거나, 삭제하기 위해 사용되며, 일반적으로 시스템 제조사가 발행하는 UEFI의 최상위 인증서입니다. KEK는 서명 데이터베이스 (DB)를 업데이트 할 때 사용됩니다.

DB는 KEK를 사용한 서명, 서명 키 또는 SHA256 해시로 구성됩니다. UEFI에서 바이너리를 실행하기 위해서는 바이너리를 KEK로 서명하거나, 자신의 키로 서명한 다음 그 키를 DB에 업데이트 하거나, 바이너리의 SHA256 해시를 DB에 업데이트 해야 합니다.

DBX는 X.509의 인증서 해지 목록 (CRL)과 유사한 역할을 하는 것입니다. 알려진 취약점을 가진 EFI 바이너리의 해시 또는 유출된 인증서의 서명을 차단하여, 악의적인 EFI 바이너리가 실행되지 못하게 막습니다.

BlackLotus 부트킷과 완화 방법

'허용된 서명'을 가진 바이너리만을 실행하는 UEFI의 Secure Boot 메커니즘은, 허용된 바이너리에서 취약점이 발견될 경우 무력화 될 수 있습니다. CVE-2023-24932는 Windows의 부트로더에서 발견된 취약점이며, 이 취약점을 악용하는 BlackLotus 라는 부트킷이 야생에서 발견되면서 널리 알려졌습니다.

이 취약점 자체는 바로 패치되었지만, 문제가 되는 바이너리가 UEFI의 DBX에 추가되지 않았기 때문에, 공격자는 Bring Your Own Vulnerable Driver (BYOVD) 공격과 같은 방식으로 취약한 bootmgfw.efi를 반입하여 공격을 시작할 수 있었습니다.

이에 대응하여 Microsoft는 DB와 DBX를 업데이트하고, SVN 검증 기능을 활성화하는 방법을 자세히 다룬 매뉴얼을 출판하였습니다[2]

DB/DBX 자체는 현재 Windows Update를 통해 배포되지만, 여전히 문제가 된 부트로더와, 서명의 DBX 업데이트는 자동으로 적용되지 않습니다. 해당 조치는 아마도 Enforcement Phase에서 강제될 것으로 보이나, 2024년 7월, Deployment Phase에 진입한 이후로 Enforcement Phase의 전환 시점은 아직 알려지지 않았습니다.

따라서, BlackLotus와 같은 취약한 바이너리를 이용한 공격을 완화하려면 최신 보안 패치를 적용한 뒤, MS의 매뉴얼을 따라 완화 조치를 적용해야 합니다.

단, VMware 환경에서 32-bit 윈도우를 실행하는 경우, 적용 후 부팅에 실패하는 문제가 알려져 있습니다[3]

다른 플랫폼의 경우에도 부팅 이슈가 발생할 수 있으니, 반드시 Bitlocker 키를 백업하고, 사전 테스트 후 전체 시스템에 적용해야 합니다.

KEK/DBX 검증 도구

한편, 보안 커뮤니티에서는 사용자의 Windows 시스템이 유효한 KEK CA와 DBX를 가지고 있는지 검증할 수 있는 도구를 릴리즈 하였습니다[4]

이 도구를 이용해 Windows의 UEFI CA 및 DBX 적용 상태를 확인할 수 있습니다.

Windows UEFI CA 인증서 만료 대응 방안

먼저 짚고 넘어가야 할 부분은, 'UEFI CA 인증서가 만료되더라도, 시스템 부팅은 차단되지 않는다'는 것입니다.

UEFI 부트 시 인증서의 유효기간을 검증하게 되면, RTC가 초기화되었을 때 문제가 생기며, 공격자가 RTC를 조작하여 부팅을 불가능하게 만드는 DoS 공격을 시도할 수 있기 때문입니다.

다만, 만료된 KEK 인증서를 통한 DB/DBX 업데이트가 불가능해 지기 때문에 향후 취약한 바이너리를 통한 공격에 노출되거나, DB/DBX를 업데이트 하는 보안 업데이트의 설치가 실패할 수 있습니다.

Windows의 UEFI CA 인증서 만료에 대응하는 방법은 두 가지가 있습니다.

  1. 새로운 CA 인증서를 삽입한 UEFI 펌웨어 배포
  2. 운영체제 수준에서의 UEFI CA 인증서 업데이트

가장 좋은 방법은 첫 번째입니다. 펌웨어 수준에서 CA 인증서를 업데이트 하기 때문에, 공장 초기화나 Secure Boot 비활성화 등의 설정 변경이 있더라도 만료된 인증서로 롤백되지 않습니다.

하지만 이 방법은 제조사의 펌웨어 업데이트 지원이 필요하기 때문에, MS에서는 Windows Update를 통해 CA 인증서를 갱신하는 방법을 제공합니다.

이 글을 작성하는 시점 (2025년 7월)에는 자동으로 KEK CA 인증서를 업데이트 하지 않지만, 레지스트리를 통해 간단하게 이 변경사항을 트리거 할 수 있습니다.

[4]의 Repo에 있는 Apply DB update (restart required).reg 레지스트리 파일을 실행한 뒤 재부팅하거나, 다음 명령어를 관리자 권한을 가진 PowerShell로 실행하고 재부팅합니다.

참고로, 작업 스케줄러 태스크가 완료되기까지는 약 2분 정도의 시간이 필요하며, 반드시 태스크가 완료된 뒤 재부팅해야 합니다.

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x40 /f

Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"

재부팅 후 [4]의 Check UEFI KEK, DB and DBX.cmd 를 실행하면, Current UEFI DB에 Windows UEFI CA 2023 이 추가된 것을 확인할 수 있을 것입니다.

마치며

이것으로 BlackLotus가 악용한 Secure Boot 취약점을 완화하는 방법과, 만료 예정인 Windows UEFI CA 인증서를 갱신하는 방법을 알아 보았습니다.

이 변경사항은 Windows Update를 통해 2026년 중 모든 시스템에 배포될 것으로 예상되나, 에어 갭 환경에서 실행되는 시스템의 경우 시스템 관리자의 주의가 필요할 것입니다.

Reference

[1] https://github.com/microsoft/secureboot_objects

[2] https://support.microsoft.com/ko-kr/topic/cve-2023-24932%EC%99%80-%EA%B4%80%EB%A0%A8%EB%90%9C-%EB%B3%B4%EC%95%88-%EB%B6%80%ED%8C%85-%EB%B3%80%EA%B2%BD%EC%97%90-%EB%8C%80%ED%95%9C-windows-%EB%B6%80%ED%8C%85-%EA%B4%80%EB%A6%AC%EC%9E%90-%ED%95%B4%EC%A7%80%EB%A5%BC-%EA%B4%80%EB%A6%AC%ED%95%98%EB%8A%94-%EB%B0%A9%EB%B2%95-41a975df-beb2-40c1-99a3-b3ff139f832d

[3] https://knowledge.broadcom.com/external/article/325212/32bit-windows-vms-fail-to-boot-after-win.html

[4] https://github.com/cjee21/Check-UEFISecureBootVariables

profile
Virtualization / Network / Storage / Server Hardware and.. Linux

0개의 댓글