Сегодня мы бы хотели рассказать об одной старой и почти всеми забытой атаке под названием DNS rebinding. Первые разговоры о ней начались еще в 2007 году, однако тогда эксперты из области практической информационной безопасности не уделяли ей должного внимания в связи с особенностями эксплуатации этой атаки, а также мало ощутимыми, как тогда казалось, последствиями. Сегодня мы попробуем убедить в обратном их и вас, в частности, продемонстрировав, что в современном мире эта атака обрела второе дыхание и более не кажется такой безобидной.
Рассмотрим следующую схему:
У нас есть компьютер жертвы с IP 192.168.0.2 в локальной сети, а также в ней имеется роутер с IP-адресом 192.168.0.1. Цель злоумышленника, управляющего сервером с адресом 13.37.13.37 и доменным именем hacker.com (также, на ip-шнике крутится наш собственный DNS-сервер, содержащий информацию о домене), – получить доступ к роутеру в локальной сети.
Для эксплуатации техники DNS rebinding нам необходимо заманить жертву на наш вредоносный сайт. Предположим, что нам это удалось.
Давайте теперь подробно разберем, как работает атака.
В первую очередь, браузер обращается к DNS-серверам с запросом А-записи:
Цепочка DNS-серверов приводит к нашему серверу, который, в свою очередь, выдает стандартный ответ, содержащий истинный IP-адрес вредоносного сайта, а также указывает необходимый нам TTL, в данном случае 59.
Далее браузер делает стандартный HTTP-запрос на полученный IP.
На следующем этапе сервер отвечает HTML-страницей с javascript кодом, обращающимся на наш же домен.
Теперь, пока не истечет TTL и пользователь будет находится на сайте, будет выполняться полученный выше javascript. Как только TTL закончится, браузер снова сделает запрос A-записи.
В это время наш javascript продолжает выполняться, а управляемый нами DNS-сервер ответит A-записью с IP-адресом из локальной сети, куда злоумышленник хочет достучаться.
Так как домен, порт и протокол остаются неизменными, то SOP не нарушается, и в результате браузер обращается по домену pew.hacker.com, однако стучаться он уже будет на заветный и недосягаемый роутер.
Как результат, мы спокойно получаем ответ от роутера и перенаправляем его к себе, встроив соответствующий функционал в javascript код, подгруженный ранее.
Итак, давайте резюмируем вышесказанное:
С этим разобрались! У многих может возникнуть резонный вопрос: «Ну и что?», ведь для эксплуатации нужно знать внутренние IP-адреса сервисов, удержать пользователя определенное время и т.д.
Да, однако, с приходом стримминговых сервисов, видео хостингов, старых добрых порносайтов и прочих платформ, где люди надолго зависают, у злоумышленника будет достаточно времени, чтобы провести атаку. Что касательно адресов, то они зачастую бывают стандартными или легко предугадываемыми.
Но это всё в теории, а что же на практике? Мы выбрали 4 наиболее актуальные сферы в 2019, где произошли инциденты, связанные с атакой DNS rebinding, это:
Давайте рассмотрим каждый топик по порядку и выясним, действительно ли всё так безобидно?
Google home – это умный помощник от компании Google. Этот девайс имеет (или имел в прошлом) API, не требующий какой-либо аутентификации для управления устройством. Он предоставляет ряд возможностей, таких как:
Примерный сценарий атаки: злоумышленник может деанонимизировать пользователя, получая координаты ближайших WI-FI точек. Очевидно, что тут никакой VPN не спасет.
Данные колонки от компании Sonos подымают в локальной сети UPnP веб-сервер, который дает доступ к ряду интересных страниц:
В данном случае злоумышленник имеет возможность исполнять команду traceroute для сканирования топологии внутренней сети.
Это один из наших самых любимых кейсов. Данная модель термостата также обладает API без какой-либо авторизации и позволяет изменять:
Как результат, злоумышленник может заставить свою жертву нехило попотеть, но если говорить серьезно, то подобная атака на термостат, например, медицинского учреждения может привести к довольно малоприятным последствиям.
У телевизоров от компании Roku всё тот же недуг – API без аутентификации.
API позволяет:
В данном случае максимум, что грозит пользователю, это утечка чувствительных данных, что тоже неприятно.
Этот IoT-девайс сегодня есть дома почти у каждого. Ни для кого не секрет, что многие рядовые пользователи не меняют стандартные пароли от админ-панелей своих роутеров. При помощи DNS rebinding нам ничего не мешает совершить попытку логина со стандартными учетными данными и получить доступ к админке. В случае, если локальный IP не удается подобрать, на помощь приходит WebRTC.
Выделим некоторые возможности, которые предоставляет DNS rebinding при работе с IoT:
Теперь поговорим о криптокошельках. Первый кейс из рассмотренных – это клиент для ethereum-кошельков, под названием Geth. Здесь ящик пандоры кроется в работе JSON-RPC сервиса. Для начала давайте разберемся что это такое. JSON-RPC – это протокол удаленного вызова процедур в JSON формате. Выглядит это всё примерно так:
Большинство клиентов запускают этот сервис на localhost:8545, а он, в свою очередь, предоставляет набор интересных функций, таких как eth_sendTransaction и так далее.
Теперь пример, каким образом можно без ведома пользователя и с использованием атаки DNS rebinding получить его баланс и адрес кошелька:
Далее на очереди у нас клиент для EOSIO-кошельков. Сам keosd запускается на localhost:8900 и автоматически подписывает любые действия приложения на 15 минут после ввода авторизационных данных. Углубившись в API, можно опять обнаружить интересный функционал. Для наглядности, используя продемонстрированный ниже запрос, можно получить публичный ключ пользователя:
Блок инцидентов, связанных с Desktop-приложениями, хочется начать с относительно нашумевшей уязвимости в торрент-клиенте Transmission.
Здесь проблема кроется во всё том же JSON-RPC, который мы рассмотрели чуть выше. В данном случае он позволяет изменять пользовательские настройки, например, изменять папку для загрузки файлов:
С одной стороны, вроде бы ничего серьезного, однако если указать вместо папки контролируемую злоумышленником smb share (в случае, если клиент использует Windows клиент), то можно перехватить хеш пользователя, который может быть использован в дальнейшем.
Этот товарищ имеет у себя в арсенале всё тот же JSON-RPC сервис, позволяющий изменять конфигурационные файлы пользователя, а также скачивать файлы.
В данном случае требуется аутентификация, однако учетные данные доступны из http://localhost:19575/users.conf. Как же можно это использовать?
Для начала делаем следующий запрос:
После получения токена меняем папку загрузки на папку, где располагаются программы, запускаемые при старте системы:
И, наконец, даем команду на скачивание необходимой полезной нагрузки:
В итоге, evil.exe будет запущен после следующей перезагрузки.
Minikube – утилита командной строки для настройки и запуска однонодового кластера Kubernetes в виртуальной машине на локальном компьютере.
Он всегда висит на 192.168.99.100, а web-интерфейс доступен на 3000 порту. В итоге у злоумышленника есть возможность создать зловредный контейнер с общей папкой с основной системой.
Первый делом необходимо получить csrf токен.
Далее нужно создать контейнер, а для этого послать следующий запрос:
Давайте разберем, что он делает. В нем мы указываем, что при запуске контейнера нам нужно пробросить reverse-shell, а также примонтировать папку Users с основной системы:
Для фреймворка Ruby on Rails существует гем, позволяющий выполнять Ruby-код прямо в браузере.
Давайте попробуем разобраться, что нам для этого понадобится?
Для начала нам нужно обратиться на несуществующую страницу:
Далее мы делаем попытку обращения к консоли через браузер:
Ну и, наконец, формируем запрос за запуск приложения калькулятор (в данном примере вектор для MAC OS X):
Не только разработчики и обычные пользователи подвержены атаке типа DNS rebinding, но и геймеры тоже. Здесь мы опять же встречаемся с проблемой JSON-RPC сервиса, торчащим в данном случае на localhost на 1120 порту. Сервис дает возможность производить апдейты, изменять настройки и другие различные обслуживающие опции.
В данном случае поддерживается аутентификация, но пройти её, делая запросы от localhost, не составляет труда:
Как результат, можно добиться чего-то подобного:
Более подробно можно ознакомиться тут.
Ну, и напоследок, осталось самое интересное – облака. Суть в том, что облачные сервисы часто используются для размещения ПО, которое проводит аналитику приходящих на сайт пользователей. Например, переходя headless браузером по ссылке из заголовка Referer, чтобы скраулить ресурс, с которого клиент перешел на сайт. Этот вектор атаки так же можно использовать, ведь по сути headless браузер — это полноценный веб-браузер без графического интерфейса, но с поддержкой DOM, JS и всего остального.
Возвращаясь к нашим баранам, что мы можем сделать в данном случае? Ведь для атаки нам необходимо задержать пользователя (в данном случае бота) на странице. Что ж, для этого мы можем использовать на странице изображение, имеющее Content-Length на единицу больше, чем оно есть на самом деле. Как результат, бот будет думать, что картинка ещё не прогрузилась и задержится на нашей странице, а далее, мы применяем нашу стандартную технику DNS rebinding.
В итоге, так как запросы мы будем слать от доверенного лица, мы можем творить множество веселых вещей. Например:
Вернемся непосредственно к Amazon. AWS EC2 имеет такой функционал, как Instance Metadata Service. Она позволяет любой EC2 сущности использовать REST API, находящийся по адресу 169.254.169.254, раскрывающий информацию об инстансе.
Например, вот небольшой список подобных сервисов у различных облаков:
Теперь давайте рассмотрим кейс, в котором мы побалуемся с AWS.
Для начала пусть бот сделает запрос к API:
В ответе мы можем получить конфиденциальную информацию, например, креды в скрипте, который запускается при старте машины:
Далее мы можем вытащить имя ноды, с которой будем дальше работать:
Далее мы сделаем следующее обращение по уже известному имени и – бинго!
Мы получили различную информацию о пользователе, такую как AccessKeyId, SecretAccessKey, Token и т.д.
Получив эти данные, мы можем использовать их для авторизации через консольный клиент:
Давайте выделим общие слабые точки, которые мы заметили при эксплуатации атаки типа DNS rebinding:
Таким образом, несмотря на различные доводы со стороны экспертов в области практической информационной безопасности, атака данного типа рождается заново в эпоху IoT, облачных сервисов, криптовалют и так далее, даже несмотря на необходимость задержки клиента на стороне злоумышленника, ведь в мире онлайн-кинотеатров, видеохостингов и прочих сервисов, предоставляющих контент пользователю, сделать это не составляет особого труда. Поэтому будьте бдительны при путешествии в онлайн-мире, при покупке очередного умного помощника, ну и при разработке, естественно.
Чтобы взломать сеть Wi-Fi с помощью Kali Linux, вам нужна беспроводная карта, поддерживающая режим мониторинга…
Работа с консолью считается более эффективной, чем работа с графическим интерфейсом по нескольким причинам.Во-первых, ввод…
Конечно, вы также можете приобрести подписку на соответствующую услугу, но наличие SSH-доступа к компьютеру с…
С тех пор как ChatGPT вышел на арену, возросла потребность в поддержке чата на базе…
Если вы когда-нибудь окажетесь в ситуации, когда вам нужно взглянуть на спектр беспроводной связи, будь…
Elastic Security стремится превзойти противников в инновациях и обеспечить защиту от новейших технологий злоумышленников. В…