In the realm of cybersecurity research, peculiar behaviors and quirks often surface, initially appearing as mere novelties. However, these seemingly insignificant oddities can sometimes become crucial pieces in uncovering more serious issues. It’s essential to keep track of them, as they might one day hold the key to a significant discovery.
Imagine embedding a YouTube video into a Google Slides presentation – a common and convenient feature. But what if this simple act could be twisted into a method for unauthorized file access? This exploration dives into a fascinating vulnerability chain that leverages YouTube and Google Slides in an unexpected way, demonstrating how a seemingly harmless feature can be manipulated for malicious purposes. You might find this kind of internet deep-dive intriguing, much like the captivating investigations featured on channels like “The Why Files Youtube”, which explores various mysteries and unusual phenomena. While “the why files youtube” delves into a broad spectrum of topics, this article focuses on a specific technical exploit within the digital landscape.
Part 1: The Allure of Embeds and Cat Videos
Let’s face it, who can resist a good cat video? Google Slides makes it incredibly easy to incorporate YouTube videos into presentations. Simply use the video picker, search for your desired clip, and seamlessly integrate it onto a slide.
This integration works by embedding an iframe that points to www.youtube.com/embed/{VIDEOID}, displaying your chosen cat video directly within the presentation. A user-friendly feature, but does its functionality extend beyond simple video playback?
Network analysis reveals that when a video is added, Slides transmits the video’s ID, which is then used to construct the embed URL for the iframe. While we can alter the video ID, we lack control over the complete URL. However, could manipulating the video ID parameter still yield unexpected results?
Path traversal is an immediate thought. If we alter the video ID to “../“, the resulting URL becomes www.youtube.com/embed/../, theoretically resolving to www.youtube.com/ – the YouTube homepage itself. Let’s put this to the test.
Surprisingly, navigating to www.youtube.com within the Slides iframe results in a connection refusal.
www.youtube.com refused to connect.This outcome, while unexpected in its specific manifestation, reveals a security measure. YouTube, like many modern web applications, prevents the framing of most of its pages to mitigate clickjacking attacks. The /embed/ page is a deliberate exception, designed for embedding. But are there other intriguing, framable pages within www.youtube.com?
Further investigation reveals a collection of framable resources under /s/. This includes access to YouTube’s emoji assets and CSS/JS source code directly within a presentation iframe! While not immediately exploitable, it’s a curious capability demonstrating the flexibility – and potential vulnerabilities – within the iframe context.
Part 2: The Open Redirect Angle
Open redirects, often categorized as minor vulnerabilities, are URLs that can redirect users to any arbitrary page. For example, google.com/url?q=https://example.com would redirect you to example.com. These are often deemed low-severity because the impact is typically limited to redirection.
However, within the confines of a youtube.com iframe, an open redirect becomes significantly more interesting. The ability to redirect this Slides iframe to a website of our choosing unlocks a range of potential exploits. The hunt for a YouTube open redirect begins.
The most logical starting point is external links on the site, such as those found in video descriptions and comments. Clicking a link in a video description indeed redirects through a /redirect endpoint:
https://www.youtube.com/redirect?event=video_description&redir_token=...&q=https%3A%2F%2Flyra.horse%2F&v=tbYxAFHnzG0This redirect functions, but notice the redir_token parameter. This token appears to be a session-specific redirect authorization. If someone else attempts to use the same link, they encounter a warning page:
youtube.com/redirect?event=video_description&redir_token=...&q=https%3A%2F%2Flyra.horse%2F&v=tbYxAFHnzG0[YouTube](https://www.youtube.com/)
Are you sure you want to leave YouTube?
The link is taking you to a site outside of YouTube (**lyra.horse**).
[GO TO SITE](https://lyra.horse/)[BACK TO YOUTUBE](https://www.youtube.com/watch?v=tbYxAFHnzG0)This intermediary page with a warning makes this redirect less practical for exploitation, especially within a cross-origin iframe, which is further restricted by the x-frame-options: SAMEORIGIN header.
Next, authentication flows often present open redirect opportunities, as websites frequently aim to return users to their original page after login. YouTube is no exception, using a /signin endpoint for Google account logins:
https://www.youtube.com/signin?action_handle_signin=true&app=desktop&hl=en&next=https%3A%2F%2Fwww.youtube.com%2F&feature=passive&hl=enIntriguingly, this endpoint redirects without any verification token! The next parameter seems to accept arbitrary URLs. Let’s try redirecting to an external site.
Navigating to youtube.com/signin?next=https://lyra.horse/ yields an error:
youtube.com/signin?next=https://lyra.horse/
Sorry, we found some errors:
- Invalid url forwarding parameter
- Sorry, your login was incorrect.It appears a direct open redirect is blocked. Testing with google.com and even youtube.com itself produces the same error.
However, realizing the subdomain oversight, testing with www.youtube.com reveals that redirects do function. Further testing uncovers that redirects work with various YouTube subdomains – music.youtube.com and admin.youtube.com also function as redirect origins. While still confined to YouTube domains, this expands the potential attack surface.
Part 3: Chaining Redirects for Deeper Access
The /signin redirect isn’t the only redirect discovered. Another exists on a different YouTube subdomain:
https://accounts.youtube.com/accounts/SetSID?ssdc=1&sidt=&continue=https%3A%2F%2Fwww.google.com&tcc=1&dbus=EEThis appears related to Google account logins, potentially used to update cookies across Google domains. Experimentation reveals that while not a fully open redirect, it accepts redirects to a range of Google domains, including services like Google Docs.
Redirecting the iframe to docs.google.com unlocks significant possibilities. Google Docs pages generally employ x-frame-options: SAMEORIGIN, preventing cross-site framing. However, a redirect originating from youtube.com and landing on docs.google.com within the iframe could create a same-origin context, allowing us to frame and interact with Docs pages in unintended ways.
Let’s attempt to chain the path-traversal /signin redirect with this accounts.youtube.com redirect to embed a Docs page within the Slides iframe.
../signin?next=https%3A%2F%2Faccounts.youtube.com%2Faccounts%2FSetSID%3Fcontinue%3Dhttps%3A%2F%2Fdocs.google.comBy carefully constructing the chained redirects, we achieve the unexpected: Docs within Docs!
Untitled presentation FileEditViewInsertFormatSlideArrangeToolsExtensionsHelp
Slideshow
Share
L
Untitled presentation FileEditViewInsertFormatSlideArrangeToolsExtensionsHelp
Slideshow
Share
L
Untitled presentation FileEditViewInsertFormatSlideArrangeToolsExtensionsHelp
Slideshow
Share
L
yeah
This nested embedding, while visually amusing, raises the question: what practical impact can this achieve?
Part 4: From Nested Docs to File Access
While embedding Docs within Docs is a novelty, its direct utility is limited. Exploring the Docs homepage reveals minimal interactive elements beyond basic document management like deletion (easily recoverable from trash). A more impactful target within the Docs domain is needed.
Initially, document editing pages seem promising. However, these pages are intentionally designed to be embeddable and have built-in protections when framed externally, disabling sensitive functionalities like sharing options.
The key lies in discovering a less protected, yet still impactful, page within the docs.google.com domain. Extensive searching through Wayback Machine archives and Google dorks eventually led to: docs.google.com/file/d/{ID}/edit.
This page facilitates previewing and interacting with Google Drive files, folders, and even Google Sites pages, directly within the Docs domain, unlike other links that redirect to Google Drive itself. Crucially, it even works with the Drive “Root” folder.
docs.google.com/file/d/0ALK4w9WgXcQUUk9PVA/edit
Root
Open with
Share
Share
L
No preview availableThe critical element here is the persistent “Share” button, remaining active even within an iframe. If a user can be tricked into clicking this “Share” button, entering a target email, and modifying folder permissions, unauthorized access can be granted.
Part 5: Reducing Friction to a Single Click
Convincing a user to perform multiple actions – clicking “Share,” entering an email, and altering permissions – is a significant hurdle, heavily reliant on social engineering. To elevate this exploit beyond social engineering, the goal is to reduce the interaction to a single click.
Recalling Google Drive’s access request feature offers a potential solution. Requesting access to a document triggers an email with a prominent “Manage sharing” button, streamlining permission management.
| from: | **Lyra Rebane (via Google Drive)** |
|---|---|
| reply-to: | Lyra Rebane @gmail.com> |
| to: | [email protected] |
| date: | Sep 19, 2024, 10:30 AM |
| subject: | Share request for "Secret Folder" |
| mailed-by: | doclist.bounces.google.com |
| signed-by: | google.com |
| security: | 🔒 Standard encryption (TLS) [Learn more](https://blog.aegrel.ee/) |Share request for "Secret Folder"
Inbox
**Lyra Rebane (via Google Drive)**
to me
Sep 19th, 2024, 10:30 AM
Share a folder?
L
Lyra Rebane ([email protected]) is **requesting access** to the following folder:
hi pls give access kthxbye
Secret Folder
[Manage sharing](https://docs.google.com/file/d/1sHy3aQXsIlnOCj-mBFxQ0ZXm4TzjjfFL/edit?usp=sharing_esp&[email protected]&sharingaction=manageaccess&role=writer&ts=66e724ba)The email button links to a Drive URL: drive.google.com/drive/folders/{ID}?usp=sharing_esp&[email protected]&sharingaction=manageaccess&role=writer&ts=66e724ba, which, upon opening, displays the Share dialog with the access request.
Adapting this to the Docs URL by copying the query parameters:
docs.google.com/file/d/1sHy3aQXsIlnOCj-mBFxQ0ZXm4TzjjfFL/edit?usp=sharing_esp&[email protected]&sharingaction=manageaccess&role=writer&ts=66e724badocs.google.com/file/d/1sHy3aQXsIlnOCj-mBFxQ0ZXm4TzjjfFL/edit?usp=sharing_esp&[email protected]&sharingaction=manageaccess&role=writer&ts=66e724ba
Secret Folder
Open with
Share
Share
L
[?](https://www.youtube.com/watch?v=yD2FSwTy2lw "no one's around to help")Share "Secret Folder"
Lyra Rebane asked to be an editor✖
People with access
L
Lyra Rebane (you)
[email protected]
Owner
General access
Restricted
Only people with access can open with the link
Copy link
Done
Request for access
L
Lyra Rebane asked to be an editor
[email protected]
hi pls give access kthxbye
Editor
?
Decline
ShareIn this state, the attack requires two clicks: one on “Review” and then “Share.” However, further investigation using DevTools and JavaScript analysis reveals a more streamlined approach.
Experimenting with just the userstoinvite query parameter:
docs.google.com/file/d/1sHy3aQXsIlnOCj-mBFxQ0ZXm4TzjjfFL.../[email protected]docs.google.com/file/d/1sHy3aQXsIlnOCj-mBFxQ0ZXm4TzjjfFL.../[email protected]
Secret Folder
Open with
Share
Share
L
[?](https://www.youtube.com/watch?v=6XFX8hL6YdI "there's no one in moominvalley to help")
Share "Secret Folder"
L
Lyra Rebane✖
Editor
Cancel
SendBy omitting other query parameters, the share dialog auto-populates the email field from userstoinvite, defaulting to “Editor” permissions. This reduces the attack to a single click on the ambiguously labeled “Send” button.
Part 6: The Triple Redirect Chain
Assembling the complete attack chain involves combining all the discovered techniques:
- Start with the streamlined Docs share URL:
https://docs.google.com/file/d/1sHy3aQXsIlnOCj-mBFxQ0ZXm4TzjjfFL/[email protected] - Embed it within the
accounts.youtube.comredirect:https://accounts.youtube.com/accounts/SetSID?continue=https%3A%2F%2Fdocs.google.com%2Ffile%2Fd%2F1sHy3aQXsIlnOCj-mBFxQ0ZXm4TzjjfFL%2Fedit%3Fuserstoinvite%3Dlyra.horse%40gmail.com - Wrap that in the
youtube.com/signinredirect:https://www.youtube.com/signin?next=https%3A%2F%2Faccounts.youtube.com%2Faccounts%2FSetSID%3Fcontinue%3Dhttps%3A%2F%2Fdocs.google.com%252Ffile%252Fd%252F1sHy3aQXsIlnOCj-mBFxQ0ZXm4TzjjfFL%252Fedit%253Fuserstoinvite%253Dlyra.horse%2540gmail.com - Finally, use path traversal as the “videoid” for embedding in Slides:
../signin?next=https%3A%2F%2Faccounts.youtube.com%2Faccounts%2FSetSID%3Fcontinue%3Dhttps%3A%2F%2Fdocs.google.com%252Fa%252Fa%252Ffile%252Fd%252F1sHy3aQXsIlnOCj-mBFxQ0ZXm4TzjjfFL%252Fedit%253Fuserstoinvite%253Dlyra.horse%2540gmail.com
However, initial tests reveal an obstacle:
Google Drive
You need access
[Open the document directly](https://docs.google.com/presentation/d/10LlimFowOJ_noDrJsv4CnRgU8XoUKRAa6YjTeJFrs70/edit) to see if requesting access is possible, or switch to an account with access. [Learn more](https://www.youtube.com/watch?v=Hh9iFc5Sdso)
You are signed in as
[email protected]Docs implements a mitigation, blocking cross-site redirects to file pages within iframes. It checks Sec-Fetch-Dest and Sec-Fetch-Site headers, returning a 403 error when both are iframe and cross-site, respectively. This server-side mitigation aims to prevent cross-origin framing.
To bypass this, a same-origin redirect within the iframe is needed. The current chain is:
accounts.youtube.com (cross-site) → docs.google.com/file/d/…/edit (403)
The desired chain is:
accounts.youtube.com (cross-site) → docs.google.com/??? (same-origin) → docs.google.com/file/d/…/edit (200)
The solution lies in utilizing a legacy Google Suite URL format: docs.google.com/a//…. While its original purpose is obsolete, it now redirects to the standard Docs URL. Logged-in users can even use docs.google.com/a/a/... for this redirect.
Examples:
https://docs.google.com/a/wyo.gov/file/d/10LlimFowOJ_noDrJsv4CnRgU8XoUKRAa6YjTeJFrs70/edit(works regardless of login)https://docs.google.com/a/a/file/d/10LlimFowOJ_noDrJsv4CnRgU8XoUKRAa6YjTeJFrs70/edit(requires Google account login)
Both redirect to https://docs.google.com/file/d/10LlimFowOJ_noDrJsv4CnRgU8XoUKRAa6YjTeJFrs70/edit.
Integrating /a/a/ into the “videoid” bypasses the 403 error: ../signin?next=https%3A%2F%2Faccounts.youtube.com%2Faccounts%2FSetSID%3Fcontinue%3Dhttps%3A%2F%2Fdocs.google.com%252Fa%252Fa%252Ffile%252Fd%252F1sHy3aQXsIlnOCj-mBFxQ0ZXm4TzjjfFL%252Fedit%253Fuserstoinvite%253Dlyra.horse%2540gmail.com
Share "Secret Folder"
L
Lyra Rebane✖
Editor
Cancel
SendThe attack now functions as intended.
Part 7: Polishing the Deception
With the share dialog embedded, the final step is to disguise it within the presentation for effective deception. Since the goal is a single “Send” button click, the demo is designed to resemble a Google Forms page.
Cancel
Send
Who are the coolest horses?
Never submit passwords
This content is neither created nor endorsed by Google.
Hover over the form to see behind it.This form overlay conceals the share dialog, creating a “cutout” specifically for the “Send” button. Clicking “Send” grants “Editor” permissions to the attacker-specified email for the targeted file or folder. Sharing the Slides presentation with the /present URL directly initiates the attack in presentation mode.
This culminates in a one-click clickjacking attack, chaining a Google Slides YouTube embed path traversal with three redirects to gain editor access to a Drive file or folder.
The vulnerability chain was reported to Google on July 1st, 2024, triaged and confirmed the same day. On July 11th, the VRP panel awarded $4133.70 ($3133.70 + $1000 bonus).
Afterword
Thank you for reading!
This write-up is a condensed version of a presentation given at BSides Tallinn 2024. The talk recording is available here and the slides are here.
The blog post itself is crafted purely in HTML/CSS, with no images, JavaScript, or external resources, totaling a mere 31kB gzipped. This intentional design choice prioritizes interactivity and responsiveness.
If any aspect of this complex attack chain remains unclear, feel free to ask questions.
Love <3!
Discuss this post on: twitter, mastodon, lobsters (rip cohost :c)
