< HomePage | Снимки
<- Понеделник, 21 Юли 2008 | Начална страница | Сряда, 23 Юли 2008 ->
Вторник, 22 Юли 2008

Администраторите, които не са обновили DNS съвърите под техен контрол е крайно време да го направят! Из нета тук-там народа се изказа скептично спрямо новата и все още не обявена официално атака, но днес започнаха да се появяват подробности около нея и от това, което виждам ми се струва, че няма никаво място за омаловажаване и мотаене.

Ако на първо четене не ви стане ясно точно какъв е проблемът, прочетете цялото писание пак и пак и пак. Проблемът наистина е много-много сериозен и ако DNS софтуерът ви разчита само на ограниченото (16-bit) DNSID поле, за да потвърждава валидността на отговора, считайте че рекурсивният ви сървър е лесна плячка и ЩЕ БЪДЕ ужасно лесно да подведен да връща фалшиви отговори. От там клиентите ползващи го, едва ли ги чака нещо хубаво.

[ Коментари: 18 | Добави коментар ]
Коментари

"Цялото описание" завършва така:
"[...] Mallory has combined attack #1 with attack #2, defeating fix #1 and fix #2. Mallory can conduct this attack in less than 10 seconds on a fast Internet link."

Аз ли не разбирам, или там пише, че и случайните портове плюс случайните QID-та (fix #1), заедно със "bailiwick checking" (fix #2) пак не решават проблема...? :(

Написа Geo на 23-Jul-2008 22:41


В описанието на атаката липсва елемента случайни портове, затова завършва така.

При добавянето на случайните портове се увеличава трудността в спечелването на race-a, защото вместо само 2^16 възможности за случайно ID в комбинацията със случайни портове вероятността да улучиш ID вече е близо 2^32, което си е трудна работа, но за съжаление не и невъзможно. Така описана атаката може да бъде провеждана просто докато успее, защото атакуваният едва ли ще забележи нещо, а улучиш ли веднъж ID-то, играта е спечелена. Затова и ISC бяха написали, че проблемът може да се реши само с ползване на DNSSEC.

Написа Георги Чорбаджийски (www) на 24-Jul-2008 01:40


Ако позволите, 2 неща не ми станаха ясни:

За да ги опиша по-просто, нека допуснем че резолверът (когото заблуждават лошите) е с IP адрес 1.1.1.1, ауторитативния сървър е с адрес 2.2.2.2, а атаката идва от 6.6.6.6

Ако съм разбрал правилно механизма на отравянето, 6.6.6.6 изпраща постоянно "поток от DNS отговори" към 1.1.1.1 и разчита да отговори с еднакво QID на запитване за дадено име преди 2.2.2.2 да успее да направи това.

Ако е така:

1. Как точно се генерира въпросния поток, изисква ли това специализиран софтуер и познания от по-задълбочено ниво?
2. Една DNS транзакция единствено на QID ли разчита? Не се ли проверява и адреса от който идват отговорите? Искам да кажа, защо резолверът 1.1.1.1 трябва въобще да слуша отговорите от 6.6.6.6 при положение че въобще не го е питал за нищо?


--
Извинявам се, ако за някого отговорите са прекалено очевидни, ще съм благодарен да понауча нещо в тази посока.

Написа mx_starter на 24-Jul-2008 11:57


В добавка към постоянното изпращане на отговори, което си е стара атака, тук развитието е изпращането на glue записи заедно с тези отговори.

1. Със софтуер като например dsniff и конкретно dnsspoof програмчето в него /лесно може да се пачне, за да праща освен фалшиви отговори и glue записи). Вече има модул за metasploit, който осъществява атаката както е описана.
2. Разбира се, че се проверява адреса, но за тези заявки DNS ползва UDP, което значи че изпращането на фалшиви пакети е елементарно (подсказка, UDP не е session oriented протокол като TCP и всеки пакет е грубо казано "сам за себе си").

Написа Георги Чорбаджийски (www) на 24-Jul-2008 12:04


@Георги:
Тоест, не може да се докаже със сигурност че даден UDP пакет идва от определен адрес?

А пък с тоя отговор на първия въпрос току виж се наложи да ти носим цигари в затвора, хехе...

Написа mx_starter на 24-Jul-2008 12:47


Не, всеки може да генерира каквито udp пакети му душа сака :-)

Написа Георги Чорбаджийски (www) на 24-Jul-2008 13:01


Ето вече и работещи експлойти:
http://blog.wired.com/27bstroke6/2008/07/dns-exploit-in.html

"We just added a second exploit which replaces the nameservers of the target domain. This is the bug people should actually care about, since it doesn't matter if anything is already cached.

Regarding the cache situation (of the first exploit) -- it's not possible to do cache overwrites, but it is possibe to look up the cache timeout, wait for it, and then replace it. With the new exploit module, we just change the DNS server for the entire domain (regardless of what is cached), so it's much more effective for wide-scale hijacking."

Който се мотае с обновяване е крайно време да се събуди.

Написа Георги Чорбаджийски (www) на 24-Jul-2008 13:43


По-тревожното е, че тук в БГ не съм видял някой да се е загрижил сериозно.
А я си представи какъв квич ще настане в медиите ако някой им подхвърли мръвката?
Отсега си се хиля представяйки си заглавия от сорта "Краят на Интернета", "Апокалипсис в мрежата" или "Хакнаха пак сайта на президента, показва порно сцени"...
Чудя се как не са надушили още...

Написа mx_starter на 24-Jul-2008 13:54


Като се погаври някой с dns-ите на бтк, ще се чуе :-)

Написа Георги Чорбаджийски (www) на 24-Jul-2008 13:56


И аз за БТК се сетих, и нахарах един познат с ADSL да тества на сайта на Kaminski. Изглежда са update-нали. Виж държавните институции са друга бира. При зареждане на сайта на НАП под windows, примерно се натъкваме на http://img522.imageshack.us/my.php?image=napur0.jpg
Проблема с DNS, както е отбелязано горе е много много сериозен, нищо че някои го подценяват.

Написа Николай на 24-Jul-2008 14:32


dnscache
djbdns-1.05
http://cr.yp.to/djbdns/forgery.html

Написа Nikola Vladov на 24-Jul-2008 20:34


@nikola: тези никога не са били уязвими, djb си знае работата :)

Написа Георги Чорбаджийски (www) на 24-Jul-2008 20:58


@Георги
Като спомена, че докторът си знае работата, спомням си че преди бая време се канеше да зарязваш qmail.
Какво стана с таз работа? Гледам че май си се отказал все пак?

Написа V. Vassilev на 24-Jul-2008 21:57


@mx_starter

Надушили са ... ама не знаят какво, на 10-ти беше това:

http://news.ibox.bg/news/id_897887249

Не им се смейте. Много. Те толкоз си могат :)

п.п. Преди малко получих мейл на abuse@ ... от myNetWatchman, с който ме уведомяват, че на еди-кой-си-адрес в мрежата имало vulnerable name server. И да, наистина има (на клиент, уведомен е) ... така че да се надяваме хората да вземат мерки.

Написа N.Pepelishev на 25-Jul-2008 00:03


@v.vasilev: поради елементарен мързел отпред на unixsol стои един qmail. Иначе си ползваме courier-mta и е супер. Някой ден просто ще си поиграя няколко часа и от qmail-а няма да остане и следа :)

Написа Георги Чорбаджийски (www) на 25-Jul-2008 00:31


В мрежата имам един сървър, за който би трябвало да се грижи друг човек и, съответно, bind не беше пипнат. Да, ама получих мейлче със събджект: myNetWatchman Urgent Alert: Hosts confirmed vulnerable to US-CERT: VU#800113 (Multiple DNS implementations vulnerable to cache poisoning) и с обяснения каква мизерия може да стане + ip адреса на неъпдейтнатата машина.

Написа Коко на 25-Jul-2008 15:02


На тез тикви сме им клиент и една от зоните ни се бекъпва от същия NS.

; <<>> DiG 9.5.0-P1 <<>> @pns.btc-net.bg version.bind chaos txt
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63414
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;version.bind. CH TXT

;; ANSWER SECTION:
version.bind. 0 CH TXT "9.2.2"

Написа x3f на 28-Jul-2008 21:13


За клиентите на тези провайдери, изход в ползването на opendns.com

Написа Георги Чорбаджийски (www) на 28-Jul-2008 22:42


Добавяне на коментар
Не пишете nicknames, освен ако не се обръщам така към вас.
Е-мейл адресът няма да се показва на сайта.
Към него ще има връзка.

Коментарът трябва да е написан на български с кирилица или на английски. Останалите се трият.

Запомни адреса и името ми, за да не го пиша следващия път
начало
Valid XHTML 1.0! Valid CSS!