This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Community Hub.
Attestation: Another tool for Tactics, Techniques, and Procedures
Ensuring that a platform is healthy and trustworthy is a fundamental vertical in today’s zero trust approach, and this has become one of the key focus areas of recent times. Pre-OS boot continues to remain a prime target for adversaries, which we have seen attacks due to supply chain trust brittleness. Firmware remains critical to any platform provider and often with minimal view and control. These programs control the flow of execution before the operating system takes control and can be used to bypass Anti-virus, monitoring, Host intrusion prevention systems, etc. In the recent Microsoft-commissioned study showing how attacks against firmware are outpacing investments targeted at stopping them, the August 2022 Signals report showed that more than 80% of enterprises have experienced at least one firmware attack in the past two years.
One of the overlooked tools in TTP for any IT admin, Sec Operations admin, security researcher, app developer is device attestation and how it can help detect and respond to some of these attacks. To help our customers and partners be more secure we are now releasing an update to our existing Azure Attestation service to start supporting Key attestation along with support for Integrity Measurement Architecture for Linux.
Let’s look at some attack scenarios and how attestation helps defend against them.
UEFI Boot kit-based bypass detection
Lojax which was a recent malware observed to successfully infect the UEFI firmware and load itself as an EFI process, which is the core of a boot process. The malware could also survive an operating system reinstall; with an altered UEFI the attacker can have full control over the device. In addition to gaining access to resources, the attacker can potentially compromise other computers on the network as well. This means data on the computer or network it is connected to can be stolen or hijacked for the attacker’s own use.
Measured boot which records the steps taken during boot along with remote attestation can be used to detect and respond to such a threat. Device attestation which uses the measured boot logs to perform validation can be updated with an attestation policy to look at all EFI drivers loaded during the boot along with names, file hash and signatures. A successful or failure of attestation based on the desired policy can help in protecting organizations from such bypasses and attacks.
Attesting to loaded drivers loaded during boot can help in protecting from pre-boot malicious drivers. Here is a snippet of the policy that produces the list of all loaded modules during boot.
Vulnerability exposures on Linux:
The Boot hole vulnerability which has a high CVSS score could be exploited to interfere with the boot process and control how the operating system (OS) is loaded, bypassing security controls on Linux. Grand Unified Bootloader (GRUB) that loads and transfers control to the OS in most Linux distributions was impacted by this which is a buffer overflow vulnerability that exists in the way that GRUB2 parses content from the GRUB2 configuration file. The GRUB2 config file usually isn't signed like other files and executables and as a result can be changed without due validations. A resultant of this flow is an attacker could change the contents of the GRUB2 config file and take advantage of buffer overflow to run malicious code before the OS is loaded. An attacker could not only install drivers to gain even higher privileges and persist on the device but also change the security parameters passed to the kernel.
Attesting to validate the GRUB configuration file and kernel cmdline can help ensure the grub config file loaded is the same as expected by the system administrator and the kernel booted with the expected parameters. Here is a snippet of the policy that issues a claim(validgrubcfg) when the measurements contain the grub configuration file measurement.
Token Theft
In the same 2022 Aug Signals report, attacks on credentials/identity theft are on the rise where attackers are looking to dismantle the trust model itself. Along with MFA and passwordless authentication, a hardware bound credential makes it harder for attackers to steal credentials. Making it a primary requirement in today’s ecosystem. Key attestation is the ability to prove to a relying party that a private key was generated, managed, and is bound in a non-exportable manner to a valid hardware cryptographic module (TPM) can address the concerns. Proof of Possession token binding can also help protect long-lived tokens from theft and replay by cryptographically binding access tokens to a more durable artifact.
Key attestation gives you more confidence that the keys you use in your app are stored in a device's hardware-backed keystore. Here is a snippet of the attestation token that contains the tpm key to be verified by your relying party for specific key attributes, for example the below attribute value contains the fixedTPM, fixedParent and sensitiveDataOrigin among others. These attributes are important to prove that the key was generated in the TPM and cannot be exported.
More information about the attributes can be found in the Trusted Computing Group’s TPM spec.
Start using attestation to protect your assets
The purpose of an attestation statement is to provide untampered and verifiable proof, certifying something took place or the lack of it. In the world of security this has evolved to provide a comprehensive device health attestation statement which one can leverage to assess the integrity of the platform. What’s new this time around is the capability to do key attestation and support for Integrity Measurement Architecture (IMA) on Linux, which opens attestation to be used by even more apps and services.
Learn more about Attestation here to quickly get set up for attestation, be it platform health, boot/root kit detections, credential protections, etc.