Exclusive: CISA Sounds the Alarm on UEFI Security
Against the backdrop of the debacle that mitigating the BlackLotus bootkit has become, the Cybersecurity and Infrastructure Security Agency (CISA) is calling for revamped security for Unified Extensible Firmware Interface (UEFI) update mechanisms.
In a blog post published by , CISA is urging the computer industry across the board to take a secure-by-design approach to bolster the overall security of UEFI, which is the firmware that's responsible for a system's booting-up routine. It's comprised of several components — including security and platform initializers, drivers, bootloaders, and a power management interface.
"Secure-by-design is about having the organizations that design the software take responsibility for the security, and that includes the update pathways," Jonathan Spring, senior technical advisor at CISA, tells Dark Reading in an exclusive interview.
UEFI is a popular attack surface because if it's loaded with malicious code, threat actors can achieve a high level of persistence on a system, since that code will launch before the OS or any security software does. This makes it invisible to most incident response tactics and OS-level defenses, and impervious to system reboots. Spring says that the CISA's call to action is a demand for standard movement across the board to neutralize threats to UEFI by creating software and an accompanying update pathway that is inherently hardened.
"Anyone who purchases a system would have an expectation that is it secure by design and securely updateable," he says. "This is an ongoing concern."
BlackLotus and the ongoing threat related to the malware is somewhat of a poster child for the issues that can arise without a more secure update mechanism, he adds.
BlackLotus and the Trouble With UEFI Updating
BlackLotus, the first in-the-wild malware to successfully bypass Microsoft's UEFI Secure Boot implementation, was first spotted for sale on the Dark Web last fall. Right now, protection against it requires manually applying patches that Microsoft issued in January 2022 and May 2023.
But that's not all: In June, the NSA warned that applying the current patches for BlackLotus is "a good start," but does not go far enough to completely fix the problem. That's because Microsoft did not issue patches to revoke trust in unpatched boot loaders via the Secure Boot Deny List Database (DBX), giving bad actors an opportunity to simply replace fully patched boot loaders with legitimate but vulnerable versions, allowing them to execute BlackLotus.
"BlackLotus exploits a failure in secure update distribution," Spring explained in the CISA post. "BlackLotus can roll back a file to a vulnerable version and then exploit it, rendering the update distribution channel for UEFI updates on Windows not sufficiently resilient or secure."
On a related note, Spring also says that if Microsoft had used a more secure-by-design public key infrastructure (PKI) approach for UEFI along with an automated update system, the issue might well be fixed by now.
Generally in PKI management, there is one secret key, or certificate, that is kept "very secret," while other, intermediate certificates are used to sign other files, which are easy to revoke in case of a problem. However, in Windows PKI, one key signs a large number of files, so to revoke it to mitigate the BlackLotus issue "would cause a lot of collateral damage" in other parts of the OS, he says, adding, "Public key infrastructure shouldn't be signed like that."
Spring notes, "If the update distribution mechanism used appropriate PKI, I believe that those updates would have been distributed by default and the keys for the vulnerable files would have been removed by default, and we would be done."
As a result of all of this, NSA has recommended that infrastructure owners take additional manual steps to harden their systems, such as tightening up user executable policies and monitoring the integrity of the boot partition. In the meantime, Microsoft is eyeing sometime in early 2024 for an automated and comprehensive fix for BlackLotus.
"The manual mitigation is quite difficult, and I don't think everyone is going to do it," Spring says. Therefore, the CISA hopes to promote a future in which "these manual security fixes are not the norm," he says.
CISA's Specifics for Improving UEFI Update Cybersecurity
BlackLotus certainly highlights the UEFI threat landscape and can be used as a talking point to promote the development of more secure systems in the future, Spring says: "There is never a bad time to point out that all the software we use should be secure by design, that there are some ways in which it is currently not, and to encourage people to expect and build better systems so that everyone can have a lower risk of longstanding persistent malware on their systems."
To that end, CISA outlined in its post specifics on how a secure-by-design strategy, working in tandem with a mature product security incident response team (PSIRT), can jointly reinforce "a holistic security engineering solution."
These include the following efforts:
- System owners should be able to audit, manage, and update UEFI components just like any other software that is being acquired, complete with software bills of materials.
- Operational teams should expect to be able to collect, analyze, and respond to event logs that identify UEFI-related activities — such as changes, updates, and add/remove components — using UEFI-native watchdog and reporting capabilities relayed to the OS or endpoint detection and response tools as appropriate.
- UEFI component developers should use secure development environments and adopt software development best practices, just like any other software.
- The UEFI vendor community should universally adopt uninterrupted and reliable update capabilities to ensure that UEFI component updates do not burden operational communities and end users.
- With a UEFI Security Response Team (USRT) in place to provide continued leadership, the UEFI community should broaden engagement in communities to expand adoption of best practices for PSIRT operations.
Reference link
A.K
Comments
Post a Comment