Varonis Details Cross-Tenant Code Execution Risk in Google Cloud Dataflow
Summary
Varonis Threat Labs describes how predictable Dataflow staging buckets and a swapped Python session pickle could enable cross-tenant code execution. Google says global fixes add bucket-ownership checks and SHA-256 artifact verification.
Key points
- The researchers describe a risk affecting certain Apache Beam Python pipelines using the default staging bucket and --save_main_session, before the project had created that bucket in the region.
- Beam derived the default bucket name from the project ID and region; the Python SDK did not verify that a pre-existing bucket belonged to the victim project.
- An attacker could reportedly squat the bucket, replace the staged pickled_main_session, and have Dataflow workers execute code when they unpickled the artifact.
- The described payload could access the worker service account’s identity and token; potential impact depended on that account’s permissions.
- Google’s global mitigations include a Beam Python SDK ownership check, server-side Dataflow bucket-ownership enforcement, and SHA-256 verification of staged artifacts.
- The researchers note that explicitly configured staging or temporary buckets remain dependent on their owners’ access controls, and that pickle can execute code by design.
Article Details
- Attack Vectors
- An attacker precomputes a predictable default Dataflow staging-bucket name from a target project ID and region, creates the bucket in an attacker-owned project, and grants AllUsers read/write access.
- When a qualifying Python Beam pipeline uses the default staging bucket and --save_main_session, the pipeline stages its pickled session in the squatted bucket. The attacker watches for the file, replaces it with a malicious pickle, and workers may execute the payload when they unpickle it.
- The payload can query the instance metadata server for the Dataflow worker service account's identity and access token, then exfiltrate them to an attacker-controlled endpoint.
- Defensive Notes
- Google reports that global mitigations are deployed: Beam 2.75.0 and later checks ownership of pre-existing default buckets, and the Dataflow service independently rejects default buckets owned by another project.
- Dataflow workers verify SHA-256 digests of staged artifacts at startup and abort if an artifact was modified after staging.
- For explicitly configured staging or temporary buckets, restrict access and secure the project that owns them; the article says default-bucket ownership checks do not apply to explicitly configured buckets.
- Treat write access to staging storage as equivalent to write access to pipeline code, since --save_main_session still uses pickle, which can execute code when deserialized.
MITRE ATT&CK
T1041 · Exfiltration Over C2 ChannelThe payload is described as exfiltrating the worker service account token to an attacker-controlled endpoint.T1059.006 · PythonThe malicious pickle payload executes Python code when Dataflow workers unpickle the swapped session file.T1078.004 · Cloud AccountsThe article says the stolen service account token could be used to pivot to other GCP resources the account can reach.T1552.005 · Cloud Instance Metadata APIThe described payload queries the instance metadata server to retrieve the worker service account's identity and access token.T1565.001 · Stored Data ManipulationThe attacker deletes the staged pickled_main_session and replaces it with a malicious pickle in the squatted bucket.
Vendors
Products
Apache BeamAfter our Dataflow Rider research, we examined Apache Beam, the open-source SDK behind Dataflow, and found that under certain conditions, attackers could run code in projects they could not access directly.DataflowVaronis Threat Labs uncovered a cross-tenant Google Cloud Dataflow vulnerability that potentially allowed attackers to exploit predictable bucket names and achieve remote code execution (RCE) on another organization'sGCPUnder the right conditions, the attack started from just the target's GCP project ID.