Network Performance Monitoring (NPM) and Diagnostics | Application Performance Monitoring (APM) | Application-Aware Network Performance Monitoring (AA NPM) | Network Fault Management | Information Security | Network Security

Краткое объяснение сути атаки DNS Rebinding и перечисление методов защиты от нее

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

Киберпреступники, проводя атаки перепривязывания DNS, получают возможность отправлять команды в различные системы, в том числе и потенциально уязвимым устройствам из локальных сетей, которые расположены за брандмауэром жертвы. Это происходит тогда, когда условная жертва, привлеченная любым известным способом (социальная инженерия, фишинг, межсайтовый скриптинг и т.д.), попадает на контролируемый злоумышленниками домен, через который эти киберпреступники могут отправлять запросы на привлечение различных ресурсов. Так, например, жертвы могут быть направлены на веб-сайт, содержащий вредоносный код JavaScript, который затем будет запущен в их браузерах на их компьютерах, то есть уже за брандмауэром, со всеми вытекающими последствиями.

Схема атаки DNS Rebinding

Схема атаки DNS Rebinding

Вот как это работает:

  1. Вы регистрируете домен и устанавливаете контроль над DNS-сервером, обслуживающим этот домен.
  2. Если вам удалось заманить кого-то перейти на ваш вредоносный домен, то сразу ваш DNS-сервер вернет IP-адрес веб-сервера для host.domain (допустим, 1.3.4), передающий вредоносный код вашей жертве. Это, к примеру, может быть достигнуто благодаря перенаправлению жертвы на сайт, содержащий код JavaScript.
  3. Если вы настроите ваш DNS-сервер таким образом, чтобы его ответы содержали очень короткий TTL (Time to live, время жизни — параметр, определяющий актуальность данных при кешировании DNS-запросов) — например, 10 секунд, — то вы вынудите систему жертвы постоянно обращаться к вашему домену для проверки актуальности IP-адреса для host.domain, избежав таким образом кеширование ответа.
  4. Если вы знаете (или предполагаете), что ваша жертва имеет определенный тип оборудования в своей внутренней сети — например, конкретный маршрутизатор или IoT-устройство, — которое вы бы смогли контролировать, если бы находились в одной с ним сети, вы можете использовать часть своего вредоносного кода JavaScript, которое уже запущен в браузере жертв (так как они посетили ваш сайт), чтобы отправлять запросы к этой уязвимой системе, например, «https: //host.domain/set-dns-server? Server = 6.7.8.9».
  5. Когда этот запрос будет отправлен в первый раз, он будет адресован на IP-адрес 1.2.3.4, так как именно он был изначальным IP-адресом, который вы отправили жертве для host.domain.
  6. Но когда браузер жертвы обратится к вашему домену с новым DNS-запросом (через 10 секунд, так как именно такое значение параметра TTL вы установили), вашим ответом будет якобы новый актуальный IP-адрес для вашего домена — например, «192.168.1.1», — что заставит браузер жертвы отправлять запросы «https://host.domain/set-dns-server?server=7.8.9» уже на IP-адрес 192.168.1.1!
  7. Если гипотетический маршрутизатор, на который вы нацелились, реально существует и уязвим к запросу, который вы заставили отправить систему вашей жертвы (к примеру, на данном маршрутизаторе используются учетные данные по умолчанию либо вообще отсутствуют), это заставит обновить значение DNS-сервера, к которому подключается этот маршрутизатор, на те, которые контролирует злоумышленник, коим, вероятнее всего, вы же и будете.
  8. Повторяйте по мере необходимости эти запросы, чтобы определить правильный IP-адрес и / или отправляйте разные команды разным устройствам внутри сети жертвы.

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

Что делает атаку DNS Rebinding настолько эффективной и опасной, так это то, что она использует две основные функции в фундаментальной структуре Интернета, которые точно не будут изменены в обозримом будущем:

  1. Тот факт, что пользовательские браузеры запускают код JavaScript по умолчанию (включая такие потенциально опасные активности, как, скажем, запуск скрипта hook.js фреймворка BeEF) и…
  2. Возможность устанавливать низкие значения параметра TTL для ответов на DNS-запросы, что позволяет постоянно изменять привязку доменного имени к конкретному IP-адресу.

Защита от атаки DNS Rebinding: основные принципы

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

Обычно, защита от атак DNS Rebinding опирается на следующие основные принципы:

  1. Ограничение для запуска кода JavaScript (чтобы атакующий не имел возможность заставить браузер жертвы отправлять запросы).
  2. Привязка IP-адресов к доменным именам (чтобы злоумышленника лишить возможности их менять).
  3. Не принимать значение параметров TTL для ответов на DNS-запросы меньше определенного значения (что значительно ограничивает злоумышленника в возможности изменять значение IP-адреса для доменного имени).
  4. Не принимать ответы на DNS-запросы (для внешних доменов) с IP-адресами, указывающими на внутреннюю сеть (чтобы ограничить возможности киберпреступников отправлять команды во внутреннюю сеть).

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

Оставайтесь защищенными!

 

Подписывайтесь на рассылку, делитесь статьями в соцсетях и задавайте вопросы в комментариях!

Вечный параноик, Антон Кочуков.

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

См. также:

Рейтинг@Mail.ru © 2015 - 2024 NetworkGuru.ru Использование материалов сайта без согласования запрещено!
Заказать звонок