Our target is BKAV Professional (Internet Security AI 2019 whatever this mean) - super duper last version available for download.
During it install and startup this software install and load the following drivers.
 |
| Pic 1. BKAV drivers. |
This driver has dispatch entry with user callable IOCTLs 0x2221CC, 0x22E141, 0x22E145. First one work with internal driver data, two others are more interesting. First is for file deletion, second is for file renaming. As filename they use parameter of device I/O control input buffer from user mode. However even if BKAV device called \Device\BkavSP has default security descriptor they can't be called directly without some little magic. This driver approves calls only from few processes that is hardcoded inside and requester checked everytime IOCTL 0x22E141 or 0x22E145 dispatch hit.
Approval algorithm is the following:
- Query requester full image path name, ZwQueryInformationProcess(ProcessImageFileName), shake it a bit, lower chars;
- Compare result with hardcoded values, if they equal - caller is trusted, process IOCTL.
Hardcoded values are:
BkavService.exe, BluProService.exe, BkavFirewallService.exe, EnterpriseUpdateService.exe
They are expected to be in \SystemRoot\SysWOW64. And yes after installation there is at least one of them present - BkavService.exe. There is no validation if this is valid executables from BKAV or renamed or malicious, just filename comparison. Perhaps authors thinks if they are in SysWOW64 this protect them from tampering. That is a mistake. By the way I saw identical requester check in some trash from ASUS software with same pity result.
What we need to do is to run BkavService.exe with our code inside, create a typical zombie process. What is BkavService.exe? It is 32 bit application with requestedExecutionLevel = requireAdministrator set in embedded manifest. So we will use 32 bit loader and to be able to exploit this BKAVSP feature we need to bypass requireAdministrator manifest setting. We cannot modify this file as it in SYSWOW64 folder and we cannot use it from outside this folder. So we need another simple workaround. During CreateProcess phase we will create copy of our environment with RtlCreateEnvironment and extend it by RtlSetEnvironmentVariable with the new variable __COMPAT_LAYER with value RUNASINVOKER. Next this environment block will be supplied as parameter for CreateProcess API. This will override manifest setting and launch this BkavService.exe requiring administrator rights. From this zombie process we can do our "hack the planet" stuff. Even from Guest account.
The full source code below. As target for deletion selected Windows driver "pci.sys" with hardcoded path. You can use other filenames, they not necessary must be inside Windows directory.
I would suggest BKAV to reconsider the way they validate requester process, discover for yourself modern security API to secure driver devices and stop using code solutions found in Google search. Otherwise this is just another lolAV with loldrivers that only does damage to client PC. Moving this "security solution" to the Recycle Bin as usual.
 |
| Pic2. Running proof-of-concept from Guest account. |
 |
| Pic 3. Inject success, device opened. |
 |
| Pic 4. PCI.sys deleted successfully. |
P.S. Journey will continue ⛵ The much more dangerous "security solutions" are still waiting for publication.
