CVE-2020-11519 및 CVE-2020-11520에 대한 기술적 보고서

날짜: 2020년 6월

작성자: Dennis Elser (코드: github)

소개

웹 표현(web representation)에 따르면, Winmagic SecureDoc는 "비즈니스가 IT 환경의 보안을 효율적으로 처리할 수 있도록 하는 기능을 제공합니다: 전체 디스크 암호화(FDE), 다중 요소 인증, 이동식 미디어 컨테이너 암호화(RMCE), 파일 및 폴더 암호화(FFE) 등이 있습니다. 이러한 기능은 비즈니스의 보안을 강화하고, 비즈니스 리스크를 완화하며, 하드 드라이브 암호화에 대한 정부 및 규제 요구 사항을 충족하는 데 도움이 됩니다."

Winmagic SecureDoc 제품은 독립형 및 엔터프라이즈 에디션으로 제공되며, 버전 8.3 및 8.5에서 두 가지 로컬 권한 상승 취약점(CVE-2020-11519 및 CVE-2020-11520)의 영향을 받습니다. 취약점이 3월 말에 Winmagic에 보고된 후, 공급업체는 2020년 6월 중순(공개 타임라인)에 패치(버전 8.5SR2)를 출시했습니다. 그러나 이 패치는 취약점을 불충분하게 해결한 것으로 밝혀져 버전 8.5SR2도 보고된 결함에 취약하게 만들었습니다. 이러한 이유로 취약점에 대한 기술적 세부 정보는 보류되었지만, 그 이후로 결함은 공개된 것으로 간주됩니다. ~~공급업체에 따르면, Winmagic에 대한 초기 취약점 보고 후 약 106일이 지난 시점에서 또 다른 패치가 준비 중입니다.~~ 7월 15일, 공급업체에 대한 초기 취약점 보고 후 111일째 되는 날, Winmagic은 SecureDoc v8.5 SR2 HF1을 고객에게 출시했으며, 이는 CVE-2020-11519 및 CVE-2020-11520을 수정한다고 합니다. 8.3 이전 버전의 SecureDoc은 테스트되지 않았지만 영향을 받는 구성 요소의 코드에 기반하여 영향을 받을 것으로 추정됩니다.

이러한 취약점 중 하나라도 성공적으로 악용되면 로컬로 인증된 공격자가 SYSTEM 권한으로 상승할 수 있습니다.

접근 방식 및 기술 설명

두 취약점 모두 Winmagic SecureDoc 제품에 포함된 커널 드라이버인 "SDDisk2k.sys" 구성 요소에 영향을 미칩니다. 보안 결함은 Hex-Rays IDA Pro 디스어셈블러 및 디컴파일러를 사용한 수동 정적 분석을 통해 식별되었습니다. 돌이켜보면, 퍼징과 같은 동적 테스트 접근 방식을 대신 적용했다면 훨씬 적은 노력으로 약점을 발견할 수 있었을 것입니다. 그 이유는 드라이버가 제한된 사용자 모드 애플리케이션에서 인터페이스할 수 있고, 기본적으로 입력이 올바르게 구성되어 있다고 가정하기 때문입니다.

CVE-2020-11519

"SDDisk2k.sys" 드라이버가 "SecureDocDevice" 장치 개체를 안전하지 않게 생성하고 적절한 보안 설명자를 설정하는 코드가 누락되어, 제한된 사용자 계정도 CreateFile() API 함수를 사용하여 장치에 대한 핸들을 얻을 수 있습니다. 드라이버가 사용자 모드 애플리케이션에 장치 개체에 대한 핸들을 부여함으로써, 커널 영역에서 공격 표면으로의 직접적인 경로가 열리게 됩니다.``` c RtlInitUnicodeString(&DestinationString, L"\Device\SecureDocDevice"); RtlInitUnicodeString(&SymbolicLinkName, L"\DosDevices\SecureDocDevice"); if ( IoCreateDevice(v1, 0xDD8u, &DestinationString, 0x8D1Fu, 0, 0, &DeviceObject) >= 0 ) // <--- unsafe { memset(DeviceObject->DeviceExtension, 0, 0xDD8ui64); DeviceObject->Flags |= 4u; DeviceObject->AlignmentRequirement = 0; if ( IoCreateSymbolicLink(&SymbolicLinkName, &DestinationString) < 0 ) IoDeleteDevice(DeviceObject); IoObject = DeviceObject; }

"SDDisk2k.sys" 드라이버의 여러 [IOCTL](https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/introduction-to-i-o-control-codes) 서비스 핸들러를 리버스 엔지니어링한 결과, 그중 하나가 의도적으로 임의 드라이브의 원시 디스크 섹터에 대한 읽기 및 쓰기 작업을 허용하는 중요한 기능을 사용자 모드에 노출한다는 사실이 발견되었습니다. 여기에 더해, 이 코드와 인터페이스할 때 드라이버가 이전에 드라이브에 설정되었을 수 있는 배타적 잠금을 무시한다는 것이 확인되었습니다. 결과적으로 동시 읽기/쓰기 작업이 가능해져 경쟁 조건이 발생하고 데이터 손실 위험이 커집니다.

다음은 원시 디스크 섹터의 읽기 요청을 처리하는 드라이버의 디컴파일된 IOCTL 서비스 핸들러를 보여줍니다. 이 핸들러는 "controlled_buf"라는 인수를 사용하여 함수 sub_29CD4()를 호출합니다. 여기서 "controlled_buf"는 호출하는 사용자 모드 애플리케이션이 임의로 내용을 선택할 수 있는 버퍼에 대한 포인터입니다.``` c
if ( ioctlcode == 0x8D1F2824 )   // <--- I/O control code for raw disk reading functionality
{
  controlled_buf = (unsigned __int8 *)controlled_addr;
  mode = 0;
  temp_result = sub_29CD4((char *)controlled_buf, v3, mode);   // <--- call to raw disk read function

사실, 이 공격자가 제어하는 버퍼는 "offset", "length", "ptr_buf" 필드가 온전히 검사되지 않은 함수 인수로서 IoBuildSynchronousFsdRequest() 호출에 전달되는 구조체입니다. 후자 함수는 IofCallDriver() 호출을 사용하여 기본 파일 시스템 드라이버로 전송하는 IRP_MJ_READ I/O 요청 패킷 (IRP)을 준비합니다:``` c __int64 __fastcall sub_29CD4(char *controlled_addr, PIRP a2, char mode) { //[...snip...] // extract drive number and type (floppy/hd) from offset 0 devicetype_and_num = (unsigned __int8)*controlled_buf // <--- controllable from user mode

// advance pointer p = controlled_buf + 1;

// build device name if ( (devicetype_and_num & 0x80u) == 0 ) v11 = vsnprintf_wrapper(&device_name, 0x3Fui64, L"\Device\Floppy%d", devicetype_and_num); else v11 = vsnprintf_wrapper(&device_name, 0x3Fui64, L"\Device\Harddisk%d\Partition0", devicetype_and_num & 0x7F); v12 = v11; if ( v11 >= 0 ) { RtlInitUnicodeString(&DestinationString, &device_name);

// get object pointer of drive
if ( IoGetDeviceObjectPointer(&DestinationString, 0x80u, &FileObject, &DeviceObject) >= 0
  || (v12 = sub_2C5D4(&DestinationString, &DeviceObject), v12 >= 0) )
{
  // extract further fields from structure
  offset = *(_QWORD *)(p + 0x4E);                    // <--- where to start reading from
  length = *(_DWORD *)(p + 0x56);                    // <--- number of bytes to read
  ptr_buf = *(void **)(p + 0x5A);                    // <--- ptr to destination buffer
  devobj = DeviceObject;
  StartingOffset.QuadPart = offset << 9;
  KeInitializeEvent(&Event, NotificationEvent, 0);
  
  // build request
  v17 = IoBuildSynchronousFsdRequest(
          (unsigned int)(mode != 0) + IRP_MJ_READ,   // <--- issue read request
          devobj,
          ptr_buf,
          length << 9,
          &StartingOffset,
          &Event,
          &IoStatusBlock);
  v18 = v17;
  if ( v17 )
  {
    v19 = v17->Tail.Overlay.CurrentStackLocation;
    if ( mode )
      v19[0xFFFFFFFF].Flags |= 0x10u;
    ObfReferenceObject(devobj);

    // send request to respective device object (issue read request)
    v12 = IofCallDriver(devobj, v18);

//[...snip...] }

원시 디스크 섹터를 읽는 것과 마찬가지로, 사용자 모드에서 디스크 섹터를 쓰는 것은 IOCTL 핸들러 0x8D1F2820을 호출함으로써 가능해지며, 이는 동일한 데이터 구조를 처리하고 비슷한 방식으로 구현됩니다. 이 드라이버의 프로토콜과 호환된다는 점을 고려하면, 임의의 사용자 모드 애플리케이션이 운영 체제를 완전히 손상시키는 것을 막을 수 있는 것은 없습니다. 보안 부팅 메커니즘으로 보호되지 않는 한, 여기에는 시스템 부팅 프로세스 초기에 실행될 수 있는 소프트웨어(랜섬웨어, 부트킷, 사용자 지정 임플란트 등)의 설치도 포함됩니다.

### CVE-2020-11520
"SDDisk2k.sys" 드라이버의 서비스 핸들러에 대한 추가 조사 결과, 사용자 모드 애플리케이션의 메모리 주소가 사전 검증 없이 처리되는 것으로 나타났습니다. 경우에 따라 이러한 포인터가 접근하는 메모리는 드라이버에 의해 맹목적으로 기록되며, 공격자가 이를 악용하여 커널 쓰기 기본 요소를 생성할 수 있습니다. 모든 쓰기 기본 요소는 데이터를 쓸 **위치**를 직접 제어할 수 있게 해주지만, 불행히도 **어떤** 데이터를 쓸지 직접 제어할 수 있는 요소는 발견되지 않았습니다. [CVE-2020-11519](#cve-2020-11519)의 경우는 예외로, 이 컨텍스트에서 악용하려면 디스크 읽기/쓰기 작업을 통한 추가 우회가 필요하며, 저는 이를 지저분한 접근 방식이라 생각하여 피하고 싶었습니다. 그러나 한 특정 핸들러가 확인되었는데, 이 핸들러는 데이터 자체를 제어할 수는 없었지만 다른 수단을 통해 재사용하기에 충분히 유용한 것으로 드러났습니다.

winmagic_sd

인기

CVE-2020-11519 및 CVE-2020-11520에 대한 기술적 보고서

목차

소개

접근 방식 및 기술 설명

CVE-2020-11519