How to Use Uptycs’ Audit & Detection Features During BootHole Remediation

SecOps and IT administrators have seen plenty of information regarding the GRUB2 BootHole vulnerability. In addition to BootHole, several low to moderate vulnerabilities were also discovered and fixed. While a key recommendation for mitigation is to install OS updates and patches, vendor patches should be carefully tested and incrementally applied to vulnerable assets. Updating the Secure Boot Forbidden Signature Database (dbx) has caused issues in the past. Initial GRUB2 patches from Red Hat caused boot issues for some RHEL and CentOS machines.

There are three phases in BootHole remediation:

Pre-patch
Patch GRUB2 and related OS packages
Update UEFI revocation list

As users are trying to figure out the process, platforms like Uptycs can help keep an eye on GRUB2 configuration files. While there are no known BootHole exploits (yet), it’s good security hygiene to track changes to GRUB2-related configuration.

Audit

As a part of security auditing across your asset inventory, it’s a good practice to track your package inventory. By default, Uptycs seed profiles (default query packs) gather Debian (deb_packages) and RPM packages (rpm_packages) from all enrolled assets every few hours. Uptycs simplifies the process of taking inventory of the various versions of GRUB2 and other relevant packages. Users can take advantage of the reporting feature to create visual sections for various OS flavors and package versions. The data sets from the queries can be transformed into insightful burn-down charts that can help monitor and track the progress of asset patching.

BootHole-related packages and version information on a RHEL asset. (See larger version of image.)

Detection

Until all the assets are patched, it is critical to keep track of changes to GRUB configuration files. Osquery File Integrity Monitoring (FIM) and Event/Alert rules can help with this. FIM profiles like the following can be created and assigned to vulnerable assets.

2-fim

BootHole file integrity monitoring in Uptycs.

But osquery FIM events will capture any and all file events for the above configured directories and files. While the assets are being updated, this can generate excessive noise. Uptycs events and alert rules can help exclude noise. A simple rule like the following can generate alerts if GRUB configuration files are modified by users or exploits. The rule excludes events related to GRUB2 patches being applied by yum or apt processes.

3-event

Example of a rule that generates alerts if GRUB configuration files are modified by users or exploits.

In addition to the above, customers can also use osquery tables like augeas, file, hash to keep tabs on GRUB2 configuration files. A scheduled query pack can be created to gather configuration file content, metadata, and checksums. For a given asset, a previous value can be compared with a current value to detect drifts. File carving can also help to extract configuration files from the assets and analyze them remotely.

There is no augeas lens for GRUB2 configuration, but using the Uptycs osquery agent, contents of grub2.cfg can be extracted using motd or other generic lenses. The following query can extract every line from /boot2/grub2/grub.cfg along with the length of each line.

SELECT *, length(value)
FROM AUGEAS
WHERE lens = 'motd'
      AND path = '/boot/grub2/grub.cfg'

GRUB2 configuration file contents and line length for each line. Queried using augeas lens. (See larger version of image.)

The final step in the BootHole patching procedure is updating the UEFI revocation list. During this process, vendor signing key/certificates are added to the revocation list (dbx). Vendors use new key/certificates for signing packages trusted by the SecureBoot process (Debian). In the Uptycs osquery agent we added the efivars table to query EFI firmware variables. Users can query the efivars table to retrieve dbx information and identify if the revocation list has been updated or not. The updated revocation list can be confirmed by the presence of SHA-256 signatures of revoked certificates in the dbx data column on patched machines.