What is BlackLotus bootkit?

BlackLotus was first spotted in October 2022. Its seller claimed that the bootkit had a built-in Secure Boot bypass, built-in Ring0/Kernel deletion protection, and also ran in recovery mode and safe mode. The malware is equipped with anti-virtualization, anti-debugging and obfuscation, which complicates its detection and analysis. Also, according to the seller, the security software cannot detect and destroy the bootkit, since it runs under the SYSTEM account inside a legitimate process.

In addition, BlackLotus is able to disable security mechanisms on target machines, including Hypervisor-Protected Code Integrity (HVCI) and Windows Defender, as well as bypass User Account Control (UAC). The payload has a size of 80 kilobytes, is written in assembler and C, and it can determine the geofence of the victim in order to avoid infecting machines in the CIS countries. Last year, the malware was offered for sale for $5,000, with each new version priced at another $200.

Later, the threat was studied by analysts from ESET. They confirmed that the bootkit easily bypasses Secure Boot and uses the Baton Drop vulnerability (CVE-2022-21894) from a year ago to gain a foothold in the system.

How does the exploit work?

It was highlighted that Microsoft fixed this issue back in January 2022, but attackers can still exploit it because the affected signed binaries were not added to the revocation list. According to analysts, BlackLotus is the first documented case of abuse of this vulnerability.

Later, Microsoft experts, during the analysis of devices compromised with BlackLotus, identified a number of features that make it possible to detect infection and described in detail possible indicators of compromise.

They also discovered that BlackLotus exploits another vulnerability, CVE-2023-24932, which is also related to bypassing Secure Boot protection. Although the bug was fixed in May of this year, this update was disabled by default, and Microsoft required Windows users to perform a very complicated manual installation of this fix.

Since the company warned that installing the patch incorrectly could cause Windows to stop starting and could not be restored even from installation media, many people chose not to install the patches, leaving devices vulnerable to attacks.

BlackLotus UEFI Bootkit Leaked to the GitHub

As Binarly experts now say, the BlackLotus source code was leaked to GitHub by a user under the nickname Yukari. He writes that the source code has been changed and no longer exploits the Baton Drop vulnerability. Instead, BlackLotus uses the bootlicker UEFI rootkit, which is based on the CosmicStrand, MoonBounce, and ESPECTRE UEFI APT rootkits.

He explains that the methods used in the bootkit are no longer new, but leaking the source code would allow attackers to easily combine the bootkit with new vulnerabilities, both known and unknown.

Since the BlackLotus UEFI Bootkit source code is now available to everyone, it is possible that with its help hackers will be able to create more powerful malware that can bypass existing and future measures to counter such threats.

The post Researchers Found BlackLotus UEFI Bootkit Sources on GitHub appeared first on Gridinsoft Blog.

Many Dell, HP and Lenovo devices use old and insecure versions of OpenSSL, as Binarly warns.

Let me remind you that we also wrote that OpenSSL Fixes First Critical Vulnerability Since 2016, and also that OpenSSL Patches Released and Critical Vulnerability Turns Out to be Not So Critical.

The problem lies in the EFI Development Kit II (EDK II) open-source environment, since EDK II comes with its own cryptographic package, CryptoPkg, which, in turn, relies on OpenSSL. As a result, according to the researchers, the firmware associated with corporate Lenovo Thinkpad devices uses three different versions of OpenSSL at once (0.9.8zb, 1.0.0a and 1.0.2j), the newest of which was released in 2018.

Moreover, one of the firmware modules (InfineonTpmUpdateDxe) does rely on OpenSSL version 0.9.8zb, released on August 4, 2014.

In addition to the OpenSSL versions listed, some Lenovo and Dell firmware also use an even older version (0.9.8l) that was released on November 5, 2009. The HP firmware code also used a 10-year-old version of OpenSSL (0.9.8w).

Binarly’s report highlights that the issue that was discovered clearly illustrates a situation where third-party dependencies significantly complicate the supply chain ecosystem, as in this case.

The post Dell, HP, and Lenovo Devices Use Older Versions of OpenSSL appeared first on Gridinsoft Blog.