Protect Your IoT Designs from Malware

Protect Your IoT Designs from Malware
Rudy Ramos, Mouser Electronics
12/18/2017 08:00 AM EST

Recent malware attacks such as BrickerBot are a call to action to improve security in products designed for the Internet of Things.[…]
* Provide software patches as new vulnerabilities are discovered
* Provide routine automatic software updates
* Designate a point of contact if a security issue occurs
* Implement encryption for updates
[…]

https://www.eetimes.com/author.asp?section_id=36&doc_id=1332744

PeiBackdoor

Re: https://firmwaresecurity.com/2016/08/28/peibackdoor-new-uefi-payloadbackdoor-tool/

N0where.net has a new story showing how to use this backdoor, and various Twitter news sites are also covering this. πŸ™‚

https://github.com/Cr4sh/PeiBackdoor

https://twitter.com/Hackers_toolbox/status/941957029878468608

https://n0where.net/pei-stage-backdoor-for-uefi-compatible-firmware-peibackdoor/

BTW, the blog site for Dmytro has been down for a few days. A few months ago, it was down for about a week. Hopefully it’ll come back again.
http://blog.cr4.sh/

 

 

RU 5.20.0328 beta released

RU is closed-source freeware for MS-DOS and UEFI. Some UI changes and bugfixes. Changes include:

* Add PCI Express Capabilities Register.bit8 Slot implemented information to info block
* Fix device name was not cleared while changing PCI device
* F6 PCI list changes (PCI Express) to PCIe
* RU /D ACPI: Display the saving file information more clearly
* ALT-6 ACPI table list now list OEM ID, OEM Table ID and Creator ID.
* Fix wrong ACPI table checksum bad information if the length > 0xffff

Important notes: Every version of RU has it own bugs simply because I did not test it fully. Please leave comments here if you find any bug. RU.EXE are not tested at all.

Password: 174105371023

http://ruexe.blogspot.com/2017/12/ru-5200328-beta.html

https://github.com/JamesAmiTw/ru-uefi/

ARM adds ACPIView tool to UEFI Shell: dump ACPI tables

For UEFI Shell uers, there is another ACPI diagnostic tool, in addition to CHIPSEC and acpidump. Excerpts of edk2-devel mailing list post and tool manpage below, see full list posting for source code and more info.

ShellPkg: Add acpiview tool to dump ACPI tables
This program is provided to allow examination of ACPI table contents from the UEFI Shell. This can help with investigations, especially at that stage where the tables are not enabling an OS to boot. The program is not exhaustive, and only encapsulates detailed knowledge of a limited number of table types. Default behaviour is to display the content of all tables installed. ‘Known’ table types will be parsed and displayed with descriptions and field values. Where appropriate a degree of consistency checking is done and errors may be reported in the output. Other table types will be displayed as an array of Hexadecimal bytes. To facilitate debugging, the -t and -b options can be used to generate a binary file image of a table that can be copied elsewhere for investigation using tools such as those provided by acpica.org. This is especially relevant for AML type tables like DSDT and SSDT. The inspiration for this is the existing smbiosview Debug1 Shell command. Many tables are not explicitly handled, in part because no examples are available for our testing. The program is designed to be extended to new tables with minimal effort, and contributions are invited.

acpiview
Display ACPI Table information.

ACPIVIEW [[-?] | [[-l] | [-s AcpiTable [-d]]] [-c] [-v] [-h Highlight]]
-l – Display list of installed ACPI Tables.
-s – Display only the specified AcpiTable type.
AcpiTable : The required ACPI Table type.
-d – Generate a binary file dump of the specified AcpiTable.
-c – Consistency checking (enabled by default).
-v – Display verbose data (enabled by default).
-h – Enable/Disable Colour Highlighting.
Highlight : TRUE/ON enables highlighting;
FALSE/OFF (default) disables highlighting.
-? – Show help.

Formatted display and checking is provided for these signature types:
APIC – Multiple APIC Description Table (MADT)
BGRT – Boot Graphics Resource Table
DBG2 – Debug Port Table 2
FACP – Fixed ACPI Description Table (FADT)
GTDT – Generic Timer Description Table
IORT – IO Remapping Table
MCFG – Memory Mapped Config Space Base Address Description Table
RSDP – Root System Description Pointer
SLIT – System Locality Information Table
SPCR – Serial Port Console Redirection Table
SRAT – System Resource Affinity Table
XSDT – Extended System Description Table

EXAMPLES:

To display a list of the installed table types:
fs0:\> acpiview -l

To parse and display a specific table type:
fs0:\> acpiview -s GTDT

To save a binary dump of the contents of a table to a file in the current working directory:
fs0:\> acpiview -s DSDT -d

To display contents of all ACPI tables:
fs0:\> acpiview

TrailOfBits releases osquery extenson repo, including EFI use

 

https://blog.trailofbits.com/2017/12/14/announcing-the-trail-of-bits-osquery-extension-repository/

Pepijn on Apple use of Intel ME

Interesting, Pepijn Bruienne is looking at new Apple firmware, and how it uses Intel ME.

 

RaspberryPiPkg – 64-bit Tiano Core UEFI for the Raspberry Pi 3

64-bit Tiano Core UEFI for the Raspberry Pi 3

Last updated December 14th, 2017.

This is an implementation of a 64-bit UEFI firmware for the RPi3 platform, based off Ard Bisheuvel’s 64-bit http://www.workofard.com/2017/02/uefi-on-the-pi/ and Microsoft’s 32-bit https://github.com/ms-iot/RPi-UEFI/tree/ms-iot/Pi3BoardPkg. Initially, this was supposed to be an easy walk in the park, where the Microsoft drivers just sorta slide into Ard’s UEFI implementation, and I call it a day. It turned out to be a bit more frustrating of an experience than that :-). This is meant as a generally useful 64-bit UEFI implementation for the Pi3, good enough for most kinds of UEFI development and good enough for running real operating systems. It has been validated to install and boot Linux and FreeBSD.[…]

https://github.com/andreiw/RaspberryPiPkg

Intel Total Memory Encryption (TME) and Multi-Key Total Memory Encryption (MKTME)

This document describes the memory encryption support targeting future Intel processors. Note that Intel platforms supports many different types of memory and not all SOC would support this capability for all types of memory. Initial implementation is likely to focus on traditional DRAM and NVRAM.

Total Memory Encryption (TME) – as name would imply is a capability to encrypt entirety of physical memory of a system. This capability is typically enabled in very early stages of boot process with small change to BIOS and once configured and locked will encrypt all the data on external memory buses of an SOC using NIST standard AES-XTS algorithm with 128-bit keys. The encryption key used for TME uses hardware random number generator implemented in Intel SOC and the keys are not accessible by software or using external interfaces to Intel SOC. TME capability is intended to provide protections of AES-XTS to external memory buses and DIMMs. The architecture is flexible and will support additional memory protections schemes in future. This capability when enabled is intended to support (unmodified) existing system and application software. Overall performance impact of this capability is likely to be relatively small and is highly dependent on workload.

Multi-Key Total Memory Encryption (MKTME) builds on TME and adds support for multiple encryption keys. The SOC implementation will support a fixed number of encryption keys, and software can configure SOC to use a subset of available keys. Software manages the use of keys and can use each of the available key for encrypting any page of the memory. Thus, MKTME allows page granular encryption of memory. By default MKTME uses TME encryption key unless explicitly specified by software. In addition to supporting CPU generated ephemeral key (not accessible by software or using external interfaces to SOC), MKTME also supports software provided keys. Software provided keys are particularly useful when used with non-volatile memory or when combined with attestation mechanisms and/or used with key provisioning services. In virtualization scenario, we anticipate VMM or hypervisor to manage use of keys to transparently support legacy operating systems without any changes (thus, MKTME can also be viewed as TME virtualization in such deployment scenario). An OS may be enabled to take additional advantage of MKTME capability both in native or virtualized environment. When properly enabled, MKTME is available to each guest OS in virtualized environment, and guest OS can take advantage of MKTME in same was as native OS.

Click to access Multi-Key-Total-Memory-Encryption-Spec.pdf

BTW, this is a great Twitter account to watch for updates to the Intel documentation.

Apple releases iMac Pro, with firmware security updates

Re: https://firmwaresecurity.com/2017/12/13/apple-secure-boot/

A New Level of Integration and Security
iMac Pro brings a new level of integration and security to the Mac with the T2 chip, Apple’s second generation custom Mac silicon. By designing and integrating several new controllers β€” such as the System Management Controller, image signal processor, audio controller and SSD controller β€” T2 delivers new capabilities to the Mac like enhanced imaging processing for the FaceTime HD camera. T2 also enables a new level of security by including a secure enclave coprocessor that provides the foundation for new encrypted storage and secure boot capabilities. Dedicated AES hardware encrypts data on the SSD without affecting performance, while secure boot ensures that only trusted software loads at startup.

https://www.apple.com/newsroom/2017/12/imac-pro-the-most-powerful-mac-ever-available-today/

I wish there was some firmware information in the tech specs:

https://www.apple.com/imac-pro/specs/

 

 

Linaro releases Enterprise Reference Platform 17.12

ERP 17.12 has been released!

The goal of the Linaro Enterprise Reference Platform is to provide a fully tested, end to end, documented, open source implementation for ARM based Enterprise servers. The Reference Platform includes kernel, a community supported userspace and additional relevant open source projects, and is validated against existing firmware releases. The Linaro Enterprise Reference Platform is built and tested on Linaro Enterprise Group members hardware and the Linaro Developer Cloud. It is intended to be a reference example for use as a foundation for members and partners for their products based on open source technologies. The members and partners to include distribution, hyperscaler or OEM/ODM vendors, can leverage the reference for ARM in the datacenter.
[…]
– Focused on ACPI and UEFI use-cases.
[…]

http://releases.linaro.org/reference-platform/enterprise/17.12/
https://platforms.linaro.org/documentation/Reference-Platform/Platforms/Enterprise/ReleaseNotes-17.12.md/

More info: linaro-announce@lists.linaro.org list archives:
https://lists.linaro.org/mailman/listinfo/linaro-announce

Apple seeks UEFI firmware engineer

Mac Firmware Engineer

The Mac Platform Software team is looking for a firmware engineer to join a new Austin-based team responsible for developing Apple’s UEFI implementation and related technologies for the Mac product line. Mac Platform Software is responsible for bringing up macOS and Windows on all new Mac products, including the development and integration of firmware and systems software for macOS and Windows, the development of platform-level features for the Mac, and the leadership of cross-functional debug and optimization efforts across hardware and software teams. A Mac Firmware Engineer is responsible for the development of Apple’s UEFI implementation and its related technologies. UEFI provides the boot firmware for all Mac systems and plays a critical role in system stability, performance, and battery life. This role also contributes to development of the boot loader and firmware update mechanisms, as well as other related technologies. Primary job responsibilities include firmware feature development supporting new Mac software and hardware features, supporting ongoing efforts to improve the quality of shipped Macs in the field, and assisting the larger Mac Platform organization in cross-functional efforts to design and build new Mac products.
* Experience in firmware/BIOS development
* Experience with boot loaders and firmware/kernel interfaces
* Knowledge of UEFI and the x86 platform and standards, including ACPI, SMM, PnP, PCIe, and JEDEC DDR a plus
* Strong understanding of system power management a plus

https://jobs.apple.com/search?job=56183392&openJobId=56183392#&openJobId=56183392

Apple Secure Boot

Apple Insider has a story on new Apple security processor. Caber Sasser reviews a loaner iMac Pro.

http://appleinsider.com/articles/17/12/12/imac-pro-debuts-custom-apple-t2-chip-to-handle-secure-boot-password-encryption-more

 

FAT-EFI: FAT EFI loader plugin for Hopper Disassembler

This project is a FAT EFI loader plugin for Hopper Disassembler. Apple uses an extension to the standard PE format for EFI binaries to allow FAT EFI binaries that contain both 32 and 64 bits executables. It is very similar to the FAT format, except for a different magic number and for little endianness. This plugin allows to read these FAT EFI binaries with Hopper Disassembler.[…]

https://github.com/pascalwerz/FAT-EFI

https://www.hopperapp.com/

Similar: https://github.com/0xc010d/EFIFatBinary.hopperLoader

more on Intel-SA-00068 (Intel ME) vuln

Intel has updated their advisory again, many more OEMs on the list now:

https://www.intel.com/content/www/us/en/support/articles/000025619/software.html

Intel ME has impacted Intel WPA2:

https://security-center.intel.com/advisory.aspx?intelid=intel-sa-00101&languageid=en-fr

Microsoft provides info, but the researchers argue with their conclusions:

https://blogs.technet.microsoft.com/surface/2017/12/11/intel-management-engine-vulnerability-and-surface-devices/