How We Impersonated Cloud Code by Google Cloud and Took Over GCP Accounts

How We Impersonated Cloud Code by Google Cloud and Took Over GCP Accounts

Speakers: Moshiko, Appwin

Conference: BSides NYC

YouTube: https://www.youtube.com/watch?v=ITtSFxy9RKs

Overview

This talk, presented by Moshiko from Appwin at BSides NYC, unveils critical security research demonstrating how his team successfully impersonated Google Cloud Code, a popular Visual Studio Code extension, to gain full administrative access to Google Cloud Platform (GCP) accounts. The research highlights profound security risks inherent in the rapid adoption of DevOps tools, hybrid cloud environments, and the often-overlooked vulnerabilities within VS Code extensions and their underlying development practices.

Moshiko emphasizes that while organizations meticulously secure their cloud infrastructure, they frequently neglect the security posture of the very tools and integrations used by developers, often granting them extensive permissions from potentially insecure personal devices. The core of the vulnerability exploited lies in the hard-coding of sensitive authentication credentials within the client-side code of a widely used, official Google extension, enabling an attacker to craft a perfectly convincing malicious counterpart.

The significance of this research extends beyond a single extension, serving as a stark warning about the broader implications of insecure software supply chains, the perils of over-privileged developer tools, and the urgent need for enhanced runtime security monitoring. It challenges the assumption of inherent security in developer-centric products and underscores the necessity for security professionals to deeply understand technology before applying security principles.

Background

▶ Watch: Introduction to Cloud Code impersonation research. (0:00)

In today's fast-paced development landscape, developers and DevOps teams prioritize speed and efficiency. This often leads to the widespread adoption of Integrated Development Environments (IDEs) like VS Code, which offer vast marketplaces for extensions that streamline workflows and integrate with various services. One such extension is Google Cloud Code, designed to connect developers directly to their GKE (Google Kubernetes Engine) clusters, other Kubernetes environments managed through GCP, and Docker environments, providing what the speaker describes as "full access."

The problem, as Moshiko points out, stems from a fundamental disconnect: organizations invest heavily in cloud security, blocking S3 buckets and securing perimeters, yet often overlook the immense power and potential vulnerabilities of DevOps tools. These tools are frequently granted root account permissions and accessed from developer laptops that may not adhere to stringent security standards. The prevailing assumption among developers that everything they build is secure often leads to the exposure of unsecured APIs, internal APIs, and the hard-coding of sensitive information.

Moshiko's team questioned why a tool as powerful as Google Cloud Code, granting such extensive access, was available as a public extension and, critically, why its authentication method was handled directly within VS Code itself. This local authentication mechanism, where the IDE directly handles credentials rather than relying on a separate, secure plugin, immediately raised red flags. Common attack vectors for extensions, identified from intelligence work, include:

• Unsecured APIs and unauthenticated endpoints left for internal purposes.
• Exposure of internal APIs that should not be public.
• Impersonation and supply chain attacks, a growing concern in the extension ecosystem.
• Exposed secrets within the codebase.
• Leftover code and artifacts from development.

These observations laid the groundwork for the research, focusing on the hypothesis that the convenience and deep integration offered by such extensions could hide significant security flaws.

Key Findings

▶ Watch: Questioning Cloud Code's VS Code authentication method. (2:30)

Moshiko and his team embarked on a process of reverse engineering the Google Cloud Code VS Code extension. This forensic analysis quickly yielded a treasure trove of artifacts, revealing a startling lack of secure development practices. They uncovered:

1. Exposed Source Code and Secrets: The extension's codebase, being JavaScript, was essentially plain code, even if minified or obfuscated. Through their reverse engineering efforts, they found numerous artifacts, including snippets of source code, various secrets, and unauthenticated APIs that were inadvertently exposed.
2. Working Firelog API Key: While not the primary focus of their exploit, the team discovered a Firelog API key that directly worked for Google. This key allowed them to inject raw data into Google's logging infrastructure, demonstrating a potential avenue for log injection attacks, similar to Log4j vulnerabilities, which could poison DevOps pipelines.
3. Plaintext Authentication Method: The most critical discovery was the entire authentication method for GCP, laid bare in plain code. This included the specific scope, client secret, and client token that GCP used to authenticate its edge clients. This finding was particularly egregious as these credentials, crucial for establishing trust between the extension and GCP, were directly embedded within the client-side code.
4. Misplaced Code and Documentation: The team observed peculiar coding practices, such as parts of the code being stored in what appeared to be CSV files (though still rendered as plain code) and the presence of internal API documentation that should never have been publicly exposed. They also found numerous zip files containing additional source code, further indicating a lack of proper code hygiene and artifact removal.

The presence of the scope, client secret, and client token in plaintext was the linchpin. It meant that an attacker could replicate the exact authentication process of the legitimate Google Cloud Code extension. This allowed Moshiko's team to develop any application they desired and have it authenticate against GCP with the same authority as the official extension. The discovered OAuth2 token not only granted administrative access to GCP but also provided the ability to enumerate and map every user within an organization using the extension. This finding exposed a fundamental design flaw where critical, secret-level credentials were treated as client-side public information.

Technical Deep Dive

▶ Watch: Reversing extension: exposed APIs, secrets, plain code auth. (4:00)

The technical heart of this vulnerability lies in the nature of VS Code extensions and Google's chosen authentication method. VS Code extensions are primarily built using JavaScript, which, even when minified, packed, or obfuscated, remains client-side code that can be reverse engineered. Moshiko's team, leveraging their expertise, easily deconstructed the extension to reveal its inner workings.

The critical flaw was the discovery of the OAuth2 client credentials—specifically the scope, client secret, and client token—hardcoded directly within the extension's JavaScript. These are not ephemeral tokens; they are the static, identifying credentials that Google Cloud uses to recognize the Cloud Code extension as a legitimate application authorized to interact with GCP APIs on behalf of a user. By possessing these hardcoded values, an attacker could effectively impersonate the official Cloud Code application.

The attack methodology proceeded as follows:

1. Credential Extraction: The scope, client secret, and client token were extracted from the reversed extension. These allowed the researchers to understand the exact parameters required for the Cloud Code extension to authenticate with GCP.
2. Malicious Application Development: With these credentials, Moshiko's team could build their own malicious application. They initially developed a mock application using Python with Flaskserver to test the validity of the stolen OAuth2 credentials. This application was designed to mimic the legitimate GCP authentication flow.
3. VS Code Extension Creation: To execute a convincing supply chain attack, they needed to create a malicious VS Code extension. Leveraging tools like ChatGPT, they quickly generated the boilerplate for a new JavaScript-based VS Code extension.
4. Token Exfiltration Mechanism: The challenge was to exfiltrate the generated GCP token from the victim's machine. The malicious extension was designed with an activate function, a standard entry point for VS Code extensions. When the extension was installed and activated (e.g., when VS Code started), it would pop up a prompt, deceptively asking the user to "Please log in to GCP to continue working with us."
5. Impersonation and Credential Theft:

• The malicious extension's login screen was meticulously crafted to look identical to the official Google Cloud Code login, complete with the same icons and logos.
• Crucially, when the user clicked "Log in," they were redirected to the actual GCP authentication endpoint. GCP, seeing the legitimate client secret and client token embedded in the malicious extension's request, processed the login as if it originated from the official Cloud Code.
• Upon successful authentication with GCP, a valid OAuth2 token (representing the user's access) was generated by GCP and then returned to the malicious extension.
• The malicious extension then exfiltrated this token to the attacker's controlled infrastructure (e.g., a blob storage in Azure for cross-cloud functionality).
• The speaker highlighted a key aspect of Google's design: authentication for extensions often uses a local server. This means that installing an extension effectively installs a local web server on the user's machine, which handles the authentication redirect flow. The malicious extension exploited this by having its own local server redirect the token to the attacker.

1. Full Access: Once the attacker possessed the user's legitimate GCP OAuth2 token, they had full administrative access to the victim's GCP account, identical to what the legitimate Cloud Code extension would have. This token could then be used by the attacker from any location or application to interact with GCP resources.

The fundamental vulnerability was not in Google's OAuth2 protocol itself, but in the insecure implementation within the official Cloud Code extension, where application-level secrets were treated as public client-side information. This allowed the attacker to perfectly spoof the legitimate application and intercept the highly privileged access tokens.

Demo / Proof of Concept

▶ Watch: Discovery of GCP client secret/token in plain code. (6:40)

While the presentation did not feature a live, real-time hacking demonstration, Moshiko described and showed screenshots of the proof-of-concept (PoC) developed by his team.

The initial phase involved testing the extracted OAuth2 token using a mock Python Flaskserver application. This allowed them to verify that the stolen client secret and client token could indeed initiate a legitimate-looking GCP authentication flow and grant administrative access. Moshiko humorously noted that no one at the conference would sign into his Flask app, but his internal DevOps employees, unaware of the test, successfully logged in, providing full GCP access.

The core of the PoC was the creation of the malicious VS Code extension. Moshiko mentioned using ChatGPT to rapidly generate the boilerplate for a JavaScript extension, demonstrating the ease with which such tools can accelerate attacker development. The screenshots presented showed:

• The malicious extension's activation prompt, asking the user to log in to GCP.
• The meticulously crafted login interface, which mirrored the official Google Cloud Code branding, including the exact icons and logos.
• The deceptive nature of the attack: despite the malicious extension being named "malicious cloud code," the user interface during the login process still displayed "Cloud Code" and even Google's official GCP support emails, building a high level of trust.
• The successful capture of a GCP token after a user logged in.
• An Okta integration view (from Appwin's platform) illustrating how a legitimate organization would appear, showing user permissions, cloud accounts, and the indication of client usage (like Cloud Code). This demonstrated how Appwin's runtime monitoring solution could detect such an attack in real-time by observing unusual activity associated with the stolen token.

Moshiko explicitly stated, "we tried this on our customer," likely referring to a controlled internal test or a simulated environment to validate the attack's efficacy and Appwin's detection capabilities. The PoC effectively demonstrated that the impersonation was highly convincing and resulted in complete compromise of GCP accounts, underscoring the severity of the hardcoded credentials vulnerability.

Defensive Implications

▶ Watch: Weaponizing vulnerability for GCP admin access. (7:55)

The research by Moshiko and Appwin provides a critical blueprint for organizations to re-evaluate their security posture concerning developer tools and hybrid cloud environments. The defensive implications are multi-faceted, spanning technical controls, architectural changes, and organizational policies:

1. Refresh Credentials Frequently: The most straightforward recommendation is to implement aggressive credential rotation. By forcing users to refresh their credentials every few hours or days, the lifespan of any stolen token is drastically reduced, limiting an attacker's window of sustained access.
2. Server-Side Authentication for Sensitive Extensions: For extensions that manage sensitive cloud resources, authentication should primarily occur on the server side. This prevents critical client secret and client token from being exposed in client-side code, mitigating the core vulnerability demonstrated in this talk. Remote authentication processes are inherently more secure than local, client-side ones.
3. Improve Extension Architecture and Development Practices: Developers must adopt more rigorous security practices. This includes:

• Removing leftover code: To-do lists, internal documentation, and unused source code (like those found in zip files) should be stripped from production builds.
• Avoiding hard-coding sensitive information: This is a recurring theme in open-source and extension development (Moshiko cited similar issues in Argo CD and Flux CD). Secrets must be managed securely, injected at runtime, or retrieved from secure secret stores, never embedded in the codebase.
• Secure code review: Thorough security reviews should be standard for all extensions, especially those with high privileges. The fact that Google considered this a "bug by design" rather than a vulnerability highlights a significant gap in their security evaluation process for this specific component.

1. Limit Access and Permissions (Least Privilege): Extensions should always operate with the principle of least privilege. They should only request the minimum necessary permissions to perform their function. While this is partly the responsibility of the IDP (Identity Provider), extension developers must design their tools to facilitate granular access control. For startups and smaller companies, where a single developer might have root access to everything, this becomes an even more critical issue.
2. Limit API Access and Segmentation: Organizations should segment and limit API access based on environment and purpose. Separate APIs should be used for development, beta testing (dogfooding), and general availability (GA) to prevent exposure of sensitive internal endpoints.
3. Track and Log Unusual Token Activity: Robust logging and monitoring are crucial for detecting post-compromise activity. Security teams should track and log unusual activity associated with tokens, such as:

• Geolocation changes: A token typically used from Germany suddenly logging in from Uzbekistan is a clear indicator of compromise.
• User agent discrepancies: A token associated with a VS Code extension suddenly being used by a CLI tool or a Python application.
• Correlation between DevOps tools and authentication methods: Establishing a baseline of normal behavior allows for the detection of anomalies.

1. Embrace Runtime Security: Moshiko strongly advocates for runtime security over a sole focus on "shift-left" approaches. While static analysis and pre-production checks are important, attackers ultimately target production environments. Real-time monitoring of geolocation, time, and client context can provide the necessary correlation to detect and respond to active breaches, allowing for immediate access limitation.
2. Limit Bring Your Own Device (BYOD) and Personal Laptops: A significant number of attacks originate from personal devices used for work. Organizations should provide dedicated, secured work devices and strictly limit or forbid access to sensitive cloud environments from personal laptops to reduce the attack surface.
3. Limit Access by Geolocation: A simple yet effective control is to restrict access to corporate resources based on geolocation. If employees are primarily located in specific regions, logins from unexpected countries (e.g., a U.S. employee logging in from Thailand while not on approved vacation) should be flagged and blocked.
4. Monitor Third-Party Application Usage: Cloud providers like Amazon, Google, and Azure often provide visibility into the third-party applications or clients accessing an organization's resources. Organizations should actively monitor these logs and track which extensions are being used, by whom, and from where, to identify suspicious activity.
5. Extension Review Process: For organizations allowing extensions, a passive review process is recommended. Extensions should be installed in a sandbox environment, and their behavior (identity interactions, network connectivity, generated logs) should be thoroughly monitored before broader deployment. This allows security teams to understand the extension's true footprint without blocking developer productivity.

By implementing these defensive strategies, organizations can significantly harden their environments against the types of sophisticated supply chain and impersonation attacks demonstrated by Moshiko's research.

Key Takeaways

• Critical Vulnerability in Developer Tools: Hardcoding sensitive authentication credentials (like OAuth client secrets and tokens) in client-side code of widely used VS Code extensions, such as Google Cloud Code, creates a critical vulnerability for impersonation and full account takeover.
• Ease of Exploitation: Attackers can easily reverse engineer client-side JavaScript, extract these hardcoded secrets, and then craft highly convincing malicious extensions or applications, often with the aid of tools like ChatGPT, to steal legitimate user tokens.
• Supply Chain Risk Amplified: The widespread use of developer marketplaces and extensions introduces significant supply chain risks, as users implicitly trust these tools with extensive permissions, often from potentially insecure personal devices in hybrid cloud environments.
• Beyond Shift-Left Security: While "shift-left" security practices are valuable, robust runtime security monitoring is indispensable. Real-time correlation of login parameters (geolocation, user agent, client application) is crucial for detecting and responding to active compromises where stolen tokens are being used.
• Fundamental Design Flaw: Google's response that the hardcoded credentials were a "bug by design" highlights a fundamental difference in security philosophy for developer tools, where convenience and local authentication might inadvertently trade off against secure credential management.
• Comprehensive Defensive Strategy Needed: Effective defense requires a multi-pronged approach: frequent credential rotation, advocating for server-side authentication in sensitive tools, strict code review to prevent hardcoding, implementing least privilege, and rigorous monitoring of unusual token activity and third-party application usage.

About the Speaker(s)

Moshiko is a security researcher from Appwin, with a significant background in military intelligence. He spent eight years in the DoD and Cyber Command in Israel, where he gained extensive experience in understanding technology and identifying vulnerabilities. His work involves deep technical analysis, including reverse engineering. Moshiko is a strong advocate for security personnel understanding technology intrinsically before applying security principles. His current role at Appwin focuses on runtime security, emphasizing the need to monitor and protect production environments against sophisticated attacks, believing that security truly "happens at runtime." He is passionate about uncovering security issues in popular DevOps tools and integrations, particularly in hybrid cloud contexts, to help organizations better understand and mitigate their risks.