The Diary
Дневникът на Георги
<- Понеделник, 21 Юли 2008 | Начална страница | Сряда, 23 Юли 2008 ->
Вторник, 22 Юли 2008
Администраторите, които не са обновили DNS съвърите под техен контрол е крайно време да го направят! Из нета тук-там народа се изказа скептично спрямо новата и все още не обявена официално атака, но днес започнаха да се появяват подробности около нея и от това, което виждам ми се струва, че няма никаво място за омаловажаване и мотаене.
Ако на първо четене не ви стане ясно точно какъв е проблемът, прочетете цялото писание пак и пак и пак. Проблемът наистина е много-много сериозен и ако DNS софтуерът ви разчита само на ограниченото (16-bit) DNSID поле, за да потвърждава валидността на отговора, считайте че рекурсивният ви сървър е лесна плячка и ЩЕ БЪДЕ ужасно лесно да подведен да връща фалшиви отговори. От там клиентите ползващи го, едва ли ги чака нещо хубаво.
[ Коментари: 18 ]Коментари
В описанието на атаката липсва елемента случайни портове, затова завършва така.
При добавянето на случайните портове се увеличава трудността в спечелването на race-a, защото вместо само 2^16 възможности за случайно ID в комбинацията със случайни портове вероятността да улучиш ID вече е близо 2^32, което си е трудна работа, но за съжаление не и невъзможно. Така описана атаката може да бъде провеждана просто докато успее, защото атакуваният едва ли ще забележи нещо, а улучиш ли веднъж ID-то, играта е спечелена. Затова и ISC бяха написали, че проблемът може да се реши само с ползване на DNSSEC.
Ако позволите, 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 при положение че въобще не го е питал за нищо?
--
Извинявам се, ако за някого отговорите са прекалено очевидни, ще съм благодарен да понауча нещо в тази посока.
В добавка към постоянното изпращане на отговори, което си е стара атака, тук развитието е изпращането на glue записи заедно с тези отговори.
1. Със софтуер като например dsniff и конкретно dnsspoof програмчето в него /лесно може да се пачне, за да праща освен фалшиви отговори и glue записи). Вече има модул за metasploit, който осъществява атаката както е описана.
2. Разбира се, че се проверява адреса, но за тези заявки DNS ползва UDP, което значи че изпращането на фалшиви пакети е елементарно (подсказка, UDP не е session oriented протокол като TCP и всеки пакет е грубо казано "сам за себе си").
@Георги:
Тоест, не може да се докаже със сигурност че даден UDP пакет идва от определен адрес?
А пък с тоя отговор на първия въпрос току виж се наложи да ти носим цигари в затвора, хехе...
Не, всеки може да генерира каквито udp пакети му душа сака :-)
Ето вече и работещи експлойти:
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."
Който се мотае с обновяване е крайно време да се събуди.
По-тревожното е, че тук в БГ не съм видял някой да се е загрижил сериозно.
А я си представи какъв квич ще настане в медиите ако някой им подхвърли мръвката?
Отсега си се хиля представяйки си заглавия от сорта "Краят на Интернета", "Апокалипсис в мрежата" или "Хакнаха пак сайта на президента, показва порно сцени"...
Чудя се как не са надушили още...
Като се погаври някой с dns-ите на бтк, ще се чуе :-)
И аз за БТК се сетих, и нахарах един познат с ADSL да тества на сайта на Kaminski. Изглежда са update-нали. Виж държавните институции са друга бира. При зареждане на сайта на НАП под windows, примерно се натъкваме на http://img522.imageshack.us/my.php?image=napur0.jpg
Проблема с DNS, както е отбелязано горе е много много сериозен, нищо че някои го подценяват.
dnscache
djbdns-1.05
http://cr.yp.to/djbdns/forgery.html
@nikola: тези никога не са били уязвими, djb си знае работата :)
@Георги
Като спомена, че докторът си знае работата, спомням си че преди бая време се канеше да зарязваш qmail.
Какво стана с таз работа? Гледам че май си се отказал все пак?
@mx_starter
Надушили са ... ама не знаят какво, на 10-ти беше това:
http://news.ibox.bg/news/id_897887249
Не им се смейте. Много. Те толкоз си могат :)
п.п. Преди малко получих мейл на abuse@ ... от myNetWatchman, с който ме уведомяват, че на еди-кой-си-адрес в мрежата имало vulnerable name server. И да, наистина има (на клиент, уведомен е) ... така че да се надяваме хората да вземат мерки.
@v.vasilev: поради елементарен мързел отпред на unixsol стои един qmail. Иначе си ползваме courier-mta и е супер. Някой ден просто ще си поиграя няколко часа и от qmail-а няма да остане и следа :)
В мрежата имам един сървър, за който би трябвало да се грижи друг човек и, съответно, bind не беше пипнат. Да, ама получих мейлче със събджект: myNetWatchman Urgent Alert: Hosts confirmed vulnerable to US-CERT: VU#800113 (Multiple DNS implementations vulnerable to cache poisoning) и с обяснения каква мизерия може да стане + ip адреса на неъпдейтнатата машина.
На тез тикви сме им клиент и една от зоните ни се бекъпва от същия 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"
За клиентите на тези провайдери, изход в ползването на opendns.com
Disclaimer: Except where otherwise noted all opinions expressed here are personal
opinions of the author and do not reflect official opinions of my employer or
any other person, company or organization associated with the author.
Copyright: Except where otherwise noted the content of this site is licensed under a
Creative Commons Attribution License. Текстът на договора за ползване на български
Copyright (cc) 2003-2011 Georgi Chorbadzhiyski. Some rights reserved.
Comments, texts and pictures not signed by me are property of their respective owners.
Страницата е генерирана от Glog v3.99-test
"Цялото описание" завършва така:
"[...] 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 19:41