SIGRed: уязвимост в Windows Server се спотайва 17 години?

SIGRed (CVE-2020-1350). Толкова ли е опасна колкото си мислим и какви са щетите, които може да нанесе?

И преди сме чували за уязвимости с подобен “wormable” характер. Благодарение на тях може да се разпространява зловреден код, без да се изискват никакви действия от потребителя. Именно това е причината рискът от тях да е огромен. Примери за подобно поведение са EternalBlue, използвана за атаката от криптовируса WannaCry и BlueKeep в протокола за отдалечен десктоп (RDP) на Windows.

Но SIGRed е малко по-различна. На 16 юли 2020 г. Агенцията за кибер- и инфраструктурна сигурност на САЩ (CISA) обяви извънредна директива, в която се определя уязвимостта CVE-2020-1350 за сериозен риск за всички Windows сървъри. А от държавната администрация на страната бе изискано в рамките на 24 часа да елиминират проблема и да пачнат своите системи.

Какво точно представлява тази уязвимост SIGRed?

SIGRed или CVE-2020-1350 е уязвимост в Windows сървъри, които имат стартирана DNS сървър услуга.

Открита е от Check Point и е оценена с перфектните 10 CVSS точки. Причината за тази оценка: разпространява се на принципа на червеите и трудно може да бъде овладяна, ако не се вземат мерки навреме. На практика, тя би могла да позволи на атакуващите да добият администраторски права и да внедрят зловреден код.

Добрата новина за повечето потребители, е че уязвимостта засяга само Windows Server, тъй като пропускът се намира в Windows DNS сървър кода, а не в клиентския. Лошата новина е, че засяга всички Windows сървърни дистрибуции, произведени от Microsoft в последните 17 години. Така, ако мрежата, към която е свързан потребителят, разчита на Windows DNS сървър, то крайният потребител е изложен на риск само защото е част от тази мрежа.

За да разберем какво прави SIGRed, трябва да имаме поне основна представа за DNS. Най-просто казано DNS е телефонния указател на Интернет – глобална база данни с информация за имената на домейни и IP адреси.  Ако потребител иска да достъпи www.freedomonline.bg, DNS се грижи да предостави съответстващия IP адрес. По-подробно обяснение как работи DNS услугата вижте тук, но засега е достатъчно да знаем, че:

• DNS използва TCP/UDP на порт 53
• Размера на едно DNS съобщение (заявка или отговор) може да бъде максимално 512 байта (по UDP) или 65,535 байта (по TCP).
• DNS е йерархичен. Това означава, че когато сървърът не знае отговора на заявка, която получава, заявката се препраща към DNS сървър над него в йерархията.

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

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

Как точно работи?

Ще се опитаме да обясним принципа на работа на SIGRed на достъпен език, но по-подробни технически детайли може да бъдат прочетени в проучването на Check Point.

Формата, в който тече DNS трафика (RFC 1035), датира още от 80-те години на миналия век, когато не е имало толкова ресурси, колкото днес. Затова се е целяло служебните съобщения да бъдат в максимално компресиран формат с минимален размер. Идеята при DNS се базирала на предположението, че всички заявки и отговори биха се побрали в 512 байта (без 12 байта за служебна информация).

Ако се налагало обмен на по-дълги съобщения, те били предавани по такъв начин, че първите два байта да обозначат дължината на очакваните данни, последвани от самите данни. Най-голямото число, което може да се запише в 2 байта (16 бита) е 2¹⁶ -1, което е 0xFFFF в 16-тична бройна система или 65 535 в 10-тична. Именно това е максималният размер за DNS отговор. Това е едното важно нещо, което трябва да имаме предвид за по-нататък.

Вторият съществен момент са различните видове DNS отговори, още наричани RR (Resource Records), които се записват като TYPE с помощта на 16 битови числа. Пример за RR е “A record” – този запис съхранява IPv4 адреса със съответстващия му домейн. Друг вид запис отговаря за SIG заявката. Както вече споменахме DNS е проектиран преди доста години, когато сигурността на данните в Интернет не е била с такъв приоритет, за разлика от днес.

Чак след години е създаден DNSSEC –  е разширение на стандартния протокол, специално предназначено за защита на DNS трафика. Идеята на DNSSEC е да гарантира легитимността на DNS съобщенията. Повече за принципа на DNSSEC тук.

Тази допълнителна защита става посредством SIG заявки – записът в нея доказва, че DNS отговорите не са подменени и идват от доверен източник. По-късно RFC 3755 налага използването на RRSIG вместо SIG. RRSIG записите имат сходен формат с тези на SIG, но следват различни правила за форматиране на данните в тях. И както става обикновено след замяната на нещо старо с ново – оригиналният код, който отговарял за SIG заявките продължава да съществува някъде там, неизползван и податлив на уязвимости.

Уязвимостта съществува поради начина, по който Windows DNS сървърът анализира входящите заявки, както и как се обработват препратени заявки. По-конкретно, изпращането на DNS отговор със SIG запис над 64KB може да доведе до контролиран heap-based buffer overflow. По този начин може да се “срине” сървъра или в най-лошия случай да се изпълни отдaлечено злонамерен код (RCE).

Как по точно става това?

Първо трябва да знаем, че:

• Най-голямото количество данни, което е възможно да се появи в отговор на DNS, е 65 535 байта.
• Следователно максималният обем памет, която ще е необходима за съхраняването на тези данни при прочитането им, е 65 535 байта.
• Това означава че unsigned short int (16 -битово число) е с достатъчно голяма дължина да изчисли дадената заявка

За съжаление, SIG записите включват поле NAME, което може да бъде предадено в компресирана форма, като се използва алгоритъмът на рудиментарното компресиране на DNS. Тоест NAME низ, който може да е до 255 байта на големина, след компресирането може да заеме само два байта в DNS отговора.

SIG записите включват и поле данни за цифровия подпис, което може да бъде с произволна дължина, така че е лесно да се конструира отговор, в който общото количество данни да е точно на границата от 65 535 байта. Кодът използва 16-битова целочислена стойност, когато изчислява колко памет ще му е необходима след декомпресията.

В такъв случай имаме 65 535 байта сурови данни от отговора плюс (да речем) още 40 байта, които са допълнително внедрени от хакера използвайки хитро изработено компресирано поле NAME. Програмата ще изчисли 65 535 + 40, но понеже това ще прескочи лимита на integer типа и ще изчисли и задели само 39 байта памет за SIG записа, след това ще опита да прехвърли 65,535 + 40 байта в буфера на паметта, като по този начин ще  доведе до heap-based buffer overflow.

Как да оправим този проблем?

Като се има предвид, че Microsoft нарича това „wormable vulnerability“, е препоръчително администраторите да  приложат съответните пачове в максимално кратък период.

В случай, че ъпдейт не е възможен от Microsoft са предоставили workaround с промяна на регистър.

По материала работиха: Кристиян Цанков и Стелиана Козарева