The Vault: August 2020

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:

No requestor access rights check - all driver devices are created with default security descriptor meaning everyone have read/write access to them;
No input parameters checking or they are insufficient/incorrect - easy way to crash your system from any user;
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:

In client application - call GetCurrentProcessId(), modify result with SWAP_UINT32 macro;
Copy result to local 16 bytes length buffer;
Encrypt this buffer with AES ECB, using TinyAES open source code, as key they used slightly modified values found in Google search (😎);
Call driver with special IOCTL passing encrypted buffer as input parameter;
Driver processes this IOCTL, decrypts buffer (same TinyAES) and extracts PID to remember it in internal list of "trusted" applications;
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:

Query current timestamp with GetSystemTimePreciseAsFileTime;
Convert it to seconds since 1970;
Copy value to 16 bytes length buffer and encrypt it using AES ECB (TinyAES again);
AES key again found in Google search and slightly modified;
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:

TinyAES is no longer used, they switched to CNG (maybe also found it while doing usual Google searches for copy-pasta ready code);
MSR related code removed;
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.