Yesterday I gave a presentation at Bsides Seattle on defending firmware. This version of the presentation attemped to address DFIR audience, not just SysAdmin/Site Reliablity Engineer audience.
I got some interesting feedback on IR after this presentation, we’ll do a blog on this in the next few days. As well as a few updates to existing IR standards to showcase where firmware is lacking.
Below is copy of slides:
There are 4 sections, Threats, Tech, Tools, and Guidance. The Tech section is probably weakest to read without having an audio. This talk was result of trying to jam a 4-hour training session into a 1-hour talk, the Tech section lost the most from this compression.
Bsides didn’t record audio/video of their event.
I updated the slides from yesterday, the “DIY Homework” section focused on following along with the analysis in the old Intel ATR blog post on the Wikileaked Hacking Team UEFI malware blob. However, that blog URL is no longer around.
If you know of any online archives of these URLs, please leave a Comment on this blog post, thanks!
This is the best-fit replacement for missing above URL, and it includes some new content (eg, blacklist command) that original blog did not. Save a copy of the blog post, I don’t expect it to be archived:
New or Updated Modules:
* Updated X64 Python for UEFI Shell
New or Updated Functionality:
* Updated FREG definitions
* Added mmap support to kernel module and chipsec device
* Fixed memory reads with kernel 4.8+
* Fixed version display in chipsec_util
* Fixed UEFI Shell X64 calling convention for SW SMI generation
* Fixed range check in bios_wp
* Fixed P2SB register accesses
* Fixed IOCTL_WRMMIO for x86_64 in Linux driver
Above relnotes aside, there are some other smaller features not listed above, in the changelog:
I wish the CHIPSEC team signed their binary-only release of CPython 2.7x for UEFI, and/or included their build tree of the EDK2 that generates this, so we can build our own, hopefully ‘reproducably’.
I don’t see any ARM support. Obviously, the title of below blog post was wrong, it was not released at Black Hat, AFAICT. Was this patch lost in Las Vegas? Is the ARM code a non-McAfee patch by Eclypsium that won’t be upstreamed into the GPL’ed CHIPSEC codebase? I wish I knew…
WOW! I just heard that Alex and Yuriy have left Intel Advanced Threat Research (McAfee) and have started Eclypsium, Inc.
Alex Bazhaniuk is the “Founder and VP of Technology at Eclypsium, Inc.”
Yuriy Bulygin is the “Founder and CEO at Eclypsium, Inc.”
Good news: the Intel Advanced Threat Research (ATR) team has release some of their UEFI security training materials!
This repository contains materials for a hands-on training ‘Security of BIOS/UEFI System Firmware from Attacker and Defender Perspectives’. 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.
0 Introduction to Firmware Security
1 BIOS and UEFI Firmware Fundamentals
2 Bootkits and UEFI Secure Boot
3 Hands-On Platform Hardware and Firmware
4 System Firmware Attack Vectors
5 Hands-On EFI Environment
7 System Firmware Forensics
N Miscellaneous Materials
Thanks to a friend for pointing this out to me, something I had not noticed.
Intel ATR has a new github project which hosts the whitelist database that CHIPSEC uses:
I wish more user-mode security researchers would study how OEM/IBV/OSV implementations of UEFI firmware update, from the OS-present appplication, looking for problems. For example: https://firmwaresecurity.com/2016/06/05/asus-liveupdate-of-uefi-sent-authenticated/
* tools.uefi.whitelist – The module can generate a list of EFI executables from (U)EFI firmware file or extracted from flash ROM, and then later check firmware image in flash ROM or file against this list of [expected/whitelisted] executables
* tools.uefi.blacklist – Improved search of blacklisted EFI binaries, added exclusion rules, enhanced blacklist.json config file
* tools.smm.rogue_mmio_bar – Experimental module that may help checking SMM firmware for MMIO BAR hijacking vulnerabilities described in “BARing the System: New vulnerabilities in Coreboot & UEFI based systems” (http://www.intelsecurity.com/advanced-threat-research/content/data/REConBrussels2017_BARing_the_system.pdf) by Intel Advanced Threat Research team at RECon Brussels 2017
* tools.uefi.uefivar_fuzz – The module is fuzzing UEFI Variable interface. The module is using UEFI SetVariable interface to write new UEFI variables to SPI flash NVRAM with randomized name/attributes/GUID/data/size.
* Debian packaging support
* Compiling in setup.py and automated loading of chipsec.kext kernel module on macOS
* Internal Graphics Device support including software DMA via Graphics Aperture
* Improved parsing andsearch within UEFI images including update capsules
* Export of extracted EFI firmware tree in JSON format
* Export of CHIPSEC results in JSON format via –json command-line argument
* EFI (de-)compression ported from uefi-firmware-parser project
* Decompression to macOS helper to parse Mac EFI firmware images
* Support of command-line arguments in chipsec_util.py
* SMI count command
* Improved platform dependent Flash descriptor parsing
* ReadWriteEverything helper to work with RWE driver
* map_io_space to improve SPI read performance on Linux
* Native (OS based) access PCI, port I/O and CPU MSR to Linux helper
* Improved chipsec_util.py unit testing
See full announcement for list of bugfixes.
CHIPSEC already has a Blacklist command. Now there is a UEFI whitelist command.
“EFI firmware malware is a new frontier for stealth and persistent attacks which may be used by sophisticated adversaries to penetrate and persist within the organization’s and national infrastructure for very long time. Use open source CHIPSEC to defend from this threat and stay safe.”
Thomas Roccia write a new blog post on watching how malware detects VM’s virtualized hardware/firmware resources, including a defensive POC and a pointer to a similar tool.
Stopping Malware With a Fake Virtual Machine
As we explained in a previous post, some advanced malware can detect a virtual environment such as a sandbox to avoid detection and analysis. Some threats can also detect monitoring tools used for malware analysis. Often such malware will not execute or change their behavior to appear harmless. Because some malware uses these tactics, planting fake virtual machine artefacts or fake analysis tools on a system could stop their malicious behavior. We have created a quick proof of concept (POC) to demonstrate this defensive tactic. […] A lot of registry keys are created by specific tools or by sandbox emulation. Using the Windows API RegCreateKeyEx we can create all the (fake) keys normally created by a virtual hypervisor. The following list shows of few of the potential registry keys that malware can detect:
HKLM\HARDWARE\DEVICEMAP\Scsi\Scsi Port 0\Scsi Bus 0\Target Id 0\Logical Unit Id 0\“Identifier”;“VMWARE”
HKLM\SOFTWARE\VMware, Inc.\VMware Tools
HKLM\SOFTWARE\Oracle\VirtualBox Guest Additions
Intel CHIPSEC is — or at least was — Intel-specific. Actually it may be called McAfee CHIPSEC now? Anyway, it did not work on ARM. Via Linaro, ARM Ltd. was in the process of porting LUV (Linux UEFI Validation) distro to AArch64, and LUV includes CHIPSEC, so that was on the list, but AFAIK Linaro had not yet started to port CHIPSEC to ARM yet.
So the above screenshot is news to me, and very exciting. I hope we get more news about this soon!! AND a source check-in (currently nothing in repo)… 🙂
Proof-of-concept module for Xen XSA-188 (https://xenbits.xen.org/xsa/advisory-188.html)
CVE-2016-7154: “use after free in FIFO event channel code”
Discovered by Mikhail Gorobets
This module triggers host crash on vulnerable Xen 4.4
“chipsec_main.py -m tools.vmm.xen.xsa188“