Zapier Storage Exposes Sensitive Customer Data Due to Poor User Choices

Zenity research team has recently discovered a potential customer data leakage in Storage by Zapier, a service used for simple environment and state storage for Zap workflows. With only a few simple steps and no authentication, we were able to access sensitive customer data. Given the nature of this flaw, it would be easy for bad actors to recreate our approach and access the same sensitive data without significant expertise.

Turns out, Volkis has already identified this issue in August 2020, almost 2 years ago. Our research presents a workaround to the mitigation put forth by Zapier after the original discovery.

Zapier security team has been responsive and quick to analyze and act on the issue. Following Zenity’s disclosure, the Zapier team has notified all affected customers. However, data could still be leaked today due to poor customer secret choices.

Quick FAQ

We use Zapier. Am I secure?

If you are using the Storage by Zapier or Code by Zapier apps to store data, that data could be available for anonymous access. Scroll down to What should I do now for a concrete checklist to ensure your data is secure.

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. 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. This point is true for any No-Code/Low-Code platform, and is not unique to Zapier.  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 are using best practice when building and maintaining your Zaps and involve your security teams for guidance. If you’re looking for an automated governance 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.

Timeline

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

March 20, 2022 – Zapier initial response

March 24, 2022 – Zapier acknowledge the vulnerability with medium severity, and issued a $400 reward

May 20, 2022 – Zapier resolves the case

June 21, 2022 – Zenity coordinates the write up publication with Zapier

July 1, 2022 – Zenity publishes the writeup after Zapier has notified its relevant customers

What is store.zapier.com?

According to Zapier the Storage by Zapier connector allows users to:

“Quickly store and retrieve small values of data. Allows you to reference data between Zap runs or share data between different Zaps.”

Under the hood, Storage by Zapier (and other connectors such as Code by Zapier) are based on https://store.zapier.com. Calling the endpoint returns a developer-oriented documentation::

“”what is it?”: [

    “store.zapier.com is a simple storage REST API that you”,

    “might use to stash a bit of state. we use it to power”,

    “`StoreClient` in our Code steps of Zapier – you can read”,

    “more docs at https://zapier.com/help/code-python/ or at”,

    “https://zapier.com/help/code/.”

  ],

  “—————“: “——————————————-“,

  “what can it do?”: [

    “only one endpoint – GET & POST to read and write, PATCH to update”,

    “store any value that is JSON serializable”,

    “BYOS (bring your own secrets) for authentication”

  ],
This endpoint is being used by the Storage by Zapier and Code by Zapier connectors, Both of them store data on https://store.zapier.com.

What happened

Investigating Zapier’s storage, we found the only protection on user data is a secret provided by the client (Bring Your Own Secret), which has to be a UUID4 string. Beyond that, there is no user-level or account-level authentication in place.

Before August 2020, users could pick any secret they wanted, including extremely simple ones like 123456789, secret, or password. To address the vulnerability found by Volkis, Zapier began enforcing the usage of UUID4 secrets. Those secrets are much harder to guess but can still lead to collisions among users in rare cases. This solution is alright, but it still leaves room for data leakage as we’ll show below.

To show how we accessed Zapier user data, let’s take their own example for using https://store.zapier.com.

“how does it work?”: {

    “always provide either `?secret=12345` or `X-Secret: 12345`”: “”,

    “GET /api/records”: [

      “will return a full object of all values stored by default.”,

      “you can also specify only the keys you want via the”,

      “querystring like`?key=color&key=age`.”

    ],

First, we issued the following request (through our browser):

https://store.zapier.com/api/records?secret=12345

Notice that according to the official documentation, as our secret is not a valid UUID4, we should receive  an error from the server.

To our surprise, we received a JSON object of what appeared to be user IDs and names!

Even though current users supposably can’t use non-UUID4 secrets while using Storage by Zapier we managed to scrape sensitive up-to-date data using legacy secrets.

Among the data we found were:

1. Authentication keys
2. Email addresses
3. Phone numbers
4. Cryptographic wallet IDs
5. Other business data

Common secrets enumeration

In order to see what data can be leaked, we decided to enumerate the storage service with public common password lists.

The secrets wordlists we used are:

• naive-hashcat/rockyou
• wpxmlrpcbrute/1000-most-common-passwords
• SecLists/10-million-password-list-top-10000
  

To bypass any throttling protection or request rate limits imposed by Zapier, we wrote a script that rotates the source IP address every 200 requests. As a result, we did not encounter any hang ups during our script run.

Vulnerability scope

This vulnerability impacts every Zapier customer who uses the Zapier  Storage by Zapier connector, or the Custom Code connector with the StoreClient Python or JavaScript class. The issue allows customers to use insecure secrets, thus exposing their data to unauthenticated observers.

Root cause analysis

The endpoint https://store.zapier.com is used as storage space for key-value pairs generated by Zapier customers within their Zaps. 

There are a few inherent security problems with this design:

1. The storage is maintained globally and is not customer-specific. Therefore, any unauthenticated party can gain access to the stored data as long as they have the secret.
2. Zapier lets users determine their own secret for interacting with the store.zapier.com endpoint.
3. Until 2020, Zapier did not enforce any policy on the strength of the secret. This led to some extremely poor user choices such as 123, aa, password or secret. To mitigate this issue, Zapier enforces UUID4 to be used for new secrets. 
4. Although mitigated, customers today can still use legacy secrets that were used before this fix. These secrets are straightforward to guess (One of them – 12345, is Zapier’s example of  getting started with https://store.zapier.com).

According to Zapier documentation, data unused for over 3 months gets deleted. This means that any data accessed through this vulnerability is up-to-date. Moreover, this allows attackers to periodically retrieve data from the said secrets to discover if more sensitive information has been written to the secret entry in Zapier’s storage.

What should I do now?

Identify all Zaps that use either Storage by Zapier or Code by Zapier apps. For each one, go through their connections and make sure they are using strong secrets. Here is how:

Storage by Zapier:

1. Go to Zapier.com -> Connections.
2. Choose your Storage by Zapier connection.
3. Make sure you’re using a UUID4 secret. If you aren’t, change it immediately.
4. Consider encrypting your data before storing it.

Code by Zapier:

1. Review your zaps and find out if you’re using Code by Zapier
2. Go over the code (Python/Javascript) and look for usage of the StoreClient class.
3. Make sure you’re using a UUID4 secret. If you aren’t, Change it immediately.
4. Consider encrypting your data before storing it.