CVE-2020-0753-and-CVE-2020-0754

CVE-2020-0753, CVE-2020-0754에 대한 분석 및 PoC, 그리고 수정되지 않은 6가지 Windows DOS 취약점

Exploit FileSystem 경쟁 조건 버그 - CVE-2020-0753 및 CVE-2020-0754 분석

지난 Patch Tuesday에서 Windows Error Reporting 서비스의 2가지 권한 상승 버그가 수정되었으며, 이 두 버그는 CVE-2020-0753 및 CVE-2020-0754로 지정되었습니다. 두 버그 모두 서비스의 FileSystem 작업에서 경쟁 조건 버그를 활용합니다. 그러나 작은 경쟁 윈도우와 불확실한 파일 드롭 위치로 인해 이 두 버그를 악용하는 것은 쉽지 않습니다. 여기서는 이를 악용하는 기술을 공유합니다.

두 경쟁 버그의 근본 원인은 보고서에 제공되어 있으며, 실제 원인은 예측 가능함은 취약함이다로 표현할 수 있습니다. WER 서비스가 임시 파일을 처리할 때 C:\ProgramData\Microsoft\Windows\WER\Temp 위치의 파일을 조작하는데, 이 디렉터리는 인증된 사용자에게 읽기/쓰기가 가능합니다. 즉, medium-IL 일반 사용자가 WER 서비스가 생성한 파일을 덮어쓰거나, 이를 FileSystem 링크로 변환하여 원래는 건드릴 수 없었던 다른 파일을 손상/삭제할 수 있습니다.

파일 작업을 안전하게 유지하기 위해 WER 서비스는 GetTempFileNameW라는 표준 API에 의존하며, 이를 wersvc.dll->UtilGetTempFile로 래핑합니다. 이 API는 WerSvc가 "WER****.tmp" 형식의 점유되지 않은 임의 파일 이름을 생성하도록 도와줍니다. 파일 이름의 임의 부분은 4바이트 16진수(0000 ~ FFFF)로 생성되며, 하나의 번호가 파일을 생성하는 데 사용되면 API는 다른 임의의 파일 이름을 선택합니다.

이 전략은 WER0000.tmp부터 WERFFFE.tmp까지 65535개의 파일을 생성하면 분명히 결함이 있습니다. API는 임의의 번호를 선택하고 파일이 존재하는지 확인합니다(예: WERA560.tmp). 파일이 이미 존재하면 WERA560.tmp부터 WERFFFF.tmp까지 계속 테스트합니다. 테스트가 진행되는 동안 준비 윈도우가 나타나는데, WerSvc가 GetTempFileNameW 호출에서 4~5초 동안 멈추도록 만드는 방법을 찾았기 때문입니다. 이는 상당히 큰 타이밍 간격입니다. 그 동안 서비스가 고정된 파일 이름 WERFFFF.tmp로 임시 파일을 드롭하도록 강제합니다.

서비스가 WERFFFF.tmp라는 임시 파일을 생성한 후, API는 자동으로 파일에 대한 핸들을 닫고 파일 이름을 서비스에 반환하여 추가 작업을 수행합니다. 이것이 바로 버그가 발생하는 지점입니다. 세 가지 조건이 충족됩니다:

1. 서비스가 생성한 파일이 일반 사용자가 제어 가능한 위치에 있음.
2. 서비스가 파일에 대한 모든 핸들을 닫음.
3. 서비스가 나중에 파일을 사용함(쓰기 또는 삭제).

여기서 서비스는 파일에 내용을 쓰고 삭제합니다. 쓰기와 삭제 모두 FileSystem 링크와 특정 악용 기술을 활용하여 권한 상승을 유발할 수 있습니다.

버그를 임의 파일 삭제로 전환하기 위해 다중 디렉터리 정션을 창의적으로 활용하여 악용을 완료했습니다. 악용 코드는 다음 단계를 포함합니다:

• 모든 WER***.tmp 파일을 $pwd\1\에 넣고, $pwd\2\ -> $pwd\1\ 정션을 생성합니다.
• 이 함수를 계속 트리거하는 프로세스 하나와 SetOplock $pwd\1\WERFFFF.tmp 명령을 계속 실행하는 다른 프로세스를 생성합니다.
• Oplock이 트리거되면 $pwd\2\ -> \RPC CONTROL\ 정션을 생성하고, \RPC CONTROL\WERFFFF.tmp -> $target 및 \RPC CONTROL\WERFFFF.tmp.etl -> $target 개체 심볼릭을 생성합니다.
• Oplock을 해제하면 대상 파일이 시스템 권한으로 삭제됩니다.

자세한 악용 및 PoC는 WERReport-CVE-2020-0753에 제공되어 있습니다.

GetTempFileNameW의 결함을 악용하여 서비스가 작업할 예측 가능한 위치를 얻었고, 다중 레벨 FileSystem 정션을 사용하여 경쟁 조건을 안정적으로 악용 가능하게 만들었습니다.

동시에 이러한 종류의 경쟁 버그가 파일 덮어쓰기 문제를 일으킬 수 있으며, 특정 상황에서는 권한 상승 버그로 이어질 가능성이 있음을 발견했습니다.

부분 제어가 가능한 임의 파일 손상에서 권한 상승으로

임의 파일 손상(파일 내용의 극히 일부(63바이트 미만)만 제어할 수 있는 경우)이 EoP로 전환될 수 있는 이유를 설명하려면 Windows Defender의 작동 메커니즘에 주목해야 합니다.

Windows Defender에는 악성코드 서명 데이터베이스가 있습니다. 일부 파일에 악성코드 서명이 포함되어 있으면 Defender는 이를 악성코드로 간주하고 삭제합니다. 그러나 이 기능은 추가 공격 표면을 초래합니다. 예를 들어, WCTF2019에서 tokyowesterns의 @icchy가 "Gyotaku The Flag"라는 Windows CTF 챌린지를 설계하여 이 기능을 정보 유출을 위한 오라클로 사용했습니다.

여기서는 Windows Defender의 이 기능을 활용하여, 파일 내용을 부분적으로 제어할 수 있는 임의 파일 손상이 있을 경우 임의 파일 삭제를 수행합니다. 파일에 악성코드 서명을 작성하고 Windows Defender의 기본 검사를 트리거하면 파일이 Defender의 격리 영역으로 이동되며, 일반 사용자(예: medium-IL 비관리자 사용자)가 검사 작업을 두 번 트리거하여 삭제할 수 있습니다.

따라서 임의 파일 손상 버그는 버그를 사용하여 대상 파일에 악성코드 서명 문자열을 넣을 수 있는 한 임의 파일 삭제로 전환될 수 있습니다.

• 단계1:

버그로 대상 파일을 손상시키고 Windows Defender가 인식할 수 있는 특징 문자열을 삽입합니다.

• 단계2:

Windows Defender가 대상 파일을 검사하도록 트리거하여 파일이 격리되도록 합니다.

• 단계3:

검사를 다시 트리거하면 대상 파일이 삭제됩니다.

이 기술을 통해 Defender의 도움을 받아 임의 파일 삭제를 획득합니다.

임의 파일 삭제는 추가 권한을 얻기 위해 훨씬 쉽게 악용될 수 있습니다.

수정되지 않은 6가지 FileSystem DOS 취약점 - Microsoft OneDrive

Microsoft OneDrive는 개인 클라우드 스토리지 서비스를 제공하는 애플리케이션 번들로, Windows 8부터 기본 설치 옵션으로 Windows에 통합되었습니다. 연구 중 OneDrive의 서비스 예약 작업에서 6가지 취약점을 발견하여 MSRC에 제출했습니다.

---

다음은 Microsoft OneDrive 관련 예약 작업에서 공개할 취약점 표입니다:

6가지 버그 모두 서비스가 하드링크와 심볼릭 링크를 부적절하게 처리하여, 일반 사용자가 제어 가능한 위치에서 작업할 때 발생합니다. 이러한 버그를 악용할 때의 어려움 중 하나는 파일 이름에 일반적으로 현재 프로세스의 PID 또는 파일이 작업된 시간의 타임스탬프가 포함된다는 점입니다. 두 문제 모두 서비스가 실행되도록 트리거될 때 로드하려고 시도하는 고유한 DLL 파일에 oplock을 설정하여 해결할 수 있으며, 이를 통해 서비스가 나중에 작업하려는 파일 이름을 예측하는 데 필요한 모든 정보를 얻을 수 있습니다. 예제 PoC는 FileSyncConfigTemp_hardlink 디렉터리에 제공되어 있습니다.

취약점 영향

위에 언급된 6가지 취약점은 모두 완전한 보고서와 PoC 프로그램과 함께 제공됩니다. 대부분의 버그가 처음에는 임의 파일 손상을 일으키지만, 이러한 종류의 버그는 여전히 시스템 충돌(중요 시스템 구성 파일 덮어쓰기)을 유발할 수 있으며, 모두 Windows 재설치가 필요합니다. 따라서 Windows 시스템 서비스 거부(DoS) 버그 유형의 기준을 충족합니다.

또한, 이러한 종류의 버그는 특정 상황에서 실제로 권한 상승을 유발할 수 있습니다. 우리는 임의 파일 덮어쓰기 문제를 활용하여 임의 파일 삭제 프리미티브를 달성하는 악용 기술을 논의했으며, 따라서 권한 상승이 달성 가능합니다.

취약점 크레딧

Fangming Gu

Zhiniang Peng of Qihoo 360 Core Security

타임라인

2월 02 2020: 취약점 보고

2월 08 2020: MSRC가 조사 후 제출한 OneDrive의 6가지 버그에 대해 답변, 너무 많은 사용자 상호작용 필요/신뢰할 수 있는 악용 구축이 너무 어려움이라는 이유로 수정하지 않기로 결정.

2월 08 2020: 답변: 사용자 상호작용이 필요하지 않습니다. 작업 스케줄이 실행되기만 기다리면 됩니다. 따라서 이 시나리오는 일반적입니다.

2월 11 2020: MSRC 답변: 사용자 머신에서 특정 파일을 어떻게 얻습니까? 그리고 해당 폴더에 모든 순열의 파일을 배치합니까? 날짜/시간/PID와 정확히 일치해야 합니까? 이러한 이유로 너무 많은 사용자 노력이 필요한 것으로 보입니다.

2월 11 2020: 답변: PoC는 단순화된 버전입니다. 파일 이름 예측의 노력을 줄이기 위해, 실제로는 oplock만 설정하면 됩니다. 그러면 {pid},{hour},{data}를 모두 얻을 수 있습니다. 따라서 사용자 상호작용이 필요하지 않습니다.

2월 12 2020: 6가지 취약점에 대한 분석을 게시할 수 있는지 문의.

2월 13 2020: MSRC 답변: 분석을 게시해도 좋습니다.

2월 22 2020: 세부 정보 공개

하드링크는 Windows Insider Preview 빌드에서 이미 수정되었지만, 최신 릴리스 버전의 Windows에서는 수정되지 않았습니다. 그리고 모든 지원 OS에 백포트할 계획이 없는 것으로 보입니다 :( . 또한 이러한 취약점을 수정하지 않기로 한 결정은 책임 있는 조치로 보이지 않습니다.