Уязвимостта BIND може да срине всеки сървър: как и защо работи

Замислихме се да създадем правила (NAD) за откриване на експлоатация на тези уязвимости по мрежата - за да направим това, трябваше да се задълбочим в BIND кода и да напишем собствените си експлойти. Нашият анализ ще ви помогне да разберете как работи всичко в такъв популярен DNS сървър, както и да разберете за грешките, направени от разработчиците на проекта, и възможните решения на тези проблеми.

Какъв е проблемът

Рекурсивните сървъри с поддръжка на DNSSEC са изложени на най-голям риск, така че по-нататък ще се съсредоточим върху случая на рекурсивна заявка.

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

За по-нататъшно разбиране на проблема е необходимо да се проучи публично достъпната корекция за тази CVE. Пачът поправя само няколко реда код в един от модулите, отговорни за обработката на DNS отговорите.

Както виждаме, пластирът поправя логическа грешка в състоянието

Изпълнението и на трите израза стана задължително за промяна на променливата have_answer на true. Това е необходимо, за да се определи дали пакетът съдържа отговор на нашето искане:

По този начин става очевидно, че експлоатацията на уязвимостта става чрез непълно изпълнение на условието от кръпката. Нека се опитаме да разберем каква комбинация от записи в пакета е необходима за работа.

Писане на подвизи

Можете да стигнете до клона с уязвимия код чрез следното кратко състояние

Намерената променлива е зададена в пет блока код от една и съща функция, които обработват различни варианти на отговори, като пренасочване на имена със записи CNAME или DNAME, отговор на ВСЯКА заявка и т.н.:

Нека запомним един малък намек в описанието на кръпката:

„Името е обработило неправилно някои отговори, при които се връщат обхващащи RRSIG записи, без исканите данни да доведат до неуспешно твърдение. (CVE-2016-9147) "

Което казва, че един от записите трябва да бъде RRSIG запис. RRSIG е един от DNSSEC механизмите, който осигурява целостта на DNS данните в отговора. За записи от всякакъв тип (A, AAAA, NS, DNAME, CNAME и др.) Отговорът изпраща съответния RRSIG запис, който съдържа цифров подпис. За да се разбере кой тип RRSIG съдържа подпис, в RRSIG има поле с тип покритие .

Само 2 от 5 състояния са свързани с RRSIG откриване в DNS отговор:

Тази проверка се задейства, ако намерим RRSIG с подпис за записа, който търсим (за който изпратихме заявката).

И това условие е подобно на първото, само записът RRSIG трябва да покрива типа CNAME.

Достигнахме много близо до заключението, че за използване на тази грешка е необходим един запис на RRSIG в ANSWER_SECTION. Всъщност тази ситуация не трябва да се случва при редовен DNS трафик, тъй като RRSIG не може да бъде прекратена връзка с друг запис.

Опитваме се да възпроизведем топологията с рекурсивен DNS сървър и да изпратим отговор от един RRSIG запис на рекурсивната заявка, която обхваща или CNAME, или типа от DNS заявката.

Както се очаква, виждаме прекъсването на Named демона:

Какъв е резултатът

Разглежданата уязвимост е доста проста и опасна, тъй като нейната експлоатация не изисква трудни условия. Разработчиците на BIND непрекъснато поправят сериозни уязвимости на DNS сървъра, които могат да нарушат работата му.

Експертите от Positive Technologies внимателно проучиха всички уязвимости, фиксирани от разработчиците, възпроизведоха ги в реални условия и разработиха IDS подписи за откриване на експлоатация.

- Откриване на атака (@AttackDetection) 7 февруари 2017 г.

Автор: Кирил Шипулин, специалист, Изследователска група за откриване на атаки
Положителни технологии