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

CVE-2020-1350: уязвимость в DNS-серверах под Windows


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

Компания Microsoft сообщила об уязвимости CVE-2020-1350 в DNS-сервере Windows. Что плохо: уязвимость получила оценку в 10 баллов по шкале CVSS, то есть рейтинг «критическая». Что хорошо: злоумышленники могут использовать эту уязвимость, только если система работает в режиме DNS-сервера, то есть число потенциально подверженных машин невелико. К тому же компания уже выпустила заплатки и опубликовала обходное решение.

Что это за уязвимость и чем она опасна?

Уязвимость CVE-2020-1350 позволяет заставить DNS-серверы, работающие под управлением Windows Server, удаленно выполнить вредоносный код. Иными словами, она относится к классу RCE. Для того чтобы проэксплуатировать уязвимость, злоумышленникам достаточно послать DNS-серверу специальным образом сгенерированный запрос.

Посторонний код будет исполняться в контексте учетной записи Local System Account. Эта запись имеет обширные привилегии на локальном компьютере, а в сети действует как компьютер. К тому же Local System Account не распознается подсистемой обеспечения безопасности. По словам Microsoft, основная опасность уязвимости заключается в том, что она может быть использована для распространения угрозы по локальной сети, то есть классифицируется как Wormable.

Кто в зоне риска из-за CVE-2020-1350?

Уязвимы все версии Windows Server, но только если они работают в режиме DNS-сервера. Если в вашей компании нет DNS-сервера или же используется DNS-сервер на базе другой операционной системы, то вам волноваться не о чем.

К счастью, уязвимость была обнаружена исследователями из Check Point Research, и подробной информации о том, как ее можно эксплуатировать, в открытом доступе пока нет. Кроме того, на данный момент нет и никаких свидетельств того, что CVE-2020-1350 когда-либо эксплуатировали злоумышленники.

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

Что делать?

Лучше всего — установить патч, который модифицирует метод обработки запросов DNS-серверами Windows. Заплатка доступна для систем семейств Windows Server 2008, Windows Server 2012, Windows Server 2016, Windows Server 2019, а также Windows Server version 1903, Windows Server version 1909 и Windows Server version 2004. Скачать ее можно на странице с объяснением этой уязвимости.

Однако поскольку в некоторых крупных компаниях существуют внутренние правила и установленный ритм обновления программного обеспечения, некоторые администраторы могут не иметь возможности установить патч немедленно. Чтобы их DNS-серверы не остались под угрозой, компания также предложила обходной путь. Он заключается во внесении следующих правок в системный реестр:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters
DWORD = TcpReceivePacketSize
Value = 0xFF00

После сохранения изменений сервер следует перезапустить. Однако этот обходной путь может потенциально приводить к некорректной работе сервера в тех редких случаях, когда сервер получит TCP-пакет размером более 65280 байт. Так что, когда патч все-таки будет установлен, Microsoft рекомендует удалить переменную TcpReceivePacketSize вместе с ее значением и вернуть запись реестра к исходному состоянию.

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

View the full article

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

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

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



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

    • KL FC Bot
      От KL FC Bot
      Плохие новости для компаний, использующих сайты на базе WordPress с механизмом двухфакторной аутентификации, реализованным через плагин Really Simple Security. Недавно обнаруженная в этом плагине уязвимость CVE-2024-10924 позволяет постороннему человеку аутентифицироваться на сайте под видом легитимного пользователя. Поэтому плагин рекомендуется обновить как можно быстрее.
      Чем опасна уязвимость CVE-2024-10924
      Как бы иронично это ни звучало, но уязвимость CVE-2024-10924 в плагине с названием Really Simple Security имеет CVSS-рейтинг 9.8 и классифицируется как критическая. По сути это ошибка в механизме аутентификации, из-за которой атакующий может залогиниться на сайте как любой из зарегистрированных на нем пользователей, с полными его правами (даже админскими). В результате это может привести к перехвату контроля над сайтом.
      На GitHub уже появились доказательства возможности эксплуатации этой уязвимости. Более того, судя по всему, ее применение можно автоматизировать. Исследователи из Wordfence, обнаружившие CVE-2024-10924, назвали ее самой опасной уязвимостью, обнаруженной ими за 12 лет работы в сфере безопасности WordPress.
       
      View the full article
    • KL FC Bot
      От KL FC Bot
      Среди уязвимостей, на которые компания Microsoft обратила внимание последним вторничным патчем от 12 ноября, была CVE-2024-49040 в Exchange. Ее эксплуатация позволяет атакующему создавать письма, которые в интерфейсе жертвы будут отображаться с вполне легитимным адресом отправителя. Казалось бы, уязвимость была исправлена, но, как выяснилось, уже 14 ноября Microsoft временно приостановила распространение апдейта для Exchange. Тем временем мы уже наблюдали попытки эксплуатации этой уязвимости. Пока случаи единичные, похожие на проверку работоспособности эксплойта. Поэтому мы в отделе развития методов фильтрации контента «Лаборатории Касперского» добавили во все решения для защиты электронной почты механизм, выявляющий попытки использования CVE-2024-49040 для спуфинга.
      В чем проблема уязвимости CVE-2024-49040
      CVE-2024-49040 — это уязвимость с CVSS-рейтингом 7,5 актуальная для Exchange Server 2019 и Exchange Server 2016, классифицируемая как «важная». Суть ее заключается в некорректно сформулированной политике обработки хедера P2 FROM. Благодаря ей злоумышленник может задать это поле таким образом, что в нем, по сути, будет указано два электронных адреса: один реальный, который требуется скрыть от жертвы, а другой — легитимный, который, наоборот, жертве требуется показать. В результате Microsoft Exchange корректно проверит адрес отправителя, но получателю покажет совершенно другой адрес, который не будет вызывать у пользователя никаких подозрений (например, внутренний адрес сотрудника той же компании).
      Патчем от 12 ноября Microsoft добавила новую функцию, которая выявляет хедеры P2 FROM, не соответствующие стандарту интернет-сообщений RFC 5322, что должно было исправить ситуацию. Однако, согласно посту в блоге Microsoft, у некоторых пользователей начались проблемы с правилами потока обработки почты, которые иногда переставали работать после переустановки обновления. Поэтому раздача обновления была приостановлена и будет возобновлена после доработки.
       
      View the full article
    • lex-xel
      От lex-xel
      Добрый день!
      Аналогичная ситуация  сервер подвергся взлому, база данных заархивирована с шифрованием.
      Антивирус снесли, хоть он был под паролем.
      Подскажите есть способ как то исправить ситуацию, расшифровать базу данных?
       
      Do you really want to restore your files?
      Write to email: a38261062@gmail.com
       
      Сообщение от модератора Mark D. Pearlstone перемещено из темы.
         
    • SS78RUS
      От SS78RUS
      Добрый вечер. 
      С нами случилась ситуация 1в1 с вышеописанной. NAS Zyxel 326 со всеми патчами, отключены все выходы во внешнюю сеть, работал только как локальное хранилище, всё равно атаковали через уязвимость самого NAS -создали облачного пользователя, которого даже удалить не могу.
      Подскажите, какой вариант с починкой файлов? Заранее спасибо.
       
      Сообщение от модератора Mark D. Pearlstone Перемещено из темы.
    • LeraB
      От LeraB
      Приветствую.
      Поймали шифровальщика, который работает до сих.
      Ничего не переустанавливали и не трогали, проверяем только доступность компьютеров, их работу и ищем, где он еще может работать. Если понятно, что шифровальщик еще где-то работает, то отключаем этот сервер/компьютер.
      Все, что можно спасти, копируем.
      Пострадала почти вся сеть, не только лок.пк и сервера, но и NAS (именно smb)
      Шифровальщик затронул большинство нужных файлов, но не все.
      Логи собрали с одного сервера, примеры файлов с него же.
      Файл шифровальщика пока найти не удалось, как и выяснить все остальное, кроме того, как оно работает с ночи примерно с 00:00 12.12.2024
      FRST.txt Addition.txt архив.zip
×
×
  • Создать...