TL;DR

I have found a SSRF vulnerability by exploiting content partial flow which Vimeo upload function implements in uploading process.

The Journey

I was studying the most subject I hate and decided to take a rest, I told myself that I wouldn’t lose anything If I hunted on my lovely target in HackerOne “Vimeo”, I bring my MacBook and I went direct to upload function specifically Google Drive upload feature, I chose to upload from google drive, chose video file, back to BurpSuite to catch the request:

Upload Request

As you can see, It sends the file URL with google authorization to let the backend server fetch the file from the url and pass the authorization on the header to access the file from google drive.

let’s setup WireShark in our VPS and make the backend request a video file from our server to see what would happen in the backend, that was the result:

HTTP Stream Of Download request

I noticed an unusual headers, like Range , Content-Range . But its name was enough to tell me what its work. we can assume because most of the time, the size of video files are big, so Vimeo don’t request the full file by one request if the size was big. if the video file is small, It will request the full file, if not It will request the file partially until collect the full file, the following digram can describe what happens:

Normal person uploading

The server sends a request to check the file size, then if the file was small as it can be transferred to the server by single connection, it will request the full file.

Suddenly, an idea came to me, what if I didn’t send the full file to the server? For example, if my server responed to the backend server told it that the file length was 500B , the server will request the 500B , now what if I just responed to the server with 200B ? let’s try it ;)

I have coded a Web Server by Python to test it, The full file length is 554231B , when vimeo request the full file, my server will responed by 8228B Only! my server will log vimeo Range header for me :)

My baby script

Cool! the server stored the 8228B , requested the rest of the file, Cool! I have scenario can lead to SSRF in this case.

What If my server responed with redirect response? vimeo will follow the redirect? store the response? request me the rest? If there rest

The following diagram knocked my brain:

I love draw diagrams

some web servers restricted me to reproduce the attack, So I decided to code a pure http server to perform this attack, I have coded, ran it and passed my attacker host to upload function, SURPRISE! my attack works fine! my thoughts was right D:

Notice: in vimeo you can download your original video file, so you can find the request forgery response easily

Time to exploit

I have gathered information about the server, it was a google cloud Instance, so lets try to retrieving instance metadata, I changed the redirect target to http://metadata.google.internal/computeMetadata/v1beta1/instance/service-accounts/default/token , reproduced the attack and I was able to get their compute engine api access token! it was a great moment for me because it my first SSRF with critical impact I have ever found.

Oh

What now?

Sent to Vimeo, resolved, paid in 2d!

Thanks for reading ;)

Timeline

Apr 29th : Triaged by HackerOne team.

Apr 29th : Vimeo rewarded me initial $100.

May 1st : Vulnerability has been fixed.

May 1st : $4900 rewarded.