🐞 CVE-2025-3052: IhisiParamBuffer 메모리 손상

이 저장소는 Microsoft의 타사 인증서로 서명된 UEFI 모듈의 메모리 손상 취약점인 CVE-2025-3052와 관련된 연구 자료를 중앙 집중화한 것입니다. 이 취약점을 통해 공격자는 보안에 중요한 펌웨어 구조를 손상시키고, Secure Boot 시행을 무력화하며, 운영 체제가 로드되기 전에 임의의 서명되지 않은 코드를 실행할 수 있습니다. 여기에는 근본 원인과 익스플로잇 기법에 대한 기술 분석, 실제 환경 및 교육용 취약 바이너리, 그리고 연구자들이 이 취약점 클래스를 이해하고 재현하며 실험하는 데 도움이 되는 지원 문서가 포함되어 있습니다.

📂

Secure Boot 및 Microsoft 인증서
모듈 발견 및 정찰
취약점 익스플로잇
공격 흐름
영향받는 모듈

🧠 최초 발견 및 공식 참고 자료

CVE-2025-3052는 Binarly Research Team에 의해 최초로 발견되어 책임감 있게 공개되었습니다. 공식 및 커뮤니티 참고 자료:

Binarly Research 블로그 (2025년 6월 10일)
- Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass
커뮤니티 참고 자료 모음
- Awesome Bring Your Own Vulnerable UEFI Application

🐜 취약한 바이너리

이 저장소에는 서로 다른 연구 및 학습 목표를 위해 제공되는 두 개의 취약한 바이너리가 포함되어 있습니다.

🧨 실제 환경 취약 바이너리

이 바이너리는 실제 환경에 존재했던 취약점을 나타냅니다.

CVE-2025-3052의 영향을 받은 원본 취약 UEFI 애플리케이션.
실제 환경 분석 및 리버스 엔지니어링을 위한 목적.
Microsoft의 타사 UEFI 인증서로 서명됨.
공개 악성코드 저장소에서 추출:
- VirusTotal
- MalShare

🎓 교육용 취약 바이너리

단순화된 교육용 UEFI 애플리케이션의 완전히 컴파일 가능한 소스 코드.
실제 환경 바이너리와 동일한 취약점 전제를 재현합니다.
초보자를 돕기 위해 설계됨:
- 원본 바이너리 분석을 향해 점진적으로 나아갈 수 있도록 함.
- 초기 단계에서 과도한 리버스 엔지니어링을 피할 수 있도록 함.
- 취약점 메커니즘을 이해할 수 있도록 함.

🧪 취약점 개요 (분석, 익스플로잇, PoC)

CVE-2025-3052는 UEFI 시스템에 영향을 미치는 Secure Boot 우회 취약점으로, 서명된 UEFI 애플리케이션 내부에서 NVRAM 변수로부터 검색된 데이터를 안전하지 않게 처리함으로써 발생합니다. 이 취약점을 통해 공격자는 부팅 과정에서 보안에 중요한 펌웨어 구조를 손상시켜 UEFI 신뢰 체인을 효과적으로 깨뜨리고, 운영 체제가 로드되기 전에 서명되지 않은 코드를 실행할 수 있습니다.

이 취약점이 특히 큰 영향을 미치는 이유는 버그 자체의 성격, 즉 메모리 손상 프리미티브뿐만 아니라 그것이 존재하는 맥락에 있습니다. 즉, 대부분의 현대 시스템에서 기본적으로 신뢰되는 Microsoft의 타사 UEFI 인증서로 서명된 UEFI 모듈이라는 점입니다. 결과적으로 익스플로잇은 OS 수준의 보안 제어 이전에, 플랫폼의 가장 초기이자 가장 높은 권한의 실행 단계 중 하나에서 발생합니다.

🔐 Secure Boot 및 Microsoft 인증서

Secure Boot는 펌웨어에서 운영 체제까지 플랫폼의 신뢰 체인을 시행하도록 설계된 UEFI의 핵심 보안 기능입니다. 주된 목적은 부트킷과 같은 무단 또는 악성 부팅 구성 요소가 부팅 과정에서 실행되는 것을 방지하는 것입니다.

높은 수준에서 Secure Boot는 UEFI 실행 파일이 실행되기 전에 암호학적으로 검증하는 방식으로 작동합니다. 이 검증은 펌웨어가 유지 관리하는 두 개의 데이터베이스를 사용하여 수행됩니다:

db: 신뢰할 수 있는 Authenticode 해시와 신뢰할 수 있는 루트 인증서를 포함합니다.
dbx: 폐기되었거나 명시적으로 신뢰할 수 없는 해시와 인증서를 포함합니다.

UEFI 애플리케이션은 다음 중 하나에 해당하면 실행이 허용됩니다:

해당 Authenticode 해시가 db의 항목과 일치하거나,
해당 인증서 체인이 db에 존재하는 신뢰할 수 있는 루트 인증서까지 검증되고, dbx에 존재하지 않는 경우.

기본적으로 대부분의 시스템은 다음 인증서를 db에서 신뢰하도록 제공됩니다:

Microsoft Corporation UEFI CA 2011 - Linux shim을 포함한 타사 UEFI 구성 요소에 서명하는 데 사용됩니다.
Microsoft Windows Production PCA 2011 - Windows 부트로더에 서명하는 데 사용됩니다.
하나 이상의 OEM 소유 인증서.

CVE-2025-3052와 관련된 취약한 모듈은 Microsoft Corporation UEFI CA 2011 인증서를 사용하여 서명되었습니다. 이 인증서는 벤더와 플랫폼 전반에서 널리 신뢰되기 때문에, 이를 사용하는 서명된 애플리케이션은 대부분의 UEFI 시스템에서 사용자 상호작용 없이 실행될 수 있습니다. 이러한 광범위한 신뢰는 Secure Boot의 의도된 보호 보장을 효과적으로 우회하기 때문에, 이러한 모듈 내 취약점의 영향을 크게 증폭시킵니다.

🔎 모듈 발견 및 정찰

취약한 UEFI 모듈은 공개 악성코드 저장소, 특히 VirusTotal에 업로드된 UEFI 바이너리에 대한 대규모 분석 중에 최초로 발견되었습니다. 이 모듈의 최초 공개 제출은 2024년 11월에 이루어졌지만, Authenticode 서명을 검사한 결과 이미 2022년 10월에 서명된 것으로 나타나, 이 바이너리가 탐지되기 전 상당한 기간 동안 유포되었을 가능성을 시사했습니다.

분석 중 관찰된 원래 파일 이름은 Dtbios-efi64-71.22.efi였습니다. 내장 문자열, 인증서 메타데이터, 파일 동작을 조사한 결과, 이 모듈은 견고한 모바일 컴퓨팅 장치를 전문으로 하는 벤더인 DT Research, Inc에 의해 개발된 것으로 강하게 추정되었습니다.

추가 리버스 엔지니어링을 통해 이 모듈이 BIOS 플래싱 유틸리티로, 디스크에서 펌웨어 이미지를 읽어 시스템 ROM에 기록하도록 설계되었음이 밝혀졌습니다. 원래는 DT Research 하드웨어용으로 의도되었지만, 이 모듈은 특정 플랫폼에 제한되지 않으며 Microsoft 타사 UEFI 인증서를 신뢰하는 모든 시스템에서 실행될 수 있습니다.

정찰 중 중요한 단서는 IhisiParamBuffer NVRAM 변수의 존재였습니다. 이 변수는 Insyde 기반 펌웨어 구현과 밀접하게 연관되어 있으며, 이전에 Binarly가 공개한 다른 취약점들(예: BRLY-2022-023 및 BRLY-2023-005)에도 관련된 바 있습니다. 그 존재는 즉시 NVRAM 관련 문제의 잠재적 부류를 시사했습니다.

💥 취약점 발견 및 익스플로잇

CVE-2025-3052의 근본 원인은 NVRAM 변수에서 읽은 데이터를 검증 없이 안전하지 않게 사용하는 데 있습니다. 구체적으로:

UEFI 애플리케이션이 IhisiParamBuffer NVRAM 변수의 값을 검색합니다.
이 값은 신뢰할 수 있는 포인터로 취급되어 주소 0xf7a0의 전역 변수에 저장됩니다.
이후 코드는 global + 0x18에서 메모리 쓰기 작업을 수행하여 해당 주소를 0으로 설정합니다.
동일한 공격자 제어 NVRAM 값에서 파생된 추가 쓰기 작업이 이어집니다.
어느 시점에서도 경계 검사, 정상성 검증, 접근 제어가 적용되지 않습니다.

결과적으로 IhisiParamBuffer 변수를 제어할 수 있는 공격자는 이러한 쓰기가 메모리 내 어디에서 발생할지 영향을 미칠 수 있는 능력을 얻게 됩니다. 쓰기 프리미티브는 다소 제한적이어서 일반적으로 임의 주소에 0 또는 작은 상수를 쓰는 것만 허용하지만, 여전히 중요한 펌웨어 상태를 손상시키기에 충분히 강력합니다.

Binarly의 개념 증명에서 공격은 Security2 Architectural Protocol에 대한 포인터를 보유하는 전역 변수 gSecurity2를 대상으로 합니다(이 특정 익스플로잇 기법에 대한 자세한 설명은 다음 저장소 "TheMalwareGuardian: Exploitation Technique SecureBoot Bypass gSecurity2 Corruption"을 참조하십시오). 이 프로토콜은 Secure Boot 정책을 시행하기 위해 LoadImage 서비스에서 참조됩니다. 즉, gSecurity2를 null 포인터로 덮어쓰면 런타임에 Secure Boot 검사가 효과적으로 비활성화됩니다. 결정적으로, 이 우회는 운영 체제에 투명합니다. 부팅이 완료되면 Secure Boot는 펌웨어 수준에서 완전히 무력화되었음에도 불구하고 OS 수준에서는 여전히 활성화된 것처럼 보입니다.

중요한 미묘한 점은 Insyde 기반 플랫폼에서 IhisiParamBuffer 변수가 일반적으로 읽기 전용으로 잠겨 있어, 추가 취약점 없이는 해당 시스템에서 익스플로잇을 효과적으로 방지한다는 것입니다. 아이러니하게도, 이는 취약한 변수 패턴을 처음 도입한 IBV의 벤더가 가장 노출이 적은 대상 중 하나인 반면, 다른 모든 플랫폼은 여전히 위험에 처해 있음을 의미합니다. 변수가 잠겨 있는 경우, BRLY-2023-005와 같은 우회를 연계하여 익스플로잇을 진행하기 전에 변수에 대한 쓰기 접근 권한을 얻을 수 있습니다. 변수가 직접 쓰기 가능한 시스템에서는 공격이 간단하고 매우 안정적입니다.

🎯 공격 흐름

다음은 OS 수준 접근 권한을 가진 권한 있는 공격자를 가정하여 CVE-2025-3052를 활용한 종단 간 공격을 설명합니다:

NVRAM 변수 설정: 공격자는 운영 체제에서 IhisiParamBuffer NVRAM 변수를 임의의 대상 주소로 설정하여 gSecurity2를 가리키도록 합니다.
페이로드 등록: 공격자는 취약한 서명된 모듈을 UEFI Boot Manager에 등록하고(또는 기존 OS 로더를 이 모듈로 교체), 추가로 실제 페이로드를 포함하는 두 번째 서명되지 않은 모듈을 등록합니다.
재부팅: 시스템이 재부팅된 후, 펌웨어는 Boot Device Selection (BDS) 단계에 진입하여 등록된 부팅 항목을 실행하기 시작합니다.
실행: 취약한 서명된 모듈이 먼저 실행됩니다. 제한된 쓰기 프리미티브를 사용하여 gSecurity2를 null로 덮어쓰고 Secure Boot 시행을 비활성화합니다. 검사가 무력화된 상태에서 펌웨어는 서명되지 않은 페이로드 모듈을 로드하고 실행하여, 운영 체제가 자체 방어를 구축할 기회를 갖기 전에 DXE 단계 끝에서 공격자에게 임의 코드 실행 권한을 부여합니다.

📦 영향받는 모듈

Microsoft는 14개의 서로 다른 UEFI 모듈이 영향을 받은 것으로 판단하고, 해당 해시를 Secure Boot dbx에 추가하여 문제를 완화했습니다.

모듈 이름	Authenticode SHA-256 해시
BiosFlashShell-efi64-80.02.efi	C54A4060B3A76FA045B7B60EEAEBC8389780376BA3EF1F63D417BA1B5528E95
BiosFlashShell-efi64-81.02.efi	CBFAA286144EB2D165A6B17245BAD4F73058436C7292BE56DC6EBA29A369ADDF
Dtbios-efi64-70.17.efi	9D7E7174C281C6526B44C632BAA8C3320ADDD0C77DC90778CC14893882D74618
Dtbios-efi64-70.18.efi	9B1F35052CFC5FB06DABE5E8F7B747F081DA28D722DB59ADE253B9E38A7A3C76
Dtbios-efi64-70.19.efi	E3CE55E584371D3F2FBCA2241EF0711FF80876EBF71BAB07D8ECEE645A40DCFC
Dtbios-efi64-70.20.efi	EE093913ABBD34CB8B5EA31375179A8B55A298353C03AFE5055AA4E8E3F705EF
Dtbios-efi64-70.21.efi	B4E1880425F7857B741B921D04FD9276130927CF90A427C454B970E7A2F442F9
Dtbios-efi64-70.22.efi	CDA0B4A59390B36E1B654850428CBB5B4C7B5E4349E87ACDE97FB543736FF1D4
Dtbios-efi64-71.17.efi	C87EFD057497F90321D62A69B311912B8EF8A045FE9C5E6BD5C8C1A4E6F39629
Dtbios-efi64-71.18.efi	9E19DD645235341A555D6AC0665591453AE13918ECD37DF22DFBEE91EAA9A2DA
Dtbios-efi64-71.19.efi	63F67824FDA998798964FF33B87441857DA92F3A8EE3E04166EEC3156E4E6B82
Dtbios-efi64-71.20.efi	0BC4F078388D41AB039F87AE84CF8D39302CCBDD70C4ADEE02263EBF6A2DD328
Dtbios-efi64-71.21.efi	E2AEC271B9596A461EB6D54DB81785E4E4C615CFDA5F4504BCC0A329248A4D36
Dtbios-efi64-71.22.efi	6B4328EBCBE46ED9118FF2D4472DE329D70BA83016DF7A6F50F8AF92342160A1

🤝 연구 및 협업

비슷한 작업을 하고 계신가요? UEFI, 커널 보안, 익스플로잇 또는 다른 흥미로운 보안 주제를 연구하고 계신가요? 익스플로잇 개발, 기법 탐구에 도움이 필요하거나 단순히 아이디어를 교환하고 싶다면 주저하지 말고 연락해 주세요. 저는 항상 연구에 대해 논의하고, 도울 수 있는 부분을 돕고, 흥미로운 프로젝트에서 협업하는 것에 열려 있습니다. LinkedIn으로 편하게 연락해 주세요.

CVE-2025-3052 — Updated!