Захват поддомена. Уроки хакинга. Глава 10.

В результате, злоумышленник может захватить uwn-images.s3website-us-west-1.amazonaws.com и разместить там сайт. Предполагая, что он может сделать сайт похожим на Ubiquiti, уязвимость здесь заключается в обмане пользователей, сборе их личной информации и получении их аккаунтов.

Выводы

записи DNS представляет новую и уникальную возможность раскрыть уязвимые места. Используйте KnockPy для проверки существования поддоменов, а затем удостоверьтесь, что они указывают на допустимые ресурсы, уделяя особое внимание сторонним поставщикам услуг, таким как AWS, Github, Zendesk и т.д. услуги, которые позволяют регистрировать кастомные URL.

[ad name=»Responbl»]

2. Переадресация Scan.me на Zendesk

Сложность: Низкая
Url: support.scan.me
Ссылка на отчет: https://hackerone.com/reports/11413440
Дата отчета: 2 февраля 2016
Выплаченное вознаграждение: $1,000

Описание:

Так же, как в примере с Ubiquiti, scan.me (приобретение Snapchat) содержал CNAME запись, указывающую псевдоним поддомена support.scan.me на scan.zendesk.com. В этой ситуации хакер harry_mg смог захватить scan.zendesk.com, на который переадресовывал запросы к support.scan.me.

Вот и все. Выплата вознаграждения составила $1,000…

Выводы

БУДЬТЕ ВНИМАТЕЛЬНЫ! Первое сообщение указанное в описании от Detectify было написано в октябре 2014 г. Эта уязвимость была найдена февраля 2016 и совершенно не была сложной. Успешная охота за ошибками требует наблюдательности.

[ad name=»Responbl»]

Подмена официальных токенов доступа Facebook

Сложность: Высокая Url: facebook.com
Ссылка на отчет: Philippe Harewood Swiping Facebook Official Access Tokens41
Дата отчета: 29 февраля 2016

Описание:

Я не знаю, попадает ли это под техническое определение захвата поддомена (если такое существует), но я думаю, это отличная находка, позволившая Филиппу похищать любой аккаунт Facebook с минимальными усилиями.

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

Я надеюсь, вы заметили здесь потенциал для эксплуатации. Если OAuth позволяет пользовательскую авторизацию, воздействие от некорректной реализации может быть огромным. Учитывая процесс, Филипп предоставил отличное изображение, объясняющее то, как был реализован протокол:

Вкратце, здесь мы видим:

1. Пользователь запрашивает использование Facebook API для каких-либо целей через какое-либо приложение
2. ЭтоприложениеперенаправляетпользователянаFacebook API, чтобы тот дал разрешение
3. Facebook API предоставляет пользователю код и перенаправляет его к приложению
4. Приложение берет код и делает запрос к Facebook API, чтобы получить токен
5. Facebook возвращает токен приложению, которое получает право осуществлять запросы от имени пользователя

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

Значительная уязвимость здесь заключена в том, что Facebook предоставляет токен доступа приложению в пункте 5.

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

Оказалось, что каждый пользователь Facebook имеет авторизованные его аккаунтом приложения, но они могут не использо-
ваться явно. В соответствии с его текстом, примером является “Content Tab of a Page on www”, который загружает некоторые запросы к API на фанатские страницы Facebook. Список приложений доступен по адресу https://www.facebook.com/search/me/appsused.

Просмотрев этот список, Филипп нашел приложение, которое было неправильно настроено и могло быть использовано для перехвата токенов запросом вроде следующего:

https://facebook.com/v2.5/dialog/oauth?response_type=to\
2  ken&display=popup&client_id=APP_ID&redirect_uri=REDIREC\
3  T_URI

Здесь приложение, которые он хотел использовать для APP_ID имело полные права доступа, было уже авторизованным и неправильно сконфигурированным подразумевается, что шаги 1 и 2 уже выполнены, и пользователь не получил всплывающего окна, в котором должен быть дать права приложению, потому что он уже их дал! Кроме того, поскольку REDIRECT_URI не принадлежало Facebook, Филипп мог завладеть им в точности как поддоменом. В результате, когда пользователь кликал по его ссылке, его перенаправляло на:

1  http://REDIRECT_URI/access_token_appended_here

что Филипп мог использовать для получения всех токенов доступа и захвата аккаунтов Facebook! Что еще круче, судя по его посту, когда ты имеешь официальный токен доступа Facebook, ты имеешь доступ к токенам других ресурсов Facebook, таких, как Instagram! Все, что ему нужно было сделать это осуществить запрос к Facebook GraphQL (API для получения данных от Facebook) и ответ включал бы access_token для подразумеваемого приложения.

[ad name=»Responbl»]

Выводы

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

Кроме того, если вам понравился этот пример, загляните в блог Филиппа (он включен в главу Ресурсы и в Hacking Pro Tips Interview он сидит he sat down with me to do он предоставил множество отличных советов!).

Заключение главы

Захват поддоменов на самом деле совершенно не трудно осуществить, когда в DNS записях сайта есть неиспользуемая запись, указывающая на стороннего поставщика услуг. Существует немало способов обнаружить их, включая использование KnockPy, Google Dorks (site:*.hackerone.com), Recon-ng, и так далее. Использование их всех описано в главе Инструменты этой книги.

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

Оглавление:

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

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

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

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

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

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

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

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

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