Vincent: Ghosts of…. Ghosts of GUID’s past

Vincent has a new blog post, with some history of UEFI and recent security conference interactions, and includes a snippet of some old EFI code from Ken Reneris!

(I used to work with Ken. He is amazingly proficient coder. When he went on vacation to get married, we replaced his keyboard driver such that the ‘;’ key would replace the ‘:’ key randomly. (Back then drivers weren’t signed and a lot easier to replace.) His response was to rewire the person’s mouse so that it would work upside down/backwards.)

http://vzimmer.blogspot.com/2018/10/ghosts-of.html

How Does an Intel Processor Boot?

When we switch on a computer, it goes through a series of steps before it is able to load the operating system. In this post we will see how a typical x86 processor boots. This is a very complex and involved process. We will only present a basic overall structure. Also what path is actually taken by the processor to reach a state where it can load an OS, is dependent on boot firmware. We will follow example of coreboot, an open source boot firmware.[…]

https://binarydebt.wordpress.com/2018/10/06/how-does-an-x86-processor-boot/

Facebook seeks Silicon Security Architect

Facebook Reality Labs, or FRL, focuses on delivering Facebook’s vision through Augmented Reality (AR). Compute power requirements of Augmented Reality require custom silicon. Facebook Silicon team is driving the state of the art forward with breakthrough work in computer vision, machine learning, mixed reality, graphics, displays, sensors, and new ways to map the human body. Our chips will enable AR devices where our real and virtual world will mix and match throughout the day. We believe the only way to achieve our goals is to look at the entire stack, from transistor, through architecture, to firmware, and algorithms. We are looking for a Security Architect who will work with a world-class group of researchers and engineers.[…]
* Drive a silicon security architecture that includes functions from secure boot, to encryption, to protection to device authentication.
[…]

https://www.facebook.com/careers/jobs/289123918543829/?ref=a8lA00000004CJ6IAM

2 new Tianocore/EDK2 security advisories

Tianocore Security Advisories has 2 new UEFI vulnerabilities:

https://edk2-docs.gitbooks.io/security-advisory/content/

30. EDK II Authenticated Variable Bypass
Logic error in MdeModulePkg in EDK II firmware may allow authenticated user to potentially bypass configuration access controls and escalate privileges via local access.
https://edk2-docs.gitbooks.io/security-advisory/content/edk-ii-authenticated-variable-bypass.html

31. EDK II TianoCompress Bounds Checking Issues: Multiple privilege escalation vulnerabilities in TianoCompress and UEFICompress decompression algorithm may allow authenticated user to potentially manipulate stack and heap buffers via local access.

https://edk2-docs.gitbooks.io/security-advisory/content/edk-ii-tianocompress-bounds-checking-issues.html

Microsoft Project Mu: adaptation of TianoCore’s EDK2

https://github.com/Microsoft/mu_plus

https://github.com/Microsoft/mu_basecore

6 repos: https://github.com/topics/projectmu

https://microsoft.github.io/mu/faq/

https://microsoft.github.io/mu/

Project Mu is a modular adaptation of TianoCore’s edk2 tuned for building modern devices using a scalable, maintainable, and reusable pattern. Mu is built around the idea that shipping and maintaining a UEFI product is an ongoing collaboration between numerous partners. For too long the industry has built products using a “forking” model combined with copy/paste/rename and with each new product the maintenance burden grows to such a level that updates are near impossible due to cost and risk.

Project Mu also tries to address the complex business relationships and legal challenges facing partners today. To build most products it often requires both closed-source, proprietary assets as well as open source and industry standard code. The distributed build system and multi-repository design allow product teams to keep code separate and connected to their original source while respecting legal and business boundaries.

Project Mu originated from building modern Windows PCs but its patterns and design allow it to be scaled down or up for whatever the final product’s intent. IoT, Server, PC, or any other form factor should be able to leverage the content.

ME Analyzer v1.70.0 released

ME Analyzer v1.70.0 adds full parsing & unpacking of all Intel CSE ME/TXE/SPS File Systems (MFS/AFS) based on the amazing initial research by @_Dmit. MEA can now show the FS state and log all low-level details. General CSE firmware analysis also improved.

https://github.com/platomav/MEAnalyzer

llvm-mctoll: l statically (AOT) translates (or raises) binaries to LLVM IR

This tool statically (AOT) translates (or raises) binaries to LLVM IR.

https://github.com/Microsoft/llvm-mctoll

Reaper: Characterization and Fast Detection of Card Skimmers

From USENIX Security in August: https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-scaife.pdf

Abstract:

Payment card fraud results in billions of dollars in losses annually. Adversaries increasingly acquire card data using skimmers, which are attached to legitimate payment devices including point of sale terminals, gas pumps, and ATMs. Detecting such devices can be difficult, and while many experts offer advice in doing so, there exists no large-scale characterization of skimmer technology to support such defenses. In this paper, we perform the first such study based on skimmers recovered by the NYPD’s Financial Crimes Task Force over a 16 month period. After systematizing these devices, we develop the Skim Reaper, a detector which takes advantage of the physical properties and constraints necessary for many skimmers to steal card data. Our analysis shows the Skim Reaper effectively detects 100% of devices supplied by the NYPD. In so doing, we provide the first robust and portable mechanism for detecting card skimmers.

This is some excellent stuff! Some immediate questions come to mind:

  • When will the Payment Card Industry (PCI) require this sort of relatively cheap, fast audit of every card interface? ATMs at a minimum require someone to regularly physically attend to them to load/unload cash.
  • Why did it take so long, and so many attacks for someone to come up with this?
  • Who is working on similar technology for physical interfaces? (admittedly, much less common than payment card attacks!)
    • USB
    • PCIe/Thunderbolt/USB-C
    • Ethernet

Electric Scooter Hacking

Old news, summarized nicely: https://melmagazine.com/en-us/story/inside-the-lawless-new-world-of-electric-scooter-hacking

Most of these hacks have nothing to do with firmware at all – they are basic physical access analog hacks… or in some variants, simple theft and vandalism.

The 3 primary components of these (and any e-bike, or electric car!) are:

  • Battery – with it’s own resale / reuse value
  • Motor – with it’s own resale / reuse value
  • Computer – with it’s own resale / reuse value, AND virtually impossible to prevent it from being completely hacked “in place.”

Most of the current activity on the streets of San Francisco seems to be either simply tearing apart the scooter to reuse/resell the current parts, or on basic hotwiring (routing entirely around the computer) to make the scooter function as – just an electric scooter.

Some response from the scooter providers has been firmware updates to disable some things, such as suspending billing by picking up a scooter and relocating it.

Much more interesting, and relevant to firmware security will be to watch the cat and mouse game play out with regards to the firmware on the computer.

Manufacturers of highly computerized, shared use vehicles beware – your threat model is that of a “Hands-on for days” (SUPER Evil Maid) attack, scaling up to unlimited physical access. Much closer to trying to protect an entire manufacturing supply chain than it is to making sure TSA isn’t getting too handsy with your laptop. Worse, if you consider that Attackers can:

  • Move your vehicle (even if you were to lock the axles!) to a full laboratory setting
  • Rewrite any storage, including pulling and reflashing chips
  • Create scalable, automated, fast, reusable attacks, developed in a laboratory

Hardware & Firmware Attacks Versus Time – Threat Modeling

During the Spring 2018 UEFI Forum Plugfest, Brent Holtsclaw and John Loucaides of Intel presented an “Introduction to Platform Security.“(slides pdf).  There is also a Youtube video: https://www.youtube.com/watch?v=M5krZGV1BLk

I suggest this is required material for anyone interested in this topic!

Slide #8 “Classes of Attacker” with an illustration of attacker power relative to level of access: physical but limited, unlimited physical, and privileged versus unprivileged malware. It is elegant and simple.

Here’s my chart, inspired by the above, which is neither. Feedback welcome!

Hardware-and-Firmware-Attacks-Versus-Time

This illustrates graphically what many people have been saying in words. I’ll need to explain it in words anyway. Perfect for a talk! Or a long blog post.

  1. Scale is:
    • fairly precise for time
    • fairly precise for attacker power, not quantified in this illustration
    • only relative for attacker cost / effort / sophistication
  2. Attacker power and time are illustrated as bars, to show the discrete nature of each type of attack.
    • Time: An attacker who believes they are going to have hands on your hardware for seconds cannot safely assume that they might have minutes or hours.
    • Power: An attacker who has the ability to reboot the machine via BMC compromise does not necessarily have the ability to read/write data from the hard drive, as in SATA controller firmware compromise.
  3. OBSERVATION: Time, attacker power and cost are not always directly correlated. The most dramatic example is remote. By design, remote management systems give the fullest control of their host computer possible, and are full Internet connected computers running an operating system in their own right. A classic “weakest link” – if your BMC is not equally secure to the primary system, then it defines the security of the entire system. Attacking these remotely is just as cheap and efficient as attacking the host system remotely.
  4. Remote, unprivileged malware and privileged malware share similarity in that:
    • they should only be able to compromise unsecured or misconfigured firmware. Unfortunately that is most of the firmware, most of the time.
    • ideally they should be verifiable and repairable with software only.

Detail for each type of hardware/firmware attack, as a sort of taxonomy:

Remote

Attacks a management computer built into, or added on to the primary computer. Examples include: IPMI, Redfish, BMCs, Intel AMT and AMD PSP, HP iLo, Dell DRAC, etc. In every way possible, this is the same as simply attacking any network-attached computer. A baseline assumption by manufacturers is often that these specially privileged computers will be attacked to a specially secured network.

Unprivileged Malware

Any standard computer virus / malware can modify at least some of the system firmware, by executing as an unprivileged executable. Special skill and effort is typically required to do this over the creation of a normal virus intended to interact with eg: data files on the filesystem, owned by the unprivileged user. And it is significantly less portable as it often must target a specific SuperIO chip or particular make/model/revision of SATA disk.

Privileged malware

Escalating privilege is understood to be fairly easy on most systems.The primary gain with this attack is using firmware update mechanisms for firmware that can be updated through software (as opposed to requiring direct interaction with the chip in a programmer).  UEFI provides the framework for requiring:

  • Updates cryptographically signed by the manufacturer
  • Forward-only updates, to ensure an attacker cannot revert to an earlier, vulnerable firmware version

But this is not uniformly, or well implemented in the UEFI space, and is not present for most other types of platform firmware.

Hands-on For Seconds

Creates the opportunity for a known-fast side-channel attack, such as the CIA’s “Sonic Screwdriver” exploiting PCIe/Thunderbolt DMA. Or for a stealthy hardware implant, such as the NSA’s Firewalk ethernet jack shim, or an ATM skimmer. Example: Airport security (TSA in the USA) handles a laptop passing through security.

Hands-on For Minutes

Expands the opportunity to slower side-channel attacks, and much more stealthy implants. There may be sufficient time to open the case, and implant something internally, though definitely not for soldering. There is probably an (unillustrated) distinction between hands-on out of sight of the hardware owner, versus in-sight. Example: Airport security (TSA in USA) selects an individual for “enhanced” screening, and separates them from their laptop for some minutes.

Hands-on For Hours

The classic Evil Maid attack, for hardware left unattended in an assumed-safe location such as a hotel room, at home, or an office, or separated from the owner such as at border control for a “suspicious person.” Hours ensures that any case can be opened, and (de)soldering can happen, with the limitation of portable tools only.

Hands-on For Days

An interdiction attack, such as the NSA TAO implants on Cisco routers. More expense and secrecy risk is incurred due to the facilities and number of people involved, but much finer grained (de)soldering is possible.

Unlimited Time (Supply Chain)

Fully invisible implants sandwiched between layers of circuit board are now possible.

Ted Reed: Exploring Universal Flash Storage (UFS) Write Protection on the HiKey960

In my previous post I gave an overview of basic “do it yourself” root-of-trust creation through MMC boot region write-protection. I used this on sample HiKey (original) devices to authenticate ARM-Trusted-Firmware code beyond BL2, authenticating the OPTEE OS and U-Boot as BL33. This post explores the same concept on a HiKey960.[…]

https://casualhacking.io/blog/2018/10/6/exploring-universal-flash-storage-ufs-write-protection-on-the-hikey960

see-also: https://casualhacking.io/blog/2018/7/8/diy-root-of-trust-using-arm-trusted-firmware-on-the-96boards-hikey

Arduino announces Coordinated Vulnerability Disclosure Policy

https://blog.arduino.cc/2018/10/10/announcing-arduino-coordinated-vulnerability-disclosure-policy/

https://github.com/arduino/arduino-cvd-policy

https://www.arduino.cc/en/Main/Security

Microsoft Open Enclave SDK

https://openenclave.io/sdk/

What is Open Enclave SDK?
Confidential computing is an ongoing effort to protect data throughout its lifecycle at rest, in transit and now in use. With the use of Trust Execution Environments, customers can build applications that protect data from outside access while in use. Open Enclave SDK is an open source SDK targeted at creating a single unified enclaving abstraction for developer to be build Trusted Execution Environment (TEEs) based applications. As TEE technology matures and as different implementations arise, the Open Enclave SDK is committed to supporting an API set that allows developers to build once and deploy on multiple technology platforms, different environments from cloud to hybrid to edge, and for both Linux and Windows.

https://azure.microsoft.com/en-us/blog/protect-data-in-use-with-the-public-preview-of-azure-confidential-computing/

Android Security: Control Flow Integrity in the Android kernel

by Sami Tolvanen, Staff Software Engineer, Android Security

Android’s security model is enforced by the Linux kernel, which makes it a tempting target for attackers. We have put a lot of effort into hardening the kernel in previous Android releases and in Android 9, we continued this work by focusing on compiler-based security mitigations against code reuse attacks. Google’s Pixel 3 will be the first Android device to ship with LLVM’s forward-edge Control Flow Integrity (CFI) enforcement in the kernel, and we have made CFI support available in Android kernel versions 4.9 and 4.14. This post describes how kernel CFI works and provides solutions to the most common issues developers might run into when enabling the feature.[…]

https://android-developers.googleblog.com/2018/10/control-flow-integrity-in-android-kernel.html

 

6 new security advisories from Intel

Intel® Server Boards Firmware Advisory
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00179.html

Intel® RAID Web Server 3 Service Advisory
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00171.html

Intel® NUC Bios Updater Advisory
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00168.html

Intel® NVMe and Intel® RSTe Driver Pack Advisory
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00166.html

Intel® Server Board Firmware Advisory
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00138.html