afang5472/cve-2020-0753-and-cve-2020-0754CVE-2020-0753, CVE-2020-0754 및 수정된 6가지 Windows DOS 취약점에 대한 Writeup 및 POC
Windows Error Reporting 서비스는 지난 Patch Tuesday에서 2개의 권한 상승(Elevation of Privilege) 버그를 수정했습니다. 두 버그는 CVE-2020-0753 및 CVE-2020-0754로 지정되었습니다. 두 버그 모두 서비스의 FileSystem 작업에서 경쟁 조건(race condition) 버그를 이용합니다. 그러나 이러한 두 버그는 경쟁 조건의 시간 창(race window)이 작고 파일 생성 위치가 불확실하기 때문에 악용하기가 쉽지 않습니다. 여기서 우리는 이를 악용하는 기술을 공유합니다.
두 경쟁 조건 버그의 근본 원인은 우리의 보고서에 나와 있으며, 실제 원인은 **예측 가능하면 취약하다(Predictable is Vulnerable)**로 표현할 수 있습니다. WER 서비스가 임시 파일을 처리할 때 C:\ProgramData\Microsoft\Windows\WER\Temp 위치의 파일을 조작하는데, 이 디렉터리는 Authenticated Users에게 읽기/쓰기(R/W) 권한이 열려 있습니다. 즉, 중간 IL(medium-IL) 일반 사용자는 WER 서비스가 만든 파일을 덮어쓸 수 있고, 심지어 해당 파일을 FileSystem 링크로 바꿔서 평소에는 건드릴 수 없었던 다른 파일을 손상시키거나 삭제할 수 있습니다.
파일 작업을 안전하게 유지하기 위해 WER 서비스는 GetTempFileNameW라는 표준 API에 의존하며 wersvc.dll->UtilGetTempFile로 이를 래핑합니다. 이 API는 WerSvc가 "WER****.tmp" 형태의 사용되지 않는 임의의 파일 이름을 생성하도록 도와줍니다. 파일 이름의 임의 부분은 0000-FFFF 범위의 4바이트 16진수로 생성되며, 만약 해당 번호가 이미 파일을 만드는 데 사용되었다면 API는 다른 임의의 파일 이름을 선택합니다.
이 전략은 WER0000.tmp부터 WERFFFE.tmp까지의 65535개 파일을 생성하면 명백한 결함이 있습니다. API는 임의의 숫자를 선택하고 예를 들어 WERA560.tmp와 같은 파일 이름이 존재하는지 테스트합니다. 파일이 이미 존재한다는 것을 발견하면 WERA560.tmp부터 WERFFFF.tmp까지 계속 테스트합니다. 테스트가 진행되는 동안, 우리는 WerSvc가 GetTempFileNameW 호출에서 4~5초 동안 멈추게 하는 방법을 찾았기 때문에 준비 창(preparing window)이 나타나며, 이는 꽤 큰 시간 간격입니다. 그 동안 우리는 서비스가 고정된 파일 이름, 즉 WERFFFF.tmp로 임시 파일을 생성하도록 강제합니다.
서비스가 WERFFFF.tmp라는 임시 파일을 만든 후 API는 파일에 대해 보유하고 있는 핸들을 자동으로 닫고, 파일 이름을 서비스에 반환하여 이후 파일에 대한 작업을 수행하게 합니다. 바로 이 지점이 버그가 발생하는 위치입니다. 세 가지 조건이 충족됩니다:
여기서 서비스는 파일에 내용을 쓰고 삭제합니다. 쓰기와 삭제 모두 FileSystem 링크와 특정 악용 기술을 활용하여 권한 상승을 유발합니다.
이 버그를 임의 파일 삭제로 전환하기 위해, 우리는 여러 개의 디렉터리 정션(junction)을 창의적으로 활용하여 악용을 완료합니다. 우리의 익스플로잇은 다음 단계로 구성됩니다:
WER***.tmp 파일 전체를 $pwd\1\에 넣고 $pwd\2\ -> $pwd\1\로 정션합니다;$pwd\2\ 경로로 이 함수를 지속적으로 트리거하는 프로세스를 만들고, 다른 프로세스를 만들어 SetOplock $pwd\1\WERFFFF.tmp 명령을 지속적으로 실행합니다;$pwd\2\ -> \RPC CONTROL\로 정션한 다음, \RPC CONTROL\WERFFFF.tmp -> $target 및 \RPC CONTROL\WERFFFF.tmp.etl -> $target 객체 심볼릭 링크를 생성합니다.자세한 악용 방법과 POC는 WERReport-CVE-2020-0753에 제공됩니다.
GetTempFileNameW의 결함을 악용하여 서비스가 작업할 예측 가능한 위치를 확보하고, 다중 레벨 FileSystem 정션을 활용하여 경쟁 조건을 안정적으로 악용할 수 있게 만듭니다.
한편, 우리는 이러한 종류의 경쟁 조건 버그가 파일 덮어쓰기 문제를 일으킬 수도 있다는 점을 발견했으며, 특정 상황에서는 권한 상승(Escalation of Privilege) 버그로 이어질 가능성이 있습니다.
임의 파일 손상(파일 내용의 아주 작은 일부, 즉 63바이트 미만을 제어할 수 있는 경우)이 EoP로 전환될 수 있는 이유를 설명하려면 Windows Defender의 작동 메커니즘에 주목해야 합니다.
Windows Defender에는 악성코드 시그니처 데이터베이스가 있습니다. 파일에 악성코드 시그니처가 포함되어 있으면 Defender는 이를 악성코드로 간주하고 삭제합니다. 그러나 이 기능은 추가적인 공격 표면을 만듭니다. 예를 들어 WCTF2019에서 tokyowesterns의 @icchy는 이 기능을 정보 유출을 위한 오라클로 사용하는 Windows CTF 챌린지인 "Gyotaku The Flag"를 설계했습니다.
여기서 우리는 Windows Defender의 이 기능을 활용하여 파일 내용을 부분적으로 제어할 수 있는 임의 파일 손상이 있다면 임의 파일을 삭제합니다. 파일에 악성코드 시그니처를 작성하고 Windows Defender의 기본 검사를 트리거하기만 하면 파일이 Defender의 격리 영역에 들어가며, 일반 사용자(즉, 중간 IL 비관리자 사용자)는 검사 작업을 2번 트리거하는 것만으로 해당 파일을 삭제할 수 있습니다.
따라서 해당 버그를 사용하여 악성코드 시그니처 문자열을 대상 파일에 넣을 수 있다면, 임의 파일 손상 버그는 임의 파일 삭제로 전환될 수 있습니다.
버그로 대상 파일을 손상시키고, Windows Defender가 인식할 수 있는 특징 문자열을 그 안에 넣습니다.
Windows Defender가 대상 파일을 검사하도록 트리거하여 파일을 격리시킵니다.
검사를 다시 트리거하면 대상 파일이 삭제됩니다.
이 기술을 활용하면 Defender의 도움으로 임의 파일 삭제를 얻을 수 있습니다.
임의 파일 삭제는 추가 권한을 얻기 위해 훨씬 더 쉽게 악용될 수 있습니다.
Microsoft OneDrive는 개인 클라우드 저장소 서비스를 제공하는 애플리케이션 번들입니다. 이 애플리케이션은 Windows 8부터 기본 설치 옵션으로 Windows에 통합되었습니다. 연구 과정에서 OneDrive의 유지 관리 예약 작업에서 6가지 취약점을 발견하여 MSRC에 제출했습니다.
다음은 Microsoft OneDrive 관련 예약 작업에서 공개할 취약점 표입니다:
| 취약한 프로그램 | 유형 | POC 제공 |
|---|---|---|
| FileSyncConfig.exe | HardLink | 예 |
| FileSyncHelper.exe | HardLink | 예 |
| OneDriveFileSyncConfig.exe | SymLink | 예 |
| OneDriveSetup.exe | HardLink | 예 |
| OneDriveSetup.exe | HardLink | 예 |
| OneDriveStandaloneUpdater.exe | HardLink | 예 |
6가지 버그는 모두 서비스가 일반 사용자가 제어할 수 있는 위치에서 작업하면서 하드링크와 심볼릭 링크를 부적절하게 처리하기 때문에 발생합니다. 이러한 버그를 악용하는 동안 파일 이름에 일반적으로 현재 프로세스의 pid나 파일이 작업된 시점을 나타내는 타임스탬프가 포함된다는 어려움이 있습니다. 둘 다 서비스가 실행될 때 로드하려고 하는 고유한 dll 파일에 oplock을 설정하여 해결할 수 있으며, 이를 통해 서비스가 나중에 작업하려는 파일 이름을 예측하는 데 필요한 모든 것을 얻을 수 있습니다. 예제 POC는 FileSyncConfigTemp_hardlink 디렉터리에 제공됩니다.
위에 언급된 6가지 취약점 모두 완전한 보고서와 POC 프로그램이 제공됩니다. 대부분의 버그는 처음에는 임의 파일 손상을 일으키지만, 이러한 종류의 버그는 여전히 시스템 충돌(중요한 시스템 구성 파일을 덮어씀으로써)을 일으킬 수 있으며, 모두 Windows 재설치가 필요합니다. 따라서 Windows 시스템 서비스 거부(Denial of Service) 버그 유형의 기준을 충족합니다.
게다가, 이러한 종류의 버그는 특정 상황에서 실제로 권한 상승(Elevation of Privilege)을 유발할 수 있습니다. 우리는 임의 파일 덮어쓰기 문제를 활용하여 임의 파일 삭제 원시 동작(primitive)을 달성하는 악용 기술을 논의했으며, 따라서 권한 상승이 달성 가능합니다.
Zhiniang Peng of Qihoo 360 Core Security
2020년 2월 2일: 취약점 보고
2020년 2월 8일: MSRC가 우리가 제출한 OneDrive의 6가지 버그에 대해 조사하고 답변했습니다. 그들의 결론은 필요한 사용자 상호작용이 너무 많음/신뢰할 수 있는 익스플로잇 구축이 너무 어려움으로 인해 수정하지 않는다는 것이었습니다.
2020년 2월 8일: 우리는 답변했습니다: 사용자 상호작용이 필요하지 않습니다. 예약 작업이 실행되기를 기다리기만 하면 됩니다. 따라서 이 시나리오는 일반적입니다.
2020년 2월 11일: MSRC가 답변했습니다: 사용자 머신의 특정 파일을 어떻게 얻습니까? 해당 폴더에 그 파일의 모든 순열을 배치하고 있습니까? Date/Hour/PID와 정확히 일치해야 합니까? 이러한 이유로 사용자 노력이 너무 많이 필요한 것처럼 보입니다.
2020년 2월 11일: 우리는 답변했습니다: 우리의 POC는 단순화된 버전입니다. 파일 이름을 예측하는 노력을 줄이기 위해서입니다. 실제로는 oplock을 설정하기만 하면 됩니다. 그러면 {pid}, {hour}, {data}를 모두 얻을 수 있습니다. 따라서 사용자 상호작용이 필요하지 않습니다.
2020년 2월 12일: 이 6가지 취약점에 대한 writeup을 게시할 수 있는지 문의.
2020년 2월 13일: MSRC가 답변했습니다: writeup을 게시해도 됩니다.
2020년 2월 22일: 세부 정보 공개
상태 업그레이드: 6가지 취약점 모두 2020년 3월 Patch Tuesday에서 수정되었습니다.