Явявайки се един от основните елементи на инфраструктурата на IP-мрежата службата DNS, в същото време е далеч не толкова идеална от гледна точка на информационната безопасност. Ползването на транспортния протокол без установяването на виртуалният канал (UDP), отсъствието на средства за идентификация, оторизация и разграничения на достъпа, я правят уязвима за различни типове отдалечени атаки. В статията ще разгледаме междусегментната отдалечена атака на DNS-сървър, която не изисква твърде сериозни условия за провеждането и, а същевременно е ефективна и с практическа реализация.
• DNS с думи прости е разпределена база данни, основното съдържание на която се явява информацията за съответните символни имена на мрежовите обекти, техните IP-адреси. DNS е опганизирана по йерархически принцип. Структурната единица на тази база е домейна (domain), който на свои ред може да съдъпжа други домейни (поддомейни). Първичният источник на информация за всеки домейн е отговарящият за даденият домейн DNS-сървър (могат да бъдат няколко). Отговорността за част от информацията на домейна (поддомейна) може да бъде делегирана на други сървъри. Клиентската част DNS се нарича resolver, достъпът до който приложните програми получаст чрез API. При взаичодействие на resolver'a със сървъра в качество на транспортен протокол се използва UDP. Запитванията генерирани от resolver'а се явяват рекурсивни, т.е. в качеството на отговор на такова запитване се връща или исканата информация или съобщение за нейното отсъствие. Получавайки запитване от resolver'а, съвръра или веднега връща отговора (при условие, че исканата информация е в базата), или формира запитване към друг сървър. Това запитване обикновено се явява интерактивно и за разлика от рекурсивното допуска отговор във вид на препратка към друг сървър, който е по-добре осведомен за мястото на разположение на исканата информация. Като общо търксенето започва от кореновия сървър, който възвръща информацията за сървърите отговарящи за домейна на най-горно ниво, след което се формира ново интерактивно запитване към един от тези сървъри и т.н. Резултата от тази верига въпрос/отговор се явява или получаването на исканата информация или информация за нейното отсъствие, след което отговорът се връща на resolver'а. всички запитвания към сървъра в процеса на работа се кешират с цел ускорение обслужването на последните запитвания и минимизация на мрежовия трафик.
• Междусегментна отдалечена атака на DNS-сървър
Възможността за атака на DNS по пъта на фалшификация на отговора на DNS-сървъра е известна доста отдавна. Обектът на атака може да е както resolver'а, така и DNS-сървъра. Причината за успеха на подобни атаки се крият в лекотата на фалшификация на отговорите на сървъра. Протоколите DNS, използвани в днешно време не включват кой знае какви средства за проверки на оторизацията на получаваните данни и техния източник, напълно осланяйки се в това на по-ниско лежащите протоколи на транспортно ниво. Използваният транспортен протокол (UDP), с цел повишаване ефективността не предполага установяване на виртуален канал и използва в качества на идентификатор източника на съобщения IP-адреса, който може да бъде елементарно подправен. При възможност атакващия да прехване съобщения, които лъжат клиента и сървъра (вътрешно сегментна атака) реализацията на такава атака не представлява почти никаква трудност. Въпреки всичко такъв вариант на атака не представлява значителен практически интерес, до колкото възможността за вътрешно сегментна атака предполага наличието на определен взаимно свързан клиент със сървъра и хоста (например, атакуващият и целеви DNS-сървър ги разделя физическата среда на предаване), което на практика се реализира доста рядко. По-чести са случаите на междусегментни атаки, които не изискват такива усливия. По тази причина ние ще се спрем именно на такъв клас отдалечени атаки представляващи както академичен, така и практически интерес. Междусегментната атака на DNS-сървъра изглежда по следния начин. Да предположим, че цел на атаката ни се явява поддомейн с IP-адрес на web-сървъра http://www.coolsite.com с IP-адрес на сървъра http://www.badsite.com за user'ите на някаква мрежа, която обслужва DNS-сървъра ns.victim.com. Във фазата на атака ns.victim.com се провокира за търсенето на информация за IP-адрес http://www.coolsite.com по пътя на рекурсимно запитване. Във втората фаза атакуващия изпраща на сървъра ns.victim.com лъжлив отговор от името на ns.coolsite.com, който се явява отговорен за домейн coolsite.com. в лъжливия отговор вместо реалния IP-адрес на http://www.coolsite.com се указва IP-адреса на http://www.badsite.com. Сървърът ns.victim.com кешира получената информация в резултат на което в течение на определен промеждутък от време (големината на промеждутъка се указва в полето TTL на лъжливия отговор и може да се избира произволно от атакуващия) нищо неподозиращите user'и вместо на сървъра http://www.coolsite.com попадат на http://www.badsite.com. за да може лъжливият отговор да бъде възприет от сървъра ns.victim.com като истински е достатъчно да бъдат изпълнени четири условия: IP-адреса на отправителя на отговора е длъжен да съответства на IP-адреса на запитващия сървър (в нашия случай ns.coolsite.com); UDP-портът към който се отправя оговора трябва да съвпада с порта, от който е било изпратено запитването; идентификаторът трябва да съвпада с идентификаторът на запитването; отговорът трябва да съдържа запитваната информация (в нашия случай IP-адреса на web-сървъра http://www.coolsite.com). Очевидно е, че изпълнението на първото и четвъртото условие за атакуващия няма да е трудно. Второто и третото условие на ситуацията са малко по-сложни, до колкото в случая на междусегментна атака, атакуващия няма възможност да прехване изходното запитване и да "прегледа" необходимите параметри. Болшинството използвани в двешно врими за реализация DNS-сървъри (BIND4, MS DNS) използват за изходни запитвания порт 53, така че може успешно да се изпрати лъжлив отговор към този порт. Дадения метод обаче не винаги сработва, например BIND8 може да използва за изходни запитвания случайно избран непривилигирован порт. Идентификаторът (id) на запитването представлява двубайтово число, указващо сървъра в запитването с цел еднозначна идентификация на отговора на даденото запитване. Това число се инкрементира с всяко ново запитване. Незнанието на некущото значение на идентификаторът довежда до необходимост от изпращане на множество лъжливи отговори с различни значения id. Именно това обстоятелство прави практическата реализация на дадената атака трудно осъществима. Действително лъжливия отговор трябва да бъде получен от целевия сървър в промеждутък от време от момента на изпращането на запитването до момента на пристигането на отговора от истинския сървър, което на практика представлява не повече от няколко секунди. За този интервал от време атакуващия трябва да изпрати 216 лъжливи отговора с всички възможни значения id, а в случаите на незнание на портовете тази цифра се увеличава с още няколко десетки пъти. До колкото размера на IP-пакета, съдържащ лъжливия отговор е около 100 байта, то пред атакуващия стои задачата за изпращането на няколко мегабайта информация за няколко секунди, което в болшинството случаи е неосъществимо
• Метод за определяне номера на порта и текуция идентификатор на запитването
При изпълнение на допълнителните условия даже в случаите на междусегментна атака атакуващия има възможност да определи текущия id на запитването и номера на порта. Контролът над сървъра в дадения контекс означава възмогността да се прехванат всички запитвания адресирани до и от него. Това е възможно ако атакуващият непосредствено овладее сървъра (явява се негов администратор) или разделя с него общата физическа среда на предаване (в случай на Ethernet). Очевидно, че даденото условие не е трудно изпълнимо до колкото намиращите се в един колизионен домейн с DNS-сървъра е типично за корпоративните мрежи. При наличие на контролирания сървър описаната ак.така може да бъде модифицирана по следния начин. Да предположим, че атакуващия контролира сървъра ns.hacker.com, отговарящ за домейна hacker.com. в първата фаза на атаката ние провокираме сървъра ns.victim.com за обръщение към ns.hacker.com по пъта на изпращането на рекурсивно запитване за търсене на каквото и да е име (не е задължително да е съществуващо) в домейна hacker.com. До колкото ns.hacker.com се намира под контрола на атакуващия той може да прехване това запитване и да извлече от него информация за номера на порта и текущия id. Следващите две фази на атаката не се различават от описаните с тази разлика, че атакуващия е достатъчно да изпрати само няколко ръжливи отговора тъй като той точно знае номера на порта и може с висока степен на точност да предскаже значението на идентификатора на запитването към ns.coolsite.com• Метод на косвена провокация
Очевидно е, че необходими условия за успешното провеждане на атаки се явява възможността за изпращане на рекурсивни запитвания към целевия сървър, провокиращи го към обръщение към други сървъри с цел търсене на исканата информация. По принцип съществува възможност DNS-сървърът да се настрои по такъв начин, че да приема рекурсивни само от "свои" клиенти (хостове, ресолвери). В този случай осъществяването на атаката е невъзможно. С цел да се заобиколи това ограничение може да се предложи прост метод, който условно ще наречем "косвена провокация". Основната идея на този метод се заключава в използването на която и да е общодостъпна услуга, явяваща се клиент на целевия DNS-сървър, за формиране на необходимото провокиращо запитване. Най-подходящ кандидат представлява общодостъптия сървър за електронна поща, който по определение е длъжен да приема връзки с всички компютри от Интернет. Да предположим, че ресолвера на компютъра mail.victim.com е настроен за използване на сървъра ns.victim.com, като последния приема рекурсивните запитвания само от домейна ns.victim.com. примерът по-долу за SMTP-диалог провокира ns.victim.com за търсене на информация за име any-name.any-domain.com: $ telnet mail.victim.com 25 Trying... Connected to mail.victim.com. Escape character is '^]'. 220 mail.victim.com ESMTP Send mail 8.8.0/8.8.0; Wed, 5 May 2001 21:30:42 hello I.am.cracker 250 mail.victim.com Hello crack.hacker.com [1.1.1.1], pleased to meet you mail from: user@any-name.any-domain.com 250 user@any-name.any-domain.com... Sender ok quit 221 mail.victim.com closing connection Connection closed. По такъв начин използвания метод на "косвена провокация", позволява осъществяването на атака без пряко изпращане на запитване към целевия DNS-сървър.
• Как възниква епидемия
При нормални условия успешната атака довежда до "заразяването" на кеша на конкретния сървър и областта на разпространение на лъжливата информация се ограничава само до неговите клиенти. При наличие на ситуация на "неконкретно делигиране" (lame delegation), възникваща заради грешки при администрирането е възможно разпространение на лъжлива информация на други сървъри, което може да доведе до глобално заразяване. Под некоректно делигиране се резбира ситуация при която ответствеността за домейна се делегира на сървър, който не притежава локално копие с информацията за домейна. Това довежда до това, че в отговор на интерактивните запитвания на другите сървъри вместо исканата от тях информация, той им връща техните запитвания. Да разгледаме ситуация при която за домейна victim.com съществува два отговарящи сървъра - ns.victim.com и ns2.victim.com, но за ns2.victim.com делегирането не е извършено коректно. Използвайки описания метод отокуващия може да "зарази" кеша на сървъра ns2.victim.com с лъжлива информация за имената в домейна victim.com, например, да подмени IP-адреса на web-сървъра http://www.victim.com с IP-адреса http://www.very-bad-site.com. До колкото ns2.victim.com се счита за отговорен за домейн на victim.com другите сървъри в Интернет ще се обръщат към него за информация и имена в този домейн. Не разполагайки с локални копия на информацията за домейна за victim.com, даденият сървър ще връща в отговор по-рано кешираната лъжлива информация, довеждайки до "заразяване" на всички обръщащи се към него сървъри. Неприятна особеност на дадения сценарий е невъзможността за бърза ликвидация на последствията от атаката, до колкото лъжливата информация се намира в кеша на хиледи сървъри до изтичане на определеното време, което атакауващия може да избере да е доста голямо
• Реализация и полеви изпитания
Програмата за реализация на атака на DNS-сървър с използване на контролирания сървър, стана достъпна в Интернет вероятно от февруари 1999г. За щастие използването на такива програми не ви извеждат директно IP-адреса на целевия сървър и няма директен клавиш "Infect It!", а изисква достатъчно задълбочени познаня за принципите на работа на DNS. С цел да се обезпечи чистотата на експеримента (полевите изпитания) са били взети три неконтролирани от атакуващия корпоративни мрежи. Естествено администраторите им са били наясно и не са се възпрогивили против експеримента. За съжаление нито една от тях не е устояла на атаката. Диапазона на целите, които могат да бъдат достигнати с помощта на DNS-атака се простират от "отказ за обслужване" и подмяна на web-сайтове до прехващане на съобщенията на илектронната поща и пълен контрол над информацията предавана между произволно избрани хостове в net'а. При всичко това атакуващия практически не оставал следи, до колкото на него не му било необходима да изпраща провокиращи запитвания и лъжливи отговори от собствения си IP-адрес.
• Поглед от другата страна на барикадата
По мнението на автора в днешно време единствените надеждни средства за противодействие срещу описаната атака се явяват използваните стандартизирани в RFC2065 разширения на протокола DNS, разгреждащи използването на криптографски метод за идентификация на информацията за домейна и с обектите за мрежови взаимодействия. Базовата подддръжка на този стандарт е включена във версията BIND8. За съжаление желан резуртат може да се постигне само при широкомащабното внедряване на новите протоколи, което е съпроводено със зночителни организационни трудности и не би могло да стане в близко време. За да затрудните все пак осъществяването на атака може да забраните обслужването на DNS-сървъра към рекурсивни запитвания, постъпващи от "чужди" клиенти. Това може да бъде направено както чрез средствата на собствения сървър (например, BIND8 има такива възможности), така и със средства за междумрежово екраниране. Трябва да обърнете внимание на настройката за "антиспуфинг" на firewall'а си. При използване на дадения метод не трябва да се забравя, че подобна защита може да бъде достатъчно лесно преодоляна чрез използването на описания метод за косвена провокация.
Заключение
Тази атака се различава от останалите, които търсят "следи", backdoors и различни грешки на администраторите, и използването на "социалната инженерия" по своята изящност. В същото време по своя характер и мащабност на резултатите дадената атака напълно може да бъде наречена информационно оръжие за масово поръжение!!!
)) Липсата на адекватни средства на защита много слабо изразените "дири" и трудностите при отстраняване на последствията от атаката още повече влошават ситуацията. Удивителен е фактът, че не се използва широко от взломаджии. Може би това се обяснява с недостатъчната им квалификация На мрежоните администратори им остава само да се надяват, че уязвимостите на DNS-протокола ще бъдат отстранени преди те самите да я почуства върху гърба си