klezVirus

Finding new drivers vulnerable to CVE-2024-26507 > Disclaimer > > I disclosed all of this publicly: the tooling, the proof of concept, and the reports. The NVD entry for CVE-2024-26507 now lists this repository (PaulDotSH/vuln-driver-aida64) among its references. Some of the code and text was AI-assisted. I verified every finding, hash, IOCTL, and code path on a real Windows machine. > > I did not report the original CVE. Another researcher found the AIDA64 kernel driver issue in early 2024 and got CVE-2024-26507 assigned (advisory at belong2yourself.github.io, PoC at klezVirus/AIDA64Driver-EoP). My work was to find additional vulnerable builds and versions that nobody had covered, verify them, and get them added to the existing record. At a glance | | | |---|---| | CVE | CVE-2024-26507 | | Class | Local privilege escalation via arbitrary physical memory R/W | | Weakness | CWE-1286 | | CVSS 3.1 | 7.8 (High) | | Vendor | FinalWire (AIDA64) | --- BYOVD Kernel exploit kits almost never are from a fresh kernel bug. They ship a signed driver that already does what the attacker wants, usually arbitrary physical or kernel memory read and write, and that an unprivileged process can drive with no check in between. A real vendor signed the driver, so it loads on a stock Windows box with Driver Signature Enforcement on. The attacker brings the driver and the kernel supplies the escalation. The question I cared about was not whether I could write an exploit. It was which signed drivers have a dangerous primitive accessible by a normal user. That is a search problem, so I automated it. One detail matters here. A CVE pins one version range, not every build. Vendors keep shipping the same flawed driver across releases, each signed with a fresh timestamp and a new hash. Enumerating those builds is useful work on its own, and it is what I ended up doing. --- Static triage I have written a static analyzer in Python (drvscan) for Windows kernel drivers. It scores drivers against the pattern that makes BYOVD work, then I have a more detailed look at the found driver. drvscan parses the PE headers, and has some weights based on the found signals. We also check if a device is created, since we only care for user mode reachability. We also count memory mapping, section mapping and others. I have implemented a scraper for multiple web sources which I won't name, where I get the drivers from. The analysis is done on the downloaded drivers. --- What I have actually found AIDA64 is FinalWire's system information and diagnostics utility. Its kernel component, kerneld.x64, ships as aida64x.sys with a second build as aida64.sys. FinalWire signs both and they load on stock Windows, including builds I pulled from current vendor packages. The triage report for the second build: Output from my custom tool: - Score: 26/100 (MEDIUM) - SHA-256: eba3233869c744271d5c22e4c1011ce866987d444a00bb78e4089637b7ed794b - Findings: physical_memory, mdl_mapping, exposes_device - Device paths: \Device\AIDA64Driver, \DosDevices\AIDA64Driver - PDB: e:\work\visualc\llkd\driver.nt\amd64\LLKD.pdb We see by these findings together a driver that creates a device object, maps physical memory, maps MDLs, and imports no access check. The original 2024 report already described that shape. What I found was that the same defect sits in additional signed builds and versions, including ones in current 8.x AIDA64 packages, none of which were in the known-vulnerable record for the family. The device object is the pivot. The driver creates \Device\AIDA64Driver from DriverEntry with no ACL, so any process can open it: HANDLE h = CreateFileA("\\\\.\\AIDA64Driver", GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING, 0, NULL); The driver then exposes IOCTLs that take a caller-supplied physical address and size and pass them through with no validation: | IOCTL | Effect | |---|---| | 0x80112074 | read 4 bytes at physical (hi<<32)\|lo | | 0x80112078 | write 4 bytes to physical (hi<<32)\|lo | | 0x80112040 | memcpy(dest_va, MmMapIoSpace(phys, size), size) for a bulk physical read | | 0x8011204c / 0x80112084 | rdmsr / wrmsr | | other | raw port I/O and PCI configuration-space read and write | The bulk path is the standard kernel-to-user mapping chain. The handler reads the address and length from IRP->SystemBuffer and calls MmMapIoSpace, IoAllocateMdl, MmBuildMdlForNonPagedPool, and MmMapLockedPagesSpecifyCache in sequence, mapping the result into the caller's address space. An unprivileged caller ends up with arbitrary physical memory read and write. With the token-stealing technique that h0mbre and Ruben Boonen have both written up, that is enough to reach NT AUTHORITY\SYSTEM without a memory-safety bug. --- Proof (PoC) aida64_rw.c is built to prove it with a round trip instead of exposing a poke-any-address tool: 1. Open the device. 2. VirtualAlloc a large buffer, fill it with a 16-byte marker, and VirtualLock it so it stays resident. 3. Scan physical memory in 64 KB chunks through the bulk-read IOCTL until the marker shows up, which proves the read. 4. Read the located address back through the single-dword IOCTL and confirm it matches. 5. Write a new value through the driver and confirm it appears in the process's own mapping, which proves the write. 6. Restore the original value. If the driver were not mapping real physical memory, the round trip would fail. It does not. I left the step from arbitrary physical read and write to kernel code execution or an EDR kill out of the PoC and this post. The point is to document the defect for the advisory process, not to ship a weapon. --- The memflow connector To measure how usable the primitive is, I wrote a memflow connector, memflow-aida64, over the two METHOD_BUFFERED IOCTLs. It presents the driver as a memflow PhysicalMemory backend, so any memflow OS layer can run on top of it, which is full virtual memory access to the running OS from an unprivileged process. memflow-bench compares it against a raw IOCTL backend on per-call latency and on bulk throughput up to 4 MB. I am not publishing the connector. Same reason as the PoC: defenders need to know the driver is dangerous, not to be handed a kernel memory access tool. --- Disclosure Everything is public. - Original discovery (not mine): reported in early 2024 and assigned CVE-2024-26507. Advisory at belong2yourself.github.io, PoC at klezVirus/AIDA64Driver-EoP. - My report: magicsword-io/LOLDrivers#461 covers the additional signed builds and hashes and the affected IOCTLs, and asks for them to be added to the existing record. - My repository: PaulDotSH/vuln-driver-aida64 holds the analysis and the PoC. - Advisory: GHSA-xp8w-jxfc-xrqq. - CVE: CVE-2024-26507. The binaries I reported: | File | SHA-256 | Size | |---|---|---| | aida64.sys | 27375351b4a723465f937866f0ffc86e8e612b093673ee25ccf0b7ea803f888f | 34,648 bytes | | aida64x.sys (kerneld.x64) | eba3233869c744271d5c22e4c1011ce866987d444a00bb78e4089637b7ed794b | 68,376 bytes | --- For security researchers The "lesson" here is not that I found a bug. Someone else found it and got the CVE. The lesson is that a CVE entry does not enumerate every affected build. The same signed physical-memory primitive kept shipping, and the original record did not cover it. For anyone auditing: signing does not make a driver safe, and a diagnostics utility that maps physical memory for hardware information is one IOCTL away from local privilege escalation. Keep scanning after a CVE lands, because the fixed version in the record can be narrower than the vulnerable reality.

Special thanks to @klezvirus.bsky.social for Moonwalk++ kept the original SystemFunction032 + static "MyTest1" key and the same VP(RWX) → ENCRYPT → VP(NOACCESS) ladder. Refs: klezVirus/Moonwalk-- / klezvirus.github.io

Special thanks to @KlezVirus for Moonwalk++ kept the original SystemFunction032 + static "MyTest1" key and the same VP(RWX) → ENCRYPT → VP(NOACCESS) ladder. Refs: klezVirus/Moonwalk-- / klezvirus.github.io