In May 2021, a set of five vulnerabilities in Dell computer drivers collectively tracked as CVE-2021-21551 was disclosed and fixed after it remained exploitable for 12 years.
However, Dell’s fix wasn’t comprehensive enough to prevent additional exploitation, and as security researchers warn now, it is an excellent candidate for future Bring Your Own Vulnerable Driver (BYOVD) attacks.
“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,” explains Rapid7 researcher Jake Baines.
“However, the partially fixed driver can still help attackers.”
What’s BYOVD
BYOVD is the abbreviation for “Bring Your Own Vulnerable Driver,” an attack technique in which threat actors install a legitimate but vulnerable driver on a target machine.
This vulnerable driver is then exploited to elevate privileges or execute code on the target system.
It is a known technique that has been widely deployed in the wild for many years. Unfortunately, even though Microsoft has attempted to mitigate the issue with stricter Windows DSE (Driver Signature Enforcement) rules, the problem persists.
There are at least four open-source exploits enabling actors to load unsigned drivers onto the Windows kernel, and one of them, KDU, supports over 14 driver options.
Based on that alone, and without even accounting for custom tools authored by sophisticated actors and used privately and exclusively, it becomes clear that BYOVD is a permanent threat.
The Dell problem
Dell’s ‘dbutil_2_3.sys’ driver, which is the driver that is vulnerable to CVE-2021-21551, can facilitate BYOVD attacks, and as Rapid7 researchers warn, this applies to recent driver versions too.
The write-what-where condition persists in dbutildrv2.sys 2.5 and 2.7, so attackers have a total of three signed driver candidates for kernel code execution.
To exploit the vulnerability, threat actors will already need administrator privileges, which may make it silly to be concerned about this vulnerability.
However, advanced threat actors can use this vulnerability to execute code in kernel mode, or ring 0, which is the highest privilege level possible in Windows.
With this level of access, threat actors can deploy UEFI rootkits, hide exploitation and rootkit artifacts, or perform almost any command they want in Windows. Ultimately, advanced threat actors can conduct attacks that are highly resistant to detection, allowing them to remain resident on devices for months, if not longer.
The researchers developed a Metasploit module that implements an LSA protection-subversion attack using the later (2.5 and 2.7) versions of the Dell driver, which is demonstrated in the video below.
“An attacker with escalated privileges can use the module to enable or disable process protection on arbitrary PID,” explains Rapid7’s report.
“The Dell drivers are especially valuable because they are compatible with the newest signing requirements issued by Microsoft.”
To add to the problem, these later driver versions are unlikely to get blocked and will remain available for targeted, stealthy exploitation.
Source: Rapid7
Addressing the problem
According to Rapid7, threat actors are still limited to exploiting dbutil_2_3.sys, so versions 2.5 and 2.7 aren’t being abused yet.
However, the researchers believe this is only a matter of time now, so additional detection and mitigation efforts are required.
Rapid7 contacted Dell on the issue, and as the vulnerability already requires administrator privileges, the computer maker responded with the following statement:
“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.”
However, as threat actors can still use the drivers to gain ring 0 access, Rapid7 advises admins to implement the following security measures to block malicious drivers from loading on their system:
- Utilize Microsoft’s driver block rules (not currently including the Dell drivers)
- Use the three hashes for 2.3, 2.5, and 2.7 on a third-party EDR solution
- Enable the Hypervisor-Protected Code Integrity (HVCI)
Finally, consider submitting the vulnerable drivers to Microsoft to apply pressure for their inclusion in the blocklist.
Source: www.bleepingcomputer.com