Month: March 2018

Richard Wilkins of Phoenix on UEFI-based IoT security (and rant on firmware diversity)

~ hucktech ~ Leave a comment

Richard Wilkins  of Phoenix Technologies has an article in Embedded Computing about UEFI-based IoT security:

[…]This article is focused on system startup/firmware and the potential security problems for IoT devices in that space. And most important, what to do about them.[…]

http://www.embedded-computing.com/articles/firmware-security-for-iot-devices

PS: RANT… for some reason, one sentence jumped out at me:

“So why isn’t everyone using UEFI firmware? If the UEFI architecture provides the “solution” to these security threats, why isn’t everyone using it?”

I think the answer: UEFI is *A* solution, there are other solutions. Coreboot with Heads is another solution. Coreboot with Verified Boot is another solution. Using TXT and TPM measurements are other layers. Hypervisors/TEEs/SEEs are another layer. Separate security processors are another way. What is the right way, why isn’t everyone using one way? While I am a UEFI Forum member, I don’t think UEFI everyone should be using it. I welcome firmware diversity. 🙂 IMO, there are multiple implementations of signed code, signed updates, and a signed boot-up process, controlled by multiple (not a single) organization. I’m still hoping to see some professor gets a grad student to write a report doing a proper comparision of the various modern firmware security implementations’ strengths, so someone can start to make a reasonale decision as to which firmware security architecture is the solution for them.

Alex’s OffensiveCon slides uploaded

~ hucktech ~ Leave a comment

“My @offensive_con slides released! Include all 010 templates for Intel ACM and Boot Guard (KM + IBBM). All these details been REconstructed from AMI FW. Discovered few Intel Boot Guard bypasses: 2 SW + 1 HW. Never underestimate RE in your Threat Model!!”

Betraying the BIOS: Where the Guardians of the BIOS are Failing

For UEFI firmware, the barbarians are at the gate — and the gate is open. On the one hand, well-intentioned researchers are increasingly active in the UEFI security space; on the other hand, so are attackers. Information about UEFI implants — by HackingTeam and state-sponsored actors alike — hints at the magnitude of the problem, but are these isolated incidents, or are they indicative of a more dire lapse in security? Just how breachable is the BIOS? In this presentation, I’ll explain UEFI security from the competing perspectives of attacker and defender. I’ll cover topics including how hardware vendors have left SMM and SPI flash memory wide open to rootkits; how UEFI rootkits work, how technologies such as Intel Boot Guard and BIOS Guard (and the separate Authenticated Code Module CPU) aim to kill them; and weaknesses in these protective technologies. There are few public details; most of this information has been extracted by reverse engineering. This talk is a revisited version of the Black Hat Vegas 2017 research with new details about Intel BIOS Guard and Intel ACM’s including new vulnerabilities.

https://github.com/REhints/Publications/tree/master/Conferences/Betraying%20the%20BIOS
https://www.offensivecon.org/agenda/

Click to access Offensivecon_18%5Bv2.0%5D.pdf

Sources:
https://github.com/REhints/Publications/tree/master/Conferences/Betraying%20the%20BIOS/Intel%20Boot%20Guard%20%5BREconstructed%5D

010 editor templates:
https://github.com/REhints/Publications/tree/master/Conferences/Betraying%20the%20BIOS/010%20templates
https://www.sweetscape.com/010editor/

 

X41 D-Sec GmbH browser security whitepaper: WebUSB, WebBluetooth, WebSMM

~ hucktech ~ Leave a comment

This white paper provides a technical comparison of the security features and attack surface of Google Chrome, Microsoft Edge, and Internet Explorer. We aim to identify which browser provides the highest level of security in common enterprise usage scenarios, and show how differences in design and implementation of various security technologies in modern web browsers might affect their security. Comparisons are done using a qualitative approach since many issues regarding browser security cannot easily be quantified. We focus on the weaknesses of different mitigations and hardening features and take an attacker’s point of view. This should give the reader an impression about how easy or hard it is to attack a certain browser. The analysis has been sponsored by Google. X41 D-Sec GmbH accepted this sponsorship on the condition that Google would not interfere with our testing methodology or control the content of our paper. We are aware that we could unconsciously be biased to produce results favorable to our sponsor, and have attempted to eliminate this by being as transparent as possible about our decision-making processes and testing methodologies.

Click to access X41-Browser-Security-White-Paper.pdf

https://www.x41-dsec.de/#about

https://www.x41-dsec.de/security/report/whitepaper/2017/09/18/whitepaper-x41-browser-security/

OpticSpy: A tool to explore optical data transmissions and covert channels

~ hucktech ~ Leave a comment

https://www.crowdsupply.com/grand-idea-studio/opticspy

Uses & Application Ideas:
Search for optical covert channels that may exist in modern devices
Add data exfiltration/transfer functionality into a project
Capture/decode/demodulate IR signals from remote controls
Discover Li-Fi networks or Visible Light Communication (VLC) systems

khwasan: kernel hardware assisted address sanitizer

~ hucktech ~ Leave a comment

“Kernel HardWare-assisted AddressSANitiser (KHWASAN). It’s a much less RAM-hungry ASAN for your kernel, AArch64-only”

https://twitter.com/kayseesee/status/969681048391962624

This patchset adds a new mode to KASAN, which is called KHWASAN (Kernel
HardWare assisted Address SANitizer). There’s still some work to do and
there are a few TODOs in the code, so I’m publishing this as a RFC to
collect some initial feedback.

The plan is to implement HWASan [1] for the kernel with the incentive,
that it’s going to have comparable performance, but in the same time
consume much less memory, trading that off for somewhat imprecise bug
detection and being supported only for arm64.[…]

https://groups.google.com/forum/#!topic/kasan-dev/XXflR8Qy6g0

https://github.com/xairy/kasan-prototype/tree/khwasan

http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html

UEFI Python: CPython 3.x or MicroPython 3.4?

~ hucktech ~ Leave a comment

In the beginning, Intel maintained CPython 2.x for UEFI. Current version is 2.7x. It looks like they may have stopped porting it, I am unclear.

In addition to Intel’s CPython 2.7x port, recently Google has proposed updating CPython 3.x to support UEFI, see:

Proposal for CPython v3.x for UEFI

I may’ve missed it, but I not sure Intel is involved with this effort.

At the UEFI Plugfest later this month, Intel is giving a talk about MicroPython for UEFI, “Implementing MicroPython in UEFI”.  So I am *guessing* that Intel has chosen MicroPython over CPython. I presume this means that CPython 2.7x port is now abandonware. I hope the CPython 3.x proposal is not dead, because of this MicroPython effort. Hoping both get traction, but will not hold my breath…

https://micropython.org/
https://github.com/micropython/micropython

Differences between CPython and MicroPython:
http://docs.micropython.org/en/latest/pyboard/genrst/index.html
https://pypi.python.org/pypi?%3Aaction=search&term=micropython

Once once of these Python 3.x implementations works, and the CHIPSEC project ports from 2.x to 3.c, I can finally stop using v2!!

MicroPython Logo

 

UEFI Forum Spring 2018 plugfest agenda

~ hucktech ~ Leave a comment

The UEFI Plugfest is in Seattle later this month.

I guess I missed the CFP, as the agenda is now available… 😦

* Intel: An Introduction to Platform Security
* Phoenix: TBD
* Arm:UEFI Updates, Secure Firmware and Secure Services on Arm
* Intel: The State of ASL Programming
* Intel: Implementing MicroPython in UEFI
* Insyde Software: UEFI and the Security Development Lifecycle
* Intel: Attacking and Defending the Platform
* Microsoft: Microsoft Security Features and Firmware Configurations
* Arm: Dynamic Tables Framework: A Step Towards Automatic Generation of ACPI & SMBIOS Tables
* Microsoft: Microsoft Sample Code on GitHub and Walkthrough on Firmware Updates and WU
* Linaro: Edk2-Platforms Overview
* AMI: Enabling Advanced NVMe Features Through UEFI

http://uefi.org/SpringPlugfest2018

ShowSLIC.efi: Access ACPI-based Windows SLIC License Key

~ hucktech ~ Leave a comment

FPMurphy has a new blog post with source to a new tool, and mentions plans for 3-4 new tools/year!

Those who follow my work in the UEFI Shell space are aware that I usually develop a number of new, and hopefully useful, UEFI shell utilities each year. This year, I plan to write three or four new utilities and enhance a number of existing utilities. This is the first of these new utilities. In this post, I describe the ShowSLIC utility. It is the first of my new utilities and came about from license and booting issues caused by a disk failure on a friend’s laptop that was running Windows 7. ShowSLIC is designed to enable you to retrieve SLIC (System License Internal Certificate) information from a UEFI-based Microsoft Windows PC or laptop. Such information is accessible (exposed) via the ACPI (Advanced Configuration and Power Interface) SLIP table.[…]

https://blog.fpmurphy.com/2018/01/accessing-acpi-slic-from-uefi-shell.html#ixzz58Wq6TSMw

https://blog.fpmurphy.com/

Looks like you have to scrape the source from the HTML blog post, not included in latest UEFI-Utilities, AFAICT:

https://github.com/fpmurphy/UEFI-Utilities-2016/commits/master

DMTF Releases New PLDM for Redfish Device Enablement Specification

~ hucktech ~ Leave a comment

The DMTF has released its new Platform Level Data Model (PLDM) for Redfish® Device Enablement Specification [1] as a Work in Progress, inviting public review and comment. This standard enables a management controller to present Redfish -conformant management of I/O adapters in a server, without the need for code specific to each adapter family/vendor/model. PLDM for Redfish Device Enablement describes the operation and format of request messages (also referred to as commands) and response messages, designed to be delivered using PLDM messaging. Using Redfish, messages are generated by a Redfish client through interactions with a user or a script, and communicated via JSON over HTTP or HTTPS to a management controller. Using the new standard, the management controller will encode the message into a binary format (Binary Encoded JSON, or BEJ) and communicate it using PLDM to an appropriate device for servicing. The device processes the message and returns the response back using PLDM to the management controller, again in binary format. The management controller then decodes the response and constructs a standard Redfish response in JSON over HTTP or HTTPS for delivery back to the client. PLDM for Redfish Device Enablement is developed by the DMTF’s Platform Management Components Intercommunications (PMCI) Working Group [2], which defines standards to address “inside the box” communication and functional interfaces. It can be used in conjunction with other PMCI standards, such as the PLDM Firmware Update Specification, to provide a comprehensive, common architecture for improved communication between management subsystem components. The new WIP release is the latest example of the ongoing hard work and close collaboration between DMTF Working Groups (including PMCI, SMBIOS and SPMF) to seamlessly address both internal- and external-facing interfaces and protocols for system management.

[1] https://www.dmtf.org/sites/default/files/standards/documents/DSP0218_0.8.0a.pdf
[2] https://www.dmtf.org/standards/pmci
https://www.dmtf.org/standards/redfish
http://www.dmtf.org/standards/smbioswg
http://www.dmtf.org/standards/spmf