Cve 2016 2183 как устранить windows server 2008 r2

Обновлено: 03.02.2023

Обновлено: 07.07.2021. Microsoft выпустила обновление KB5004945 для Windows 10, версия 21H1, 20H2 и 2004 для устранение уязвимости PrintNightmare.

Microsoft недавно расскрыла информацию о новой уязвимости удаленного выполнения кода в Windows, которая использует диспетчер очереди печати Windows. Уязвимость активно эксплуатируется, и поэтому компания опубликовала сразу два предварительных решения для защиты систем от атак, использующих данную уязвимость.

Известно, что уязвимость CVE-2021-34527 (PrintNightmare) затрагивает как серверные операционные системы, такие как Windows Server 2008, 2012, в том числе Windows Server 2016, так и десктопные версии Windows 7 SP1, Windows 8.1, Windows 10 1809 и выше, в том числе Windows 10 21H1.

Компания Acros Security, разработчик 0patch Agent для Windows, проанализировав уязвимость, предположила, что проблема затрагивает преимущественно серверные версии Windows Server. Однако, уязвимость может также затрагивать и десктопные версии Windows 10 и серверные версии Windows Server без DC (контроллер доменов), при условии внесения следующих изменений в конфигурацию по умолчанию:

Описание уязвимости CVE-2021-34527 (PrintNightmare):

Уязвимость удаленного выполнения кода эксплуатируется в случаях, когда служба диспетчера очереди печати Windows неправильно выполняет привилегированные файловые операции. Злоумышленник, успешно воспользовавшийся этой уязвимостью, может запустить произвольный код с правами SYSTEM. После этого злоумышленник может установливать программы; просматривать, изменять или удалять данные; или создавать новые учетные записи с полными правами пользователя.

Атака вовлекает аутентифицированного пользователя, вызывающего RpcAddPrinterDriverEx ().

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

Microsoft предлагает два решения: отключение службы диспетчера очереди печати и отключение входящей удаленной печати с помощью групповой политики. Первое решение отключает локальную и удаленную печать на устройстве. Решение подойдет для случаев, когда функция печати не требуется и не подойдет для случаев, если функция печати используется на устройстве. Вы можете включить диспетчер очереди печати по запросу, но данное решение не удобно.

В качестве второго решения требуется доступ к редактору групповой политики, который доступнен только в версиях Windows Pro и Enterprise.

Два решения для закрытия уязвимости CVE-2021-34527 (PrintNightmare)

Отключение диспетчер очереди печати

Чтобы отключить диспетчер очереди печати, выполните следующие рекомендации:

• Откройте PowerShell с повышенными привилегиями, например, используя сочитание клавиш Win + X и из выпадающего списка выберите Windows PowerShell (Администратор).
• Поочередно запустите следующие команды:

Последние две команда останавливают службу диспетчера очереди печати и отключают её.

Обратите внимание. После внесения изменений вы больше не сможете использовать функцию печати (если снова не включите службу диспетчера очереди печати).

Второе решение – отключение службы входящей удаленной печати с помощью редактора групповой политики

Чтобы отключить входящую удаленную печать, выполните следующие рекомендации:

• Нажмите сочетание клавиш Windows + R , чтобы открыть окно команды «Выполнить».
• Введите gpedit.msc и нажмите ОК.
• В открывшемся Редакторе групповой политики перейдите по следующему пути: Конфигурация компьютера / Административные шаблоны / Принтеры
• Два раза нажмите на политику Разрешить очереди печати принтера прием клиентских подключений.
• Установите для политики значение Отключено.
• Нажмите на кнопку Применить.

0Patch разработали и опубликовали микропатч, который устраняет проблему удаленного выполнения кода диспетчера очереди печати. Однако исправление было создано только для серверных версий Windows Server, в частности для Windows Server 2008 R2, Windows Server 2021, Windows Server 2016 и Windows Server 2019.

Сканер уязвимостей TrustWave не выполняет сканирование из-за компьютера с Windows 10, на котором запущен RDP:

Алгоритмы блочного шифрования с размером блока 64 бита (например, DES и 3DES), день рождения, известный как Sweet32 (CVE-2016-2183)

ПРИМЕЧАНИЕ. В системах Windows 7/10 с RDP (протокол удаленного рабочего стола) уязвимый шифр, который следует отключить, помечен как «TLS_RSA_WITH_3DES_EDE_CBC_SHA».

Используя IIS Crypto (от Nartac), я попытался применить шаблон «Best Practices», а также шаблон PCI 3.1, однако оба они включают небезопасный шифр (TLS_RSA_WITH_3DES_EDE_CBC_SHA):

Если я отключу этот шифр, RDP с этого компьютера на многие станции Windows перестанет работать (он все еще работает на некоторых серверах 2008 R2 и 2012 R2). RDP-клиент просто выдает «Произошла внутренняя ошибка» и журнал событий:

При создании учетных данных клиента TLS произошла неустранимая ошибка. Состояние внутренней ошибки 10013.

Запрос на подключение TLS 1.2 был получен от удаленного клиентского приложения, но ни один из наборов шифров, поддерживаемых клиентским приложением, не поддерживается сервером. Запрос на соединение SSL не выполнен.

Было сгенерировано следующее фатальное предупреждение: 40. Состояние внутренней ошибки — 1205.

Или, если описанное выше невозможно, могу ли я что-то сделать на каждом узле RDP, к которому я больше не могу подключиться, и обработать его на этом конце?

— Обновление № 1 —

После отключения TLS_RSA_WITH_3DES_EDE_CBC_SHA на компьютере с Windows 10 я попытался подключиться к нескольким узлам RDP (половина из них завершилась с ошибкой «Внутренняя ошибка . »). Поэтому я сравнил один из этих хостов, к которому я могу подключиться, с тем, к которому я не могу подключиться. Оба 2008 R2. Оба имеют одинаковую версию RDP (6.3.9600, поддерживается протокол RDP 8.1).

Я сравнил протоколы и шифры TLS с помощью IIS Crypto, чтобы выполнить «Сохранить шаблон» в их текущих настройках, чтобы я мог сравнить файлы шаблонов. Они были идентичны! Так что, какая бы проблема ни была, похоже, это не проблема отсутствующего набора микросхем на хосте. Вот скриншот из Beyond Compare по файлам:

Можете ли вы использовать NetMon или Wireshark для захвата приветствия клиента / сервера, чтобы увидеть, о каком наборе шифров на самом деле идет речь при сбое соединения, а не об успешном?
@RyanRies: Уже сделал, но это никогда не добирается до фактического рукопожатия TLS. Клиент отправляет пакет «TPKT, продолжение», а сервер отвечает «RST, ACK».

В IIS Crypto есть возможность установить параметры как на стороне сервера (входящий), так и на стороне клиента (исходящий). Существует несколько шифров, которые необходимо оставить включенными на стороне клиента для совместимости.

Чтобы сделать то, что вы хотите, я бы лично пошел со следующим:

• Применить шаблон 3.1
• Оставьте все наборы шифров включенными
• Применить как к клиенту, так и к серверу (флажок установлен).
• Нажмите «Применить», чтобы сохранить изменения

Перезагрузите здесь, если хотите (и у вас есть физический доступ к машине).

• Применить шаблон 3.1
• Оставьте все наборы шифров включенными
• Применить к серверу (флажок снят).
• Снимите флажок с опции 3DES

Перезагрузка здесь должна привести к правильному конечному состоянию.

По сути, вы хотите только отключить входящий 3DES, но разрешить исходящее использование указанного набора шифров.

Это звучит многообещающе! Однако отключение 3DES 168, похоже, было ошибкой — я больше не могу подключиться к нему. После того, как я справлюсь с этим, я попытаюсь просто отключить шифр только на стороне сервера и доложить / принять ответ.
Я попробовал ваше предложение: 1) Примените «Рекомендации» и примените к серверу и клиенту, затем 2) Снимите флажок с шифра TLS_RSA_WITH_3DES_EDE_CBC_SHA и «Установите протоколы на стороне клиента» и примените снова, затем, конечно, перезагрузите компьютер. Проблема RDPing от этой машины все еще сохраняется. Дополнительные предложения приветствуются.
@ Зек странный . Я использовал ту же самую технику, и она работает.
@Zek Я только что понял, что сделал большую ошибку в том, как написал это. Я обновлю соответственно.
Я попробовал это. 1) Выберите шаблон 3.1 + оставьте все комплекты шифров без изменений + «Установить протоколы на стороне клиента» + проверьте TLS 1.0 (SQL и т. Д. Обрывы без TLS 1.0) + Применить и перезагрузить. 2) Выберите шаблон 3.1 + оставьте все комплекты шифров без изменений + «Установить протоколы на стороне клиента», не снимайте флажок + снимите флажок 3DES + отметьте TLS 1.0 + Применить и перезагрузить. Я больше не могу подключиться, «произошла внутренняя ошибка» (я думаю, что сервер должен поддерживать 3DES). Я подключаюсь с компьютера с Windows 10.

У меня была такая же проблема, установка патча KB3080079 на сервере позволяет поддерживать tls 1.1 и 1.2.

Обратите внимание, что для клиентов Windows 7 вам нужно будет установить обновление клиента rdp (KB2830477), иначе только Windows 8+ сможет подключиться.

Я просто дважды проверил, и эти обновления уже установлены (я думаю, что они уже включены в стандартное обновление Windows уже некоторое время), так что это не проблема.

Поделюсь ответ от TechNet нити , но первого BLUF:

Вывод о сбое сервера: Скорее всего, у вас есть другое различие между системами. Вы подключаетесь между разными версиями ОС, в одной системе включена поддержка FIPS, а в другой нет, или в вашей системе действуют другие ограничения шифрования HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphers . Я бы определенно включил протоколирование SCHANNEL в системе, которая работает, чтобы определить, какой шифр используется. Хотелось бы получить ответ, если бы вы каким-то образом заставили RDP работать с альтернативным шифром.

Мы получили это на работу!

Очевидно, что в 2008 и 2012 годах есть синтаксические проблемы, а в 2008/7 требуется трейлинг / 168. 2012 / 8.1 / 10 нет.

ключ на 2008 выглядит так: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersTriple DES 168/168

И ключ на 2012 год выглядит так: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersTriple DES 168

Я могу подтвердить, что использование «Triple DES 168/168» НЕ отключает 3DES в системе. Вы можете доказать это себе с помощью сканера протокола (например, Nessus) или включив ведение журнала SCHANNEL:

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNEL] «EventLogging»=dword:00000007

Тогда у вас будут события в журнале SYSTEM, например;

Рукопожатие клиента SSL успешно завершено. Согласованные криптографические параметры заключаются в следующем.

Протокол: TLS 1.0 CipherSuite: 0x2f Сила обмена: 1024

Для меня результат 0xa, который Google показывает как TLS_RSA_WITH_3DES_EDE_CBC_SHA.

Когда я использую «Triple DES 168» (без / 168), системный идентификатор события 36880 не появляется и сеанс RDP блокируется.

Службы удаленных рабочих столов (RDS) Для шифрования сетевого взаимодействия Служб удаленных рабочих столов этот параметр политики поддерживает только алгоритм шифрования Triple DES.

Таким образом, оба из них поддерживают идею, что RDP может использовать только 3DES. Тем не менее, эта статья предлагает более широкий спектр шифров: FIPS 140 Validation

В конечном счете, неясно, может ли RDP поддерживать протоколы не 3DES, когда включен режим FIPS, но свидетельства предполагают, что это не так.

Я не вижу доказательств того, что Server 2012 R2 будет функционировать иначе, чем Server 2008 R2, однако, похоже, что Server 2008 R2 основан на соответствии FIPS 140-1, а Server 2012 R2 следует FIPS 140-2, поэтому вполне возможно, что Server 2012 R2 поддерживает дополнительные протоколы. Вы заметите дополнительные протоколы в ссылке FIPS 140 Validation .

В заключение: я не думаю, что Server 2008 R2 может поддерживать RDP в режиме FIPS с отключенным 3DES. Я рекомендую выяснить, соответствует ли ваша система условиям для атаки SWEET32 (более 768 ГБ отправлено за один сеанс) и стоит ли отключать 3DES, чтобы исключить возможность RDP. Существуют и другие утилиты для управления серверами за пределами RDP, особенно в мире, где виртуализация широко распространена.

Атака, которая получила название SWEET32, посвящен отдельный сайт, ее подробности и демо-видео исследователи планируют представить на конференции ACM Conference on Computer and Communications Security, которая в следующем месяце пройдет в Австрии. Мы собрали известную на данный момент информацию в своем материале.

В чем проблема

Криптографические протоколы вроде TLS, SSH, IPsec и OpenVPN используют алгоритмы блочного шифрования (AES, Triple-DES, Blowfish). Таким образом обеспечивается шифрование передаваемых между клиентом и сервером данных. Данные при этом разбиваются на блоки фиксированной длины, каждый из которых шифруется отдельно. Более старые шифры вроде Triple-DES и Blowfish используют размер блока равный 64 битам, а AES использует размер блока 128 бит.

Короткая длина блока делает шифр уязвимым к «атакам дня рождения». Исследователи заявляют о том, что подобные атаки встречаются для 64-битных шифров протоколов TLS и OpenVPN. Подобные алгоритмы шифрования используются огромным количеством ресурсов в интернете.

Перехват защищенного трафика

В ходе PoC-атаки исследователям удалось сделать это меньше чем за два дня с помощью специального JavaScript-кода для генерации трафика.

С точки зрения вычислительной сложности атака SWEET32 сравнима с недавними атаками на шифр RC4. Кроме того, исследователям удалось осуществить похожие атаки на VPN-сессии, использующие 64-битные шифры — к примеру, на практике эта ситуация может встретиться в случае применения OpenVPN, который настроен на использование Blowfish.

Насколько все серьезно

В итоге общее число серверов, которые принимают большое количество запросов по одному соединению, остается большим, пишут исследователи. Исследователи просканировали веб-серверы из каталога Alexa — для этого использовался инструмент cipherscan. Выяснилось, что 86%, поддерживающих TLS, включают Triple-DES в качестве одного из используемых шифров.

PoC-атака

Содержание файла attack.html:

В ходе эксперимента «захват» зашифрованных пакетов проводился с помощью tcpdump, а для извлечения блоков шифротекста применялась программа на C++, использующая libpcap.

Как защититься

Исследователи рекомендуют отказаться от использования 64-битных “legacy-шифров” блочного шифрования. Если же это по какой-то причине невозможно, то снизить вероятность ее успешного проведения можно следующим образом:

Веб-браузеры должны использовать 3DES в качестве “fallback-only” шифра во избежание ситуации, при которой он используется в общении с серверами, поддерживающими AES.

TLS-библиотеки и приложения должны ограничивать длину TLS-сессий для 64-битных шифров. Сделать это можно с помощью механизма повторной установки соединения.

Пользователи OpenVPN могут изменить используемый шифр с «дефолтного» Blowfish на AES. Если сделать этого нельзя, то необходимо принудительно инициировать повторный выпуск ключей с помощью функции reneg-bytes 64000000.

Главная угроза цифровизации — не нехватка бюджетов и даже не технологическое отставание. Куда большей бедой для развития бизнесов по всему миру стали киберпреступники и взятые ими на вооружение программы-вымогатели. В июле 2020 года ежедневно фиксировались 2300 случаев заражения устройств таким ПО. Спустя всего полгода эта цифра выросла более чем в 7 раз — до 17200 устройств.

• Что нужно знать о тактиках злоумышленников, чтобы спасти свой бизнес?
• Каким компаниям киберпреступники угрожают в первую очередь и какие цели они преследуют?
• Какими будут последствия заражения, кроме необходимости платить выкуп?

Зарегистрируйтесь, чтобы скачать исследование компании Fortinet о программах-вымогателях и основных проблемах, которые они вызывают.

Компании все чаще становятся жертвами программ-вымогателей. Любая автоматизация расширяет поверхность атаки. Чем более успешной она окажется, тем большей окажется сумма ущерба для бизнеса. Наибольшей проблемой становятся атаки с использованием электронной почты, а также эксплойты уязвимостей «нулевого дня» и компрометация авторизованных цепочек доставки.

• Можно ли прекратить атаку хакеров когда она только-только разворачивается?
• Какие векторы атак чаще всего используют киберпреступники?
• Чем могут помочь шлюзы защиты почты и межсетевые экраны?

Зарегистрируйтесь, чтобы скачать обзор Fortinet о решениях, которые помогают отражать атаки программ-вымогателей.

В ОС Windows Server с самого момента ее появления в 2003 г. содержалась опасная уязвимость, дававшая хакерам полный контроль над сервером под ее управлением. Ее выявили лишь в мае 2020 г., а Microsoft выпустила патч для ее устранения еще через два месяца, в июле 2020 г. Воспользоваться ею сможет даже начинающий хакер – она предельно проста в эксплуатации, что делает ее очень опасной.

Почти совершеннолетняя уязвимость

Серверные операционные системы Windows Server корпорации Microsoft в течение 17 лет содержали очень опасную уязвимость SigRed. Известно о ней стало лишь в мае 2020 г., а патч, устраняющий ее, Microsoft выпустила спустя еще два месяца.

SigRed обнаружили специалисты ИБ-компании Check Point. По их словам, брешь была частью всех версий ОС Windows Server, разработанных Microsoft с 2003 по 2019 гг. включительно.

SigRed может использоваться с целью проведения удаленных атак, притом даже автоматизированных, и не требует предварительной аутентификации в системе. Уязвимости был присвоен идентификатор CVE-2020-1350, и она получила максимальные 10 баллов по шкале оценки CVSSv3. Это означает, что для ее эксплуатации злоумышленнику не нужно обладать углубленными техническими знаниями – она очень проста в использовании.

Как работает SigRed

По данным экспертов Check Point, эксплуатация SigRed осуществляется хакером путем вредоносных DNS-запросов к DNS-серверам Windows. Это дает ему возможность запускать любой нужный ему код и полностью перехватить контроль над этими серверами.

В частности, киберпреступник сможет управлять сетевым трафиком, получит доступ к персональным данным пользователей (при их наличии на сервере), и даже будет иметь возможность контролировать электронную почту людей, подключенных к скомпрометированному серверу.

Работа уязвимости основана на общем принципе анализа DNS-сервером Windows всех входящих и обработки переадресованных DNS-запросов. К примеру, отправка запроса длиной свыше 64 КБ может привести к контролируемому переполнению буфера, что и даст хакеру выполнить на сервере нужный ему код.

Специалист Check Point Саги Тцадик (Sagi Tzadik) назвал SigRed черверобразной уязвимостью. Он сообщил, что ее использование на одном сервере может запустить своего рода цепную реакцию, что приведет к распространению атаки от одной скомпрометированной машины к другой без дополнительных действий со стороны хакера.

Как защититься от атаки

На момент публикации материала существовало два действенных способа снижения до нуля вероятности стать жертвой хакера, воспользовавшегося именно уязвимостью CVE-2020-1350. Первый и самый очевидный – это установка патча, закрывающего ее.

Пакет обновлений KB4569509 в настоящее время доступен для скачивания и установки. Он подходит для интеграции в состав всех версий Windows Server, начиная с 2008 Service Pack 1. Устанавливать патч необходимо на сервер, использующийся в качестве DNS-сервиса.

Microsoft выпустила патч для устранения SigRed на 17 лет позже, чем было нужно

1. «reg add HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesDNSParameters” /v “TcpReceivePacketSize” /t REG_DWORD /d 0xFF00 /f»

2 net stop DNS && net start DNS.

Добавим, что на момент публикации материала не было зафиксировано ни одного случая взлома Windows-серверов путем эксплуатации SigRed. Однако Microsoft обратилась к Check Point с просьбой о временном удалении из их отчета технической информации об этой бреши, чтобы дополнительно снизить вероятность ее использования, пока большинство копий Windows Server не будут пропатчены.

Другие многолетние уязвимости

В ОС семейства Windows могут существовать и другие уязвимости, которые Microsoft по тем или иным причинам не устраняет годами. К примеру, в январе 2020 г. CNews писал об обнаружении опасной «дыры», затронувшей все без исключения версии Windows. выпущенные за последние 24 года. Впервые она появилась еще в Windows NT 4.0, увидевшей свет в 1996 г.

Не меньшую озабоченность вызывает и то, что уязвимость в библиотеке может использоваться для подмены цифровой подписи, привязанной к конкретному ПО. Этим может воспользоваться злоумышленник, выдав вредоносное ПО за легитимное, выпущенное и подписанное добросовестным разработчиком.

Подобные просчеты разработчиков встречаются не только в Windows. Так, в 2014 г. В Linux и Unix была найдена масштабная многолетняя брешь, относящаяся к командной оболочке Bash. В ней есть переменные окружения, которые можно задавать согласно специальному синтаксису при вызове оболочки. Оболочка запускается и задает значения переменных, прописанные в синтаксисе. Уязвимость заключалась в том, что непосредственно в самом задаваемом значении переменной можно было дописать произвольные команды, которые оболочка также выполнила бы. В случае если Bash была назначена системной оболочкой по умолчанию, она могла быть использована злоумышленниками для проведения сетевых атак на серверы с применением веб-запросов.

Многолетние уязвимости есть и в составе популярных программ. В начале 2019 г. компания Check Point обнаружила серьезную брешь в популярном архиваторе WinRAR, созданном в 1995 г. российским программистом из Челябинска Евгением Рошалом. Багу на тот момент было не менее 14 лет – он появился в программе не позднее 2005 г.

Уязвимость содержалась в библиотеке unacev2.dll, использовавшейся для синтаксического анализа давно устаревшего и редко используемого формата архивов ACE – этот формат был разработан еще в 1990 г. На практике злоумышленник мог подсунуть жертве вредоносный архив ACE, замаскированный под файл RAR. При открытии этого файла WinRAR уязвимость, известная как выход за пределы назначенного каталога, позволяла злоумышленнику разархивировать содержащиеся внутри файлы в произвольный каталог Windows – по выбору злоумышленника.

Читайте также:

  

• Windows defender чем заменить

  

• Hiberfil sys удалить windows 10

  

• Как узнать версию пакета linux

  

• Настройка cisco jabber для windows

  

• Ninja linux что это