Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

The author found several weird quirks and behaviors that were not useful individually. By combining all of these together, they were able to steal files on Google Slides with YouTube.

Google Slides allows for the embedding of YouTube videos. When doing this, it makes a request to just add the video id to the page. Using a directory traversal, it's possible to go backwards on YouTube. Since YouTube has anti-framing protections on the main page couldn't be used but emojis, css/js and some other things could be framed. Our own website here would be nice to have!

The author started looking for an open redirect on YouTube now. They first tried looking at how external links were processed but realized that it required an extra click. Next, they reviewed the authentication flow. Within the authentication flow, they found a redirect but only to a few YouTube subdomains. Luckily, they found an open redirect on accounts.youtube.com but ONLY for various Google products.

The redirect chain is now YouTube->accounts.youtube.com->docs.google.com. Why is this helpful though? According to the author, Google Docs has SAMEORIGIN on the iFrame options, meaning we shouldn't be able to add iFrames on the page besides for itself. If a document has been framed, it automatically disables dangerous functionality like sharing though, making this hard to exploit.

While looking through links, they came across docs.google.com/file/d/{ID}/edit. This page gives a preview of the file and allows for sharing the document as well. It also stays on the docs.google.com domain as well, instead of redirecting to the Drive.

They remembered that Google had a feature that requested access to a folder. This will send an email with a link that prepopulates the request for information. While messing around with the fields, they noticed that they could turn this from two clicks to one click by adding in the userstoinvite parameter to the URL. Additionally, removing the capabilities option from the URL just defaulted to edit.

Putting everything together doesn't frame the permissions page though. Why? Various people at Google mentioned that there is a mitigation in place for preventing cross-origin framing on the server-side. The server-side is checking the Sec-Fetch-Dest and Sec-Fetch-Site headers. To bypass this, the request BEFORE the file preview must be a same origin redirect, instead of coming from YouTube.

Instead of finding another open redirect, they realized that ANY change in the URL with a redirect was fine. For instance, https://docs.google.com/a/a/file/d/<file>edit would go to the main file after the redirect. To make this more believable, they put a Google Form over the top of the docs link with a hole over a particular portion of it. All it takes is one click!

Here's the full attack:

1. Create a Google Slide with the crazy URL as an embedded URL.
2. User loads the Google Slideshow which will load the page we need with the steps below.
3. Path traversal is performed on YouTube.com to move to accounts.youtube.com.
4. Use the redirect from accounts.youtube.com to the /a/a google doc link.
5. Redirect is done to go to the document sharing link.
6. User clicks on the iFramed box, giving the attacker access to it.

The amount of steps and problem-solving here was amazing! I found this via James Kettle and this post did not disappoint at all. The more I read about client-side security, the more I realize I know nothing about the browser. Great post!