Intel engineering data breach: including firmware internals

Apparently the dump includes info on: Intel ME, Intel FSP, and “Lots of other things”…

https://del.dog/onufumerap.txt

https://www.theregister.com/2020/08/06/intel_nda_source_code_leak/

Microsoft offers UEFI Secure Boot DBX guidance

Microsoft has a new Knowledgebase Article on UEFI SecureBoot DBX certs:

On July 29, 2020, Microsoft published security advisory 200011 that describes a new vulnerability that’s related to Secure Boot. Devices that trust the Microsoft third-party Unified Extensible Firmware Interface (UEFI) Certificate Authority (CA) in their Secure Boot configuration may be susceptible to an attacker who has administrative privileges or physical access to the device. This article provides guidance to apply the latest Secure Boot DBX revocation list to invalidate the vulnerable modules. Microsoft plans to push an update to Windows Update to address this vulnerability after further testing in 2021.[…]

https://support.microsoft.com/en-ph/help/4575994/microsoft-guidance-for-applying-secure-boot-dbx-update

https://uefi.org/revocationlistfile

There really should be more technical information provided about the revoked/otherwise bad certs in the DBX files.

uefi-code-defn: a third UEFI plugin for Visual Studio Code

Re: https://firmwaresecurity.com/2019/11/23/edk2-vscode-visual-studio-code-plugin-for-edkii-files/ and https://firmwaresecurity.com/2019/10/01/musupport-a-vs-code-extension-to-support-project-mu/:

there is a third UEFI plugin for Visual Studio Code, from Abhishek Sharma of Microsoft:

This is a VS code extension which helps points to definition of keywords in the UEFI code like PCDs, GUIDs, etc.

https://github.com/unkemptArc99/uefi-code-defn

BootHole: GRUB UEFI Secure Boot vulnerability.

In case you’ve not been reading the news, a vulnerability has been found in GRUB:

https://eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/
https://lists.gnu.org/archive/html/grub-devel/2020-07/msg00034.html
https://www.kb.cert.org/vuls/id/174059
https://www.kb.cert.org/vuls/id/174059
https://ubuntu.com/security/notices/USN-4432-1
https://cyber.gc.ca/en/alerts/grub-security-advisory
https://access.redhat.com/security/vulnerabilities/grub2bootloader
https://access.redhat.com/errata/RHSA-2020:3217

fujitsu-redfish-samples: Fujitsu iRMC Redfish Scripting Samples

New Python Redfish samples beyond the ones in Fujitsu’s project. Half a dozen scripts, including one that does a BIOS update.

Sample Python scripts to manage Fujitsu integrated Remote Management Controller (iRMC) via Redfish in Fujitsu Server PRIMERGY.

https://github.com/mmurayama/fujitsu-redfish-samples

See-also:

https://github.com/fujitsu/fujitsu-ansible-irmc-integration
https://support.ts.fujitsu.com/IndexDownload.asp?SoftwareGuid=CED64CAE-A20C-494E-91FE-66ADAD0DBFD2
https://support.ts.fujitsu.com/IndexDownload.asp?SoftwareGuid=85DBC785-B759-4CDE-A1D3-C335B5EC7C1D

There are a few blog posts on Fujitsu Redfish here:
http://mmurayama.blogspot.com/search?q=redfish

A Modular End-to-End Framework for Secure Firmware Updates on Embedded Systems

By: Solon Falas, Charalambos Konstantinou, Maria K. Michael

[…]In this paper, we present a framework for secure firmware updates on embedded systems. The approach is based on hardware primitives and cryptographic modules, and it can be deployed in environments where communication channels might be insecure. The implementation of the framework is flexible as it can be adapted in regards to the IoT device’s available hardware resources and constraints. Our security analysis shows that our framework is resilient to a variety of attack vectors. The experimental setup demonstrates the feasibility of the approach. By implementing a variety of test cases on FPGA, we demonstrate the adaptability and performance of the framework. Experiments indicate that the update procedure for a 1183kB firmware image could be achieved, in a secure manner, under 1.73 seconds.

https://arxiv.org/abs/2007.09071

Intel/ARM/Microsoft/Apple platform security checklists: overlaps and gaps?

So, there are a handful of tools for checking for hardware/firmware security issues. Each tool has a separate list of security checks, half of which are publicly-viewable. With gaps from some hardware and OS vendors. I’m wondering how much overlap there is between these security lists, that might be useful to port and find additional security issues.

* Intel has CHIPSEC, for testing the hardware and firmware for security issues. It works on Intel x86 and Intel x64, not AMD AMD64. It works on Mac, Windows, and Linux, and UEFI. Public can run this on their own device.

https://github.com/chipsec/chipsec/wiki/Vulnerabilities-and-CHIPSEC-Modules

* ARM has SBSA-ACS, for testing hardware and firmware security issues.It works on ARM AArch64 ‘enterprise’ devices. Unclear if there is a technical distinction for non-enterprise AArch64 device use. Not AArch32. It works on UEFI. Intended for vendor use on development machines, not consumer devices (“To prevent the leakage of secure information, it is strongly recommended that the ACS test suite is run only on development platforms. If it is run on production systems, the system should be scrubbed after running the test suite.”).

https://github.com/ARM-software/sbsa-acs/blob/master/docs/testcase-checklist.md

* Apple has eficheck for macOS. It works on Intel x64, and I am guessing that it’ll also work on future ARM processors. The list of security tests it makes is unknnown, the documentation is lacking.

* Microsoft has Defender AV (which has UEFI support) for Windows.  I presume (but do not know) it works on all ISAs that Windows does, so maybe coverage on Intel, AMD, and ARM. The list of security tests it makes is unknnown, the documentation is lacking.

* AMD has nothing. Except for Microsoft Defender (for Windows users only).

* Linux has nothing. Except for Intel CHIPSEC on Intel systems.

I wonder about the delta between these 4 security lists. I wish there was more information from Microsoft and Apple on the specific tests their tools make. Are there any from one list that should also be tested on the other lists, and vice versa? Obviously, some entries are platform-centric, but there are others that might not be.

Any professors out there: please suggest a grad student do some research on the Intel and ARM security lists. Thanks.

FWTS ported to RISC-V

Re: https://firmwaresecurity.com/2016/05/08/uefi-ported-to-risc-v/

Atish of Western Digital is using FWTS to test the RISC-V port of UEFI on Linux.

http://lists.infradead.org/pipermail/linux-riscv/2020-July/001248.html

https://wiki.ubuntu.com/FirmwareTestSuite

Colin of Canonical has updated FWTS to have a RISC-V port.

Potential Verified Boot support in Barbara IoT (new OS)

There is a relatively-new operating system called “Barbara IoT”, based out of Madrid Spain, which is new to my daily “Verified Boot” searches.

Their security page mentions “verified boot”. Given the vagueness of their web site, I can’t say if this is Linux/Android/Chrome Verified Boot or something else. Unclear what flavor(s) of platform firmware the OS interacts with.

“Raise the security level of your devices with verified boot, data encryption and no exposed network services”

Have not found the source to the OS yet, I’m guessing closed-source. Their web site is pretty closed: it requires you to submit name/email contact info to view any data on their OS. Their home page link to their Developers page is broken.

https://barbaraiot.com/

security

View at Medium.com

“Raise the security level of your devices with verified boot,”

IBM: Policy-based governance in a trusted container platform

IBM has a new article discussing how they secure their cloud, discussing security technologies such as TPM, Intel TXT, and Intel BootGuard:

 

Policy-based governance in a trusted container platform

Project uses Intel Security Libraries for Data Center (Intel SecL-DC), a library that discover, attest, and utilize Intel security features, to enable critical cloud security and confidential computing use-cases.

https://01.org/intel-secl

IETF draft-richardson-secdispatch-idevid-considerations-01: Security and Operational considerations for manufacturer installed keys and anchors

[There was a time when I had bandwidth to read all new IETF RFCs and I-Ds that came out each day. Sigh…]

There is a new IETF Internet Draft from the “anima Working Group” about storing private keys in embedded devices. Sandelman Software Works and Huawei Technologies are authors. There are other documents from this working group as well.

This document provides a nomenclature to describe ways in which manufacturers secure private keys and public trust anchors in devices.

https://datatracker.ietf.org/doc/draft-richardson-secdispatch-idevid-considerations/

https://datatracker.ietf.org/wg/anima/about/
https://datatracker.ietf.org/wg/anima/documents/
https://tools.ietf.org/wg/anima/

Efi-memory, EfiDump, and EFI_Driver_Access

There are multiple OS-level drivers which provide interfaces to UEFI via device drivers. CHIPSEC has one (actually 3), for Mac, Windows, and Linux. FWTS has one for Linux. Each UEFI-aware OS has their own driver-level code to interact with UEFI, some of them expose an API/DDI. Below are 3 other UEFI drivers. A secure OS should be checking for any drivers who interact with firmware, and have a user policy for optionally preventing this. Do you know all the tools and drivers in your OS which interacts with firmware?

Efi-memory: Efi-memory is a proof-of-concept EFI runtime driver for reading and writing to virtual memory. It uses EfiGuards method of hooking SetVariable to communicate with the user-mode process.

https://github.com/SamuelTulach/efi-memory

EfiDump: Yet another PoC EFI runtime driver. This time for direct process memory read/write. This is a simple example of how can process dumper work. If you want to use this for some more complex project, please add memory checks (or you are going to be bluescreening every 5 minutes) and save the Windows kernel exports pointers in the driver once, so you don’t have to send them every time.

https://github.com/SamuelTulach/EfiDump

EFI_Driver_Access: Efi Driver Access is a simply project to load a driver during system boot with the idea to give the user kernel access for read/write memory without restrictions.

https://github.com/TheCruZ/EFI_Driver_Access

HPE Hack Shack Redfish Challenge: Redfish lab/competition

There are 3 versions, IPython/Jypter-style for Bash, PowerShell, or Python.

[…]providing the instructions and the response form for the HPE Discover Virtual Experience Hack Shack Redfish Challenge[…]DMTF’s Redfish is a standard designed to deliver simple and secure management for converged, hybrid IT and the Software-Defined Data Center (SDDC). Today it is rapidly replacing proprietary protocols. In this hands-on workshop, you’ll get to explore the Redfish tree of an OpenBMC and HPE iLO 5 to understand its basic structure, and learn how to modify resources and perform simple actions. You’ll interact with the HTTP/JSON-based standard using your favorite language, whether it’s PowerShell, Python or Bash/cURL. Beginners and experts welcome. Login to My Agenda above and Reserve or Waitlist session to notify us of your interest. Please note, this session will take place in Zoom and we will email you joining instructions.

user=”student”
Password = “P@ssw0rd!”

https://github.com/HPEDevCom/RedfishChallenge

https://hackshack.hpedev.io/

https://content.attend.hpe.com/go/agendabuilder.sessions/?l=1043&sid=20482_0&locale=en_US

Raytheon: Electronic Armor Trusted Boot (EA-TB) (and Boot Shield)

Raytheon sells a few products with different firmware security features: Trusted Boot, Secure Boot, and Measured Boot. Their EA-TB whitepaper was just revised, ACAICT.

EA-TB offers an integral solution for cyber resiliency and technology protection. The EA Trusted Boot Solution EA-TB is a hardware-based foundation for ensuring secure boot and runtime integrity for commercial off-the-shelf (COTS) processors such as Intel-, ARM- and PowerPC-based systems. EA-TB defends against boot-level attacks and kernel/application modification, and protects against attackers gaining persistence on a system. It can also be deployed with Electronic Armor Operating System (EA-OS).[…]

Warning: first URL is a PDF which includes SPACEs in the filename. Ugh. Why didn’t W3C do more to discourage this sort of behavior?

Click to access 4500615_RIS_Electronic%20Armor%20Trusted%20Boot_v13.pdf


https://www.raytheonintelligenceandspace.com/capabilities/products/electronic-armor
https://www.raytheonintelligenceandspace.com/news/feature/get-bus

see-also: Boot Shield
https://www.raytheonintelligenceandspace.com/capabilities/products/boot-shield
https://www.raytheonintelligenceandspace.com/news/feature/fighting-hardware-hack

also-see-also: CounterVail
https://www.raytheonintelligenceandspace.com/capabilities/products/countervail

Anatomy of a Boot, a QEMU perspective

Have you ever wondered about the process a machine goes through to get to the point of a usable system? This post will give an overview of how machines boot and how this matters to QEMU. We will discuss firmware and BIOSes and the things they do before the OS kernel is loaded and your usable system is finally ready.[…]

https://www.qemu.org/2020/07/03/anatomy-of-a-boot/

Getting-Started-With-ACPI: A quick explainer on ACPI

This is a nice introduction to how people hack ACPI to get macOS working on non-Mac systems (Hackintosh). Includes breakdown of how various hardware components (CPU, EC, I2C, USB, IRQ, etc.) between different Intel processor revisions.

So what are DSDTs and SSDTs? Well, these are tables present in your firmware that outline hardware devices like USB controllers, CPU threads, embedded controllers, system clocks and such. A DSDT(Differentiated System Description Table) can be seen as the body holding most of the info with smaller bits of info being passed by the SSDT(Secondary System Description Table).[…]

https://github.com/dortania/Getting-Started-With-ACPI

Industrial Control System Cybersecurity: Build It in or Bolt It On?

[…]Security begins with the modular components of the system. The first requirement for a secure module is a secure boot. No unauthorized party should be able to tamper with the software while the processor is starting up—something that cannot just be bolted on. A secure boot starts with an initial phase loaded from on-chip masked ROM, so it must be built into the microprocessor silicon. Numerical cryptokeys that authenticate, decrypt, load, and start additional levels of encrypted software are stored in this secure memory. A secure ICS must be able to start up and to decay in a secure state. Intentional or unintentional power cycling must not degrade the level of cyber protection and cybersecurity. A secure boot of every system-wide microprocessor is essential to meeting this requirement.[…]

https://blog.isa.org/industrial-control-system-cybersecurity-build-bolt