DNS cache poisoning

Обычно компьютер в сети использует 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-сервер атакующего является авторитетным.

Первый вариант отравления 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.

Второй вариант атаки заключается в перенаправлении 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 не установится, если клиентом и сервером не будут предъявлены заранее известные ключи ЭЦП. Приложения, которые загружают свои обновления автоматически, могут иметь встроенную копию сертификата ЭЦП и проверять подлинность обновлений с помощью сравнения ЭЦП сервера обновлений со встроенным сертификатом.

• Корневые серверы DNS
• Фарминг

• SANS DNS cache poisoning update
• DNS Threats & Weaknesses: research and presentations
• Movie explaining DNS Cache Poisioning
• An Illustrated Guide to the Kaminsky DNS Vulnerability
• US CERT advisory : Multiple DNS implementations vulnerable to cache poisoning
• Secret Geek A-Team Hacks Back, Defends Worldwide Web An article about defending against DNS poisoning
• Обзор схем DNS-атак