Обнаружена уязвимость в WDS: PXE-сервер можно вывести из строя удалённо

Обнаружена уязвимость в WDS: PXE-сервер можно вывести из строя удалённо

Обнаружена уязвимость в WDS: PXE-сервер можно вывести из строя удалённо

Если вы всё ещё используете Windows Deployment Services (WDS) для раздачи образов Windows по сети, пора всерьёз задуматься. Специалист обнаружил серьёзную уязвимость, которая позволяет удалённо и без аутентификации вывести из строя сервер буквально за несколько минут.

Да-да, без логинов, паролей и вообще какого-либо взаимодействия с пользователем — просто взял и положил.

WDS использует старый добрый протокол TFTP по UDP (порт 69) для раздачи установочных образов Windows. При подключении клиента сервер создаёт объект CTftpSession.

Проблема в том, что никакого лимита на число сессий не предусмотрено. В результате злоумышленник может подделывать IP-адреса и порты, рассылать фальшивые UDP-пакеты — и сервер начинает захлёбываться в собственных объектах.

«Ключевая проблема в том, что EndpointSessionMapEntry не накладывает ограничений на число сессий», — говорится в техническом отчёте. — «Атакующий может подделывать IP-адреса и номера портов, многократно создавая новые сессии, пока ресурсы системы не будут исчерпаны».

На тестовом сервере с Windows Server Insider Preview и 8 ГБ оперативной памяти исследователю Чжиниану Пэну удалось полностью обрушить систему за 7 минут — исключительно с помощью случайных UDP-пакетов с поддельными исходными адресами.

Это классическая zero-click DoS-атака — никаких действий со стороны пользователя не требуется. Просто поток UDP-трафика, и PXE-инфраструктура, через которую разворачиваются Windows-образы, оказывается парализованной.

Что ответил Microsoft? Пэн сообщил об уязвимости в Microsoft 8 февраля 2025 года. 4 марта компания подтвердила наличие бага, а 23 апреля… отказалась его исправлять. По официальной позиции Microsoft, проблема «не соответствует критериям для выпуска патча».

Пэн не скрывает разочарования:

«Мы считаем, что это важная уязвимость, которая подпадает под стандарт SDL, и нам было очень неприятно общаться с Microsoft по этому поводу», — написал он.

Тем не менее Microsoft патч выпускать не планирует, поэтому Пэн даёт однозначную рекомендацию:

«Чтобы защитить PXE-сеть от этой угрозы, не используйте Windows Deployment Services».

Альтернативы — сторонние PXE-решения на базе Linux, кастомные сборки или переход к другим способам развёртывания.

Почему не стоит входить с помощью Google в важные аккаунты

Кнопка «Войти с аккаунтом Google» долго казалась удобным решением, ибо не нужно придумывать новый пароль, заполнять профиль и помнить ещё одни учётные данные. Но у такого удобства есть обратная сторона. Главный риск — зависимость от одного аккаунта.

Если пользователь потеряет доступ к Google из-за взлома, блокировки, фишинга или другой проблемы, под ударом окажутся не только Gmail и Диск, но и все сторонние сервисы, куда он входил через Google.

Это может быть что угодно: рабочие инструменты, доставка еды, такси, умный дом, сервисы ИИ, приложения для путешествий или финансов.

Есть и вопрос безопасности. Современные фишинговые атаки умеют подделывать страницу входа Google и перехватывать не только пароль, но и сессионные токены.

В таком случае злоумышленник может получить доступ к аккаунту даже при включённой двухфакторной аутентификации. Чем чаще пользователь входит в разные сервисы через всплывающие окна Google, тем выше риск попасть на такую подделку.

Ещё один минус — недостаток конфиденциальности. Когда разные сервисы привязаны к одному Google-аккаунту, компания получает более цельную картину цифровой активности пользователя: какие приложения он использует, как часто и в каких сценариях. Даже если данные обрабатываются в агрегированном виде, это всё равно расширяет цифровой след.

Более безопасная альтернатива — создавать отдельные учётные записи для важных сервисов и хранить пароли в менеджере паролей. Это менее удобно на старте, зато снижает риск единой точки отказа. Если один аккаунт будет скомпрометирован или заблокирован, остальные не посыплются вслед за ним.

Для незначительных сайтов вход через Google может оставаться быстрым вариантом. Но для банков, рабочих сервисов, почты, облаков, ИИ-инструментов, умного дома и других важных аккаунтов лучше использовать отдельный логин, сложный пароль и двухфакторную аутентификацию.

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