꼰머의 보안공부

1. 개요

- 업데이트된 윈도우 시스템의 보안을 무너뜨릴 수 있는 두 개의 제로데이 취약점이 공개 (Windows Downdate 공격) [1]

- 다운그레이드 공격을 통해 윈도우 서버 시스템이 이전의 취약한 상태로 되돌아갈 수 있음

> 윈도우 업데이트의 액션 리스트를 조작함으로써 시스템의 구성 요소를 다운그레이드

> 공격자는 NT 커널, DLL, VBS, UEFI 기능까지 다운그레이드할 수 있음

1.1 Windows Update Architecture

- Windows Update는 COM을 통해 통신하는 업데이트 클라이언트와 업데이트 서버가 포함

> 업데이트 클라이언트는 Administrator, 업데이트 서버는 Trusted Installer가 적용되며, 업데이트 파일은 Trusted Installer만 액세스 가능

- 업데이트 흐름

① 클라이언트는 서버가 제공하는 업데이트 폴더에 포함된 업데이트를 수행하도록 서버에 요청

> 업데이트 폴더에는 업데이트 구성 요소가 들어 있음

② 서버는 업데이트 폴더의 무결성 검증

③ 무결성 검증 후, 클라이언트가 액세스할 수 없는 서버 제어 폴더에 업데이트 파일을 저장

④ 서버는 서버 제어 폴더에 작업 목록을 Pending.xml 파일로 저장하며, 해당 파일에 업데이트 작업이 포함

> 파일 생성, 파일 삭제, 파일 이동, 파일 하드 링크, 레지스트리 키 및 값 생성, 키 및 값 삭제 등의 기능을 제공하는 XML 파일

⑤ OS가 재부팅되면 작업 목록 작동 및 재부팅 중 업데이트 진행

2. 주요내용

- 윈도우 시스템을 다운그레이드 할 수 있는 제로데이 공격 Windows Downdate 발견

> CVE-2024-38202 (CVSS: 7.3): Windows Update Stack 권한 상승 취약성

> CVE-2024-21302 (CVSS: 6.7): Windows Secure Kernel Mode 권한 상승 취약성

2.1 Differential 파일 및 Action List

- 해당 공격에서는 Differential 파일 악용을 시도하였으나, 그러지 못함

> 예상 업데이트 파일의 해시 값이 Manifest 파일에 하드코딩되어 있음

> Manifest 파일 변경 시 Catalog 파일의 서명이 깨짐

- Action List의 경우 Trusted Installer가 적용되어 내용을 변경할 수 없음

> 레지스트리에서 Action List 경로를 검색해보니 PoqexecCmdline 키 발견 (목록과 목록 경로를 구문 분석하는 실행 파일을 포함)

> 해당 키의 보안 속성을 확인한 결과 Trusted Installer가 적용되지 않음

- 다운그레이드를 수행하기 위해 다음 작업을 수행

> 식별자는 무결성 확인을 위해 작업 목록의 식별자와 비교되는 숫자

> 다음 세 가지 작업 모두 Trusted Installer가 적용되지 않음

> 이를 통해 사용자 지정 다운그레이드 작업 목록으로 시스템을 업데이트할 수 있었음

* 작업 목록은 검증 후 생성되므로 검증을 가정하기 때문에 모든 무결성 검증을 우회

2.2 VBS UEFI 잠금 우회

- VBS (Virtualization-Based Security): 하드웨어 가상화 및 Windows 하이퍼바이저를 사용하여 시스템을 여러 개의 격리된 환경으로 나누고, 각 환경을 보호함으로써 전체 시스템의 보안을 강화하는 기술 [3]

- UEFI (Unified Extensible Firmware Interface): 운영 체제가 시작되기 전에 시스템을 검사하고, 보안 부팅(Secure Boot) 등의 기능을 통해 보안성을 높임 [4]

> UEFI 잠금 기능을 구현하여 VBS를 비활성화로부터 보호

> 사용자가 VBS를 비활성화하려면 MS에서 서명한 EFI 애플리케이션을 로드해야 함

> EFI는 부팅 중 사용자에게 VBS 비활성화를 물리적으로 승인하도록 요청하며, 승인 시 VBS 비활성화

- OS로더가 정상적으로 부팅되고 VBS의 파일 중 하나를 검증하지 못하면 VBS를 포기

> 해당 프로세스를 통해 VBS 비활성화 및 UEFI 잠금을 우회할 수 있었음 [5]

2.3 Exploit

- VBS의 보안 경계는 다음을 권한 상승으로 간주

> VTL0(일반적인 실행 환경) -> VTL1(보안이 강화된 환경)

> Ring3(일반적인 실행 환경)/0(커널) -> Ring -1(하이퍼바이저)

- 연구에서는 세 가지 경우를 대상으로 다운그레이드 수행

① 보안 모드의 격리된 사용자 모드 프로세스 대상

- Credential Guard

> Ring3-VTL1에서 LsaIso.exe라는 이름의 격리된 사용자 모드 프로세스로 구현

> Credential Guard를 실행하면 비밀이 원래 LSASS 프로세스 대신 VTL1의 LsaIso.exe에 저장

- CVE-2022-34709로 다운그레이드 진행 및 다운그레이드 감지 없이 허용 (Ring3-VTL0 -> Ring3-VTL1)

> CVE-2022-34709: Windows Defender Credential Guard 보안 기능 우회 취약성 [6]

② 보안 모드 커널 대상

- 보안 커널이란 일반 커널에 보안 기능을 추가하여 안전성을 강화한 커널

- CVE-2021-27090로 다운그레이드 진행 및 다운그레이드 감지 없이 허용 (Ring3-VTL0 -> Ring3-VTL1)

> CVE-2021-27090: Windows 보안 커널 모드 권한 상승 취약성 [7]

③ 하이퍼바이저 대상

- 하이퍼바이저 권한 상승 취약점이 다수 있었으나, 구체적인 내용은 공유되지 않음

> 하이퍼바이저를 2년 전 버전으로 다운그레이드 시도 및 다운그레이드 감지 없이 허용 (Ring3-VTL0 -> Ring3-VTL1)

- 24.02 MS에 내용 전달 및 MS는 24년 8월 정기 보안 업데이트에서 해당 취약점을 포함한 다수의 취약점에 대한 패치를 제공 [9]

3. 참고

[1] https://www.safebreach.com/blog/downgrade-attacks-using-windows-updates/
[2] https://www.safebreach.com/wp-content/uploads/2024/08/AFD-Downgrade-Kernel-Code-Execution.mp4
[3] https://learn.microsoft.com/ko-kr/windows-hardware/design/device-experiences/oem-vbs
[4] https://namu.wiki/w/UEFI
[5] https://www.safebreach.com/wp-content/uploads/2024/08/Credential-Extraction-PPL-and-UEFI-Lock-Bypass.mp4
[6] https://nvd.nist.gov/vuln/detail/CVE-2022-34709
[7] https://nvd.nist.gov/vuln/detail/cve-2021-27090
[8] https://www.safebreach.com/wp-content/uploads/2024/08/Hyper-V-Hypervisor-Downgrade.mp4
[9] https://msrc.microsoft.com/update-guide/releaseNote/2024-Aug
[10] https://www.dailysecu.com/news/articleView.html?idxno=158444

1. 개요

- 세계 3대 BIOS 회사(Insyde, AMI, Phoenix)에서 만든 제품 전부에 영향을 주는(세계 PC 95%) 취약점이 발견 [1]

> 여러 취약점들을 통합한 이름으로 LogoFAIL 취약점으로 명명

> IBV(Independent BIOS Vendor)는 UEFI 펌웨어가 포함된 최신 시스템에 대해 다양한 형식의 이미지 파서를 제공

> 사용자 정의 로고를 통해 입력을 지정할 수 있으며, DXE 단계에서 취약점이 발생하는 것으로 판단됨 

- 취약점을 악용하는데 성공할 경우 엔드포인트에 존재하는 모든 보안 장치들이 무력화되며, 높은 권한을 획득

1.1 UEFI (Unified Extensible Firmware Interface) [2][3]

- 통합 확장 펌웨어 인터페이스
- 운영 체제와 플랫폼 펌웨어 사이의 소프트웨어 인터페이스를 정의하는 규격
- BIOS를 대체하는 펌웨어 규격으로, 16비트 BIOS의 제약 사항 극복 및 새로운 하드웨어의 유연한 지원을 위해 64비트 기반으로 개발

1.2 ESP (EFI system partition) [2][4]

- PC가 부팅되면 UEFI는 EFI 파티션에 저장된 파일을 로드하여 운영 체제 및 기타 필요한 유틸리티를 시작

1.3 DXE (Driver Execution Environment) [2][5]

- 대부분의 시스템 초기화가 수행

2. 취약점

- 3대 BIOS는 다양한 이미지 파서를 제공

> 이미지 파서는 부팅이나 BIOS 설정 중에 로고를 표시할 수 있도록 하기 위해 존재

> 벤더사는 사용자가 파서에 입력을 지정할 수 있는 사용자 정의 기능을 제공하며, 해당 기능이 취약점을 야기

※ Insyde 기반 펌웨어: BMP, GIF, JPEG, PCX, PNG, TGA 파서
※ AMI 기반 펌웨어: 단일 BMP 파서, BMP, PNG, JPEG, GIF 파서
※ Phoenix 기반 펌웨어: BMP, GIF, JPEG 파서

※ 제공하는 파서는 다를 수 있음

- 침해된 이미지들을 EFI 시스템 파티션(ESP)이나 서명이 되지 않은 펌웨어 업데이트 영역에 삽입해 악성코드 실행

> 시스템 부팅 과정 자체를 공격자가 하이재킹 하는 것

> Secure Boot, Intel Boot Guard와 같은 보안 장치를 우회할 수 있으며, OS 단 밑에서 공격을 지속시키는 것도 가능

※ Secure Boot, Intel Boot Guard : 부팅시 펌웨어의 유효성 즉, 펌웨어의 서명을 확인해 유효한 경우 부팅을 시작 (서명을 이용해 부팅 프로세스를 검증) [6][7]

2.1 취약점 상세

- 일반적으로 로고는 펌웨어 볼륨에서 직접 읽어짐

> 볼륨은 하드웨어 기반 자체 검사 부팅 기술(예: Intel Boot Guard)로 서명 및 보호

> 공격자는 해당 섹션에 서명하는 데 사용된 OEM 캐인 키가 아닌 한 사용자 정의 로고를 사용할 수 없음

> OEM별 사용자 정의를 통해 로고를 사용할 수 있으며, 공격자 또한 동일한 방법이 사용 가능

※ OEM(Original Equipment Manufacturing): '주문자 상표 부착 생산', 주문자는 제품 계발 및 참여만 직접 하고, 생산은 하청업체나 다른 생산 라인 등에 외주

- OEM별 사용자 정의 로고를 읽는 방법은 다음과 같음

① 로고는 “\EFI\OEM\Logo.jpg” 와 같이 ESP의 고정 위치에서 읽혀짐

② OEM/IBV는 사용자 정의 로고를 설치하고 OS에서 캡슐을 플래시할 수 있는 공급업체별 통합 도구를 제공

③ NVRAM 변수에는 로고를 읽는 ESP 경로가 포함

④ 로고 자체는 압축된 형태로 NVRAM 변수 내에 저장

> 로고가 포함된 펌웨어 영역이 Boot Guard에 포함되지 않으면 공격에 악용될 수 있음

- 분석 결과 Insyde의 PNG 파서를 제외한 모든 파서는 하나 이상의 취약점이 존재

> 총 29개 중 15개는 임의 코드 실행을 야기

2.2 원인 및 PoC

- 근본적인 원인은 입력 데이터에 대한 유효성 검사의 부족

① Insyde 의 BMP 파서 버그

> RLE4/RLE8 압축을 지원하는 코드에서 취약점 발생

> PixelHeight (공격자 제어 가능) 및 변수 i 가 0 일 때 발생

> 이 경우 변수 Blt 는 BltBuffer [ PixelWidth * -1] 의 주소 로 초기화

> 공격자는 Blt를 BltBuffer 아래의 임의의 주소로 임의로 설정할 수 있음

② AMI 펌웨어 PNG 파서 버그

> 첫 번째 버그: 실패 시 NULL을 반환하는 "EfiLibAllocateZeroPool" 함수 의 반환 값에 대한 검사 누락

> 두 번째 버그: 할당 크기를 나타내는 32비트 정수의 정수 오버플로

※ 공격자가 변수 "PngWidth"를 큰 값으로 설정시 2를 곱한 결과가 오버플로되어 작은 값 할당(예: 0x80000200 * 2 = 0x400)

3. 참고

[1] https://binarly.io/posts/finding_logofail_the_dangers_of_image_parsing_during_system_boot/
[2] https://en.wikipedia.org/wiki/UEFI
[3] https://namu.wiki/w/UEFI
[4] https://en.wikipedia.org/wiki/EFI_system_partition
[5] https://uefi.org/specs/PI/1.8/V2_Overview.html
[6] https://learn.microsoft.com/ko-kr/windows-hardware/design/device-experiences/oem-secure-boot
[7] https://github.com/corna/me_cleaner/wiki/Intel-Boot-Guard
[8] https://www.boannews.com/media/view.asp?idx=124406&page=4&kind=1