Episode 189

Posted on Friday, Mar 3, 2023
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.

Show Notes

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]

[USN-5884-1] Linux kernel (AWS) vulnerabilities [01:26]

[USN-5882-1] DCMTK vulnerabilities [01:36]

[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]

[USN-5890-1] Open vSwitch vulnerabilities [04:27]

[USN-5891-1, USN-5894-1] curl vulnerabilities

[USN-5892-1] NSS vulnerabilities

[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

[USN-5895-1] MPlayer vulnerabilities

[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

[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

[USN-5638-4] Expat vulnerabilities

[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]

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 and grub - 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 and grub) - 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 the shim is Red Hat’s shim - unmodified and signed by Microsoft and hence trusted - this will then trust their malicious grub as it is signed by the key they just enrolled in the MOK
    • whilst their shim is an unmodified copy, their grub is not - and is actually malicious
    • shim then goes on to boot this malicious grub 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
  • 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 really shim 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 with grub) - 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
  • 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