
CVE-2021-43229 워크스루
Windows NTFS 권한 상승 취약점
다음과 구분됨:
패치: 2021년 12월 14일
Twitter의 @AravGarg3에 따르면, CVE-2021-43229는 악용 가능하며 정수 오버플로와 관련된 것으로 보입니다.
출처: https://twitter.com/AravGarg3/status/1479447843458863104
| Windows 10 마이너 버전 | 릴리스 날짜 |
|---|---|
| 1387 | 11/22/2021 |
| 1415 | 12/14/2021 |
BinDiff와 IDA Pro를 사용한 패치 디핑 결과는 다음과 같은 변경 사항을 보여줍니다:
세 가지 후보가 유력합니다:
Microsoft의 12월 보안 업데이트 가이드에 따르면, 4개의 CVE가 NTFS와 관련이 있습니다:
CVE-2021-43240는 NtSetShortNameInfo와 관련된 것으로 보입니다.
NtfsRenameToPrivateDir, TxfAllocateAndStoreNameForTxLogging 그리고 TxAllocateFullFilePathForChangeNotify는 모두 동일한 새로운 길이 검사를 가지며, CVE-2021-43229, CVE-2021-43230, CVE-2021-43231과 관련된 것으로 보입니다. 반드시 이 순서는 아닙니다. 현재, 어느 것이 어느 것인지 알 수 없습니다. Microsoft는 이 정보에 대해 약간 인색합니다.
세 CVE 모두에서 할당 크기 계산(디렉터리 경로 길이 + 파일 이름 길이) 중 정수 오버플로가 발생하여, 이후 두 번의 디렉터리 경로 및 파일 이름 memmove로 인해 풀 기반 버퍼 오버플로가 발생합니다.
NtfsRenameToPrivateDirNtfsRenameToPrivateDir까지의 경로는 아래와 같습니다:
NtfsCommonSetInformation
|__________________
| |
v v
NtfsSetLinkInfo NtfsSetRenameInfo
|__________________|
|
v
NtfsRemoveSupersededTarget
|
v
NtfsRenameToPrivateDir
먼저, NtfsCommonSetInformation을 호출하려면 NtSetInformationFile을 호출하기만 하면 됩니다. 그런 다음 NtfsSetLinkInfo와 NtfsSetRenameInfo를 거치려면 NtSetInformationFile의 파일 정보 클래스로 각각 FileLinkInformationEx와 FileRenameInformationEx를 사용하세요.
NtfsSetRenameInfo를 통해 NtfsRemoveSupersededTarget에 도달하려면 FILE_RENAME_REPLACE_IF_EXISTS 및 FILE_RENAME_POSIX_SEMANTICS 플래그를 설정해야 합니다. 기존 파일의 이름으로 파일 이름을 바꾸면 NtfsRemoveSupersededTarget에 접근할 수 있습니다. NtfsRenameToPrivateDir의 경우, 교체되는 파일이 어떤 프로세스에 의해 열려 있어야 하므로 약간 까다롭습니다.
안타깝게도 NtfsRemoveSupersededTarget 호출 전에 길이 검사가 수행됩니다.
NtfsSetLinkInfo를 사용하는 방법은 NtfsSetRenameInfo와 유사하며, 단지 플래그 이름만 다르고 의미는 동일합니다. 그러나 NtfsSetRenameInfo와 마찬가지로 NtfsRemoveSupersededTarget 호출 전에 또 다른 검사가 수행됩니다.
TxfAllocateAndStoreNameForTxLoggingTxfAllocateAndStoreNameForTxLogging까지의 경로는 아래와 같습니다:
NtfsCommonCreate
|
v
NtfsCreateNewFile
|
v
TxfNewFileCreate
|
v
TxfAllocateAndStoreNameForTxfLogging
먼저, NtfsCommonCreate를 호출하려면 CreateFile을 호출하기만 하면 됩니다.
TxfNewFileCreate 함수는 Txf 접두사가 붙는데, 이는 "트랜잭션 NTFS"를 의미하며 트랜잭션 파일이 생성될 때 호출됩니다. TxfAllocateAndStoreNameForTxfLogging은 트랜잭션 파일의 경로를 저장하기 위해 프로세스 중에 호출됩니다.
필요한 호출은 두 개뿐입니다:
아래는 TxfAllocateAndStoreNameForTxLogging의 취약한 코드입니다:
...
and di, 2
add di, [rsi+UNICODE_STRING.Length] ; File name
add di, [rsp+68h+RelativeNormalizedDirectoryPath.Length] ; OVERFLOW HERE
cmp [rsp+68h+arg_20], r12b
jnz loc_16592C
movzx edx, di
add rdx, size UNICODE_STRING ; NumberOfBytes
mov ecx, cs:PoolType
or ecx, 10h ; PoolType
mov r8d, 'afxT' ; Tag
call cs:__imp_ExAllocatePooliWthTag
...
오버플로를 트리거하려면 0xFFFF 바이트(32767자)를 초과하는 과도한 길이의 파일을 만들어야 합니다.
문제는 파일 또는 디렉터리 이름이 NULL 문자를 포함하여 256자를 초과할 수 없다는 것입니다. 이 문제를 해결하려면 깊은 하위 폴더를 사용해야 합니다. 이상하게도 그렇게 쉽지 않습니다. 하위 폴더가 성공적으로 생성되었음에도 하위 파일을 생성할 수 없었습니다. 확실히 이전에 수행된 일부 검사 때문입니다.
explorer 표시줄을 사용하면 디렉터리 경로를 표시하는 데 사용되는 형식을 확인할 수 있습니다. 그것은 제가 예상한 것이 아니었습니다. "고전적인" 경로 대신 explorer는 DOS의 구식 형식인 8.3 짧은 형식을 사용합니다.
하위 폴더 생성을 이전과 동일하게 유지하고, 파일 생성 중에 하위 디렉터리의 짧은 이름을 사용하면 문제가 해결됩니다.
16바이트가 오버플로된 크기에 추가된다는 점에 유의해야 합니다. 이는 최종 경로를 나타내는 UNICODE_STRING의 크기입니다. 요청된 메모리에 UNICODE_STRING과 이 UNICODE_STRING의 버퍼가 차례로 포함되기 때문입니다.
방법:
현재 조건:
VS Heap을 대상으로 하는 Synacktiv의 SSTIC 2020 발표 분석 자료는 파고들어 볼 만한 아이디어가 될 수 있습니다.
CVE-2020-17087은 위에서 언급한 기법을 사용하여 PixiePoint Security가 발표한 유사한 악용 사례입니다.
| Simi | Conf | 함수 | 정보 |
|---|
| NOK | 0.98 | 0.99 | NtfsCommonSetInformation$fin$0 | 점프 수정 |
| 0.97 | 0.99 | NtSetShortNameInfo | ||
| 0.96 | 0.99 | NtfsUpdateSecurity | ||
| NOK | 0.91 | 0.94 | NtfsRenameToPrivateDir$fin$1 | 점프 수정 |
| 0.89 | 0.98 | NtfsInitializeFileInDirectory | ||
| OK | 0.88 | 0.95 | TxfAllocateAndStoreNameForTxLogging | 길이 검사 |
| OK | 0.87 | 0.93 | NtfsRenameToPrivateDir | 길이 검사 |
| OK | 0.81 | 0.95 | TxfAllocateFullFilePathForChangeNotify | 길이 검사 |
| 0.76 | 0.94 | NtfsCommonSetInformation |