2022년 2월부터 Trend Micro의 연구에 따르면 Windows 0-day 취약점을 사용하는 것으로 보이는 새로운 랜섬웨어가 보고되었습니다.
이 랜섬웨어에 대한 자세한 정보는 이 링크에서 확인할 수 있습니다.
Kaspersky의 분석에 따르면 Nokoyawa 랜섬웨어 그룹은 2022년 6월부터 CLFS(Common Log File System) 드라이버를 대상으로 하는 유사하지만 뚜렷한 특징을 가진 다른 익스플로잇을 사용했으며, 모두 단일 익스플로잇 개발자와 연결되어 있습니다.
2023년 4월 Microsoft가 패치를 출시했을 때 CVE-2023-28252가 할당되었습니다.
이전에 2022년에는 동일한 구성 요소의 유사한 버그가 저희에 의해 연구되었으며, 이 블로그 게시물에 문서화되었습니다.

CLFS(Common Log File System) 파일 형식:

분석을 수행하려면 취약한 CLFS(Common Log File System) 드라이버인 CLFS.sys가 처리하는 .blf 파일 형식을 알아야 하며, 이 드라이버는 system32 내의 드라이버 폴더에 있습니다.

이 파일 형식에 대한 자세한 정보는 아래 링크에서 확인할 수 있습니다:

https://www.zscaler.com/blogs/security-research/technical-analysis-windows-clfs-zero-day-vulnerability-cve-2022-37969-part

https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/introduction-to-the-common-log-file-system

https://github.com/ionescu007/clfs-docs/blob/main/README.md

https://www.coresecurity.com/core-labs/articles/understanding-cve-2022-37969-windows-clfs-lpe

취약점:

이 분석은 Windows 11 21H2, clfs.sys 버전 10.0.22000.1574를 대상으로 하지만 Windows 10 21H2, Windows 10 22H2, Windows 11 22H2 및 Windows Server 2022에서도 작동합니다.

이전 Windows 버전에서는 일부 값을 조정해야 하며, 그렇지 않으면 BSOD가 발생합니다.

2023년 4월 Microsoft 패치 화요일.

드라이버 버전을 확인하는 방법은 위와 같습니다.

취약점이 공개되었을 때인 2023년 4월, 저는 Esteban Kazimirow와 함께 CLFS.sys 드라이버 리버싱을 시작했습니다. 하지만 이 경우 패치만 분석하는 것은 버그가 어디에 있는지, 어떻게 트리거하는지 추론하기 매우 어려웠습니다. 익스플로잇이 매우 복잡하기 때문입니다.

이후, 악성코드 샘플을 통해 HexRays가 디컴파일한 코드의 일부와 익스플로잇이 어디를 대상으로 해야 하는지에 대한 정보를 제공하는 블로그 게시물이 나왔습니다.

제공된 정보가 완전하지는 않았지만, 이 도움 없이는 PoC를 구축하고 나중에 작동하는 익스플로잇을 만드는 것은 불가능했을 것입니다.

이해를 돕기 위해 먼저 PoC를 구축하는 방법을 설명한 다음 취약점 분석을 수행하겠습니다.

이 블로그 게시물은 두 개의 섹션으로 구성되어 있습니다:

PoC 구축:

1- 익스플로잇에 필요한 커널 주소 얻기

2- .blf 파일을 생성할 경로 준비:

3- CreateLogFile() 함수를 사용하여 "트리거 blf" 파일 생성

4- "트리거 blf" 파일 조작

5- 트리거 blf의 BASE BLOCK 커널 주소 얻기

6- 트리거 blf의 핸들로 AddLogContainer 호출

7- 스프레이 blf 파일 준비

8- 스프레이를 수행할 메모리 준비

9- 버그 트리거

디버깅:

1- 메모리 스프레이 확인

2- 트리거 blf의 RecordOffset[12] 살펴보기

3- 스프레이 blf 파일의 iFlushBlock 값 확인

4- BLOCK 0 CONTROL 대신 BLOCK 1 SHADOW에서 읽는 이유?

5- 블프 스프레이 파일에서 체크섬이 0인 이유?

6- 익스플로잇 종료.

7- 실제 패치

PoC 구축:

1- 익스플로잇에 필요한 커널 주소 얻기

InitEnvironment라는 함수를 만들어 필요한 일부 커널 주소를 얻겠습니다.

내 프로세스의 EPROCESS 주소를 가져와 g_EProcessAddress 변수에 저장하고, SYSTEM 프로세스의 EPROCESS 주소를 가져와 system_EPROCESS에 저장합니다. 그런 다음 내 프로세스의 메인 스레드의 EHTREAD 주소를 가져와 g_EThreadAddress에 저장하고, 마지막으로 PREVIOUS MODE의 주소를 가져오지만 이 PoC 버전에서는 사용되지 않습니다.

이 방법은 잘 알려져 있으며, GetObjectKernelAddress 함수는 첫 번째 인수 SystemExtendedHandleInformation으로 NtQuerySystemInformation을 두 번 호출합니다. 첫 번째 호출은 잘못된 크기로 전달되어 오류를 반환하지만, 두 번째 호출에 사용되는 올바른 크기도 반환하며 모든 핸들에 대한 정보를 얻습니다. 그런 다음 각 핸들의 정보를 루프로 검토하여 올바른 handleinfo의 Object 필드에서 커널에서 찾고자 하는 주소를 얻습니다.

또한 CLFS.sys에서 내보낸 다음 함수들의 커널 주소가 필요합니다:

• ClfsEarlierLsn

• ClfsMgmtDeregisterManagedClient

그리고 NTOSKRNL.exe에서 내보낸 함수들:

• RtlClearBit/PoFxProcessorNotification

• SeSetAccessStateGenericMapping

이러한 주소를 얻기 위해 두 모듈의 커널 베이스를 얻는 데 사용되는 것과 유사한 방법을 사용합니다. NtQuerySystemInformation을 두 번 호출하지만, 이번에는 첫 번째 인수가 SYSTEM_INFORMATION_CLASS가 됩니다(PoC에서는 이 목적으로 FindKernelModulesBase 함수를 사용합니다).

그런 다음 CLFS.sys와 NTOSKRNL.exe를 LoadLibrary를 호출하여 사용자 모드에서 일반 모듈로 로드하고, GetProcAddress로 사용자 모드 주소를 얻은 다음 각각에서 imagebase를 빼서 함수의 오프셋을 얻습니다. 마지막으로 각 오프셋을 해당 커널 베이스에 더하여 필요한 모든 함수의 커널 주소를 얻습니다.

2- .blf 파일을 생성할 경로 준비:

createInitialTriggerBlfFile이라는 함수를 만들어 .blf 파일을 생성하고 씁니다.

CreateLogFile에 인수로 사용되는 경로는 일반 경로와 다릅니다. 예를 들어 C:\Users\Public 폴더에 있는 1280.blf 파일을 열려면 LOG:C:\Users\Public\1280 경로를 설정해야 합니다. 이는 stored_name_CreateLog 변수에 저장됩니다.

**wsprintfW()**를 사용하여 이를 수행합니다. stored_env는 환경 변수에서 이전에 얻은 경로 C:\Users\Public을 저장합니다. 이 문자열 앞에 LOG: 문자열을 추가하고 끝에 임의의 이름을 추가합니다(.blf 확장자 없이).

이것이 제가 "트리거 blf"라고 부를 초기 파일의 경로입니다. 물론, 앞에 **LOG:**가 없고 BLF 확장자가 있는 동일한 파일의 일반 경로도 저장해야 합니다. 예: C:\Users\Public\1280.blf. 이 경로는 **CreateFile(), WriteFile()**을 사용하여 다른 파일과 마찬가지로 열고 수정하기 위한 것이며 stored_name_fopen 변수에 저장됩니다.

물론 두 경로 모두 동일한 파일에 해당하며, 필요에 따라 하나를 사용해야 합니다.

3- CreateLogFile() 함수를 사용하여 "트리거 blf" 파일 생성

CreateLogFile 함수는 **CreateFile()**과 매우 유사한 기능을 수행합니다(새 파일을 만들거나 기존 파일을 열고 핸들을 얻음). 일부 인수도 유사하지만 **CreateLogFile()**은 blf 파일에서만 작동합니다.

또한 기존 파일을 열 때 형식이 올바른지 확인하며, 각 블록에 체크섬이 있고 올바르지 않으면 오류를 반환합니다.

2가지 종류의 BLF 파일을 만들겠습니다:

1. 트리거 blf

2. 스프레이 blf

둘 다 blf 파일이지만 다른 방식으로 수정됩니다.

이런 식으로 PoC는 먼저 CreateLogFile을 사용하여 "트리거 blf" 파일을 만듭니다. 경로는 예: 이전에 설정한 LOG:C:\Users\Public\1280이며 stored_name_CreateLog 변수에 저장되었습니다.

다섯 번째 인수 fCreateDisposition은 ***CreateFileA()***와 마찬가지로 다음 값을 가질 수 있습니다:

이 경우 OPEN_ALWAYS 인수를 사용합니다. 따라서 파일이 없으면 생성되고 있으면 열립니다. 파일이 아직 없으므로 임의의 이름으로 생성됩니다.

logFile = CreateLogFile(stored_name_CreateLog, GENERIC_READ | GENERIC_WRITE, 1, 0, 4, 0);

**CreateLogFile()**은 6개의 블록과 해당 체크섬을 포함한 "트리거 blf" 파일을 생성하고, logFile 변수에 저장될 핸들을 반환합니다.

각 블록은 왼쪽 열에 표시된 오프셋부터 헤더를 가지며, 그 크기는 0x70바이트입니다.

예를 들어 CONTROL BLOCK의 헤더는 오프셋 0x0에서 0x70까지입니다.

모든 블록의 모든 헤더는 _CLFS_LOG_BLOCK_HEADER라는 동일한 구조를 가집니다.

다음은 헤더 구조입니다:

헤더의 오프셋 0xC에서 체크섬을 찾을 수 있습니다. 따라서 CONTROL BLOCK이 오프셋 0부터 시작하므로 체크섬은 파일의 오프셋 0xC에 있으며, 각 블록은 해당 블록 시작부터 오프셋 0xC에 체크섬이 있습니다.