Uncategorized

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/

Standard
Uncategorized

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/

Standard
Uncategorized

ACPI registry updates

It looks like there have been 3 new ACPI regisrations so far this year:

Coreboot Project     BOOT     02/28/2017
https://www.coreboot.org/

Exar Corporation     EXAR     02/28/2017
https://www.exar.com/

VR Technology Holdings Limited     3GVR     01/19/2017
http://www.3glasses.com/en/

http://www.uefi.org/acpi_id_list

Standard
Uncategorized

Microsoft updates Secure Boot and ACPI requirements

These Microsoft pages have recently (last month) been updated. No changelog, so unclear what has changed. 😦

 

https://msdn.microsoft.com/en-us/windows/hardware/drivers/bringup/secure-boot-and-device-encryption-overview

https://msdn.microsoft.com/en-us/windows/hardware/commercialize/design/device-experiences/acpi-firmware-implementation-requirements

https://msdn.microsoft.com/en-us/windows/hardware/drivers/bringup/firmware-requirements-for-d3cold

 

Standard
Uncategorized

ACPI graph support

Sakari Ailus of Intel posted a patch to the Linux-ACPI list that enables ‘ACPI graph support’. Slightly edited version of announcement below:

I posted a previous RFC labelled set of ACPI graph support a while ago[1]. Since then, the matter of how the properties should be used as in ACPI _DSD was discussed in Ksummit and LPC, and a document detailing the rules  was written [1]. I’ve additionally posted v1 which can be found here[2]. This set contains patches written by Mika Westerberg and by myself. The patchset brings support for graphs to ACPI. The functionality achieved by these patches is very similar to what the Device tree provides: the port and the endpoint concept are being employed. The patches make use of the _DSD property and data extensions to achieve this. The fwnode interface is extended by graph functionality; this way graph information originating from both OF and ACPI may be accessed using the same interface, without being aware of the underlying firmware interface. The last patch of the set contains ASL documentation including an example. The entire set may also be found here (on mediatree.git master, but it also applies cleanly on linux-next)[3]. The resulting fwnode graph interface has been tested using V4L2 async with fwnode matching and smiapp and omap3isp drivers, with appropriate changes to make use of the fwnode interface in drivers. The V4L2 patches can be found here. The fwnode graph interface is used by the newly added V4L2 fwnode framework which replaces the V4L2 OF framework, with equivalent functionality.[4]

[1] http://www.spinics.net/lists/linux-acpi/msg69547.html
[2] http://www.spinics.net/lists/linux-acpi/msg71661.html
[3] https://git.linuxtv.org/sailus/media_tree.git/log/?h=acpi-graph
[4] https://git.linuxtv.org/sailus/media_tree.git/log/?h=v4l2-acpi

Full announcement — including changes for v1 — is on the linux-acpi list:
http://vger.kernel.org/majordomo-info.html
http://www.spinics.net/lists/linux-acpi/

Standard
Uncategorized

faking virtual firmware to thwart malware authors

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\HARDWARE\Description\System\ “SystemBiosVersion”;”VMWARE”
    HKLM\HARDWARE\Description\System\”SystemBiosVersion”;VBOX
    HKLM\SOFTWARE\Oracle\VirtualBox Guest Additions
    HKLM\HARDWARE\ACPI\DSDT\VBOX__

https://securingtomorrow.mcafee.com/mcafee-labs/stopping-malware-fake-virtual-machine/

https://github.com/fr0gger/RocProtect-V1

 

 

Standard