Cloud & Infrastructure Unit 42 1 month ago

The Machine With Many Faces: Post-Exploitation Identity Misuse in SPIFFE/SPIRE

CN
CyberNew Threat Research Desk
• Original Reporting: Unit 42
CyberNew Threat Intel Assessment
Assessed Severity: HIGH
Impacted Surface
Cloud & Distributed Infrastructure
Intelligence Sector
Cloud & Infrastructure

Analyst Takeaway

"Executive Summary This research demonstrates post-exploitation techniques that could allow an attacker with root access on a compromised Kubernetes node to misuse an open standard and reference implementation for machine identity known as SPIFFE/SPIRE to impersonate co-located workloads and harvest SPIFFE Verifiable Identity Documents (SVIDs). We show how the trust assumption at the core of every..."

Recommended Defense & Mitigation

  • Access Review: Audit administrative roles, enforce phishing-resistant MFA, and review privilege escalations.
  • Credential Rotation: Rotate high-privilege service credentials and tokens associated with impacted services.
Curated & Verified by CyberNew Threat Intelligence Desk Standard Defense Framework (NIST / MITRE ATT&CK)

Executive Summary

This research demonstrates post-exploitation techniques that could allow an attacker with root access on a compromised Kubernetes node to misuse an open standard and reference implementation for machine identity known as SPIFFE/SPIRE to impersonate co-located workloads and harvest SPIFFE Verifiable Identity Documents (SVIDs). We show how the trust assumption at the core of every machine-identity system — that the node is trusted — collapses once an attacker obtains root on that node. Unit 42 has not observed this technique exploited in the wild.

The Secure Production Identity Framework for Everyone (SPIFFE)/the SPIFFE Runtime Environment (SPIRE) is widely deployed in Kubernetes and cloud-native environments to replace long-lived secrets with short-lived, cryptographically verifiable workload identities.

Our research shows how an attacker with root can spoof the Linux control group (cgroup) information the SPIRE agent uses during workload attestation. This tricks the agent into issuing a co-located workload's SVID to an attacker-controlled process.

As part of this research, we developed Spooffe, an open-source tool that defenders can use to test whether an attacker with administrative access could manipulate cgroup metadata to retrieve co-located workload identities and assess the resulting identity area of impact.

When designing threat models for SPIFFE/SPIRE, organizations should assume that root-level access to a node grants access to all cryptographic identities scoped to it. We recommend performing the following activities to reduce exposure:

  • Harden nodes
  • Restrict root access
  • Prohibit privileged containers, host access
  • Minimize reliance on weak selectors

Palo Alto Networks customers are better protected from the threats described here through the following products and services:

If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team.

Related Unit 42 Topics Identity, Cloud, Kubernetes

Introduction

SPIFFE is an open standard for machine identity designed to solve the “Secret Zero” problem — the challenge of securely introducing the initial secret required to bootstrap trust — by replacing long-lived secrets with short-lived workload identities. When deployed correctly, SPIFFE enforces strong identity boundaries between workloads.

However, these guarantees rely on a core assumption shared by all identity systems that the underlying node is trusted. If an attacker gains root access to a node, they can interact with identity mechanisms to retrieve all identities authorized to that compromised node.

Our research explores how attackers can exploit root access to harvest workload identities from a compromised node. In this post, we lay the groundwork by explaining machine identity and how SPIFFE establishes and verifies trust in cloud-native environments. We then demonstrate workload impersonation through selector spoofing. Finally, we introduce Spooffe, a tool we built to automate the extraction of these workload identities (SVIDs).

Note to readers: If you’re already familiar with SPIFFE/SPIRE concepts and architecture, you can jump directly to Workload Attestation and How the Agent Attests the Workload sections.

SPIFFE Overview

Consider a scenario where two applications, a frontend and a backend, must communicate securely.

We could generate key pairs and exchange public keys to communicate through Mutual Transport Layer Security (mTLS), but this option raises a few key questions:

  • Who rotates those keys?
  • Who revokes them if the app is compromised?
  • Can we verify who/what is presenting the keys?

SPIFFE addresses these issues by standardizing how machines are named and how short-lived credentials are issued.

The term machines refers to two broad categories:

  • Workloads: Containers, processes and services running application logic
  • Devices: Endpoints such as desktops, mobile devices and internet of things (IoT) or operational technology (OT) systems
    • (Note: Device identity is not part of the core SPIFFE specification)

SPIFFE Identity Components

Each workload is assigned three identity components:

  1. SPIFFE ID: Who you are (your name)
  2. SPIFFE Verifiable Identity (SVID): Proof that you are who you are claiming to be (your credentials)
  3. Trust Bundle: How others verify that a trusted authority issued your credential

Let’s go into a little more detail about each of these.

SPIFFE ID is a canonical name for a workload identity that follows a URI-style format like spiffe://<trust-domain>/<path> (Figure 1).

Source Verification & Original Intelligence

This threat report was reviewed by CyberNew analysts and cross-referenced with primary security disclosures from Unit 42.

Primary Advisory →