fortra/cve-2022-30136CVE-2022-30136을 위한 Windows 네트워크 파일 시스템 원격 익스플로잇
저자: Ricardo Narvaja
데모 목적으로만 사용하십시오. 전체 익스플로잇은 취약한 Windows Server 시스템에서 작동합니다.
분석 문서 확인: Analysis of CVE-2022-30136 “Windows Network File System Vulnerability“.
이 글은 Core Impact 익스플로잇 “Windows Network File System Remote”를 개발하면서 수행한 분석을 설명하기 위해 작성되었습니다. 이 익스플로잇은 CVE-2022-30136 취약점을 악용합니다.
Windows Network File System 원격 코드 실행 취약점은 NFS 버전 4.1을 사용하는 COMPOUND REQUEST에서 서버 응답을 생성할 때 발생하는 크기 계산 오류입니다.
서버는 풀을 할당하는 데 필요한 크기보다 작은 크기를 계산한 다음, 응답을 생성하기 위해 데이터를 복사할 때 버퍼를 오버플로합니다.
nfssvr.sys의 함수 Nfs4SvrXdrpGetEncodeOperationResultByteCount는 각 작업에 대해 호출되며, 필요한 크기보다 4바이트 작은 값을 반환합니다.
Nfs4SvrXdrpGetEncodeOperationResultByteCount에 대한 패치가 적용되었습니다.
이 함수는 COMPOSE REQUEST의 각 OPERATION 중 호출되어 OPCODE에 따라 각 작업에 필요한 바이트 수를 반환합니다. 그런 다음 헤더 및 응답의 다른 부분에 추가됩니다. 다음으로, 전체 응답의 최종 크기를 계산하여 할당한 후 복사하여 응답합니다.
각 경우에서, 취약한 버전이 반환하는 각 작업의 크기 값이 패치된 버전보다 4바이트 작은 것을 확인할 수 있습니다.
Windows Server 2019용 POC를 구축했습니다.
아래는 이 POC에 사용된 취약한 버전의 nfssvr.sys이며, 그 다음은 Windows Server 2019용 패치된 버전입니다:
다음 이미지는 diff에서 CASE 26을 보여줍니다:
CASE 26의 예에서, 취약한 버전은 계산된 값에 추가된 상수가 0x2c인 반면, 패치된 버전은 0x30임을 확인할 수 있습니다.
각 OPCODE에 해당하는 각 CASE에서도 동일하게 나타납니다. 취약한 버전은 항상 패치된 버전보다 4바이트 작은 크기를 반환합니다.
패치는 모든 OPCODE에 대해 유사하므로 모든 사례를 보여주지는 않겠습니다.
Nfs4SvrXdrpGetEncodeOperationResultByteCount의 부모 함수는 Nfs4SvrXdrEncodeCompoundResults입니다. 이 함수는 COMPOUND REQUEST에서 전송된 작업 수를 읽습니다.
이 POC에서 값은 0x34(52d)입니다. POC가 포트 2049(NFS 기본 포트)를 통해 서버에 연결할 때, 중단을 위한 조건부 중단점을 설정해야 합니다.
이 인스턴스에서 number_of_operations=0x34일 때 중단됩니다.
태그가 ARGS인 풀이 여기에 할당됩니다.
그런 다음 TAG_ARGS_0x10e0이라는 구조체를 만들어 필드를 리버스 엔지니어링합니다.
number_of_operations를 r13에 복사하고, 카운터가 r13 값에 도달할 때까지 각 작업에 대해 취약한 함수를 반복합니다.
첫 번째 package_OPCODE는 0x35이며, 이는 COMPOUND REQUEST의 첫 번째 필수 작업인 SEQUENCE에 해당합니다. 아래 이미지에서 화살표는 내 패키지의 이 OPCODE를 가리킵니다.
여기서 취약한 함수의 인수를 볼 수 있습니다.
취약한 함수 내부에서 OPCODE를 읽고 해당 CASE로 이동합니다.
원래 OPCODE 값(53)에서 3을 뺍니다.
그리고 CASE 50으로 점프하여 이 작업에 필요한 크기로 0x28을 반환합니다.
diff에서 패치된 버전이 0x2c를 반환하는 것을 확인할 수 있습니다.
이 반환된 값은 작업 크기를 계산하기 위해 응답의 다른 필드의 이전 값에 추가됩니다. 이 경우 값은 0x40c입니다.
아래에서 값이 추가되는 것을 볼 수 있습니다:
루프를 빠져나오면 총 크기가 계산됩니다. 이 경우 총 크기는 0x1310입니다.
취약한 버전과 패치된 버전의 차이는 다음 공식을 사용하여 크기를 계산하여 추측할 수 있습니다: number_of_operations * 4.
이 경우 패치된 버전의 할당은 취약한 버전보다 0x34 * 4 = 0x68 더 큽니다.
그 후 0x24를 추가합니다. 이 값은 취약한 버전과 패치된 버전 모두에서 비슷한 방식으로 계산됩니다.
그런 다음 두 경우 모두 상수 0xf를 추가합니다.
이 시점까지 이 예제의 크기는 0x1340이었습니다.
다음으로 rpcxdr_OncRpcBufMgrpAllocate에 도달합니다.
그런 다음 r15로 이동합니다.
1을 빼고 4를 더합니다. 그런 다음 0x800과 비교합니다.
이 잘못 계산된 크기는 0x800보다 큰 경우에만 사용됩니다. 따라서 COMPOUND REQUEST만이 버그를 트리거합니다.
먼저 크기가 0x80이고 태그가 XdBD인 풀을 할당합니다.
마지막으로, 여기에 응답을 위한 풀을 크기 0x1398로 할당하며, 여기에 일부 상수 값이 추가됩니다.
그런 다음 0x13a0을 할당합니다(태그 XdBP 및 헤더 포함).
여기에서 새로 할당된 풀의 주소를 필드에 저장합니다: tag_XdBD_0x80.p_TAG_XDBP_0x13a0.
이는 항상 복사되는 응답의 주소를 가리킵니다.
그런 다음 응답 헤더를 구성하기 시작합니다.
다음은 임시 포인터의 내용에 데이터를 저장하고 4를 더하는 예입니다.
아래에서는 응답 주소의 내용에 복사하는 방법을 볼 수 있습니다.
첫 번째 dword를 쓰고 포인터를 4만큼 증가시킵니다.
다음으로 두 번째 dword를 쓰고 4를 더합니다.
함수를 종료한 후, 전체 헤더가 작성됩니다.
그 후 nfssvr.sys로 돌아가 응답 작성을 계속합니다.
응답에서 디코딩 및 작성을 계속하며, 임시 포인터에 4를 더합니다.
헤더를 완료하면 모든 작업을 작성하기 위해 이 루프에 도달합니다. 첫 번째 OPCODE 0x35부터 시작합니다.
풀 시작 부분에서 0x428을 쓰는 것을 볼 수 있습니다.
이제 태그 뒤를 가리킵니다.
여기에 중단점을 설정하면 모든 작업이 어떻게 작성되었는지 확인할 수 있습니다.
루프를 종료한 후 모든 작업이 복사됩니다.
풀의 끝을 확인해 보겠습니다.
거기서 제한을 초과하는 쓰기를 볼 수 있습니다.
할당 크기가 복사된 데이터보다 작아 풀 오버플로가 발생합니다.
이로 인해 대상 머신에서 BSOD가 발생합니다. 그러나 질문은, 원격 코드 실행 또는 Write what where를 달성할 수 있을까?입니다.
오버플로된 바이트에 제어된 데이터가 포함된 응답을 얻기 위해 여러 가지 opcode 조합을 시도했지만 운이 없었습니다.
최대 태그(내가 제어 가능)는 시작 부분에만 배치할 수 있으며 최대 크기는 0x400입니다.
시도한 다른 모든 opcode는 제어된 데이터로 응답하지 않았습니다. 따라서 이 버그로 RCE를 얻거나 권한을 상승시키는 것이 불가능하거나 적어도 매우 어렵다고 생각합니다. 그렇지만 여전히 가능할 수도 있습니다. 존재하는 많은 가능성 중 모든 조합을 시도하지는 않았기 때문입니다.
POC 구축을 위해 “NFS CLIENT”라는 클라이언트를 시도했습니다. 이 클라이언트는 NFS 4.1을 지원하며 파일 복사, 편집, 폴더 생성 등 다양한 opcode를 시도할 수 있었습니다.
이 구축에서는 COMPOUND 샘플 패키지를 만들고 크기, 클라이언트 ID, 세션 ID 등을 조정할 수 있었습니다.
다음으로 EXCHANGE_ID를 보내 클라이언트 ID를 얻고, 이를 사용하여 CREATE_SESSION을 보낸 후 마지막으로 큰 COMPOUND REQUEST를 보냈습니다.
이 시점에서 버그가 익스플로잇되어 DoS 공격을 허용하는 원격 코드 실행이 발생합니다.
도움이 되길 바랍니다. 문의 사항이 있으면 [email protected]으로 연락 주십시오.
즐기세요!
