Автор: Christopher Makarem
Во время DNS-спуфинга происходит изменение записей на DNS сервере с целью перенаправления трафика. DNS-спуфинг может выполняться через прямую атаку на сервер (о чем мы и поговорим в этой статье) или посредством атаки типа «человек посередине», специально заточенной под DNS-трафик.
Подмена DNS кэша основана на эксплуатации схемы DNS коммуникации. Когда DNS сервер пытается выполнить поиск в домене, то перенаправляет запрос в корневой уполномоченный сервер и итеративно продвигается по цепочке DNS-серверов пока не достигнет уполномоченного сервера в домене. Поскольку локальный DNS-сервер не знает, какой сервер принадлежит какому домену, и не знает полный путь до каждого уполномоченного сервера, то принимает ответы на свои запросы откуда угодно, пока ответ соответствует запросу и нужному формату.
Злоумышленник может эксплуатировать эту схему и подменить ответ актуального уполномоченного DNS-сервера на запрос локального сервера. Таким образом, локальный DNS-сервер будет использовать DNS-записи злоумышленника вместо ответа уполномоченного сервера. Из-за архитектуры DNS локальный сервер не может отличить поддельный ответ от настоящего.
Ситуация усугубляется еще больше, поскольку DNS-сервера кэшируют запросы, отсылаемые между собой, в целях экономии времени на запросы к уполномоченным серверам каждый раз при запросе домена. Здесь возникаете еще одна проблема. Если злоумышленник сможет подменить ответ уполномоченного DNS-сервера, тогда записи, используемые злоумышленником, закэшируются локальным DNS-сервером, и остальным пользователям этого локального сервера будут отдаваться поддельные записи. В итоге все пользователи данного локального сервера будут перенаправляться на сайт злоумышленника.
Рисунок 1: Схема отравления DNS-кэша
Примеры отравления DNS-кэша
Подделка слепого ответа через атаку «дней рождения»
В протоколе DNS не предусмотрено подтверждение подлинности ответа на рекурсивные итеративные запросы. Проверяется только 16-битный идентификатор транзакции, IP-адрес источника и целевой порт, присутствующие в ответе. До 2008 года все DNS-резольверы использовали фиксированный порт 53. Таким образом, кроме идентификатора транзакции, вся информация, нуждающаяся в подделке во время ответа, была предсказуема. Атаки на DNS, эксплуатирующие эту слабость, были основаны на «парадоксе дней рождения». В среднем требовалось 256 попыток (два в восьмой степени) на угадывания идентификатора транзакции. Для успешной реализации атаки поддельный DNS-ответ должен поступить на целевой резольвер перед легитимным ответом. Если легитимный ответ поступит первым, то будет закэширован и до истечения времени TTL резольвер не будет отправлять запрос с тем же самым именем домена. Таким образом, злоумышленник не сможет отравить кэш для этого домена в течение времени TTL.
Эксплоит Каминского
В 2008 году на конференции Black Hat было предложено нововведение для атаки «дней рождения». Базовый метод слепого угадывания остается тем же. DNS-ответы могут быть двух типов: первый тип — с IP-адресом запроса, второй (реферальный) — с сервером, уполномоченным для определенной зоны. При атаке «дней рождения» происходит подделка ответа и инъекция содержимого для указанной записи домена. Эксплоит Каминсого использует реферал для создания поддельной записи для целого домена и обхода ограничения, связанного с TTL, у предыдущих записей. Вначале злоумышленник выбирает домен для компрометирования, а затем отправляет запрос целевому резольверу для незакэшированного поддомена (целевой несуществующий поддомен вполне подойдет). Поскольку поддомен не находится в кэше, целевой резольвер отсылает запрос уполномоченному серверу этого домена. В этот момент злоумышленник спамит резольвер большим количеством поддельных ответов с разными идентификаторами транзакций. Если злоумышленнику удается инъекция поддельного ответа, резольвер закэширует поддельную информацию от имени уполномоченного сервера. Последующие DNS-запросы к целевому резольверу скомпрометированного домена будут перенаправляться на уполномоченный резольвер контроллера злоумышленника. В итоге злоумышленник сможет формировать вредоносные ответы без необходимости внедрения поддельного содержимого для каждой новой DNS-записи.
Перехват трафика
Многие идеи по повышению безопасности DNS связаны с рандомизацией исходного порта, например, кодирование по алгоритму 0x20 XOR или WSEC-DNS в зависимости от ассиметричной доступности компонентов, используемых для аутентификации. Другими словами, эти меры безопасности основываются на неопределенности, а не конфиденциальности при помощи аутентификации или криптографии. Эти техники направлены на защиту от слепых атак, описанных выше. Однако при использовании данных методов DNS остается уязвимым к тривиальным атакам, связанным с компрометированием серверов и сетевыми перехватчиками, для выяснения нужной информации и последующей реализации атак, описанных выше. В этом случае слепое угадывание уже не требуется. Даже в средах, где используются коммутаторы, техники типа ARP poisoning и другие схожие методы могут использоваться для перенаправление всех пакетов в нужное место для выяснения необходимой информации и обхода методов, связанных с рандомизацией и неопределенностью.
Защита от отправления DNS-кэша
DNSSEC
Лучший способ предотвратить отравление кэша DNS-резольвера – внедрить безопасный метод криптографии и аутентификации. Несмотря на то, что DNS – один из самых старых протоколов, являющийся основной всего интернета, но до сих пор не использует шифрование и валидацию записей и ответов.
Решение – внедрить верификацию и аутентификацию под названием DNS Secure или DNSSEC. В этом протоколе создается уникальная криптографическая сигнатура, хранимая вместе с DNS-записями. Впоследствии эта сигнатура используется DNS-резольвером для проверки подлинности ответа и записи. Кроме того, эта схема используется для создания достоверной цепочки от TLD до зоны уполномоченного домена и безопасности преобразования DNS имен.
Несмотря на очевидные преимущества DNSSEC внедряется довольно медленно, и многие не очень популярные TLD до сих пор не внедрили меры безопасности на базе DNSSEC. Главная проблема – сложность установки DNSSEC и необходимость в модернизации оборудования для работы с новым протоколом. Кроме того, вследствие устаревания и утраты актуальности большинства атак, связанных со спуфингом DNS, задача по внедрению DNSSEC не является приоритетной и обычно происходит в тот момент, когда приходит время менять оборудование.
Источник: