Author: hucktech

more on Infineon TPM issue

~ hucktech ~ Leave a comment

The UK gov guidance was also recently updated, so maybe worth a re-read:
https://www.ncsc.gov.uk/guidance/roca-infineon-tpm-and-secure-element-rsa-vulnerability-guidance

https://blog.cr.yp.to/20171105-infineon.html

https://blog.habets.se/2017/10/Is-my-TPM-affected-by-the-Infineon-disaster.html
https://github.com/ThomasHabets/simple-tpm-pk11/blob/master/check-srk/check-srk.cc

https://crocs.fi.muni.cz/public/papers/rsa_ccs17

http://mickitblog.blogspot.com/2017/10/infineon-tpm-vulnerability-report-using.html

http://www.thesccm.com/configmgr-query-infineon-firmware-tpm-microsoft-advisory-adv170012/

https://sites.google.com/a/chromium.org/dev/chromium-os/tpm_firmware_update

Encryption chip flaw afflicts huge number of computers

https://dl.acm.org/citation.cfm?id=3133969

https://twitter.com/UXGaurav/status/923063487605043200

ARM IETF I-D changes from FUD to SUIT

~ hucktech ~ Leave a comment

Re: https://firmwaresecurity.com/2017/07/18/arm-ietf-id-on-iot-firmware-update-architecture/
It looks like the Internet Draft has changed from “fud” to “suit”:
https://tools.ietf.org/html/draft-moran-suit-architecture-00
The “fud” list is gone, and there is a new “suit” mailing list:
https://www1.ietf.org/mailman/listinfo/suit

A Firmware Update Architecture for Internet of Things Devices
draft-moran-suit-architecture-00
October 30, 2017

Vulnerabilities with IoT devices have raised the need for a solid and secure firmware update mechanism that is also suitable for constrained devices. Incorporating such update mechanism to fix vulnerabilities, to update configuration settings as well as adding new functionality is recommended by security experts. This document specifies requires and an architecture for a firmware update mechanism aimed for Internet of Things (IoT) devices. The architecture is agnostic to the transport of the firmware images and associated meta-data. This version of the document assumes asymmetric cryptography and a public key infrastructure. Future versions may also describe a symmetric key approach for very constrained devices.

 

xen-uefi: Instructions and tools to boot Xen in UEFI mode with TPM measurements of Xen and dom0

~ hucktech ~ Leave a comment

Instructions and tools to boot Xen in UEFI mode with TPM measurements of Xen and dom0

This repository contains tools and instructions for installing Xen and dom0 with UEFI/SecureBoot such that all critical components of Xen and the dom0 kernel get SecureBoot verified and measured into the TPM.

https://github.com/tklengyel/xen-uefi

Includes an updated Shim.

Linux Security Summit 2017 Summary

~ hucktech ~ Leave a comment

James Morris summarized the recent LSS event, excerpts below. For full message, see his original oss-security list posting.

The 2017 Linux Security Summit (LSS) was held on Sept 14th and 15th in Los Angeles, USA. It was co-located with Open Source Summit North America (previously/including LinuxCon) and the Linux Plumbers Conference (LPC). LSS is unique as a security conference as it’s dedicated to Linux and Open Source, and tends to be focused on defensive security engineering. This year we had refereed presentations, Linux kernel security subsystem updates, and BoF topics. There was also a shared day with LPC (on the 13th), where the TPMs and containers microconfs were held. We’re also seeing continued activity in TPMs (v2.0 stack developoment), integrity/boot verification, hardware-based mitigations, mobile/device, and containers. There are lots of challenges across these areas, and the materials I’ve linked from LSS and LPC are a good place to start if you’re interested in where things are at currently. There was no video this year, unfortunately, and we’ll work on making that happen for next year.

http://events.linuxfoundation.org/events/archive/2017/linux-security-summit
http://events.linuxfoundation.org/events/archive/2017/linux-security-summit/program/schedule
http://events.linuxfoundation.org/events/archive/2017/linux-security-summit/program/slides (in some cases by clicking on the session topics).

Linux Security Summit 2017 Roundup


http://www.paul-moore.com/blog/d/2017/09/linux-security-summit.html
https://tyhicks.com/2017/09/22/2017-Linux-Security-Summit-Day-1/
https://tyhicks.com/2017/09/25/2017-Linux-Security-Summit-Day-2/
https://etherpad.openstack.org/p/LPC2017_TPM
https://etherpad.openstack.org/p/LPC2017_Containers

Click to access LSS-2017-Kernel-Self-Protection-Project.pdf

Lenovo seeks CHIPSEC-savvy security intern

~ hucktech ~ Leave a comment

Lenovo’s Data Center Group (DCG) is seeking a qualified intern to join the Software Security Review Board (SSRB) team as a Junior Product Security Test Engineer (Ethnical Hacker). The SSRB is dedicated to enhancing the security of Lenovo DCG products for our customers. Projects will include configuring security test targets such as servers, storage, and networking environments; performing product security assessments; creating assessment reports; and working with global product teams to review assessment results.

– Setup, configure, and use security tools such as AppAudit, Arachni, Burp Suite Pro, CHIPSEC, nmap, Nessus, Protecode SC, and Metasploit to perform SSRB security assessments

 

https://lenovoworldwide.rolepoint.com/?shorturl=YJvM8&sourceType=PREMIUM_POST_SITE#job/ahBzfnJvbGVwb2ludC1wcm9kchALEgNKb2IYgIDQ0J3Z6ggM

 

S2E 2.0 released

~ hucktech ~ Leave a comment

Vitaly Chipounov announced the 2.0 release of S2E on the s2e-dev GoogleGroup, excerpts of announcement below.

S2E 2.0 is a complete redesign of the old version, focusing on ease of use and speed. The advanced Python tooling lets you setup analysis projects in seconds with minimum knowledge of S2E. Everything is automated, from building guest images to writing configuration files based on the type of your binary. And if you don’t want to build S2E, there is a ready-to-run docker image that demonstrates vulnerability finding in DARPA CGC binaries, the same (almost) that we used during the competition.

Some of the major features include:
– Up to 6x faster in concrete mode than S2E 1.0
– Z3 constraint solver
– Advanced OS support including Linux guests and Windows XP, 7, 8, 10.
– Complete set of plugins for vulnerability analysis
– Integration with fuzzing
– Static x86-to-LLVM translation with Revgen

http://s2e.systems
https://github.com/s2e.

Proposal for CPython v3.x for UEFI

~ hucktech ~ 1 Comment

Thiebaud Weksteen of Google posted a message on the UEFI Forum EDK2 and Python development lists, asking for help with an official port of Python for UEFI. Please help out if you can!! Excerpt of his message below, full message (and thread):
https://lists.01.org/pipermail/edk2-devel/2017-November/016805.html

UEFI has become the standard for firmware (BIOS) interface. Intel has provided an open source implementation under the name EDK2 (part of the TianoCore initiative) [1] for some time. This implementation has evolved significantly and now provides the functionalities of a small OS with a standard library similar to POSIX. In 2011, a port of Python 2.7.1 was added to the EDK2 repository [2]. This port then evolved to 2.7.2 which is still defined as the reference port [3]. In 2015, another port was added of Python 2.7.10 in parallel of 2.7.2 [4]. Since then, both implementations have diverged from upstream and know vulnerabilities have not been fixed. I would like to bring support for edk2 in the official Python repository to remediate this situation, that is officially support edk2 as a platform. Technically, there would be three main aspects for the on-boarding work:

1) Fix headers and source to resolve definition conflicts, similarly to ABS definition in [5];
2) Add the edk2module.c [6] to handle platform-specific functionalities, similarly to the posixmodule.c;
3) Add the build configuration file [7] and necessary modifications within Python to handle the edk2 toolchain;

This work would target the master branch (that is Python 3). I would be interested in hearing your thoughts on this idea.

[1] https://github.com/tianocore/edk2
[2] https://github.com/tianocore/edk2/commit/006fecd5a177b4b7b6b36fab6690bf2b2fa11829
[3] https://github.com/tianocore/edk2/blob/master/AppPkg/Applications/Python/PythonReadMe.txt
[4] https://github.com/tianocore/edk2/commit/c8042e10763bca064df257547d04ae3dfcdfaf91
[5] https://gist.github.com/tweksteen/ed516ca7ab7dfa8d18428f59d9c22a3e
[6] https://github.com/tianocore/edk2/blob/master/AppPkg/Applications/Python/Efi/edk2module.c
[7] https://github.com/tianocore/edk2/blob/master/AppPkg/Applications/Python/PythonCore.inf

 

DriverMon: Monitor activity of any Windows driver

~ hucktech ~ Leave a comment

https://github.com/zodiacon/DriverMon

See-also:
https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/extra-tools
https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/tools-for-software-tracing
https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/index-of-windows-driver-kit-tools#tech-all
https://docs.microsoft.com/en-us/sysinternals/downloads/
https://www.osronline.com/section.cfm?section=27
https://github.com/processhacker2/processhacker

 

PoC||GTFO Issue 16 released

~ hucktech ~ Leave a comment

https://www.alchemistowl.org/pocorgtfo/

Click to access pocorgtfo16.pdf

Insyde Software security updates for Windows 10

~ hucktech ~ Leave a comment

Hurray, UEFI vendors focusing on security! 🙂

Insyde® Software Highlights Strategies to Strengthen Firmware Security at the Fall UEFI Plugfest

Company’s Chief Technology Officer to Present at The UEFI Forum Plugfest in Taipei, Taiwan

[…]In related UEFI-security news, Insyde Software announced its full compliance with the latest firmware security updates needed by Microsoft’s upcoming Windows® release. The Windows 10 Fall Creators Update adds new requirements that include improved support for TPMs (Trusted Platform Modules) and new functionality for Secure Boot BIOS update, all of which is fully supported by InsydeH2O® UEFI BIOS.[…]

https://www.insyde.com/press_news/press-releases/insyde%C2%AE-software-highlights-strategies-strengthen-firmware-security-fall

Intel TXE 3.0 security update??

~ hucktech ~ 1 Comment

Quoting an article from hexus.net:

MSI adds latest Intel TXE 3.0 security update

In order to avoid severe security vulnerabilities for the platforms, MSI motherboards now support the latest Intel Trusted Execution Engine (TXE) 3.0 for safer system protection. According to recent Intel comprehensive security review, security vulnerabilities are identified and could potentially allow attackers to gain unauthorized access to platforms features, secrets and 3rdparty secrets protected by Intel TXE. Therefore, Intel has validated and released Intel TXE 3.0 updates to address the encountered security situations. Currently all MSI 100,200 and 300 series motherboards are supporting the newest Intel TXE 3.0 by updating to the latest BIOS and installing the latest software updates. MSI always places strong emphasis on security and anti-hack issues to makes sure all MSI motherboard users are operating under the most secure circumstances. MSI will continue to provide additional updates if necessary to ensure maximum platform security protection for users.[…]

https://hexus.net/tech/items/mainboard/111626-msi-adds-latest-intel-txe-30-security-update/

[ Update: my last paragraph was wrong, removed. see Comment by reader. :-). ]

European Coreboot Conference 2017: some presentations online

~ hucktech ~ Leave a comment

Multiple PDFs from the European Coreboot Conference 2017, are already online, linked off their individual event pages, eg:

https://ecc2017.coreboot.org/schedule-location

And hopefully we can watch videos of the other presentations soon:

https://twitter.com/coreboot_org/status/924182339793678336

PS: The Coreboot event is happening in Europe nearly the same time the UEFI event is happening in Asia. I with those two firmware communities would sync their events and host them adjacently.

Firmware attacker -vs- defender job trends

~ hucktech ~ Leave a comment

A small observation: While searching for news on firmware, I have a variety of job searches, using various keywords, mostly scoped (due to tool limitations) to US-based jobs. I notice that most jobs related to firmware security are based around D.C. and require security clearance.

What concerns me is it seems the ratio is growing towards attackers, fewer related jobs by either device vendors or enterprises.

Granted vendors are hiring up all the firmware security researchers. But only a much smaller ratio of these kinds of jobs than for attacker jobs.

One good sign I have seen is a small rise in firmware security skills by enterprise sysadmins. Only a small number, but more than previously.

I wish some data scientist would do a study in attack/defense job ratios, without all the biases involved in my observations…

ReFirm Labs: IoT firmware security startup

~ hucktech ~ Leave a comment

“ReFirm Labs is at the forefront of IoT firmware security, vulnerability and zero-day discovery, and firmware remediation for IoT devices.”

https://www.refirmlabs.com/

http://i95business.com/2017/10/offit-kurman-represented-refirm-labs-1-5m-venture-capital-raise/

https://www.linkedin.com/pulse/iot-disasters-you-cannot-escape-terry-dunlap

Their “sister company” is Tactical  Network Solutions:

https://www.tacnetsol.com/

 

Fall UEFI Plugfest agenda

~ hucktech ~ Leave a comment

The Fall UEFI Plugfest is happening, a week of interop testing with UEFI vendors, along with some presentations. The presentation abstracts are below, see the full itenary for speaker bios.

http://www.uefi.org/events/upcoming

http://www.uefi.org/sites/default/files/resources/Agenda%20and%20Session%20Abstracts%20-%20Final_Oct%2024%202017.pdf

“Last Mile” Barriers to Removing Legacy BIOS (Intel)
While UEFI has become a dominant standard since its introduction in 2005, many use cases still rely on compatibility with PC/AT Legacy BIOS. These legacy corner cases are a barrier to completing the transition to modern firmware standards. Intel has identified maintaining compatibility as an issue for platform security and validation costs, and plans to eliminate legacy BIOS elements in our 2020 data center platforms. This session discusses “last mile” gaps for 16-bit compatibility and identifies UEFI capabilities that the industry can promote as alternatives, including HTTPS Boot, OS Recovery, and Signed Capsule Update.

UEFI Firmware – Security Concerns and Best Practices (Phoenix)
(no Abstract)

Strategies for Stronger Software SMI Security in UEFI Firmware (Insyde)
Avoid design errors and software coding pitfalls when implementing SMI handlers. Device manufacturers customize UEFI firmware using new runtime interfaces that are implemented using software SMIs. Heavy customization, tight deadlines and poor code implementation can accidentally allow malware to abuse the power of SMM. This session focuses on four common software SMI vulnerabilities and how to change your UEFI firmware and applications to avoid them.

Advances of UEFI Technologies in ARM Systems (ARM)
This session will discuss the ARM-related interfaces defined in the latest UEFI and ACPI specifications, the requirements of the UEFI and ACPI interfaces for the SBBR Specification, and the use of UEFI SCT and FWTS in the SBBR compliance test. Also, discussed will be the required UEFI interfaces for the embedded space when the separation of the device and OS development is desired.

Introduction to the Self-Certification Test (SCT) in UEFI World (Canonical and Intel)
The UEFI Test Working Group (UTWG) endorses two test suites: Firmware Test Suite (FWTS) and the UEFI Self-Certification Test (SCT). FWTS is focused on validating Linux compatibility, and is endorsed by UTWG for ACPI validation. The UEFI SCT is designed to validate firmware and driver behavior per the UEFI Specification. This session demonstrates the operation of both tools, and discusses how they use open source models to improve test quality.

Firmware Test Suite Introduction: Uses, Development, Contribution and GPL (Canonical)
Firmware Test Suite (FWTS) is the recommended ACPI 6.1 Self-Certification Test (SCT). This command line tool is easy to use and provides explanatory and informative. Its open-source nature allows developers to add new tests easily, and many code examples such as ACPI, UEFI and SMBIOS are available for references. Code contribution are appreciated and technical discussion and code reviews on the mailing list are answered by an active community. As licensed by GPL, FWTS ensures it is available and suitable to everyone who wants to use it publicly and privately.

NFC and UEFI (AMI)
NFC is a technology that has permeated many aspects of everyday life. Using NFC, you can now pay with your phone or enter secure building areas. However, the UEFI specification lacks any implementation of NFC. AMI will cover a proposed solution for NFC implementation in UEFI, how to best fit NFC into the UEFI specification, and potential use cases.

Edk2 Platforms Overview (Linaro)
For a couple of years now, the Linaro OpenPlatformPkg repository has been used to collate a number of (at least partially) open source EDK2 platform ports. However, with a now properly defined process for the TianoCore edk2-platforms and edk2-non-osi repositories, these platforms are now moving over there and OpenPlatformPkg. This session will discuss the process, the current state of things and the practicalities of working with edk2-platforms.

UEFI Manageability and REST Services (HPE and Intel)
With the increase in platform firmware complexity and capabilities, there is an increased need to standard firmware manageability is increasing. The UEFI 2.7 Specification defines REST services to provide secure solutions for managing modern platforms. This session describes enterprise configuration scenarios, discusses implementation gaps in the UEFI specification, and proposes enhancements related to vendor-specific REST services.

Alex Matrosov joins NVIDIA!!

~ hucktech ~ Leave a comment

This is great news for NVIDIA security!!

Also anyone from ARM Ltd must be quite excited to see recent career paths of ex-CHIPSEC Project members. Alex and Yuriy of Eclypsium has an ARM port of CHIPSEC, which they says they they’re going to release (when!?!). Now Alex is joining Nvidia and will also be focusing on ARM. Note to the Linaro team working on the AArch64 port of LUV-live, once CHIPSEC works on ARM, you really need to get this project active again.

I hope the CHIPSEC team, and or (ARM Ltd, Linaro, Eclypsium, or now NVIDIA) helps update the CHIPSEC Project’s release of CPython. Today it is a binary-only release for x86 and x64, in the Github source tree. It’ll need ARM versions of CPython, and hopefully make CPython build for CHIPSEC transparent, or at least sign the blobs. Actually, this points out an upstream problem to Tianocore: CHIPSEC is an example of an ISV with a UEFI app that needs CPython, and has to ship it themselves. Tianocore should consider shipping CPython binaries along with ShellPkgBin binaries.

PS: I also just noticed that their book has a nice (new?) domain name: http://bootkits.io/ (no HTTPS).