Применение логической уязвимости

Применение логической уязвимости отличается от других типов уязвимостей, которые мы обсуждали. Хотя HTML-инъекция, HTML-параметрическое загрязнение и XSS связаны с отправкой некоторого типа потенциального вредоносного ввода, применение логической уязвимости фактически связано с манипулированием сценарием и использованием ошибок в коде веб-приложения.

Примером атаки этого типа является проникновение Егора Хомакова на Github, который написан на RoR (Ruby on Rails). Если вы не знакомы с Rails, это очень популярный веб-фреймворк, который может обрабатывать множество сложных вещей при разработке веб-сайтов.

В марте 2012 года Егор уведомил сообщество Rails о том, что Rails обычно принимает все переданные ему параметры и использует эти значения для обновления записей базы данных (в зависимости от реализации разработчика). Идея разработчиков ядра Rails заключается в том, что разработчики, использующие Rails для создания веб-приложений, должны сами заботиться о заполнении пробелов в безопасности и определять, какие значения могут быть отправлены пользователями для обновления записей. Это уже стало общеизвестным в сообществе, но ветка на Github показывает, что немногие люди способны распознать риски, связанные с этим (https://github.com/rails/rails/issues/5228).

Когда основные разработчики не согласились с ним, Егор продолжил использовать уязвимость аутентификации на Github, угадывая и отправляя значения параметров, включая дату создания (если вы знакомы с Rails и знаете, что большинство записей базы данных содержат столбцы даты создания и обновления, это не так сложно). Таким образом, он передал на Github билет с датой в будущем. Он также смог обновить ключ доступа SSH, что позволило ему получить доступ к официальному репозиторию кода Github.

Как упоминалось ранее, эта атака через бэкэнд-код Github не проводила разумную проверку действий Егора, что впоследствии могло быть использовано для обновления записей базы данных. Здесь Егор обнаружил то, что называется уязвимостью массового присвоения.

Логические уязвимости, такие как обсуждаемые здесь типы атак, более сложны, поскольку они зависят от логики приложения и не просто отправляют потенциально вредоносный код (не все XSS-атаки также сложны!).

Используя пример Github, Егор знал систему на основе Rails и то, как Rails обрабатывает пользовательский ввод. В других примерах это включает в себя прямое программирование вызовов API для тестирования поведения приложения, например, обходя полномочия администратора Shopify. Или это включает повторное использование возвращаемых значений из вызовов аутентифицированных API для последующих вызовов API, которые не должны позволять вам это делать. Сервис AWS представляет собой надёжную систему, включающую в себя систему управления правами доступа, которая позволяет администраторам определять права доступа для каждого сервиса, включая S3.

Разрешения включают создание корзины S3 (Bucket), чтение и запись данных в корзину, а также другие операции.

Согласно раскрытой информации, Shopify не настроил должным образом разрешения для своих корзин S3, что позволило любому аутентифицированному пользователю AWS читать или записывать данные в эти корзины. Это может быть проблемой, поскольку вы не хотите, чтобы злоумышленники использовали вашу корзину S3 для хранения и управления файлами.

К сожалению, подробности проблемы не были раскрыты, но их можно найти с помощью инструмента AWS CLI, который позволяет взаимодействовать с сервисами AWS на вашем компьютере. Хотя для этого вам потребуется аккаунт AWS, создание аккаунта фактически бесплатно, так как вам не нужны никакие сервисы. Таким образом, используя CLI, вы можете пройти аутентификацию на AWS и затем проверить, доступен ли доступ (это также способ, которым я обнаружил HackerOne Bucket, который будет описан ниже).

Важно отметить: при исследовании потенциальной цели убедитесь, что вы учитываете все возможные инструменты, включая веб-сервисы, которые могут быть использованы. Каждый сервис или программное обеспечение, операционная система и другие компоненты могут предоставить новые векторы атаки. Кроме того, полезно быть знакомым с популярными веб-инструментами, такими как AWS S3, Zendesk, Rails и другими, которые используются многими сайтами.

6. Открытый доступ к корзине HackerOne S3

Сложность: средняя

URL: [REDACTED].s3.amazonaws.com

Ссылка на отчёт: https://hackerone.com/reports/128088

Дата отчёта: 2016.04.03

Награда: $2500

Описание:

Мы собираемся обсудить некоторые интересные вещи. Эта уязвимость отличается от той, что была описана для Shopify, поэтому я решил подробно рассказать о том, как я её обнаружил.

Итак, сначала, упомянутая уязвимость заключается в том, что корзина была публично доступна через ссылку на Shopify. Это означает, что когда вы посещаете этот сайт, вы увидите вызов AWS-сервиса, и хакер узнает, куда указывает корзина. Однако я этого не сделал — я использовал крутой скрипт и несколько инструментов, чтобы обнаружить корзину.

В выходные дни 3 апреля я по какой-то причине решил выйти за рамки привычного мышления и попробовать атаковать HackerOne. Сначала я поиграл с их сайтом и каждый раз, когда обнаруживал новую уязвимость, заставлял себя читать информацию о ней, чтобы понять, почему я пропустил её. Я хотел узнать, есть ли у них такая же уязвимость, как у Shopify. Я также хотел знать, как хакеры получили доступ к корзине Shopify. Я узнал, что это было сделано через инструмент командной строки Amazon.

Обычно я бы остановился здесь, потому что HackerOne вряд ли всё ещё имеет уязвимости. Но внезапно у меня появилась идея, основанная на интервью с Ben Sadeghipour (@Nahamsec), которая заключается в том, чтобы не сомневаться в себе или в ошибках компании.

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

1. «There’s a Hole in 1,951 Amazon S3 Buckets» (https://community.rapid7.com/community/infosec/blog/2013/03/27/1951-open-s3-buckets)

2. «S3 Bucket Finder» (https://digi.ninja/projects/bucket_finder.php)

Первый — это интересный пост от Rapid7, компании по безопасности, о том, как находить публичные корзины S3, доступные для записи, с использованием методов поиска по ключевым словам или угадывания имени корзины.

Второй — это крутой инструмент, который принимает список слов и вызывает S3 для поиска корзин. Однако он не содержит встроенного списка. В статье Rapid7 упоминается ключевое слово «использование другого списка для угадывания имён, содержащего названия 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 и был готов к работе. Вы можете найти руководство по этому инструменту на сайте docs.aws.amazon.com/cli/latest/userguide/installing.html.

Сейчас команда awss3help открывает справку по S3 и перечисляет доступные команды. Одной из этих команд является mv, которая используется в форме aws s3 mv [FILE] [s3://BUCKET]. Поэтому я попробовал:

touch test.txt
aws s3 mv test.txt s3://hackerone.marketing

Это первая корзина, которую я попытался использовать, и получил отказ в доступе при вызове операции PutObject.

Так что я попробовал следующую корзину, 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 позволяет любому человеку создавать любую корзину под глобальным именем пространства. Это значит, что вы или любой читатель могли фактически владеть корзиной, которую я тестировал.

Я не был уверен, стоит ли отправлять отчёт без подтверждения владения. Я искал в Google, могу ли я найти какие-либо ссылки на эту корзину. Ничего не нашёл. Я выключил компьютер, чтобы разобраться в своих мыслях. Я понимал, что худшее, что может произойти, — это получение ещё одного недействительного отчёта и вклад -5. С другой стороны, я знал, что это, по крайней мере, стоит $500, основываясь на уязвимости Shopify, которая могла стоить до $1000.

Я нажал кнопку отправки и пошёл спать. Когда я проснулся, HackerOne ответил с поздравлениями и сказал, что они исправили эту и некоторые другие уязвимые корзины. Успех! И согласно их правилам, когда они присуждают вознаграждение, они учитывают потенциальные риски безопасности, включая те, которые я мог пропустить, но которые существовали.

Важные выводы:

Есть несколько важных выводов:

1. Не недооценивайте свои способности и вероятность ошибок разработчиков. HackerOne — отличная команда с отличными специалистами по безопасности. Но люди могут ошибаться. Бросьте вызов своим предположениям.

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

3. Всё зависит от мелочей. Если вы знаете об уязвимости, вы будете знать, что искать и проверять. Чтение этой книги — хорошее начало.

4. Как я уже говорил, повторю ещё раз: атакуйте поверхность, которая лучше всего соответствует сайту, и услуги, используемые компанией. Выходите за рамки привычного.

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

Сложность: средняя

URL: нет

Ссылка на отчёт: https://hackerone.com/reports/128085

Дата отчёта: 03.04.2016

Вознаграждение: нет

Описание:

3 апреля Jobert Abma (сооснователь HackerOne) сообщил GitLab о возможности входа злоумышленника в учётную запись жертвы при включённой двухфакторной аутентификации.

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

Здесь Jobert заметил, что после ввода имени пользователя и пароля отправляется токен для завершения входа. При отправке этого токена POST-запрос выглядит следующим образом:

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

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

212421 
----------1881604860-

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

POST /users/sign_in HTTP/1.1 
Host:
``` Я также видел, что это можно сделать с помощью команды ping. Однако независимо от метода, теперь у него есть IP-адрес поддомена, и с помощью команды sudo namp -sSV -p- 31.192.117.70 -oA stage__ph -T4 & он получил:

Starting Nmap 6.47 ( http://nmap.org ) at 2016-06-07 14:09 CEST Nmap scan report for 31.192.117.70 Host is up (0.017s latency). Not shown: 65532 closed ports PORT STATE SERVICE VERSION 80/tcp open http nginx 443/tcp open http nginx 60893/tcp open memcache Service detection performed.Please report any incorrect results at http://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 22.73 seconds

Разберём команду:

+   Флаг `-sSV` определяет тип пакета, который будет отправлен на сервер, сообщая Nmap о попытке и определении любых служб на открытых портах.

+  `-p-` сообщает серверу проверить все 65 535 портов (по умолчанию проверяется только 1000 наиболее часто используемых портов).

+ `31.192.117.70` — это IP-адрес для сканирования.

+ `-oA stage__ph` сообщает Nmap вывести результаты в трёх основных форматах один раз, используя имя файла stage__ph.

+ `-T4` определяет время задачи (опции от 0 до 5, чем больше число, тем быстрее).

Что касается результатов, важно отметить, что порт 60893 открыт, и Nmap считает, что он работает под управлением Memcache. Для тех, кто не знаком, Memcache — это кэш-сервис, использующий пары ключ-значение для хранения произвольных данных. Обычно он используется для ускорения работы веб-сайтов за счёт более быстрого обслуживания контента. Аналогичный сервис — Redis.

Обнаружение само по себе не является уязвимостью, но является опасным сигналом (хотя руководство по установке рекомендует сделать его недоступным для публичного доступа в качестве меры безопасности). После тестирования оказалось, что Pornhub не включил никаких мер безопасности. Andy может подключиться к сервису через netcat без необходимости имени пользователя и пароля. После подключения он выполняет команды для получения версии, состояния и других данных, чтобы подтвердить наличие уязвимости.

Однако злоумышленник может использовать его для:

+ создания отказа в обслуживании путём непрерывной записи и удаления кэша, что приводит к постоянной занятости сервера (в зависимости от конфигурации сайта).

+ DOS-атак путём заполнения сервиса мусорными данными кэша (также зависит от конфигурации сайта).

+ выполнения межсайтовых скриптинговых атак путём внедрения вредоносного JS-контента в качестве действительных данных кэша для предоставления пользователям.

+ возможно, выполнения SQL-инъекций, если данные memcache хранятся в базе данных.

> **Заключение**

> Поддомен и более широкая сетевая конфигурация представляют собой огромный потенциал для проникновения. Если вы заметили программу, содержащую ` *.SITE.com` в домене, попробуйте найти возможные уязвимые поддомены, а не гоняться за низко висящими плодами на основном сайте, потому что их может найти каждый. Также стоит потратить время на то, чтобы ознакомиться с некоторыми инструментами, такими как Nmap, Eyewitness, KnockPy и другими. Это поможет вам понять точку зрения Andy.

## **Вывод**

Логические уязвимости в приложениях не всегда связаны с кодом. Напротив, их использование требует острого наблюдения и выхода за рамки привычного мышления. Всегда обращайте внимание на инструменты и сервисы, которые могут использоваться другими сайтами, поскольку они представляют новые векторы атак. Сюда входят библиотеки JavaScript, используемые сайтом для рендеринга контента.

Их обнаружение требует использования прокси-сервера, который позволяет вам манипулировать некоторыми значениями перед отправкой на сайт, который вы используете. Попробуйте изменить любые значения, связанные с распознаванием вашей учётной записи. Это может включать создание двух разных учётных записей, чтобы у вас было два набора действительных учётных данных, что может быть полезно. Одновременно ищите скрытые или редко используемые терминалы, которые можно использовать для использования функций, к которым случайно получают доступ.

Также следует обращать внимание на определённые типы транзакций. Разработчики иногда не обрабатывают условия конкуренции на уровне базы данных (особенно в NoSQL). То есть их код может остановить вас, но если вы заставите код выполняться достаточно быстро, например, почти одновременно, вы можете обнаружить статические условия. Убедитесь, что вы несколько раз протестировали всё в этой области, так как попытки не всегда успешны, как в случае со Starbucks.

Наконец, обратите внимание на новые функции — они обычно демонстрируют новые области для тестирования. И если возможно, автоматизируйте свои тесты, чтобы лучше использовать своё время.