I am very excited to have started my new role as VP of Engineering at Eclypsium. We are building defenses for attacks targeting firmware and hardware.
— John Loucaides of Borg (@JohnLoucaides) April 18, 2018
!!!
!!!
A variety of attacks targeting system firmware have been discussed publicly, drawing attention to interaction with system firmware components. This includes operating system loaders, secure boot mechanisms, runtime interfaces, and system management mode (SMM). This training will detail and organize objectives, attack vectors, vulnerabilities, and protection mechanisms in this fascinating environment. The training includes two parts.
1. Present a structured approach to system firmware security analysis and mitigations through lecture and hands-on exercises to test system firmware for vulnerabilities. After the training, students will have basic understanding of platform hardware components, system firmware components, attacks against system firmware, and available mitigations. Students can apply this knowledge to identify firmware vulnerabilities and perform forensic analysis.
2. Apply concepts to an enterprise environment. Using an understanding of security issues, students explore potential risks to operational environments including both supply chain and remote malware attacks. Students will perform assessments and basic forensic analysis of potential firmware attacks.
[Strange, I was doing the previous blog post on Brian, and during that time, he did a new blog post…]
Brian Richardson of Intel has a new blog post on using CHIPSEC whitelist command to help with UEFI security:
Using Whitelists to Improve Firmware Security
Firmware has become more popular in the world of computer security research. Attacks operating at the firmware level can be difficult to discover, and have the potential to persist even in bare-metal recovery scenarios. This type of hack has been well documented by investigations of the HackingTeam and Vault7 exploits. Fortunately, there are methods for detecting and defending against such attacks. Firmware-based attacks typically attempt to add or modify system firmware modules stored in NVRAM. Tools provided by the open source CHIPSEC project can be used to generate and verify hashes of these modules, so users can detect unauthorized changes.[…]
https://software.intel.com/en-us/blogs/2017/12/05/using-whitelists-to-improve-firmware-security
https://github.com/chipsec/chipsec
BARing the System: New vulnerabilities in Coreboot & UEFI based systems
Yuriy and John of the Intel CHIPSEC team are quoted in a new Dark Reading article on firmware security.
[…] Yuriy Bulygin and John Loucaides, security researchers at Intel Security, point out that hackers attack firmware because they know many security and IT managers aren’t paying attention to it. They say security teams are so overwhelmed by the prevailing threat landscape, that they have their hands full just deploying the basics, like firewalls, intrusion prevention systems and sandboxes. […]
http://www.darkreading.com/iot/5-tips-for-protecting-firmware-from-attacks/d/d-id/1325604
The Intel CHIPSEC team doesn’t give training often, so when they do, it is worth mentioning.
Like last year, CHIPSEC will be offering training at REcon!
A variety of attacks targeting system firmware have been discussed publicly, drawing attention to the pre-boot and firmware components of the platform such as BIOS and SMM, OS loaders and secure booting. This training will detail and organize objectives, attack vectors, vulnerabilities and exploits against various types of system firmware such as legacy BIOS, SMI handlers and UEFI based firmware, mitigations as well as tools and methods available to analyze security of such firmware components. It will also detail protections available in hardware and in firmware such as Secure Boot implemented by modern operating systems against bootkits. The training includes theoretical material describing a structured approach to system firmware security analysis and mitigations as well as many hands-on exercises to test system firmware for vulnerabilities. After the training you should have basic understanding of platform hardware components and various types of system firmware, security objectives and attacks against system firmware, mitigations available in hardware and firmware. You should be able to apply this knowledge in practice to identify vulnerabilities in BIOS and perform forensic analysis of the firmware.
Ricardo Neri of Intel announced Linux UEFI Validation (LUV) v2.0-rc4 release, with lots of changes, new versions of CHIPSEC, BITS, FWTS, and multiple UEFI improvements in LUV. IMO, one of the most important features it that LUV-live’s CHIPSEC should properly log results now! Excerpts from Ricardo’s announcement:
This release touches many areas. Here are some highlights:
Naresh Bhat implemented changes to build from Linus’ tree when building LUV for ARM. While doing this, he got rid of the leg-kernel recipe. Now the kernel is built from linux-yocto-efi-test for all architectures. Also, he took the opportunity to remove some of the LUV-specific changes we had in the meta layer (i.e., our genericarmv8 machine). It always good to restrict ourselves to the meta-luv layer, unless we plan to upstream to the Yocto Project. Now LUV for aarch64 is built using qemuarm64.
It was reported that CHIPSEC was not running correctly in LUV due to missing configuration files and Python modules. This release includes a major rework of CHIPSEC integration into LUV. It ran correctly on all the systems in which we tested. Also, we bumped to v1.2.2; the CHIPSEC latest release.
This release includes new functionality to build BITS from its source rather than just deploying its binaries. BITS is a challenging piece of software when it comes to integration into a bitbake recipe. The build process was broken into several steps. This work help for future work to customize BITS for other CPU architectures and netboot.
The UEFI specification v2.5 includes a Properties Table for the memory map. Under this feature, it is possible to split into separate memory sections the code and data regions of the PE/COFF image. Unfortunately, kernels previous to v4.3 crash if this features is enabled. We have backported a fix pushed to Linux v4.3. We will be bumping the kernel for x86 to 4.3 in our next release.
The EFI stub feature in the kernel allows to run the kernel as an EFI application. Also, it allows the kernel to parse the memory map directly from the firmware rather than taking the map from the bootloader. This is clearly advantageous in case of bugs in the bootloader.
Now that LUV support storing the results of multiple bots, it may happen that disk runs out of space. Gayatri Kammela made updates to increase the size of the results partition and issue a warning when available space runs below 2MB.
Finally, keeping up with the latest changes in the Yocto Project has paid off handsomely. This release is based on Jethro, the latest version of the Yocto Project. Rebasing to this new version as done with very little effort. In the LUV tree you can find the jethro and jethro-next branches; the bases of this release. The fido and fido-next branches are still maintained.
We have bumped the following test suite versions:
*FTWS is now V15.12.00
*CHIPSEC is now v1.2.2
*BITS is 2005
Time to update your LUV-live images! It is a Release Candidate, so please help the LUV team by testing it out and pointing out any issues on the LUV mailing list. This version of CHIPSEC includes VMM tests, so time to test LUV-luv in your virtual machines, not just on bare-metal boxes.
Many people contributed to this release, including: Ricardo Neri, Naresh Bhat, Darren Bilby, Megha Dey, Gayatri Kammela, John Loucaides, Sai Praneeth Prakhya, and Thiebaud Weksteen. It was nice to see the LUV and CHIPSEC teams work together in this release!
More information:
https://lists.01.org/pipermail/luv/2015-December/000745.html
https://download.01.org/linux-uefi-validation/v2.0/luv-live-v2.0-rc4.tar.bz2
https://download.01.org/linux-uefi-validation/v2.0/sha256_sums.asc
Jim Walter, Director of Advanced Threat Research for Intel Security, with contributions from Yuriy Bulygin and John Loucaides, wrote a blog for Dark Reading that summarizes some recent firmware attacks.
Vulnerable From Below: Attacking Hypervisors Using Firmware And Hardware
Malicious attacks with firmware privileges can compromise an entire system, so it is especially important to apply measures to reduce the risks.
Read the full article here:
Usenix WOOT 2015 is happening in Washington D.C. later this month. It has a very interesting UEFI security talk:
Symbolic execution for BIOS security
Oleksandr Bazhaniuk, John Loucaides, Lee Rosenbaum, Mark R. Tuttle, Vincent Zimmer, Intel Corporation
May 25, 2015
We are building a tool that uses symbolic execution to search for BIOS security vulnerabilities including dangerous memory references (call outs) by SMM interrupt handlers in UEFI-compliant implementations of BIOS. Our tool currently applies only to interrupt handlers for SMM variables. Given a snapshot of SMRAM, the base address of SMRAM, and the address of the variable interrupt handler in SMRAM, the tool uses S2E to run the KLEE symbolic execution engine to search for concrete examples of a call to the interrupt handler that causes the handler to read memory outside of SMRAM. This is a work in progress. We discuss our approach, our current status, our plans for the tool, and the obstacles we face.
There might be other interesting talks happening there, but none have BIOS/UEFI/firmware in their title/abstract, so I missed them. 🙂
https://www.usenix.org/node/191950
https://www.usenix.org/conference/woot15/workshop-program/presentation/bazhaniuk
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Discover the Desktop
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
News from coreboot world
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Just another WordPress.com site
Hastily-written news/info on the firmware security/development communities, sorry for the typos.