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

Уязвимости в логике приложений отличаются от тех, что мы обсуждали до этого момента. В то время, как HTML-инъекции, HTML Parameter Pollution и XSS включают отправку какого либо вида потенциально вредоносных данных, уязвимости, основанные на аутентификации, включают манипулятивные сценарии и использование багов в коде приложения.

Хорошим примером этого типа атак можно назвать атаку, осуществленную Егором Хомяковым в отношении GitHub, который использует Ruby on Rails. Если вы незнакомы с Rails, это очень популярный веб-фреймворк, который по умолчанию заботится о множестве вещей при разработке сайтов.

В марте 2012 Егор указал сообществу Rails, что по умолчанию, Rails принимает все отправляемые ему параметры и использует эти значения для обновления записей в базе данных (в зависимости от реализации разработчиками). Идея разработчиков ядра Rails состояла в том, что веб-разработчики, использующие Rails, должны нести ответственность за закрытие этой бреши в безопасности приложения и определять, какие значения могут быть отправлены пользователем для обновления записей в БД. Это поведение уже было хорошо известно в сообществе, но тема на GitHub показывает, насколько малое их число оценило риски, которые нес такой подход.

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

Как я уже сказал, взлом стал возможен через бэкенд-код GitHub, который не аутентифицировал корректным образом действия Егора, который не должен был иметь возможность отправить значения с датой создания, используемые впоследствии для обновления записей в БД. В этом случае, Егор обнаружил то, что называется уязвимостью mass assignment.

[ad name=»Responbl»]

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

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

Примеры

1. Обход администраторских привилегий на Shopify

Сложность: Низкая
Url: shop.myshopify.com/admin/mobile_devices.json Ссылка на отчет: https://hackerone.com/reports/10093814 Дата отчета: 22 ноября 2015
Выплаченное вознаграждение: $500
Описание:

Shopify огромная и устойчивая платформа, которая включает и веб-интерфейс, и API. В этом примере API не валидировал права доступа, тогда как веб-интерфейс осуществлял эту валидацию. В результате, администраторы магазинов, которые не должны были получать уведомления на почту, могли обойти настройки безопасности при помощи манипуляции с API и в результате могли получать уведомления на свои устройства от Apple.

В соответствии с отчетом, хакеру нужно было лишь:

• Войти в приложение Shopify для телефона под аккаунтом с полным доступом
• Перехватить POST-запрос к /admin/mobile_devices.json
• Удалить все настройки прав доступа для этого аккаунта
• Удалить добавленное уведомление на мобильный
• ВоспроизвестиPOST-запроск/admin/mobile_devices.json

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

[ad name=»Responbl»]

Выводы

Здесь два ключевых вывода. Во-первых, не всегда необходимо осуществлять инъекцию кода, HTML или чего-либо еще. Всегда используйте прокси и смотрите, какая информация передается сайту и играйтесь с ней, чтобы увидеть, что произойдет. В этом случае для обхождения проверок безопасности нужно было лишь удалить параметры из POST-запроса. Во-вторых, еще раз, не все атаки основаны на HTML-страницах. Эндпоинты API всегда представляют потенциальную зону уязвимости, так что убедитесь, что рассматриваете и тестируете обе части приложения.

2. Starbucks Race Conditions

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

Url: Starbucks.com

Ссылка на отчет: http://sakurity.com/blog/2015/05/21/starbucks.html15

Дата отчета: 21 мая 2015

Выплаченное вознаграждение: $0

Описание:

Если вы не знакомы с race condition, то, в общих чертах, эта уязвимость становится возможной, когда два потенциальных

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

Вот пример:

1. Вы входите на сайт своего банка со своего телефона и запрашиваете перевод $500 с одного счета, остаток на котором равен всего $500, на другой счет.
2. Запрос выполняется слишком долго (но все еще выполняется), так что вы входите на сайт банка уже со своего ноутбука и совершаете тот же самый запрос на перевод денег еще раз.
3. Запрос,созданныйсноутбука,завершаетсяпочтимгновенно, но в этот же момент завершается и запрос, созданный с телефона.
4. Вы обновляете ваши банковские счета и видите $1000 на счету, куда пытались перевести деньги. Это значит, что процесс выполнился дважды, чего не должно было произойти, поскольку у вас изначально было лишь $500.

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

Возвращаясь к этому примеру, Егор протестировал перевод денег с одной карты Starbucks и обнаружил, что он может успешно воспроизвести race condition. Запросы создавались почти одновременно при помощи программы cURL.

[ad name=»Responbl»]

Выводы

Race conditions являются интересным видом уязвимостей, иногда присутствующие в приложениях, которые работают с каким-либо видом баланса, например, деньгами, кредитами, и так далее. Эту уязвимость не всегда можно обнаружить с первой попытки и может потребоваться совершить несколько повторных одновременных запросов. В нашем примере Егор сделал 6 запросов, прежде чем сумел воспроизвести уязвимость. Однако помните, что тестирование на наличие race condition создаст определенный трафик и постарайтесь избегать постоянных попыток забросать сайт тестовыми запросами.

Продолжение следует.

Оглавление:

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

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

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

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

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

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

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

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

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