Akamai раскрыла опасную дыру в Windows Server 2025 до выхода патча

Akamai раскрыла опасную дыру в Windows Server 2025 до выхода патча

Akamai раскрыла опасную дыру в Windows Server 2025 до выхода патча

Специалисты Akamai устроили шум в сообществе ИБ: они опубликовали полное техническое описание и PoC-эксплойт для уязвимости под кодовым названием BadSuccessor. Брешь способна привести к повышению привилегий в Windows Server 2025.

Суть в том, что с её помощью злоумышленник может получить полный контроль над любым пользователем в Active Directory, даже не будучи админом.

Исследователь Akamai Юваль Гордон сообщил, что Microsoft подтвердила баг, но присвоила ему «умеренную» степень опасности и отложила выпуск патча на неопределённое время. Akamai с этим категорически не согласна. По мнению Гордона, уязвимость серьёзнее, чем кажется.

BadSuccessor связана с новым типом аккаунтов в Server 2025 — delegated Managed Service Accounts (dMSA). Они должны были заменить устаревшие сервисные учётки, но получилось не очень: новая учётка может «наследовать» полномочия старой, и контроллер домена это спокойно принимает за чистую монету.

Гордон показал, как обычный пользователь с правами Create-Child в нужной OU может создать dMSA, который фактически будет обладать привилегиями другого пользователя. Без изменения групп, без записи в чувствительные объекты — просто два изменения атрибутов, и готово.

Почему это важно?

По данным Akamai, в 91% проверенных сред хотя бы один «неадмин» уже имеет права Create-Child в каком-нибудь OU — а этого вполне достаточно для атаки. При этом Windows Server 2025 по умолчанию включает поддержку dMSA, так что риски появляются сразу, как только вы добавляете новый контроллер в домен.

Akamai предупредила Microsoft о баге ещё 1 апреля. Ответ был: «да, уязвимость есть, но серьёзной мы её не считаем, спешить с патчем не будем». Это и стало последней каплей: в блоге компании появился полный разбор, примеры кода, рекомендации по логированию и скрипты для поиска уязвимых объектов.

Реакция сообщества — спорная

Публикация до выхода патча снова разожгла споры о правилах ответственного раскрытия. Одни исследователи критикуют Akamai за то, что они «слили» всё публично. Другие считают, что Microsoft слишком часто затягивает с устранением действительно опасных уязвимостей и по-другому с ней не получается.

Akamai в свою очередь говорит: BadSuccessor открывает совершенно новый, ранее неизвестный путь к компрометации AD-домена, и это нельзя игнорировать.

Подпишитесь на новости

Новая атака на кеш Nginx позволяет красть данные и ломать сайты

Исследователь YesWeHack Алекс Брумен описал вектор кибератаки Cache Key Injection. В случае её эксплуатации последствия для потенциальной жертвы опасные: обход контроля доступа, раскрытие закрытых страниц, отказ в обслуживании и при определённых условиях.

Как объясняет исследователь YesWeHack, проблема возникает не в Nginx по умолчанию, а в конфигурациях, где администраторы просто склеивают несколько значений переменной длины без разделителей. Например:

$scheme$host$request_uri$http_accept

Разных запроса два, а итоговая строка может получиться одна. Так, запрос к /h с заголовком Accept: ome*/* создаёт тот же ключ, что и обычное обращение к /home с Accept: */*.

Если атакующий успеет первым положить в кеш ответ 404, пользователи вместо главной страницы будут получать ошибку до очистки записи. Получается CPDoS — отказ в обслуживании с доставкой прямо из кеша.

 

Ещё веселее становится с закрытыми разделами. В лабораторном примере страница /admin была доступна только с localhost, но злоумышленник мог обратиться к /ad и перенести оставшуюся часть имени в соседний компонент ключа. Nginx видел разрешённый путь, однако доставал из кеша содержимое админ-панели.

При совпадении нескольких условий техника позволяет столкнуть HTTP- и HTTPS-запросы и записать в кеш страницу со ссылкой на атакующий JavaScript, превратив ошибку конфигурации в stored XSS. Даже Cloudflare не всегда спасёт: заголовок Authorization может провести запрос мимо его кеша прямо к уязвимому кешу Nginx.

 

Защита выглядит до смешного просто: не склеивать значения вслепую. Между элементами ключа нужны разделители или структурное кодирование, например:

$scheme|$host|$request_uri|$http_accept

Также следует проверять Host, перенаправлять HTTP на HTTPS и не кешировать аутентифицированные запросы.

RSS: Новости на портале Anti-Malware.ru