Перейти к содержанию

Zerologon: уязвимость в протоколе Netlogon позволяет захватить контроллер домена


Рекомендуемые сообщения

В августовский «вторник обновлений» компания Microsoft закрыла несколько уязвимостей, среди которых была и CVE-2020-1472. В принципе, никто и не сомневался, что дыра в протоколе Netlogon со степенью серьезности «критическая» (по шкале CVSS она получила рейтинг 10 из 10) будет достаточно опасной. Но на днях исследователь Том Тервурт (Tom Tervoort) из компании Secura (человек, обнаруживший эту уязвимость) опубликовал подробное исследование и объяснил, почему эта уязвимость, названная Zerologon, столь опасна и как злоумышленники могут воспользоваться ей, чтобы захватить контроллер домена.

В чем суть уязвимости Zerologon?

По большому счету, уязвимость CVE-2020-1472 заключается в несовершенстве схемы криптографической аутентификации Netlogon Remote Protocol. Этот протокол используется для аутентификации пользователей и машин в сетях, построенных на базе домена. В частности, Netlogon служит и для удаленного обновления паролей компьютеров. Уязвимость позволяет злоумышленнику выдать себя за компьютер-клиент и заменить пароль контроллера домена (сервера, контролирующего всю сеть, в том числе запускающего службы Active Directory). В результате атакующий может получить права администратора домена.

Кто уязвим?

Уязвимость CVE-2020-1472 актуальна для компаний, сети которых построены на базе контроллеров доменов под управлением операционных систем Windows.

В частности, злоумышленники могут захватить контроллер домена на базе:

  • всех версий Windows Server 2019, Windows Server 2016;
  • всех вариантов Windows Server версии 1909;
  • Windows Server версии 1903;
  • Windows Server версии 1809 (Datacenter, Standard);
  • Windows Server 2012 R2;
  • Windows Server 2012;
  • Windows Server 2008 R2 Service Pack 1.

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

К счастью, пока нет информации о том, что уязвимость Zerologon когда-либо использовали в реальных атаках. Однако после публикации исследования в блоге компании Secura вокруг этой проблемы поднялся ажиотаж, который, скорее всего, привлек и внимание злоумышленников. Несмотря на то что исследователи не опубликовали работающий proof of concept, они не сомневаются, что злоумышленники смогут его создать, основываясь на патчах.

Как защититься от атак с использованием Zerologon?

Компания Microsoft выпустила патчи, закрывающие эту уязвимость для всех затронутых систем. Они доступны с начала августа этого года, так что если вы еще не обновились, то лучше поспешить. Кроме того, компания рекомендует отслеживать все попытки логина по уязвимой версии протокола и выявлять устройства, которые не поддерживают новую версию. В идеале эксперты Microsoft считают необходимым перевести контроллер домена в режим, в котором все устройства должны использовать безопасный вариант протокола Netlogon.

Обновления не делают этого в принудительном порядке, потому что Netlogon Remote Protocol используется не только в Windows, — есть множество устройств на базе других ОС, которые также полагаются на этот протокол. И далеко не все из них поддерживают его защищенный вариант. Если сделать использование безопасной версии обязательным, эти устройства не смогут корректно работать.

Тем не менее 9 февраля 2021 года контроллеры доменов переведут в этот режим в обязательном порядке, так что администраторам придется как-то решать проблему со сторонними устройствами до этой даты — обновлять или вручную прописывать в исключение. Подробнее о том, что делает августовский патч и что изменится после февральского, можно найти в материале Microsoft наряду с подробными гайдлайнами.

View the full article

Ссылка на комментарий
Поделиться на другие сайты

Пожалуйста, войдите, чтобы комментировать

Вы сможете оставить комментарий после входа в



Войти
  • Похожий контент

    • KL FC Bot
      Автор KL FC Bot
      Умный дом сегодня — это не фантастика из фильмов конца девяностых, а реальность практически каждого жителя мегаполиса. Умные розетки, колонки и телевизоры можно встретить практически в любой современной квартире. А что касается новых домов, то их иногда и вовсе сразу же строят умными, получаются умные жилые комплексы. Их жители могут с единого приложения управлять не только внутриквартирными приборами, но и внешними: домофоном, камерами, шлагбаумами, счетчиками и датчиками пожарной сигнализации.
      Но что будет, если в таком приложении окажется дыра в безопасности? Ответ знают наши эксперты из Global Research and Analysis Team (GReAT). Мы обнаружили уязвимость в приложении Rubetek Home и рассказали, что могло бы случиться с безопасностью владельцев умных квартир и домов — но, к счастью, не случилось.
      Что за уязвимость
      Уязвимость заключалась в отправке чувствительных данных в процессе логирования работы приложения. Разработчики использовали Telegram Bot API для сбора аналитики и отправки файлов с отладочной информацией от пользователей в приватный чат команды разработки при помощи Telegram-бота.
      Проблема в том, что отправляемые файлы, помимо системной информации, содержали в себе персональные данные пользователей, а также, что более критично, Refresh-токены, необходимые для авторизации в аккаунте пользователя, чей токен был получен. У потенциальных атакующих была возможность переслать все эти файлы себе при помощи того же Telegram-бота. Для этого они могли получить его Telegram-токен и идентификатор нужного чата из кода приложения, а после перебрать порядковые номера сообщений, содержащих такие файлы.
       
      View the full article
    • KL FC Bot
      Автор KL FC Bot
      Исследователи обнаружили три уязвимости в популярной платформе для контент-менеджмента Sitecore Experience Platform:
      CVE-2025-34509 заключается в наличии жестко заданного в коде пароля (причем состоящего из одной буквы), позволяющего атакующему удаленно аутентифицироваться в служебной учетной записи; CVE-2025-34510 — уязвимость типа Zip Slip, позволяющая аутентифицированному пользователю загрузить ZIP-архив и распаковать его в корневую папку сайта; CVE-2025-34511 также позволяет загрузить на сайт посторонний файл, но на этот раз вообще произвольный. Используя первую уязвимость совместно с любой из остальных двух, атакующий может удаленно добиться выполнения произвольного кода (RCE) на сервере под управлением Sitecore Experience Platform.
      На данный момент нет свидетельств об использовании этих уязвимостей в реальных атаках, однако опубликованный экспертами из watchTowr Labs анализ содержит достаточно подробностей для создания эксплойта, так что злоумышленники могут взять их на вооружение в любой момент.
       
      View the full article
    • rcbsbss
      Автор rcbsbss
      Сегодня были зашифрованы сервера и компьютеры входящие в домен. В результате при включении компьютера появляется сообщение "Обратитесь в телеграмм...". Пользователь телеграмм @dchelp. Был установлен антивирус Касперского с новыми базами, он пропустил. Сервер Касперского также был заражен. Просим помочь!!!
    • KL FC Bot
      Автор KL FC Bot
      В мартовском вторничном патче компания Microsoft закрыла целых шесть уязвимостей, которые активно эксплуатируются злоумышленниками. Четыре из этих уязвимостей связаны с файловыми системами, причем три из них имеют одинаковый триггер, что может указывать на их использование в одной атаке. Детали их эксплуатации пока (к счастью) неизвестны, однако свежее обновление крайне рекомендуется к немедленной установке.
      Уязвимости в файловых системах
      Две из уязвимостей в системе NTFS позволяют злоумышленникам получить доступ к частям кучи (heap), то есть к динамически распределяемой памяти приложений. Что интересно, первая из них, CVE-2025-24984 (4,6 по шкале CVSS) подразумевает физический доступ злоумышленника к атакуемому компьютеру (он должен вставить в USB-порт подготовленный вредоносный накопитель). Для эксплуатации второй уязвимости типа Information Disclosure Vulnerability, CVE-2025-24991 (CVSS 5,5), злоумышленникам необходимо каким-то образом заставить локального пользователя подключить вредоносный виртуальный жесткий диск (VHD).
      Точно также активизируются и две другие уязвимости, связанные с файловыми системами CVE-2025-24985, в драйвере файловой системы Fast FAT и CVE-2025-24993 в NTFS. Вот только их эксплуатация приводит к удаленному запуску произвольного кода на атакуемой машине (RCE). У обеих уязвимостей CVSS рейтинг составляет 7,8.
       
      View the full article
    • KL FC Bot
      Автор KL FC Bot
      Чуть больше года назад в посте Google OAuth и фантомные аккаунты мы уже обсуждали, что использование опции «Вход с аккаунтом Google» в корпоративные сервисы дает возможность сотрудникам создавать фантомные Google-аккаунты, которые не контролируются администратором корпоративного Google Workspace и продолжают работать после оффбординга. Недавно выяснилось, что это не единственная проблема, связанная с OAuth. Из-за недостатков этого механизма аутентификации любой желающий может получить доступ к данным многих прекративших деятельность организаций, перерегистрировав на себя брошенные компаниями домены. Рассказываем подробнее об этой атаке.
      Как работает аутентификация при использовании «Вход с аккаунтом Google»
      Некоторые могут подумать, что, доверяя опции «Вход с аккаунтом Google», компания получает надежный механизм аутентификации, использующий продвинутые технологии Google и широкие возможности интернет-гиганта по мониторингу пользователей. Однако на деле это не так: при входе с Google OAuth применяется достаточно примитивная проверка. Сводится она, как правило, к тому, что у пользователя есть доступ к почтовому адресу, который привязан к Google Workspace организации.
      Причем, как мы уже говорили в предыдущем материале о Google OAuth, это вовсе не обязательно Gmail — ведь привязать Google-аккаунт можно совершенно к любой почте. Получается, что при использовании «Входа с аккаунтом Google» доступ к тому или иному корпоративному сервису защищен ровно настолько надежно, насколько защищен почтовый адрес, к которому привязан Google-аккаунт.
      Если говорить несколько более подробно, то при аутентификации пользователя в корпоративном сервисе Google OAuth отправляет этому сервису следующую информацию:
      В теории в ID-токене Google OAuth есть уникальный для каждого Google-аккаунта параметр sub, но на практике из-за проблем с его использованием сервисы проверяют лишь домен и адрес электронной почты. Источник
       
      View the full article
×
×
  • Создать...