Security design flaw in Storage by Zapier

Posted on 2020-08-05 by Alexei Doudkine in Vulnerability Disclosure

Recently, we discovered a design flaw in how Storage by Zapier was verifying authentication. This flaw could allow attackers to compromise other users’ data stored within Storage by Zapier if the victim mistakenly chose a weak key or a key that was already in use.

This vulnerability was disclosed to Zapier and has since been partially remediated. Zapier’s solution is assessed at the end of this article.

What is Storage by Zapier?

Storage by Zapier is an App built by Zapier that can be used as part of a Zap’s flow. Storage, just like externally built Apps, is registered as an App inside your account. During this registration process, the user is asked to choose a key for this instance of Storage. When the user goes to make a new Zap (what Zapier calls their workflows/pipelines), they can reference the previously registered Storage app and use it to set and retrieve key/value pairs within Storage. You can think of it as a key/value store inside Zapier.

Storage can also be accessed from outside the Zapier application ecosystem by calling the https://store.zapier.com/api endpoint. More on this shortly.

Design flaws with Storage by Zapier

We identified 3 flaws in the design of Storage that could pose security risks to users of Storage and Zapier themselves:

  1. Storage by Zapier is a global service whilst allowing weak keys;
  2. No mechanism to prevent key collisions;
  3. Zapier account is not required to interact with Storage.

We would like to address each of these in detail and provide remediation advice.

Storage by Zapier is a global service whilst allowing weak keys

It is our opinion that, Storage appears to only be accessible by the account that created it. We had this assumption for many reasons:

  • A Storage key must be created from within a Zapier account after logging in;
  • The main description of Storage (https://zapier.com/apps/storage) states “… you can reference data from other steps of your Zap or share data between different Zaps”, alluding to the fact that it is per-account, since there is no mention of cross-account data sharing.
  • There is little documentation about the existence of the https://store.zapier.com/api endpoint, making it hard to find.

We use Zapier internally and this was initially our assumption. As it turns out, this is not the case. Storage is actually a single, global instance that groups data based on the key chosen by the user.

Rather than choosing a strong key on behalf of the user, Zapier allows users to choose arbitrary keys for themselves. This enables users who incorrectly assume Storage is account-bound to choose weak keys and expose their data to external attackers.

During our investigation, we used the https://store.zapier.com/api/records?secret=key endpoint and rotated the key to identify if users were using weak keys. Our findings showed that sensitive information was stored using weak keys alluding to the fact that some users did not fully understand how Storage works.

For example, Personally Identifiable Information (PII) and authentication tokens were found:

Name and phone numbers in Storage

JWT in Storage

No mechanism to prevent key collisions

When a user registers Storage as an App inside their account, there is no warning given if the key chosen was previously chosen by another user. Since Storage is a global service, it is possible for users to accidentally and unknowingly, overwrite other users’ data and have their data overwritten by others.

If users do realise that they have chosen the same key, they would be able to read all data stored within that key-group.

Zapier account is not required to interact with Storage

Users and attackers can interact with Storage without ever registering for a Zapier account. Although this can be beneficial for ease-of-use, it may present a risk to Zapier.

Attackers can abuse this by using Storage by Zapier for malicious purposes such as storing malware, using Storage as a Command & Control (C2) channel and performing Denial of Service (DoS) attacks by filling up Storage.

Tracking these activities will be very difficult for Zapier, since there is no account tied to any action.

Responsible Disclosure and Zapier’s response

These flaws were disclosed according to Volkis’ Responsible Disclosure Policy and Zapier’s Bug Bounty Program.

Zapier’s security engineer was very responsive throughout the process and provided constant updates on the state of remediation efforts. Upon request from Zapier, public disclosure was delayed by two weeks to give Zapier additional time to remediate the vulnerability.

At the time of writing Zapier has partially addressed the flaws in the following ways:

  • Storage now enforces the use of UUID4 tokens as keys. Although old keys remain in use, any new key must be of UUID4 format (e.g. 1a06054c-441f-4a1f-9662-f1bfeba0bf6b).
  • The “Getting Started” documentation (https://zapier.com/help/doc/how-get-started-storage-zapier) has been updated to say “There are no user accounts for Storage. All data stored in Storage is identified and grouped by a Secret Key.”

Recommendations for further improvement

We understand that design flaws are difficult to remediate entirely without affecting backward compatibility. Zapier must find a suitable balance between full remediation and legacy support. For example, using a username and password for authentication is not a viable solution as Storage must be globally accessible by design. Keeping this in mind, Volkis recommends the following actions to further address the root causes:

  • Restrict new keys from being created outside of the Zapier application ecosystem. Rather, users should be required to login to Zapier to create a new Storage key-group. Zapier can then track which keys belong to which user accounts. The key-group can remain accessible globally for read/write operations.
  • Zapier should generate a new, random UUID4 token on behalf of the user rather than letting the user choose their own.
  • During the creation process, ensure that the chosen key is unique. Although it is highly unlikely for collisions to happen, it is still possible.
  • Further update Storage related documentation to explain that Storage is a global instance that can be accessed from outside Zapier. Include reference to the https://store.zapier.com/api endpoint.

Recommendations for Storage users

If you use Storage by Zapier, we recommend the following precautions:

  • If you are currently using a weak key, change that to a UUID4 token as soon as possible;
  • Generate new UUID4 tokens using a random generator rather than filling in the format yourself;
  • When creating a new key for Storage, check for collisions by browsing to https://store.zapier.com/api/records?secret=key where key is your new UUID4 token. You should see an empty JSON object displayed as {}. If, in the extremely unlikely event you see data instead, generate a new key and check again for collisions using the new key.

Timeline

The following timeline describes the sequence of events for this disclosure:

  • 2020-04-23: Vulnerability found and disclosed to Zapier.
  • 2020-04-24: Response from Zapier stating that they are aware of the vulnerability from a recent penetration test and their proposed solution to the vulnerability.
  • 2020-07-01: Follow-up email sent to Zapier for a progress update.
  • 2020-07-02: Zapier responds that the ticket is in backlog and will come back with an ETA.
  • 2020-07-10: Zapier responds that a fix is coming up “pretty soon now”.
  • 2020-07-14: Email sent to Zapier with reminder that 90 disclosure deadline is 1 week away.
  • 2020-07-16: Zapier asks to hold off on public disclosure and commits to a fix by 2020-08-05. Volkis agrees to delay the disclosure date.
  • 2020-08-05: Vulnerability is publicly disclosed.

Final words

Although there are still improvements to be made, the actions taken to partially remediate this vulnerability significantly increase the security of Storage by Zapier.

It was a pleasure to work with Zapier on a solution to this vulnerability and we are glad to see improvements in the services they provide. The ongoing responsiveness of Zapier made our work feel appreciated and we would be happy to work with them in the future.

As a customer of Zapier, we feel confident that they take the security of our data seriously and will continue to use Zapier’s services.

About the author

Alexei Doudkine is Co-Founder and Offensive Director at Volkis. Hacker, tinkerer, car modder and dog person, Alexei has been in the infosec game for over 10 years focusing on the “attack” side of security. You can catch him on Twitter and LinkedIn.

If you need help with your security, get in touch with Volkis.
Follow us on Twitter and LinkedIn