web

Уязвимости в логике работы приложений. Примеры. Уроки хакинга. Глава 6

Открытые бакеты HackerOne S3

Содержание скрыть

1 Открытые бакеты HackerOne S3

1.1 Поэтому я отправился в Google и нашел пару интересных страниц:

1.2 Выводы

2 Обход двухфакторной аутентифиации GitLab

2.1 Описание:

2.2 Выводы

Сложность: Средняя
Url: [****].s3.amazonaws.com
Ссылка на отчет: https://hackerone.com/reports/12808819 Дата отчета: 3 апреля 2016
Выплаченное вознаграждение: $2,500

Описание:

Здесь мы сделаем кое-что несколько иное. Эта обнаруженная мной уязвимость немного отличается от бага Shopify, описанного выше, так что я поделюсь всеми деталями о том, как я её нашел.

Итак, начнем с того, что уязвимость выше описывала публично доступный бакет, связанный с Shopify. Это значит, что когда вы посещали ваш магазин, вы могли увидеть запросы к сервису S3 компании Amazon, а хакер знал, на какой бакет нацеливаться. Я не знал я нашел взломанный мной бакет с помощью крутого скрипта и некоторой изобретательности.

В течение выходных на 3 апреля, я не знаю почему, но я решил попробовать мыслить нестандартно и атаковать HackerOne. Я играл с их сайтом с самого начала и каждый раз давал себе пинка, увидев новый отчет об обнаруженной уязвимости и недоумевая, как я мог её пропустить. Я подумал, а что, если их S3 бакет был уязвим, так же, как бакет Shopify? Я так же пытался понять, как хакер получил доступ к бакету Shopify… Я решил, что он смог сделать это, используя Amazon Command Line Tools.

[ad name=»Responbl»]

В этот момент я бы скорее всего остановился бы, подумав, что нет никаких шансов, что HackerOne все еще содержит

уязвимости. Но одна из множества вещей, которые я усвоил из интервью с Беном Садежипуром (@Namahsec) было то, что нельзя сомневаться в себе или в возможности компании совершать ошибки.

Поэтому я отправился в Google и нашел пару интересных страниц:

Дыры есть в 1951 бакете Amazon S320

Поисковик бакетов S321

Первая интересная статья от 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 ответили, поздравив меня с нахождением уязвимости и сообщив, что она уже исправлена, а так же, что были уязвимы еще несколько бакетов. Успех! И к их чести, при выплате вознаграждения они учли потенциальную опасность этой уязвимости, и то, что она затрагивала и другие бакеты, которые я не обнаружил, но которые также были уязвимы.

Выводы

Из этой ситуации следует несколько выводов:

Не стоит недооценивать свою изобретательность и возможности разработчиков совершать ошибки. HackerOne отличная команда отличных исследователей безопасности. Но люди совершают ошибки. Проверяйте свои предположения.
Не сдавайтесь после первой попытки. Когда я обнаружил эту уязвимость, проверяя каждый недоступный бакет, я почти сдался. Но затем я попробовал записать файл и это сработало.
Все зависит от знания. Если вы знаете, какие существуют виды уязвимостей, вы знаете, куда смотреть и что тестировать. Покупка этой книги отличный первый шаг.
Яужеговорилобэтомранееискажуснова, потенциальная зона атаки это не только сайт, это и сервисы, используемые компанией. Думайте иначе.

[ad name=»Responbl»]

Обход двухфакторной аутентифиации GitLab

Сложность: Средняя
Url: Недоступен
Ссылка на отчет: https://hackerone.com/reports/12808522 Дата отчет: 3 апреля 2016

Выплаченное вознаграждение: Недоступно

Описание:

3 апреля Джоберт Абма (сооснователь HackerOne) сообщил GitLab, что при включенной двухфакторной аутентификации хакер смог войти в аккаунт жертвы, не зная её пароля.

Для тех, кто не знает, что это такое, скажу, что двухфакторная аутентификация двухступенчатый процесс входа, обычно пользователь вводит свой логин и пароль и затем сайт отправляет ему код авторизации, обычно через email или SMS, который пользователь должен ввести, чтобы завершить процесс аутентификации.

В этом случае Джоберт заметил, что в процессе входа, после ввода хакером его логина и пароля, отправлялся токен для завершения входа. При отправке токена POST-запрос выглядел так:

 POST /users/sign_in HTTP/1.1
  Host: 159.xxx.xxx.xxx
  ...

  ----------1881604860
  Content-Disposition: form-data; name=”user[otp_attempt 7 ]”

  212421

 ----------1881604860--

Если атакующий перехватывал его и добавлял имя пользователя к запросу, например:

POST /users/sign_in HTTP/1.1 2 Host: 159.xxx.xxx.xxx
  ...

 ----------1881604860
  Content-Disposition: form-data; name=”user[otp_attempt 7 ]”

  212421

 ----------1881604860
  Content-Disposition: form-data; name=”user[login]” 12
  john
  ----------1881604860--

то атакующий мог войти в аккаунт Джона, если токен otp_attempt был валидным для Джона. Другими словами, в процессе двухфакторной аутентификации, если атакующий добавлял параметр user[login], он мог изменить аккаунт, в который совершалась попытка входа.

Единственным недостатком здесь было то, что атакующий должен был иметь валидный OTP-токен жертвы. Но это как раз подходящий случай для брутфорса. Если администраторы сайта не реализовали ограничение на количество запросов, Джоберт мог бы осуществлять повторяющиеся запросы к серверу в попытках угадать валидный токен. Вероятность успешной атаки зависела бы от транзитного времени отправки запроса к серверу и от срока валидности токена, но вне зависимости от этих параметров, уязвимость здесь довольно явная.

[ad name=»Responbl»]

Выводы

Двухфакторную аутентификацию непросто реализовать корректно. Когда вы замечаете, что сайт использует её, вы можете захотеть провести полное тестирование всей функциональности, включая длительность жизни токена, максимальное количество запросов, повторное использование истекших токенов, вероятность угадать токен, и так далее.

Оглавление:

Базовые знания о HTTP протоколе. Глава 1

Что такое HTML иньекция. Уроки хакинга. Глава 2.

Что такое HPP (HTTP Parameter Pollution) атака? Уроки хакинга. Глава 3

Что такое CRLF инъекция, примеры использования. Уроки хакинга, Глава 4.

Уязвимости в логике приложений. Уроки хакинга. Глава 6

Уязвимости в логике работы приложений. Примеры.

Что такое XSS атака (Cross Site Scripting Attacks). Уроки хакинга. Глава 7.

SQL иньекции. Виды и примеры использования. Уроки хакинга. Глава 8.

Уязвимости Открытого Перенаправления. Уроки хакинга. Глава 9

Click to rate this post!

[Total: 10 Average: 3.2]

cryptoworld

Специалист в области кибер-безопасности. Работал в ведущих компаниях занимающихся защитой и аналитикой компьютерных угроз. Цель данного блога - простым языком рассказать о сложных моментах защиты IT инфраструктур и сетей.