Blog has second poster: Paul English of PreOS Security

So far, this blog has been my daily education, writing down URLs of things I learn that day. A few people also feed me interesting URLs. Paul English, co-founder of PreOS Security[1], has been giving me more and more links, so I’ve asked him to deal with them, instead of asking me to do posts on those URLs. 🙂

This is Paul’s first post:

https://firmwaresecurity.com/2018/08/01/meet-us-at-black-hat-usa-2018/

He’s also trying to help fix the WordPress-based site to be more usable. It looks like the font has already changed.

[1] https://preossec.com/

 

Meet Us At Black Hat USA 2018

Management here – we’ll be at Black Hat USA 2018.. next week. If you’ll be there, be sure and stop by our Arsenal Tools Demo Wednesday, August 8 | 2:30pm-3:50pm, Station #5.

https://www.blackhat.com/us-18/arsenal/schedule/index.html#firmware-audit-platform-firmware-security-automation-for-blue-teams-and-dfir-11359

We’ll be around before and after, attending talks and available for meetings. If you think your employer should be doing more platform firmware security, we’d love to talk! Email to set up a meeting:

blackhatusa2018@preossec.com

New ebook: Platform Firmware Security Defense for Enterprise System Administrators and Blue Teams

Yesterday was SysAdmin Appreciation Day.

PreOS Security has a new free ebook, “Platform Firmware Security Defense for Enterprise System Administrators and Blue Teams”. If you’re new to firmware security issues, this gives an introduction. Advanced readers: there’s a feedback mechanism, so please give some feedback. There’s plans for an updated book.

https://preossec.com/

https://lists.preossec.com/mailman/listinfo/newsletter_lists.preossec.com

The book includes a snapshot of the awesome-firmware-security list as an appendix: https://github.com/PreOS-Security/awesome-firmware-security

Disclaimer: I work at PreOS Security, and helped with book. Paul did most of the work: thanks Paul!

 

PreOS presentation from SeaGL online

Last week Paul English of PreOS Security gave a presentation at SeaGL Conference (spelled with the RMS-preferred prefix, “Seattle GNU/Linux Conference”, pronounced like the bird “Seagull”). The presentation was about about firmware defensive skills. Whereas my previous presentation presumed an audience of enterprise (SysAdmins, SREs, Blue Teams, or DFIR), Paul’s talk presumed an audience of end-users, with no enterprise to back them up.

Alas, with most SeaGL presentations, this presentation was not video/audio-taped. His blog post has pointer to his slides.

His blog post also mentions brief status update on the sysadmin ebook that Paul is driving, he’s nearly ready, it’ll be nice to have this resource available.

Also, note that the PreOS Security web site has been revamped. All known HTTP/HTTPS problems have been resolved, and the blog backlog is getting flushed.

https://preossec.com/SeaGL-2017/

 

UEFI slides from SOURCE Seattle uploaded

Last week I gave a presentation at SOURCE Seattle Conference, on defensive UEFI tools/guidance, mostly talking about NIST 147’s lifecycle, and how to use tools like (CHIPSEC, acpidump, FWTS) to look for signs of firmware attacks.

As I understand it, SOURCE Conference will have video of this presentation online sometime in the near future.

https://www.sourceconference.com/copy-of-seattle-2016-agenda-details

Slides have been uploaded to this blog, and are available here:.srcsea17. (PreOS Security will have an archive of all of our post-conference materials on Github shortly.)

At the conference, Bryan of the Brakeing Security podcast interviewed PreOS Security co-founder Paul English and myself, along with some other SOURCE Seattle speakers. I am not sure when that podcast is queued up for. I hate public speaking in general, but I cringe at completely unprepared interviews like this podcast. Sorry I didn’t have better concise answers to the questions put to me. I think the normal podcast drinking game is to drink whenever you hear ‘um’ or ‘I mean’. Be careful if you’re playing that game during my brief audio clips. 😦

http://www.brakeingsecurity.com/

http://brakeingsecurity.com/rss

@bryanbrake

 

A slide in the presentation pre-announces an upcoming tool we’re working on. That tool should be ready in a few weeks, more details soon.

UEFI at SeaGL

If you are the Seattle area, the Seattle GNU Linux Conference (SeaGL, pronounced “Seagull”) is happening shortly. There’re two UEFI talks, one by PreOS Security, and one by System76.

https://osem.seagl.org/conferences/seagl2017/program/proposals/374

http://seagl.org/news/2017/09/28/QA-penglish.html

https://preossec.com/

https://system76.com/

https://osem.seagl.org/conferences/seagl2017/program/proposals/326

PreOS Security releases CHIPSEC quickref for SysAdmins

[Disclaimer: I work for PreOS Security.]

CHIPSEC is a suite of dozens of tests/tools/utilities, many of which are strictly for security researchers. Timed with SysAdmin Appreciation Day, PreOS Security has created a 1-page quick reference for CHIPSEC for sysadmins. The below message also mentions an upcoming short ebook for sysadmins:

Currently this quickref is only availble by filling out a form:

https://preossec.com/free+ebook/

on the PreOS Security site, with some opt-in stuff to help the new startup.

PS: PreOS Security has joined the Twitosphere(sp), first post above. And we have a LinkedIn page. Please ‘Follow us’. Thanks!

https://twitter.com/PreOS_Security/
https://www.linkedin.com/company/preos-security

Alex updates smmtestbuildscript for Fedora 26 and QEMU 2.9

A while ago[1], Alex Floyd of PreOS Security wrote a shell script to help codify this wiki article[2] by Laslo Ersek of Red Hat, setting up a UEFI SMM/OVMF testing environment for Fedora-based systems. Recently, Alex updated this script to work with the recently-released Fedora 26. Quoting email from Alex on the changes in this release:

The build script has been updated for Fedora 26 support. It now uses the native QEMU 2.9 library from Fedora 26 and no longer builds a snapshot of QEMU 2.9 which makes some new testing possibilities available.

https://github.com/gencymex/smmtestbuildscript

[1] https://firmwaresecurity.com/2017/04/19/shell-script-for-laszlos-smm-test-environment-article/

[2] https://github.com/tianocore/tianocore.github.io/wiki/Testing-SMM-with-QEMU,-KVM-and-libvirt

 

CHIPSEC_GUI

There’s a relatively new GUI front-end to the command line-based CHIPSEC project, called CHISPEC_GUI. This GUI for chipsec 1.2.5 provides a fairly simple design but lets you select each module that you want to run. It is made with PyQt4. It is getting updated to Chipsec 1.3.0 with the appropriate module additions written into the GUI. It was originally written in Persian by Emad Helmi, and translated to English by Alex Floyd of PreOS-Security.

English version:
https://www.github.com/mex20/chipsec_gui

Forked from Persian version:
https://www.github.com/EmadHelmi/chipsec_gui

Shell script for Laszlo’s SMM test environment article

Laszlo Ersek of Red Hat wrote a wiki article on tianocore.org[1], showing how to setup the EDK2 with QEMU/OVMF for testing SMM code using Fedora.

Recently, Alex Floyd of PreOS Security wrote a shell script to codify this wiki article[2].

Laszlo’s wiki is dense, I expect this script will be useful for some UEFI firmware engineers and security researchers.

According to Alex, “some things needed tweaking to get to work, and the Windows portion of the tutorial is not included in the script.”

[1] https://github.com/tianocore/tianocore.github.io/wiki/Testing-SMM-with-QEMU,-KVM-and-libvirt

[2] https://github.com/gencymex/smmtestbuildscript

https://github.com/gencymex/smmtestbuildscript/blob/master/smmtesthost.sh

UEFI lab at Cascadia IT Conference in Seattle March 10th

[DISCLAIMER: FirmwareSecurity is my personal blog. I work at PreOS Security.]

PreOs Security is offering a half-day training lab for System Administrators, SRE/DevOps in the Seattle area at Cascadia IT Conference, for those interested in learning about UEFI/ACPI/BIOS/SMM/etc security. Here’s the text for the training:

Defending System Firmware

Target audience: System administrators, SRE, DevOps who work with Intel UEFI-based server hardware

Most enterprises only defend operating system and application software; system and peripheral firmware (eg., BIOS, UEFI, PCIe, Thunderbolt, USB, etc) has many attack vectors. This workshop targets enterprise system administrators responsible for maintaining the security of their systems. The workshop is: an introduction to UEFI system firmware, an overview of the NIST secure BIOS platform lifecycle model of SP-(147,147b,155) and how to integrate that into normal enterprise hardware lifecycle management, and an introduction to the available open source firmware security tools created by security researchers and others, and how to integrate UEFI-based systems into the NIST lifecycle using available tools, to help protect your enterprise. It will be a 3.5 hour presentation, and at the end, you can optionally can run some tests on your laptop: Intel CHIPSEC, Linux UEFI Validation distribution (LUV-live), FirmWare Test Suite live boot distribution (FWTS-live), and a few other tools. Attendees trying to participate in the lab will need to have a modern Intel x86 or x64-based (not AMD), UEFI-based firmware, running Windows or Linux OS software. That means no AMD systems, no Apple Macbooks, no ARM systems. Any system used in the lab must have all data backed up, in case some tool bricks the device. Attendees should understand the basics of system hardware/firmware, be able to use a shell (eg, bash, cmd.exe, UEFI Shell), and able to use Python-based scripts.

https://www.casitconf.org/casitconf17/tutorials/

announcing PreOS Security Inc.

FirmwareSecurity.com is my personal blog. I use it to post information about firmware as I come across it, in the hope that it might help others. I try to keep it impersonal and only focus on news/information, but my bias towards open source HW/FW/SW is not hard to find.

I started the blog a few years ago to learn firmware by focusing on the security perspective of firmware and learning from existing security researchers. I’d been doing OS-level driver consulting for a while, and was moving from OS-level moving down into firmware. Along the way, I’ve learned a lot and given talks and training on firmware security at LinuxFest Northwest, B-Sides PDX, SOURCE Seattle, and other places.

With great advice from both firmware engineers as well as firmware security researchers, I’ve seen an opportunity to help secure enterprises at the firmware level.

I’ve started a small new company, PreOS Security Inc.,  https://preossec.com/ . Besides attending the last UEFI Plugfest, we’ve been mostly in ‘stealth mode’, busy working on code. We have a small group of advisors who are teaching us lots of things about security/b2b/tool startups.

We’re creating a product to help enterprises secure their system firmware, as per NIST SP 800-147 guidance. We’re leveraging the expertise of existing firmware security researchers, and some of their tools (for example CHIPSEC). We’re also writing new tools to fill in some of the gaps. Our product is currently in a pre-alpha stage, and are looking for a few enterprises who’re eager to secure their firmware to work on the alpha release.

We have a draft document on ‘enterprise firmware guidance’ that we’ll be publishing on our web site (and Github), as well as that ‘awesome firmware’ links that I’ve been promising in previous blog posts. We have some patches to existing tools that we need to upstream.

We also offer training to UEFI/ACPI device vendor QA teams, data centers, and security-minded enterprises, on using firmware security tools, and consulting to customize/integrate these tools. We’ve got a half-day training event that we’ll announce shortly.

We need a Python developer, either as a partner, or a few as contractors. Currently we have equity to offer. For more information, see:  https://preossec.com/careers/ .

We’re currently self-funded, hoping to fund our product development with training/consulting. But to offer more than equity, we’ve begun looking at some other sources of funding. If there are any firmware-friendly angel investors reading this, we should talk.

https://preossec.com/careers/