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.

Dustman APT: Art of Copy-Paste

Dustman is a piece of data wiping malware with origin believed to be from Iran or if you like - quote from zdnet.com "Iranian state-sponsored hackers". 

There is a full technical overview of this malware -> https://www.scribd.com/document/442225568/Saudi-Arabia-CNA-report, I wouldn't waste time fully repeating it, as it gives a brief and enough description of this malware key parameters and capabilities.

Usually I pay zero attention to typical APT hysterics and low quality malware pushed by mass media/various fakeAv's as "incredible sophisticated" spyware/whatever. With exception if there is anything related to my work, for example copy/pasted from it. Just like in this case.

This is believed shared code with another data wiper called "ZeroCleare" - and IBM did analysis with 28 page PDF where they managed to copy-paste from my github repository without even giving a single credit or link to original. Well, ok, fuck you too IBM IRIS rippers 💩

Why this thing called Dustman? Well authors of this malware were lazy and left full pdb string inside main dropper C:\Users\Admin\Desktop\Dustman\x64\Release\Dustman.pdb. This doesn't look like fake and left because Visual Studio (and this one created in it) always sets debug information to Release builds by default (Project settings->Linker->Debugging). It is something from series of small tips just like if you are wondering why some of rootkits pdb paths always at Z: drive - easy to use hotkey while debugging on VMware.

Dustman main executable is a muldrop (SHA-1 e3ae32ebe8465c7df1225a51234f13e8a44969cc). 

It contain three more files stored inside executable resource section. They are encrypted with simple xor.

for (ULONG i = 0; i < (ResourceSize / sizeof(ULONG_PTR)); i++)
        Buffer[i] ^= 0x7070707070707070;


Resource with id 1 (decrypted SHA-1 7c1b25518dee1e30b5a6eaa1ea8e4a3780c24d0c) is a VirtualBox driver. It is ripped by me from WinNT/Turla (another APT, this time "believed" to be from GRU GS AF RF, that one by the way also had some references/inspirations of my/our previous work). Dustman author(s) got it from my github repository called TDL - Turla Driver Loader (https://github.com/hfiref0x/TDL), well not only that driver, half of their work actually blatant copy-paste of this repository.

Resource with id 103 (decrypted SHA-1 a7133c316c534d1331c801bbcd3f4c62141013a1) is Eldos RawDisk modified driver (version 3.0.31.121). It is modified by Dustman authors by removing digital certificate from it. Currently I have no answer why they did this, except Eldos RawDisk certificate is widely blacklisted or detected by intrusion prevention systems/AV as possible sign of threat as it was used before multiple times in different malwares (https://attack.mitre.org/software/S0364/)

Resource with id 106 (decrypted SHA-1 20d61c337653392ea472352931820dc60c37b2bc) is malware agent application that is intended to work with Eldos RawDisk to perform data wipe. It contain pdb string C:\Users\Admin\Desktop\Dustman\Furutaka\drv\agent.plain.pdb which is giving you insides on VS solution structure. Furutaka is an internal name that I gave to TDL project executable.

Initial dropper is a modified version of original TDL (Furutaka) version 1.1.5, so it is relatively new, as this is final version in that repository before it was archived at April 2019. Just to show you how much Dustman authors copy-pasted, here is a screenshot of functions which I was able to identify in this malware (while rest of them are various trash from MS runtime).

Pic 1. Dustman dropper functions.

It seems Dustman author(s) simple took TDL solution and then modified it by removing console/debug output in code and adapting it for their specific tasks - decrypt, drop resources to the disk, load RawDisk driver and start agent application at final stage. Lets take a look on modifications made by Dustman author(s).

At main (which is a heavily modified TDLMain from original TDL) right at the beginning Dustman attempts to block multiple copies from installing VirtualBox/mapping Eldos driver by setting mutex with a very specific name "Down With Bin Salman". I do not want to dig into politics and other bullshit but I would like to suggest in case if this is false flag operation (surprise, but we will never know this) use something more creative - like for example "Coded by Soleimani" or "(c) 2019 IRGC", "covfefe" is fine too. If I would doing APT of such kind I would at first refrain from creating such wrong and stupid mutexes or build their unique names based on current environment without using any idiotic constants. Another fun message hidden inside agent executable (dropper resource 106 as mentioned above) "Down With Saudi Kingdom Down With Bin Salman" - very creative (not). Eldos license key is hardcoded in agent executable as "b4b615c28ccd059cf8ed1abf1c71fe03c0354522990af63adf3c911e2287a4b906d47d".

Back to initial dropper, supQueryResourceData (https://github.com/hfiref0x/TDL/blob/master/Source/Furutaka/sup.c#L99) is modified by adding xor decryption loop mentioned above. Below is screenshot of TDLStartVulnerableDriver routine slightly modified by removing console output, code responsible for backup and new file name for dropped file.

Pic 2. TDLStartVulnerableDriver copy-paste.

Original routine https://github.com/hfiref0x/TDL/blob/master/Source/Furutaka/main.c#L498

Assistant.sys here is VirtualBox driver which is loaded as shown on picture above. Have no idea why Dustman authors left VirtualBox USB/Network drivers unload code intact. In original TDL this is required to load driver on machine with VirtualBox installed and this is requirement because VBoxHardenedLoader is depends on this. However this is not required in APT and can be removed, but it seems Dustman author(s) had mediocre understanding of what they are doing. It is a little doubtful that target machines has VirtualBox running which can produce incompatibilities with TDL.

Our next stop is TDLMapDriver routine. In original TDL proof-of-concept it setups shellcode that next will be executed in kernel by VBoxDrv, maps input file, processes it imports and merges it with shellcode. Next VBoxDrv memory mapping executed and finally exploit called. In shellcode original TDL allocates memory for driver mapping using ExAllocatePoolWithTag routine with tag 'SldT' (Tdl Shellcode), processes image relocs, creates system thread (PsCreateSystemThread) with parameter set to driver entry. TDL mapped drivers must be specially designed as DriverEntry parameters in such way of loading will be invalid. Finally thread handle closed with ZwClose. Function pointers passed to shellcode through registers by small bootstrap code which is constructed in user mode. Dustman author(s) modified this loading scheme in the following way: 

1) Encryption for module/function names, funny note that the following string used to decrypt strings in runtime "I'm 22 and looking for fulltime job!". Because this is copy-paste from open source and original TDL is very well detected by various fakeAVs (https://www.virustotal.com/gui/file/37805cc7ae226647753aca1a32d7106d804556a98e1a21ac324e5b880b9a04da/detection) this maybe an attempt to remove some of these detections.
2) They remember ExAllocatePoolWithTag, PsCreateSystemThread and IoCreateDriver however they never use PsCreateSystemThread despite checking it resolving success and instead in their shellcode simple call IoCreateDriver with pointer to driver entry point as InitializationFunction param.

Since IoCreateDriver expects DriverName as pointer to UNICODE_STRING modified shellcode also contain "\Driver\elRawDsk" string stored as local array of bytes. IoCreateDriver will create driver object with specified name and pass it to the InitializationRoutine as parameter, exactly what Eldos RawDisk need at it driver entry. Thus original TDL limitation bypassed and mapping code can work with usual drivers. As result of successful exploitation Eldos RawDisk will be mapped to the kernel and it DriverEntry executed.

 

Pic 3. Eldos driver object as seen by WinObjEx64.

Because driver was mapped without involving Windows loader it doesn't have corresponding entry in PsLoadedModulesList therefore WinObjEx64 shows it driver object major functions as belonging to unknown memory area which is always automatically suspicious and usually mean kernel mode malware activity. While Eldos RawDisk DriverEntry execution it creates a symbolic link to provide access for the applications. It also can be seen with WinObjEx64.

Pic 4. ElRawDisk symbolic link.

Here is a mystery or at least question. Why do they use TDL at all? If you look at Eldos RawDisk previous versions, for example https://www.virustotal.com/gui/file/c5c821f5808544a1807dc36527ef6f0248d6768ef9ac5ebabae302d17dd960e4/details you will notice it is digitally signed. As I said at the beginning of this post there can be IPS/AV blocking Eldos driver by it certificate. However why use Eldos RawDisk if you can write your own driver which will be much simpler/smaller (because it will miss useless license check) and use it with TDL? It seems author(s) of Dustman prefer simplest ways and incapable of writing anything beyond simple copy-pasting with small additions. State sponsored hackers, rofl? It of course depends on effectiveness of such methods but I think someone need a bigger budget. However if you take this entire Dustman as false flag operation it looks pretty much ok, because Dustman thing can be built in 4-5 hours and cost almost nothing, while doing severe impact as informational warfare.

A little about agent application, a little because as fact there is nothing interesting inside. It is built as typical C++ MS runtime based application full of ineffective code unrelated to main purpose - wipe data on disk. To do this agent calls Eldos RawDisk with mentioned above license. As data to fill it uses "Down With Saudi Kingdom Down With Bin Salman" string. If agent launched without elevation it will crash with error due to its code quality, state sponsored hackers do you remember?

Pic 5. Wipe in progress.

 

WinObjEx64 v1.8.3 release

This is maintenance release. It contain only internal program changes, small bugfixes (e.g. current directory affects plugins availability in case if program restarted elevated/or as system) and little usability improvements (rescan option for system call tables dialog). No new features have been added. Unfortunately I wasn't able to test latest 20H2 builds as they apprears to be unstable and I'm having issues with their install.

Link to download
https://github.com/hfiref0x/WinObjEx64/releases/tag/v1.8.3