The Risk of Exposed Cloud Functions and How to Harden

The Risk of Exposed Cloud Functions and How to Harden
Mandiant explains how publicly exposed serverless applications such as Google Cloud Run can be abused through LFI, command injection, and metadata-token theft to reach broader cloud compromise. The article also outlines hardening guidance using S-SDLC, least-privilege IAM, Cloud Armor, VPC Service Controls, and Cloud Run Threat Detection to reduce exposure. #Mandiant #CloudRun #CloudArmor #VPCServiceControls

Keypoints

  • Publicly exposed serverless applications often lack authentication because of business requirements, making them attractive initial access points.
  • Serverless deployments can be vulnerable to LFI/RFI, command injection, and other application-layer flaws in custom code or third-party packages.
  • LFI can expose source code, environment files, configuration files, logs, and system files such as /etc/passwd.
  • Command injection can be used to reach the GCP metadata server and steal a service account bearer token.
  • Stolen tokens can be used with Google Cloud CLI to read, modify, or delete resources, deploy services, and access secrets and encryption keys.
  • Mandiant recommends S-SDLC, dedicated sandboxing for AI-generated code, least-privilege IAM, and defense-in-depth controls such as Cloud Armor and VPC Service Controls.
  • Cloud Run Threat Detection in Google Cloud Security Command Center can help detect credential access, reconnaissance, scripts, and reverse shells.

MITRE Techniques

  • [T1190 ] Exploit Public-Facing Application – Attackers abuse publicly exposed serverless apps as an entry point, including vulnerable Cloud Run services (‘publicly exposed serverless workloads can serve as an initial access point’).
  • [T1213 ] Data from Information Repositories – LFI is used to read sensitive files like source code, configuration, logs, and /etc/passwd (‘retrieve sensitive files from the Cloud Run instance’).
  • [T1005 ] Data from Local System – The attacker reads files directly from the container and retrieves local data such as main.py and /etc/passwd (‘request sensitive files… by using curl’).
  • [T1059.004 ] Command and Scripting Interpreter: Unix Shell – Unsanitized input is passed to shell execution with subprocess.run(shell=True) to execute arbitrary commands (‘allowing an attacker to execute arbitrary commands’).
  • [T1021 ] Remote Services – Stolen credentials are then used with Google Cloud CLI from an attacker-controlled system to operate in the victim environment (‘use it on an attacker-controlled system to execute Google Cloud CLI commands’).
  • [T1552.001 ] Unsecured Credentials: Credentials In Files – The article notes that secrets may be hardcoded in source code or local container files and can be extracted by attackers (‘Hardcoded secrets such as API keys, database credentials, or authentication tokens’).
  • [T1552.005 ] Unsecured Credentials: Cloud Instance Metadata API – Attackers query the GCP metadata server to steal a service account bearer token (‘curl http://metadata.google.internal/…/token’).
  • [T1078.004 ] Valid Accounts: Cloud Accounts – A stolen service account token is used to act with the permissions of the Cloud Run compute service account (‘within the security context of the Cloud Run Compute service account’).
  • [T1090 ] Proxy – The attacker pivots through the compromised service account and CLI access to reach additional Google Cloud resources (‘pivot to adjacent systems and workloads’).
  • [T1482 ] Domain Trust Discovery – Attackers inspect application logic, internal endpoints, and architecture details to identify further attack paths (‘Internal service endpoints and architecture details’).

Indicators of Compromise

  • [URLs ] Example Cloud Run and metadata-service targets used in exploitation – cloudrun01-abc.europe-west3.run.app, cloudrun02-abc.europe-west3.run.app
  • [Internal metadata service URL ] Token theft request destination – metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token
  • [File paths ] Sensitive files targeted via LFI and traversal – main.py, ../../../etc/passwd, /etc/passwd, /proc/self/environ
  • [Environment variables ] Abused to authenticate stolen cloud tokens – CLOUDSDK_AUTH_ACCESS_TOKEN
  • [WAF rule names ] Cloud Armor preconfigured rules referenced for blocking attacks – lfi-v33-stable, rce-v33-stable
  • [Example domain ] Cloud Armor validation target shown in blocking examples – exampleabc01.com


Read more: https://cloud.google.com/blog/topics/threat-intelligence/exposed-cloud-functions-harden/