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

Повышение полномочий на Binary.com

Сложность: Низкая
Url: binary.com
Ссылка на отчет: https://hackerone.com/reports/9824716
Дата отчета: 14 ноября 2015
Выплаченное вознаграждение: $300

Описание:

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

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

Перед взломом, если бы вы были залогинены на Binary.com/cashier и посмотрели в исходный HTML страницы, вы бы заметили тег <iframe>, который содержал параметр PIN. Этот параметр
на самом деле являлся ID вашего аккаунта.

Далее, если бы вы отредактировали HTML и вставили другой PIN, сайт автоматически выполнил бы действие от имени нового аккаунта, без валидации пароля или других данных. Другими словами, сайт считал бы вас владельцем аккаунта, ID которого вы только что вставили.

Еще раз, все что было нужно — знать номер чьего-нибудь аккаунта. Вы могли даже изменить событие, выполняемое в iframe на PAYOUT чтобы инициализировать выплату на другой счет. Однако, несмотря на то, что Binary.com сообщает, что все выплаты требуют ручного рассмотрения сотрудником, это не значит, что подмена была бы замечена.

[ad name=»Responbl»]

Выводы

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

Если вы обнаружили, что передается какой-либо вид данных доступа, посмотрите, зашифрованы ли они и попробуйте поиграться с ними. В этом случае pin был просто CRXXXXXX, хотя пароль был 0e552ae717a1d08cb134f132… Очевидно, что PIN не был зашифрован, а пароль — был. Незашифрованные значения являются хорошей стартовой точкой для начала экспериментов.

[ad name=»Responbl»]

Манипуляции с Signal на HackerOne

Сложность: Низкая
Url: hackerone.com/reports/XXXXX
Ссылка на отчет: https://hackerone.com/reports/10630517 Дата отчета: December 21, 2015
Выплаченное вознаграждение: $500
Описание:

В конце 2015 HackerOne представили новую функциональность своего сайта, названную Signal. Вкратце, она помогает определить эффективность предыдущих отчетов хакера о уязвимостях после того, как эти отчеты были закрыты. Здесь важно заметить, что белые хакеры могут закрывать свои собственные отчеты на HackerOne, если считают, что результат не изменит их Репутацию и Signal…

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

Вот и все.

Выводы

Хотя описание довольно краткое, нельзя переоценить выводы, проявляйте внимание к новой функциональности! Когда сайт внедряет новую функциональность, это как свежее мясо для белых хакеров. Новая функциональность предоставляет возможность исследовать новый код и искать баги. То же самое было и с Shopify Twitter CSRF и XSS-уязвимостями Facebook. Чтобы не пропускать большую часть нововведений, стоит изучить компании и подписаться на их блоги, чтобы получать уведомления, когда они выпускают что-то новое. А затем тестировать.

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

Сложность: Средняя
Url: cdn.shopify.com/assets
Ссылка на отчет: https://hackerone.com/reports/10630518 Дата отчета: 9 ноября 2015
Выплаченное вознаграждение: $1000
Описание:

Amazon Simple Storage, S3, является сервисом, который позволяет клиентам хранить и обслуживать файлы с облачных серверов Amazon. Shopify, как и многие другие сайты, использует S3 для хранения и обслуживания статического контента, такого, как изображения.

Весь набор Amazon Web Services, AWS, очень устойчив и включает систему управления правами доступа, позволяющую администраторам определять права доступа для каждого от

дельного сервиса, включая S3. Права доступа включают в себя возможность создавать бакеты S3 (бакет это что-то вроде директории-хранилища), читать из бакетов и записывать в бакеты, помимо всего остального.

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

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

[ad name=»Responbl»]

Выводы

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

Оглавление:

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

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

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

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

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

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

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

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

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