CVE-2020-0753-and-CVE-2020-0754

Writeup и POC для CVE-2020-0753, CVE-2020-0754 и шести исправленных уязвимостей DOS в Windows

Эксплуатация ошибки состояния гонки в файловой системе - анализ CVE-2020-0753 и CVE-2020-0754

Служба отчетов об ошибках Windows исправила 2 ошибки повышения привилегий в последний Patch Tuesday, эти две ошибки зарегистрированы как CVE-2020-0753 и CVE-2020-0754. Обе ошибки используют состояние гонки в операциях службы с файловой системой. Однако эти две уязвимости не так просто эксплуатировать из-за маленьких окон гонки и неопределенных мест сброса файлов. Здесь мы делимся нашими методами их эксплуатации.

Коренная причина двух ошибок гонки приведена в наших отчетах, фактическую причину можно выразить как Предсказуемость уязвима. Когда служба WER обрабатывает временные файлы, она манипулирует расположением файла C:\ProgramData\Microsoft\Windows\WER\Temp, который является каталогом с доступом на чтение/запись для аутентифицированных пользователей. Это означает, что обычный пользователь со средним уровнем целостности может перезаписывать файл, созданный службой WER, и даже превратить его в ссылку файловой системы, чтобы повредить/удалить другие файлы, к которым они не могли получить доступ.

Чтобы обеспечить безопасность файловых операций, служба WER использует стандартный API под названием GetTempFileNameW и обернутый им wersvc.dll->UtilGetTempFile. Этот API помогает WerSvc генерировать незанятые случайные имена файлов в форме "WER****.tmp", случайная часть имени файла генерируется как 4-байтовое шестнадцатеричное число от 0000 до FFFF. Если одно число уже было занято для создания файла, API выберет другое случайное имя файла.

Эта стратегия явно имеет недостаток: если создать 65535 файлов с именами от WER0000.tmp до WERFFFE.tmp, API выберет случайное число и проверит, существует ли файл с таким именем, например WERA560.tmp. Он обнаружит, что файл уже существует, и продолжит проверку от WERA560.tmp до WERFFFF.tmp. Пока идет проверка, появляется окно подготовки, потому что мы нашли способ заставить WerSvc зависнуть на вызове GetTempFileNameW на 4-5 секунд, что представляет собой большой временной промежуток. Тем временем мы заставляем службу сбросить временный файл с фиксированным именем, а именно WERFFFF.tmp.

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

1. Файл, созданный службой, находится в месте, контролируемом обычным пользователем.
2. Служба закрывает все дескрипторы файла.
3. Служба будет использовать файл позже (запись или удаление).

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

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

• мы помещаем все файлы WER***.tmp в $pwd\1\ и создаем точку соединения $pwd\2\ -> $pwd\1\;
• мы создаем процесс для непрерывного запуска этой функции с путем $pwd\2\ и создаем другой процесс для непрерывного выполнения команды SetOplock $pwd\1\WERFFFF.tmp;
• Как только Oplock срабатывает, мы создаем точку соединения $pwd\2\ -> \RPC CONTROL\, а затем создаем объект символической ссылки \RPC CONTROL\WERFFFF.tmp -> $target и \RPC CONTROL\WERFFFF.tmp.etl -> $target;
• Снимаем Oplock, целевой файл будет удален с системными привилегиями.

Подробное описание эксплуатации и POC предоставлены в WERReport-CVE-2020-0753.

Эксплуатируя недостаток в GetTempFileNameW, мы получаем предсказуемое местоположение, с которым будет работать служба; используя многоуровневые точки соединения файловой системы, мы делаем состояние гонки надежно эксплуатируемым.

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

От произвольного повреждения файлов с частичным контролем до повышения привилегий

Чтобы объяснить, почему произвольное повреждение файлов (если вы можете контролировать очень малую часть содержимого файла: менее 63 байт) может быть превращено в повышение привилегий (EoP), нам нужно обратить внимание на механизм работы Защитника Windows.

У Защитника Windows есть база сигнатур вредоносных программ. Если какой-то файл содержит сигнатуру вредоносного ПО, Защитник считает его вредоносным и удаляет. Однако эта функция приводит к дополнительной поверхности атаки. Например, на WCTF2019 @icchy из tokyowesterns разработал задание Windows ctf под названием "Gyotaku The Flag", которое использует эту функцию как оракул для утечки информации.

Здесь мы используем эту функцию Защитника Windows для удаления произвольного файла, если у нас есть произвольное повреждение файла с частичным контролем его содержимого. Мы можем просто записать сигнатуру вредоносного ПО в файл и инициировать стандартное сканирование Защитником Windows, файл будет помещен в изолированную область Защитника, которая может быть удалена обычным пользователем (т.е. пользователем со средним уровнем целостности без прав администратора) простым запуском операции сканирования дважды.

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

• Шаг 1:

Повредите целевой файл с помощью ошибки, поместите в него строку функции, распознаваемую Защитником Windows.

• Шаг 2:

Запустите сканирование Защитника Windows целевого файла, что приведет к его изоляции.

• Шаг 3:

Запустите сканирование снова, целевой файл будет удален.

Используя эту технику, мы получаем произвольное удаление файлов с помощью Защитника.

Произвольное удаление файлов можно использовать гораздо проще для получения дальнейших привилегий.

Шесть исправленных уязвимостей DOS файловой системы в Microsoft OneDrive

Microsoft OneDrive — это пакет приложений, предоставляющий услуги персонального облачного хранения, это приложение было интегрировано в Windows как опция установки по умолчанию, начиная с Windows 8. В ходе нашего исследования было обнаружено и отправлено в MSRC 6 уязвимостей в запланированных задачах обслуживания OneDrive.

---

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

Все 6 ошибок вызваны неправильной обработкой службой жестких и символических ссылок при работе с расположениями, контролируемыми обычным пользователем. При эксплуатации этих ошибок сложность возникает из-за того, что имя файла обычно содержит PID текущего процесса или временную метку, указывающую, когда файл обрабатывается. Обе проблемы можно решить, установив oplock на уникальный DLL-файл, который служба попытается загрузить при запуске, что позволяет нам получить все необходимое для предсказания имени файла, с которым служба будет работать позже. Пример POC предоставлен в каталоге FileSyncConfigTemp_hardlink.

Влияние уязвимостей

Все 6 уязвимостей, указанных выше, предоставлены с полным отчетом и программой POC, хотя большинство ошибок в первую очередь вызывают произвольное повреждение файлов, такой вид ошибок все равно вызывает сбой системы (путем перезаписи критического системного конфигурационного файла), и все они потребуют переустановки Windows. Таким образом, они соответствуют стандарту типа ошибок отказа в обслуживании системы Windows.

Кроме того, такой вид ошибок может фактически привести к повышению привилегий в определенном контексте. Мы обсудили метод эксплуатации, который может использовать проблему произвольной перезаписи файлов для достижения примитива произвольного удаления файлов, таким образом, повышение привилегий достижимо.

Авторы уязвимостей

Fangming Gu

Zhiniang Peng из Qihoo 360 Core Security

Хронология

Feb 02 2020: Уязвимости зарегистрированы.

Feb 08 2020: MSRC изучил и ответил по поводу 6 ошибок в OneDrive, которые мы отправили. Их заключение: не исправлять из-за Слишком большого взаимодействия с пользователем / слишком сложно создать надежный эксплойт.

Feb 08 2020: Мы ответили: Нет необходимости во взаимодействии с пользователем. Нужно просто дождаться выполнения запланированной задачи. Так что этот сценарий типичен.

Feb 11 2020: MSRC ответил: Как вы получаете конкретный файл на машине пользователя? И вы помещаете все перестановки этого файла в эту папку? Должно ли оно точно совпадать с Дата/Час/PID? Именно по этим причинам кажется, что это требует слишком больших усилий от пользователя.

Feb 11 2020: Мы ответили: Наш POC — это упрощенная версия. Чтобы уменьшить усилия по предсказанию имени файла. В реальности нужно просто установить oplock. Тогда вы получите все {pid},{час},{дата}. Так что взаимодействие с пользователем не требуется.

Feb 12 2020: Запрос: можем ли мы опубликовать writeup для этих 6 уязвимостей.

Feb 13 2020: MSRC ответил: Вы можете опубликовать writeup.

Feb 22 2020: Детали опубликованы

Обновление статуса: Все 6 уязвимостей получили исправление в мартовском Patch Tuesday 2020 года.