Author: hucktech

Firmware Test Suite 17.02.00 released

~ hucktech ~ Leave a comment

Alex Hung of Canonical announced the 17.02.00 release of FWTS, with new EFI and ACPI support. As well, IBM has been contributing some OpenPOWER support and it appears there is work to make an OpenPOWER version of FWTS-live.

One thing I recently noticed for FWTS: the UEFI Secure Boot tests are hard-coded only to work with Ubuntu’s Secure Boot key. I hope some other Linux distros add some distro-centric Secure Boot tests, beyond the Ubuntu test.

New Features:
  * ACPICA: Update to version 20170119
  * acpi: s3: Add new –s3-resume-hook option
  * Add README_JSON.txt for FWTS
  * klog.json: Add some more kernel messages to klog data base
  * klog.json: Add some EFI driver kernel messages to klog database
  * klog.json: Add some EFI quirk driver kernel messages to klog database
  * klog.json: Add some more EFI driver kernel messages to klog database
  * klog.json: Add some miscellaneous messages to klog database
  * Integrate PPC for FWTS-LIVE Frontend
  * fedora: Add fedora internal versioning number in fwts.spec
  * fedora: Add fwts.spec.in
  * fedora: Update buildsrpm.sh for dynamic versioning
  * fwts_framework: handle -? option differently from -h

See the full announcement for list of bugfixes.
https://launchpad.net/ubuntu/+source/fwts
http://fwts.ubuntu.com/release/fwts-V17.02.00.tar.gz
https://launchpad.net/~firmware-testing-team/+archive/ubuntu/ppa-fwts-stable
https://wiki.ubuntu.com/FirmwareTestSuite/ReleaseNotes/17.02.00

NIST SP 1800-7: Situational Awareness for Electric Utilities

~ hucktech ~ Leave a comment

NIST just released some guidance for electical grid …and it includes one entry on securing firmware!

“The NCCoE released a draft of the NIST Cybersecurity Practice Guide, SP 1800-7 “Situational Awareness for Electric Utilities” on February 16, 2017.  Public comments on the draft will be expected through April 17, 2017. Submit your comments.”

“To improve the security of information and operational technology, including industrial control systems, energy companies need mechanisms to capture, transmit, analyze and store real-time or near-real-time data from these networks and systems. With such mechanisms in place, energy providers can more readily detect and remediate anomalous conditions, investigate the chain of events that led to the anomalies, and share findings with other energy companies. Obtaining real-time and near-real-time data from networks also has the benefit of helping to demonstrate compliance with information security standards.”

“5.1.1.17PR.DS-6: Integrity checking mechanisms are used to verify software, firmware, and information integrity”

https://nccoe.nist.gov/projects/use_cases/situational_awareness

more on SCONE

~ hucktech ~ Leave a comment

Re: SCONE, mentioned here: https://firmwaresecurity.com/2017/01/07/secure-linux-containers-with-intel-sgx/

 

SCONE: Secure Linux Containers with Intel SGX
Sergei Arnautov, Bohdan Trach, Franz Gregor, Thomas Knauth, Andre Martin, Christian Priebe, Joshua Lind, Divya Muthukumaran, Dan O’Keeffe, Mark L Stillwell, David Goltzsche, Dave Eyers, Rüdiger Kapitza, Peter Pietzuch, Christof Fetzer

In multi-tenant environments, Linux containers managed by Docker or Kubernetes have a lower resource footprint, faster startup times, and higher I/O performance compared to virtual machines (VMs) on hypervisors. Yet their weaker isolation guarantees, enforced through software kernel mechanisms, make it easier for attackers to compromise the confidentiality and integrity of application data within containers. We describe SCONE, a secure container mechanism for Docker that uses the SGX trusted execution support of Intel CPUs to protect container processes from outside attacks. The design of SCONE leads to (i) a small trusted computing base (TCB) and (ii) a low performance overhead: SCONE offers a secure C standard library interface that transparently encrypts/decrypts I/O data; to reduce the performance impact of thread synchronization and system calls within SGX enclaves, SCONE supports user-level threading and asynchronous system calls. Our evaluation shows that it protects unmodified applications with SGX, achieving 0.6✓–1.2✓ of native throughput.[…]

https://www.usenix.org/conference/osdi16/technical-sessions/presentation/arnautov

Click to access osdi16-arnautov.pdf

Click to access osdi16_slides_knauth.pdf

GRUB 2.02 in the works…

~ hucktech ~ Leave a comment

See the FOSDEM slides for some of the features listed in the Phoronix article.

http://www.phoronix.com/scan.php?page=news_item&px=GRUB-2.02-RC1-Features

https://fosdem.org/2017/schedule/event/grub_new_maintainers/

Click to access slides.pdf

http://alpha.gnu.org/gnu/grub/grub-2.02~rc1.tar.gz

Rootkits and Bootkits book update

~ hucktech ~ 1 Comment

https://www.nostarch.com/rootkits

Table of Contents
Chapter 1: Observing Rootkit Infections
Chapter 2: What’s in a Rootkit: The TDL3 Case Study (NOW AVAILABLE)
Chapter 3: Festi Rootkit: The Most Advanced Spam Bot (NOW AVAILABLE)
Chapter 4: Bootkit Background and History (NOW AVAILABLE)
Chapter 5: Operating System Boot Process Essentials (NOW AVAILABLE)
Chapter 6: Boot Process Security (NOW AVAILABLE)
Chapter 7: Bootkit Infection Techniques (NOW AVAILABLE)
Chapter 8: Static Analysis of a Bootkit Using IDA Pro (NOW AVAILABLE)
Chapter 9: Bootkit Dynamic Analysis: Emulation and Virtualization (NOW AVAILABLE)
Chapter 10: Evolving from MBR to VBR Bootkits: Olmasco (NOW AVAILABLE)
Chapter 11: IPL Bootkits: Rovnix & Carberp (NOW AVAILABLE)
Chapter 12: Gapz: Advanced VBR Infection (NOW AVAILABLE)
Chapter 13: Rise of MBR Ransomware (NOW AVAILABLE)
Chapter 14: UEFI Boot vs. the MBR/VBR Boot Process (NOW AVAILABLE)
Chapter 15: Contemporary UEFI Bootkits
Chapter 16: UEFI Firmware Vulnerabilities
Chapter 17: How Secure Boot Works
Chapter 18: HiddenFsReader: Bootkits Forensic Approaches
Chapter 19: CHIPsec: BIOS/UEFI Forensics

VUSec: Reverse Engineering Page Table Caches in Your Processor

~ hucktech ~ Leave a comment

https://github.com/vusec/revanc

https://www.vusec.net/projects/anc/

 

OnePlus bootloader vulnerabilities

~ hucktech ~ Leave a comment

 

Owning a Locked OnePlus 3/3T: Bootloader Vulnerabilities
Feb 08, 2017 • Roee Hay
In this blog post I disclose two vulnerabilities in the OnePlus 3/3T bootloader. The first one, CVE-2017-5626, is a critical severity vulnerability affecting OxygenOS 3.2-4.0.1 (4.0.2 is patched). The vulnerability allows for a physical adversary (or one with ADB/fastboot access) to bypass the bootloader’s lock state, even when Allow OEM Unlocking is disabled, without user confirmation and without triggering a factory reset. This vulnerability allows for kernel code execution (albeit with a 5 seconds warning upon boot). The second vulnerability, CVE-2017-5624, affecting all versions of OxygenOS to date (Feb 10 UPDATE: OxygenOS 4.0.3, released Feb 09, seems to be patched), allows the attacker to disable dm-verity. The combination of the vulnerabilities enables a powerful attack – persistent highly privileged code execution without any warning to the user and with access to the original user’s data (after the victim enters his credentials). Both issues were responsibly disclosed to and acknowledged by OnePlus Security. The first vulnerability, CVE-2017-5626, was reported on January 23rd. It was also found independently by a OnePlus engineer. CVE-2017-5624, reported on January 16th, should be fixed in a future OxygenOS release – the reason for its today’s public disclosure is because someone already published it on January 24th. Disclaimer: I tested the vulnerabilities on OnePlus 3 only, but OnePlus 3T contains the vulnerable code too.[…[

https://securityresear.ch/2017/02/08/oneplus3-bootloader-vulns/

https://oneplus.net/3t

 

Raptor Engineering seeks funds for OpenBMC port

~ hucktech ~ Leave a comment

Raptor Engineering is asking for crowdsource funding to help them port OpenBMC to an ASUS system:

“Make coreboot a first-class citizen in the datacenter on modern, blob-free hardware.”

https://www.raptorengineering.com/coreboot/kgpe-d16-bmc-port-offer.php

dual-booting FreeBSD or Windows

~ hucktech ~ Leave a comment

Kevin Bowling has an article that shows how to setup a UEFI system to work with FreeBSD — including ZFS on root — and another UEFI OS like Windows.

https://www.freebsdnews.com/2017/01/23/freebsd-uefi-root-zfs-windows-dual-boot-kevin-bowling/

https://bsdmag.org/freebsd_uefi_root/

I’m not sure if this article is an improved version of or just a rebroadcast of:

http://kev009.com/wp/2016/07/freebsd-uefi-root-on-zfs-and-windows-dual-boot/

 

CHIPSEC gets efi_compressor

~ hucktech ~ Leave a comment

 

https://github.com/chipsec/chipsec/pull/152

https://github.com/chipsec/chipsec

(I haven’t looked at this patch yet, but I hope it’s a Python native version, since CHIPSEC used Linux/Windows/UEFI native versions of external compress/decompress tools, and it would be nice to have a pure Python version, compression and decompression. If you want to better trust CHIPSEC,in addition to reviewing it’s source code, you also have to deal with the compress/decompress blobs and CPython for UEFI blobs that it ships, and have to build your own versions. I think I noticed a few Microsoft Windows Win32 .exe files embedded inside that UEFI CPython release, which should not be there.)

 

Mozilla Corporation abandons IoT project

~ hucktech ~ Leave a comment

As expected, Mozilla has canceled their IoT project:

“This experiment has concluded.”

https://wiki.mozilla.org/Connected_Devices
https://wiki.mozilla.org/Connected_Devices/Participation

No press on the Mozilla press site in months, however:
https://blog.mozilla.org/press/

http://www.computerworld.com/article/3165465/internet-of-things/mozilla-zaps-residue-of-firefox-os-as-it-shutters-iot-group.html
http://www.zdnet.com/article/firefox-os-is-dead-mozilla-kills-off-open-source-iot-project-with-50-layoffs/
https://internetofbusiness.com/mozilla-iot-lays-off-staff/

https://learning.mozilla.org/blog/exploring-the-internet-of-things-with-mozilla

Mozilla Launches Open Source Support Program

Google on fuzzing PCIe

~ hucktech ~ Leave a comment

https://twitter.com/revskills/status/830102871077224448

Fuzzing PCI express: security in plaintext
By Julia Hansbrough, Software Engineer

Google recently launched GPUs on Google Cloud Platform (GCP), which will allow customers to leverage this hardware for highly parallel workloads. These GPUs are connected to our cloud machines via a variety of PCIe switches, and that required us to have a deep understanding of PCIe security. Securing PCIe devices requires overcoming some inherent challenges. For instance, GPUs have become far more complex in the past few decades, opening up new avenues for attack. Since GPUs are designed to directly access system memory, and since hardware has historically been considered trusted, it’s difficult to ensure all the settings to keep it contained are set accurately, and difficult to ensure whether such settings even work. And since GPU manufacturers don’t make the source code or binaries available for the GPU’s main processes, we can’t examine those to gain more confidence. You can read more about the challenges presented by the PCI and PCIe specs here. With the risk of malicious behavior from compromised PCIe devices, Google needed to have a plan for combating these types of attacks, especially in a world of cloud services and publicly available virtual machines. Our approach has been to focus on mitigation: ensuring that compromised PCIe devices can’t jeopardize the security of the rest of the computer. Fuzzing to the rescue[…]

https://cloudplatform.googleblog.com/2017/02/fuzzing-PCI-Express-security-in-plaintext.html

Microsoft Surface Enterprise Management Mode (SEMM)

~ hucktech ~ Leave a comment

Quoting the Ars Technica story:

[…]To further increase the appeal of the Surface in constrained enterprise environments, today Microsoft is announcing Surface Enterprise Management Mode (SEMM) for Surface Pro 4, Surface Book, and Surface Studio. SEMM enables administrators with physical access to the hardware to lock out integrated peripherals such as webcam, microphone, and USB ports. This locking out is done by the firmware, disabling the devices in question, rendering them wholly inaccessible to the operating system. It’s intended as a much more elegant alternative to supergluing the ports or drilling out the cameras. SEMM is designed to allow not just static configuration, wherein the devices are disabled permanently, but also dynamic configuration that responds to the environment. For example, a SEMM system could be configured so that when it was on a classified network the USB ports and camera were disabled, but when on an open network they were re-enabled. The system uses digital signatures and certificates to manage the configurations, preventing end users from re-enabling devices that they shouldn’t have access to.[…]

https://arstechnica.com/information-technology/2017/02/no-more-superglued-usb-ports-surface-hardware-can-be-locked-down-in-firmware/

https://technet.microsoft.com/en-us/itpro/surface/surface-enterprise-management-mode

https://blogs.technet.microsoft.com/surface/2017/01/16/introducing-surface-enterprise-management-mode-and-system-center-configuration-manager-support-for-semm/

 

 

Securing Hardware: Applied Physical Attacks and Hardware Pentesting

~ hucktech ~ Leave a comment

Joe Fitzpatrick of Securing Hardware has announced a new course:

[…]This course focuses on approaching hardware as part of a pentest or red team engagement, implementing advanced hardware hacks, and managing the hardware ‘problem’. This two-day course builds directly upon the skills covered in Physical Attacks on Embedded Systems – consider taking the two together for a complete 4 days. If you’ve already taken another class that covers the basics of embedded/IOT/hardware hacking, including UART, JTAG, and SPI, you should have sufficient background.[…]

https://securinghardware.com/news/Announcing-Hardware-Pentesting-Course/

https://securinghardware.com/training/pentesting/

clr-boot-manager: Clear Linux’s UEFI boot manager

~ hucktech ~ Leave a comment

clr-boot-manager exists to enable the correct maintainence of vendor kernels and appropriate garbage collection tactics over the course of upgrades. The implementation provides the means to enable correct cohabitation on a shared boot directory, such as the EFI System Partition for UEFI-booting operating systems. Special care is taken to ensure the ESP is handled gracefully, and in the instance that it is not already mounted, then clr-boot-manager will automatically discover and mount it, and automatically unmount the ESP again when it is complete. Clr-boot-manager is designed to operate solely with GPT disks, and exclusively uses PARTUUID. Generated boot entries also contain the PARTUUID in their root= command line, as part of a merge of the vendor provided cmdline files for default options.
Copyright © 2016-2017 Intel Corporation

 

https://clearlinux.org/

https://github.com/ikeydoherty/clr-boot-manager

UK NCSC on firmware security, part II

~ hucktech ~ Leave a comment

https://twitter.com/TrapezoidSec/status/829732647467438082

Regarding:

UK National Cyber Security Center and firmware

There’s a second post:

As we noted back in November, it’s common knowledge that keeping device software up to date and securely configured is important. System firmware, on the other hand, is often overlooked. Despite being critical to the secure operation of a device, it’s frequently out of date. But how bad is the problem? How widespread? And what can be done to remedy the situation? To answer these questions we decided to put our money where our mouth is and run some simple tests on one of our research networks. The goal was gain an accurate picture of the BIOS version running on all connected devices. The results were a wake-up call. The firmware of devices running on our own network required some attention. This may be the case for you as well.[…]

https://www.ncsc.gov.uk/blog-post/firmware-ii-status-check

with some source code:

https://www.ncsc.gov.uk/file/1972/download?token=wIpTEpLO