Protecting Rugged Gear from UEFI Threats and Secure Boot Vulnerabilities

One time while attending a conference and getting ready to hop in an Uber (although it may have been a cab at the time), I was passing my luggage to be loaded in the vehicle. Perhaps it was the Las Vegas heat, coupled with being exhausted after a long conference, but I managed to drop my bag with my laptop in it. The memory of that terrible sound makes me cringe to this day. 

Photo of the actual laptop (an Apple MacBook Pro “Core 2 Duo” circa 2008)  that was damaged years ago.

And whenever I looked at the dents that remained in my Macbook, I considered getting something more rugged. I’m sure many of you have also had your share of laptop damage, and let’s not even discuss the time I spilled an entire beer into my laptop on the podcast.

Aside from really tired and clumsy commuters, there are many use cases for rugged laptops and servers. From police departments to the military to utilities, workers in the field require gear that can withstand even more than a casual drop. You can imagine a technician setting out to service a truck or field location in the middle of the night, in pouring rain, and having the laptop or tablet get dropped or fall down a flight of stairs into a puddle. Traditional gear just isn’t rated for this type of environment.

Suffice it to say that rugged gear, in proper working order, staying safe from all threats whether it be the environment or malicious threat actors, is important for many critical job functions. Our research team recently contributed to the overall safety and security of some of these devices manufactured by Getac, a company that manufactures rugged gear specifically for first responders (and the like). 

Secure Boot Vulnerability

The Eclypsium research team disclosed a vulnerability that impacts all GETAC-branded computers produced in 2016 or later (However, the certificate for the signed UEFI application was generated in 2012, see below for more information). This vulnerability allows for arbitrary code execution during boot when Secure Boot is enabled. Ensuring that protections such as Secure Boot are enabled in this environment is also critical. Threat actors could be specifically targeting the industries that most often use rugged computing devices (such as military, police, and critical infrastructure personnel). Therefore, Secure Boot can offer some further resiliency to threats that have tried to either bypass Secure Boot or implant themselves into the boot process to run malicious software before the operating system loads. Recent examples include Black Lotus, Glupteba, and Moonbounce, representing malware that has been observed in the wild attracting various parts of the UEFI subsystem to gain higher privileges and persistence.

In the case of Getac, a Signed UEFI Shell binary is included in Getac support update packages used for firmware updates. This binary is a signed version of the UEFI Shell that is not restricted and allows for memory read/write access during boot, even when secure boot is enabled. The file is signed by the “Getac UEFI CA 2012” certificate, which can be found in BIOS.

The vulnerability has been addressed by Insyde, the provider of the UEFI firmware, in Insyde Security Advisory 2023050 and assigned CVE-2023-24932. Getac also published a full advisory, crediting Eclypsium, in the security update titled “Getac Technology Corporation Statement For 2023h2 Security Update”. It is important for Getac customers to note that not only was the Insyde-SA-2023050 security vulnerability addressed, but several other Insyde security advisories were fixed as well.


Eclypsium recommends that Getac revoke all related signing certificates in UEFI (perhaps by a DBX update) and by doing so, block all signed shell versions from executing. Getac customers must install UEFI updates to all affected devices (a complete list can be found in the Getac advisory).

Eclypsium also advises that UEFI firmware and other critical software be monitored for changes. Integrity checking is essential to determine if the system may have been compromised or tampered with by malicious actors. Comparing running firmware to known good samples and to previous snapshots can provide valuable indicators of compromise.