Сегодня мы бы хотели рассказать об одной старой и почти всеми забытой атаке под названием DNS rebinding. Первые разговоры о ней начались еще в 2007 году, однако тогда эксперты из области практической информационной безопасности не уделяли ей должного внимания в связи с особенностями эксплуатации этой атаки, а также мало ощутимыми, как тогда казалось, последствиями. Сегодня мы попробуем убедить в обратном их и вас, в частности, продемонстрировав, что в современном мире эта атака обрела второе дыхание и более не кажется такой безобидной.
Что такое DNS rebinding?
Рассмотрим следующую схему:
У нас есть компьютер жертвы с 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-адрес и короткий TTL
- Находясь на сайте, браузер делает обращения к тому же домену, где находится пользователь. Как только истекает время жизни кэша, браузер снова запрашивает IP домена.
- Далее наш DNS-сервер выдает вместо настоящего адреса, IP-адрес внутреннего сервиса (в нашем случае – роутера)
- После запрос идет по домену на роутер, а результат нам отправляет подгруженный заранее пользователем javascript.
С этим разобрались! У многих может возникнуть резонный вопрос: «Ну и что?», ведь для эксплуатации нужно знать внутренние IP-адреса сервисов, удержать пользователя определенное время и т.д.
Да, однако, с приходом стримминговых сервисов, видео хостингов, старых добрых порносайтов и прочих платформ, где люди надолго зависают, у злоумышленника будет достаточно времени, чтобы провести атаку. Что касательно адресов, то они зачастую бывают стандартными или легко предугадываемыми.
Но это всё в теории, а что же на практике? Мы выбрали 4 наиболее актуальные сферы в 2019, где произошли инциденты, связанные с атакой DNS rebinding, это:
- IoT
- Crypto wallets
- Desktop applications
- Clouds
Давайте рассмотрим каждый топик по порядку и выясним, действительно ли всё так безобидно?
Iot
Google home
Google home – это умный помощник от компании Google. Этот девайс имеет (или имел в прошлом) API, не требующий какой-либо аутентификации для управления устройством. Он предоставляет ряд возможностей, таких как:
- Проигрывание контента
- Сканирование
- Перезагрузка
- Подключение к WI-FI сетям и т.д.
Примерный сценарий атаки: злоумышленник может деанонимизировать пользователя, получая координаты ближайших WI-FI точек. Очевидно, что тут никакой VPN не спасет.
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-девайс сегодня есть дома почти у каждого. Ни для кого не секрет, что многие рядовые пользователи не меняют стандартные пароли от админ-панелей своих роутеров. При помощи DNS rebinding нам ничего не мешает совершить попытку логина со стандартными учетными данными и получить доступ к админке. В случае, если локальный IP не удается подобрать, на помощь приходит WebRTC.
Итог по IoT
Выделим некоторые возможности, которые предоставляет DNS rebinding при работе с IoT:
- Возможность деанонимизировать пользователя
- Возможность сканировать локальную сеть
- Издеваться над пользователем
- Что угодно, в зависимости от функционала IoT-устройства
Crypto wallets
Geth
Теперь поговорим о криптокошельках. Первый кейс из рассмотренных – это клиент для ethereum-кошельков, под названием Geth. Здесь ящик пандоры кроется в работе JSON-RPC сервиса. Для начала давайте разберемся что это такое. JSON-RPC – это протокол удаленного вызова процедур в JSON формате. Выглядит это всё примерно так:
Большинство клиентов запускают этот сервис на localhost:8545, а он, в свою очередь, предоставляет набор интересных функций, таких как eth_sendTransaction и так далее.
Теперь пример, каким образом можно без ведома пользователя и с использованием атаки DNS rebinding получить его баланс и адрес кошелька:
EOSIO keosd wallet
Далее на очереди у нас клиент для EOSIO-кошельков. Сам keosd запускается на localhost:8900 и автоматически подписывает любые действия приложения на 15 минут после ввода авторизационных данных. Углубившись в 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 в виртуальной машине на локальном компьютере.
Он всегда висит на 192.168.99.100, а web-интерфейс доступен на 3000 порту. В итоге у злоумышленника есть возможность создать зловредный контейнер с общей папкой с основной системой.
Первый делом необходимо получить csrf токен.
Далее нужно создать контейнер, а для этого послать следующий запрос:
Давайте разберем, что он делает. В нем мы указываем, что при запуске контейнера нам нужно пробросить reverse-shell, а также примонтировать папку Users с основной системы:
Ruby on Rails
Для фреймворка Ruby on Rails существует гем, позволяющий выполнять Ruby-код прямо в браузере.
Давайте попробуем разобраться, что нам для этого понадобится?
Для начала нам нужно обратиться на несуществующую страницу:
Далее мы делаем попытку обращения к консоли через браузер:
Ну и, наконец, формируем запрос за запуск приложения калькулятор (в данном примере вектор для MAC OS X):
Blizzard Desktop application
Не только разработчики и обычные пользователи подвержены атаке типа DNS rebinding, но и геймеры тоже. Здесь мы опять же встречаемся с проблемой JSON-RPC сервиса, торчащим в данном случае на localhost на 1120 порту. Сервис дает возможность производить апдейты, изменять настройки и другие различные обслуживающие опции.
В данном случае поддерживается аутентификация, но пройти её, делая запросы от localhost, не составляет труда:
Как результат, можно добиться чего-то подобного:
Более подробно можно ознакомиться тут.
Итог по Desktop Application:
- злоумышленник может получить RCE на основной системе (также не забываем про VM Escape)
- злоумышленник может получить доступ к конфиденциальным данным и т.д.
Clouds
Ну, и напоследок, осталось самое интересное – облака. Суть в том, что облачные сервисы часто используются для размещения ПО, которое проводит аналитику приходящих на сайт пользователей. Например, переходя headless браузером по ссылке из заголовка Referer, чтобы скраулить ресурс, с которого клиент перешел на сайт. Этот вектор атаки так же можно использовать, ведь по сути headless браузер — это полноценный веб-браузер без графического интерфейса, но с поддержкой DOM, JS и всего остального.
Возвращаясь к нашим баранам, что мы можем сделать в данном случае? Ведь для атаки нам необходимо задержать пользователя (в данном случае бота) на странице. Что ж, для этого мы можем использовать на странице изображение, имеющее Content-Length на единицу больше, чем оно есть на самом деле. Как результат, бот будет думать, что картинка ещё не прогрузилась и задержится на нашей странице, а далее, мы применяем нашу стандартную технику DNS rebinding.
В итоге, так как запросы мы будем слать от доверенного лица, мы можем творить множество веселых вещей. Например:
- сканировать внутреннюю сеть
- авторизовываться во внутренних сервисах (теоретически)
- красть данные авторизации других сервисов и т.д.
Вернемся непосредственно к Amazon. AWS EC2 имеет такой функционал, как Instance Metadata Service. Она позволяет любой EC2 сущности использовать REST API, находящийся по адресу 169.254.169.254, раскрывающий информацию об инстансе.
Например, вот небольшой список подобных сервисов у различных облаков:
- AWS http://169.254.169.254/latest/user-data
- Google Cloud http://169.254.169.254/computeMetadata/v1/
- Digital Ocean http://169.254.169.254/metadata/v1.json
- OpenStack/RackSpace http://169.254.169.254/openstack
- Azure http://169.254.169.254/metadata/instance
- Oracle Cloud http://169.254.169.254/opc/v1/instance/
Теперь давайте рассмотрим кейс, в котором мы побалуемся с AWS.
Для начала пусть бот сделает запрос к API:
В ответе мы можем получить конфиденциальную информацию, например, креды в скрипте, который запускается при старте машины:
Далее мы можем вытащить имя ноды, с которой будем дальше работать:
Далее мы сделаем следующее обращение по уже известному имени и – бинго!
Мы получили различную информацию о пользователе, такую как AccessKeyId, SecretAccessKey, Token и т.д.
Получив эти данные, мы можем использовать их для авторизации через консольный клиент:
Общий итог:
Давайте выделим общие слабые точки, которые мы заметили при эксплуатации атаки типа DNS rebinding:
- API без аутентификации
- Локальные сервисы без аутентификации
- Игнорирование Host параметра к запросе
- Использование http вместо https
Таким образом, несмотря на различные доводы со стороны экспертов в области практической информационной безопасности, атака данного типа рождается заново в эпоху IoT, облачных сервисов, криптовалют и так далее, даже несмотря на необходимость задержки клиента на стороне злоумышленника, ведь в мире онлайн-кинотеатров, видеохостингов и прочих сервисов, предоставляющих контент пользователю, сделать это не составляет особого труда. Поэтому будьте бдительны при путешествии в онлайн-мире, при покупке очередного умного помощника, ну и при разработке, естественно.
