Episode 189
Manage episode 356897381 series 2423058
Overview
This week we dive into the BlackLotus UEFI bootkit teardown and find out how this malware has some roots in the FOSS ecosystem, plus we look at security updates for the Linux kernel, DCMTK, ZoneMinder, Python, tar and more.
This week in Ubuntu Security Updates
111 unique CVEs addressed
[USN-5739-2] MariaDB regression [00:48]
- Affecting Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
- Latest point release had various memory and performance regressions
[USN-5883-1] Linux kernel (HWE) vulnerabilities [01:05]
- 19 CVEs addressed in Xenial ESM (16.04 ESM)
- 4.15 kernel backported from 18.04LTS to 16.04ESM
- sysctl stack buffer overflow discussed last week plus a range of other kernel vulns
[USN-5884-1] Linux kernel (AWS) vulnerabilities [01:26]
- 6 CVEs addressed in Xenial ESM (16.04 ESM)
- 4.4 GA kernel from 16.04
[USN-5882-1] DCMTK vulnerabilities [01:36]
- 10 CVEs addressed in Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
- libraries and utils for handling DICOM (Digital Imaging and Communications in Medicine) image files (used for radiology etc)
- various memory corruption issues -> DoS / code execution
[USN-5885-1] APR vulnerability [02:29]
- 1 CVEs addressed in Jammy (22.04 LTS), Kinetic (22.10)
- Integer overflow -> memory corruption -> DoS / code exec
[USN-5886-1] Intel Microcode vulnerabilities [02:44]
- 4 CVEs addressed in Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
- latest upstream release from Intel
- Various issues in SGX and out-of-band management - particularly on Intel Xeon processors - allow require privileged access in the first place (ie admin) but could allow to then say bypass SGX protections and the like
[USN-5887-1] ClamAV vulnerabilities [03:27]
- 2 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
- latest upstream point release - 0.103.8
- one in HFS+ and the other in the DMG parsers - both different filesystem formats for Apple
[USN-5889-1] ZoneMinder vulnerabilities [03:49]
- 13 CVEs addressed in Xenial ESM (16.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS)
- Video surveillance software system - includes a web interface so has usual types of issues and then some
- Various XSS issues plus a stack buffer overflow in handling of username / passwords as would use a fixed size buffer for these (what year is this?) and a upload file handling issue resulting in possible remote code execution
[USN-5890-1] Open vSwitch vulnerabilities [04:27]
- 2 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
[USN-5891-1, USN-5894-1] curl vulnerabilities
- 3 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
- 3 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM)
[USN-5892-1] NSS vulnerabilities
- 2 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
[USN-5893-1] WebKitGTK vulnerabilities [04:34]
- 1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
- type confusion in webkit - Apple says that they had seen reports that this had been actively exploited in the wild
[USN-5896-1] Rack vulnerabilities
- 2 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS)
[USN-5895-1] MPlayer vulnerabilities
- 10 CVEs addressed in Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
[USN-5897-1] OpenJDK vulnerabilities [04:55]
- 2 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
- openjdk 11 (aka lts), 17, 18
- latest upstream point releases
[USN-5898-1] OpenJDK vulnerabilities [05:05]
- 2 CVEs addressed in Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
- openjdk 8 - also latest upstream point release
[USN-5888-1] Python vulnerabilities [05:09]
- 6 CVEs addressed in Focal (20.04 LTS)
- python3.9 - esm-apps
- high priority - vuln in multiprocessing module - if used with forkserver on Linux would allow pickles to be deserialized from any user on the same machine in the same network namespace - therefore as one local user can easily get code execution as another user on the same machine
[USN-5899-1] AWStats vulnerability
- 1 CVEs addressed in Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
[USN-5901-1] GnuTLS vulnerability
- 1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
[USN-5902-1] PHP vulnerabilities
- 3 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
[USN-5821-3] pip regression
- 1 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
[USN-5903-1] lighttpd vulnerabilities
- 2 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
[USN-5638-4] Expat vulnerabilities
- 2 CVEs addressed in Trusty ESM (14.04 ESM)
[USN-5900-1] tar vulnerability [06:15]
- 1 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
- 1-byte OOB read - although as yet no evidence this can be used to gain control flow hence really only a possible DoS
[USN-5880-2] Firefox regressions [06:42]
- 15 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)
- 110.0.1 - biggest regression was that if chose to clear recent cookies it would clear all cookies - plus a webgl crash when running under vmware on Linux
Goings on in Ubuntu Security Community
BlackLotus UEFI bootkit teardown [07:23]
- https://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/
- https://github.com/Wack0/CVE-2022-21894
- Teardown of the first in-the-wild UEFI bootkit that bypasses UEFI Secure Boot by eset
- Appears to be BlackLotus which has been sold on hacking and criminal forums since atleast October 2022
- At that time no sample was available so security researchers could not verify the claims of the malware author, namely:
- very small - only 80kb, has anti-debug / obfuscation to help avoid RE
- bypasses Windows UAC + Secure Boot and can load unsigned drivers
- disables HVCI (hypervisor protected code integrity - a feature designed to protect the Windows kernel from modification at runtime), BitLocker and Windows Defender
- persists in UEFI and is able to protect itself from being unloaded
- uses a signed boot loader so can work on machines with Secure Boot enabled
- Of these, the most interesting part for Linux users is the UEFI Secure Boot bypass - this is something which we theorised was possible via all the previously disclosed shim and grub vulnerabilities
- And in particular, they way they go about this is by using a copy of
shim
andgrub
- but not because they are exploiting any vulnerabilities in them, but since they are very useful components if you want to boot your own bootkit - they also exploit a vulnerability in the Windows Boot Manager UEFI binary which allows them to subvert the Secure Boot process and load their own code to bypass Secure Boot and gain persistence on future boots
- they way they do this is to install their own UEFI binaries into the EFI partition (including
shim
andgrub
) - but also a copy of a vulnerable version of the Windows Boot Manager UEFI binary plus their own custom boot configuration data - and since they have disabled BitLocker already these will happily be loaded at next boot without the usual integrity checks etc - when the machine reboots, their vulnerable Windows Boot Manager binary is loaded, along with their custom boot configuration data which allows them to exploit the vulnerability and to then load additional binaries into the boot process
- those binaries then go on to modify the secure boot configuration by enrolling a new key in the machine owners keyring (aka MOK) db
- normally enrolling a new key like this would require a system admin to be physically present to confirm the operation - but since they bypasses the normal Secure Boot protections this can be done without any knowledge of the sysadmin
- their
grub
is signed using this key whilst theshim
is Red Hat’sshim
- unmodified and signed by Microsoft and hence trusted - this will then trust their maliciousgrub
as it is signed by the key they just enrolled in the MOK - whilst their
shim
is an unmodified copy, theirgrub
is not - and is actually malicious shim
then goes on to boot this maliciousgrub
which starts Windows but also installs a bunch of UEFI memory hooks to be able to subvert further stages of the boot process and eventually Windows itself
- And in particular, they way they go about this is by using a copy of
- There are lots more details in the teardown article, particularly about how the various components are installed into Windows and how they are able to then load additional drivers etc into Windows, plus the further components of the malware that are able to download additional binaries, how the C2 and anti-analysis etc works - but this is the USP so we won’t cover those here
- But what is interesting for Linux is that this is reusing components that were ostensibly designed to boot Linux on machines that were originally designed to boot Windows
- one member of our team wondered if Microsoft might become more hesitant about signing
shim
in the future - perhaps, but it is not reallyshim
that is at fault here - the issue is the original vulnerability in the Windows Boot Manager -shim
just helps to make loading additional parts of their bootkit easier (along withgrub
) - so hopefully Microsoft don’t go down that path - and the reason this can be exploited in the first place is that Microsoft have not revoked their vulnerable Windows Boot Manager binary
- back in the original BootHole vulns, various
shim
’s did get revoked - but revoking this Microsoft binary would mean many older systems may fail to boot, including their recovery images and install media etc - ideally Microsoft would revoke this to stop further exploitation
- back in the original BootHole vulns, various
- one member of our team wondered if Microsoft might become more hesitant about signing
- Another interesting wrinkle is that their UEFI exploit apparently appears to come directly from a PoC that was uploaded to Github in August 2022 - will likely restart the usual discussions around public PoCs being a “bad thing” as they can be used for actual malicious purposes
- interesting to note the PoC has had additional code added to it in the last 24 hours which allow it to operate on older versions of Windows 10
- even more reason for Microsoft to perhaps revoke this old binary
Get in contact
217 قسمت