Хабрахабр

DNS rebinding в 2k19, или как по-настоящему вспотеть, посетив порносайт

Сегодня мы бы хотели рассказать об одной старой и почти всеми забытой атаке под названием DNS rebinding. Всем привет! Сегодня мы попробуем убедить в обратном их и вас, в частности, продемонстрировав, что в современном мире эта атака обрела второе дыхание и более не кажется такой безобидной. Первые разговоры о ней начались еще в 2007 году, однако тогда эксперты из области практической информационной безопасности не уделяли ей должного внимания в связи с особенностями эксплуатации этой атаки, а также мало ощутимыми, как тогда казалось, последствиями.

Что такое DNS rebinding?

Рассмотрим следующую схему:

168. У нас есть компьютер жертвы с IP 192. 2 в локальной сети, а также в ней имеется роутер с IP-адресом 192. 0. 0. 168. Цель злоумышленника, управляющего сервером с адресом 13. 1. 13. 37. 37 и доменным именем hacker.com (также, на ip-шнике крутится наш собственный DNS-сервер, содержащий информацию о домене), – получить доступ к роутеру в локальной сети.

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

Давайте теперь подробно разберем, как работает атака.

В первую очередь, браузер обращается к DNS-серверам с запросом А-записи:

Цепочка DNS-серверов приводит к нашему серверу, который, в свою очередь, выдает стандартный ответ, содержащий истинный IP-адрес вредоносного сайта, а также указывает необходимый нам TTL, в данном случае 59.

Далее браузер делает стандартный HTTP-запрос на полученный IP.

На следующем этапе сервер отвечает HTML-страницей с javascript кодом, обращающимся на наш же домен.

Как только TTL закончится, браузер снова сделает запрос A-записи. Теперь, пока не истечет TTL и пользователь будет находится на сайте, будет выполняться полученный выше javascript.

В это время наш javascript продолжает выполняться, а управляемый нами DNS-сервер ответит A-записью с IP-адресом из локальной сети, куда злоумышленник хочет достучаться.

Так как домен, порт и протокол остаются неизменными, то SOP не нарушается, и в результате браузер обращается по домену pew.hacker.com, однако стучаться он уже будет на заветный и недосягаемый роутер.

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

Итак, давайте резюмируем вышесказанное:

  • Пользователь посещает сайт, получая реальный IP-адрес и короткий TTL
  • Находясь на сайте, браузер делает обращения к тому же домену, где находится пользователь. Как только истекает время жизни кэша, браузер снова запрашивает IP домена.
  • Далее наш DNS-сервер выдает вместо настоящего адреса, IP-адрес внутреннего сервиса (в нашем случае – роутера)
  • После запрос идет по домену на роутер, а результат нам отправляет подгруженный заранее пользователем javascript.

У многих может возникнуть резонный вопрос: "Ну и что?", ведь для эксплуатации нужно знать внутренние IP-адреса сервисов, удержать пользователя определенное время и т.д. С этим разобрались!

Что касательно адресов, то они зачастую бывают стандартными или легко предугадываемыми. Да, однако, с приходом стримминговых сервисов, видео хостингов, старых добрых порносайтов и прочих платформ, где люди надолго зависают, у злоумышленника будет достаточно времени, чтобы провести атаку.

Мы выбрали 4 наиболее актуальные сферы в 2019, где произошли инциденты, связанные с атакой DNS rebinding, это: Но это всё в теории, а что же на практике?

  • IoT
  • Crypto wallets
  • Desktop applications
  • Clouds

Давайте рассмотрим каждый топик по порядку и выясним, действительно ли всё так безобидно?

Iot

Google home

Этот девайс имеет (или имел в прошлом) API, не требующий какой-либо аутентификации для управления устройством. Google home – это умный помощник от компании Google. Он предоставляет ряд возможностей, таких как:

  • Проигрывание контента
  • Сканирование
  • Перезагрузка
  • Подключение в WI-FI сетям и т.д.

Очевидно, что тут никакой VPN не спасет. Примерный сценарий атаки: злоумышленник может деанонимизировать пользователя, получая координаты ближайших WI-FI точек.

Sonos WIFI speakers

Данные колонки от компании Sonos подымают в локальной сети UPnP веб-сервер, который дает доступ к ряду интересных страниц:

  • 192.168.1.76:1400/support/review – выплевывает вывод некоторых UNIX-команд
  • 192.168.1.76:1400/tools – позволяет запускать некоторые UNIX-команды

В данном случае злоумышленник имеет возможность исполнять команду traceroute для сканирования топологии внутренней сети.

Radio Thermostat CT50

Данная модель термостата также обладает API без какой-либо авторизации и позволяет изменять: Это один из наших самых любимых кейсов.

  • Климат-режим
  • Температуру
  • Режим подсветки и прочие настройки

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

Roku TV

У телевизоров от компании Roku всё тот же недуг – API без аутентификации.

API позволяет:

  • Запускать различные приложения
  • Проигрывать контент
  • Совершать поисковые запросы по системе и т. д.

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

Любой WI-FI роутер

Ни для кого не секрет, что многие рядовые пользователи не меняют стандартные пароли от админ-панелей своих роутеров. Этот IoT-девайс сегодня есть дома почти у каждого. В случае, если локальный IP не удается подобрать, на помощь приходит WebRTC. При помощи DNS rebinding нам ничего не мешает совершить попытку логина со стандартными учетными данными и получить доступ к админке.

Итог по IoT

Выделим некоторые возможности, которые предоставляет DNS rebinding при работе с IoT:

  • Возможность деанонимизировать пользователя
  • Возможность сканировать локальную сеть
  • Издеваться над пользователем
  • Что угодно, в зависимости от функционала IoT-устройства

Crypto wallets

Geth

Первый кейс из рассмотренных – это клиент для ethereum-кошельков, под названием Geth. Теперь поговорим о криптокошельках. Для начала давайте разберемся что это такое. Здесь ящик пандоры кроется в работе JSON-RPC сервиса. Выглядит это всё примерно так: JSON-RPC – это протокол удаленного вызова процедур в JSON формате.

Большинство клиентов запускают этот сервис на localhost:8545, а он, в свою очередь, предоставляет набор интересных функций, таких как eth_sendTransaction и так далее.

Теперь пример, каким образом можно без ведома пользователя и с использованием атаки DNS rebinding получить его баланс и адрес кошелька:

EOSIO keosd wallet

Сам keosd запускается на localhost:8900 и автоматически подписывает любые действия приложения на 15 минут после ввода авторизационных данных. Далее на очереди у нас клиент для EOSIO-кошельков. Для наглядности, используя продемонстрированный ниже запрос, можно получить публичный ключ пользователя: Углубившись в API, можно опять обнаружить интересный функционал.

Итог по Crypto wallets:

  • злоумышленник может красть деньги пользователя
  • злоумышленник может изменять различные пользовательские настройки
  • возможность деанонимизации пользователя

Desktop applications

Transmission client

Блок инцидентов, связанных с Desktop-приложениями, хочется начать с относительно нашумевшей уязвимости в торрент-клиенте Transmission.

В данном случае он позволяет изменять пользовательские настройки, например, изменять папку для загрузки файлов: Здесь проблема кроется во всё том же JSON-RPC, который мы рассмотрели чуть выше.

С одной стороны, вроде бы ничего серьезного, однако если указать вместо папки контролируемую злоумышленником smb share (в случае, если клиент использует Windows клиент), то можно перехватить хеш пользователя, который может быть использован в дальнейшем.

uTorrent web client

Этот товарищ имеет у себя в арсенале всё тот же JSON-RPC сервис, позволяющий изменять конфигурационные файлы пользователя, а также скачивать файлы.

Как же можно это использовать? В данном случае требуется аутентификация, однако учетные данные доступны из http://localhost:19575/users.conf.

Для начала делаем следующий запрос:

После получения токена меняем папку загрузки на папку, где располагаются программы, запускаемые при старте системы:

И, наконец, даем команду на скачивание необходимой полезной нагрузки:

В итоге, evil.exe будет запущен после следующей перезагрузки.

Minikube

Minikube – утилита командной строки для настройки и запуска однонодового кластера Kubernetes в виртуальной машине на локальном компьютере.

168. Он всегда висит на 192. 100, а web-интерфейс доступен на 3000 порту. 99. В итоге у злоумышленника есть возможность создать зловредный контейнер с общей папкой с основной системой.

Первый делом необходимо получить csrf токен.

Далее нужно создать контейнер, а для этого послать следующий запрос:

В нем мы указываем, что при запуске контейнера нам нужно пробросить reverse-shell, а также примонтировать папку Users с основной системы: Давайте разберем, что он делает.

Ruby on Rails

Для фреймворка Ruby on Rails существует гем, позволяющий выполнять Ruby-код прямо в браузере.

Давайте попробуем разобраться, что нам для этого понадобится?

Для начала нам нужно обратиться на несуществующую страницу:

Далее мы делаем попытку обращения к консоли через браузер:

Ну и, наконец, формируем запрос за запуск приложения калькулятор (в данном примере вектор для MAC OS X):

Blizzard Desktop application

Здесь мы опять же встречаемся с проблемой JSON-RPC сервиса, торчащим в данном случае на localhost на 1120 порту. Не только разработчики и обычные пользователи подвержены атаке типа DNS rebinding, но и геймеры тоже. Сервис дает возможность производить апдейты, изменять настройки и другие различные обслуживающие опции.

В данном случае поддерживается аутентификация, но пройти её, делая запросы от localhost, не составляет труда:

Как результат, можно добиться чего-то подобного:

Более подробно можно ознакомиться тут.

Итог по Desktop Application:

  • злоумышленник может получить RCE на основной системе (также не забываем про VM Escape)
  • злоумышленник может получить доступ к конфиденциальным данным и т.д.

Clouds

Суть в том, что облачные сервисы часто используются для размещения ПО, которое проводит аналитику приходящих на сайт пользователей. Ну, и напоследок, осталось самое интересное – облака. Этот вектор атаки так же можно использовать, ведь по сути headless браузер — это полноценный веб-браузер без графического интерфейса, но с поддержкой DOM, JS и всего остального. Например, переходя headless браузером по ссылке из заголовка Referer, чтобы скраулить ресурс, с которого клиент перешел на сайт.

Ведь для атаки нам необходимо задержать пользователя (в данном случае бота) на странице. Возвращаясь к нашим баранам, что мы можем сделать в данном случае? Как результат, бот будет думать, что картинка ещё не прогрузилась и задержится на нашей странице, а далее, мы применяем нашу стандартную технику DNS rebinding. Что ж, для этого мы можем использовать на странице изображение, имеющее Content-Length на единицу больше, чем оно есть на самом деле.

Например: В итоге, так как запросы мы будем слать от доверенного лица, мы можем творить множество веселых вещей.

  • сканировать внутреннюю сеть
  • авторизовываться во внутренних сервисах (теоретически)
  • красть данные авторизации других сервисов и т.д.

AWS EC2 имеет такой функционал, как Instance Metadata Service. Вернемся непосредственно к Amazon. 254. Она позволяет любой EC2 сущности использовать REST API, находящийся по адресу 169. 254, раскрывающий информацию об инстансе. 169.

Например, вот небольшой список подобных сервисов у различных облаков:

Теперь давайте рассмотрим кейс, в котором мы побалуемся с AWS.

Для начала пусть бот сделает запрос к API:

В ответе мы можем получить конфиденциальную информацию, например, креды в скрипте, который запускается при старте машины:

Далее мы можем вытащить имя ноды, с которой будем дальше работать:

Далее мы сделаем следующее обращение по уже известному имени и – бинго!

Мы получили различную информацию о пользователе, такую как AccessKeyId, SecretAccessKey, Token и т.д.

Получив эти данные, мы можем использовать их для авторизации через консольный клиент:

Общий итог:

Давайте выделим общие слабые точки, которые мы заметили при эксплуатации атаки типа DNS rebinding:

  • API без аутентификации
  • Локальные сервисы без аутентификации
  • Игнорирование Host параметра к запросе
  • Использование http вместо https

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

Источники:

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть