While I was cleaning up some folders from my Desktop, I accidentally found one of them called “PoCs”, which was full of text files and images. They were from my previously reported security bugs, 99% of them for the Google Vulnerability Reward Program.
All those hours spent looking for bugs, trying different methods and understanding how Google services work taught me many lessons which are very helpful now, at work or at home, hacking for bounties. I hope that through this article I can share my experience and help hackers to discover new interesting and cool bugs.
This article will be about two vulnerabilities that I found in the YouTube web application, more exactly in the Studio platform. YouTube Studio (https://studio.youtube.com/) is a new dashboard created by Google for the content creators which makes their lives easier and speeds up the process of editing and publishing videos. This tool has a lot of cool features, including the possibility to view the Analytics data for your videos, changing community and channel related settings and also updating all your videos at once – a feature called Update In Bulk.
Change any YouTube video
If you go to the YT Studio homepage, you will see that in the left menu there is a tab called Videos, which once clicked will redirect you to a new page, where you can see all your videos:
If you are a content creator and want to change all your videos at once (to put a new partner link in the description, add a tag in the title, or shut down your channel by setting all your videos on private) there is a functionality which allows you to do that. By selecting the videos you want to update, a new toolbar will appear in the context of the application. Then, you will be able to select which part(s) of the videos you want to change (title, description, tags, visibility, comments, etc) and a new update button will be shown in the page:
That blue Update button once clicked will trigger a POST request to the YouTube servers (https://studio.youtube.com/youtubei/v1/creator/enqueue_creator_bulk_action) and will have as a body, a JSON formatted code. That JSON object includes various attributes and configuration parameters, but among them, only one caught my attention: a parameter called videos, represented by videoIds object, which has an array with the ids of the videos I’ve just selected for update:
After playing with it for a bit, I discovered that there was no protection or access-right checks to verify if the videos behind those id values are really owned by the user who initiated the update process. This way, I could have changed any YouTube video’s settings just by setting its video ID.
The impact of this vulnerability was pretty big since I could, for example, shut down any YouTube channel just by setting its videos on private. The regular viewer won’t be able to find those videos anymore and then many views will be lost.
Also, if someone wanted to promote a website or a product, this flaw could help him a lot since the only thing he had to do was to update the title and the video of some of the most popular YouTube videos, like Despacito or Shape of you by Ed Sheeran. Also, if someone wanted to gain some pocket-money, he could add a “Donation” PayPal account in the description of some high-ranked videos just as many YouTubers do these days.
Below, there is a PoC video that I’ve created for this bug. Thinking back, maybe I should have made it shorter, but it captures all the technical aspects and all the reproduction steps of this bug:
11.11.2018 — Bug reported
12.11.2018 — Bug triaged & “Nice catch”
13.11.2018 — Bug rewarded
13.12.2018 — Bug fixed
Get the Unlisted Playlists of any YouTube user
The second bug was a logic flaw by which an attacker could have seen any unlisted playlist of any YouTube user.
Any time a user opens the Studio dashboard and wants to edit a specific video, they have to click on it first and then they will be redirected to a new page.
Once this page opens, a new POST request is sent in the background to the https://studio.youtube.com/youtubei/v1/creator/list_creator_playlists endpoint, which, as the name suggests, will retrieve all the playlists of the currently logged-in user. The role of this request was to populate the Playlists section, from the Video Edit page.
Once again, the body of that request was JSON formatted and contained an attribute called channelId, representing the value of the channel being currently edited. After several tests, I discovered that the backend scripts didn’t verify if the value supplied by the user for the channelId parameter was actually his channel ID.
In the response sent back by the application, there were all the playlists associated with that specific channelId with only one condition: the channel should have only PUBLIC and UNLISTED playlists.
If that condition was met, an attacker could have got any unlisted playlist of a YouTube user. This was more like a privacy bug since an unlisted playlist (as an unlisted video) can’t be found in the platform unless shared by the person who owns it.
12.11.2018 — Bug reported
13.11.2018 — Bug triaged
14.11.2018 — “Nice catch”
30.11.2018 — Bug rewarded
12.12.2018 — Bug fixed
Hacking Google is always fun and it’s also a good way to improve your pentesting skills. I recommend you have a look at the Google VRP program and start hacking as one of the good guys 🙂
See you next time!