Опубликован эксплойт для «отравления» DNS-кэша

А защиту-то где посмотреть? или это провокация? ;)

> А защиту-то где посмотреть?

Вообще говоря, защиты нет. :) Это уязвимость протокола.

Можно сходить на сайт к Каминскому, проверить там свой DNS. Некоторые дистрибьюторы пытались выложить заплатки. Эксперты говорят, что эти заплатки ничего не заплатывают.

> или это провокация? ;)

В каком смысле провокация? ;)

Ах да, сайт забыл... http://www.doxpara.com/ Он там справа, серенький такой.

>В каком смысле провокация? ;)

ну как бы обычно на патчи новости выкладывают и т.д. а тут защиты нет. ссылка на експлойт... провокация:)

> ну как бы обычно на патчи новости выкладывают и т.д. а тут защиты нет. ссылка на експлойт... провокация:)

Ну, пусть будет провокация, если Вам того так хочется. :) Исходники эксплойта в свободном доступе, программа бесплатна. Проверьте, если хотите.

вот из фиксы в OpenBSD уже сделали http://undeadly.org/cgi?action=article&sid=20080723204659&mode=expanded

Ага, вы бы видели, какие баталии развернулись в misc@openbsd.org по поводу этого патча. Ведь ошибку обнаружили относительно давно, а опенбсд-девелоперы выпустили патч только сейчас. правда, на то были существенные причины.

Кстати, а на чем этот эксплоит написан? Интересный язык. Типа перла под тяжелым макропроцессором ;)

> Эксперты говорят, что эти заплатки ничего не заплатывают.

Можно подробнее?

> Кстати, а на чем этот эксплоит написан? Интересный язык. Типа перла под тяжелым макропроцессором ;)

Очевидно, внутренний язык Metasploit.

называется "кто не спрятался - я не виноват", теперь ленивым админам и их подопечным придется несладко, наверняка в сети еще полно непропатченных DNS серверов

сделают "копию" сайта windows update например - вот и готов ботнет )

> Можно подробнее?

Ну вот, например http://www.edn.com/blog/400000040/post/1480030348.html

пропатчил свои сервера под саляркой. нагрузка на CPU вырасла минимум в два раза если не больше, пришлось в срочном порядке перетаскивать с двух голового сервака на четырёх головый и всё равно сервак загружен на 100%. Радости мало.

Нифига не понимаю. Ну, т.е. меня эта байда вообще не касается, как я понял, у меня PowerDNS как авторитетный и djbdns как кеширующий. Везде, и уже несколько лет как. И я нифига не могу понять что за "flaw" в протоколе? Когда посылается днс-запрос, то он посылается на определённый адрес и определённый порт, и только с них полученный ответ считается, а случайное число в заголовке скорее для идентификации запроса, когда их одновременно много идёт. Не пойму как на этом можно организовать атаку, чтобы в чужой кеш чего-то подсунуть?

Нифига я не понял... Ну сказал мне проверяльщег, что мой днс уязвим. Что дальше-то делать? Где заплатки?

смотря чем пользуетесь опять таки - всегда есть исходники, для BIND на http://www.isc.org/bind

вот для тех у кого есть сомнения что и как и опубликован эксплоит...

Страшно жить стало. Переписал IP адрес лора на листочек, на всякий случай.

>всегда есть исходники, для BIND на http://www.isc.org/bind

Это прикол в стиле "есть исходники, можешь сам пофиксить"?

Мне эта байда TCP/IP напоминает Линукс - студенческая поделка, слишком серьёзно воспринятая и распространившаяся по всему миру (как зараза).

Эээ это нормально ?

Your name server, at ХХ.ХХХ.ХХХ.Х, appears to be safe, but make sure the ports listed below aren't following an obvious pattern.

> Администраторам рекомендуется срочно произвести обновление BIND до версий 9.5.0-P1, 9.4.2-P1, 9.3.5-P1

Сейчас впаду в состояние аффекта и остановлю bind.

>Мне эта байда TCP/IP напоминает Линукс

Сам-то ты сидишь на могучем фидонете, поди.

>известных имплементаций.

кноун имплементатионс.

нет, это не прикол и не "пофиксить" а установить ) впрочем - репозитории всех нормальных дистров уже давно имеют обновленный пакет bind

идет речь не о tcp/ip а о ДНС, к тому же дырки были во всех ДНС серверах включая Microsoft DNS сервер

причем тут линукс?

да

http://www.doxpara.com/

Стрим.

> Your name server, at 62.5.255.34, appears vulnerable to DNS Cache Poisoning.

> Переписал IP адрес лора на листочек, на всякий случай.

Как теперь узнаешь был ли это правильный адрес?

Оставил только кэширующий . Обновлений в redhat нет.. У прова freebsd - dig показывает 9.3.5-P1

> Оставил только кэширующий . Обновлений в redhat нет.. У прова freebsd - dig показывает 9.3.5-P1

Разве нет? А это: https://www.redhat.com/archives/fedora-package-announce/2008-July/msg00402.html разве не оно? Если я правильно понимаю, речь идёт о уязвимости, которую исправили в начале месяца.

> Ну, т.е. меня эта байда вообще не касается, как я понял, у меня PowerDNS как авторитетный и djbdns как кеширующий.

Тебя и меня /не сильно/ касается. Чтобы проспуфить, надо угадать и порт (2^16 - 1024), и идентификатор (2^16), оба числа djb получает достаточно стойким алгоритмом.

А у bind без патча порт всегда один, выбирается при запуске — это они так производительность повышали. Мало того, у него ещё и для вычисления следующего id используется нестойкий алгоритм: зная предыдущий ip, можно предсказать следующий с вероятностью около 1/16.

> Когда посылается днс-запрос, то он посылается на определённый адрес и определённый порт

Нет. Он его посылает /с/ определенного порта, и ответ ждет на него же.

> а случайное число в заголовке скорее для идентификации запроса, когда их одновременно много идёт.

Изначально так и было, но наличие id ещё и повышает стойкость к спуфу в 2^16 раз.

> Не пойму как на этом можно организовать атаку, чтобы в чужой кеш чего-то подсунуть?

Смотри, в нормальной сети авторитарный и кеширующий серверы разнесены (чего bind особо не умеет), причем второй принимает запросы от клиентов на одном интерфейсе, а сам ресолвит с другого.

Подключенный к твоей сети злоумышленник ищет дополнительно провайдера-идиота, который выпускает из своей сети любые ip, а таких всё ещё полно (можно спуфить), затем:

1. Запрашивает у твоего сервера случайное имя в контролируемом им домене — узнает порт.

2. Запрашивает в цикле имена из атакуемого домена, параллельно отправляя через другое подключение кучу пакетом с фиктивным ip на известный ему порт.

3. С (очень) большой вероятностью через конечное время подменяет в кеширующем bind всё что угодно.

PS. А если у тебя кривой bind, который слушает ответы серверов на *:port, и в сети не контролируется reverse path (ты сам — тупой провайдер), то спуфится с одного подключения за секунды.

> Страшно жить стало. Переписал IP адрес лора на листочек, на всякий случай.

дурик, не на листочек, а в hosts, где он и находится у большинства здесь присутсвующих (я так думаю, может и неправ ?)

Не-а, не прав. Если у ЛОР'а IP поменяется (какие-нибудь передвижки у хостера), будешь долго соображать, что ты не видишь ЛОР потому, что у тебя в hosts не тот IP.

Я правильно понял, что уязвимы только кеширующие сервера. За те, которые зоны отдают можно не бояться?

Так-с. Задача в кеширующем днс сделать заданное содержимое, так? Т.е. имеет смысл атаковать кеш какого-либо провайдера, чтобы клиентов потом перенаправить куда нам надо? Теперь понял. У меня действительно никогда не было таких проблем, с момента появления pdns мне не нужен бинд как авторитетный, а как кеширующий djbdns мне всегда больше нравился. Хехе. Теперь я понял намёки хакеров, что они использовали бинд для взлома сайтов. Оказывается, это старая хакерская лазейка наконец-то раскрыта :)

> Так-с. Задача в кеширующем днс сделать заданное содержимое, так?

Ага.

> Т.е. имеет смысл атаковать кеш какого-либо провайдера, чтобы клиентов потом перенаправить куда нам надо?

Естественно. Причем мы можем выяснить порт для исходящих, спровоцировав обращение к нашему DNS (пощупав кривой почтарь/веб-сервер, например). А затем, зная, что у любого крупного провайдера запросы в какой-нибудь mail.ru, google.com или microsoft.com шпарят постоянно, тупо спуфить ответы от их NS.

Хотя лучше просто подменить [a-m].root-servers.net ;)

> Оказывается, это старая хакерская лазейка наконец-то раскрыта :)

Этому баяну со лет в обед, djb разбирал по полочкам ещё десяток лет назад. Просто никому оно нафиг не надо было заморачиваться. Это как с SMTP — пока как-то работает, никто менять не будет.

> Кстати, а на чем этот эксплоит написан? Интересный язык. Типа перла под тяжелым макропроцессором ;)

Metasploit написан на Ruby. Эксплоит, видимо, тоже.

> Разве нет? А это: https://www.redhat.com/archives/fedora-package-announce/2008-July/msg00402.html разве не оно? Если я правильно понимаю, речь идёт о уязвимости, которую исправили в начале месяца.

Да, верно. В redhat и соответсвенно в centos и fedoar это пофиксили еще 10 июля.

капча - thucks

>> Можно подробнее?

> Ну вот, например http://www.edn.com/blog/400000040/post/1480030348.html

Там просто написано, что уязвимость лежит в самом протоколе. А патч направлен на снижение вероятности ее использования путем увеличения "случайности" случайных чисел, используемых в запросах.

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

> Мне эта байда TCP/IP напоминает Линукс - студенческая поделка, слишком серьёзно воспринятая и распространившаяся по всему миру (как зараза).

Угу. Предложи концептуально новый стек, лишенный каких бы то ни было вообще проблем и недостатков.

TCP/IP разрабатывался в 70-е гг., когда вообще компьютерные сети были уделом немногих. И на тот момент все сегодняшние проблемы типа DoS и т.п. не были актуальны.

> Смотри, в нормальной сети авторитарный и кеширующий серверы разнесены (чего bind особо не умеет)

Чего именно он не умеет?

>"заплатки ничего не заплатывают"

Может и заплатывают, но ИМХО, нужно не только повышать "случайность" id-пакета и src-адреса, от которого делается запрос, но и принимать все ответы, допустим в течении 0,1 сек. И если пришло несколько пакетов (ответов) с разными id, то игнорировать все пакеты...

[*] Sent 22000 queries and 440000 spoofed responses...

ну когда уже?

>Этому баяну со лет в обед, djb разбирал по полочкам ещё десяток лет назад. Просто никому оно нафиг не надо было заморачиваться. Это как с SMTP — пока как-то работает, никто менять не будет.

нет, Каминский показал, что можно не только перебирать 16-битный id, а еще и использовать дополнительные секции для RR, содержащие обновленную информацию.

Т.е. перебирать id хакер будет для qweasdzxc.herznaet4to.com, а в additional rr поставит 'A rdata' для www.google.com, и тем самым заменитв кэше эти данные.

>matumba (*) (24.07.2008 19:56:04)

Ужас, сколько тупых унылых виндотроллей на лоре - nikolayd, iRunix, Corran_Horn, matumba.. Где вас столько штампуют? На Фабрике Идиотов им. баллмера?

вот потому и БЫЛ СОЗДАН IPv6.

> перебирать id хакер будет для qweasdzxc.herznaet4to.com, а в additional rr поставит 'A rdata' для www.google.com, и тем самым заменитв кэше эти данные.

Как бы помягче сказать... Это называется cache poisoning, известен уже /почти 20 лет/. Неоднократно обсосан всеми, включая djb. Никто, кроме bind (и производных) на него не ловится.

djb говорил только о переборе id. И атака эта известна _только_ для перебора id. Об особенности additional RRs Дэн Камински будет говорить впервые.

> Об особенности additional RRs Дэн Камински будет говорить впервые.

Какая самоуверенная молодежь пошла... Повторяю, Дэн уже не раз
говорил об этом. И djbdns на такую туфту не ловится.

Так, для общего ознакомления:

„Poison

 RFC 1034's resolution algorithm allows any server on the Internet
to destroy, or take over, yahoo.com. All the nasty.dom server has to do
is delegate www.nasty.dom to the yahoo.com servers while providing
false addresses for those servers: 
     www.nasty.dom NS ns1.yahoo.com
     www.nasty.dom NS ns2.dca.yahoo.com
     www.nasty.dom NS ns3.europe.yahoo.com
     www.nasty.dom NS ns5.dcx.yahoo.com
     ns1.yahoo.com A 1.2.3.4
     ns2.dca.yahoo.com A 1.2.3.4
     ns3.europe.yahoo.com A 1.2.3.4
     ns5.dcx.yahoo.com A 1.2.3.4

 The nasty.dom server can now wait for (or encourage) the cache to ask
about www.nasty.dom. When the cache receives the answer, it will,
according to RFC 1034, save the forged yahoo.com addresses for
future reference. Subsequent queries for yahoo.com will be misdirected.
...
It's obvious how to eliminate all poisoning. Caches must discard
yahoo.com information except from the yahoo.com servers, the com servers, and the root servers. This stops malicious poisoning, so
of course it stops accidental poisoning too. End of problem.“


Сейчас ни один нормальный кеширующий сервер не примет информацию от
левого домена, где бы в ответе она не находилась.