Подмена DNS

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

Обзор системы доменных имен

Сервер системы доменных имен преобразует удобочитаемое доменное имя (например, example.com) в числовой IP-адрес , который используется для маршрутизации связи между узлами . ^[1] Обычно, если сервер не знает запрошенный перевод, он запрашивает другой сервер, и процесс продолжается рекурсивно . Чтобы повысить производительность, сервер обычно запоминает (кэширует) эти переводы в течение определенного периода времени. Это означает, что если он получит еще один запрос на тот же перевод, он сможет ответить, не запрашивая другие серверы, пока не истечет срок действия кэша.

Когда DNS-сервер получил ложный перевод и кэширует его для оптимизации производительности, он считается отравленным и передает ложные данные клиентам. Если DNS-сервер отравлен, он может возвращать неверный IP-адрес, перенаправляя трафик на другой компьютер (часто злоумышленник). ^[2]

Атаки отравления кэша

Обычно сетевой компьютер использует DNS-сервер, предоставляемый поставщиком услуг Интернета (ISP) или организацией пользователя компьютера. DNS-серверы используются в сети организации для повышения производительности ответа на разрешение путем кэширования ранее полученных результатов запроса. Отравляющие атаки на одиночный DNS-сервер могут повлиять на пользователей, обслуживаемых непосредственно скомпрометированным сервером или косвенно обслуживаемых его нижестоящими серверами, если это применимо. ^[3]

Для проведения атаки по отравлению кэша злоумышленник использует недостатки в программном обеспечении DNS. Сервер должен правильно проверять ответы DNS, чтобы гарантировать, что они получены из авторитетного источника (например, с помощью DNSSEC ); в противном случае сервер может в конечном итоге кэшировать неправильные записи локально и передавать их другим пользователям, которые делают тот же запрос.

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

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

Варианты

В следующих вариантах записи для сервера ns.target .пример будет отравлен и перенаправлен на сервер имен злоумышленника по IP-адресу wxyz . Эти атаки предполагают, что сервер имен для цель.пример является ns.target.example .

Для осуществления атаки злоумышленник должен заставить целевой DNS-сервер сделать запрос на домен, контролируемый одним из серверов имен злоумышленника. ^{[ нужна ссылка ]}

Перенаправить сервер имен целевого домена

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

Запрос DNS-сервера: для чего нужны записи адреса субдомен.атакер.пример ?

subdomain.attacker.example. IN A

Ответ злоумышленника:

Отвечать:

(no response)

Раздел полномочий:

attacker.example. 3600 IN NS ns.target.example.

Дополнительный раздел:

ns.target.example. IN A w.x.y.z

Уязвимый сервер будет кэшировать дополнительную A-запись (IP-адрес) для ns.target.example , что позволяет злоумышленнику разрешать запросы ко всему цель.пример домен.

Перенаправить запись NS в другой целевой домен

Второй вариант заражения DNS-кэша предполагает перенаправление сервера имен другого домена, не связанного с исходным запросом, на IP-адрес, указанный злоумышленником. ^{[ нужна ссылка ]}

Запрос DNS-сервера: для чего нужны записи адреса субдомен.атакер.пример ?

subdomain.attacker.example. IN A

Ответ злоумышленника:

Отвечать:

(no response)

Раздел полномочий:

target.example. 3600 IN NS ns.attacker.example.

Дополнительный раздел:

ns.attacker.example. IN A w.x.y.z

Уязвимый сервер будет кэшировать несвязанную информацию о полномочиях для цель.пример NS-запись (запись сервера имен), позволяющая злоумышленнику разрешать запросы ко всему цель.пример домен.

Предотвращение и смягчение последствий

Многие атаки по отравлению кэша на DNS-серверы можно предотвратить, если меньше доверять информации, передаваемой им от других DNS-серверов, и игнорировать любые переданные обратно DNS-записи, которые не имеют прямого отношения к запросу. Например, версии BIND 9.5.0-P1 ^[5] и выше выполните эти проверки. ^[6] Рандомизация исходного порта для DNS-запросов в сочетании с использованием криптографически безопасных случайных чисел для выбора как исходного порта, так и 16-битного криптографического nonce может значительно снизить вероятность успешных атак DNS-гонки. ^{[ нужна ссылка ]}

Однако когда маршрутизаторы, межсетевые экраны , прокси-серверы и другие шлюзовые устройства выполняют преобразование сетевых адресов (NAT) или, более конкретно, преобразование адресов портов (PAT), они могут перезаписывать исходные порты, чтобы отслеживать состояние соединения. При изменении исходных портов устройства PAT могут удалять случайность исходного порта, реализуемую серверами имен и заглушками. ^{[ нужна ссылка ]}^[7]

Secure DNS ( DNSSEC ) использует криптографические цифровые подписи, подписанные доверенным сертификатом открытого ключа, для определения подлинности данных. DNSSEC может противостоять атакам по отравлению кэша. В 2010 году DNSSEC был реализован на серверах корневой зоны Интернета. ^[8] необходимо развернуть на всех серверах домена верхнего уровня но его также . Их готовность к DNSSEC показана в списке доменов верхнего уровня Интернета . По состоянию на 2020 год все исходные ДВУ поддерживают DNSSEC, как и ДВУ с кодом страны большинства крупных стран, но многие ДВУ с кодом страны до сих пор этого не делают.

Этот вид атаки можно смягчить на транспортном уровне или уровне приложения , выполняя сквозную проверку после установления соединения. Типичным примером этого является использование Transport Layer Security и цифровых подписей . Например, используя HTTPS (безопасную версию HTTP ), пользователи могут проверить, действителен ли цифровой сертификат сервера и принадлежит ли предполагаемому владельцу веб-сайта. Аналогично, программа удаленного входа в безопасную оболочку проверяет цифровые сертификаты на конечных точках (если они известны) перед продолжением сеанса. Для приложений, которые загружают обновления автоматически, приложение может встроить копию сертификата подписи локально и проверить подпись, хранящуюся в обновлении программного обеспечения, по встроенному сертификату. ^[9]

См. также

Ссылки

^ Ву, Хао; Данг, Сянлэй; Ван, Лидун; Он, Лунтао (2016). «Метод на основе объединения информации для обнаружения и идентификации атак отравления кэша распределенной системы доменных имен» . Информационная безопасность ИЭПП . 10 (1): 37–44. doi : 10.1049/iet-ifs.2014.0386 . ISSN 1751-8717 . S2CID 45091791 .
^ Сын, Суэл; Шматиков, Виталий. «Руководство для автостопщика по отравлению кэша DNS» (PDF) . Корнеллский университет . Архивировано (PDF) из оригинала 14 августа 2017 года . Проверено 3 апреля 2017 г.
^ Штормы, Эндрю (2006). «Не доверяйте методологии распространения программного обеспечения вашего поставщика». Безопасность информационных систем . 14 (6): 38–43. дои : 10.1201/1086.1065898X/45782.14.6.20060101/91858.8 . S2CID 15167573 – через ProQuest Central.
^ м. Диссанаяке, IM (2018). «Отравление DNS-кэша: обзор метода и мер противодействия» . Национальная конференция по информационным технологиям (NITC) 2018 года . стр. 1–6. дои : 10.1109/NITC.2018.8550085 . ISBN 978-1-5386-9136-6 . Проверено 31 января 2024 г.
^ «Матрица безопасности BIND» . ISC-привязка . Архивировано из оригинала 11 ноября 2011 года . Проверено 11 мая 2011 г.
^ «ISC Bind Security» . ISC-привязка . Архивировано из оригинала 11 ноября 2011 года . Проверено 11 мая 2011 г.
^ Диринг, Кристофер (2019). «Личная информация как вектор атаки: почему конфиденциальность должна быть оперативным аспектом национальной безопасности США †» . Журнал закона и политики национальной безопасности . 10 : 351–403. ProQuest 2395864954 – через ProQuest.
^ «Корневой DNSSEC» . ICANN/Verisign. п. 1. Архивировано из оригинала 10 сентября 2017 года . Проверено 5 января 2012 г.
^ «Правильная конфигурация для защиты вашего сервера» . Цифровой гид IONOS . Проверено 29 апреля 2022 г.

[1] Ву, Хао; Данг, Сянлэй; Ван, Лидун; Он, Лунтао (2016). «Метод на основе объединения информации для обнаружения и идентификации атак отравления кэша распределенной системы доменных имен» . Информационная безопасность ИЭПП . 10 (1): 37–44. doi : 10.1049/iet-ifs.2014.0386 . ISSN 1751-8717 . S2CID 45091791 .

[2] Сын, Суэл; Шматиков, Виталий. «Руководство для автостопщика по отравлению кэша DNS» (PDF) . Корнеллский университет . Архивировано (PDF) из оригинала 14 августа 2017 года . Проверено 3 апреля 2017 г.

[3] Штормы, Эндрю (2006). «Не доверяйте методологии распространения программного обеспечения вашего поставщика». Безопасность информационных систем . 14 (6): 38–43. дои : 10.1201/1086.1065898X/45782.14.6.20060101/91858.8 . S2CID 15167573 – через ProQuest Central.

[4] м. Диссанаяке, IM (2018). «Отравление DNS-кэша: обзор метода и мер противодействия» . Национальная конференция по информационным технологиям (NITC) 2018 года . стр. 1–6. дои : 10.1109/NITC.2018.8550085 . ISBN 978-1-5386-9136-6 . Проверено 31 января 2024 г.

[5] «Матрица безопасности BIND» . ISC-привязка . Архивировано из оригинала 11 ноября 2011 года . Проверено 11 мая 2011 г.

[6] «ISC Bind Security» . ISC-привязка . Архивировано из оригинала 11 ноября 2011 года . Проверено 11 мая 2011 г.

[7] Диринг, Кристофер (2019). «Личная информация как вектор атаки: почему конфиденциальность должна быть оперативным аспектом национальной безопасности США †» . Журнал закона и политики национальной безопасности . 10 : 351–403. ProQuest 2395864954 – через ProQuest.

[rootdnssec-8] «Корневой DNSSEC» . ICANN/Verisign. п. 1. Архивировано из оригинала 10 сентября 2017 года . Проверено 5 января 2012 г.

[9] «Правильная конфигурация для защиты вашего сервера» . Цифровой гид IONOS . Проверено 29 апреля 2022 г.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]