Mandiant Details Risks and Hardening Measures for Exposed Cloud Run Services
Summary
Mandiant explains how vulnerabilities in publicly accessible serverless functions can expose files, enable command execution, and put cloud resources at risk, then recommends layered controls to reduce impact.
Key points
- Publicly accessible serverless applications may contain code or package vulnerabilities, including local file inclusion and command injection.
- File inclusion can expose application source, configuration, environment variables, logs, and potentially sensitive data.
- Command execution can enable attackers to obtain service-account tokens from the cloud metadata service and access resources permitted to that account.
- Mandiant recommends isolating public-facing services in dedicated projects and using custom service accounts with only necessary permissions.
- Use an external Layer 7 load balancer with Cloud Armor, rate limits, logging, and identity controls where appropriate; restrict direct service ingress.
- Apply secure development practices, keep secrets out of code and container files, and use Secret Manager for credentials.
- Use VPC Service Controls to limit lateral movement and exfiltration, and Security Command Center detectors to monitor certain Cloud Run threats.
Article Details
- Defense Focus
- Harden publicly accessible serverless workloads and detect attacks against Cloud Run resources.
- Detection Methods
- Use Cloud Armor preconfigured WAF rules to block local file inclusion, path traversal, and remote code execution attempts.
- Use Security Command Center Cloud Run Threat Detection to detect credential access, reconnaissance, script execution, and reverse shells.
- Apply continuous security testing, security scanning, and code review before deployment.
- Data Sources
- Security Command Center Cloud Run control-plane detections.
- Load balancer and forwarded traffic logs for security monitoring.
- Rule Types
- Cloud Armor preconfigured WAF rules using evaluatePreconfiguredWaf, including lfi-v33-stable and rce-v33-stable, configured at sensitivity 3.
- Defensive Actions
- Place public-facing Cloud Run services in a dedicated, isolated Google Cloud project.
- Use custom service accounts with least-privilege permissions instead of the default Compute Engine service account; scope access to only required buckets and secrets.
- Restrict serverless ingress to internal traffic and use an external Layer 7 Application Load Balancer to manage internet exposure.
- Use Cloud Armor to filter malicious traffic and apply rate limits and request limitations.
- Use VPC Service Controls with direct VPC egress or VPC Access connectors to restrict lateral movement and exfiltration.
- Keep secrets out of source code and local container files; use Secret Manager.
- Integrate security scanning, code review, least-privilege IAM, and continuous security testing into development and CI/CD.
- Isolate AI-code experimentation in sandboxes, enforce data-egress controls, and restrict development environments to approved IDEs and verified least-privilege plugins.
MITRE ATT&CK
T1059.004 · Unix ShellThe command-injection example passes unsanitized input to shell execution, allowing attacker-supplied commands to run in the function.T1190 · Exploit Public-Facing ApplicationThe article describes attackers exploiting vulnerabilities in publicly exposed serverless applications, including LFI and command injection, to gain initial access.T1552.001 · Credentials In FilesThe article describes extracting hardcoded secrets from application code and retrieving sensitive files that may contain credentials.T1552.005 · Cloud Instance Metadata APIAfter code execution, an attacker requests a service-account bearer token from the Google Cloud instance metadata service.
People
Vendors
Google CloudWhile this analysis focuses on hardening strategies for Google Cloud Run services and functions that must remain publicly accessible, these principles apply universally to any public serverless deployment.MandiantMandiant security assessments frequently identify publicly exposed serverless applications that lack authentication, often as a result of specific business requirements.
Products
Cloud ArmorCloud Armor Integration: Web Application Firewall (WAF) support to harden applications against vulnerabilities such as Local/Remote File Inclusion (LFI/RFI) and Server-Side Request Forgery (SSRF).Cloud RunWhile this analysis focuses on hardening strategies for Google Cloud Run services and functions that must remain publicly accessible, these principles apply universally to any public serverless deployment.Cloud StorageCloud Storage Bucket Access: If the service only requires read access to objects from a Cloud Storage bucket, grant the Storage Object Viewer (roles/storage.objectViewer) role restricted to that specific bucket.Google Cloud CLIOnce obtained, an attacker can use it on an attacker-controlled system to execute Google Cloud CLI commands.Identity-Aware ProxyIdentity-Aware Proxy (IAP): integration support for scenarios requiring specific identity-based authentication for internal users.Secret ManagerUtilize a dedicated secrets management solution, such as Secret Manager.Security Command CenterBeyond the hardening recommendations outlined in this post, Google Cloud Security Command Center (SCC) provides built-in services to detect control plane attacks against Cloud Run resources.VPC Service ControlsSpecifically, when using direct VPC egress or VPC Access connectors, use VPC Service Controls to restrict lateral movement and exfiltration through granular access policies.
Industries
E-commerceServerless services underpin major e-commerce, media, payment processing applications, and AI usage.MediaServerless services underpin major e-commerce, media, payment processing applications, and AI usage.Payment processingServerless services underpin major e-commerce, media, payment processing applications, and AI usage.