DNS cache poisoning (DNS cache poisoning)
Эту страницу предлагается объединить со страницей DNS spoofing. |
DNS cache poisoning (отравление кэша DNS) — повреждение целостности данных в системе DNS путём заполнения кэша DNS-сервера данными, не исходящими от авторитетного DNS-источника. Подобная компрометация данных может быть результатом хакерской атаки на сервер имён или неожиданным результатом ошибки в конфигурировании DNS-кэша. Данный тип атаки был впервые изучен и описан в 2008 году экспертом по информационной безопасности Дэном Камински. Первая известная крупная атака такого типа была совершена Евгением Кашпуревым в 1997 году[источник не указан 3815 дней].
Когда 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 не установится, если клиентом и сервером не будут предъявлены заранее известные ключи ЭЦП. Приложения, которые загружают свои обновления автоматически, могут иметь встроенную копию сертификата ЭЦП и проверять подлинность обновлений с помощью сравнения ЭЦП сервера обновлений со встроенным сертификатом.
Примечания
[править | править код]Ссылки
[править | править код]- 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-атак