Отравление кеша DNS - следующее поколение

  1. Вступление Старая проблема отравления DNS-кешем вновь подняла свою уродливую голову. Хотя некоторые...
  2. Суб-атак
  3. Перенаправление веб-трафика
  4. Человек посередине
  5. Рекомендуемые средства защиты от отравления DNS-кешем
  6. Код подтверждения концепции: spooftest.pl
  7. Рекомендации

Вступление

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

Краткая история отравления кешем

В 1993 году Кристоф Шуба выпустил документ под названием «Устранение недостатков в протоколе системы доменных имен». В нем он выделил несколько уязвимостей, в том числе технику отравления DNS-кэша. В самом раннем воплощении было возможно предоставить дополнительную информацию в ответном пакете DNS, которая будет кэшироваться демоном. Это позволило злоумышленнику внедрить ложную информацию в кэш DNS для сети, что позволяет ему выполнять атаки «человек посередине» или другие неприятности.

В 1997 году CERT выпустил консультативный CA-1997-22 описание уязвимости в BIND, программном обеспечении Berkeley Internet Name Domain, которое используется почти всеми серверами имен в Интернете. На этот раз, наконец, был реализован очень простой принцип: BIND не рандомизировал свои идентификаторы транзакций - они были чисто последовательными. Помимо проверки протокола уровня 3 и 4 (IP-адреса и порты источника и назначения должны совпадать), идентификатор транзакции является единственной формой аутентификации для ответа DNS. Поскольку злоумышленник может легко предсказать идентификатор следующей транзакции после выполнения собственного запроса, атака с отравлением кэша может быть выполнена с использованием поддельного запроса, за которым следует поддельный ответ. Чтобы решить эту проблему, все новые версии BIND были обновлены для использования рандомизированных идентификаторов транзакций.

В 2002 году Вагнер Сакраменто выпустил рекомендацию, показывающую еще одну проблему с реализацией протокола DNS BIND. Он обнаружил, что BIND будет отправлять несколько одновременных рекурсивных запросов для одного и того же IP-адреса. Из-за этого в игру вступает математический феномен, известный как «парадокс дня рождения». Это приводит к тому, что вероятность успешной атаки возрастает почти до 100% с помощью всего нескольких сотен пакетов вместо десятков тысяч, которые ранее считались необходимыми.

Исследуя выводы Сакраменто, команда CERT также поняла, что возможна еще одна атака, основанная на работе Михала Залевского в области последовательных номеров TCP и анализе фазового пространства генераторов псевдослучайных чисел, используемых различными операционными системами для их генерации. , Залевский обнаружил, что с использованием определенного типа анализа часто тривиально угадать следующий порядковый номер в определенных реализациях. Команда CERT полагала, что это также может относиться к генераторам случайных чисел в BIND. Эта статья попытается показать, что их предположение было правильным.

Атака № 1 - Атака на день рождения
Чтобы выполнить эту атаку, необходимо отправить достаточное количество запросов уязвимому серверу имен, одновременно отправляя равное количество фальшивых ответов. Поскольку недостаток в программном обеспечении BIND генерирует несколько запросов для одного и того же доменного имени в одно и то же время, возникает статистически улучшенная вероятность попадания в точный идентификатор транзакции. Это классическая «атака на день рождения», которая происходит от «парадокса дня рождения», описанного ниже:

Атака на день рождения - это имя, используемое для обозначения класса атак грубой силы.Он получил свое название из-за удивительного результата, что вероятность того, что два или более человека в группе из 23 человек имеют одинаковый день рождения, больше 1/2;такой результат называется парадоксом дня рождения.

Если какая-либо функция, снабженная случайным входом, возвращает одно из k одинаково вероятных значений, то путем многократной оценки функции для разных входов мы ожидаем получить один и тот же выход примерно через 1,2k1 / 2. Для указанного выше парадокса дня рождения замените k на 365. (неизвестный автор, http://x5.net/faqs/crypto/q95.html)


Мы можем применить ту же методологию к последовательностям псевдослучайных чисел, таким как та, которая генерирует идентификаторы транзакций в BIND.

При обычной подмене мы бы отправляли n поддельных ответов на один запрос. Наша вероятность успеха равна n / 65535. При атаке на день рождения BIND мы отправляем n поддельных ответов на n запросов. Для этого мы можем предсказать вероятность успеха, используя формулу ниже, где t - общее количество возможных значений в основном наборе, а n - количество значений в подмножестве спуфинга.

Для этого мы можем предсказать вероятность успеха, используя формулу ниже, где t - общее количество возможных значений в основном наборе, а n - количество значений в подмножестве спуфинга

Сила этого метода спуфинга по сравнению с обычным спуфингом DNS показана на рисунке 2. Атака на день рождения приближается к 100% успеха около 700 пакетов. В этот момент обычная атака с использованием спуфинга будет иметь вероятность успеха только 700, деленную на 65535 (1,07%). Крутизна кривой такова, что для достижения коэффициента успеха 50% требуется всего 300 пакетов. Это вполне обычная атака на любого, кто имеет широкополосное подключение к Интернету.

Это показывает, что даже идеальный генератор случайных чисел уязвим для атаки, когда он генерирует несколько чисел для одной транзакции. Это то, что должен учитывать любой разработчик программного обеспечения, работающий со случайными числами. Это долго использовалось в атаках грубой силы на односторонние хеш-системы, как описано Брюсом Шнайером в его книге « Прикладная криптография» .

Атака BIND на день рождения будет следовать последовательности, показанной на рисунке 3. Злоумышленнику просто нужно отправить несколько сотен запросов на сервер имен ISP, запрашивающий IP-адрес доменного имени, который будет перехвачен. В то же время он отправит то же количество сформулированных ответов, чтобы они выглядели так, как если бы они были отправлены с авторитетного сервера имен. В каждом пакете он назначит случайный идентификатор транзакции. Чтобы быть успешным, один из его идентификаторов транзакций с поддельными пакетами, IP-адреса источника и назначения и порты должны совпадать с законным рекурсивным пакетом запроса от сервера имен жертвы.

Найти правильный IP-адрес очень просто; мы знаем нашу цель, и мы знаем адреса законных серверов имен для домена, который будет захвачен. Найти порт немного сложнее. Мы знаем, что порт назначения рекурсивного запроса - это UDP-порт 53, но исходный порт является движущейся целью. К счастью для нашего злоумышленника, BIND чаще всего использует один и тот же порт источника для запросов от имени одного и того же клиента. Таким образом, если злоумышленник работает с авторитетного сервера имен, он может сначала выполнить запрос DNS-поиска имени хоста на своем сервере. Когда приходит пакет рекурсивного запроса, он может посмотреть на порт источника. Скорее всего, это будет тот же порт источника, который использовался, когда жертва отправляет запросы на взлом домена. Посмотрите на вывод tcpdump четырех последующих запросов для разных доменных имен:

10: 54: 12.423228 192.168.1.2.33748> 66.218.71.63.53: 21345 [1au] A? www.yahoo.com. (42) (DF) 10: 54: 21.313293 192.168.1.2.33748> 216.239.38.10.53: 53735 [1au] A? www.google.com. (43) (DF) 10: 54: 27.182852 192.168.1.2.33748> 149.174.213.7.53: 19315 [1au] A? www.netscape.com. (45) (DF) 10: 54: 43.252461 192.168.1.2.33748> 66.35.250.11.53: 43129 [1au] A? www.linux.com. (42) (DF)

Все четыре запроса использовали исходный порт 33748 при запросе четырех разных серверов имен. Если бы BIND использовал рандомизированные исходные порты, он мог бы повысить свои шансы отразить спуфинговые атаки.

Если бы BIND использовал рандомизированные исходные порты, он мог бы повысить свои шансы отразить спуфинговые атаки

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

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

Атака № 2: Фазо-пространственный анализ, спуфинг
Примечание об уязвимости CERT в http://www.kb.cert.org/vuls/id/457875 сделал следующее наблюдение:

Кроме того, в статье Михала Залевского «Странные аттракторы и анализ порядкового номера TCP / IP» [ZALEWSKI] описан метод анализа предсказуемости идентификаторов транзакций, который, как мы полагаем, может быть расширен и для анализа пар портов идентификатора транзакции / UDP.

ОБНОВЛЕНИЕ - 08-13-2007

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

Суб-атак

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

Перенаправление веб-трафика

Атака такого рода может варьироваться от простого раздражения до финансового кошмара для большого числа людей. Цель здесь - создать веб-сайт, который будет достаточно похож на оригинал, чтобы не вызывать подозрений. Затем домен захватывается с помощью отравления кэша для максимально возможного числа интернет-провайдеров / компаний, в результате чего их трафик попадает на фальшивый сайт. Некоторые из под-атак здесь:

  • Перенаправить популярную поисковую систему на всплывающий рекламный сайт
  • Перенаправить сайт банка, чтобы получить доступ к паролям аккаунта.
  • Перенаправить новостной сайт, чтобы вводить лживые истории и манипулировать акциями

Человек посередине

В этом случае злоумышленник пытается перехватить безопасную связь между двумя сторонами. Например, Ксавье хочет сделать онлайн-покупку на сайте Юрия. Злоумышленник отравляет кеш у интернет-провайдера Ксавье, направляя трафик на сайт Юрия в систему Замфира. Zamfir принимает входящее SSL-соединение, расшифровывает его, считывает весь трафик и делает тот же запрос через SSL на сайт Юрия. Ответы Юрия читаются Замфиром, а затем отправляются обратно Ксавьеру в течение того же зашифрованного сеанса. У Zamfir теперь есть номер кредитной карты Ксавье и все другие детали, необходимые для его незаконного использования.

Рекомендуемые средства защиты от отравления DNS-кешем

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

Владелец домена
Для владельца домена вы мало что можете сделать, чтобы защитить себя от подделки вашего доменного имени уязвимому серверу имен. Если вы используете веб-сервер, рассмотрите возможность использования SSL для аутентификации в браузерах. В конце концов DNSSec позволит всем доменным серверам иметь криптографически подписанные записи, но в настоящее время это не получило широкого распространения. Даже обнаружение такой атаки будет затруднено, поскольку угон будет в значительной степени независимым от ваших серверов. Будьте внимательны к коротким атакам типа «отказ в обслуживании»; они могут указывать на то, что кто-то пытается временно замедлить работу вашего сервера или дать сбой, чтобы завершить попытку подмены.

ISP Nameserver Admin
Вы можете обновить BIND до последней версии из серии 9.x, которая не подвержена этой атаке. В качестве альтернативы вы можете попробовать использовать Djbdns , альтернатива BIND, написанная DJ Bernstein, автором программы MTA Qmail , Программное обеспечение djbdns поставляется с гарантией безопасности, в основном предлагая денежное вознаграждение всем, кто публично раскрывает законные уязвимости переполнения буфера в djbdns. Хотя гарантия не распространяется на атаки с отравлением кэша, позже в этой статье я покажу, что при правильном развертывании djbdns предлагает гораздо большую защиту от таких атак.

Отключите рекурсивные запросы из внешнего мира, используя DNS с разделением-разделением, если это возможно (см. Иллюстрацию 7). Split-split DNS означает, что у вас есть 2 сервера имен; один для предоставления информации о вашем общественном достоянии во внешний мир, а другой - для рекурсивных запросов для ваших пользователей. Публичный сервер не должен разрешать рекурсивные запросы, а рекурсивный (кэширующий) сервер должен быть защищен из Интернета брандмауэром.

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

Если вы не можете использовать расщепленный DNS, вы должны хотя бы попытаться ограничить число тех, кто может выполнять рекурсивные запросы с вашего сервера имен. Использование опции «allow-recursion» не дает вам особой защиты - помните, что злоумышленник уже подделывает IP-адрес источника, поэтому он просто знает, каким адресам разрешено выполнять рекурсивные запросы. Если возможно, используйте опцию «listen-on», чтобы привязать демон сервера имен к интерфейсу, защищенному от внешнего мира.

Если возможно, используйте опцию «listen-on», чтобы привязать демон сервера имен к интерфейсу, защищенному от внешнего мира

Конечный пользователь
Попросите вашего интернет-провайдера / компанию обновить BIND. Если они не открыты для этого, вы всегда можете запустить свой собственный рекурсивный преобразователь и обойти сервер имен провайдера. Практиковать безопасные вычисления; обновляйте антивирусное программное обеспечение и обновляйте подписи. Всегда проверяйте SSL-сертификаты при совершении безопасных онлайн-транзакций. Если вы подозреваете, что сайт подделан, вы можете использовать записи whois ARIN, чтобы определить, действительно ли IP-адрес принадлежит организации, которой принадлежит доменное имя.

продавец
Эту уязвимость можно исправить, изменив поведение BIND 8 и 4, чтобы отправлять только один запрос на любое количество запросов для одного и того же имени. BIND 9 уже делает это, так что, скорее всего, поставщик просто призовет людей обновить его. Тем не менее, BIND 9 также демонстрирует то же поведение повторного использования исходных портов. Это должно быть исправлено, так как это затруднит выполнение любых новых атак на PRNG.

Код подтверждения концепции: spooftest.pl

Я написал следующую программу, чтобы продемонстрировать выполнимость атаки BIND Birthday. Это только пассивная демонстрация; его нельзя использовать для выполнения реальной атаки. Он будет отправлять n запросов на рекурсивный сервер, одновременно генерируя набор спуфинга. который является просто массивом псевдо-случайных чисел. Если какой-либо из идентификаторов транзакций рекурсивных запросов, возвращаемых с целевого сервера имен, совпадает с номером в наборе спуфинга, атака была бы успешной.

#! / usr / bin / perl ########################################## #################### # spooftest.pl # # Джо Стюарта # # Проверяет, уязвим ли сервер BIND для техники # # спуфинга в День рождения, описанной Vagner Sacramento в # # http://www.rnp.br/cais/alertas/2002/cais-ALR-19112002a.htm # # # # Этот сценарий ДОЛЖЕН запускаться с # # IP-адреса авторитетного сервера имен и должен выполняться в место реального # # сервера имен. Он отправляет несколько запросов и видит, # ​​# может ли он угадать правильный идентификатор транзакции из целевого IP # # адреса. Если он угадает правильно, удаленный хост # # считается уязвимым для атаки BIND Birthday. # # Не отправляет никаких ответов, поэтому не может # # выполнить реальную атаку (извините, детишки из сценария) # ###################### ############################################### use IO :: Socket; использовать строгое; $ | = 1; my $ using = "Usage: $ 0 [IP-адрес] [количество пакетов] \ n"; my $ target = $ ARGV [0]; my $ m = $ ARGV [1]; умрите «$ using», если только $ ARGV [0] && $ ARGV [1]; умрите «использование $», если $ m! ~ / ^ \ d + $ / || $ m == 0; my $ domain = "mydomain.com"; # доменное имя с NS RR, указывающим на нас my $ r = 0xdead; # начальный идентификатор транзакции для наших запросов my @spoofingset; # список наших догадок my $ total = 65536; # всего возможных пакетов my $ maxlen = 1500; мои $ коллизии = 0; моя $ датаграмма; printf "Вероятность успеха при использовании пакетов $ m:% .2f %% \ n", 100 - (((1 - (1 / $ всего)) ** (($ m * ($ m - 1)) / 2) ) * 100); для (0 .. ($ m - 1)) {$ spoofingset [$ _] = sprintf ("% x", int (rand ($ total - 1))); } #print "Spoofing set:", join ("", @spoofingset), "\ n"; мой $ server = IO :: Socket :: INET-> new (LocalPort => 53, Proto => "udp") или die "Не может быть сервером udp на порту 53: $ @ \ n"; мой $ client = IO :: Socket :: INET-> new (PeerAddr => $ target, PeerPort => 53, Proto => "udp") или die "Не может быть клиентом udp на порту 53: $ @ \ п "; my ($ second, $ top) = split (/\./, $ domain); мой $ findlabel = chr (длина ($ секунда)). $ Второй; мой $ request = "\ x01 \ x00 \ x00 \ x01 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x03". "WWW $ findlabel \ x03 $ сверху \ x00 \ x00 \ x01 \ x00 \ x01"; for (0 .. ($ m - 1)) {## отправить запрос с инкрементным идентификатором транзакции $ client-> send (pack ("H *", sprintf ("% x", $ r ++)). $ request); } print "Отправил начальные запросы $ m DNS к цели ... \ n"; $ SIG {'ALRM'} = sub {die "timeout"}; мой $ count = 0; eval {alarm (30); while ($ count ($ m) {$ server-) recv ($ дейтаграмма, $ maxlen); my $ tid = sprintf ("% x", hex (распаковать ("H *", substr ($ datagram, 0,2)))); printf "Полученный рекурсивный запрос с идентификатором транзакции: $ tid \ r"; for (@spoofingset) {if ($ tid eq $ _) {print "\ nMatched TID $ tid в наборе спуфинга. Успех. \ n"; $ соударения ++; }} $ count ++; } тревога (0); }; if ($ @) {if ($ @! ~ / timeout /) {alarm (0); умри $ !; }} print "\ nПолученные рекурсивные запросы $ count для начальных запросов $ m \ n"; if ($ count == 0) {print "Цель не прослушивает или не отвечает на рекурсивные запросы \ n"; } if ($ count == 1) {print "Цель не является уязвимой \ n"; } if ($ collisions> 0) {print "Поддельная атака была бы успешной с", "этими параметрами. \ n"; } else {print "Поддельная атака не удалась в этом запуске. \ n"; }

Рекомендации

Альбитц, Пол и Крикет Лю. DNS и Bind. 3-е изд. Севастополь, Калифорния: O'Reilly & Associates, Inc, 1998.

Мокапетрис, Пол. RFC 882 - ДОМЕННЫЕ ИМЕНА - КОНЦЕПЦИИ И СРЕДСТВА. Ноябрь 1983
http://www.faqs.org/rfcs/rfc882.html

Мокапетрис, Пол. RFC 883 - ДОМЕННЫЕ ИМЕНА - ОСУЩЕСТВЛЕНИЕ И СПЕЦИФИКАЦИЯ. Ноябрь 1983
http://www.faqs.org/rfcs/rfc883.html

Интернет-консорциум программного обеспечения. 15 декабря 2002
http://www.isc.org/downloads/BIND/ ,

CERT / CC Примечание об уязвимости VU # 457875. 5 декабря 2002 г. 15 декабря 2002 г.
http://www.kb.cert.org/vuls/id/457875 ,

CERT Advisory CA-1997-22 BIND - демон интернет-имени Беркли. 26 мая 1998 г. 15 декабря 2002 г.
http://www.cert.org/historical/advisories/CA-1997-22.cfm ,

Как работает «парадокс дня рождения»? 15 декабря 2002 г.
http://people.howstuffworks.com/question261.htm ,

Что такое атака на День Рождения? 15 декабря 2002 г.
http://x5.net/faqs/crypto/q95.html ,

Шнайер, Брюс. Прикладная криптография. 2-е изд. Нью-Йорк: John Wiley & Sons, Inc, 1996.

DNSSEC - Защита системы доменных имен. 15 декабря 2002 г.
http://www.dnssec.net/

DJ Бернштейн. djbdns: инструменты системы доменных имен. 15 декабря 2002 г.
http://cr.yp.to/djbdns.html

Au] A?
Au] A?
Au] A?
Au] A?
Например, хотите ли вы предотвратить, чтобы ваши пользователи возвращали поддельные данные?
Или вы пытаетесь предотвратить взлом вашего доменного имени?