Apple publishes whitepaper on T2 security chip

Click to access Apple_T2_Security_Chip_Overview.pdf

ZeroNights 2018: NUClear explotion

Alexander Ermolov and Ruslan Zakirov will deliver their «NUClear explotion» talk. A major and most significant approach to UEFI BIOS security is preventing it from being illegitimately modified and the SPI flash memory from being overwritten. Modern vendors use a wide range of security mechanisms to ensure that (SMM BLE / SMM BWP / PRx / Intel BIOS Guard) and hardware-supported verification technologies (Intel Boot Guard). In other words, they do everything just not to let an attacker to place a rootkit into a system. Even the likelihood of execution in the most privileged mode of a processor – System Management Mode (can be achieved through vulnerable software SMI handlers) – is of no interest to adversaries since it does not guarantee they will be able to gain a foothold in a system. A single reboot and an attack must be started anew. However, there is a thing that can make all BIOS security mechanisms inefficient. And this thing is a vulnerable update mechanism implemented by a vendor. Moreover, quite often a legitimate updater adds lots and lots of critical security holes to a system. In this talk, we will speak about how vendors manage to throw all those security flaws together in one system using Intel NUC, a small home PC, as an example. Besides, we will demonstrate how an adversary can compromise BIOS from the userland.

https://2018.zeronights.ru/en/news/the-selection-of-zeronights-2018-talks-is-finished/

Melting Down PatchGuard: Leveraging KPTI to Bypass Kernel Patch Protection

by Omri Misgav & Udi Yavo on October 26, 2018 –

The mitigation for Meltdown created a new part in the kernel which PatchGuard left unprotected, making hooking of system calls and interrupts possible, even with HVCI enabled.[…]

https://blog.ensilo.com/meltdown-patchguard

AMI BIOS Guard Extractor: Parses AMI BIOS Guard (a.k.a. PFAT) images and extracts a proper SPI/BIOS image

Parses AMI BIOS Guard (a.k.a. PFAT) images and extracts a proper SPI/BIOS image. You can either Drag & Drop or manually enter the full path of a folder containing AMI PFAT images.

https://github.com/platomav/BIOSUtilities#ami-bios-guard-extractor

US-CERT: ST18-005: Proper Disposal of Electronic Devices

US DHS US-CERT has new advice, including this excerpt:
ST18-005: Proper Disposal of Electronic Devices

Deleting Data: Removing data from your device can be one method of sanitization. When you delete files from a device—although the files may appear to have been removed—data remains on the media even after a delete or format command is executed. Do not rely solely on the deletion method you routinely use, such as moving a file to the trash or recycle bin or selecting “delete” from the menu. Even if you empty the trash, the deleted files are still on device and can be retrieved. Permanent data deletion requires several steps. Computers: Use a disk cleaning software designed to permanently remove the data stored on a computer hard drive to prevent the possibility of recovery.
* Secure erase. This is a set of commands in the firmware of most computer hard drives. If you select a program that runs the secure erase command set, it will erase the data by overwriting all areas of the hard drive.
* Disk wiping. This is a utility that erases sensitive information on hard drives and securely wipes flash drives and secure digital cards.
[…]

https://www.us-cert.gov/ncas/tips/ST18-005

It would be nice if it mentioned resetting system firmware, ensuring no user account  information is on system. The above discussion is all about data on the hard drive. You can replace the hard drive and the firmware data will remain. Then again, if you’re disposing of a system, you may not care if the new owner inherits your bootkits (you probably didn’t know about the bootkits in the first place). But if you’re at the receiving end of second-hand — aka ‘grey market’, used — hardware, you should not trust the firmware, and only accept the hardware if the manufacturer has tools and images to let you restore the firmware back to a known-good-state.

UEFI parsing libraries

AFAIK, there are 4 libraries/codebases to parse UEFI binaries. Two in Python, one in C++, and the latest one in Go:

1) CHIPSEC, written in Python, available as a library and an app:
https://github.com/chipsec/chipsec

2) UEFI Firmware Parser, written in Python, available as a library and an app:
https://github.com/theopolis/uefi-firmware-parser

3) UEFITool, written in C++ (the New Engine branch of the code does not rely on Qt for the parsing engine):
https://github.com/LongSoft/UEFITool/tree/new_engine

4) and a new one, written in Go, part of the LinuxBoot toolchain:
https://github.com/linuxboot/fiano

Thanks to Nikolaj Schlej, author of UEFITools’ parser, for pointing out that Fiano has a new parser. I got the chance to meet Nikolaj at BSidesPDX the other day. 🙂

Am I missing a library? Leave a Comment on this post. Thanks!

UEFIDump replaced by UEFIExtract with ‘unpack’ option

UEFITool is a Qt-based GUI tool that works on Mac/Windows/Linux. In addition to the main Qt-based GUI tool, the project also has a few other command line tools, UEFIExtract, UEFIFind, UEFIDump. And there are two codebases on Github, master and new-engine.

Some of the command line tools have been changing: UEFIDump was a tool that dumped info. UEFIDump is now gone, replaced by UEFIExtract with the “unpack” option (the “dump” option is related).

https://github.com/LongSoft/UEFITool/blob/new_engine/UEFIExtract/uefiextract_main.cpp

UEFIDump/UEFIExtract aside, UEFIFind is also useful to find information:

https://github.com/LongSoft/UEFITool/blob/new_engine/UEFIFind/uefifind_main.cpp

 

GEF 2018.10 released: GDB Enhanced Features for exploit devs & reversers

New features:
Support for RISC-V architecture (@dlrobertson )
Brand new skin, designed by our own @Grazfather
New command print-format
New convenience variables / functions ($_pie , $_heap) by @wbowling
Better AARCH64 support
All command outputs are now buffered, so less IO, more perf
“Repeatable” commands are in
PyEnv support (@hazedic)
Ditched Travis-CI for Circle-CI
Glibc Tcache bins support
Colorized hexdump byte (pwntools-like)

Changelog:
Bugfix in x86 EFLAGS parsing
Better and more unit tests
More caching (on key functions, settings, etc.)
Fixed the doc
(ARM) Auto. adjust GEF mode from cspr flag
Bugfix in capstone integration
Fixed minor issues in format-string-helper
Fixed IDA integration, thx @cclauss
And more minor bugfixes, and speed improvement

https://github.com/hugsy/gef

gef-context

BB-Weight-Angr: Angr-based static analysis tool for vusec/vuzzer64 fuzzing tool

https://github.com/ash09/angr-static-analysis-for-vuzzer64

This repository contains a Angr-based static analysis module developed during my internship at VU Amsterdam for their fuzzing tool Vuzzer. It supports both the 32bit and 64bit versions of Vuzzer
see-also:

Telemetry: Enhancing Customer Triage of Intel® SSDs

by Behnam Eliyahu and Monika Sane

Telemetry refers to an umbrella of tools, utilities, and protocols to remotely extract and decode information for debugging potential issues with Intel® SSDs. Telemetry works over industry standard protocols, and eliminates or minimizes the need to remove SSDs from customer systems for retrieving debug logs. Telemetry thus enables host tools, Intel technical sales specialists, (TSS), Intel application engineers (AEs), and Intel engineering teams to better identify and debug performance excursions, exception events and critical failures in Intel® SSDs, without sending the physical drive to Intel for failure analysis. This capability is designed in accordance with NVMe* 1.3 telemetry specifications as well as corresponding ACS 4 SATA definitions (which are common industry standards), and is expected to accelerate debugging of external and internal bug sightings pertaining to Intel® SSDs. The key difference between NVMe and SATA is the fact that there is no controller-initiated capability on SATA drives.[…]

https://itpeernetwork.intel.com/telemetry-enhancing-customer-triage/

 

See-also:
https://github.com/linux-nvme/nvme-cli/blob/master/Documentation/nvme-telemetry-log.txt
https://github.com/linux-nvme/nvme-cli/blob/master/linux/nvme.h

What’s New In NVMe 1.3


https://nvmexpress.org/resources/specifications/

Sites with sample firmware rom binaries

I was looking for some UEFI binaries to include in a workshop, and thought I’d make a quick post on the options.

Firmware Vault, a unofficial collection of Apple EFI ROMs:
https://github.com/theopolis/uefi-firmware-parser

A new site, from the author of UEFI Firmware Parser:
https://github.com/theopolis/uefi-firmware-samples

The same author wrote uefi-spider, a tool to scrape vendor web sites of their images, but it appears bitrot has taken effect. It’d be nice if someone submitted some patches to update this useful script. It’d be even nicer if someone would  maintain a site of crawled binaries, so multiple people don’t have to run the crawler against the sites.

tool review: uefi-spider (and firmware_vault)

The Intel Minnowboard releases include some binaries that can be used for analysis:
https://firmware.intel.com/projects/minnowboard-max

Similar to the Minnowboard releases, the Intel FSP releases includes multiple binaries:
https://github.com/IntelFsp/FSP

Linaro.org should have some ARM images. Tianocore should have some OVMF images, and has ShellBinPkg binaries for Intel and ARM. Tianocore and this site have UEFI OVMF images:
https://www.kraxel.org/repos/
https://github.com/tianocore/edk2/tree/master/ShellBinPkg

If you have other ideas, please leave a Comment on the blog with new URLs. Thanks!

Dell PowerEdge BIOS failure with Intel ME

https://www.dell.com/support/article/us/en/19/sln309027/dell-poweredge-14g-bios-update-fails-on-the-first-attempt-second-attempt-works?lang=en

[…]For servers with greater than 24 days of power on time since the last AC power cycle, the first BIOS update will fail because the Intel Management Engine (ME) fails to enter recovery mode for the BIOS update.[…]

Non-Dell OEMs: please also add this to your QA cycle. 🙂

Reversing ESP8266 Firmware (Part 1)

Exciting, this is expected to be a 6-part series!

[…]The challenge was described as follows: We managed to obtain the firmware of an unknown device connected to our wireless access point. We’ve been told it’s connecting to a service and retrieving secrets, but we can’t reach the service. Can you?[…]

Reversing ESP8266 Firmware (Part 1)

https://boredpentester.com/wp-content/uploads/2018/10/recovered_file_updated.zip

Building a Proof of Concept Hardware Implant

Implanted Apple Lightning USB cable [at BSidesPDX]

https://twitter.com/_MG_/status/1054929638621757441

https://mg.lol/blog/badusb-cables/

VirtualBox 6.0 Beta 1 released

https://forums.virtualbox.org/viewtopic.php?f=1&t=89946

https://blogs.oracle.com/virtualization/oracle-vm-virtualbox-60-beta-1-released

Hmm, it looks like the ChangeLog is not up-to-date yet, unclear what firmware changes have occured:

https://www.virtualbox.org/wiki/Changelog