>
Январь 2018
Пн Вт Ср Чт Пт Сб Вс
« Дек    
1234567
891011121314
15161718192021
22232425262728
293031  

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

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

Image result for атака на поддомен

  1. example.com регистрируется в Heroku
  2. example.com создает DNS запись, указывающую переадресацию поддомена subdomain.example.com на unicorn457.heroku.com
  3. example.com не претендует на unicorn457.heroku.com
  4. Злоумышленник забирает unicorn457.heroku.com и дублирует example.com
  5. Весь траффик для subdomain.example.com направляется на вредоносный сайт, который выглядит как example.com

Таким образом, для того чтобы это произошло, должны быть невостребованные DNS записи для внешней службы. Таких как Heroku, Github, Amazon S3, Shopify и т.д. Лучший способ найти их использовать KnockPy, который обсуждается в разделе Инструменты. Он перебирает общий список поддоменов, чтобы проверить их существование.

Примеры Захвата Поддомена.

1. Захват поддомена Ubiquiti

Сложность: Низкая
Url: http://assets.goubiquiti.com
Ссылка на отчет: https://hackerone.com/reports/10969939
Дата отчета: 10 января 2016
Выплаченное вознаграждение: $500

Описание:

Так же, как и в описании для захвата поддомена предполагается, что http://assets.goubiquiti.com содержит запись DNS, указывающую на Amazon S3 для хранения файлов. Но на самом деле такого Amazon S3 хранилища не существует. Скриншот из HackerOne:

Goubiquiti Assets DNS

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

Выводы

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

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 и совершенно не была сложной. Успешная охота за ошибками требует наблюдательности.

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

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

Описание:

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

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

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

Philippe Harewood Facebook OAuth Process

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

  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.

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

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

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

Выводы

Я надеюсь, вы видите, почему этот пример был включен в книгу и эту главу в частности. Самым важным выводом для меня было понимание того, насколько устаревшие ресурсы могут быть использованы при взломе. В предыдущих примерах этой главы это были оставленные 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

[Всего голосов: 9    Средний: 4.7/5]
Share Button

Вам может быть интересно также:

Last updated by at .

Leave a Reply

You can use these HTML tags

<a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">