This week we released the Technical Preview of the Vivaldi Mail and Calendar client. One of the minor, but necessary features in this client is that it can, with your permission, access your Gmail account’s Email and Calendar info using APIs published by Google.
Access to these APIs has to be enabled in Google’s Cloud Platform’s API Console which is used to manage API keys and IDs for various projects. These keys and IDs are used by the client application to identify which services the user is asked to grant access to when logging in, using a protocol called OAuth.
Some of these services, such as sensitive ones like Gmail and Calendar access, have a significant limitation to how many accounts an application can access without being approved by Google.
At the time of writing, this process (which might deserve its own article) has still not been completed for Vivaldi’s Mail and Calendar client, despite starting the process in February.
Although we do understand the need to prevent bad actors from getting access, it’s not a pleasant situation when a company can dictate which clients can connect to their service, and essentially shut out the new competition for the best part of a year.
This is why so many of you still can’t connect to Google Mail using Vivaldi Mail.
While the approval process has been frustrating on many levels, the requirements for one small part of it, the support email address, revealed what we think is a security problem, possibly a security vulnerability.
When we reported it in early May, Google’s security team didn’t agree.
The Google Cloud API Console issue
When you approve an app’s access to your Gmail account, you do that via an “OAuth Consent Screen” that informs you about the app requesting access, and what it is requesting access to. Part of that screen is a support email address.
According to Google, this support email address MUST be either a Google mailing list or the email address of one of the project owners or editors. Hopefully, at this point you can see the problem – the support email is forced to be a project owner’s or editor.
Obviously, we are not interested in using a Google-hosted mailing list for our user support work. In fact, like most companies, we would rather avoid using email, and start our users in need of support by pointing them to our actual support channels, such as our bug tracking system, user support tracker, forums, and help pages. But that is not possible at present.
In fact, this requirement for a support email address of an owner or an editor of the Cloud API project owning the enabled APIs is a potential security problem, and possibly a vulnerability.
There are several aspects to why this is a problem, some of them not really related to security.
First of all, it should not be necessary to have a support email address as a member of the project, especially since the domain hosting the email has already been approved.
Second, in general, the support team has no special need to know about the Cloud API project or have access to it.
Where this enters security territory is that should the email address’s Google Account be hijacked, the attacker (whether external or internal) will get editing access to the API project account, and could break the application’s access by disabling the APIs, and possibly do other bad things.
This, of course, applies to all the accounts having access, but the problem with giving the support email account access is that it is publicly known, giving it a much larger external attack surface. Support email accounts shared by multiple people are easier targets, and should not have administrator privileges. Roles like this should always be separate.
Another problem is that support email addresses are frequently piped into a request tracking system, which creates an opportunity for an attacker that has gained access to it, to intercept emails about approving a password reset that can then be used to get control of the account. Your administration security gets reduced to the level of your support tracker, which might be accessed by multiple members of staff, perhaps even volunteers depending on your organization.
Two-factor authentication can mitigate against much of this, but it is not perfect, and an external attacker could use more targeted attacks against employees to obtain the second factor. A targeted attack against employees was used to take control of many verified Twitter accounts earlier this year.
In my opinion, Google should consider rethinking this part of the system to allow the use of any email in the verified domain as a support email (and the owner/editor accounts should not generally be allowed for this address in an approved consent screen), and should also allow a URL in the verified domain to be used instead.
The support team – whose job is to help users – should not be expected to act as trusted administrators of a project. And I also think it is very limiting, and controlling, for Google to force companies to only use email for support, rather than allowing standard support systems like support ticket systems, bug tracking systems, forums, troubleshooting tools, and help pages.
Photo by Shahadat Rahman on Unsplash
