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

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

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

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

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

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

Однако при помощи 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, значит, более мелких производителей эта проблема тоже касается, и можно сказать, что уязвимых устройств бесчисленное множество.

Подробнее: https://www.securitylab.ru/analytics/499265.php