New Details on Google’s Titan M (2nd generation) Security Module

Much more detail than in the past, and a promise of open-source software release soon:

https://android-developers.googleblog.com/2018/10/building-titan-better-security-through.html

Titan M performs several security sensitive functions, including:

  • Storing and enforcing the locks and rollback counters used by Android Verified Boot.
  • Securely storing secrets and rate-limiting invalid attempts at retrieving them using the Weaver API.
  • Providing backing for the Android Strongbox Keymaster module, including Trusted User Presence and Protected Confirmation. Titan M has direct electrical connections to the Pixel’s side buttons, so a remote attacker can’t fake button presses. These features are available to third-party apps, such as FIDO U2F Authentication.
  • Enforcing factory-reset policies, so that lost or stolen phones can only be restored to operation by the authorized owner.
  • Ensuring that even Google can’t unlock a phone or install firmware updates without the owner’s cooperation with Insider Attack Resistance.

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.

New! Single Make / Model / Revision Firmware Security Report from PreOS Security

We’re both pretty excited to offer a new report. For any single make / model / revision of hardware, we’ll do an in-depth firmware security report. We will lead by posting example reports to this blog, in sections as (tagged!) blog posts, for:

  • Lenovo Carbon X1 6th Generation
  • Dell XPS 13 9370 (Early 2018)
  • Purism Librem 15 v3

Once we’re done, you’ll be able to access the full reports as a pdfs on the corporate site:

https://preossec.com/services/single-variant-firmware-security-report/

We think it is cool enough to include the entire corporate spiel here:

$500 USD.

You ship us a single example of a current, or intended fleet machine – laptop, desktop or server, and we’ll make you a firmware security report for that system. Use this report to inform purchasing decisions, system security positioning, and improve IT procedures such as firmware updates and incident response.

Example reports available September 2018 for Lenovo Carbon X1 6th Generation, Dell XPS 13 9370 (Early 2018) and Purism Librem 15v3.

If it is an Intel x86_64 machine, we will run:

  • CHIPSEC
  • Firmware Test Suite (FWTS)

and include an analysis of the results in the report.

We will run all publicly available firmware and hardware vulnerability tools and check version numbers, for known issues such as:

  • Intel AMT
  • Intel ME
  • AMD PSP
  • Spectre
  • Meltdown
  • Microcode
  • Rowhammer

We’ll include a comprehensive list of firmware on the system, and highlight potential issues such as:

  • Closed source binary blobs
  • Modifiable firmware
    • How it can be modified (eg: desoldering and flashing chips, JTAG, I2C, etc)
    • Compliance with applicable NIST standards
    • Tools, updates and support availability from component manufacturer, and OEM
    • Operational support, such as signed firmware updates via Windows update and Linux Vendor Firmware Service (aka: fwupd).

We will make recommendations if this system should not be used in sensitive areas such as:

  • Critical Infrastructure
  • DOD
  • PCI
  • HIPAA
  • Executives (CEO, CTO, etc)
  • Finance
  • Legal

Disclose.io Legal Framework for Security Researchers

Paul again.

As far as I know, this is the first effort to tidy up and standardize the legalities around bug bounty programs. Security research is already legally fraught, particularly in the US. Bug bounty programs that pay meaningful amounts are clearly a great step, but there have already been multiple instances of security researchers attempting to do the right thing, and being thwarted by the process – more, and standardized legal protection should help.

https://arstechnica.com/information-technology/2018/08/new-open-source-effort-legal-code-to-make-reporting-security-bugs-safer/

Are there any bug bounty programs in the firmware and/or hardware domain directly?

Apple has one that covers their (low SKU) product line, but things get complicated when a shipping system has components from so many distinct providers and a manufacturer makes so many SKUs. Seems like the buck should still stop at the integrated system manufacturer – eg: Dell, Lenovo, HP, Supermicro, etc, and at the component manufacturer for components that can be replaced – HDDs, SSDs, discrete PCIe devices.

 

Duo Security purchased by CISCO

Paul writing again. Soon you’ll learn to check the byline, or notice that I’m a lot more wordy than Lee (Hucktech).

https://www.cnbc.com/2018/08/02/cisco-buys-security-start-up.html

Duo Security pays more attention than most to platform firmware security, and have done R&D and released open source software in the space. Previously:

https://firmwaresecurity.com/2017/11/20/duo-labs-releases-idapython-coretex-m-firmware-aned-amnesia-modules/

https://firmwaresecurity.com/2018/05/03/duo-on-apple-firmware-security-and-new-efigy-release/

Notably, EFIgy:

https://github.com/duo-labs/EFIgy/

 

 

 

Meet Us At Black Hat USA 2018

Management here – we’ll be at Black Hat USA 2018.. next week. If you’ll be there, be sure and stop by our Arsenal Tools Demo Wednesday, August 8 | 2:30pm-3:50pm, Station #5.

https://www.blackhat.com/us-18/arsenal/schedule/index.html#firmware-audit-platform-firmware-security-automation-for-blue-teams-and-dfir-11359

We’ll be around before and after, attending talks and available for meetings. If you think your employer should be doing more platform firmware security, we’d love to talk! Email to set up a meeting:

blackhatusa2018@preossec.com