Заражение кэша DNS-серверов провайдеров за счет манипуляции DNS-ответами от легитимных авторитетных DNS-серверов

    Серьезной проблемой современности являются сетевые угрозы ИБ, то есть классы угроз, реализуемых с использованием протоколов межсетевого взаимодействия. Одним из таких протоколов является протокол системы доменных имен — DNS.

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

    Отследить модификацию пакетов DNS-транзакций, при потенциально высокой опасности реализации в информационных системах атак довольно непросто, поэтому становятся возможными такие атаки как:

    • анализ сетевого трафика;
    • подмена доверенного объекта сети;
    • навязывание ложного маршрута;
    • внедрение ложного объекта сети.

    Тема заражения кэша DNS-серверов провайдеров уже давно изъезжена, однако на практическом примере покажем, как довольно просто заставить «ходить» клиентов конкретного интернет-провайдера по нужному нам IP-адресу, вместо правильного, для заданного домена, ничего при этом не взламывая и не заражая троянами, тем самым давая нам полный контроль над трафиком, связанным с конкретной DNS-зоной.

    Представим фрагмент глобальной сети Интернет от клиентского ПЭВМ до некоего удаленного веб-сервиса, а также другие элементы сети, имеющие отношение к системе доменных имен


    В состав типовой компьютерной сети, реализующей подмену IP-адреса для целевого домена, входят следующие элементы:

    1. Клиентская ПЭВМ (Клиент).
    2. Интернет-провайдер (в составе: кэширующий DNS-сервер, шлюз).
    3. Вспомогательный клиент.
    4. Система доменных имен.
    5. Точка мониторинга (межсетевой экран, фильтр, прокси-сервер).
    6. Сервер информационной службы.

    Для успешной реализации нашего замысла необходимо выполнение ряда условий:

    1. Существует контролируемый DNS-сервер, отвечающий за какую-либо (любую) зону системы доменных имен.
    2. Клиент обслуживается интернет-провайдером с кэширующим DNS-сервером либо известен иной DNS-сервер, услугами которого пользуется клиент, и данный сервер является кэширующим.
    3. В момент получения DNS-ответа от контролируемого DNS-сервера в кэше DNS-сервера интернет-провайдера отсутствует запись с целевым DNS-именем узла информационной службы.
    4. В точке мониторинга существует база IP адресов и доменных имен целевых информационных службы, в отношении которых ведется мониторинг и управление сетевым взаимодействием с клиентом.

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

    Согласно рекомендациям RFC 1034, RFC 1035, устанавливающих порядок функционирования, спецификацию и применение системы доменных имен, при формировании DNS-ответа допускается добавление, так называемых полей «Additional». Данные поля необходимы для записи IP-адресов вспомогательных узлов различных типов, в том числе, для предотвращения повторного обращения к DNS-серверу, в случаях, когда по определенным причинам, основной узел, запись которого передается в поле «Answer», оказывается недоступным. В случае применения предлагаемого подхода, в поле «Additional» записывается IP-адрес, ставящийся в соответствие доменному имени целевой информационной службе, но реально принадлежащий точке мониторинга – межсетевому экрану.

    Такую задачу (добавление нужного нам поля) можно возложить на скрипт, имитирующий работу легитимного DNS-сервера, отвечающего за какую-либо DNS-зону, причем не важно какого уровня…

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

    Таким образом, клиент получает разрешение доменного имени запрошенной информационной службы с IP адресом, полученным от контролируемого DNS сервера и хранящемся в момент обработки запроса клиента интернет-провайдером в кэш-памяти провайдера. При этом IP адрес принадлежит не целевой информационной службе, запрашиваемой клиентом, а точке мониторинга. Соответственно, далее, обращение клиента к целевой информационной службе происходит по IP адресу, принадлежащему точке мониторинга.

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

    1. Разбор полученной от клиента транзакции.
    2. Выработка и применение управляющих воздействий.
    3. Аудит полученных транзакций и произведенных действий.
    4. Формирование на основе данных полученной клиентской транзакции запроса к информационной службе.

    В точке мониторинга – МСЭ осуществляется преобразование сетевых адресов (Network Address Translation – NAT), что позволяет обеспечить его «прозрачную» работу с точки зрения клиента и целевой информационной службой.

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

    1. DNS-сервер на базе программного обеспечения BIND 9.4, отве-чающий за зону ".a", с доменным именем «ns.a».
    2. DNS-сервер на базе программного обеспечения BIND 9.4, отве-чающий за зону ".b", с доменным именем «ns.b».
    3. Клиентская ПЭВМ с IP адресом 10.0.33.13.
    4. Точка мониторинга – межсетевой экран с IP адресом 10.0.33.13.

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

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

    На 1-м этапе на DNS сервере, отвечающем за зону ".b" запускается, скрипт «fakedns», реализующий работу DNS-коммутатора. В задачу скрипта входит обработка полученного DNS запроса на разрешение доменного имени из зоны ".b" и добавление в DNS ответ дополнительного поля «Additional» для заданного доменного имени (в примере – «victim.com»), соответствующим целевой информационной службе, для которой будет осуществляться мониторинг и управление безопасностью сетевого взаимодействия с клиентом, и с заданным IP адресом (в примере – «10.0.33.13»), соответствующим точке мониторинга – межсетевому экрану. Запуск скрипта «fakedns» с заданными параметрами, моделирующий работу DNS-коммутатора осуществляется **командой**


    На 2-м этапе происходит формирование и передача DNS-запроса для доменного имени «test.b» от клиента в систему доменных имен, состоящему из DNS сервера «ns.a» и DNS сервера «ns.b». При этом первичным DNS сервером (DNS сервером интернет-провайдера) для клиента является DNS сервер «ns.a».

    Структура запроса




    На 3-м этапе формируется и передается DNS-ответ для доменного имени «test.b» с дополнительным полем «Additional» и заданным доменным именем «victim.com», соответствующий информационного службе, которому поставлен в соответствие заданный IP адрес «10.0.33.13», соответствующий точке мониторинга.

    Структура пакета DNS ответа




    На 4-м этапе осуществляется проверка наличия в кэш-памяти DNS сервера «ns.a» доменного имени «victim.com», соответствующего информационной службе, но с IP адресом, соответствующем точке мониторинга – «10.0.33.13».

    Проверка осуществляется командой


    На 5-м этапе принимается ответ о наличии в кэш-памяти DNS сервера «ns.a» доменного имени «victim.com».

    Структура DNS-ответа




    Очевидно, что при дальнейшем обращении клиента к узлу «victim.com» по IP адресу из полученного DNS ответа, обращение будет происходить по IP адресу, заданному в параметрах к скрипту «fakedns» и соответствующему точке мониторинга – межсетевому экрану.

    Проверка данного факта осуществляется командой


    На основе представленных материалов проведенного эксперимента можно сделать вывод, что, при выполнении перечисленных условий и добавлению дополнительного поля «Additional» в DNS-коммутаторе при обработке запроса на разрешение доменного имени целевой информационной службы, возникает возможность осуществления контроля сетевого взаимодействия клиента и заданных информационных служб вне зависимости от их расположения и топологии компьютерной сети. Кроме этого появляется возможность мониторинга и контроля сетевого взаимодействия клиента и заданных информационных служб как на этапе установления сеанса соединения, так и на этапе информационного обмена, что не есть хорошо…

    Комментарии 22

      0
      DNSSEC?
        0

        Ну видимо да. На https же ушло в итоге больше половины интернета, и сюда уйдут. Главное опасность раздуть посильнее, и сами все побегут.

          0
          Да-да!
          Недавно столкнулся с интересным поведением домена (у клиента).
          На него невозможно было навесить сертификат letsencrypt
          Скрипт упорно возвращал ошибку «сервер не найден». Ошибка приходила от сервиса letsencrypt.
          Но хост у меня нормально грузился и ресолвился. И в ступор меня ставило то что nslookup на мой DNS работал, на яндекса работал, а на гугл 8.8.8.8 возвращал ошибку: «хост не найден». dig-ом раскопал что в домене кто-то начал настраивать DNSSEC но не закончил. Была прописана только запись DS. Запись удалили — и гугл вернул адрес!
          Вывод — гугл и letsencrypt поступают значительно логичнее чем все остальные: Если в домене есть какие-то упоминания о DNSSEC но полная верификация невозможна то нужно вернуть ошибку, а не пытаться ресолвнуть без DNSSEC!
            0
            Можно и без DNSSEC. Достаточно проверять, что данные, возвращаемые в поле Additional, имеют отношение к запрошенному имени. То есть, ответу на запрос для имени test.b позволяется вернуть записи для, максимум, домена b — но никак, не записи для домена victim.com или, тем более, com.
            Мезанизм атаки, описанный в статье, известен уже давно. И, к примеру, в DNS сервере из состава MS Windows такие левые ответы блокируются включеной по умолчанию настройкой «Secure cache against pollution». В bind аналогичная опция тоже должна быть.
            0
            Понятно, что 100% внедрение dnssec в каком-то очень далеком будущем может спасти. Но в текущей реальности — можно ли научить того же bind, как самый распространенный кэширующий сервер, не принимать то, что приходит в additional options? Если да — то как?
              +1

              Кто-нибудь может перевести это все на русский? Я уже во второй главе запутался кто тут злодей, а кто — жертва...

                0
                Все просто — какой-нибудь совершенно честный сервер, поддерживающий, например, habrahabr.ru, может прислать вместе с ответом на валидный запрос IP-адреса для www.habrahabr.ru дополнительную опцию, в которой укажет, что www.microsoft.com на самом деле доступен на совершенно левом IP. И ваш неймсервер запомнит этот резолв и будет отдавать его клиентам.
                  0

                  Эту часть я понял. Но какой смысл в качестве этого самого левого IP указывать адрес межсетевого экрана, который и без того слушает весь трафик до www.microsoft.com, потому что находится между сервером и его провайдером?

                    0
                    С точки зрения защиты, МСЭ может выполнять функции защиты от утечки информации, а с точки зрения нарушителя, это не МСЭ, а типичный MitM, позволяющий «случать», «подменять» и так далее. Обозначение «МСЭ» — чисто условное.
                      0

                      Тем не менее, по схеме — он уже между сервером и клиентом. Зачем в этой ситуации сложности с DNS?

                      0
                      Это был простой эксперимент. Подразумевалось (как я предполагаю), что указывается адрес сервера, реализующего MitM-атаку и в общем случае не находящегося между клиентом и сервером.
                  0
                  Кстати сейчас от такого mitm и https не спасёт, без дополнительных средств вроде привязки к сертификату в заголовке и/или мониторинга в реальном времени выпущенных сертификатов.

                  точно так же можно подменить DNS-ответы для сервера lets encrypt, получить их сертификат.

                  Потом уже атаковать DNS-сервер провайдера/клиента чтобы встроится посередине с сертификатом Let's encrypt. Тогда и клиент увидит валидный сертификат и браузер паниковать не будет и трафик будет прослушан.
                    +3
                    Заражение кеша через Additional Section исправили во всех популярных DNS-серверах и резолверах году так в 1997.
                      0

                      А BIND 9.4 вышел в 2007-м. Выходит, автор что-то недоговаривает?

                        0
                        Тестили на BIND 9.4. Только и всего… По части комментария ValdikSS ничего не могу сказать. Дополнительные секции предназначены ведь для передаче в ответе «запасных» IP для «заказанных» в запросе доменов. Насколько это можно исправить, если у них назначение — добавлять записи как запасные, в том числе в кэш… Спорить не буду, просто не в курсе.
                          0
                          Сделал тестовый DNS-сервер, который отвечает следующим образом:

                          ;; QUESTION SECTION:
                          ;testcache.domain.ru.           IN      A
                          
                          ;; ANSWER SECTION:
                          testcache.domain.ru.    60      IN      A       1.2.3.4
                          
                          ;; AUTHORITY SECTION:
                          ru.                     3600    IN      NS      ns1.yandex.ru.
                          
                          ;; ADDITIONAL SECTION:
                          ns1.yandex.ru.          3600    IN      A       1.2.3.4


                          При резолве через BIND 9.10.4 возвращаются следующие данные:

                          ;; QUESTION SECTION:
                          ;testcache.domain.ru.           IN      A
                          
                          ;; ANSWER SECTION:
                          testcache.domain.ru.    60      IN      A       1.2.3.4
                          
                          ;; AUTHORITY SECTION:
                          testcache.DOMAIN.ru.    36      IN      NS      ns.testcache.domain.ru.
                          
                          ;; ADDITIONAL SECTION:
                          ns.testcache.DOMAIN.ru. 36      IN      A       1.2.3.4
                          Как можно видеть, bind перезаписал значения authority section и additional section значением домена.
                            0
                            Так вы не то «резолвили». Попробуйте у вашего кеширующего bind'a запросить ns1.yandex.ru
                              0
                              Пробовал, естественно — вернулся настоящий IP-адрес ns1.yandex.ru.
                                0
                                Ммм, вы знаете, было бы правильней показать дамп сетевых пакетов DNS-запросов и DNS-ответов. Дело в том, что настройки BIND`а это одно, а то, как он формирует пакеты — несколько иное. Подобные настройки, указанные вами в рамках эксперимента тестировались, однако, как ни странно, BIND «отвечал» совсем не так, как указанно в настройках, добавляя справа к домену «дописки». Именно поэтому в эксперименте, описанном в данном материале, использовался для формирования DNS-ответов и полей Additional не BIND, а самописный скрипт.

                                Тем не менее, нисколько не умаляю довод, что данная особенность BIND`ов и их аналогов, связанная с обработкой полей Additional, могла быть исправлена.
                                  0
                                  О каких настройках вы говорите, о записях зоны? Я bind использовал только для резолва, ответ формировал DNS-сервером на основе dnslib (библиотека Python) вручную. У вас тоже нет никаких дампов пакетов в статье.

                                  Данная уязвимость была исправлена в 1997, если не раньше. Если бы она работала, ей бы пользовались все злоумышленники, чего не происходит. Пожалуйста, выложите все необходимые действия и настройки для осуществления атаки и получения такого результата, какой описан в статье. На данный момент статья не соответствует действительности.
                                    0
                                    Чем вас не устраивают дампы Wireshark`а?
                                      0
                                      Не вижу дампов, вы о визуальном представлении? Визуально мой пакет выглядит примерно так же. Только что максимально приблизил его к вашему — тот же результат, заражения кеша не происходит.

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

                      Самое читаемое