Defensive firmware talks in Seattle: SASAG and BSides Seattle

There are two presentations in Seattle area on firmware security in January and February, in case you’re in the area.

1) On January 11th, PreOS Security CEO Paul English speaking on enterprise firmware defensive tools and techniques, for a SysAdmin target audience, at SASAG, the Seattle Area SysAdmin Guild (monthly user group).

SASAG: Firmware Security Defense

Thursday, Jan 11, 2018, 7:00 PM

Brian’s office
1111 3rd Ave #2500, Seattle, WA 98101 Seattle, WA

17 Systems Administrators Went

Paul English & Lee Fisher of PreOS Security will talk about firmware security. For attackers, platform firmware is the new Software. Most systems include hundreds of firmwares – UEFI or BIOS, PCIe expansion ROMs, USB controller drivers, storage controller host and disk/SSD drivers. Firmware-level hosted malware, bare-metal or virtualized, is nearly…

Check out this Meetup →


2) On February 3rd, I’ll be speaking at BSides Seattle, on similar topic, but for a target audience of DFIR/blue teams.

Disclaimer: Paul and I both work at PreOS Securty.


sysadmin slides from last night

As mentioned earlier:

Last night I gave a talk on UEFI firmware security for a sysadmin POV. This presentation was my first attempt at trying to gather the various hardware lifecycle models into one place, and start adding NIST firmware-centric platform lifecycle as well as currently-available firmware vulnerability assessment an forensic tools to accomplish these new tasks. The models are not well integrated yet. I’ll be giving an improved version of this talk next month at, and will try to have the model section more clearly written.

On the QEMU/OVMF slide, I say “no danger of bricking hardware”. …I should clarify that. 🙂 By that I meant using fully virtualized environment, there’s no hardware to break. However, you can also use QEMU/OVMF to debug actual hardware (eg, USB devices, PCI cards, etc.), since QEMU can proxy some requests to direct hardware. ….so, you could potentially ‘brick’ some hardware (eg, USB devices, PCI cards, etc.) with QEMU/OVMF, if you’re doing tricky things, and not careful.

NISTs 147 has basic guidance, as well as some ‘extra’ guidance for organizations that want to do more, like keeping a ‘golden image’ of the firmware. (When I first read the 147 spec, I thought the Provisioning stage was a stage for the OEM/IBV and their CAs, not for an enterprise sysadmin…) As I understand it, any ‘golden image’ would be source code, not precompiled firmware ROM binaries. I presume NIST spec was written in to an abstract model, where firwmware sourcecode is fully-available. I presume some governments and large companies would be able to obtain the full source of their firmware from the ISA/OEM/IHV vendors, and do a ‘golden image’. For the rest of world, we have nearly 100% closed-source IBV code, so you can’t do this ‘golden image’-based extra level of guidance.
On Intel systems, the Intel Firmware Support Package (FSP) contains binary-only code (‘blobs’) that UEFI and coreboot use to work on modern Intel systems; unless you have the FSP source, I don’t think an org could do the NIST 147 ‘golden image’ stuff. Some ARM systems, and perhaps AMD with it’s AGESA firmware package, might have more chance at fewer blobs. Fully Open Source Hardware/Firmware/Software-based stacks would enable ‘golden image’, so FOSS has one advantage at NIST 147 support than closed source HW/FW/SW. So Novena and any Libreboot-based system would be good, any modern Intel-based system (including Purism) will not be able to do ‘golden image’ provisioning. Pragmatically, I think the best most of us can do today for the NIST 147 Provisioning stage is run CHIPSEC/FWTS tests against it, and use CHIPSEC or other tools to capture the ROM, and that ROM.bin will be as close as you can get to a ‘golden image’.
Similarly, in the Recovery phase, I’m not sure that most orgs would be able to restore a system with a ROM dump today, without more tool documentation. Instead, I presume any ROM updates are going to be coming from your vendor, using the UEFI update mechanism. If your vendor’s update tools has the ability to ‘roll-back’ to an old image, you’re lucky.

I’d love to get feedback from sysadmins and other vendors about errors in the presentation, hopefully before, for next revision.

Beyond this talk, LegbaCore has great advise for sysadmins using MITRE Copernicus for Windows enterprises. Copernicus, unlike CHIPSEC, scales, see the LegbaCore talk from RSA 2015.

Reminder: Seattle-area sysadmin firmware talk Thursday

This SASAG talk on firmware security for system administrators is this Thursday.

It will be an attempt to integrate NIST SP147’s firmware lifecycle model with the various hardware/software models sysadmins use (Hardware Lifecycle Model, ITIL, ITAM, etc.), to better represent firmware in that model, as well as recommend some open source tools to use.

It appears I had the location confused (correct address, incorrect name) in my initial post. The SASAG post has the proper name of and a Google Maps pointer to the event location:

Stamatatos Lab, 2211 Elliot Ave, 1st Floor, Seattle WA

Seattle-area SysAdmin firmware talk 9/10

What: Seattle Area SysAdmin Guild (SASAG) September Meeting
When: September 10, 2015, 19:00-21:00
Where: WTC-E 1st floor conference room (2211 Elliott Avenue, 6th Floor, 6S139, Seattle, WA 98121)
Why: Defending Intel UEFI systems from firmware attackers

In this talk, we’ll give an overview of the open source firmware security tools you can use to help detect ‘bootkits’, ‘firmworms’, and other firmware-level malware (as well as other defects and system failures), as well as some ideas how you might integrate firmware security into your long-term maintenance plan. Tools include: CHIPSEC, UEFITool, UEFI Firmware Parser, and some others discussed in this blog. (I’m not sure about the location, I think it’s the Washington Trade Center.) Unlike most talks on this topic, this talk will target system administrators, not security researchers.