False Positive DBUtilDrv2.sys

[blank0824]

Description
DBUtilDrv2.sys is a vulnerable driver and more information will be added as found.

UUID: bb808089-5857-4df2-8998-753a7106cb44
Created: 2023-01-09
Author: Michael Haag
Acknowledgement: |

name: False/Positive report
about: information of https://www.loldrivers.io/drivers/bb808089-5857-4df2-8998-753a7106cb44/?query=dbutildrv2.sys is not up-to-date
title: "f/P DBUtilDrv2.sys "
labels: f/p
assignees: '-'

Description
According to Tenable and the OEM Dell.
The Website https://www.loldrivers.io/drivers/bb808089-5857-4df2-8998-753a7106cb44/?query=dbutildrv2.sys isn´t up-to-date.

To Reproduce
Steps to reproduce the behavior:

1. Go to '..VirusTotal'
2. Check the hashes yourself
3. See Screenshots

Expected behavior
Please Update those Known Vulnerable Samples, because those are from 2021 as well as the CVE from Rapid7.

Screenshots

[nasbench]

Hi @blank0824 and thanks for reporting this potential FP. From your screenshot and discussion with the Dell team there seem to be a conflict of reporting. As the rapid7 blog clearly states that both 2.5 and 2.7 were vulnerable (even though they haven’t appeared to be used maliciously yet).

The Virustotal link doesn't actually mean anything, as it only signify that AV engines do not have static sigs for it yet.

The Dell support needs to provide a better answer on what they fixed in versions 2.5/2.7 that handled that CVEs (via changelog or similar). Because as it stands from public reporting, the drivers can still be abused even if there isn't necessarily a public poc for that.

Finally, a side note on the purpose of LOLDrivers. The hashes available here are meant to be used as a guidance for users and security professionals to assess their current environment for known suspicious/malicious/vulnerable drivers.

Hope this help.

Regards.

[Firminator]

The hashes available here are meant to be used as a guidance for users and security professionals to assess their current environment for known suspicious/malicious/vulnerable drivers.

Security Professional here :) Wanted to provide some context for how this looks like in the real-world. Usually I deal with 2 or 3 real threats per day. However after adding the hashes from LODriver.io to our security solution we have to deal with ~10 additional detections for the DBUtilDrv2.sys v2.7 (SHA256 71fe5af0f1564dc187eea8d59c0fbc897712afa07d18316d2080330ba17cf009 ) file per day. This is due to legitimate Firmware or BIOS updates being applied to our fleet of 25k+ devices. This creates a lot of noise. If there is noise you can't hear clearly :) hence I reported this to Dell yesterday in hope to get clarification. Surprised that no one else opened an Issue for clarification here, given the version 2.7 was added in March 2023 and how prevalent Dell BIOS and Firmware updates are.

Because as it stands from public reporting, the drivers can still be abused even if there isn't necessarily a public poc for that.

I actually found some research yesterday where this was POC'd @ https://github.com/tandasat/recon2024_demo

We achieve this by installing DBUtilDrv2.sys (71fe5af0f1564dc187eea8d59c0fbc897712afa07d18316d2080330ba17cf009), which has the IOCTL commands to access arbitrary kernel mode addresses and is not block-listed under HVCI. This is not a security issue as Admin-to-kernel has never been a security boundary.

The author stated "This is not a security issue as Admin-to-kernel has never been a security boundary." similarly to what the Rapid7 blog already stated back in 2021:

There is no security boundary between an administrator and the Windows kernel, according to the Microsoft Security Servicing Criteria for Windows. In our analysis of CVE-2021-21551, a write-what-where vulnerability (see CWE-123) in a Dell driver, we found that Dell’s update didn’t fix the write-what-where condition but only limited access to administrative users. According to Microsoft’s definition of security boundaries, Dell’s fix removed the security issue. However, the partially fixed driver can still help attackers.

Now that we established that DBUtilv2.7 can still be used for BYOVD attacks what do we do now? Well, the Rapid7 blog has a quote from Dell stating BYOVD is not a CVE:

After careful consideration with the product team, we have categorized this issue as a weakness and not a vulnerability due to the privilege level required to carry out an attack. This is in alignment with the guidance provided in the Windows Driver Model. We are not planning on releasing a security advisory or issuing a CVE on this.

That's the reason why Dell states in their DSA-2021-152 FAQ that all BIOS and Firmware updaters including v2.5 and v2.6 have been remediated and replaced with v2.7:

The remediated version of the DBUtilDrv2.sys driver (version 2.7) ) will be installed on your system the next time you apply a remediated BIOS, Thunderbolt, TPM, or dock firmware update to your system

However as it currently stands the file is already remediated, but can still be used for BYOVD attacks... if you are admin.
In my threat model that's a non-issue for our environment.
You can't fix or remove legitimate Ring0 software (like Dell BIOS updates) from your environment. But it does create a problem with noise when the software is prevalent (like Dell BIOS updates). Take the vulnerable SpeedFan driver for example. Tha's easily removed and non-essential software. BIOS updates not so much.

On a sidenote: I found that the real vulnerable DBUtilDrv2.sys v2.6 (SHA256 4720B202C4E6DD919222FE7B1F458705C0ED1CCC17EC4BA72A31EEF8559B87C7) is not listed @ https://github.com/magicsword-io/LOLDrivers/blob/main/detections/sysmon/sysmon_config_vulnerable_hashes.xml, nor @https://github.com/magicsword-io/LOLDrivers/blob/main/detections/hashes/samples_vulnerable.sha256 and neither on the website @ https://www.loldrivers.io/drivers/bb808089-5857-4df2-8998-753a7106cb44/

For https://www.loldrivers.io/drivers/bb808089-5857-4df2-8998-753a7106cb44/ it would also help to show the version (2.5, 2.6, 2.7) of the DBUtilDrv2.sys is listed.

[N0rimaki]

And what should a Admin now do if this Driver is used and a lot of noise in tenable (or other Tools) is created?

[Firminator]

Create an exception or allow the hash (instead of blocking/alerting), and document that this is "Risk Accepted" if you can accept the risk. To determine if you can accept the risk read on :)

This particular driver DBUtilDrv2.sys v2.7 - although fixed to not be usable by standard users anymore (CVE-2021-21551) - can still be be abused by users that are admins in your domain to access HVCI protected memory and read and write to it. HVCI is the Memory Integrity protection in Windows, see https://learn.microsoft.com/en-us/windows/security/hardware-security/enable-virtualization-based-protection-of-code-integrity and the other links above).

These admins are either your legit admins in your network or are attackers that gained admin rights through privilege escalation means by exploiting other CVEs or by compromising admin accounts. You can limit exposure to this threat by reducing the number of admins :)

Or, depending on the size of your network defender team you might just need a person to look at these alerts for a while and determine if they originate from legit processes. Our logs clearly show that the parent process was Dell BIOS and Docking Station firmware updates exectuables. There were no other alerts from the same device in the same timeframe so this whole thing falls under expected "Business Application Usage". I've looked at hundreds of these.

I appreciate @Nasreddine explaining LOLDrivers' stance and think that's a perfectly fine stance. It helped me to determine that it's up to me to deal with these alerts. At the end of the day I removed the hash from our solution to minimize noise which is more important than ever in my mind.