Сложность: Средняя
Url: [ОТРЕДАКТИРОВАНО].s3.amazonaws.com
Ссылка на отчет: https://hackerone.com/reports/128088²¹
Дата отчета: 3 апреля 2016
Выплаченное вознаграждение: $2,500
Описание:
Здесь мы сделаем кое-что несколько иное. Эта обнаруженная
мной уязвимость немного отличается от бага Shopify, описан-
ного выше, так что я поделюсь всеми деталями о том, как я её
нашел.
Итак, начнем с того, что уязвимость выше описывала пуб-
лично доступный бакет, связанный с Shopify. Это значит, что
когда вы посещали ваш магазин, вы могли увидеть запросы
к сервису S3 компании Amazon, а хакер знал, на какой бакет
нацеливаться. Я не знал - я нашел взломанный мной бакет с
помощью крутого скрипта и некоторой изобретательности.
В течение выходных на 3 апреля, я не знаю почему, но я решил
попробовать мыслить нестандартно и атаковать HackerOne. Я
играл с их сайтом с самого начала и каждый раз давал себе
пинка, увидев новый отчет об обнаруженной уязвимости и
недоумевая, как я мог её пропустить. Я подумал, а что, если
их S3 бакет был уязвим, так же, как бакет Shopify? Я так же
пытался понять, как хакер получил доступ к бакету Shopify…
Я решил, что он смог сделать это, используя Amazon Command
Line Tools.
В этот момент я бы скорее всего остановился бы, подумав,
что нет никаких шансов, что HackerOne все еще содержит уязвимости. Но одна из множества вещей, которые я усвоил
из интервью с Беном Садежипуром было то,
что нельзя сомневаться в себе или в возможности компании
совершать ошибки.
Первая - интересная статья от Rapid7 - компании, специали-
зирующейся на безопасности - которая рассказывает о том,
как они нашли доступные для публичной записи бакеты S3
и сделали это просто предположив название бакета.
Вторая - крутой инструмент, который принимает список слов
и делает запросы к S3 в поисках бакетов… Однако, этот ин-
струмент не содержит встроенного списка. В статье Rapid7 бы-
ла ключевая строка, “…Пытаясь угадать названия с помощью
нескольких разных словарей… были обнаружены компании из
списка Fortune 1000 с перестановками слов .com, -backup, -
media…”
Это было интересно. Я быстро создал список потенциальных
названий бакетов для HackerOne вроде
hackerone, hackerone.marketing, hackerone.attachments,
hackerone.users, hackerone.files, и так далее
Ни одно из перечисленных названий не является реальным -
список отредактирован, хотя я уверен, что вы тоже сможете
их найти. Так что оставим это вам в качестве испытания.
Итак, используя скрипт на Ruby, я начал делать запросы к
бакетам. С самого начало все выглядело не очень хорошо. Я
нашел несколько бакетов, но доступ был закрыт. Не повезло, я
прекратил попытки и отвлекся на просмотр NetFlix.
Но идея меня не отпускала. Перед тем, как отправиться спать, я
решил запустить скрипт еще раз, с большим количеством пе-
рестановок. Я снова нашел некоторое количество бакетов, вы-
глядящих так, словно они могли бы принадлежать HackerOne,
но доступ к ним всем был закрыт. Я понял, что ошибка об
закрытом доступе по крайней мере сообщает мне о существо-
вании бакета.
Я открыл Ruby-скрипт и понял, что он вызывает эквивалент
функции ls на бакетах. Другими словами, он пытался посмот-
реть, были ли они публично доступны для чтения - а я хотел
узнать и то, были ли они публично доступны для ЗАПИСИ.
Здесь нужно заметить, что AWS предоставляет инструмент
командной строки, aws-cli. Я знаю это, потому что я использо-
вал его прежде, так что быстрая команда sudo apt-get aws-cli
на моей виртуальной машине, и инструмент установлен. Я
авторизовался в нем под своим AWS аккаунтом и был готов
действовать. Вы можете найти инструменты для инстру-
мента на docs.aws.amazon.com/cli/latest/userguide/installing.html
Команда aws s3 help откроет помощь по S3 и список доступ-
ных команд, их около 6 на момент написания этого текста.
Одна из них - mv, выполняется в виде aws s3 mv [ФАЙЛ]
[s3://БАКЕТ]. Так что в этом случае я попробовал:
1 touch test.txt
2 aws s3 mv test.txt s3://hackerone.marketing
Это был первый бакет, от которого я получил ошибку об отказе
в доступе, И… “move failed: ./test.txt to s3://hackerone.marketing/test.txt
A client error (AccessDenied) occurred when calling the PutObject
operation: Access Denied.”
Я попробовал следующий aws s3 mv test.txt s3://hackerone.files
И… УСПЕХ! Я получил сообщение “move: ./test.txt to s3://hackerone.files/test.txt”
Потрясающе! Тогда я попробовал удалить файл: aws s3 rm
s3://hackerone.files/test.txt И снова, УСПЕХ!
Но теперь я засомневался в себе. Я быстро залогинился на
HackerOne, чтобы составить отчет, и пока я печатал, я по-
нял, что не могу непосредственно подтвердить владением
бакетом… AWS S3 позволяет любому создать любой бакет в
глобальном неймспейсе. Это значит, что вы, читатель, могли
быть владельцем бакета, который я взламывал.
Я не был уверен, что должен писать отчет без подтверждения.
Поискал в Google, пытаясь найти любую ссылку на найденный
мной бакет, и ничего не обнаружил. Я отошел от компьютера,
чтобы остудить голову. Я понял, что, в худшем случае, я полу-
чу еще один N/A отчет и -5 к репутации. С другой стороны, я
понял, что это стоит по меньшей мере $500, может даже $1000,
если посмотреть на подобную уязвимость у Shopify.
Я отправил отчет и пошел спать. Проснувшись, я обнаружил,
что HackerOne ответили, поздравив меня с нахождением уяз-
вимости и сообщив, что она уже исправлена, а так же, что
были уязвимы еще несколько бакетов. Успех! И к их чести, при
выплате вознаграждения они учли потенциальную опасность
этой уязвимости, и то, что она затрагивала и другие бакеты,
которые я не обнаружил, но которые также были уязвимы.