ZAPESCAPE: Organization-wide control over Code by Zapier

In the middle of March 2022, Zenity research team discovered a sandbox-escape vulnerability in Code by Zapier, a service used by Zapier to execute custom code as part of a Zap. Exploiting this vulnerability, any user could take full control over the execution environment of their entire account allowing them to manipulate results and steal sensitive data. For example, a Zapier user could take control over the admin’s custom code execution environment. Furthermore, the exploit could be performed via the user’s private folder, which admins cannot monitor, thus avoiding detection.

Zapier security team has been candid and responsive, and the issue is now fully mitigated. This post has been coordinated with the Zapier team.

Quick FAQ

We use Zapier. Am I secure?

The vulnerability has been fully mitigated by Zapier. If you were using Code by Zapier before 8/17/2022, your account could have been exploited. Scroll down to What should I do now for a concrete checklist to ensure your data and secrets are secure, and your business process integrity remains intact.

Is Zapier insecure?

No, Zapier is a secure platform in and of itself. Unfortunately, no platform is 100% secure and security vulnerabilities are commonplace even with the world’s largest organizations. While this is an instance of a platform vulnerability, the team at Zapier has been responsive to the disclosure and the issue is now fully mitigated. However, security of the Zapier platform itself is only one part of the story, and it is not the most important. The other, more important aspect is what YOU build on top of Zapier. When you create a Zap, you could create a vulnerability that exposes your organization to risk. No-Code development is still development, and you must own your part of the shared responsibility model. To learn about best practice for secure low-code/no-code development, see OWASP Top 10 for Low-Code/No-Code.

How can I prevent insecure usage of Zapier?

Ensure you follow best practices when building and maintaining your Zaps and involve your security teams for guidance. If you’re looking for a solution, Zenity can help by continuously scanning your Zapier environment for security issues and allowing you to set guardrails. With dozens of security policies that detect data leakage, insecure secret storage, identity misuse, over-provisioning and more, Zenity enables you to accelerate low-code/no-code development, risk free.

Breaking the Code by Zapier Sandbox

Timeline

March 16 2022 – Zenity finds the vulnerability and disclose it to Zapier

March 20, 2022 – Zapier initial response

March 30, 2022 – Zapier acknowledge the vulnerability with high severity, and issued a $900 reward

April 7, 2022 – CVE-2022-28802 is reserved for the issue

Aug 17, 2022 – Zapier resolves the case

Aug 20, 2022 – Zenity confirms the resolution

What is Code by Zapier?

Code by Zapier allows users to execute Python or JavaScript code as part of their Zap. The code has access to data that passes through the Zap, and often has access to secrets or credentials depending on user choice.

What happened

Our research exposes that Code by Zapier relies on an AWS Lambda instance shared by the entire Zapier account, and demonstrates how any user in that account, no matter their privileges, can gain full control over that Lambda instance, granting them access to code, input and secrets that belong to other users within that account.

Vulnerability scope

This vulnerability enables gaining full control over the Code by Zapier runtime environment for the entire account. It is executable by ANY account user, no matter their role. The exploit could be introduced through a private Zap, which would ensure the attacker would not be detected, since admins would have no visibility into private Zaps other than knowing that they exist (not even the names).

Our research shows that Code by Zapier runs on an AWS Lambda function shared between the entire Zapier account with ARN “arn:aws:lambda:us-east-1:996097627176:function:prd-mngd-lmbd_paidcodeapipy37_ac”. We were able to demonstrate this vulnerability in all Zapier tiers. Note that in the Free tier, the Lambda ARN is slightly different, where paidcodeapipy37 is replaced with codeapipy37.

What can attackers do with this vulnerability? Really, anything they want within the scope of the Lambda function. The attacker is practically the function for the time of the attack. This includes:

• Exfiltrating Code by Zapier input and code (which most likely contains secrets, including those used by “Store by Zapier” or its Python client “StoreClient”).
• Manipulate the output of “Code by Zapier” to whatever the attacker would like.
• Use Zapier infrastructure for malicious purposes (e.g. DDOS).
• Steal secrets passed to “StoreClient” by replacing “from store_api import StoreClient” a malicious wrapper that sends the secret to an exfiltration endpoint. See Root Cause Analysis for context of this import command.

Note that since Zapier provides a separate Lambda function instance for each Zapier account, this vulnerability is scoped to intra-account privilege escalation.

What should I do now?

Step 1: Assess blast radius

Identify all Zaps that used Code by Zapier before 8/17/2022. For each one, go through their definitions and check whether credentials or sensitive data were passed to Code by Zapier. After going through the list, determine whether to continue to the next step.

Step 2: Revoke secrets

If any secrets were passed to the Code by Zapier step in a Zap, revoke those secrets and replace them with newly issued ones.

Step 3: Identify exploits

Identify all Zaps that used Code by Zapier before 8/17/2022. For each one, go through their definitions and search for code that triggers HTTP calls, messes around with file descriptors or calls a local service through an internal IP address.

Root cause analysis

Our research exposes that Code by Zapier runs input code with the following method:

Using the exec command without any limitation is extremely dangerous, and allows the attacker to, among other actions, spawn subprocesses, query the OS (as we did), communicate with the Lambda Runtime API (as done by the malicious code in step 2), and more.

Mitigation

Zapier completely mitigated the issue by 8/17/2022 by following Zenity’s proposal and creating a separate Lambda function instance for each user, thus avoiding one user gaining control over another user’s Lambda environment. To illustrate, Zapier Lambda ARN is now

“arn:aws:lambda:us-east-1:996097627176:function:prd-mngd-lmbd_paidcodeapipy37_ac_c”.

Full writeup

Since the vulnerability has been mitigated, we have released the original vulnerability disclosure including all technical details in document and video.

References

For more information about using RCE to gain full access over a Lambda function instance, see Gaining Persistency on Vulnerable Lambdas.