슈뢰딩거의 믿음직한 장화. 인텔 부트 가드

우리는 다시 낮은 수준으로 내려가 펌웨어 x86 호환 컴퓨터 플랫폼의 보안에 대해 이야기할 것을 제안합니다. 이번 연구의 주요 요소는 컴퓨터 시스템 공급업체가 생산 단계에서 영구적으로 활성화 또는 비활성화할 수 있는 하드웨어 지원 BIOS 신뢰할 수 있는 부팅 기술인 Intel Boot Guard(Intel BIOS Guard와 혼동하지 마십시오!)입니다. 음, 우리는 이미 연구 방법을 알고 있습니다. 리버스 엔지니어링을 통해 이 기술의 구현을 얇게 자르고, 아키텍처를 설명하고, 문서화되지 않은 세부 정보로 채우고, 맛보기 위해 공격 벡터로 양념하고 혼합합니다. 몇 년 동안 여러 벤더의 제품에서 복제된 버그가 어떻게 잠재적인 공격자가 이 기술을 사용하여 시스템에서 제거할 수 없는(프로그래머도) 숨겨진 루트킷을 만들 수 있는지에 대한 이야기로 불을 붙입니다.

그건 그렇고, 이 기사는 컨퍼런스의 "On Guard for Rootkits: Intel BootGuard" 보고서를 기반으로 합니다. 제로나이츠 2016 그리고 29일 회의 데프콘 러시아 (두 프레젠테이션 모두 여기에).

Intel 64 아키텍처를 사용하는 컴퓨터 플랫폼용 펌웨어

먼저 Intel 64 아키텍처를 사용하는 최신 컴퓨터 플랫폼의 펌웨어는 무엇입니까?라는 질문에 답해 봅시다. 물론 UEFI BIOS입니다. 그러나이 대답은 정확하지 않습니다. 이 아키텍처의 데스크톱(노트북) 버전을 보여주는 그림을 살펴보겠습니다.

기초는 다음 링크입니다.

• 프로세서(CPU, Central Processing Unit): 기본 코어 외에 내장형 그래픽 코어(일부 모델 아님) 및 메모리 컨트롤러(IMC, 통합 메모리 컨트롤러)가 있습니다.
• 주변 장치와 상호 작용하고 하위 시스템을 관리하기 위한 다양한 컨트롤러가 포함된 칩셋(PCH, Platform Controller Hub). 그중에는 펌웨어(Intel ME 펌웨어)도 있는 악명 높은 Intel ME(Management Engine)가 있습니다.

위의 것 외에도 노트북에는 전원 하위 시스템, 터치 패드, 키보드, Fn 키(화면 밝기, 사운드 볼륨, 키보드)의 작동을 담당하는 통합 컨트롤러(ACPI EC, 고급 제어 및 전원 인터페이스 내장 컨트롤러)가 필요합니다. 백라이트 등).) 등. 그리고 그는 또한 자신의 펌웨어를 가지고 있습니다.

따라서 위의 펌웨어 조합은 공통 SPI 플래시 메모리에 저장되는 컴퓨터 플랫폼(시스템 펌웨어)의 펌웨어입니다. 이 메모리의 사용자가 누군가가 누워있는 곳을 혼동하지 않도록 이 메모리의 내용은 다음 영역으로 나뉩니다(그림 참조).

• UEFI 바이오스;
• ACPI EC 펌웨어(Skylake 프로세서 마이크로아키텍처(2015)와 함께 별도의 영역이 등장했지만 실제 사용 사례는 아직 본 적이 없으므로 임베디드 컨트롤러 펌웨어는 여전히 UEFI BIOS의 일부입니다.)
• 인텔 ME 펌웨어;
• 내장 GbE(기가비트 이더넷) 네트워크 어댑터의 구성(MAC 주소 등)
• 플래시 디스크립터 - 다른 영역에 대한 포인터와 액세스 권한을 포함하는 플래시 메모리의 주요 영역입니다.

영역에 대한 액세스 차별화(지정된 권한에 따라)는 이 메모리에 액세스하는 칩셋에 내장된 SPI 컨트롤러인 SPI 버스 마스터에 의해 처리됩니다. 권한이 Intel에서 권장하는(보안상의 이유로) 값으로 설정되면 SPI 플래시의 각 사용자는 해당 지역에 대해서만 전체 액세스(읽기/쓰기) 권한을 갖습니다. 나머지는 읽기 전용이거나 액세스할 수 없습니다. 알려진 사실: 많은 시스템에서 CPU는 UEFI BIOS 및 GbE에 대한 전체 액세스 권한이 있고 플래시 설명자에 대한 읽기 액세스 권한만 있으며 Intel ME 영역에 대한 액세스 권한은 전혀 없습니다. 전부가 아닌 많은 이유는 무엇입니까? 권장 사항은 선택 사항입니다. 이 기사의 뒷부분에서 자세히 알려 드리겠습니다.

수정으로부터 컴퓨터 플랫폼의 펌웨어를 보호하는 메커니즘

분명히 컴퓨터 플랫폼의 펌웨어는 가능한 손상으로부터 보호되어야 합니다. 그러면 잠재적인 공격자가 발판을 마련하고(생존 OS 업데이트/재설치) 가장 권한 있는 모드에서 코드를 실행할 수 있습니다. 물론 SPI 플래시 메모리 영역에 대한 액세스를 구분하는 것만으로는 충분하지 않습니다. 따라서 펌웨어가 수정되지 않도록 보호하기 위해 각 실행 환경에 특정한 다양한 메커니즘이 사용됩니다.

따라서 Intel ME 펌웨어는 무결성 및 인증 제어를 위해 서명되었으며 ME UMA 메모리에 로드될 때마다 ME 컨트롤러에서 확인합니다. 이 확인 프로세스는 이미 다음 중 하나에서 논의되었습니다. 조항Intel ME 하위 시스템 전용입니다.

그리고 ACPI EC 펌웨어는 원칙적으로 무결성에 대해서만 확인됩니다. 그러나 이 바이너리가 UEFI BIOS에 포함되어 있기 때문에 거의 항상 UEFI BIOS가 사용하는 것과 동일한 보호 메커니즘이 적용됩니다. 그들에 대해 이야기합시다.

이러한 메커니즘은 두 가지 범주로 나눌 수 있습니다.

UEFI BIOS 영역에 대한 쓰기 방지

1. 쓰기 방지 점퍼로 SPI 플래시 메모리 내용의 물리적 보호
2. 칩셋의 PRx 레지스터를 사용하여 CPU 주소 공간에서 UEFI BIOS 영역의 프로젝션 보호
3. 칩셋 레지스터에서 BIOS_WE/BLE 및 SMM_BWP 비트를 설정하여 해당 SMI 인터럽트를 생성 및 처리하여 UEFI BIOS 영역에 쓰기 시도를 차단합니다.
4. 이 보호 기능의 고급 버전은 PFAT(Intel BIOS Guard)입니다.

이러한 메커니즘 외에도 공급업체는 고유한 보안 조치(예: UEFI BIOS 업데이트로 캡슐 서명)를 개발하고 구현할 수 있습니다.

특정 시스템(공급업체에 따라 다름)에서는 위의 모든 보호 메커니즘이 적용되지 않거나 전혀 적용되지 않거나 취약한 방식으로 구현될 수 있다는 점에 유의해야 합니다. 이러한 메커니즘과 구현 상황에 대한 자세한 내용은 다음에서 확인할 수 있습니다. 이 기사. 관심 있는 분들은 UEFI BIOS 보안에 대한 전체 기사 시리즈를 다음 사이트에서 읽어 보시기 바랍니다. 코드러쉬.

UEFI BIOS 인증 확인

신뢰할 수 있는 부팅 기술에 대해 이야기할 때 가장 먼저 떠오르는 것은 보안 부팅입니다. 그러나 아키텍처적으로는 펌웨어 자체가 아니라 UEFI BIOS 외부의 구성 요소(드라이버, 로더 등)를 인증하도록 설계되었습니다.

따라서 Intel은 Bay Trail 마이크로아키텍처(2012)를 사용하는 SoC에서 하드웨어 전환 불가능한 보안 부팅(Verified Boot)을 구현했으며, 이는 앞서 언급한 보안 부팅 기술과 관련이 없습니다. 나중에(2013) 이 메커니즘이 개선되었고 Intel Boot Guard라는 이름으로 Haswell 마이크로아키텍처가 있는 데스크탑용으로 출시되었습니다.

Intel Boot Guard를 설명하기 전에 Intel 64 아키텍처의 실행 환경을 살펴보겠습니다. 이 환경은 신뢰할 수 있는 부팅 기술에 대한 신뢰의 근원입니다.

인텔 CPU

Cap은 프로세서가 Intel 64 아키텍처의 주요 실행 환경이라고 제안하는데 왜 이것이 신뢰의 근원이기도 합니까? 그렇게 만드는 것은 다음 요소를 소유하고 있음이 밝혀졌습니다.

• 마이크로코드 ROM은 마이크로코드를 저장하기 위한 비휘발성, 재기록 불가능 메모리입니다. 마이크로코드는 가장 간단한 명령어에 대한 프로세서 명령어 시스템의 구현이라고 믿어집니다. 마이크로코드에서도 발생 버그. 따라서 BIOS에서 마이크로코드 업데이트가 포함된 바이너리를 찾을 수 있습니다(ROM을 덮어쓸 수 없기 때문에 부팅 시 중첩됩니다). 이러한 바이너리의 콘텐츠는 암호화되어 분석이 매우 복잡해지며(따라서 마이크로코드의 특정 콘텐츠는 이를 개발한 사람만 알 수 있음) 서명되어 무결성과 신뢰성을 제어합니다.
• 마이크로코드 업데이트 내용을 해독하기 위한 AES 키
• 마이크로코드 업데이트의 서명을 확인하는 RSA 공개 키의 해시
• RSA 공개 키 해시는 인텔에서 개발한 ACM(Authenticated Code Module) 코드 모듈의 서명을 확인하며 BIOS가 시작되기 전(hello 마이크로코드) 또는 작동 중에 일부 이벤트가 발생할 때 CPU가 실행할 수 있습니다.

인텔 ME

우리 블로그의 이 하위 시스템은 две 조항. 이 실행 가능한 환경은 칩셋에 내장된 마이크로컨트롤러를 기반으로 하며 시스템에서 가장 숨겨져 있고 특권이 있음을 기억하십시오.

스텔스에도 불구하고 Intel ME는 다음과 같은 이점이 있기 때문에 신뢰의 근원이기도 합니다.

• ME ROM - 시작 코드와 Intel ME 펌웨어의 서명을 확인하는 RSA 공개 키의 SHA256 해시를 포함하는 비휘발성, 재기록 불가능 메모리(제공된 업데이트 방법 없음)
• 비밀 정보를 저장하기 위한 AES 키;
• 컴퓨터 시스템 공급업체가 지정한 정보를 포함하여 일부 정보를 영구적으로 저장하기 위해 칩셋에 통합된 퓨즈 세트(FPF, Field Programmable Fuse)에 대한 액세스.

인텔 부트 가드 1.x

작은 면책 조항. 이 문서에서 사용하는 Intel Boot Guard 기술의 버전 번호는 임의적이며 내부 Intel 설명서에 사용된 번호와 관련이 없을 수 있습니다. 또한, 여기에 제공된 이 기술의 구현에 대한 정보는 리버스 엔지니어링 중에 얻은 것이며, 공개되지 않을 가능성이 있는 Intel Boot Guard 사양에 비해 부정확한 내용이 포함될 수 있습니다.

따라서 Intel Boot Guard(BG)는 하드웨어 지원 UEFI BIOS 인증 기술입니다. 책 [Platform Embedded Security Technology Revealed, Chapter Boot with Integrity or Not Boot]의 작은 설명으로 판단하면 신뢰할 수 있는 부트 체인으로 작동합니다. 그리고 첫 번째 링크는 RESET 이벤트에 의해 트리거되는 CPU 내부의 부트 코드(마이크로코드)입니다(BIOS의 RESET 벡터와 혼동하지 마십시오!). CPU는 SPI 플래시 메모리에서 Intel이 개발하고 서명한 코드 모듈(Intel BG 시작 ACM)을 찾아 캐시에 로드하고 확인합니다(CPU에는 ACM 서명을 확인하는 공개 키 해시가 있음은 위에서 이미 언급했습니다. ) 시작합니다.

이 코드 모듈은 UEFI BIOS의 작은 시작 부분인 IBB(Initial Boot Block)를 확인하는 역할을 하며, 여기에는 UEFI BIOS의 주요 부분을 확인하는 기능이 포함되어 있습니다. 따라서 Intel BG를 사용하면 OS를 부팅하기 전에 BIOS의 신뢰성을 확인할 수 있습니다(Secure Boot 기술의 감독하에 수행 가능).

인텔 BG 기술은 두 가지 작동 모드를 제공합니다(그리고 하나는 다른 하나를 방해하지 않습니다. 즉, 시스템에서 두 모드를 모두 활성화할 수 있고 둘 다 비활성화할 수 있습니다).

신중한 부팅

계획 부팅(MB) 모드에서 각 부팅 구성 요소(CPU 부팅 ROM으로 시작)는 TPM(신뢰할 수 있는 플랫폼 모듈)의 기능을 사용하여 다음 구성 요소를 "측정"합니다. 모르시는 분들을 위해 설명드리겠습니다.

TPM에는 다음 공식에 따라 해싱 작업의 결과를 기록하는 PCR(플랫폼 구성 레지스터)이 있습니다.

저것들. 현재 PCR 값은 이전 값에 따라 다르며 이러한 레지스터는 시스템이 RESET일 때만 재설정됩니다.

따라서 MB 모드에서 특정 시점에서 PCR은 "측정"된 코드 또는 데이터의 고유한(해시 작업 기능 내) 식별자를 반영합니다. PCR 값은 일부 데이터의 암호화(TPM_Seal) 작업에 사용할 수 있습니다. 그 후, 그들의 해독(TPM_Unseal)은 PCR 값이 로드 결과로 변경되지 않은 경우에만 가능합니다(즉, 단일 "측정된" 구성 요소가 수정되지 않은 경우).

검증된 부팅

UEFI BIOS 수정을 좋아하는 사람들에게 가장 무서운 것은 각 부팅 구성 요소가 다음 구성 요소의 무결성과 신뢰성을 암호로 확인하는 검증 부팅(VB) 모드입니다. 그리고 검증 오류의 경우(다음 중 하나)가 발생합니다.

• 1분에서 30분까지 시간 초과로 종료(사용자가 자신의 컴퓨터가 부팅되지 않는 이유를 이해할 시간이 있고 가능한 경우 BIOS 복원을 시도할 수 있도록)
• 즉각적인 종료 (사용자가 이해할 시간이 없도록)
• 똑바른 얼굴로 작업 계속(더 중요한 일이 있어 안전할 시간이 없는 경우).

작업 선택은 컴퓨터 플랫폼 공급업체가 특수 설계된 스토리지 칩셋 퓨즈(FPF)에 영구적으로 기록하는 지정된 인텔 BG 구성(즉, 소위 시행 정책)에 따라 다릅니다. 이 점에 대해서는 나중에 자세히 설명하겠습니다.

구성 외에도 공급업체는 두 개의 RSA 2048 키를 생성하고 두 개의 데이터 구조를 생성합니다(그림 참조).

1. 이 매니페스트의 SVN(보안 버전 번호), 다음 매니페스트 공개 키의 SHA256 해시, RSA 공개 키(즉, 공급업체 루트 키) 이 매니페스트의 서명과 서명 자체를 확인합니다.
2. IBB 매니페스트(IBBM, Initial Boot Block Manifest)는 이 매니페스트의 SVN, IBB의 SHA256 해시, 이 매니페스트의 서명을 확인하기 위한 공개 키 및 서명 자체를 넣습니다.

OEM 루트 키의 SHA256 해시는 인텔 BG 구성과 마찬가지로 칩셋 퓨즈(FPF)에 영구적으로 기록됩니다. 인텔 BG 구성이 이 기술의 포함을 제공하는 경우 지금부터 이 시스템에서 OEM 루트 키의 개인 부분 소유자만 BIOS를 업데이트할 수 있습니다(즉, 이러한 매니페스트를 다시 계산할 수 있음). 공급업체.

사진을 보면 이렇게 긴 확인 체인이 필요하다는 의심이 즉시 떠오릅니다. 하나의 매니페스트를 사용할 수도 있었습니다. 왜 복잡합니까?

실제로 Intel은 벤더에게 다양한 제품 라인에 대해 서로 다른 IBB 키를 사용하고 하나를 루트로 사용할 수 있는 기회를 제공합니다. IBB 키의 개인 부분(두 번째 매니페스트에 서명)이 유출되면 사고는 공급업체가 새 쌍을 생성하고 다음 BIOS 업데이트에서 재계산된 매니페스트를 활성화할 때까지 한 제품 라인에만 영향을 미칩니다.

그러나 루트 키가 손상된 경우(첫 번째 매니페스트가 서명된 경우) 이를 대체할 수 없으며 해지 절차가 제공되지 않습니다. 이 키의 공개 부분 해시는 FPF에 단번에 프로그래밍됩니다.

인텔 부트 가드 구성

이제 Intel BG 구성과 생성 프로세스를 자세히 살펴보겠습니다. Intel STK(System Tool Kit)의 Flash Image Tool GUI에서 해당 탭을 보면 Intel BG 구성에 벤더 루트 키의 공개 부분 해시가 포함되어 있음을 알 수 있습니다. 값 등이 있습니다. 인텔 BG 프로필.

이 프로필의 구조:

typedef struct BG_PROFILE
{
	unsigned long Force_Boot_Guard_ACM : 1;
	unsigned long Verified_Boot : 1;
	unsigned long Measured_Boot : 1;
	unsigned long Protect_BIOS_Environment : 1;
	unsigned long Enforcement_Policy : 2; // 00b – do nothing
                                              // 01b – shutdown with timeout
                                              // 11b – immediate shutdown
	unsigned long : 26;
};

일반적으로 인텔 BG 구성은 매우 유연한 엔터티입니다. 예를 들어 Force_Boot_Guard_ACM 플래그를 고려하십시오. 지워진 경우 SPI 플래시에서 BG 시작 ACM 모듈을 찾을 수 없으면 신뢰할 수 있는 부팅이 발생하지 않습니다. 그것은 신뢰할 수 없을 것입니다.

확인에 실패하면 다시 신뢰할 수 없는 다운로드가 발생하도록 VB 모드에 대한 시행 정책을 구성할 수 있다고 위에서 이미 썼습니다.

이런건 판매자에게 맡기고...

유틸리티의 GUI는 다음과 같은 "준비된" 프로파일을 제공합니다.

아니오.
제도
기술

0
No_FVME
인텔 BG 기술 비활성화됨

1
VE
VB 모드 활성화, 시간 초과로 종료

2
VME
두 모드 모두 활성화(VB 및 MB), 시간 초과로 종료

3
VM
시스템을 끄지 않고 두 모드가 모두 활성화됩니다.

4
FVE
VB 모드 활성화, 즉시 종료

5
FVME
두 모드 활성화, 즉시 종료

이미 언급한 바와 같이 인텔 BG 구성은 시스템 공급업체가 칩셋 퓨즈(FPF)에 한 번만 작성해야 합니다. 칩셋 퓨즈(FPF)는 외부에서 프로그래밍할 수 있는 칩셋 내부의 작은(확인되지 ​​않은 정보에 따르면 256바이트에 불과함) 하드웨어 정보 저장소입니다. 인텔의 생산 시설(그래서 필드 프로그래밍 가능 퓨즈).

다음과 같은 이유로 구성을 저장하는 데 유용합니다.

• 일회성 프로그래밍 가능 데이터 저장 영역(인텔 BG 구성이 작성된 위치)이 있습니다.
• Intel ME만 읽고 프로그래밍할 수 있습니다.

따라서 특정 시스템에서 인텔 BG 기술에 대한 구성을 설정하기 위해 공급업체는 생산 중에 다음을 수행합니다.

1. 플래시 이미지 도구(Intel STK에서 제공)를 사용하여 Intel ME 영역(소위 FPF용 임시 미러) 내 변수로 지정된 Intel BG 구성을 사용하여 펌웨어 이미지를 생성합니다.
2. 플래시 프로그래밍 도구(Intel STK의)를 사용하여 이 이미지를 시스템의 SPI 플래시 메모리에 쓰고 소위 닫습니다. 제조 모드(이 경우 해당 명령이 Intel ME로 전송됨).

이러한 작업의 결과로 Intel ME는 ME 영역의 FPF에 대한 미러에서 주어진 값을 FPF에 커밋하고 SPI 플래시 디스크립터의 권한을 Intel에서 권장하는 값으로 설정합니다(처음에 설명됨). 기사) 시스템 RESET을 수행합니다.

인텔 부트 가드 구현 분석

특정 예에서 이 기술의 구현을 분석하기 위해 다음 시스템에서 Intel BG 기술의 흔적을 확인했습니다.

체계
주의

기가 바이트 GA-H170-D3H
Skylake, 지원이 있습니다

기가바이트 GA-Q170-D3H
Skylake, 지원이 있습니다

기가바이트 GA-B150-HD3
Skylake, 지원이 있습니다

MSI H170A 게이밍 프로
스카이레이크, 지원 안함

Lenovo ThinkPad 460
Skylake, 지원 가능, 기술 지원

레노버 요가 2 프로
하스웰, 지원하지 않음

레노버 U330p
하스웰, 지원하지 않음

"지원"은 인텔 BG 시작 ACM 모듈, 위에 언급된 매니페스트 및 BIOS의 해당 코드, 즉 분석을 위한 구현.

예를 들어 사무실에서 다운로드한 것을 살펴보겠습니다. Gigabyte GA-H170-D3H(버전 F4)용 SPI 플래시 메모리의 공급업체 사이트 이미지.

인텔 CPU 부팅 ROM

먼저 Intel BG 기술이 활성화된 경우 프로세서의 동작에 대해 이야기해 보겠습니다.

해독된 마이크로코드의 샘플을 찾을 수 없었기 때문에 아래에 설명된 조치가 어떻게 구현되는지(마이크로코드 또는 하드웨어에서) 공개 질문입니다. 그럼에도 불구하고 최신 Intel 프로세서가 이러한 작업을 "수행"할 수 있다는 사실은 사실입니다.

RESET 상태를 종료한 후 프로세서(플래시 메모리의 내용이 이미 매핑된 주소 공간)는 FIT(펌웨어 인터페이스 테이블)를 찾습니다. 쉽게 찾을 수 있으며 포인터는 FFFF FFC0h 주소에 기록됩니다.

이 예에서 이 주소에는 값 FFD6 9500h가 포함되어 있습니다. 이 주소로 전환하면 프로세서는 내용이 레코드로 구분되는 FIT 테이블을 봅니다. 첫 번째 항목은 다음 구조의 제목입니다.

typedef struct FIT_HEADER
{
	char           Tag[8];     // ‘_FIT_   ’
	unsigned long  NumEntries; // including FIT header entry
	unsigned short Version;    // 1.0
	unsigned char  EntryType;  // 0
	unsigned char  Checksum;
};

몇 가지 알 수 없는 이유로 이러한 테이블에서 체크섬이 항상 계산되지는 않습니다(필드는 null로 남음).

나머지 항목은 BIOS가 실행되기 전에 구문 분석/실행되어야 하는 다양한 바이너리를 가리킵니다. 레거시 RESET 벡터(FFFF FFF0h)로 전환하기 전. 이러한 각 항목의 구조는 다음과 같습니다.

typedef struct FIT_ENTRY
{
	unsigned long  BaseAddress;
	unsigned long  : 32;
	unsigned long  Size;
	unsigned short Version;     // 1.0
	unsigned char  EntryType;
	unsigned char  Checksum;
};

EntryType 필드는 이 항목이 가리키는 블록 유형을 나타냅니다. 우리는 몇 가지 유형을 알고 있습니다.

enum FIT_ENTRY_TYPES
{
	FIT_HEADER = 0,
	MICROCODE_UPDATE,
	BG_ACM,
	BIOS_INIT = 7,
	TPM_POLICY,
	BIOS_POLICY,
	TXT_POLICY,
	BG_KEYM,
	BG_IBBM
};

이제 항목 중 하나가 Intel BG 시작 ACM 바이너리의 위치를 ​​가리키는 것이 분명합니다. 이 바이너리의 헤더 구조는 인텔에서 개발한 코드 모듈(ACM, 마이크로코드 업데이트, 인텔 ME 코드 섹션 등)에 일반적입니다.

typedef struct BG_ACM_HEADER
{
	unsigned short ModuleType;     // 2
	unsigned short ModuleSubType;  // 3
	unsigned long  HeaderLength;   // in dwords
	unsigned long  : 32;
	unsigned long  : 32;
	unsigned long  ModuleVendor;   // 8086h
	unsigned long  Date;           // in BCD format
	unsigned long  TotalSize;      // in dwords
	unsigned long  unknown1[6];
	unsigned long  EntryPoint;
	unsigned long  unknown2[16];
	unsigned long  RsaKeySize;     // in dwords
	unsigned long  ScratchSize;    // in dwords
	unsigned char  RsaPubMod[256];
	unsigned long  RsaPubExp;
	unsigned char  RsaSig[256];
};

프로세서는 이 바이너리를 캐시에 로드하고 확인하고 실행합니다.

인텔 BG 스타트업 ACM

이 ACM의 작업을 분석한 결과 다음과 같은 작업을 수행한다는 것이 분명해졌습니다.

• 인텔 ME에서 칩셋 퓨즈(FPF)에 기록된 인텔 BG 구성을 수신합니다.
• KEYM 및 IBBM 매니페스트를 찾아 확인합니다.

이러한 매니페스트를 찾기 위해 ACM은 이러한 구조를 가리키는 두 가지 유형의 항목이 있는 FIT 테이블도 사용합니다(위의 FIT_ENTRY_TYPES 참조).

선언문을 자세히 살펴보겠습니다. 첫 번째 매니페스트의 구조에는 몇 가지 모호한 상수, 두 번째 매니페스트의 공개 키 해시 및 중첩된 구조로 서명된 공개 OEM 루트 키가 표시됩니다.

typedef struct KEY_MANIFEST
{
	char           Tag[8];          // ‘__KEYM__’
	unsigned char  : 8;             // 10h
	unsigned char  : 8;             // 10h
	unsigned char  : 8;             // 0
	unsigned char  : 8;             // 1
	unsigned short : 16;            // 0Bh
	unsigned short : 16;            // 20h == hash size?
	unsigned char  IbbmKeyHash[32]; // SHA256 of an IBBM public key
	BG_RSA_ENTRY   OemRootKey;
};

typedef struct BG_RSA_ENTRY
{
	unsigned char  : 8;             // 10h
	unsigned short : 16;            // 1
	unsigned char  : 8;             // 10h
	unsigned short RsaPubKeySize;   // 800h
	unsigned long  RsaPubExp;
	unsigned char  RsaPubKey[256];
	unsigned short : 16;            // 14
	unsigned char  : 8;             // 10h
	unsigned short RsaSigSize;      // 800h
	unsigned short : 16;            // 0Bh
	unsigned char  RsaSig[256];
};

OEM 루트 키의 공개 키를 확인하기 위해 현재 Intel ME에서 이미 수신한 퓨즈의 SHA256 해시가 사용되었음을 기억합니다.

두 번째 선언문으로 넘어 갑시다. 세 가지 구조로 구성됩니다.

typedef struct IBB_MANIFEST
{
	ACBP Acbp;         // Boot policies
	IBBS Ibbs;         // IBB description
	IBB_DESCRIPTORS[];
	PMSG Pmsg;         // IBBM signature
};

첫 번째는 몇 가지 상수를 포함합니다.

typedef struct ACBP
{
	char           Tag[8];          // ‘__ACBP__’
	unsigned char  : 8;             // 10h
	unsigned char  : 8;             // 1
	unsigned char  : 8;             // 10h
	unsigned char  : 8;             // 0
	unsigned short : 16;            // x & F0h = 0
	unsigned short : 16;            // 0 < x <= 400h
};

두 번째는 IBB의 SHA256 해시와 IBB의 내용(즉, 해시가 계산되는 대상)을 설명하는 설명자의 수를 포함합니다.

typedef struct IBBS
{
	char           Tag[8];            // ‘__IBBS__’
	unsigned char  : 8;               // 10h
	unsigned char  : 8;               // 0
	unsigned char  : 8;               // 0
	unsigned char  : 8;               // x <= 0Fh
	unsigned long  : 32;              // x & FFFFFFF8h = 0
	unsigned long  Unknown[20];
	unsigned short : 16;              // 0Bh
	unsigned short : 16;              // 20h == hash size ?
	unsigned char  IbbHash[32];       // SHA256 of an IBB
	unsigned char  NumIbbDescriptors;
};

IBB 디스크립터는 차례로 이 구조를 따릅니다. 콘텐츠의 형식은 다음과 같습니다.

typedef struct IBB_DESCRIPTOR
{
	unsigned long  : 32;
	unsigned long  BaseAddress;
	unsigned long  Size;
};

간단합니다. 각 설명자는 IBB 청크의 주소/크기를 포함합니다. 따라서 이러한 디스크립터가 가리키는 블록의 연결(디스크립터 자체 순서대로)은 IBB입니다. 그리고 일반적으로 IBB는 SEC 및 PEI 단계의 모든 모듈 조합입니다.

두 번째 매니페스트는 IBB 공개 키(첫 번째 매니페스트의 SHA256 해시로 확인됨)와 이 매니페스트의 서명을 포함하는 구조로 끝납니다.

typedef struct PMSG
{
	char           Tag[8];            // ‘__PMSG__’
	unsigned char  : 8;               // 10h
	BG_RSA_ENTRY   IbbKey;
};

따라서 UEFI BIOS 실행이 시작되기 전에도 프로세서는 ACM을 시작하여 SEC 및 PEI 단계 코드가 있는 섹션 내용의 진위를 확인합니다. 다음으로 프로세서는 ACM을 종료하고 RESET 벡터를 따라 이동하며 BIOS 실행을 시작합니다.

PEI 확인 파티션에는 나머지 BIOS(DXE 코드)를 검사할 모듈이 포함되어 있어야 합니다. 이 모듈은 IBV(Independent BIOS Vendor) 또는 시스템 공급업체 자체에서 이미 개발 중입니다. 왜냐하면 Lenovo 및 Gigabyte 시스템만 우리가 사용할 수 있고 Intel BG를 지원하는 것으로 밝혀졌습니다. 이러한 시스템에서 추출된 코드를 고려해 보겠습니다.

UEFI BIOS 모듈 LenovoVerifiedBootPei

레노버의 경우 레노버에서 개발한 LenovoVerifiedBootPei {B9F2AC77-54C7-4075-B42E-C36325A9468D} 모듈로 밝혀졌다.

작업은 DXE의 해시 테이블을 GUID로 조회하고 DXE를 확인하는 것입니다.

if (EFI_PEI_SERVICES->GetBootMode() != BOOT_ON_S3_RESUME)
{
	if (!FindHashTable())
		return EFI_NOT_FOUND;
	if (!VerifyDxe())
		return EFI_SECURITY_VIOLATION;
}

Хеш таблица {389CC6F2-1EA8-467B-AB8A-78E769AE2A15} имеет следующий формат:

typedef struct HASH_TABLE
{
	char          Tag[8];            // ‘$HASHTBL’
	unsigned long NumDxeDescriptors;
	DXE_DESCRIPTORS[];
};

typedef struct DXE_DESCRIPTOR
{
	unsigned char BlockHash[32];     // SHA256
	unsigned long Offset;
	unsigned long Size;
};

UEFI BIOS 모듈 BootGuardPei

Gigabyte의 경우 AMI에서 개발한 BootGuardPei {B41956E1-7CA2-42DB-9562-168389F0F066} 모듈로 밝혀졌으므로 Intel BG를 지원하는 모든 AMI BIOS에 존재합니다.

작동 알고리즘은 다소 다르지만 결국에는 동일합니다.

int bootMode = EFI_PEI_SERVICES->GetBootMode();

if (bootMode != BOOT_ON_S3_RESUME &&
    bootMode != BOOT_ON_FLASH_UPDATE &&
    bootMode != BOOT_IN_RECOVERY_MODE)
{
	HOB* h = CreateHob();
	if (!FindHashTable())
		return EFI_NOT_FOUND;
	WriteHob(&h, VerifyDxe());
	return h;
}

조회하는 해시 테이블 {389CC6F2-1EA8-467B-AB8A-78E769AE2A15}의 형식은 다음과 같습니다.

typedef HASH_TABLE DXE_DESCRIPTORS[];

typedef struct DXE_DESCRIPTOR
{
	unsigned char BlockHash[32];     // SHA256
	unsigned long BaseAddress;
	unsigned long Size;
};

인텔 부트 가드 2.x

Apollo Lake 마이크로아키텍처가 포함된 Intel SoC 기반 최신 시스템인 ASRock J4205-IT에서 발견된 Intel Boot Guard의 또 다른 구현에 대해 간단히 이야기해 보겠습니다.

이 버전은 SoC에서만 사용되지만(Kaby Lake 프로세서 마이크로아키텍처가 있는 새로운 시스템은 Intel Boot Guard 1.x를 계속 사용함) Intel SoC를 기반으로 하는 플랫폼을 위한 새로운 아키텍처 옵션을 탐색하는 데 큰 관심이 있습니다. 예를 들면 다음과 같습니다.

• BIOS 및 Intel ME 영역(또는 Intel SoC 용어에 따르면 Intel TXE)은 이제 하나의 IFWI 영역입니다.
• 인텔 BG가 플랫폼에서 활성화되었지만 FIT, KEYM, IBBM과 같은 구조는 플래시 메모리에서 발견되지 않았습니다.
• TXE 및 ISH 코어(x86) 외에도 전원 하위 시스템의 작동 가능성 및 성능 모니터링과 관련된 세 번째 코어(다시 ARC)가 칩셋인 PMC(Power Management Controller)에 추가되었습니다.

새로운 IFWI 영역의 내용은 다음 모듈 세트입니다.

편견
이름
기술

0000 2000h
SMIP
벤더가 서명한 일부 플랫폼 구성

0000 6000h
RBEP
인텔에서 서명한 인텔 TXE 펌웨어 코드 섹션, x86

0001 0000h
PMCP
펌웨어 코드 섹션 인텔 PMC, ARC, 인텔 서명

0002 0000h
FTPR
인텔에서 서명한 인텔 TXE 펌웨어 코드 섹션, x86

0007B000h
유코드
Intel이 서명한 CPU 마이크로코드 업데이트

0008 0000h
IBBP
UEFI BIOS, SEC/PEI 단계, x86, 공급업체 서명

0021 8000h
ISHC
공급업체가 서명한 인텔 ISH 펌웨어 x86의 코드 섹션

0025 8000h
FTP
인텔에서 서명한 인텔 TXE 펌웨어 코드 섹션, x86

0036 1000h
IUNP
알 수없는

0038 1000h
OBBP
UEFI BIOS, DXE 단계, x86, 서명되지 않음

TXE 펌웨어를 분석하는 동안 RESET 후 TXE가 CPU 주소 공간의 기본 내용(FIT, ACM, RESET 벡터 ...)을 준비할 때까지 프로세서를 이 상태로 유지한다는 것이 분명해졌습니다. 또한 TXE는 이 데이터를 SRAM에 저장한 후 일시적으로 프로세서에 액세스 권한을 제공하고 RESET에서 "해제"합니다.

루트킷 보호

자, 이제 "뜨거운"으로 넘어 갑시다. 우리는 한때 많은 시스템에서 SPI 플래시 디스크립터가 SPI 플래시 메모리의 영역에 액세스할 수 있는 권한을 가지고 있어 이 메모리의 모든 사용자가 모든 영역을 읽고 쓸 수 있음을 발견했습니다. 저것들. 안 돼요.

MEinfo 유틸리티(Intel STK에서 제공)로 확인한 후 이러한 시스템의 제조 모드가 닫히지 않았으므로 칩셋 퓨즈(FPF)가 불확실한 상태로 남아 있음을 확인했습니다. 예, 이러한 경우 인텔 BG는 활성화되거나 비활성화되지 않습니다.

우리는 다음 시스템에 대해 이야기하고 있습니다(Intel BG 및 이 기사의 뒷부분에서 설명할 내용과 관련하여 Haswell 프로세서 마이크로아키텍처 이상이 있는 시스템에 대해 이야기할 것입니다).

• 모든 기가바이트 제품
• 모든 MSI 제품;
• 21개의 Lenovo 노트북 모델 및 4개의 Lenovo 서버 모델.

물론 인텔은 물론 이러한 공급업체에도 발견 사실을 보고했습니다.

다음에서만 적절한 응답 레노버문제를 인정한 사람과 패치를 발표했다.

기가 바이트 그들은 취약점에 대한 정보를 받아들인 것으로 보이지만 어떠한 방식으로도 언급하지 않았습니다.

통신 MSI (암호화 된 보안 권고를 보내기 위해) 공개 PGP 키를 보내 달라는 요청에 따라 완전히 중단되었습니다. 그들은 "하드웨어 제조업체이며 PGP 키를 제조하지 않습니다."라고 말했습니다.

그러나 더 중요한 점입니다. 퓨즈는 정의되지 않은 상태로 남아 있기 때문에 사용자(또는 공격자)가 직접 프로그래밍할 수 있습니다(가장 어려운 것은 인텔 STK 찾기). 이를 위해서는 다음 단계가 필요합니다.

1. Windows OS로 부팅합니다(원하는 OS에 대한 Intel STK의 아날로그를 개발하는 경우 일반적으로 아래 설명된 단계는 Linux에서도 수행할 수 있음). MEinfo 유틸리티를 사용하여 이 시스템의 퓨즈가 프로그래밍되지 않았는지 확인하십시오.

2. 플래시 프로그래밍 도구를 사용하여 플래시 메모리의 내용을 읽으십시오.

3. UEFI BIOS 편집 도구를 사용하여 읽기 이미지를 열고 필요한 변경을 수행하고(예: 루트킷 구현) ME 영역에서 기존 KEYM 및 IBBM 구조를 생성/편집합니다.

RSA 키의 공개 부분은 그림에서 강조 표시되어 있으며 해시는 인텔 BG 구성의 나머지 부분과 함께 칩셋 퓨즈에 프로그래밍됩니다.

4. Flash Image Tool을 사용하여 새 펌웨어 이미지를 빌드합니다(인텔 BG 구성 설정).

5. 플래시 프로그래밍 도구를 사용하여 플래시에 새 이미지를 작성하고, ME 영역에 이제 Intel BG 구성이 포함되어 있는지 MEinfo를 사용하여 확인하십시오.

6. Flash 프로그래밍 도구를 사용하여 제조 모드를 닫습니다.

7. 시스템이 재부팅된 후 MEinfo를 사용하여 이제 FPF가 프로그래밍되었는지 확인할 수 있습니다.

이러한 조치 영원히 이 시스템에서 인텔 BG를 활성화합니다. 작업을 실행 취소하는 것은 불가능합니다. 즉, 다음을 의미합니다.

• 루트 키의 개인 부분 소유자(즉, 인텔 BG를 활성화한 소유자)만 이 시스템에서 UEFI BIOS를 업데이트할 수 있습니다.
• 예를 들어 프로그래머를 사용하여 원래 펌웨어를 이 시스템으로 반환하면 켜지지도 않습니다(확인 오류 발생 시 시행 정책의 결과).
• 이러한 UEFI BIOS를 제거하려면 프로그래밍된 FPF가 있는 칩셋을 "깨끗한" 것으로 교체해야 합니다(예: 자동차 가격으로 적외선 납땜 스테이션에 액세스할 수 있는 경우 칩셋을 다시 납땜하거나 마더보드만 교체). ).

그러한 루트킷이 무엇을 할 수 있는지 이해하려면 UEFI BIOS 환경에서 코드를 실행할 수 있도록 만드는 것이 무엇인지 평가해야 합니다. 프로세서의 가장 특권적인 모드 인 SMM에서 말하십시오. 이러한 루트킷은 다음 속성을 가질 수 있습니다.

• OS와 병렬로 실행됩니다(타이머에 의해 트리거되는 SMI 인터럽트를 생성하여 처리를 구성할 수 있음).
• SMM 모드에 있는 모든 이점이 있습니다(RAM 및 하드웨어 리소스의 내용에 대한 전체 액세스, OS의 비밀성).
• 루트킷 코드는 SMM 모드에서 실행될 때 암호화 및 해독될 수 있습니다. SMM 모드에서만 사용할 수 있는 모든 데이터를 암호화 키로 사용할 수 있습니다. 예를 들어 SMRAM에 있는 주소 집합의 해시입니다. 이 키를 얻으려면 SMM으로 올라가야 합니다. 그리고 이것은 두 가지 방법으로 수행될 수 있습니다. SMM 코드에서 RCE를 찾아 악용하거나 자체 SMM 모듈을 BIOS에 추가합니다. 이는 Boot Guard를 활성화했기 때문에 불가능합니다.

따라서 이 취약점으로 인해 공격자는 다음을 수행할 수 있습니다.

• 시스템에서 알려지지 않은 목적의 숨겨진 제거 불가능한 루트킷을 생성합니다.
• Intel SoC 내부의 칩셋 코어 중 하나, 즉 Intel ISH에서 코드를 실행합니다(그림 자세히 보기).

Intel ISH 하위 시스템의 기능은 아직 탐색되지 않았지만 Intel ME에 대한 흥미로운 공격 벡터인 것 같습니다.

조사 결과

1. 이 연구는 Intel Boot Guard 기술의 작동 방식에 대한 기술적 설명을 제공했습니다. 모호성 모델을 통한 인텔 보안의 몇 가지 비밀을 뺀 것입니다.
2. 시스템에서 제거할 수 없는 루트킷을 만들 수 있는 공격 시나리오가 제공됩니다.
3. 우리는 최신 Intel 프로세서가 BIOS가 시작되기 전에도 많은 독점 코드를 실행할 수 있음을 확인했습니다.
4. Intel 64 아키텍처를 사용하는 플랫폼은 하드웨어 검증, 점점 더 많은 독점 기술 및 하위 시스템(SoC 칩셋의 86개 코어: x86 ME, xXNUMX ISH 및 ARC PMC)과 같은 자유 소프트웨어를 실행하는 데 점점 더 적합하지 않게 되고 있습니다.

완화

의도적으로 제조 모드를 열어 두는 벤더는 반드시 닫아야 합니다. 지금까지 그들은 단지 눈을 감았을 뿐이며 새로운 Kaby Lake 시스템이 이를 보여줍니다.

사용자는 -closemnf 옵션과 함께 플래시 프로그래밍 도구를 실행하여 시스템에서 인텔 BG(설명된 취약점의 영향을 받음)를 비활성화할 수 있습니다. 먼저 ME 영역의 Intel BG 구성이 FPF에서 프로그래밍한 후 이 기술을 정확히 끄도록 제공하는지 확인해야 합니다(MEinfo 사용).

출처 : habr.com