DNS cache poisoning

Материал из Википедии — свободной энциклопедии
Перейти к: навигация, поиск

DNS cache poisoning (отравление кэша DNS) — повреждение целостности данных в системе DNS путем заполнения кэша DNS-сервера данными, не исходящими от авторитетного DNS-источника. Подобная компрометация данных может быть результатом хакерской атаки на сервер имён или неожиданным результатом ошибки в конфигурировании DNS-кэша. Данный тип атаки был впервые изучен и описан в 2008 году экспертом по информационной безопасности Дэном Камински. Первая известная крупная атака такого типа была совершена Евгением Кашпуревым в 1997 году.[источник не указан 105 дней]

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

DNS-сервер призван транслировать доменное имя (например, example.com) в IP-адрес, используемый хостами для соединения с ресурсами Интернета. Если DNS-сервер отравлен, он может возвращать некорректный IP-адрес, направляя таким образом трафик на другой компьютер.

Атаки на кэш[править | править вики-текст]

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

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

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

Примеры атаки[править | править вики-текст]

В показанных ниже примерах A-запись для сервера ns.target.example будет заменена (кэш будет отравлен) и станет указывать на DNS-сервер атакующего с IP-адресом w.x.y.z. В примере подразумевается, что DNS-сервером target.example является ns.target.example.

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

Подмена IP-адреса DNS-сервера домена жертвы[править | править вики-текст]

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

Запрос от DNS-сервера жертвы: какова A-запись для subdomain.attacker.example?

subdomain.attacker.example. IN A

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

Answer:
(no response)

Authority section:
attacker.example. 3600 IN NS ns.target.example.

Additional section:
ns.target.example. IN A w.x.y.z

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

Подмена NS-записи для другого домена жертвы[править | править вики-текст]

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

Запрос DNS-сервера: какова A-запись для subdomain.attacker.example?

subdomain.attacker.example. IN A

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

Answer:
(no response)

Authority section:
target.example. 3600 IN NS ns.attacker.example.

Additional section:
ns.attacker.example. IN A w.x.y.z

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

Предотвращение атак и противодействие[править | править вики-текст]

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

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

Протокол DNSSEC использует электронную цифровую подпись с построением цепочки доверия для определения целостности данных. Применение DNSSEC может свести результативность атак на кэш к нулю. В 2011 году внедрение DNSSEC идет уже быстрыми темпами (большинство доменных зон gTLD: .com, .net, .org — уже подписаны DNSSEC). Начиная с июля 2010 года корневые серверы DNS содержат корневую зону DNS, подписанную при помощи стандартов DNSSEC.

Атакам на кэш также можно противопоставить транспортный уровень либо уровень приложений модели OSI, так как и на этих уровнях могут быть использованы цифровые подписи. К примеру, в безопасной версии HTTP — HTTPS пользователь может проверить, имеет ли сервер, с которым он соединился, сертификат ЭЦП и кому этот сертификат принадлежит. Похожий уровень безопасности имеет SSH, когда программа-клиент проверяет ЭЦП удаленного сервера при установке соединения. Соединение с помощью IPSEC не установится, если клиентом и сервером не будут предъявлены заранее известные ключи ЭЦП. Приложения, которые загружают свои обновления автоматически, могут иметь встроенную копию сертификата ЭЦП и проверять подлинность обновлений с помощью сравнения ЭЦП сервера обновлений со встроенным сертификатом.

Примечания[править | править вики-текст]

Ссылки[править | править вики-текст]