Source: heimdalsecurity.com – Author: Vladimir Unterfingher
Kevin Mitnick, once dubbed the World’s Most Famous Hacker said that “hackers are breaking the systems for profit. Before, it was about intellectual curiosity and pursuit of knowledge and thrill, and now hacking is big business.” As defenders, it’s our job to put them out of business or, at the very least, provide some good sport.
In this article, I want to explore how common tools such as those from the Google Workspace suit can lead to a full-fledged business compromise.
For this purpose, I’m going to leverage a less-known X-Frame Options header vulnerability associated with the Google Docs’ ‘Send Feedback’ feature.
What you’ll learn in this article
- Another attack surface to cover and address.
- The importance of using secure tools even for day-to-day tasks.
- Alternative ways to bypass the security controls of commonly used applications.
- How to draft a security policy to deal with this attack vector.
Google Workspace Contributing to Data Breaches and Shadow IT
At its core, Google Workspace is a suite that should enhance productivity and make collaboration easier, regardless of workflow. However, if used incorrectly, it can become a liability. To this end, before going into any specifics, I invite you to ponder on the following aspects.
- The most effective business compromise methods aren’t the most obvious.
- Open-source and freeware tools should not be deployed nor used in sensitive areas.
- Google Docs and similar apps can and will be weaponized if used without restrictions and governance.
- Cost vs. benefit vs. risk of using potentially unsafe applications, thus feeding unauthorized ops such as Shadow IT.
Covering all bases being vital to business continuity (and integrity), I’m going to show you a way how an innocuous thing like a G-doc could run your business into the ground.
Brief(est) History of Google Workspace Vulnerabilities
If your team is using Google Workspace tools to log sensitive information, your next move should be to do some research on the topic. Let me save you the trouble of searching for this info. Here are a couple of incidents you should consider.
DeleFriend vs. Google Workspace
The DeleFriend exploit of Google Workspace exposed a major security vulnerability, allowing unauthorized access to sensitive data. This breach was significant due to the extensive use of Google Workspace in professional and educational environments.
The incident highlighted the risks associated with third-party integrations in major platforms. In response, DeleFriend and Google rapidly worked to rectify the security flaw, emphasizing the need for stringent security measures in digital ecosystems.
Lateral Movement with Google SSO
The lateral movement vulnerability in Google Workspace, leveraging Google’s Single Sign-On (SSO), posed a critical security threat.
It enabled attackers with initial access to one Google account to traverse multiple services and applications. This exploit risked exposing sensitive personal and organizational data.
Free Cloud Identity Data
The Google Workspace exploit utilized a flaw in the Free Cloud Identity’s token validation process, allowing attackers to bypass SSO authentication.
This technical oversight permitted unauthorized API access, potentially exposing sensitive data across multiple Workspace applications.
Google’s remediation involved patching the token validation mechanism and reinforcing API access controls to prevent such sophisticated exploits in the future.
G-Suite Super Admin
The G-Suite Super Admin exploit involved a sophisticated manipulation of permission escalation within the admin console. Attackers exploited a vulnerability in the role assignment process, gaining unauthorized Super Admin privileges.
This breach allowed wide-ranging access to all G-Suite applications and user data, prompting Google to implement stringent controls and audit mechanisms to secure the admin console against such vulnerabilities.
GhostToken
The GhostToken exploit in Google Workspace involved a complex vulnerability in the OAuth 2.0 token handling mechanism.
Attackers manipulated token validation processes to gain unauthorized access to user accounts and data across various Workspace applications. Google’s response involved a comprehensive overhaul of the OAuth system, enhancing token security and auditing procedures to prevent such advanced token-based exploits.
Now that I’ve added a bit of context to this experiment, let me go through the setup and, of course, the purpose of this exercise.
The goal is twofold:
- Gain access to a G-doc document and obtain sensitive product development data (e.g., new features, unsolved bugs, bulk-imported code from GitHub or similar repositories, flawed code, ways to bypass controls etc.)
- Infiltrating further into the network (i.e., lateral movement).
Now for the setup; for this job, I’ve used two Windows-running machines (i.e., attack and victim machine), both with the latest builds.
The first task is to collect as much intel as possible. This is a vital step because the info will allow you to identify weak links, improperly secured areas, misconfigurations, missing protocols or even a backdoor that can facilitate the entire process.
One way to go about it would be to leverage clear web resources (e.g., social media to identify key players, G-Business for company info and/or industry).
You can also try other techniques such as:
- Sending bogus surveys to phish or spear phish the victim;
- Networking scanning;
- Stealing user credentials from third-party websites (i.e., LinkedIn);
- Brute-forcing;
- Searching dark web credentials repositories;
- Drive-by downloads;
- Keylogging.
Let’s assume that the threat actor has all the intel he needs to attempt infiltration. For this exercise, I will focus on a less-known vulnerability inherent to Google Docs called an X-Frame-Options header deficit – which is another fancy way of saying that the HTTP reply header a browser should be receiving doesn’t instruct the browser if it should be accepting or not to render a page in the form of an