Abusing Predefined Cookies to Account Takeover in FlowCrypt

Hello! 😊

In this blog post, I will be explaining how I was able to achieve account takeover in FlowCrypt website by abusing cookies that is preset during the billing process. The FlowCrypt team responded to my disclosure by fixing the vulnerability the same day. See their own public disclosure.

FlowCrypt logo from https://flowcrypt.com/assets/imgs/svgs/flowcrypt-logo.svg

From their official documentation,

FlowCrypt is an email solution that lets you work with end-to-end encrypted messages securely and easily.

Additionally, I will also include FlowCrypt’s own disclosure about this vulnerability in the end of the blog post along with their bug bounty program policy.

Since FlowCrypt will be publishing their own disclosure, I will be more focus in sharing my mindset during the process of discovering this vulnerability.

Website cookie implementation

One of the stuffs that I focus is to study how the particular application handles user authentication. FlowCrypt initially allows theirs user to authenticate via Google Single sign-on (SSO).

Initial login page in https://flowcrypt.com/account

After successful authentication, the server will set two cookies which are auth_account and auth_uuid for the associated user.

Below is a screenshot of the server response.

auth_account and auth_uuid are set upon successful authentication

At a glance, we can understand that auth_account represents the email address of the authenticated user while auth_uuid acts like an alphanumeric secret to verify the user.

The authentication process seems clear and simple, let’s move on to the bug.

Predefined cookies during billing process

FlowCrypt Advanced offers more features comparing to the Free plan. Below is a screenshot of the features offered by FlowCrypt Advanced.

Features of FlowCrypt Advanced

The billing service is located in https://flowcrypt.com/billing. When I discovered the vulnerability, the initial page looks like this.

The appearance of https://flowcrypt.com/billing before the patch

The billing authentication process works differently than https://flowcrypt.com/account because it doesn’t use Google Single sign-on (SSO) to authenticate the user.

Here’s a breakdown of the authentication process in FlowCrypt Group Billing:

User supplies their email address and click ContinueThe client browser sends the request to the serverThe server sends a login email to the user’s specified email address to verify the ownershipUser clicks the link from the emailUser is logged in

The vulnerability lies in step 2 when the client browser sends the request to the server.

Here’s a screenshot of the request when I input one of my spare email address.

Intercepted request when specifying my email address

You will notice the account parameter which carries the value of my email address and uuid parameter which carries the value of an alphanumeric secret.

When I saw this request, it immediately reminds me of how the initial authentication works in the application. The fact that the value of account and uuid is so similar to auth_account and auth_uuid makes the think that

Does the cookies in billing section also works in the account section?

My initial assumption is the account and uuid value will be set as auth_account and auth_uuid cookies when the user confirms the link from their email address.

In other words, the uuid value is predefined in client side and sent to the user’s email address along with their account value.

After the user clicks the login link from their email address, the server authenticates the user by replacing the uuid value into auth_uuid cookie value.

In fact, the login link sent by the server leads me to believe I’m on the right track.

https://flowcrypt.com/api/account/login?
account=<EMAIL_ADDRESS>&
uuid=<UUID_VALUE>&
token=login-token-raw-Xu29UOpkJ2jqSKbRi2zJia4V4XeXSU8k8A0CgGfi&
redirect=billing%3Fverify%3Da9e0cd92

I quickly confirm my assumption by copying the uuid value to my clipboard and confirm the login link in an incognito window so the cookies won’t be applied in my testing environment.

In my test environment, I opened the console and manually modify the cookies value of auth_account and auth_uuid then refresh the page.

It works!

Attack Scenario

Since I know that the value uuid is predefined in client side and I’m able to send a confirmation email with any email address specified, the attack scenario I can think of is as below:

Alice is the victim while Bob is the attackerBob knows Alice’s email address is alice@victim.comBob head over to FlowCrypt billing sectionBob uses Alice’s email address and copy down the value of uuidAlice receives an email from FlowCrypt to verify her accountAlice clicks the login linkBob modify the value of auth_account to alice@victim.com and auth_uuid value into the copied uuid valueBob is able to access Alice’s account, achieving full account takeover

Timeline

After confirming the vulnerability, I swiftly report the issue to FlowCrypt’s security team.

Below is the timeline of the whole process:

17 Oct, 17:00 : (me -> sec) Initial report to security@flowcrypt.com

17 Oct, 17:34 : (sec -> me) Confirmation of email received

17 Oct, 17:42 : (sec -> me) Vulnerability confirmed

17 Oct, 17:45 : (me -> sec) More information provided

18 Oct, 02:29 : (sec -> me) Vulnerability patched and bounty awarded

18 Oct, 12:45 : (me -> sec) Patch confirmed

Closing

As mentioned in the beginning, FlowCrypt themselves also blogged about this vulnerability which can be found here.

If you happen to find a bypass or simply interested in their bug bounty program, you can find the policy here. Past vulnerabilities that are fixed can be found here.

Overall, FlowCrypt is one of the best bug bounty programs I worked with. Not only they have an amazing response time as shown in the timeline, they are also swift in patching security vulnerabilities and awarding bounties.

If you read until this end, I would like to say thank you for spending your time reading this blog post. If you have any questions, feel free to hit me up in my Twitter.